From wagner at elegosoft.com  Tue Jun  1 11:03:01 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Tue, 01 Jun 2010 11:03:01 +0200
Subject: [M3devel] OS for CM3
In-Reply-To: <20100522215317.E428D1A2096@async.async.caltech.edu>
References: <20100522215317.E428D1A2096@async.async.caltech.edu>
Message-ID: <20100601110301.g7805qomqskk4wws@mail.elegosoft.com>

Quoting Mika Nystrom <mika at 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?

Do you have simple test programs we could use to regularly measure
the performance of multithreading on different target platforms?

FreeBSD should support scaling via threads, but I've no idea about
actual performance yet.

I've been using FreeBSD/amd64 for about half a year now at home
(due to sudden death of my old hardware) and it's running OK,
except for the occasional suprise after a source upgrade ;-)

I second your feeling of dismay about loss of traditional system
administration conventions... no time to keep up-to-date with
everything.

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  Tue Jun  1 13:16:16 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 1 Jun 2010 11:16:16 +0000
Subject: [M3devel] m3cg_pop checks for side effects on the wrong thing
Message-ID: <COL101-W3186CD99E2045404ED5924E6EF0@phx.gbl>


Tony, I started looking at the effect of fixing the m3cg_pop "bug", where it checks for tree_side_effects on the wrong thing.
? You know -- is it significant? Should it be fixed in release?
In every case I looked at, optimized and not, all the fix did was add unnecessary code.
So I took another step: I tried removing the add_stmt there all together.
I built m3core before and after that, optimized and not.
Again, the code appears to be equivalent either way, just that add_stmt adds unnecessary code.


I'm going to try building the compiler and the rest of the system with this change.
If that works, I think this is an ok change.
? And we can rest easy about release.


?- Jay




 		 	   		  

From jay.krell at cornell.edu  Tue Jun  1 18:00:41 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 1 Jun 2010 16:00:41 +0000
Subject: [M3devel] uninitialized + insert_mn
Message-ID: <COL101-W235ED30E74DF1BC021F7CBE6EF0@phx.gbl>


../src/runtime/common/RTCollector.m3: In function 'RTCollector__CleanOlderRefSanityCheck':
../src/runtime/common/RTCollector.m3:1724: warning: 'M3_EB9wjE_tc' is used uninitialized in this function
../src/runtime/common/RTCollector.m3: In function 'RTCollector__RefSanityCheck':
../src/runtime/common/RTCollector.m3:1702: warning: 'M3_EB9wjE_tc' is used uninitialized in this function


PROCEDURE RefSanityCheck (<*UNUSED*>v: RTHeapMap.Visitor;? cp? : ADDRESS) =
? VAR ref := LOOPHOLE(cp, UNTRACED REF RefReferent)^;
? BEGIN
??? IF ref # NIL THEN
????? VAR
??????? h? := HeaderOf(ref);
??????? tc := h.typecode;
????? BEGIN


It is actually *kind of* true.
The store to tc uses load tc, insert_mn, store tc.


Any idea what to do?
offset=0
count=20


I'm willing to just go without -Wuninitialized, or look into turning it off for any function that uses insert.
Maybe look into what gcc uses -- hey, maybe bitfield refs? Yeah yeah, I'm half serious.
Of course I remember they caused a problem.
Perhaps we can use them, just be sure to twiddle the bit offsets depending on endian?


What I'm really doing is looking into removing the heavy use of volatile.


?- Jay

 		 	   		  

From jay.krell at cornell.edu  Tue Jun  1 18:10:11 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 1 Jun 2010 16:10:11 +0000
Subject: [M3devel] uninitialized + insert_mn
In-Reply-To: <COL101-W235ED30E74DF1BC021F7CBE6EF0@phx.gbl>
References: <COL101-W235ED30E74DF1BC021F7CBE6EF0@phx.gbl>
Message-ID: <COL101-W336E3972DCE285DA3850A7E6EF0@phx.gbl>


I found the lame hack that volatizing whatever store follows an insert_mn works.
If it suffices for the entire tree I'll go with it for now.

?- Jay


----------------------------------------
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu; m3devel at elegosoft.com
> Date: Tue, 1 Jun 2010 16:00:41 +0000
> Subject: [M3devel] uninitialized + insert_mn
>
>
> ../src/runtime/common/RTCollector.m3: In function 'RTCollector__CleanOlderRefSanityCheck':
> ../src/runtime/common/RTCollector.m3:1724: warning: 'M3_EB9wjE_tc' is used uninitialized in this function
> ../src/runtime/common/RTCollector.m3: In function 'RTCollector__RefSanityCheck':
> ../src/runtime/common/RTCollector.m3:1702: warning: 'M3_EB9wjE_tc' is used uninitialized in this function
>
>
> PROCEDURE RefSanityCheck (<*UNUSED*>v: RTHeapMap.Visitor;  cp  : ADDRESS) =
>   VAR ref := LOOPHOLE(cp, UNTRACED REF RefReferent)^;
>   BEGIN
>     IF ref # NIL THEN
>       VAR
>         h  := HeaderOf(ref);
>         tc := h.typecode;
>       BEGIN
>
>
> It is actually *kind of* true.
> The store to tc uses load tc, insert_mn, store tc.
>
>
> Any idea what to do?
> offset=0
> count=20
>
>
> I'm willing to just go without -Wuninitialized, or look into turning it off for any function that uses insert.
> Maybe look into what gcc uses -- hey, maybe bitfield refs? Yeah yeah, I'm half serious.
> Of course I remember they caused a problem.
> Perhaps we can use them, just be sure to twiddle the bit offsets depending on endian?
>
>
> What I'm really doing is looking into removing the heavy use of volatile.
>
>
>  - Jay
>
>
 		 	   		  

From jay.krell at cornell.edu  Tue Jun  1 19:16:46 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 1 Jun 2010 17:16:46 +0000
Subject: [M3devel] reducing use of volatile in backend?
Message-ID: <COL101-W17AA739AA2DE2050C6CCD0E6EF0@phx.gbl>


Tony, would we maybe be better off not using volatile everywhere but
selectively turning off optimizations in m3_post_options?
You know, using volatile probably disables more than necessary?
I'm experimenting with this.

?- Jay




 		 	   		  

From jay.krell at cornell.edu  Tue Jun  1 19:58:50 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 1 Jun 2010 17:58:50 +0000
Subject: [M3devel] optimizer doesn't do much?
Message-ID: <COL101-W32EFB0D6FFF6C0D451CC7FE6EF0@phx.gbl>


Here's a version from cm3cg with lots of optimizations turned on, a few turned off, *and* volatile generally removed:

??? xorl??? %eax, %eax
??? testq??? %rdi, %rdi
??? movq??? %rsi, %rdx
??? je??? L3
??? cmpq??? $-1, (%rdi)
??? movq??? %rdi, %rax
??? jne??? L3
??? movq??? 16(%rdi), %rax
??? movq??? %rax, -16(%rsp)
??? movq??? 8(%rdi), %rax
L3:
??? movq??? -16(%rsp), %r10
??? movq??? %rdx, %rdi
??? movq??? %rax, %r11
??? jmp??? *%r11

Much better!

?- Jay


----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Subject: optimizer doesn't do much?
> Date: Sun, 30 May 2010 18:11:26 +0000
>
>
> 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  Tue Jun  1 21:21:47 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 1 Jun 2010 19:21:47 +0000
Subject: [M3devel] unreachable code
Message-ID: <COL101-W43E6ACB5FD4C86FB00CA6FE6EF0@phx.gbl>


Here's nice stuff the compiler reports:

"../src/misc/stochastic/RandomImprovedMcGill.m3", line 63: warning: unreachable statement
"../src/misc/stochastic/RandomSubtractiveFibo2.m3", line 51: warning: unreachable statement

??? <* ASSERT Word.Size = 32 *>

Probably they just need to use Cstdint.uint32_t and mask sometimes..

?..Jay
 		 	   		  

From hosking at cs.purdue.edu  Tue Jun  1 23:05:30 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Tue, 1 Jun 2010 16:05:30 -0500
Subject: [M3devel] reducing use of volatile in backend?
In-Reply-To: <COL101-W17AA739AA2DE2050C6CCD0E6EF0@phx.gbl>
References: <COL101-W17AA739AA2DE2050C6CCD0E6EF0@phx.gbl>
Message-ID: <AA1F4490-A9C7-4F94-8E03-65A5E9031424@cs.purdue.edu>

We don't want to disable optimisations for types where it makes sense  
to have them. Better to smarten up typebased alias analysis instead so  
we can get rid of volatile properly.

Sent from my iPhone

On Jun 1, 2010, at 12:16 PM, Jay K <jay.krell at cornell.edu> wrote:

>
> Tony, would we maybe be better off not using volatile everywhere but
> selectively turning off optimizations in m3_post_options?
> You know, using volatile probably disables more than necessary?
> I'm experimenting with this.
>
>  - Jay
>
>
>
>
>


From jay.krell at cornell.edu  Tue Jun  1 23:55:31 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 1 Jun 2010 21:55:31 +0000
Subject: [M3devel] reducing use of volatile in backend?
In-Reply-To: <AA1F4490-A9C7-4F94-8E03-65A5E9031424@cs.purdue.edu>
References: <COL101-W17AA739AA2DE2050C6CCD0E6EF0@phx.gbl>,
	<AA1F4490-A9C7-4F94-8E03-65A5E9031424@cs.purdue.edu>
Message-ID: <COL101-W405F0F081CEA577B80A523E6EF0@phx.gbl>


I've had *a lot* of success here the past few hours.
 
 
There is an assert starting up mentor I need to look at, possibly out of data binaries.
  The one in socket.c assert(lossless_socklen || socklen == null || socklen < 1<<30.
 
 
Compiler seems to work.
  Lots of things do break it, so that is something.
 
 
Various gui apps startup.
  Some of the gui apps don't work, but nor did older copies I had -- fours, badbricks, and I think columns, wouldn't take any mouse clicks. I have to test older versions. Could be unrelated.
 
 
 
Here is what I have:
 
  The vast vast majority of optimizations can be enabled.
 
  Nearly all uses of volatile can be removed.
 
  Just a few optimizations "need" to be disabled.
 
In particular:
 I only have volatile remaining:
    on store after insert_mn (special case)
 
    floating point (huh? wierd)
     compile errors without this 
 
    in functions that call setjmp or vfork
      This is very reasonable, but we should try to limit it to not all the variables, only what are accessed after the second return (I'm not sure how that computes for vfork, but for setjmp it makes sense to me.
 
 
    on the load/store in loophole
      compile errors without this; perhaps redundant with the floating point check
 
 
    on load link, else it gets uninitialized warning 
 
 
 
Also I found a likely bug.
In functions that call setjmp/vfork, we volatize already seen parameters and locals, but we don't volatize not yet seen locals (in nested blocks) and temporaries. I fixed that.
 
  
 
 
 The optimizations I disabled, from memory:
 
 
  pre - partial redundancy elimination 
 
 
  fre - full redundancy elimination (these are related) 
    One or both of these causes the compiler to access violate in the optimizer, compiling libm3/Formatter.mc, but otherwise I think they compile m3core and libm3 entirely
 
 
  loop im (induction motion) - caused a compile error in Trestle 
 
  vrp - value range propagation
     This seems to be the biggest problem, no compile errors but "random" runtime malfunction, usually starting up cm3.
 
 
  insn_sched - wierd, caused a compile break
    but insn_sched_after_reload ok
 
 
 That's about it. All the ones with "alias" in them, only like two, I enabled, seemed ok.
  salias and strict_alias. I left strict alias till late in experimentation but really it seems ok.
 
 
I can compile the entire system, though I get lots of warnings about uninitialized variables.
I pass the backend the -Wuninitialized flag.
 
 
I test it out more -- the gui non-interaction, the mentor assert, and test other platforms.
But I think we'll have volatile mostly gone and just a small number of optimizations turned off fairly soon.
We can iterate more on the remaining optimizations.
 
 
Getting good typeinfo would be good so that gdb can debug.
And maybe so that other than stabs works.
 
 
 - Jay




----------------------------------------
> From: hosking at cs.purdue.edu
> To: jay.krell at cornell.edu
> Date: Tue, 1 Jun 2010 16:05:30 -0500
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] reducing use of volatile in backend?
>
> We don't want to disable optimisations for types where it makes sense
> to have them. Better to smarten up typebased alias analysis instead so
> we can get rid of volatile properly.
>
> Sent from my iPhone
>
> On Jun 1, 2010, at 12:16 PM, Jay K wrote:
>
>>
>> Tony, would we maybe be better off not using volatile everywhere but
>> selectively turning off optimizations in m3_post_options?
>> You know, using volatile probably disables more than necessary?
>> I'm experimenting with this.
>>
>> - Jay
>>
>>
>>
>>
>> 		 	   		  

From mika at async.async.caltech.edu  Wed Jun  2 05:52:26 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Tue, 01 Jun 2010 20:52:26 -0700
Subject: [M3devel] [M3commit] CVS Update: cm3
In-Reply-To: <COL101-W3678C92B3A9FA07AD57BF2E6D00@phx.gbl> 
References: <20100601124200.8E42B2474003@birch.elegosoft.com>,
	<E86D485E-C5D5-4B7A-8142-5E0BE31280DD@cs.purdue.edu>
	<COL101-W58EC381F7DE75AC44CFB57E6EF0@phx.gbl>,
	<5458A114-F000-4A90-9998-FD7DF63E06C0@cs.purdue.edu>
	<COL101-W3678C92B3A9FA07AD57BF2E6D00@phx.gbl>
Message-ID: <20100602035226.43C1F1A208F@async.async.caltech.edu>


Safety is important in that it allows you to limit the possible effects
of bugs.  Getting programs bug-free is of course a very difficult problem
no matter what you do.

But no I don't think warnings for uninitialized use of variables is 
something one should do in general in Modula-3.  The safety guarantees
lead to different idioms from in C---not so many compiler warnings
are required to get your code right.  And if you do screw up 
an uninitialized variable, the effect is going to be limited.
Unlike what happens in C, where if you screw up the initialization
of a pointer, for instance, all hell breaks loose.

Your example is contrived.  Usually the code looks like this

VAR
  x : T;
BEGIN
  IF cond1 THEN x := ... END; 
  ...
  IF cond2 THEN (* use x *) END
END

where the programmer knows that cond2 logically implies cond1.

I think the presence of VAR parameter passing makes these sorts of
warnings also less useful in Modula-3.   Is the following OK?

PROCEDURE InitializeIt(VAR a : T);
PROCEUDRE UseIt(VALUE a : T);

VAR x : T;
BEGIN
  InitializeIt(x);
  UseIt(x)
END

I would think your compiler can't prove that x is initialized.  Warning
or not?  I say no: this is actually very reasonable Modula-3 code.
But then do you want a warning for the IF?  It's logically the same.

There's a chapter in 
EWD's Discipline of Programming that deals with the problem in 
detail.  I think he winds up with six different "modes" for variables.

     Mika

Jay K writes:
>
>ok=2C so in C:
>=20
>int F()
>{
>  int i=3B
>  return i=3B
>}
>=20
>should warn or not?
>Prevailing wisdom is definitely.
>Main known exception is code to generate random numbers.
>  I believe this is how Debian broke key generation.
>=20
>=20
>Modula-3:
>=20
>=20
>PROCEDURE F(): INTEGER =3D=20
> VAR i: INTEGER=3B
>BEGIN
>  RETURN i=3B
>END F=3B
>=20
>=20
>Should warn or not?
>Since this identical to the C=2C prevailing wisdom is definitely.
>=20
>=20
>They are=2C I guess=2C "safe"=2C but most likely=2C incorrect.
>=20
>=20
>The compiler may have made "safety" guarantees=2C and they are significant=
>=2C
>but safe is far from correct=2C and however smart the compiler can be to lo=
>ok for correctness issues=2C is also nice.
>=20
>=20
>=20
>(Friend of mine conjectured something like: Safety guarantees have people d=
>eluded. Software will still have plenty of bugs and be plenty difficult to =
>get correct and require plenty of testing. Safety guarantees help=2C but th=
>ey are only a small step toward actual correctness.)
>=20
>=20
>=20
> - Jay
>
>
>----------------------------------------
>> Subject: Re: [M3commit] CVS Update: cm3
>> From: hosking at cs.purdue.edu
>> Date: Tue=2C 1 Jun 2010 20:04:00 -0400
>> CC: jkrell at elego.de=3B m3commit at elegosoft.com
>> To: jay.krell at cornell.edu
>>
>> Sure=2C an INTEGER is a valid value whatever the bits.
>>
>>
>> On 1 Jun 2010=2C at 17:44=2C Jay K wrote:
>>
>>>
>>> Start removing the rampant use of volatile in the backend and these warn=
>ings show up.
>>>
>>> Volatile quashes the uninitialized checks in the backend.
>>>
>>> Is it really ok for an INTEGER to be uninitialized? I realize it contain=
>s an "integer" value=2C as all bit patterns are.
>>>
>>> Some of these really do seem like bugs. Some do not.
>>> I'll try making fault_proc noreturn=2C which should remove some of them.
>>>
>>>
>>> - Jay
>>>
>>>
>>>
>>>
>>> ----------------------------------------
>>>> From: hosking at cs.purdue.edu
>>>> To: jkrell at elego.de
>>>> Date: Tue=2C 1 Jun 2010 16:29:20 -0500
>>>> CC: m3commit at elegosoft.com
>>>> Subject: Re: [M3commit] CVS Update: cm3
>>>>
>>>> This is bogus. The M3 compiler guarantees all variables are initialized=
>.
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On Jun 1=2C 2010=2C at 2:42 PM=2C jkrell at elego.de (Jay Krell) wrote:
>>>>
>>>>> CVSROOT: /usr/cvs
>>>>> Changes by: jkrell at birch. 10/06/01 14:42:00
>>>>>
>>>>> Modified files:
>>>>> cm3/m3-libs/m3core/src/convert/: Convert.m3
>>>>>
>>>>> Log message:
>>>>> initialize locals=3B I get warnings that some not quite all=2C are
>>>>> used uninitialized if I remove the volatile/sideeffects on every
>>>>> load/store in parse.c
>> 		 	   		  =


From jay.krell at cornell.edu  Wed Jun  2 06:50:28 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 2 Jun 2010 04:50:28 +0000
Subject: [M3devel] warning for uninitialized variables?
In-Reply-To: <20100602035226.43C1F1A208F@async.async.caltech.edu>
References: <20100601124200.8E42B2474003@birch.elegosoft.com>, ,
	<E86D485E-C5D5-4B7A-8142-5E0BE31280DD@cs.purdue.edu>,
	<COL101-W58EC381F7DE75AC44CFB57E6EF0@phx.gbl>, ,
	<5458A114-F000-4A90-9998-FD7DF63E06C0@cs.purdue.edu>,
	<COL101-W3678C92B3A9FA07AD57BF2E6D00@phx.gbl>,
	<20100602035226.43C1F1A208F@async.async.caltech.edu>
Message-ID: <COL101-W59770EAA64E52A966D79F3E6D00@phx.gbl>


Wow. You really surprise me Mika.


To warn on this kind of thing, to me, there is no question.


Limting the affects by virtue of being safe isn't much consolation.
The program can easily go down a "safe" but very incorrect path.


There are several forms.
In fact, sometimes the compiler says something "is" used uninitialized.
Sometimes it says "maybe".


In your example, generally, once the address is taken of a variable,
the compiler gives up. Esp. if that address is passed to a function it doesn't "see".


However compilers are getting better.
Windows headers are now annotated with "in" and "out", etc. with
a calculus behind them, not just informal human definitions.


So if you pass something by pointer to "in" you should a warning/error.
If it is "out", ok.


The annotations can even be checked, if you write to something that is "in"
you should get a warning/error.


There are many more warnings in the tree than I have yet looked at.
I've seen a few forms.
Some are because the compiler doesn't know that some functions don't return.
I'll see about improving that. Though I think there's a limit to how good I can manage,
unless we add a <* noreturn *> pragma.


One form is:
a: INTEGER
if cond
? a := 1;
...
if cond
? use a
?

When the compiler is really unsure, it doesn't bother saying anything.


If code is lucky, it gets one smart human to study it carefully when it is first written.
However all code is lucky to have a smart and generally getting smarter compiler
look at it repeatedly.
We shouldn't throw away this tool so rapidly, the gcc optimizer and its data flow analysis.


I grant that by initializing to 0, I haven't necessarily made the code correct either.
But at least it is now consistent.


Even better would be runtime checks that stop if a variable is read before written.


See also the rules in Java and C# that require the compiler to be able to prove
a variable is written before read. Possibly even verifiable at load time.


Other forms look related to going "through" a switch statement with no arms handling the value.
I think I can address that by marking fault_proc as noreturn.


One form apparently in cm3ide would use uninitialized data if presented with a malformed file.
Good software doesn't depend on the well formedness of its input.

There are many more warnings like this in the tree.


My inclination is at least to temporarily hardcode the gcc backend to always optimize,
and always produce these warnings. People can look over them maybe and decide.
Or they can look over my "fixes".


Or I guess if people really really really really prefer, we can always turn off the warnings
and let the code lie. I really think that is the wrong answer.


I have been burned too much by uninitialized locals in C.
I put " = { 0 }" after everything.
Again, that isn't necessarily "correct", but at least the incorrect paths are consistent.
If they don't work and I happen down them, they will guaranteeably not work.


Uninitialized values can be different run to run.
Repeatability and consistency are important.


I'm also nervous about us not taking a hard line on integer overflow.
Overflown math doesn't necessarily lead to array out of bounds soon or ever.
It too can lead to incorrect but safe behavior.


?- Jay


----------------------------------------
> To: jay.krell at cornell.edu
> Date: Tue, 1 Jun 2010 20:52:26 -0700
> From: mika at async.async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] [M3commit] CVS Update: cm3
>
>
> Safety is important in that it allows you to limit the possible effects
> of bugs. Getting programs bug-free is of course a very difficult problem
> no matter what you do.
>
> But no I don't think warnings for uninitialized use of variables is
> something one should do in general in Modula-3. The safety guarantees
> lead to different idioms from in C---not so many compiler warnings
> are required to get your code right. And if you do screw up
> an uninitialized variable, the effect is going to be limited.
> Unlike what happens in C, where if you screw up the initialization
> of a pointer, for instance, all hell breaks loose.
>
> Your example is contrived. Usually the code looks like this
>
> VAR
> x : T;
> BEGIN
> IF cond1 THEN x := ... END;
> ...
> IF cond2 THEN (* use x *) END
> END
>
> where the programmer knows that cond2 logically implies cond1.
>
> I think the presence of VAR parameter passing makes these sorts of
> warnings also less useful in Modula-3. Is the following OK?
>
> PROCEDURE InitializeIt(VAR a : T);
> PROCEUDRE UseIt(VALUE a : T);
>
> VAR x : T;
> BEGIN
> InitializeIt(x);
> UseIt(x)
> END
>
> I would think your compiler can't prove that x is initialized. Warning
> or not? I say no: this is actually very reasonable Modula-3 code.
> But then do you want a warning for the IF? It's logically the same.
>
> There's a chapter in
> EWD's Discipline of Programming that deals with the problem in
> detail. I think he winds up with six different "modes" for variables.
>
> Mika
>
> Jay K writes:
>>
>>ok=2C so in C:
>>=20
>>int F()
>>{
>> int i=3B
>> return i=3B
>>}
>>=20
>>should warn or not?
>>Prevailing wisdom is definitely.
>>Main known exception is code to generate random numbers.
>> I believe this is how Debian broke key generation.
>>=20
>>=20
>>Modula-3:
>>=20
>>=20
>>PROCEDURE F(): INTEGER =3D=20
>> VAR i: INTEGER=3B
>>BEGIN
>> RETURN i=3B
>>END F=3B
>>=20
>>=20
>>Should warn or not?
>>Since this identical to the C=2C prevailing wisdom is definitely.
>>=20
>>=20
>>They are=2C I guess=2C "safe"=2C but most likely=2C incorrect.
>>=20
>>=20
>>The compiler may have made "safety" guarantees=2C and they are significant=
>>=2C
>>but safe is far from correct=2C and however smart the compiler can be to lo=
>>ok for correctness issues=2C is also nice.
>>=20
>>=20
>>=20
>>(Friend of mine conjectured something like: Safety guarantees have people d=
>>eluded. Software will still have plenty of bugs and be plenty difficult to =
>>get correct and require plenty of testing. Safety guarantees help=2C but th=
>>ey are only a small step toward actual correctness.)
>>=20
>>=20
>>=20
>> - Jay
>>
>>
>>----------------------------------------
>>> Subject: Re: [M3commit] CVS Update: cm3
>>> From: hosking at cs.purdue.edu
>>> Date: Tue=2C 1 Jun 2010 20:04:00 -0400
>>> CC: jkrell at elego.de=3B m3commit at elegosoft.com
>>> To: jay.krell at cornell.edu
>>>
>>> Sure=2C an INTEGER is a valid value whatever the bits.
>>>
>>>
>>> On 1 Jun 2010=2C at 17:44=2C Jay K wrote:
>>>
>>>>
>>>> Start removing the rampant use of volatile in the backend and these warn=
>>ings show up.
>>>>
>>>> Volatile quashes the uninitialized checks in the backend.
>>>>
>>>> Is it really ok for an INTEGER to be uninitialized? I realize it contain=
>>s an "integer" value=2C as all bit patterns are.
>>>>
>>>> Some of these really do seem like bugs. Some do not.
>>>> I'll try making fault_proc noreturn=2C which should remove some of them.
>>>>
>>>>
>>>> - Jay
>>>>
>>>>
>>>>
>>>>
>>>> ----------------------------------------
>>>>> From: hosking at cs.purdue.edu
>>>>> To: jkrell at elego.de
>>>>> Date: Tue=2C 1 Jun 2010 16:29:20 -0500
>>>>> CC: m3commit at elegosoft.com
>>>>> Subject: Re: [M3commit] CVS Update: cm3
>>>>>
>>>>> This is bogus. The M3 compiler guarantees all variables are initialized=
>>.
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>> On Jun 1=2C 2010=2C at 2:42 PM=2C jkrell at elego.de (Jay Krell) wrote:
>>>>>
>>>>>> CVSROOT: /usr/cvs
>>>>>> Changes by: jkrell at birch. 10/06/01 14:42:00
>>>>>>
>>>>>> Modified files:
>>>>>> cm3/m3-libs/m3core/src/convert/: Convert.m3
>>>>>>
>>>>>> Log message:
>>>>>> initialize locals=3B I get warnings that some not quite all=2C are
>>>>>> used uninitialized if I remove the volatile/sideeffects on every
>>>>>> load/store in parse.c
>>> =
 		 	   		  

From jay.krell at cornell.edu  Wed Jun  2 09:41:33 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 2 Jun 2010 07:41:33 +0000
Subject: [M3devel] ADR is *too* unsafe..
Message-ID: <COL101-W617B9602E6CAA0BBE5BE25E6D00@phx.gbl>


(*
Wow, ADR generates a plain ADDRESS, not an untraced ref to a specific type?
Doesn't this seem wrong? Doesn't unsafe code deserve a little better, say,
? to be at least as typesafe as C?
http://www.cs.purdue.edu/homes/hosking/m3/reference/unsafe.html

This is why 64bit m3-comm/tcp/src/TCP.m3 breaks randomly
on some platforms on an assertion failure in C. And the
compiler isn't going to help me find these type mismatches? Ugh.

This seems wrong. :(

I guess I should really really use VAR then.
*)


UNSAFE MODULE Main;
IMPORT Ctypes, Cstddef;


PROCEDURE F1(a:UNTRACED REF Ctypes.int) =
BEGIN
? F2(a); (* error, expected *)
END F1;


PROCEDURE F2(a:UNTRACED REF Cstddef.size_t) =
BEGIN
? F1(a); (* error, expected *)
END F2;


VAR c:Ctypes.int;
??? d:Cstddef.size_t;

??? 
BEGIN
? F1(ADR(c)); (* ok *)
? F1(ADR(d)); (* error expected but no *)
? F2(ADR(c)); (* error expected but no *)
? F2(ADR(d)); (* ok *)
END Main.



?- Jay
 		 	   		  

From mika at async.async.caltech.edu  Wed Jun  2 14:44:22 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Wed, 02 Jun 2010 05:44:22 -0700
Subject: [M3devel] warning for uninitialized variables?
In-Reply-To: <COL101-W59770EAA64E52A966D79F3E6D00@phx.gbl> 
References: <20100601124200.8E42B2474003@birch.elegosoft.com>, ,
	<E86D485E-C5D5-4B7A-8142-5E0BE31280DD@cs.purdue.edu>,
	<COL101-W58EC381F7DE75AC44CFB57E6EF0@phx.gbl>, ,
	<5458A114-F000-4A90-9998-FD7DF63E06C0@cs.purdue.edu>,
	<COL101-W3678C92B3A9FA07AD57BF2E6D00@phx.gbl>,
	<20100602035226.43C1F1A208F@async.async.caltech.edu>
	<COL101-W59770EAA64E52A966D79F3E6D00@phx.gbl>
Message-ID: <20100602124422.11C6D1A209A@async.async.caltech.edu>

Jay K writes:
>
>Wow. You really surprise me Mika.
>
>
>To warn on this kind of thing=2C to me=2C there is no question.
>
>
>Limting the affects by virtue of being safe isn't much consolation.
>The program can easily go down a "safe" but very incorrect path.

It is, though!  Do you always know what value to initialize the
variables to?  If not, you're just picking some value to shut up
the compiler, and now your code no longer expresses---to a human
reader---that x is uninitialized.

Remember, code is mainly written for humans!  Computers don't care
about fancy structuring, declarations, etc.  When you write a program,
you write it to be read by a human.  The fact that a variable is
uninitialized is a part of the design of the program.

It's an unfortunate fact that our languages don't have all the 
mechanisms necessary to deal properly with uninitialized variables.
Retrofitting mechanisms to something that just isn't expressive
enough to solve the problem I really don't think is the way to go.

EWD's book chapter... read it.  "An essay on the scope of variables"
I think it is called.


>
>
>There are several forms.
>In fact=2C sometimes the compiler says something "is" used uninitialized.
>Sometimes it says "maybe".
>
>
>In your example=2C generally=2C once the address is taken of a variable=2C
>the compiler gives up. Esp. if that address is passed to a function it does=
>n't "see".

As long as this doesn't raise warnings I can live with your warnings...

...
>
>
>There are many more warnings in the tree than I have yet looked at.
>I've seen a few forms.
>Some are because the compiler doesn't know that some functions don't return=
>.
>I'll see about improving that. Though I think there's a limit to how good I=
> can manage=2C
>unless we add a <* noreturn *> pragma.

adding <*ASSERT FALSE*> in the right places might fix these warnings.

...
>
>
>I grant that by initializing to 0=2C I haven't necessarily made the code co=
>rrect either.
>But at least it is now consistent.
>
>
>Even better would be runtime checks that stop if a variable is read before =
>written.

Which you have just defeated with your initialization!

I know that my Modula code will outlive its current compiler.  Probably
by a long time.  Once you add the initialization you're talking about,
you can't go back.  It no longer expresses the useful property you're
trying to check.  When the new compiler comes along with its runtime
check, it will miss that my variables are actually uninitialized.

>
>
>See also the rules in Java and C# that require the compiler to be able to p=
>rove
>a variable is written before read. Possibly even verifiable at load time.

I *hate* this.  See above.  

What's next?  The compiler refuses to compile loops that it can't
prove will terminate???  Hogwash!

>
>
>Other forms look related to going "through" a switch statement with no arms=
> handling the value.
>I think I can address that by marking fault_proc as noreturn.
>
>
>One form apparently in cm3ide would use uninitialized data if presented wit=
>h a malformed file.
>Good software doesn't depend on the well formedness of its input.
>
>There are many more warnings like this in the tree.
>
>
>My inclination is at least to temporarily hardcode the gcc backend to alway=
>s optimize=2C
>and always produce these warnings. People can look over them maybe and deci=
>de.
>Or they can look over my "fixes".
>
>
>Or I guess if people really really really really prefer=2C we can always tu=
>rn off the warnings
>and let the code lie. I really think that is the wrong answer.
>
>
>I have been burned too much by uninitialized locals in C.
>I put " =3D { 0 }" after everything.
>Again=2C that isn't necessarily "correct"=2C but at least the incorrect pat=
>hs are consistent.
>If they don't work and I happen down them=2C they will guaranteeably not wo=
>rk.

No they will just consistently not work.  Not "guaranteeably".  You have
to initialize them to some specific value for that to be the case.
Using "0" often will just give you the wrong answer!  

>
>
>Uninitialized values can be different run to run.
>Repeatability and consistency are important.

Not forcing the programmer to obscure the meaning of the code I think
is more important.

>
>
>I'm also nervous about us not taking a hard line on integer overflow.
>Overflown math doesn't necessarily lead to array out of bounds soon or ever=
>.
>It too can lead to incorrect but safe behavior.

Similar situation is it not?  You don't generate a compiler warning
for math that "might overflow".  

I think we can all agree that error on integer overflow, error on
use of uninitialized variable, at runtime, would both be good things?

     Mika

>
>
>=A0- Jay
>
>
>----------------------------------------
>> To: jay.krell at cornell.edu
>> Date: Tue=2C 1 Jun 2010 20:52:26 -0700
>> From: mika at async.async.caltech.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] [M3commit] CVS Update: cm3
>>
>>
>> Safety is important in that it allows you to limit the possible effects
>> of bugs. Getting programs bug-free is of course a very difficult problem
>> no matter what you do.
>>
>> But no I don't think warnings for uninitialized use of variables is
>> something one should do in general in Modula-3. The safety guarantees
>> lead to different idioms from in C---not so many compiler warnings
>> are required to get your code right. And if you do screw up
>> an uninitialized variable=2C the effect is going to be limited.
>> Unlike what happens in C=2C where if you screw up the initialization
>> of a pointer=2C for instance=2C all hell breaks loose.
>>
>> Your example is contrived. Usually the code looks like this
>>
>> VAR
>> x : T=3B
>> BEGIN
>> IF cond1 THEN x :=3D ... END=3B
>> ...
>> IF cond2 THEN (* use x *) END
>> END
>>
>> where the programmer knows that cond2 logically implies cond1.
>>
>> I think the presence of VAR parameter passing makes these sorts of
>> warnings also less useful in Modula-3. Is the following OK?
>>
>> PROCEDURE InitializeIt(VAR a : T)=3B
>> PROCEUDRE UseIt(VALUE a : T)=3B
>>
>> VAR x : T=3B
>> BEGIN
>> InitializeIt(x)=3B
>> UseIt(x)
>> END
>>
>> I would think your compiler can't prove that x is initialized. Warning
>> or not? I say no: this is actually very reasonable Modula-3 code.
>> But then do you want a warning for the IF? It's logically the same.
>>
>> There's a chapter in
>> EWD's Discipline of Programming that deals with the problem in
>> detail. I think he winds up with six different "modes" for variables.
>>
>> Mika
>>
>> Jay K writes:
>>>
>>>ok=3D2C so in C:
>>>=3D20
>>>int F()
>>>{
>>> int i=3D3B
>>> return i=3D3B
>>>}
>>>=3D20
>>>should warn or not?
>>>Prevailing wisdom is definitely.
>>>Main known exception is code to generate random numbers.
>>> I believe this is how Debian broke key generation.
>>>=3D20
>>>=3D20
>>>Modula-3:
>>>=3D20
>>>=3D20
>>>PROCEDURE F(): INTEGER =3D3D=3D20
>>> VAR i: INTEGER=3D3B
>>>BEGIN
>>> RETURN i=3D3B
>>>END F=3D3B
>>>=3D20
>>>=3D20
>>>Should warn or not?
>>>Since this identical to the C=3D2C prevailing wisdom is definitely.
>>>=3D20
>>>=3D20
>>>They are=3D2C I guess=3D2C "safe"=3D2C but most likely=3D2C incorrect.
>>>=3D20
>>>=3D20
>>>The compiler may have made "safety" guarantees=3D2C and they are signific=
>ant=3D
>>>=3D2C
>>>but safe is far from correct=3D2C and however smart the compiler can be t=
>o lo=3D
>>>ok for correctness issues=3D2C is also nice.
>>>=3D20
>>>=3D20
>>>=3D20
>>>(Friend of mine conjectured something like: Safety guarantees have people=
> d=3D
>>>eluded. Software will still have plenty of bugs and be plenty difficult t=
>o =3D
>>>get correct and require plenty of testing. Safety guarantees help=3D2C bu=
>t th=3D
>>>ey are only a small step toward actual correctness.)
>>>=3D20
>>>=3D20
>>>=3D20
>>> - Jay
>>>
>>>
>>>----------------------------------------
>>>> Subject: Re: [M3commit] CVS Update: cm3
>>>> From: hosking at cs.purdue.edu
>>>> Date: Tue=3D2C 1 Jun 2010 20:04:00 -0400
>>>> CC: jkrell at elego.de=3D3B m3commit at elegosoft.com
>>>> To: jay.krell at cornell.edu
>>>>
>>>> Sure=3D2C an INTEGER is a valid value whatever the bits.
>>>>
>>>>
>>>> On 1 Jun 2010=3D2C at 17:44=3D2C Jay K wrote:
>>>>
>>>>>
>>>>> Start removing the rampant use of volatile in the backend and these wa=
>rn=3D
>>>ings show up.
>>>>>
>>>>> Volatile quashes the uninitialized checks in the backend.
>>>>>
>>>>> Is it really ok for an INTEGER to be uninitialized? I realize it conta=
>in=3D
>>>s an "integer" value=3D2C as all bit patterns are.
>>>>>
>>>>> Some of these really do seem like bugs. Some do not.
>>>>> I'll try making fault_proc noreturn=3D2C which should remove some of t=
>hem.
>>>>>
>>>>>
>>>>> - Jay
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ----------------------------------------
>>>>>> From: hosking at cs.purdue.edu
>>>>>> To: jkrell at elego.de
>>>>>> Date: Tue=3D2C 1 Jun 2010 16:29:20 -0500
>>>>>> CC: m3commit at elegosoft.com
>>>>>> Subject: Re: [M3commit] CVS Update: cm3
>>>>>>
>>>>>> This is bogus. The M3 compiler guarantees all variables are initializ=
>ed=3D
>>>.
>>>>>>
>>>>>> Sent from my iPhone
>>>>>>
>>>>>> On Jun 1=3D2C 2010=3D2C at 2:42 PM=3D2C jkrell at elego.de (Jay Krell) w=
>rote:
>>>>>>
>>>>>>> CVSROOT: /usr/cvs
>>>>>>> Changes by: jkrell at birch. 10/06/01 14:42:00
>>>>>>>
>>>>>>> Modified files:
>>>>>>> cm3/m3-libs/m3core/src/convert/: Convert.m3
>>>>>>>
>>>>>>> Log message:
>>>>>>> initialize locals=3D3B I get warnings that some not quite all=3D2C a=
>re
>>>>>>> used uninitialized if I remove the volatile/sideeffects on every
>>>>>>> load/store in parse.c
>>>> =3D
> 		 	   		  =



From jay.krell at cornell.edu  Wed Jun  2 15:01:38 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 2 Jun 2010 13:01:38 +0000
Subject: [M3devel] SOLgnu/SOLsun -O1/-O2/-O3
Message-ID: <COL101-W26B2AF5D865D1A694793DAE6D00@phx.gbl>


Anyone recall if SOLgnu/sun work with any optimization?
? You know -- the platforms that have a stack walker and don't use setjmp.
I tried leaving them having all loads/stores be volatile, except handling still doesn't work -- cm3 gets an unhandled exception instead of saying cm3.cfg not found.
I'll have to test with an old clean version.
Could be I'm missing something, or maybe the m3cg_pop change broke them.


?- Jay

 		 	   		  

From jay.krell at cornell.edu  Wed Jun  2 14:59:45 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 2 Jun 2010 12:59:45 +0000
Subject: [M3devel] warning for uninitialized variables?
In-Reply-To: <20100602124422.11C6D1A209A@async.async.caltech.edu>
References: <20100601124200.8E42B2474003@birch.elegosoft.com>, ,
	<E86D485E-C5D5-4B7A-8142-5E0BE31280DD@cs.purdue.edu>,
	<COL101-W58EC381F7DE75AC44CFB57E6EF0@phx.gbl>, ,
	<5458A114-F000-4A90-9998-FD7DF63E06C0@cs.purdue.edu>,
	<COL101-W3678C92B3A9FA07AD57BF2E6D00@phx.gbl>,
	<20100602035226.43C1F1A208F@async.async.caltech.edu>
	<COL101-W59770EAA64E52A966D79F3E6D00@phx.gbl>,
	<20100602124422.11C6D1A209A@async.async.caltech.edu>
Message-ID: <COL101-W5343011FD0FA7BCC8C42AEE6D00@phx.gbl>


I grant that an immediate runtime error upon reading an unwritten value is ideal.
But absent that possibility, I want something consistent.
Heck, here's a crazy idea: reserve the current FIRST(INTEGER) as "invalid", initialize locals to it, any read (or generation/write) of that value trigger a runtime error.
CARDINAL could work this way more easily since it has many values to spare.


?- Jay

----------------------------------------
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] warning for uninitialized variables?
> Date: Wed, 2 Jun 2010 05:44:22 -0700
> From: mika at async.async.caltech.edu
>
> Jay K writes:
>>
>>Wow. You really surprise me Mika.
>>
>>
>>To warn on this kind of thing=2C to me=2C there is no question.
>>
>>
>>Limting the affects by virtue of being safe isn't much consolation.
>>The program can easily go down a "safe" but very incorrect path.
>
> It is, though! Do you always know what value to initialize the
> variables to? If not, you're just picking some value to shut up
> the compiler, and now your code no longer expresses---to a human
> reader---that x is uninitialized.
>
> Remember, code is mainly written for humans! Computers don't care
> about fancy structuring, declarations, etc. When you write a program,
> you write it to be read by a human. The fact that a variable is
> uninitialized is a part of the design of the program.
>
> It's an unfortunate fact that our languages don't have all the
> mechanisms necessary to deal properly with uninitialized variables.
> Retrofitting mechanisms to something that just isn't expressive
> enough to solve the problem I really don't think is the way to go.
>
> EWD's book chapter... read it. "An essay on the scope of variables"
> I think it is called.
>
>
>>
>>
>>There are several forms.
>>In fact=2C sometimes the compiler says something "is" used uninitialized.
>>Sometimes it says "maybe".
>>
>>
>>In your example=2C generally=2C once the address is taken of a variable=2C
>>the compiler gives up. Esp. if that address is passed to a function it does=
>>n't "see".
>
> As long as this doesn't raise warnings I can live with your warnings...
>
> ...
>>
>>
>>There are many more warnings in the tree than I have yet looked at.
>>I've seen a few forms.
>>Some are because the compiler doesn't know that some functions don't return=
>>.
>>I'll see about improving that. Though I think there's a limit to how good I=
>> can manage=2C
>>unless we add a <* noreturn *> pragma.
>
> adding <*ASSERT FALSE*> in the right places might fix these warnings.
>
> ...
>>
>>
>>I grant that by initializing to 0=2C I haven't necessarily made the code co=
>>rrect either.
>>But at least it is now consistent.
>>
>>
>>Even better would be runtime checks that stop if a variable is read before =
>>written.
>
> Which you have just defeated with your initialization!
>
> I know that my Modula code will outlive its current compiler. Probably
> by a long time. Once you add the initialization you're talking about,
> you can't go back. It no longer expresses the useful property you're
> trying to check. When the new compiler comes along with its runtime
> check, it will miss that my variables are actually uninitialized.
>
>>
>>
>>See also the rules in Java and C# that require the compiler to be able to p=
>>rove
>>a variable is written before read. Possibly even verifiable at load time.
>
> I *hate* this. See above.
>
> What's next? The compiler refuses to compile loops that it can't
> prove will terminate??? Hogwash!
>
>>
>>
>>Other forms look related to going "through" a switch statement with no arms=
>> handling the value.
>>I think I can address that by marking fault_proc as noreturn.
>>
>>
>>One form apparently in cm3ide would use uninitialized data if presented wit=
>>h a malformed file.
>>Good software doesn't depend on the well formedness of its input.
>>
>>There are many more warnings like this in the tree.
>>
>>
>>My inclination is at least to temporarily hardcode the gcc backend to alway=
>>s optimize=2C
>>and always produce these warnings. People can look over them maybe and deci=
>>de.
>>Or they can look over my "fixes".
>>
>>
>>Or I guess if people really really really really prefer=2C we can always tu=
>>rn off the warnings
>>and let the code lie. I really think that is the wrong answer.
>>
>>
>>I have been burned too much by uninitialized locals in C.
>>I put " =3D { 0 }" after everything.
>>Again=2C that isn't necessarily "correct"=2C but at least the incorrect pat=
>>hs are consistent.
>>If they don't work and I happen down them=2C they will guaranteeably not wo=
>>rk.
>
> No they will just consistently not work. Not "guaranteeably". You have
> to initialize them to some specific value for that to be the case.
> Using "0" often will just give you the wrong answer!
>
>>
>>
>>Uninitialized values can be different run to run.
>>Repeatability and consistency are important.
>
> Not forcing the programmer to obscure the meaning of the code I think
> is more important.
>
>>
>>
>>I'm also nervous about us not taking a hard line on integer overflow.
>>Overflown math doesn't necessarily lead to array out of bounds soon or ever=
>>.
>>It too can lead to incorrect but safe behavior.
>
> Similar situation is it not? You don't generate a compiler warning
> for math that "might overflow".
>
> I think we can all agree that error on integer overflow, error on
> use of uninitialized variable, at runtime, would both be good things?
>
> Mika
>
>>
>>
>>=A0- Jay
>>
>>
>>----------------------------------------
>>> To: jay.krell at cornell.edu
>>> Date: Tue=2C 1 Jun 2010 20:52:26 -0700
>>> From: mika at async.async.caltech.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] [M3commit] CVS Update: cm3
>>>
>>>
>>> Safety is important in that it allows you to limit the possible effects
>>> of bugs. Getting programs bug-free is of course a very difficult problem
>>> no matter what you do.
>>>
>>> But no I don't think warnings for uninitialized use of variables is
>>> something one should do in general in Modula-3. The safety guarantees
>>> lead to different idioms from in C---not so many compiler warnings
>>> are required to get your code right. And if you do screw up
>>> an uninitialized variable=2C the effect is going to be limited.
>>> Unlike what happens in C=2C where if you screw up the initialization
>>> of a pointer=2C for instance=2C all hell breaks loose.
>>>
>>> Your example is contrived. Usually the code looks like this
>>>
>>> VAR
>>> x : T=3B
>>> BEGIN
>>> IF cond1 THEN x :=3D ... END=3B
>>> ...
>>> IF cond2 THEN (* use x *) END
>>> END
>>>
>>> where the programmer knows that cond2 logically implies cond1.
>>>
>>> I think the presence of VAR parameter passing makes these sorts of
>>> warnings also less useful in Modula-3. Is the following OK?
>>>
>>> PROCEDURE InitializeIt(VAR a : T)=3B
>>> PROCEUDRE UseIt(VALUE a : T)=3B
>>>
>>> VAR x : T=3B
>>> BEGIN
>>> InitializeIt(x)=3B
>>> UseIt(x)
>>> END
>>>
>>> I would think your compiler can't prove that x is initialized. Warning
>>> or not? I say no: this is actually very reasonable Modula-3 code.
>>> But then do you want a warning for the IF? It's logically the same.
>>>
>>> There's a chapter in
>>> EWD's Discipline of Programming that deals with the problem in
>>> detail. I think he winds up with six different "modes" for variables.
>>>
>>> Mika
>>>
>>> Jay K writes:
>>>>
>>>>ok=3D2C so in C:
>>>>=3D20
>>>>int F()
>>>>{
>>>> int i=3D3B
>>>> return i=3D3B
>>>>}
>>>>=3D20
>>>>should warn or not?
>>>>Prevailing wisdom is definitely.
>>>>Main known exception is code to generate random numbers.
>>>> I believe this is how Debian broke key generation.
>>>>=3D20
>>>>=3D20
>>>>Modula-3:
>>>>=3D20
>>>>=3D20
>>>>PROCEDURE F(): INTEGER =3D3D=3D20
>>>> VAR i: INTEGER=3D3B
>>>>BEGIN
>>>> RETURN i=3D3B
>>>>END F=3D3B
>>>>=3D20
>>>>=3D20
>>>>Should warn or not?
>>>>Since this identical to the C=3D2C prevailing wisdom is definitely.
>>>>=3D20
>>>>=3D20
>>>>They are=3D2C I guess=3D2C "safe"=3D2C but most likely=3D2C incorrect.
>>>>=3D20
>>>>=3D20
>>>>The compiler may have made "safety" guarantees=3D2C and they are signific=
>>ant=3D
>>>>=3D2C
>>>>but safe is far from correct=3D2C and however smart the compiler can be t=
>>o lo=3D
>>>>ok for correctness issues=3D2C is also nice.
>>>>=3D20
>>>>=3D20
>>>>=3D20
>>>>(Friend of mine conjectured something like: Safety guarantees have people=
>> d=3D
>>>>eluded. Software will still have plenty of bugs and be plenty difficult t=
>>o =3D
>>>>get correct and require plenty of testing. Safety guarantees help=3D2C bu=
>>t th=3D
>>>>ey are only a small step toward actual correctness.)
>>>>=3D20
>>>>=3D20
>>>>=3D20
>>>> - Jay
>>>>
>>>>
>>>>----------------------------------------
>>>>> Subject: Re: [M3commit] CVS Update: cm3
>>>>> From: hosking at cs.purdue.edu
>>>>> Date: Tue=3D2C 1 Jun 2010 20:04:00 -0400
>>>>> CC: jkrell at elego.de=3D3B m3commit at elegosoft.com
>>>>> To: jay.krell at cornell.edu
>>>>>
>>>>> Sure=3D2C an INTEGER is a valid value whatever the bits.
>>>>>
>>>>>
>>>>> On 1 Jun 2010=3D2C at 17:44=3D2C Jay K wrote:
>>>>>
>>>>>>
>>>>>> Start removing the rampant use of volatile in the backend and these wa=
>>rn=3D
>>>>ings show up.
>>>>>>
>>>>>> Volatile quashes the uninitialized checks in the backend.
>>>>>>
>>>>>> Is it really ok for an INTEGER to be uninitialized? I realize it conta=
>>in=3D
>>>>s an "integer" value=3D2C as all bit patterns are.
>>>>>>
>>>>>> Some of these really do seem like bugs. Some do not.
>>>>>> I'll try making fault_proc noreturn=3D2C which should remove some of t=
>>hem.
>>>>>>
>>>>>>
>>>>>> - Jay
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ----------------------------------------
>>>>>>> From: hosking at cs.purdue.edu
>>>>>>> To: jkrell at elego.de
>>>>>>> Date: Tue=3D2C 1 Jun 2010 16:29:20 -0500
>>>>>>> CC: m3commit at elegosoft.com
>>>>>>> Subject: Re: [M3commit] CVS Update: cm3
>>>>>>>
>>>>>>> This is bogus. The M3 compiler guarantees all variables are initializ=
>>ed=3D
>>>>.
>>>>>>>
>>>>>>> Sent from my iPhone
>>>>>>>
>>>>>>> On Jun 1=3D2C 2010=3D2C at 2:42 PM=3D2C jkrell at elego.de (Jay Krell) w=
>>rote:
>>>>>>>
>>>>>>>> CVSROOT: /usr/cvs
>>>>>>>> Changes by: jkrell at birch. 10/06/01 14:42:00
>>>>>>>>
>>>>>>>> Modified files:
>>>>>>>> cm3/m3-libs/m3core/src/convert/: Convert.m3
>>>>>>>>
>>>>>>>> Log message:
>>>>>>>> initialize locals=3D3B I get warnings that some not quite all=3D2C a=
>>re
>>>>>>>> used uninitialized if I remove the volatile/sideeffects on every
>>>>>>>> load/store in parse.c
>>>>> =3D
>> =
>
 		 	   		  

From hosking at cs.purdue.edu  Wed Jun  2 16:01:09 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 2 Jun 2010 10:01:09 -0400
Subject: [M3devel] ADR is *too* unsafe..
In-Reply-To: <COL101-W617B9602E6CAA0BBE5BE25E6D00@phx.gbl>
References: <COL101-W617B9602E6CAA0BBE5BE25E6D00@phx.gbl>
Message-ID: <A8CEEB02-D279-4C90-B8D3-5D163619C748@cs.purdue.edu>

Why does the compiler break?
Yes, VAR is *much* safer.

On 2 Jun 2010, at 03:41, Jay K wrote:

> 
> (*
> Wow, ADR generates a plain ADDRESS, not an untraced ref to a specific type?
> Doesn't this seem wrong? Doesn't unsafe code deserve a little better, say,
>   to be at least as typesafe as C?
> http://www.cs.purdue.edu/homes/hosking/m3/reference/unsafe.html
> 
> This is why 64bit m3-comm/tcp/src/TCP.m3 breaks randomly
> on some platforms on an assertion failure in C. And the
> compiler isn't going to help me find these type mismatches? Ugh.
> 
> This seems wrong. :(
> 
> I guess I should really really use VAR then.
> *)
> 
> 
> UNSAFE MODULE Main;
> IMPORT Ctypes, Cstddef;
> 
> 
> PROCEDURE F1(a:UNTRACED REF Ctypes.int) =
> BEGIN
>   F2(a); (* error, expected *)
> END F1;
> 
> 
> PROCEDURE F2(a:UNTRACED REF Cstddef.size_t) =
> BEGIN
>   F1(a); (* error, expected *)
> END F2;
> 
> 
> VAR c:Ctypes.int;
>     d:Cstddef.size_t;
> 
>     
> BEGIN
>   F1(ADR(c)); (* ok *)
>   F1(ADR(d)); (* error expected but no *)
>   F2(ADR(c)); (* error expected but no *)
>   F2(ADR(d)); (* ok *)
> END Main.
> 
> 
> 
>  - Jay
> 		 	   		  



From jay.krell at cornell.edu  Wed Jun  2 16:07:02 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 2 Jun 2010 14:07:02 +0000
Subject: [M3devel] ADR is *too* unsafe..
In-Reply-To: <A8CEEB02-D279-4C90-B8D3-5D163619C748@cs.purdue.edu>
References: <COL101-W617B9602E6CAA0BBE5BE25E6D00@phx.gbl>,
	<A8CEEB02-D279-4C90-B8D3-5D163619C748@cs.purdue.edu>
Message-ID: <COL101-W444318DF7FE046C2AE542AE6D00@phx.gbl>


The compiler doesn't break. Mentor does, networking stuff. I fixed it. But I would have
expected the compiler to have told me about it.
It is unfortunate. ADR should be *slightly* safer.
Maybe we can get a warning for this? passing ADR(foo) to untraced ref bar?
It seems...quite unfortunate that the language is defined this way..

?- Jay


----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Wed, 2 Jun 2010 10:01:09 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] ADR is *too* unsafe..
>
> Why does the compiler break?
> Yes, VAR is *much* safer.
>
> On 2 Jun 2010, at 03:41, Jay K wrote:
>
>>
>> (*
>> Wow, ADR generates a plain ADDRESS, not an untraced ref to a specific type?
>> Doesn't this seem wrong? Doesn't unsafe code deserve a little better, say,
>> to be at least as typesafe as C?
>> http://www.cs.purdue.edu/homes/hosking/m3/reference/unsafe.html
>>
>> This is why 64bit m3-comm/tcp/src/TCP.m3 breaks randomly
>> on some platforms on an assertion failure in C. And the
>> compiler isn't going to help me find these type mismatches? Ugh.
>>
>> This seems wrong. :(
>>
>> I guess I should really really use VAR then.
>> *)
>>
>>
>> UNSAFE MODULE Main;
>> IMPORT Ctypes, Cstddef;
>>
>>
>> PROCEDURE F1(a:UNTRACED REF Ctypes.int) =
>> BEGIN
>> F2(a); (* error, expected *)
>> END F1;
>>
>>
>> PROCEDURE F2(a:UNTRACED REF Cstddef.size_t) =
>> BEGIN
>> F1(a); (* error, expected *)
>> END F2;
>>
>>
>> VAR c:Ctypes.int;
>> d:Cstddef.size_t;
>>
>>
>> BEGIN
>> F1(ADR(c)); (* ok *)
>> F1(ADR(d)); (* error expected but no *)
>> F2(ADR(c)); (* error expected but no *)
>> F2(ADR(d)); (* ok *)
>> END Main.
>>
>>
>>
>> - Jay
>>
>
 		 	   		  

From jay.krell at cornell.edu  Wed Jun  2 16:07:35 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 2 Jun 2010 14:07:35 +0000
Subject: [M3devel] SOLgnu/SOLsun -O1/-O2/-O3
Message-ID: <COL101-W16BB57F49DB4CD5964A0A1E6D00@phx.gbl>


It looks like -O2 does work.
I need to keep digging.

?- Jay


----------------------------------------
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu; m3devel at elegosoft.com
> Subject: SOLgnu/SOLsun -O1/-O2/-O3
> Date: Wed, 2 Jun 2010 13:01:38 +0000
>
>
> Anyone recall if SOLgnu/sun work with any optimization?
>   You know -- the platforms that have a stack walker and don't use setjmp.
> I tried leaving them having all loads/stores be volatile, except handling still doesn't work -- cm3 gets an unhandled exception instead of saying cm3.cfg not found.
> I'll have to test with an old clean version.
> Could be I'm missing something, or maybe the m3cg_pop change broke them.
>
>
>  - Jay
>
>
 		 	   		  

From jay.krell at cornell.edu  Wed Jun  2 16:30:05 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 2 Jun 2010 14:30:05 +0000
Subject: [M3devel] reducing use of volatile in backend?
In-Reply-To: <AA1F4490-A9C7-4F94-8E03-65A5E9031424@cs.purdue.edu>
References: <COL101-W17AA739AA2DE2050C6CCD0E6EF0@phx.gbl>,
	<AA1F4490-A9C7-4F94-8E03-65A5E9031424@cs.purdue.edu>
Message-ID: <COL101-W35361E5B4C86598DB49C90E6D00@phx.gbl>


attached is the diff I'm working on.


It works well on a few platforms.
I've been using it on AMD64_DARWIN.
Cross I386_LINUX, PPC_DARWIN cm3 startup and give
? the correct message, which requires exception handling to work.


SOLgnu exception handling doesn't work.
MIPS64_OPENBSD internal errors a bunch in the compiler.
? Probably don't care. Don't know if it was working before.


Still to do:
? figure out what is up with SOLgnu/SOLsun


Not ideal but I think ok for now:
? volatizing all floating point
??? We already were, though granted possibly with more optimizations.
? flag_unit_at_a_time = 0

? 
flag_unit_at_a_time isn't "tricky" or subtle,
but it does remove a function we want to take the address of.
I couldn't find a way to get it to keep the function.


What I think is fine for a while:
? flag_tree_vrp = 0;
? flag_tree_pre = 0;
? flag_tree_fre = 0;

? 
Maybe it doesn't take much to let them work?
Maybe wait until 4.5 is working and try again there?
? In particular pre/fre only fail in one file among m3core/libm3, Formater.m3.
? vrp is what silently produces non-working code.
? It is either the only one, or one of pre/fre also do.
? At least one of pre/fre crash, accessing null pointer.

?
and probably also ok for a "while":
?flag_tree_loop_im = 0
?flag_schedule_insns = 0

?
though for flag_schedule_insns = 0 to fail seems odd,
and flag_tree_loop_im only broke in a little code, should
probably look at that code.


Oh and I still need to see about fours/badbricks recieving mouse clicks.
Mine aren't.


The TREE_ADDRESSABLE change in m3_write_globals was needed to get SOLgnu
to compiler. The assert failed.


We might want to have the frontend tell the backend if the
target has a stack walker, instead of the logic I have here.


While it is not ideal, I think this will let -O1/2/3 generate code much more like people expect, without
constantly reloading registers from the stack.


?- Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com
> Subject: RE: [M3devel] reducing use of volatile in backend?
> Date: Tue, 1 Jun 2010 21:55:31 +0000
>
>
> I've had *a lot* of success here the past few hours.
>
>
> There is an assert starting up mentor I need to look at, possibly out of data binaries.
> The one in socket.c assert(lossless_socklen || socklen == null || socklen < 1<<30.
>
>
> Compiler seems to work.
> Lots of things do break it, so that is something.
>
>
> Various gui apps startup.
> Some of the gui apps don't work, but nor did older copies I had -- fours, badbricks, and I think columns, wouldn't take any mouse clicks. I have to test older versions. Could be unrelated.
>
>
>
> Here is what I have:
>
> The vast vast majority of optimizations can be enabled.
>
> Nearly all uses of volatile can be removed.
>
> Just a few optimizations "need" to be disabled.
>
> In particular:
> I only have volatile remaining:
> on store after insert_mn (special case)
>
> floating point (huh? wierd)
> compile errors without this
>
> in functions that call setjmp or vfork
> This is very reasonable, but we should try to limit it to not all the variables, only what are accessed after the second return (I'm not sure how that computes for vfork, but for setjmp it makes sense to me.
>
>
> on the load/store in loophole
> compile errors without this; perhaps redundant with the floating point check
>
>
> on load link, else it gets uninitialized warning
>
>
>
> Also I found a likely bug.
> In functions that call setjmp/vfork, we volatize already seen parameters and locals, but we don't volatize not yet seen locals (in nested blocks) and temporaries. I fixed that.
>
>
>
>
> The optimizations I disabled, from memory:
>
>
> pre - partial redundancy elimination
>
>
> fre - full redundancy elimination (these are related)
> One or both of these causes the compiler to access violate in the optimizer, compiling libm3/Formatter.mc, but otherwise I think they compile m3core and libm3 entirely
>
>
> loop im (induction motion) - caused a compile error in Trestle
>
> vrp - value range propagation
> This seems to be the biggest problem, no compile errors but "random" runtime malfunction, usually starting up cm3.
>
>
> insn_sched - wierd, caused a compile break
> but insn_sched_after_reload ok
>
>
> That's about it. All the ones with "alias" in them, only like two, I enabled, seemed ok.
> salias and strict_alias. I left strict alias till late in experimentation but really it seems ok.
>
>
> I can compile the entire system, though I get lots of warnings about uninitialized variables.
> I pass the backend the -Wuninitialized flag.
>
>
> I test it out more -- the gui non-interaction, the mentor assert, and test other platforms.
> But I think we'll have volatile mostly gone and just a small number of optimizations turned off fairly soon.
> We can iterate more on the remaining optimizations.
>
>
> Getting good typeinfo would be good so that gdb can debug.
> And maybe so that other than stabs works.
>
>
> - Jay
>
>
>
>
> ----------------------------------------
>> From: hosking at cs.purdue.edu
>> To: jay.krell at cornell.edu
>> Date: Tue, 1 Jun 2010 16:05:30 -0500
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] reducing use of volatile in backend?
>>
>> We don't want to disable optimisations for types where it makes sense
>> to have them. Better to smarten up typebased alias analysis instead so
>> we can get rid of volatile properly.
>>
>> Sent from my iPhone
>>
>> On Jun 1, 2010, at 12:16 PM, Jay K wrote:
>>
>>>
>>> Tony, would we maybe be better off not using volatile everywhere but
>>> selectively turning off optimizations in m3_post_options?
>>> You know, using volatile probably disables more than necessary?
>>> I'm experimenting with this.
>>>
>>> - Jay
>>>
>>>
>>>
>>>
>>>
 		 	   		  
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: less-volatile.txt
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100602/59c4b762/attachment.txt>

From hosking at cs.purdue.edu  Wed Jun  2 16:41:47 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 2 Jun 2010 10:41:47 -0400
Subject: [M3devel] warning for uninitialized variables?
In-Reply-To: <20100602124422.11C6D1A209A@async.async.caltech.edu>
References: <20100601124200.8E42B2474003@birch.elegosoft.com>, ,
	<E86D485E-C5D5-4B7A-8142-5E0BE31280DD@cs.purdue.edu>,
	<COL101-W58EC381F7DE75AC44CFB57E6EF0@phx.gbl>, ,
	<5458A114-F000-4A90-9998-FD7DF63E06C0@cs.purdue.edu>,
	<COL101-W3678C92B3A9FA07AD57BF2E6D00@phx.gbl>,
	<20100602035226.43C1F1A208F@async.async.caltech.edu>
	<COL101-W59770EAA64E52A966D79F3E6D00@phx.gbl>
	<20100602124422.11C6D1A209A@async.async.caltech.edu>
Message-ID: <16413179-F84C-42BF-AB09-2D8294EB4782@cs.purdue.edu>

Hear, hear!

On 2 Jun 2010, at 08:44, Mika Nystrom wrote:

> Jay K writes:
>> 
>> Wow. You really surprise me Mika.
>> 
>> 
>> To warn on this kind of thing=2C to me=2C there is no question.
>> 
>> 
>> Limting the affects by virtue of being safe isn't much consolation.
>> The program can easily go down a "safe" but very incorrect path.
> 
> It is, though!  Do you always know what value to initialize the
> variables to?  If not, you're just picking some value to shut up
> the compiler, and now your code no longer expresses---to a human
> reader---that x is uninitialized.
> 
> Remember, code is mainly written for humans!  Computers don't care
> about fancy structuring, declarations, etc.  When you write a program,
> you write it to be read by a human.  The fact that a variable is
> uninitialized is a part of the design of the program.
> 
> It's an unfortunate fact that our languages don't have all the 
> mechanisms necessary to deal properly with uninitialized variables.
> Retrofitting mechanisms to something that just isn't expressive
> enough to solve the problem I really don't think is the way to go.
> 
> EWD's book chapter... read it.  "An essay on the scope of variables"
> I think it is called.
> 
> 
>> 
>> 
>> There are several forms.
>> In fact=2C sometimes the compiler says something "is" used uninitialized.
>> Sometimes it says "maybe".
>> 
>> 
>> In your example=2C generally=2C once the address is taken of a variable=2C
>> the compiler gives up. Esp. if that address is passed to a function it does=
>> n't "see".
> 
> As long as this doesn't raise warnings I can live with your warnings...
> 
> ...
>> 
>> 
>> There are many more warnings in the tree than I have yet looked at.
>> I've seen a few forms.
>> Some are because the compiler doesn't know that some functions don't return=
>> .
>> I'll see about improving that. Though I think there's a limit to how good I=
>> can manage=2C
>> unless we add a <* noreturn *> pragma.
> 
> adding <*ASSERT FALSE*> in the right places might fix these warnings.
> 
> ...
>> 
>> 
>> I grant that by initializing to 0=2C I haven't necessarily made the code co=
>> rrect either.
>> But at least it is now consistent.
>> 
>> 
>> Even better would be runtime checks that stop if a variable is read before =
>> written.
> 
> Which you have just defeated with your initialization!
> 
> I know that my Modula code will outlive its current compiler.  Probably
> by a long time.  Once you add the initialization you're talking about,
> you can't go back.  It no longer expresses the useful property you're
> trying to check.  When the new compiler comes along with its runtime
> check, it will miss that my variables are actually uninitialized.
> 
>> 
>> 
>> See also the rules in Java and C# that require the compiler to be able to p=
>> rove
>> a variable is written before read. Possibly even verifiable at load time.
> 
> I *hate* this.  See above.  
> 
> What's next?  The compiler refuses to compile loops that it can't
> prove will terminate???  Hogwash!
> 
>> 
>> 
>> Other forms look related to going "through" a switch statement with no arms=
>> handling the value.
>> I think I can address that by marking fault_proc as noreturn.
>> 
>> 
>> One form apparently in cm3ide would use uninitialized data if presented wit=
>> h a malformed file.
>> Good software doesn't depend on the well formedness of its input.
>> 
>> There are many more warnings like this in the tree.
>> 
>> 
>> My inclination is at least to temporarily hardcode the gcc backend to alway=
>> s optimize=2C
>> and always produce these warnings. People can look over them maybe and deci=
>> de.
>> Or they can look over my "fixes".
>> 
>> 
>> Or I guess if people really really really really prefer=2C we can always tu=
>> rn off the warnings
>> and let the code lie. I really think that is the wrong answer.
>> 
>> 
>> I have been burned too much by uninitialized locals in C.
>> I put " =3D { 0 }" after everything.
>> Again=2C that isn't necessarily "correct"=2C but at least the incorrect pat=
>> hs are consistent.
>> If they don't work and I happen down them=2C they will guaranteeably not wo=
>> rk.
> 
> No they will just consistently not work.  Not "guaranteeably".  You have
> to initialize them to some specific value for that to be the case.
> Using "0" often will just give you the wrong answer!  
> 
>> 
>> 
>> Uninitialized values can be different run to run.
>> Repeatability and consistency are important.
> 
> Not forcing the programmer to obscure the meaning of the code I think
> is more important.
> 
>> 
>> 
>> I'm also nervous about us not taking a hard line on integer overflow.
>> Overflown math doesn't necessarily lead to array out of bounds soon or ever=
>> .
>> It too can lead to incorrect but safe behavior.
> 
> Similar situation is it not?  You don't generate a compiler warning
> for math that "might overflow".  
> 
> I think we can all agree that error on integer overflow, error on
> use of uninitialized variable, at runtime, would both be good things?
> 
>     Mika
> 
>> 
>> 
>> =A0- Jay
>> 
>> 
>> ----------------------------------------
>>> To: jay.krell at cornell.edu
>>> Date: Tue=2C 1 Jun 2010 20:52:26 -0700
>>> From: mika at async.async.caltech.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] [M3commit] CVS Update: cm3
>>> 
>>> 
>>> Safety is important in that it allows you to limit the possible effects
>>> of bugs. Getting programs bug-free is of course a very difficult problem
>>> no matter what you do.
>>> 
>>> But no I don't think warnings for uninitialized use of variables is
>>> something one should do in general in Modula-3. The safety guarantees
>>> lead to different idioms from in C---not so many compiler warnings
>>> are required to get your code right. And if you do screw up
>>> an uninitialized variable=2C the effect is going to be limited.
>>> Unlike what happens in C=2C where if you screw up the initialization
>>> of a pointer=2C for instance=2C all hell breaks loose.
>>> 
>>> Your example is contrived. Usually the code looks like this
>>> 
>>> VAR
>>> x : T=3B
>>> BEGIN
>>> IF cond1 THEN x :=3D ... END=3B
>>> ...
>>> IF cond2 THEN (* use x *) END
>>> END
>>> 
>>> where the programmer knows that cond2 logically implies cond1.
>>> 
>>> I think the presence of VAR parameter passing makes these sorts of
>>> warnings also less useful in Modula-3. Is the following OK?
>>> 
>>> PROCEDURE InitializeIt(VAR a : T)=3B
>>> PROCEUDRE UseIt(VALUE a : T)=3B
>>> 
>>> VAR x : T=3B
>>> BEGIN
>>> InitializeIt(x)=3B
>>> UseIt(x)
>>> END
>>> 
>>> I would think your compiler can't prove that x is initialized. Warning
>>> or not? I say no: this is actually very reasonable Modula-3 code.
>>> But then do you want a warning for the IF? It's logically the same.
>>> 
>>> There's a chapter in
>>> EWD's Discipline of Programming that deals with the problem in
>>> detail. I think he winds up with six different "modes" for variables.
>>> 
>>> Mika
>>> 
>>> Jay K writes:
>>>> 
>>>> ok=3D2C so in C:
>>>> =3D20
>>>> int F()
>>>> {
>>>> int i=3D3B
>>>> return i=3D3B
>>>> }
>>>> =3D20
>>>> should warn or not?
>>>> Prevailing wisdom is definitely.
>>>> Main known exception is code to generate random numbers.
>>>> I believe this is how Debian broke key generation.
>>>> =3D20
>>>> =3D20
>>>> Modula-3:
>>>> =3D20
>>>> =3D20
>>>> PROCEDURE F(): INTEGER =3D3D=3D20
>>>> VAR i: INTEGER=3D3B
>>>> BEGIN
>>>> RETURN i=3D3B
>>>> END F=3D3B
>>>> =3D20
>>>> =3D20
>>>> Should warn or not?
>>>> Since this identical to the C=3D2C prevailing wisdom is definitely.
>>>> =3D20
>>>> =3D20
>>>> They are=3D2C I guess=3D2C "safe"=3D2C but most likely=3D2C incorrect.
>>>> =3D20
>>>> =3D20
>>>> The compiler may have made "safety" guarantees=3D2C and they are signific=
>> ant=3D
>>>> =3D2C
>>>> but safe is far from correct=3D2C and however smart the compiler can be t=
>> o lo=3D
>>>> ok for correctness issues=3D2C is also nice.
>>>> =3D20
>>>> =3D20
>>>> =3D20
>>>> (Friend of mine conjectured something like: Safety guarantees have people=
>> d=3D
>>>> eluded. Software will still have plenty of bugs and be plenty difficult t=
>> o =3D
>>>> get correct and require plenty of testing. Safety guarantees help=3D2C bu=
>> t th=3D
>>>> ey are only a small step toward actual correctness.)
>>>> =3D20
>>>> =3D20
>>>> =3D20
>>>> - Jay
>>>> 
>>>> 
>>>> ----------------------------------------
>>>>> Subject: Re: [M3commit] CVS Update: cm3
>>>>> From: hosking at cs.purdue.edu
>>>>> Date: Tue=3D2C 1 Jun 2010 20:04:00 -0400
>>>>> CC: jkrell at elego.de=3D3B m3commit at elegosoft.com
>>>>> To: jay.krell at cornell.edu
>>>>> 
>>>>> Sure=3D2C an INTEGER is a valid value whatever the bits.
>>>>> 
>>>>> 
>>>>> On 1 Jun 2010=3D2C at 17:44=3D2C Jay K wrote:
>>>>> 
>>>>>> 
>>>>>> Start removing the rampant use of volatile in the backend and these wa=
>> rn=3D
>>>> ings show up.
>>>>>> 
>>>>>> Volatile quashes the uninitialized checks in the backend.
>>>>>> 
>>>>>> Is it really ok for an INTEGER to be uninitialized? I realize it conta=
>> in=3D
>>>> s an "integer" value=3D2C as all bit patterns are.
>>>>>> 
>>>>>> Some of these really do seem like bugs. Some do not.
>>>>>> I'll try making fault_proc noreturn=3D2C which should remove some of t=
>> hem.
>>>>>> 
>>>>>> 
>>>>>> - Jay
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> ----------------------------------------
>>>>>>> From: hosking at cs.purdue.edu
>>>>>>> To: jkrell at elego.de
>>>>>>> Date: Tue=3D2C 1 Jun 2010 16:29:20 -0500
>>>>>>> CC: m3commit at elegosoft.com
>>>>>>> Subject: Re: [M3commit] CVS Update: cm3
>>>>>>> 
>>>>>>> This is bogus. The M3 compiler guarantees all variables are initializ=
>> ed=3D
>>>> .
>>>>>>> 
>>>>>>> Sent from my iPhone
>>>>>>> 
>>>>>>> On Jun 1=3D2C 2010=3D2C at 2:42 PM=3D2C jkrell at elego.de (Jay Krell) w=
>> rote:
>>>>>>> 
>>>>>>>> CVSROOT: /usr/cvs
>>>>>>>> Changes by: jkrell at birch. 10/06/01 14:42:00
>>>>>>>> 
>>>>>>>> Modified files:
>>>>>>>> cm3/m3-libs/m3core/src/convert/: Convert.m3
>>>>>>>> 
>>>>>>>> Log message:
>>>>>>>> initialize locals=3D3B I get warnings that some not quite all=3D2C a=
>> re
>>>>>>>> used uninitialized if I remove the volatile/sideeffects on every
>>>>>>>> load/store in parse.c
>>>>> =3D
>> 		 	   		  =



From jay.krell at cornell.edu  Wed Jun  2 16:52:55 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 2 Jun 2010 14:52:55 +0000
Subject: [M3devel] warning for uninitialized variables?
In-Reply-To: <16413179-F84C-42BF-AB09-2D8294EB4782@cs.purdue.edu>
References: <20100601124200.8E42B2474003@birch.elegosoft.com>,
	, , <E86D485E-C5D5-4B7A-8142-5E0BE31280DD@cs.purdue.edu>, ,
	<COL101-W58EC381F7DE75AC44CFB57E6EF0@phx.gbl>, 
	, , <5458A114-F000-4A90-9998-FD7DF63E06C0@cs.purdue.edu>, ,
	<COL101-W3678C92B3A9FA07AD57BF2E6D00@phx.gbl>, ,
	<20100602035226.43C1F1A208F@async.async.caltech.edu>,
	<COL101-W59770EAA64E52A966D79F3E6D00@phx.gbl>,
	<20100602124422.11C6D1A209A@async.async.caltech.edu>,
	<16413179-F84C-42BF-AB09-2D8294EB4782@cs.purdue.edu>
Message-ID: <COL101-W44444F6A175254747767CFE6D00@phx.gbl>


Running with a consistent initialized/uninitialized 0 is better than running with a "random" value that you get from no initialization.
?They are both "bad".
?The 0 is agreed misleading, because it might look initialized.
? But it still better than a value that can change from run to run.


C int (or ptrdiff_t) and Modula-3 INTEGER are equivalent. They both are "valid" for any bit pattern.
C programmers always consider it a bug to use uninitialized values, except, the case I pointed out, looking for entropy to generate random numbers.

?>> The fact that a variable is uninitialized is a part of the design of the program.

Not if it can be used uninitialized.
Some of the warnings from gcc are definitive -- the values *are* used uninitialized.
Sometimes it says "is used uninitialized", sometimes it says "might be used initialized", and usually it is quiet, either because it knows it isn't used uninitialized or because it is too uncertain.


Programs are written for humans to read, true, but programs that read programs are much more diligent, energetic, and often smarter (and slowly getting smarter with age, often the opposite of humans).
Compilers really do have a big "leg" up on humans, since they can harness fast digital processor with big storage.
Granted, neither is always better than the other. But compilers/computers have far more capacity for code reading than humans and I know from experience that most code is never read by a human, not even once, until I get to it :), because the bugs I readily see wouldn't survive even a glance...
?(and the compilers often fail too, granted).


Again I'm quite surprised we want to leave uninitialized variables that get used uninitialized.
The one in cm3ide for example, if the input is malformed, I believe it uses uninitialized data.
I don't see how this can be deemed anything other than a bug to be fixed, and that we should be glad the compiler (finally) found it..now that I'm working on removing the rampant volatile...


If we can invest in runtime checks to immediately catch reads of unwritten data, then I'd favor that instead.


?- Jay

----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Wed, 2 Jun 2010 10:41:47 -0400
> To: mika at async.async.caltech.edu
> CC: m3devel at elegosoft.com; jay.krell at cornell.edu
> Subject: Re: [M3devel] warning for uninitialized variables?
>
> Hear, hear!
>
> On 2 Jun 2010, at 08:44, Mika Nystrom wrote:
>
>> Jay K writes:
>>>
>>> Wow. You really surprise me Mika.
>>>
>>>
>>> To warn on this kind of thing=2C to me=2C there is no question.
>>>
>>>
>>> Limting the affects by virtue of being safe isn't much consolation.
>>> The program can easily go down a "safe" but very incorrect path.
>>
>> It is, though! Do you always know what value to initialize the
>> variables to? If not, you're just picking some value to shut up
>> the compiler, and now your code no longer expresses---to a human
>> reader---that x is uninitialized.
>>
>> Remember, code is mainly written for humans! Computers don't care
>> about fancy structuring, declarations, etc. When you write a program,
>> you write it to be read by a human. The fact that a variable is
>> uninitialized is a part of the design of the program.
>>
>> It's an unfortunate fact that our languages don't have all the
>> mechanisms necessary to deal properly with uninitialized variables.
>> Retrofitting mechanisms to something that just isn't expressive
>> enough to solve the problem I really don't think is the way to go.
>>
>> EWD's book chapter... read it. "An essay on the scope of variables"
>> I think it is called.
>>
>>
>>>
>>>
>>> There are several forms.
>>> In fact=2C sometimes the compiler says something "is" used uninitialized.
>>> Sometimes it says "maybe".
>>>
>>>
>>> In your example=2C generally=2C once the address is taken of a variable=2C
>>> the compiler gives up. Esp. if that address is passed to a function it does=
>>> n't "see".
>>
>> As long as this doesn't raise warnings I can live with your warnings...
>>
>> ...
>>>
>>>
>>> There are many more warnings in the tree than I have yet looked at.
>>> I've seen a few forms.
>>> Some are because the compiler doesn't know that some functions don't return=
>>> .
>>> I'll see about improving that. Though I think there's a limit to how good I=
>>> can manage=2C
>>> unless we add a <* noreturn *> pragma.
>>
>> adding <*ASSERT FALSE*> in the right places might fix these warnings.
>>
>> ...
>>>
>>>
>>> I grant that by initializing to 0=2C I haven't necessarily made the code co=
>>> rrect either.
>>> But at least it is now consistent.
>>>
>>>
>>> Even better would be runtime checks that stop if a variable is read before =
>>> written.
>>
>> Which you have just defeated with your initialization!
>>
>> I know that my Modula code will outlive its current compiler. Probably
>> by a long time. Once you add the initialization you're talking about,
>> you can't go back. It no longer expresses the useful property you're
>> trying to check. When the new compiler comes along with its runtime
>> check, it will miss that my variables are actually uninitialized.
>>
>>>
>>>
>>> See also the rules in Java and C# that require the compiler to be able to p=
>>> rove
>>> a variable is written before read. Possibly even verifiable at load time.
>>
>> I *hate* this. See above.
>>
>> What's next? The compiler refuses to compile loops that it can't
>> prove will terminate??? Hogwash!
>>
>>>
>>>
>>> Other forms look related to going "through" a switch statement with no arms=
>>> handling the value.
>>> I think I can address that by marking fault_proc as noreturn.
>>>
>>>
>>> One form apparently in cm3ide would use uninitialized data if presented wit=
>>> h a malformed file.
>>> Good software doesn't depend on the well formedness of its input.
>>>
>>> There are many more warnings like this in the tree.
>>>
>>>
>>> My inclination is at least to temporarily hardcode the gcc backend to alway=
>>> s optimize=2C
>>> and always produce these warnings. People can look over them maybe and deci=
>>> de.
>>> Or they can look over my "fixes".
>>>
>>>
>>> Or I guess if people really really really really prefer=2C we can always tu=
>>> rn off the warnings
>>> and let the code lie. I really think that is the wrong answer.
>>>
>>>
>>> I have been burned too much by uninitialized locals in C.
>>> I put " =3D { 0 }" after everything.
>>> Again=2C that isn't necessarily "correct"=2C but at least the incorrect pat=
>>> hs are consistent.
>>> If they don't work and I happen down them=2C they will guaranteeably not wo=
>>> rk.
>>
>> No they will just consistently not work. Not "guaranteeably". You have
>> to initialize them to some specific value for that to be the case.
>> Using "0" often will just give you the wrong answer!
>>
>>>
>>>
>>> Uninitialized values can be different run to run.
>>> Repeatability and consistency are important.
>>
>> Not forcing the programmer to obscure the meaning of the code I think
>> is more important.
>>
>>>
>>>
>>> I'm also nervous about us not taking a hard line on integer overflow.
>>> Overflown math doesn't necessarily lead to array out of bounds soon or ever=
>>> .
>>> It too can lead to incorrect but safe behavior.
>>
>> Similar situation is it not? You don't generate a compiler warning
>> for math that "might overflow".
>>
>> I think we can all agree that error on integer overflow, error on
>> use of uninitialized variable, at runtime, would both be good things?
>>
>> Mika
>>
>>>
>>>
>>> =A0- Jay
>>>
>>>
>>> ----------------------------------------
>>>> To: jay.krell at cornell.edu
>>>> Date: Tue=2C 1 Jun 2010 20:52:26 -0700
>>>> From: mika at async.async.caltech.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] [M3commit] CVS Update: cm3
>>>>
>>>>
>>>> Safety is important in that it allows you to limit the possible effects
>>>> of bugs. Getting programs bug-free is of course a very difficult problem
>>>> no matter what you do.
>>>>
>>>> But no I don't think warnings for uninitialized use of variables is
>>>> something one should do in general in Modula-3. The safety guarantees
>>>> lead to different idioms from in C---not so many compiler warnings
>>>> are required to get your code right. And if you do screw up
>>>> an uninitialized variable=2C the effect is going to be limited.
>>>> Unlike what happens in C=2C where if you screw up the initialization
>>>> of a pointer=2C for instance=2C all hell breaks loose.
>>>>
>>>> Your example is contrived. Usually the code looks like this
>>>>
>>>> VAR
>>>> x : T=3B
>>>> BEGIN
>>>> IF cond1 THEN x :=3D ... END=3B
>>>> ...
>>>> IF cond2 THEN (* use x *) END
>>>> END
>>>>
>>>> where the programmer knows that cond2 logically implies cond1.
>>>>
>>>> I think the presence of VAR parameter passing makes these sorts of
>>>> warnings also less useful in Modula-3. Is the following OK?
>>>>
>>>> PROCEDURE InitializeIt(VAR a : T)=3B
>>>> PROCEUDRE UseIt(VALUE a : T)=3B
>>>>
>>>> VAR x : T=3B
>>>> BEGIN
>>>> InitializeIt(x)=3B
>>>> UseIt(x)
>>>> END
>>>>
>>>> I would think your compiler can't prove that x is initialized. Warning
>>>> or not? I say no: this is actually very reasonable Modula-3 code.
>>>> But then do you want a warning for the IF? It's logically the same.
>>>>
>>>> There's a chapter in
>>>> EWD's Discipline of Programming that deals with the problem in
>>>> detail. I think he winds up with six different "modes" for variables.
>>>>
>>>> Mika
>>>>
>>>> Jay K writes:
>>>>>
>>>>> ok=3D2C so in C:
>>>>> =3D20
>>>>> int F()
>>>>> {
>>>>> int i=3D3B
>>>>> return i=3D3B
>>>>> }
>>>>> =3D20
>>>>> should warn or not?
>>>>> Prevailing wisdom is definitely.
>>>>> Main known exception is code to generate random numbers.
>>>>> I believe this is how Debian broke key generation.
>>>>> =3D20
>>>>> =3D20
>>>>> Modula-3:
>>>>> =3D20
>>>>> =3D20
>>>>> PROCEDURE F(): INTEGER =3D3D=3D20
>>>>> VAR i: INTEGER=3D3B
>>>>> BEGIN
>>>>> RETURN i=3D3B
>>>>> END F=3D3B
>>>>> =3D20
>>>>> =3D20
>>>>> Should warn or not?
>>>>> Since this identical to the C=3D2C prevailing wisdom is definitely.
>>>>> =3D20
>>>>> =3D20
>>>>> They are=3D2C I guess=3D2C "safe"=3D2C but most likely=3D2C incorrect.
>>>>> =3D20
>>>>> =3D20
>>>>> The compiler may have made "safety" guarantees=3D2C and they are signific=
>>> ant=3D
>>>>> =3D2C
>>>>> but safe is far from correct=3D2C and however smart the compiler can be t=
>>> o lo=3D
>>>>> ok for correctness issues=3D2C is also nice.
>>>>> =3D20
>>>>> =3D20
>>>>> =3D20
>>>>> (Friend of mine conjectured something like: Safety guarantees have people=
>>> d=3D
>>>>> eluded. Software will still have plenty of bugs and be plenty difficult t=
>>> o =3D
>>>>> get correct and require plenty of testing. Safety guarantees help=3D2C bu=
>>> t th=3D
>>>>> ey are only a small step toward actual correctness.)
>>>>> =3D20
>>>>> =3D20
>>>>> =3D20
>>>>> - Jay
>>>>>
>>>>>
>>>>> ----------------------------------------
>>>>>> Subject: Re: [M3commit] CVS Update: cm3
>>>>>> From: hosking at cs.purdue.edu
>>>>>> Date: Tue=3D2C 1 Jun 2010 20:04:00 -0400
>>>>>> CC: jkrell at elego.de=3D3B m3commit at elegosoft.com
>>>>>> To: jay.krell at cornell.edu
>>>>>>
>>>>>> Sure=3D2C an INTEGER is a valid value whatever the bits.
>>>>>>
>>>>>>
>>>>>> On 1 Jun 2010=3D2C at 17:44=3D2C Jay K wrote:
>>>>>>
>>>>>>>
>>>>>>> Start removing the rampant use of volatile in the backend and these wa=
>>> rn=3D
>>>>> ings show up.
>>>>>>>
>>>>>>> Volatile quashes the uninitialized checks in the backend.
>>>>>>>
>>>>>>> Is it really ok for an INTEGER to be uninitialized? I realize it conta=
>>> in=3D
>>>>> s an "integer" value=3D2C as all bit patterns are.
>>>>>>>
>>>>>>> Some of these really do seem like bugs. Some do not.
>>>>>>> I'll try making fault_proc noreturn=3D2C which should remove some of t=
>>> hem.
>>>>>>>
>>>>>>>
>>>>>>> - Jay
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ----------------------------------------
>>>>>>>> From: hosking at cs.purdue.edu
>>>>>>>> To: jkrell at elego.de
>>>>>>>> Date: Tue=3D2C 1 Jun 2010 16:29:20 -0500
>>>>>>>> CC: m3commit at elegosoft.com
>>>>>>>> Subject: Re: [M3commit] CVS Update: cm3
>>>>>>>>
>>>>>>>> This is bogus. The M3 compiler guarantees all variables are initializ=
>>> ed=3D
>>>>> .
>>>>>>>>
>>>>>>>> Sent from my iPhone
>>>>>>>>
>>>>>>>> On Jun 1=3D2C 2010=3D2C at 2:42 PM=3D2C jkrell at elego.de (Jay Krell) w=
>>> rote:
>>>>>>>>
>>>>>>>>> CVSROOT: /usr/cvs
>>>>>>>>> Changes by: jkrell at birch. 10/06/01 14:42:00
>>>>>>>>>
>>>>>>>>> Modified files:
>>>>>>>>> cm3/m3-libs/m3core/src/convert/: Convert.m3
>>>>>>>>>
>>>>>>>>> Log message:
>>>>>>>>> initialize locals=3D3B I get warnings that some not quite all=3D2C a=
>>> re
>>>>>>>>> used uninitialized if I remove the volatile/sideeffects on every
>>>>>>>>> load/store in parse.c
>>>>>> =3D
>>> =
>
 		 	   		  

From hosking at cs.purdue.edu  Wed Jun  2 17:02:15 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 2 Jun 2010 11:02:15 -0400
Subject: [M3devel] ADR is *too* unsafe..
In-Reply-To: <COL101-W444318DF7FE046C2AE542AE6D00@phx.gbl>
References: <COL101-W617B9602E6CAA0BBE5BE25E6D00@phx.gbl>,
	<A8CEEB02-D279-4C90-B8D3-5D163619C748@cs.purdue.edu>
	<COL101-W444318DF7FE046C2AE542AE6D00@phx.gbl>
Message-ID: <67147BA0-0307-45FB-B646-588B55EDACC3@cs.purdue.edu>

Actually, the compiler already has support to do exactly what you want.  Take a look at the flag Host.new_adr.  This implements:

ADR (t: T): UNTRACED REF T



On 2 Jun 2010, at 10:07, Jay K wrote:

> 
> The compiler doesn't break. Mentor does, networking stuff. I fixed it. But I would have
> expected the compiler to have told me about it.
> It is unfortunate. ADR should be *slightly* safer.
> Maybe we can get a warning for this? passing ADR(foo) to untraced ref bar?
> It seems...quite unfortunate that the language is defined this way..
> 
>  - Jay
> 
> 
> ----------------------------------------
>> From: hosking at cs.purdue.edu
>> Date: Wed, 2 Jun 2010 10:01:09 -0400
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] ADR is *too* unsafe..
>> 
>> Why does the compiler break?
>> Yes, VAR is *much* safer.
>> 
>> On 2 Jun 2010, at 03:41, Jay K wrote:
>> 
>>> 
>>> (*
>>> Wow, ADR generates a plain ADDRESS, not an untraced ref to a specific type?
>>> Doesn't this seem wrong? Doesn't unsafe code deserve a little better, say,
>>> to be at least as typesafe as C?
>>> http://www.cs.purdue.edu/homes/hosking/m3/reference/unsafe.html
>>> 
>>> This is why 64bit m3-comm/tcp/src/TCP.m3 breaks randomly
>>> on some platforms on an assertion failure in C. And the
>>> compiler isn't going to help me find these type mismatches? Ugh.
>>> 
>>> This seems wrong. :(
>>> 
>>> I guess I should really really use VAR then.
>>> *)
>>> 
>>> 
>>> UNSAFE MODULE Main;
>>> IMPORT Ctypes, Cstddef;
>>> 
>>> 
>>> PROCEDURE F1(a:UNTRACED REF Ctypes.int) =
>>> BEGIN
>>> F2(a); (* error, expected *)
>>> END F1;
>>> 
>>> 
>>> PROCEDURE F2(a:UNTRACED REF Cstddef.size_t) =
>>> BEGIN
>>> F1(a); (* error, expected *)
>>> END F2;
>>> 
>>> 
>>> VAR c:Ctypes.int;
>>> d:Cstddef.size_t;
>>> 
>>> 
>>> BEGIN
>>> F1(ADR(c)); (* ok *)
>>> F1(ADR(d)); (* error expected but no *)
>>> F2(ADR(c)); (* error expected but no *)
>>> F2(ADR(d)); (* ok *)
>>> END Main.
>>> 
>>> 
>>> 
>>> - Jay
>>> 
>> 
> 		 	   		  



From hosking at cs.purdue.edu  Wed Jun  2 17:02:54 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 2 Jun 2010 11:02:54 -0400
Subject: [M3devel] SOLgnu/SOLsun -O1/-O2/-O3
In-Reply-To: <COL101-W26B2AF5D865D1A694793DAE6D00@phx.gbl>
References: <COL101-W26B2AF5D865D1A694793DAE6D00@phx.gbl>
Message-ID: <C793D9CD-5C57-49D8-927D-26EBDEAFE0AB@cs.purdue.edu>

Yes, worked for me using -O3.


On 2 Jun 2010, at 09:01, Jay K wrote:

> 
> Anyone recall if SOLgnu/sun work with any optimization?
>   You know -- the platforms that have a stack walker and don't use setjmp.
> I tried leaving them having all loads/stores be volatile, except handling still doesn't work -- cm3 gets an unhandled exception instead of saying cm3.cfg not found.
> I'll have to test with an old clean version.
> Could be I'm missing something, or maybe the m3cg_pop change broke them.
> 
> 
>  - Jay
> 
> 		 	   		  



From hosking at cs.purdue.edu  Wed Jun  2 17:04:09 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 2 Jun 2010 11:04:09 -0400
Subject: [M3devel] reducing use of volatile in backend?
In-Reply-To: <COL101-W35361E5B4C86598DB49C90E6D00@phx.gbl>
References: <COL101-W17AA739AA2DE2050C6CCD0E6EF0@phx.gbl>,
	<AA1F4490-A9C7-4F94-8E03-65A5E9031424@cs.purdue.edu>
	<COL101-W35361E5B4C86598DB49C90E6D00@phx.gbl>
Message-ID: <B09FDA2E-FBC9-473F-B311-283F9D573568@cs.purdue.edu>



On 2 Jun 2010, at 10:30, Jay K wrote:

> 
> attached is the diff I'm working on.
> 
> 
> It works well on a few platforms.
> I've been using it on AMD64_DARWIN.
> Cross I386_LINUX, PPC_DARWIN cm3 startup and give
>   the correct message, which requires exception handling to work.
> 
> 
> SOLgnu exception handling doesn't work.

Possibly needs a register window flush?  I'm only speculating here.

> MIPS64_OPENBSD internal errors a bunch in the compiler.
>   Probably don't care. Don't know if it was working before.
> 
> Still to do:
>   figure out what is up with SOLgnu/SOLsun
> 
> 
> Not ideal but I think ok for now:
>   volatizing all floating point
>     We already were, though granted possibly with more optimizations.
>   flag_unit_at_a_time = 0
> 
>   
> flag_unit_at_a_time isn't "tricky" or subtle,
> but it does remove a function we want to take the address of.
> I couldn't find a way to get it to keep the function.
> 
> 
> What I think is fine for a while:
>   flag_tree_vrp = 0;
>   flag_tree_pre = 0;
>   flag_tree_fre = 0;
> 
>   
> Maybe it doesn't take much to let them work?
> Maybe wait until 4.5 is working and try again there?
>   In particular pre/fre only fail in one file among m3core/libm3, Formater.m3.
>   vrp is what silently produces non-working code.
>   It is either the only one, or one of pre/fre also do.
>   At least one of pre/fre crash, accessing null pointer.
> 
>  
> and probably also ok for a "while":
>  flag_tree_loop_im = 0
>  flag_schedule_insns = 0
> 
>  
> though for flag_schedule_insns = 0 to fail seems odd,
> and flag_tree_loop_im only broke in a little code, should
> probably look at that code.
> 
> 
> Oh and I still need to see about fours/badbricks recieving mouse clicks.
> Mine aren't.
> 
> 
> The TREE_ADDRESSABLE change in m3_write_globals was needed to get SOLgnu
> to compiler. The assert failed.
> 
> 
> We might want to have the frontend tell the backend if the
> target has a stack walker, instead of the logic I have here.
> 
> 
> While it is not ideal, I think this will let -O1/2/3 generate code much more like people expect, without
> constantly reloading registers from the stack.
> 
> 
>  - Jay
> 
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: hosking at cs.purdue.edu
>> CC: m3devel at elegosoft.com
>> Subject: RE: [M3devel] reducing use of volatile in backend?
>> Date: Tue, 1 Jun 2010 21:55:31 +0000
>> 
>> 
>> I've had *a lot* of success here the past few hours.
>> 
>> 
>> There is an assert starting up mentor I need to look at, possibly out of data binaries.
>> The one in socket.c assert(lossless_socklen || socklen == null || socklen < 1<<30.
>> 
>> 
>> Compiler seems to work.
>> Lots of things do break it, so that is something.
>> 
>> 
>> Various gui apps startup.
>> Some of the gui apps don't work, but nor did older copies I had -- fours, badbricks, and I think columns, wouldn't take any mouse clicks. I have to test older versions. Could be unrelated.
>> 
>> 
>> 
>> Here is what I have:
>> 
>> The vast vast majority of optimizations can be enabled.
>> 
>> Nearly all uses of volatile can be removed.
>> 
>> Just a few optimizations "need" to be disabled.
>> 
>> In particular:
>> I only have volatile remaining:
>> on store after insert_mn (special case)
>> 
>> floating point (huh? wierd)
>> compile errors without this
>> 
>> in functions that call setjmp or vfork
>> This is very reasonable, but we should try to limit it to not all the variables, only what are accessed after the second return (I'm not sure how that computes for vfork, but for setjmp it makes sense to me.
>> 
>> 
>> on the load/store in loophole
>> compile errors without this; perhaps redundant with the floating point check
>> 
>> 
>> on load link, else it gets uninitialized warning
>> 
>> 
>> 
>> Also I found a likely bug.
>> In functions that call setjmp/vfork, we volatize already seen parameters and locals, but we don't volatize not yet seen locals (in nested blocks) and temporaries. I fixed that.
>> 
>> 
>> 
>> 
>> The optimizations I disabled, from memory:
>> 
>> 
>> pre - partial redundancy elimination
>> 
>> 
>> fre - full redundancy elimination (these are related)
>> One or both of these causes the compiler to access violate in the optimizer, compiling libm3/Formatter.mc, but otherwise I think they compile m3core and libm3 entirely
>> 
>> 
>> loop im (induction motion) - caused a compile error in Trestle
>> 
>> vrp - value range propagation
>> This seems to be the biggest problem, no compile errors but "random" runtime malfunction, usually starting up cm3.
>> 
>> 
>> insn_sched - wierd, caused a compile break
>> but insn_sched_after_reload ok
>> 
>> 
>> That's about it. All the ones with "alias" in them, only like two, I enabled, seemed ok.
>> salias and strict_alias. I left strict alias till late in experimentation but really it seems ok.
>> 
>> 
>> I can compile the entire system, though I get lots of warnings about uninitialized variables.
>> I pass the backend the -Wuninitialized flag.
>> 
>> 
>> I test it out more -- the gui non-interaction, the mentor assert, and test other platforms.
>> But I think we'll have volatile mostly gone and just a small number of optimizations turned off fairly soon.
>> We can iterate more on the remaining optimizations.
>> 
>> 
>> Getting good typeinfo would be good so that gdb can debug.
>> And maybe so that other than stabs works.
>> 
>> 
>> - Jay
>> 
>> 
>> 
>> 
>> ----------------------------------------
>>> From: hosking at cs.purdue.edu
>>> To: jay.krell at cornell.edu
>>> Date: Tue, 1 Jun 2010 16:05:30 -0500
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] reducing use of volatile in backend?
>>> 
>>> We don't want to disable optimisations for types where it makes sense
>>> to have them. Better to smarten up typebased alias analysis instead so
>>> we can get rid of volatile properly.
>>> 
>>> Sent from my iPhone
>>> 
>>> On Jun 1, 2010, at 12:16 PM, Jay K wrote:
>>> 
>>>> 
>>>> Tony, would we maybe be better off not using volatile everywhere but
>>>> selectively turning off optimizations in m3_post_options?
>>>> You know, using volatile probably disables more than necessary?
>>>> I'm experimenting with this.
>>>> 
>>>> - Jay
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
> 		 	   		  <less-volatile.txt>

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

From hosking at cs.purdue.edu  Wed Jun  2 17:06:23 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 2 Jun 2010 11:06:23 -0400
Subject: [M3devel] warning for uninitialized variables?
In-Reply-To: <COL101-W44444F6A175254747767CFE6D00@phx.gbl>
References: <20100601124200.8E42B2474003@birch.elegosoft.com>, , ,
	<E86D485E-C5D5-4B7A-8142-5E0BE31280DD@cs.purdue.edu>, ,
	<COL101-W58EC381F7DE75AC44CFB57E6EF0@phx.gbl>, , ,
	<5458A114-F000-4A90-9998-FD7DF63E06C0@cs.purdue.edu>, ,
	<COL101-W3678C92B3A9FA07AD57BF2E6D00@phx.gbl>, ,
	<20100602035226.43C1F1A208F@async.async.caltech.edu>,
	<COL101-W59770EAA64E52A966D79F3E6D00@phx.gbl>,
	<20100602124422.11C6D1A209A@async.async.caltech.edu>,
	<16413179-F84C-42BF-AB09-2D8294EB4782@cs.purdue.edu>
	<COL101-W44444F6A175254747767CFE6D00@phx.gbl>
Message-ID: <5EDDD7E5-C33E-4BD1-A036-2D3561F08277@cs.purdue.edu>

On 2 Jun 2010, at 10:52, Jay K wrote:

> If we can invest in runtime checks to immediately catch reads of unwritten data, then I'd favor that instead.

YUCK!



From hosking at cs.purdue.edu  Wed Jun  2 17:08:55 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 2 Jun 2010 11:08:55 -0400
Subject: [M3devel] ADR is *too* unsafe..
In-Reply-To: <67147BA0-0307-45FB-B646-588B55EDACC3@cs.purdue.edu>
References: <COL101-W617B9602E6CAA0BBE5BE25E6D00@phx.gbl>,
	<A8CEEB02-D279-4C90-B8D3-5D163619C748@cs.purdue.edu>
	<COL101-W444318DF7FE046C2AE542AE6D00@phx.gbl>
	<67147BA0-0307-45FB-B646-588B55EDACC3@cs.purdue.edu>
Message-ID: <833AEC0D-7CAD-4E2E-A99D-C12F5C0DD870@cs.purdue.edu>

Also, I meant to point to:

http://www.modula3.org/threads/3/#advancedTopic

On 2 Jun 2010, at 11:02, Tony Hosking wrote:

> Actually, the compiler already has support to do exactly what you want.  Take a look at the flag Host.new_adr.  This implements:
> 
> ADR (t: T): UNTRACED REF T
> 
> 
> 
> On 2 Jun 2010, at 10:07, Jay K wrote:
> 
>> 
>> The compiler doesn't break. Mentor does, networking stuff. I fixed it. But I would have
>> expected the compiler to have told me about it.
>> It is unfortunate. ADR should be *slightly* safer.
>> Maybe we can get a warning for this? passing ADR(foo) to untraced ref bar?
>> It seems...quite unfortunate that the language is defined this way..
>> 
>> - Jay
>> 
>> 
>> ----------------------------------------
>>> From: hosking at cs.purdue.edu
>>> Date: Wed, 2 Jun 2010 10:01:09 -0400
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] ADR is *too* unsafe..
>>> 
>>> Why does the compiler break?
>>> Yes, VAR is *much* safer.
>>> 
>>> On 2 Jun 2010, at 03:41, Jay K wrote:
>>> 
>>>> 
>>>> (*
>>>> Wow, ADR generates a plain ADDRESS, not an untraced ref to a specific type?
>>>> Doesn't this seem wrong? Doesn't unsafe code deserve a little better, say,
>>>> to be at least as typesafe as C?
>>>> http://www.cs.purdue.edu/homes/hosking/m3/reference/unsafe.html
>>>> 
>>>> This is why 64bit m3-comm/tcp/src/TCP.m3 breaks randomly
>>>> on some platforms on an assertion failure in C. And the
>>>> compiler isn't going to help me find these type mismatches? Ugh.
>>>> 
>>>> This seems wrong. :(
>>>> 
>>>> I guess I should really really use VAR then.
>>>> *)
>>>> 
>>>> 
>>>> UNSAFE MODULE Main;
>>>> IMPORT Ctypes, Cstddef;
>>>> 
>>>> 
>>>> PROCEDURE F1(a:UNTRACED REF Ctypes.int) =
>>>> BEGIN
>>>> F2(a); (* error, expected *)
>>>> END F1;
>>>> 
>>>> 
>>>> PROCEDURE F2(a:UNTRACED REF Cstddef.size_t) =
>>>> BEGIN
>>>> F1(a); (* error, expected *)
>>>> END F2;
>>>> 
>>>> 
>>>> VAR c:Ctypes.int;
>>>> d:Cstddef.size_t;
>>>> 
>>>> 
>>>> BEGIN
>>>> F1(ADR(c)); (* ok *)
>>>> F1(ADR(d)); (* error expected but no *)
>>>> F2(ADR(c)); (* error expected but no *)
>>>> F2(ADR(d)); (* ok *)
>>>> END Main.
>>>> 
>>>> 
>>>> 
>>>> - Jay
>>>> 
>>> 
>> 		 	   		  
> 



From jay.krell at cornell.edu  Wed Jun  2 17:13:55 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 2 Jun 2010 15:13:55 +0000
Subject: [M3devel] warning for uninitialized variables?
In-Reply-To: <5EDDD7E5-C33E-4BD1-A036-2D3561F08277@cs.purdue.edu>
References: <20100601124200.8E42B2474003@birch.elegosoft.com>, ,
	,,<E86D485E-C5D5-4B7A-8142-5E0BE31280DD@cs.purdue.edu>,
	,,<COL101-W58EC381F7DE75AC44CFB57E6EF0@phx.gbl>, ,
	,,<5458A114-F000-4A90-9998-FD7DF63E06C0@cs.purdue.edu>,
	,,<COL101-W3678C92B3A9FA07AD57BF2E6D00@phx.gbl>,
	, , <20100602035226.43C1F1A208F@async.async.caltech.edu>, ,
	<COL101-W59770EAA64E52A966D79F3E6D00@phx.gbl>, ,
	<20100602124422.11C6D1A209A@async.async.caltech.edu>, ,
	<16413179-F84C-42BF-AB09-2D8294EB4782@cs.purdue.edu>,
	<COL101-W44444F6A175254747767CFE6D00@phx.gbl>,
	<5EDDD7E5-C33E-4BD1-A036-2D3561F08277@cs.purdue.edu>
Message-ID: <COL101-W40BE08A256108863A44C5FE6D00@phx.gbl>


Well, I'm certainly not lobbying hard for that, presumably there is no efficient implementation, esp. for full range integers.

Wikipedia has a nice article. "nice" means "agrees with me".


http://en.wikipedia.org/wiki/Uninitialized_variable
"it is a programming error and a common source of bugs in software."


And then they point out how Java requires mechanically verified initialization of locals.

The code:
void F(bool a)
?int i;
?if (a)
?? i = 0;
if (a)
? print(i)


is I believe illegal.


?- Jay


----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Wed, 2 Jun 2010 11:06:23 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] warning for uninitialized variables?
>
> On 2 Jun 2010, at 10:52, Jay K wrote:
>
>> If we can invest in runtime checks to immediately catch reads of unwritten data, then I'd favor that instead.
>
> YUCK!
>
 		 	   		  

From jay.krell at cornell.edu  Wed Jun  2 17:18:22 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 2 Jun 2010 15:18:22 +0000
Subject: [M3devel] ADR is *too* unsafe..
In-Reply-To: <833AEC0D-7CAD-4E2E-A99D-C12F5C0DD870@cs.purdue.edu>
References: <COL101-W617B9602E6CAA0BBE5BE25E6D00@phx.gbl>, ,
	<A8CEEB02-D279-4C90-B8D3-5D163619C748@cs.purdue.edu>,
	<COL101-W444318DF7FE046C2AE542AE6D00@phx.gbl>,
	<67147BA0-0307-45FB-B646-588B55EDACC3@cs.purdue.edu>,
	<833AEC0D-7CAD-4E2E-A99D-C12F5C0DD870@cs.purdue.edu>
Message-ID: <COL101-W259EC30CD3362F448A983DE6D00@phx.gbl>


Cool.

?> but also modified the front-end of the compiler to generate C
header files for Modula-3 interface files.
?> This way, procedures exported via a
Modula-3 interface can be called directly from C using "module dot method"
syntax


I've been wanting that. :)

?> "CVAR"

Sounds like a good small change?

?- Jay


----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Wed, 2 Jun 2010 11:08:55 -0400
> To: hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com; jay.krell at cornell.edu
> Subject: Re: [M3devel] ADR is *too* unsafe..
>
> Also, I meant to point to:
>
> http://www.modula3.org/threads/3/#advancedTopic
>
> On 2 Jun 2010, at 11:02, Tony Hosking wrote:
>
>> Actually, the compiler already has support to do exactly what you want. Take a look at the flag Host.new_adr. This implements:
>>
>> ADR (t: T): UNTRACED REF T
>>
>>
>>
>> On 2 Jun 2010, at 10:07, Jay K wrote:
>>
>>>
>>> The compiler doesn't break. Mentor does, networking stuff. I fixed it. But I would have
>>> expected the compiler to have told me about it.
>>> It is unfortunate. ADR should be *slightly* safer.
>>> Maybe we can get a warning for this? passing ADR(foo) to untraced ref bar?
>>> It seems...quite unfortunate that the language is defined this way..
>>>
>>> - Jay
>>>
>>>
>>> ----------------------------------------
>>>> From: hosking at cs.purdue.edu
>>>> Date: Wed, 2 Jun 2010 10:01:09 -0400
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] ADR is *too* unsafe..
>>>>
>>>> Why does the compiler break?
>>>> Yes, VAR is *much* safer.
>>>>
>>>> On 2 Jun 2010, at 03:41, Jay K wrote:
>>>>
>>>>>
>>>>> (*
>>>>> Wow, ADR generates a plain ADDRESS, not an untraced ref to a specific type?
>>>>> Doesn't this seem wrong? Doesn't unsafe code deserve a little better, say,
>>>>> to be at least as typesafe as C?
>>>>> http://www.cs.purdue.edu/homes/hosking/m3/reference/unsafe.html
>>>>>
>>>>> This is why 64bit m3-comm/tcp/src/TCP.m3 breaks randomly
>>>>> on some platforms on an assertion failure in C. And the
>>>>> compiler isn't going to help me find these type mismatches? Ugh.
>>>>>
>>>>> This seems wrong. :(
>>>>>
>>>>> I guess I should really really use VAR then.
>>>>> *)
>>>>>
>>>>>
>>>>> UNSAFE MODULE Main;
>>>>> IMPORT Ctypes, Cstddef;
>>>>>
>>>>>
>>>>> PROCEDURE F1(a:UNTRACED REF Ctypes.int) =
>>>>> BEGIN
>>>>> F2(a); (* error, expected *)
>>>>> END F1;
>>>>>
>>>>>
>>>>> PROCEDURE F2(a:UNTRACED REF Cstddef.size_t) =
>>>>> BEGIN
>>>>> F1(a); (* error, expected *)
>>>>> END F2;
>>>>>
>>>>>
>>>>> VAR c:Ctypes.int;
>>>>> d:Cstddef.size_t;
>>>>>
>>>>>
>>>>> BEGIN
>>>>> F1(ADR(c)); (* ok *)
>>>>> F1(ADR(d)); (* error expected but no *)
>>>>> F2(ADR(c)); (* error expected but no *)
>>>>> F2(ADR(d)); (* ok *)
>>>>> END Main.
>>>>>
>>>>>
>>>>>
>>>>> - Jay
>>>>>
>>>>
>>>
>>
>
 		 	   		  

From mika at async.async.caltech.edu  Wed Jun  2 17:32:20 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Wed, 02 Jun 2010 08:32:20 -0700
Subject: [M3devel] warning for uninitialized variables?
In-Reply-To: <COL101-W40BE08A256108863A44C5FE6D00@phx.gbl> 
Message-ID: <20100602153220.A4A041A209D@async.async.caltech.edu>

Jay K writes:
>
>Well=2C I'm certainly not lobbying hard for that=2C presumably there is no =
>efficient implementation=2C esp. for full range integers.
>
>Wikipedia has a nice article. "nice" means "agrees with me".
>
>
>http://en.wikipedia.org/wiki/Uninitialized_variable
>"it is a programming error and a common source of bugs in software."

I don't think anyone disagrees too strongly with that, Jay, but
the question is what can be done about it.  I think the sad answer
is, "not much."

>
>
>And then they point out how Java requires mechanically verified initializat=
>ion of locals.

One might equally well say that an infinite loop is a programming error
and a common source of bugs in software.

Some good people, accordingly, insist that every loop be accompanied by
a proof of termination.

The difference is, of course, that it is obvious that there are
useful loops that we cannot ever expect a compiler to be able to prove
termination of (on its own), whereas "some people feel" that there are
no useful ways of initializing variables that could not be verified
correct by a particular implementation of the Java compiler.

I think that if you take a step back from the problems you will see
they are in fact the same problem: they both breach the "undecidability
barrier".  This is because we haven't put enough information in the
variable declarations themselves to deduce what is wanted.  EWD's chapter
is a start on that---how to do this statically.  (That's the last time
I'm going to plug that chapter, I promise.) 

Modula-3 actually has some very nice mechanisms for avoiding uninitialized
variables.  The ability to declare/initialize a variable from an
expression without providing an explicit type is one.  WITH is another.
I almost never have problems with uninitialized variables in my Modula-3
programs.  Almost...

    Mika


From mika at async.async.caltech.edu  Wed Jun  2 17:37:04 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Wed, 02 Jun 2010 08:37:04 -0700
Subject: [M3devel] ADR is *too* unsafe..
In-Reply-To: <COL101-W259EC30CD3362F448A983DE6D00@phx.gbl> 
References: <COL101-W617B9602E6CAA0BBE5BE25E6D00@phx.gbl>, ,
	<A8CEEB02-D279-4C90-B8D3-5D163619C748@cs.purdue.edu>,
	<COL101-W444318DF7FE046C2AE542AE6D00@phx.gbl>,
	<67147BA0-0307-45FB-B646-588B55EDACC3@cs.purdue.edu>,
	<833AEC0D-7CAD-4E2E-A99D-C12F5C0DD870@cs.purdue.edu>
	<COL101-W259EC30CD3362F448A983DE6D00@phx.gbl>
Message-ID: <20100602153704.7645A1A209F@async.async.caltech.edu>

Jay K writes:
>
>Cool.
>
>=A0> but also modified the front-end of the compiler to generate C
>header files for Modula-3 interface files.
>=A0> This way=2C procedures exported via a
>Modula-3 interface can be called directly from C using "module dot method"
>syntax
>
>
>I've been wanting that. :)

What do you want it to do?

My Modula-Scheme system does this for Scheme already.. in fact it's
probably doing something even more complicated than what you want... hmm.
I've been meaning to check it in somewhere for a long time.

     Mika

>
>=A0> "CVAR"
>
>Sounds like a good small change?
>
>=A0- Jay
>
>
...


From jay.krell at cornell.edu  Wed Jun  2 17:42:41 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 2 Jun 2010 15:42:41 +0000
Subject: [M3devel] warning for uninitialized variables?
In-Reply-To: <20100602153220.A4A041A209D@async.async.caltech.edu>
References: <COL101-W40BE08A256108863A44C5FE6D00@phx.gbl>
	,<20100602153220.A4A041A209D@async.async.caltech.edu>
Message-ID: <COL101-W5218B47FE71F77410C9668E6D00@phx.gbl>


I've looked but can't quite find the paper. I found its "number".
Modula-3 ... I think beats C, because I can specify initializers for records, and subranges and enums are initialized.
C++ is more general and nice though since I can specificy initialization functions for types. Not as unenforced convention as in Modula-3, but enforced because the compiler makes the calls. Though Modula-3 does at least have the compiler generally do some initialization.


"what to do about it", well, compilers these days can tell us.
I/we have to go through the warnings that my upcoming change generate. A fair number.
But I/we should wait until I also have fault_proc marked as "noreturn", since that should help reduce them.
And maybe maybe even add <* noreturn *> pragma or such, since I know there cases like:
? (possibly the front end figures it out by seeing what you call, but still need to communicate it down)


if x = 0
? i = 0
else if x = 1
? i = 2
else if x = 2
? i = 4
else
? error(); (* probably noreturn *)
print i (* compiler complains it might be uninitialized, from the error case *)


?- Jay


----------------------------------------
> To: jay.krell at cornell.edu
> Date: Wed, 2 Jun 2010 08:32:20 -0700
> From: mika at async.async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] warning for uninitialized variables?
>
> Jay K writes:
>>
>>Well=2C I'm certainly not lobbying hard for that=2C presumably there is no =
>>efficient implementation=2C esp. for full range integers.
>>
>>Wikipedia has a nice article. "nice" means "agrees with me".
>>
>>
>>http://en.wikipedia.org/wiki/Uninitialized_variable
>>"it is a programming error and a common source of bugs in software."
>
> I don't think anyone disagrees too strongly with that, Jay, but
> the question is what can be done about it. I think the sad answer
> is, "not much."
>
>>
>>
>>And then they point out how Java requires mechanically verified initializat=
>>ion of locals.
>
> One might equally well say that an infinite loop is a programming error
> and a common source of bugs in software.
>
> Some good people, accordingly, insist that every loop be accompanied by
> a proof of termination.
>
> The difference is, of course, that it is obvious that there are
> useful loops that we cannot ever expect a compiler to be able to prove
> termination of (on its own), whereas "some people feel" that there are
> no useful ways of initializing variables that could not be verified
> correct by a particular implementation of the Java compiler.
>
> I think that if you take a step back from the problems you will see
> they are in fact the same problem: they both breach the "undecidability
> barrier". This is because we haven't put enough information in the
> variable declarations themselves to deduce what is wanted. EWD's chapter
> is a start on that---how to do this statically. (That's the last time
> I'm going to plug that chapter, I promise.)
>
> Modula-3 actually has some very nice mechanisms for avoiding uninitialized
> variables. The ability to declare/initialize a variable from an
> expression without providing an explicit type is one. WITH is another.
> I almost never have problems with uninitialized variables in my Modula-3
> programs. Almost...
>
> Mika
 		 	   		  

From jay.krell at cornell.edu  Wed Jun  2 17:48:56 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 2 Jun 2010 15:48:56 +0000
Subject: [M3devel] ADR is *too* unsafe..
In-Reply-To: <20100602153704.7645A1A209F@async.async.caltech.edu>
References: <COL101-W617B9602E6CAA0BBE5BE25E6D00@phx.gbl>, ,
	<A8CEEB02-D279-4C90-B8D3-5D163619C748@cs.purdue.edu>,
	<COL101-W444318DF7FE046C2AE542AE6D00@phx.gbl>,
	<67147BA0-0307-45FB-B646-588B55EDACC3@cs.purdue.edu>,
	<833AEC0D-7CAD-4E2E-A99D-C12F5C0DD870@cs.purdue.edu>
	<COL101-W259EC30CD3362F448A983DE6D00@phx.gbl>,
	<20100602153704.7645A1A209F@async.async.caltech.edu>
Message-ID: <COL101-W3271AE47A4F3E15973FAB3E6D00@phx.gbl>


for example:

/dev2/cm3/m3-libs/m3core/src/unix/Common/Ustat.i3

TYPE
? struct_stat = RECORD
(*
This MUST match UstatC.c.

Sorted by size, then by name; make everything LONGINT if possible, else INTEGER;
Limit on LONGINT is compatibility with existing Modula-3 code. Blowing up the sizes
larger than necessary is a slight deoptimization for the sake of simplicity and
commonality. *)
??? st_dev?? : LONGINT; (* Utypes.dev_t?? *)
??? st_ino?? : LONGINT; (* Utypes.ino_t?? *)
??? st_mtime : LONGINT; (* not time_t???? *)
??? st_nlink : LONGINT; (* Utypes.nlink_t *)
??? st_rdev? : LONGINT; (* Utypes.dev_t?? *)
??? st_size? : LONGINT; (* Utypes.off_t?? *)
??? st_flags : INTEGER; (* only on some platforms: Darwin, FreeBSD, OpenBSD, NetBSD, else 0 *)
??? st_gid?? : INTEGER; (* Utypes.gid_t?? *)
??? st_mode? : INTEGER; (* Utypes.mode_t? *)
??? st_uid?? : INTEGER; (* Utypes.uid_t?? *)
? END;
? struct_stat_star = UNTRACED REF struct_stat;


/dev2/cm3/m3-libs/m3core/src/unix/Common/UstatC.c 

struct _m3_stat_t
{
/*
This MUST match Ustat.i3.

Sorted by size, then by name; make everything LONGINT if possible, else INTEGER;
Limit on LONGINT is compatibility with existing Modula-3 code. Blowing up the sizes
larger than necessary is a slight deoptimization for the sake of simplicity and
commonality.
??? 
"st_" prefix is omitted from the names in case they are macros, which does happen */

??? LONGINT dev;
??? LONGINT ino;
??? LONGINT mtime;
??? LONGINT nlink;
??? LONGINT rdev;
??? LONGINT size;
??? INTEGER flags;
??? INTEGER gid;
??? INTEGER mode;
??? INTEGER uid;
};


We used to clone headers through careful reading of multiple platform-specified #ifdefed-to-heck headers.
Now we clone them through easier reading of simple platform-independent #ifdef-free headers.
This is progress, it is easier for programmer to get it right and eyeball it and believe it is right.


But what should actually happen is compiler should generate Ustat.h from Ustat.i3.
The only mechanical duplicate that should occur, should be done by programs.
Comments that say "must match" are the signature of a compromise, that I made.


Similarly but less obviously how, Uconstants.c should be generated.
Given a list of symbols, the C code should just #ifdef foo const bar__foo = foo #endif tc.


Such generation should happen every time one builds.
?Not just once and check them in and hope they stay current (as many folks are prone to, not necessarily present company)


?- Jay

----------------------------------------
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] ADR is *too* unsafe..
> Date: Wed, 2 Jun 2010 08:37:04 -0700
> From: mika at async.async.caltech.edu
>
> Jay K writes:
>>
>>Cool.
>>
>>=A0> but also modified the front-end of the compiler to generate C
>>header files for Modula-3 interface files.
>>=A0> This way=2C procedures exported via a
>>Modula-3 interface can be called directly from C using "module dot method"
>>syntax
>>
>>
>>I've been wanting that. :)
>
> What do you want it to do?
>
> My Modula-Scheme system does this for Scheme already.. in fact it's
> probably doing something even more complicated than what you want... hmm.
> I've been meaning to check it in somewhere for a long time.
>
> Mika
>
>>
>>=A0> "CVAR"
>>
>>Sounds like a good small change?
>>
>>=A0- Jay
>>
>>
> ...
 		 	   		  

From mika at async.async.caltech.edu  Wed Jun  2 18:08:11 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Wed, 02 Jun 2010 09:08:11 -0700
Subject: [M3devel] ADR is *too* unsafe..
In-Reply-To: <COL101-W3271AE47A4F3E15973FAB3E6D00@phx.gbl> 
References: <COL101-W617B9602E6CAA0BBE5BE25E6D00@phx.gbl>, ,
	<A8CEEB02-D279-4C90-B8D3-5D163619C748@cs.purdue.edu>,
	<COL101-W444318DF7FE046C2AE542AE6D00@phx.gbl>,
	<67147BA0-0307-45FB-B646-588B55EDACC3@cs.purdue.edu>,
	<833AEC0D-7CAD-4E2E-A99D-C12F5C0DD870@cs.purdue.edu>
	<COL101-W259EC30CD3362F448A983DE6D00@phx.gbl>,
	<20100602153704.7645A1A209F@async.async.caltech.edu>
	<COL101-W3271AE47A4F3E15973FAB3E6D00@phx.gbl>
Message-ID: <20100602160811.9FCE71A209C@async.async.caltech.edu>


That shouldn't be hard, provided you're willing to write some
Scheme code :-)

     Mika

Jay K writes:
>
>for example:
>
>/dev2/cm3/m3-libs/m3core/src/unix/Common/Ustat.i3
>
>TYPE
>=A0 struct_stat =3D RECORD
>(*
>This MUST match UstatC.c.
>
>Sorted by size=2C then by name=3B make everything LONGINT if possible=2C el=
>se INTEGER=3B
>Limit on LONGINT is compatibility with existing Modula-3 code. Blowing up t=
>he sizes
>larger than necessary is a slight deoptimization for the sake of simplicity=
> and
>commonality. *)
>=A0=A0=A0 st_dev=A0=A0 : LONGINT=3B (* Utypes.dev_t=A0=A0 *)
>=A0=A0=A0 st_ino=A0=A0 : LONGINT=3B (* Utypes.ino_t=A0=A0 *)
>=A0=A0=A0 st_mtime : LONGINT=3B (* not time_t=A0=A0=A0=A0 *)
>=A0=A0=A0 st_nlink : LONGINT=3B (* Utypes.nlink_t *)
>=A0=A0=A0 st_rdev=A0 : LONGINT=3B (* Utypes.dev_t=A0=A0 *)
>=A0=A0=A0 st_size=A0 : LONGINT=3B (* Utypes.off_t=A0=A0 *)
>=A0=A0=A0 st_flags : INTEGER=3B (* only on some platforms: Darwin=2C FreeBS=
>D=2C OpenBSD=2C NetBSD=2C else 0 *)
>=A0=A0=A0 st_gid=A0=A0 : INTEGER=3B (* Utypes.gid_t=A0=A0 *)
>=A0=A0=A0 st_mode=A0 : INTEGER=3B (* Utypes.mode_t=A0 *)
>=A0=A0=A0 st_uid=A0=A0 : INTEGER=3B (* Utypes.uid_t=A0=A0 *)
>=A0 END=3B
>=A0 struct_stat_star =3D UNTRACED REF struct_stat=3B
>
>
>/dev2/cm3/m3-libs/m3core/src/unix/Common/UstatC.c=20
>
>struct _m3_stat_t
>{
>/*
>This MUST match Ustat.i3.
>
>Sorted by size=2C then by name=3B make everything LONGINT if possible=2C el=
>se INTEGER=3B
>Limit on LONGINT is compatibility with existing Modula-3 code. Blowing up t=
>he sizes
>larger than necessary is a slight deoptimization for the sake of simplicity=
> and
>commonality.
>=A0=A0=A0=20
>"st_" prefix is omitted from the names in case they are macros=2C which doe=
>s happen */
>
>=A0=A0=A0 LONGINT dev=3B
>=A0=A0=A0 LONGINT ino=3B
>=A0=A0=A0 LONGINT mtime=3B
>=A0=A0=A0 LONGINT nlink=3B
>=A0=A0=A0 LONGINT rdev=3B
>=A0=A0=A0 LONGINT size=3B
>=A0=A0=A0 INTEGER flags=3B
>=A0=A0=A0 INTEGER gid=3B
>=A0=A0=A0 INTEGER mode=3B
>=A0=A0=A0 INTEGER uid=3B
>}=3B
>
>
>We used to clone headers through careful reading of multiple platform-speci=
>fied #ifdefed-to-heck headers.
>Now we clone them through easier reading of simple platform-independent #if=
>def-free headers.
>This is progress=2C it is easier for programmer to get it right and eyeball=
> it and believe it is right.
>
>
>But what should actually happen is compiler should generate Ustat.h from Us=
>tat.i3.
>The only mechanical duplicate that should occur=2C should be done by progra=
>ms.
>Comments that say "must match" are the signature of a compromise=2C that I =
>made.
>
>
>Similarly but less obviously how=2C Uconstants.c should be generated.
>Given a list of symbols=2C the C code should just #ifdef foo const bar__foo=
> =3D foo #endif tc.
>
>
>Such generation should happen every time one builds.
>=A0Not just once and check them in and hope they stay current (as many folk=
>s are prone to=2C not necessarily present company)
>
>
>=A0- Jay
>
>----------------------------------------
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] ADR is *too* unsafe..
>> Date: Wed=2C 2 Jun 2010 08:37:04 -0700
>> From: mika at async.async.caltech.edu
>>
>> Jay K writes:
>>>
>>>Cool.
>>>
>>>=3DA0> but also modified the front-end of the compiler to generate C
>>>header files for Modula-3 interface files.
>>>=3DA0> This way=3D2C procedures exported via a
>>>Modula-3 interface can be called directly from C using "module dot method=
>"
>>>syntax
>>>
>>>
>>>I've been wanting that. :)
>>
>> What do you want it to do?
>>
>> My Modula-Scheme system does this for Scheme already.. in fact it's
>> probably doing something even more complicated than what you want... hmm.
>> I've been meaning to check it in somewhere for a long time.
>>
>> Mika
>>
>>>
>>>=3DA0> "CVAR"
>>>
>>>Sounds like a good small change?
>>>
>>>=3DA0- Jay
>>>
>>>
>> ...
> 		 	   		  =


From jay.krell at cornell.edu  Wed Jun  2 18:54:45 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 2 Jun 2010 16:54:45 +0000
Subject: [M3devel] ADR is *too* unsafe..
In-Reply-To: <20100602160811.9FCE71A209C@async.async.caltech.edu>
References: <COL101-W617B9602E6CAA0BBE5BE25E6D00@phx.gbl>, ,
	<A8CEEB02-D279-4C90-B8D3-5D163619C748@cs.purdue.edu>,
	<COL101-W444318DF7FE046C2AE542AE6D00@phx.gbl>,
	<67147BA0-0307-45FB-B646-588B55EDACC3@cs.purdue.edu>,
	<833AEC0D-7CAD-4E2E-A99D-C12F5C0DD870@cs.purdue.edu>
	<COL101-W259EC30CD3362F448A983DE6D00@phx.gbl>,
	<20100602153704.7645A1A209F@async.async.caltech.edu>
	<COL101-W3271AE47A4F3E15973FAB3E6D00@phx.gbl>,
	<20100602160811.9FCE71A209C@async.async.caltech.edu>
Message-ID: <COL101-W2141AC09F05E54A393E48BE6D00@phx.gbl>


As long as I describe the interface just once, and you then spit out both .i3 and .h, and
they are pretty much "guaranteed to match", ok.
(Or maybe it can interface with the Modula-3 compiler at a lower level in-memory, instead
of out to text and then parsed back into something else; I have no similar hope for C..)

?- Jay


----------------------------------------
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] ADR is *too* unsafe..
> Date: Wed, 2 Jun 2010 09:08:11 -0700
> From: mika at async.async.caltech.edu
>
>
> That shouldn't be hard, provided you're willing to write some
> Scheme code :-)
>
> Mika
>
> Jay K writes:
>>
>>for example:
>>
>>/dev2/cm3/m3-libs/m3core/src/unix/Common/Ustat.i3
>>
>>TYPE
>>=A0 struct_stat =3D RECORD
>>(*
>>This MUST match UstatC.c.
>>
>>Sorted by size=2C then by name=3B make everything LONGINT if possible=2C el=
>>se INTEGER=3B
>>Limit on LONGINT is compatibility with existing Modula-3 code. Blowing up t=
>>he sizes
>>larger than necessary is a slight deoptimization for the sake of simplicity=
>> and
>>commonality. *)
>>=A0=A0=A0 st_dev=A0=A0 : LONGINT=3B (* Utypes.dev_t=A0=A0 *)
>>=A0=A0=A0 st_ino=A0=A0 : LONGINT=3B (* Utypes.ino_t=A0=A0 *)
>>=A0=A0=A0 st_mtime : LONGINT=3B (* not time_t=A0=A0=A0=A0 *)
>>=A0=A0=A0 st_nlink : LONGINT=3B (* Utypes.nlink_t *)
>>=A0=A0=A0 st_rdev=A0 : LONGINT=3B (* Utypes.dev_t=A0=A0 *)
>>=A0=A0=A0 st_size=A0 : LONGINT=3B (* Utypes.off_t=A0=A0 *)
>>=A0=A0=A0 st_flags : INTEGER=3B (* only on some platforms: Darwin=2C FreeBS=
>>D=2C OpenBSD=2C NetBSD=2C else 0 *)
>>=A0=A0=A0 st_gid=A0=A0 : INTEGER=3B (* Utypes.gid_t=A0=A0 *)
>>=A0=A0=A0 st_mode=A0 : INTEGER=3B (* Utypes.mode_t=A0 *)
>>=A0=A0=A0 st_uid=A0=A0 : INTEGER=3B (* Utypes.uid_t=A0=A0 *)
>>=A0 END=3B
>>=A0 struct_stat_star =3D UNTRACED REF struct_stat=3B
>>
>>
>>/dev2/cm3/m3-libs/m3core/src/unix/Common/UstatC.c=20
>>
>>struct _m3_stat_t
>>{
>>/*
>>This MUST match Ustat.i3.
>>
>>Sorted by size=2C then by name=3B make everything LONGINT if possible=2C el=
>>se INTEGER=3B
>>Limit on LONGINT is compatibility with existing Modula-3 code. Blowing up t=
>>he sizes
>>larger than necessary is a slight deoptimization for the sake of simplicity=
>> and
>>commonality.
>>=A0=A0=A0=20
>>"st_" prefix is omitted from the names in case they are macros=2C which doe=
>>s happen */
>>
>>=A0=A0=A0 LONGINT dev=3B
>>=A0=A0=A0 LONGINT ino=3B
>>=A0=A0=A0 LONGINT mtime=3B
>>=A0=A0=A0 LONGINT nlink=3B
>>=A0=A0=A0 LONGINT rdev=3B
>>=A0=A0=A0 LONGINT size=3B
>>=A0=A0=A0 INTEGER flags=3B
>>=A0=A0=A0 INTEGER gid=3B
>>=A0=A0=A0 INTEGER mode=3B
>>=A0=A0=A0 INTEGER uid=3B
>>}=3B
>>
>>
>>We used to clone headers through careful reading of multiple platform-speci=
>>fied #ifdefed-to-heck headers.
>>Now we clone them through easier reading of simple platform-independent #if=
>>def-free headers.
>>This is progress=2C it is easier for programmer to get it right and eyeball=
>> it and believe it is right.
>>
>>
>>But what should actually happen is compiler should generate Ustat.h from Us=
>>tat.i3.
>>The only mechanical duplicate that should occur=2C should be done by progra=
>>ms.
>>Comments that say "must match" are the signature of a compromise=2C that I =
>>made.
>>
>>
>>Similarly but less obviously how=2C Uconstants.c should be generated.
>>Given a list of symbols=2C the C code should just #ifdef foo const bar__foo=
>> =3D foo #endif tc.
>>
>>
>>Such generation should happen every time one builds.
>>=A0Not just once and check them in and hope they stay current (as many folk=
>>s are prone to=2C not necessarily present company)
>>
>>
>>=A0- Jay
>>
>>----------------------------------------
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] ADR is *too* unsafe..
>>> Date: Wed=2C 2 Jun 2010 08:37:04 -0700
>>> From: mika at async.async.caltech.edu
>>>
>>> Jay K writes:
>>>>
>>>>Cool.
>>>>
>>>>=3DA0> but also modified the front-end of the compiler to generate C
>>>>header files for Modula-3 interface files.
>>>>=3DA0> This way=3D2C procedures exported via a
>>>>Modula-3 interface can be called directly from C using "module dot method=
>>"
>>>>syntax
>>>>
>>>>
>>>>I've been wanting that. :)
>>>
>>> What do you want it to do?
>>>
>>> My Modula-Scheme system does this for Scheme already.. in fact it's
>>> probably doing something even more complicated than what you want... hmm.
>>> I've been meaning to check it in somewhere for a long time.
>>>
>>> Mika
>>>
>>>>
>>>>=3DA0> "CVAR"
>>>>
>>>>Sounds like a good small change?
>>>>
>>>>=3DA0- Jay
>>>>
>>>>
>>> ...
>> =
 		 	   		  

From hendrik at topoi.pooq.com  Fri Jun  4 01:30:22 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Thu, 3 Jun 2010 19:30:22 -0400
Subject: [M3devel] warning for uninitialized variables?
In-Reply-To: <COL101-W59770EAA64E52A966D79F3E6D00@phx.gbl>
References: <20100602035226.43C1F1A208F@async.async.caltech.edu>
	<COL101-W59770EAA64E52A966D79F3E6D00@phx.gbl>
Message-ID: <20100603233021.GA11727@topoi.pooq.com>

On Wed, Jun 02, 2010 at 04:50:28AM +0000, Jay K wrote:
> 
> Wow. You really surprise me Mika.
> 
> 
> To warn on this kind of thing, to me, there is no question.
> 
> 
> Limting the affects by virtue of being safe isn't much consolation.
> The program can easily go down a "safe" but very incorrect path.
> 
> 
> There are several forms.
> In fact, sometimes the compiler says something "is" used uninitialized.
> Sometimes it says "maybe".
> 
> 
> In your example, generally, once the address is taken of a variable,
> the compiler gives up. Esp. if that address is passed to a function it doesn't "see".
> 
> 
> However compilers are getting better.
> Windows headers are now annotated with "in" and "out", etc. with
> a calculus behind them, not just informal human definitions.
> 
> 
> So if you pass something by pointer to "in" you should a warning/error.
> If it is "out", ok.
> 
> 
> The annotations can even be checked, if you write to something that is "in"
> you should get a warning/error.
> 
> 
> There are many more warnings in the tree than I have yet looked at.
> I've seen a few forms.
> Some are because the compiler doesn't know that some functions don't return.
> I'll see about improving that. Though I think there's a limit to how good I can manage,
> unless we add a <* noreturn *> pragma.

Or a new type that has *no* values at all, and therefore can never be 
returned by anything.  If it'e the type of an expression, that 
expression can never return a value.

Notice, that if you were to let statements have a type (Algol 68 does, 
calling it the VOID type) that type would *not* be the type with no 
values at all.  The VOID type has one value, and needs log(1) = 0 bits 
to store it.

The NORETURN type would have no values, is never stored.  log(0) doesn't 
give a meaningful numper of bits, which is right.

> 
> I grant that by initializing to 0, I haven't necessarily made the code correct either.
> But at least it is now consistent.

It's very useful for code execution to ne repeatable.

> 
> 
> Even better would be runtime checks that stop if a variable is read 
> before written.

Takes extra storage, unless there are bit patterns that are known to fit 
in the available space *and* be invalid values for the type.

> 
> 
> Uninitialized values can be different run to run.
> Repeatability and consistency are important.

*VERY*

> I'm also nervous about us not taking a hard line on integer overflow.
> Overflown math doesn't necessarily lead to array out of bounds soon or ever.
> It too can lead to incorrect but safe behavior.

I agree.  But I do need a way to turn it off for specific operations so 
I get modulo results.  Perhaps also a specific type for wrap-around 
arithmetic?

-- hendrik



From hendrik at topoi.pooq.com  Fri Jun  4 01:36:14 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Thu, 3 Jun 2010 19:36:14 -0400
Subject: [M3devel] warning for uninitialized variables?
In-Reply-To: <20100602124422.11C6D1A209A@async.async.caltech.edu>
References: <20100602035226.43C1F1A208F@async.async.caltech.edu>
	<COL101-W59770EAA64E52A966D79F3E6D00@phx.gbl>
	<20100602124422.11C6D1A209A@async.async.caltech.edu>
Message-ID: <20100603233614.GB11727@topoi.pooq.com>

On Wed, Jun 02, 2010 at 05:44:22AM -0700, Mika Nystrom wrote:
> Jay K writes:
> >
> >Limting the affects by virtue of being safe isn't much consolation.
> >The program can easily go down a "safe" but very incorrect path.
> 
> It is, though!  Do you always know what value to initialize the
> variables to?  If not, you're just picking some value to shut up
> the compiler, and now your code no longer expresses---to a human
> reader---that x is uninitialized.

Not initializing it because thats your intent is OK in the cource code.
But letting the compiler initialize it to some or other value in a 
consistent manner gives the consistency that makes your code more 
rerunnable therefore more debuggable. 

> 
> Remember, code is mainly written for humans!  Computers don't care
> about fancy structuring, declarations, etc.  When you write a program,
> you write it to be read by a human.  The fact that a variable is
> uninitialized is a part of the design of the program.
> 
> It's an unfortunate fact that our languages don't have all the 
> mechanisms necessary to deal properly with uninitialized variables.
> Retrofitting mechanisms to something that just isn't expressive
> enough to solve the problem I really don't think is the way to go.

That's why I like to declare variables at the very point they are 
initialized.  If they are in scope, they are OK.  (Actually, there are 
still a very few cases where you want to declare a variable other than 
where it's initialized.  But that's quite rare).

But Modula 3 has chosen a different path, and I don't think this is 
really retrofittable.

-- hendrik


From hendrik at topoi.pooq.com  Fri Jun  4 01:41:02 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Thu, 3 Jun 2010 19:41:02 -0400
Subject: [M3devel] warning for uninitialized variables?
In-Reply-To: <COL101-W5343011FD0FA7BCC8C42AEE6D00@phx.gbl>
References: <20100602035226.43C1F1A208F@async.async.caltech.edu>
	<20100602124422.11C6D1A209A@async.async.caltech.edu>
	<COL101-W5343011FD0FA7BCC8C42AEE6D00@phx.gbl>
Message-ID: <20100603234102.GC11727@topoi.pooq.com>

On Wed, Jun 02, 2010 at 12:59:45PM +0000, Jay K wrote:
> 
> I grant that an immediate runtime error upon reading an unwritten value is ideal.

One of the variables in a cryptographic-quality random number generator 
was uninitialized.  Someone in Debian "fixed" that.  The random number 
generator was n longer of cryptographic quality.  It turns out is was 
relying on the variable being garbage.

So we still need to be able to use uninitialized stuff..  But not by 
accident.

> But absent that possibility, I want something consistent.
> Heck, here's a crazy idea: reserve the current FIRST(INTEGER) as 
> "invalid", initialize locals to it, any read (or generation/write) of 
> that value trigger a runtime error.
> CARDINAL could work this way more easily since it has many values to spare.

And if instead of a load, your machine had a load absolute value, a 
hardware overflow trap could catch the error at no additional run time.
That's a hack I planned to use for a NULL check on an IBM 360 long long 
ago.

-- hendrik


From hendrik at topoi.pooq.com  Fri Jun  4 01:51:03 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Thu, 3 Jun 2010 19:51:03 -0400
Subject: [M3devel] warning for uninitialized variables?
In-Reply-To: <COL101-W44444F6A175254747767CFE6D00@phx.gbl>
References: <16413179-F84C-42BF-AB09-2D8294EB4782@cs.purdue.edu>
	<COL101-W44444F6A175254747767CFE6D00@phx.gbl>
Message-ID: <20100603235102.GD11727@topoi.pooq.com>

On Wed, Jun 02, 2010 at 02:52:55PM +0000, Jay K wrote:
> 
> Running with a consistent initialized/uninitialized 0 is better than running with a "random" value that you get from no initialization.
> ?They are both "bad".
> ?The 0 is agreed misleading, because it might look initialized.
> ? But it still better than a value that can change from run to run.

Initializing it to cosistent gibberish won't look as initialized.  The 
University of Waterloo WATFOR compiler initialized all of memory to a 
consistent bit pattern that was *not* a printable character in the 
character set, and was *not* a valid exponent for a floating-point 
number.  It was a valid integer, though.  That much was OK, and would 
provide consistency with a high probability of misbehaviour on error.

But they went further and regularly checked for that value on reads.  It 
took time, it found errors, and it was a rare day that anyone needed 
that value.  But it did happen, and I consider the test a mistake for 
types that an validly assume all bit patterns.
> 
> Programs are written for humans to read, true, but programs that read programs are much more diligent, energetic, and often smarter (and slowly getting smarter with age, often the opposite of humans).
> Compilers really do have a big "leg" up on humans, since they can harness fast digital processor with big storage.
> Granted, neither is always better than the other. But compilers/computers have far more capacity for code reading than humans and I know from experience that most code is never read by a human, not even once, until I get to it :), because the bugs I readily see wouldn't survive even a glance...
> ?(and the compilers often fail too, granted).
> 
> 
> Again I'm quite surprised we want to leave uninitialized variables 
> that get used uninitialized.  The one in cm3ide for example, if the 
> input is malformed, I believe it uses uninitialized data.
> I don't see how this can be deemed anything other than a bug to be 
> fixed, and that we should be glad the compiler (finally) found it..now 
> that I'm working on removing the rampant volatile...
> 
> 
> If we can invest in runtime checks to immediately catch reads of 
> unwritten data, then I'd favor that instead.

The hard part is distinguishing the truly uninitialized variable from a 
variable that pappens to validly get assigned a computed bit pattern 
that just happens to be the marker for "uninitialized".

But being able to turn on such a run-time check during debugging might 
make it wasier to find a *lot* of uninitialized variables, with only anb 
occasional false positive.

-- hendrik


From jay.krell at cornell.edu  Fri Jun  4 01:47:00 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 3 Jun 2010 23:47:00 +0000
Subject: [M3devel] warning for uninitialized variables?
In-Reply-To: <20100603233614.GB11727@topoi.pooq.com>
References: <20100602035226.43C1F1A208F@async.async.caltech.edu>,
	<COL101-W59770EAA64E52A966D79F3E6D00@phx.gbl>,
	<20100602124422.11C6D1A209A@async.async.caltech.edu>,
	<20100603233614.GB11727@topoi.pooq.com>
Message-ID: <COL101-W2394F109BD07DCB14C61EBE6D10@phx.gbl>


Declare at initialization is good.
  Exactly what C++ supports and it is considered completely uncontroversial and maybe C9x even supports it.
 
 
Modula-3 supports it, both with "WITH..DO" and "VAR..BEGIN" but at too high a syntactic cost -- having to indent for each new block of variables, or to use begin/end without indenting.
 
 
Heck, C supports the same thing -- you can introduce braces anywhere, and then variables after any left brace.
 
 
I would rather move all my variables to the top of the function and initialize them with 0 than to indent every time I want a new variable. Really. I have learned to accept much about Modula-3's syntax, but not this.
 
 
 
 - Jay


----------------------------------------
> Date: Thu, 3 Jun 2010 19:36:14 -0400
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] warning for uninitialized variables?
>
> On Wed, Jun 02, 2010 at 05:44:22AM -0700, Mika Nystrom wrote:
>> Jay K writes:
>>>
>>>Limting the affects by virtue of being safe isn't much consolation.
>>>The program can easily go down a "safe" but very incorrect path.
>>
>> It is, though! Do you always know what value to initialize the
>> variables to? If not, you're just picking some value to shut up
>> the compiler, and now your code no longer expresses---to a human
>> reader---that x is uninitialized.
>
> Not initializing it because thats your intent is OK in the cource code.
> But letting the compiler initialize it to some or other value in a
> consistent manner gives the consistency that makes your code more
> rerunnable therefore more debuggable.
>
>>
>> Remember, code is mainly written for humans! Computers don't care
>> about fancy structuring, declarations, etc. When you write a program,
>> you write it to be read by a human. The fact that a variable is
>> uninitialized is a part of the design of the program.
>>
>> It's an unfortunate fact that our languages don't have all the
>> mechanisms necessary to deal properly with uninitialized variables.
>> Retrofitting mechanisms to something that just isn't expressive
>> enough to solve the problem I really don't think is the way to go.
>
> That's why I like to declare variables at the very point they are
> initialized. If they are in scope, they are OK. (Actually, there are
> still a very few cases where you want to declare a variable other than
> where it's initialized. But that's quite rare).
>
> But Modula 3 has chosen a different path, and I don't think this is
> really retrofittable.
>
> -- hendrik 		 	   		  

From hendrik at topoi.pooq.com  Fri Jun  4 01:54:55 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Thu, 3 Jun 2010 19:54:55 -0400
Subject: [M3devel] warning for uninitialized variables?
In-Reply-To: <COL101-W40BE08A256108863A44C5FE6D00@phx.gbl>
References: <5EDDD7E5-C33E-4BD1-A036-2D3561F08277@cs.purdue.edu>
	<COL101-W40BE08A256108863A44C5FE6D00@phx.gbl>
Message-ID: <20100603235455.GE11727@topoi.pooq.com>

On Wed, Jun 02, 2010 at 03:13:55PM +0000, Jay K wrote:
> 
> Well, I'm certainly not lobbying hard for that, presumably there is no efficient implementation, esp. for full range integers.
> 
> Wikipedia has a nice article. "nice" means "agrees with me".
> 
> 
> http://en.wikipedia.org/wiki/Uninitialized_variable
> "it is a programming error and a common source of bugs in software."
> 
> 
> And then they point out how Java requires mechanically verified initialization of locals.
> 
> The code:
> void F(bool a)
> ?int i;
> ?if (a)
> ?? i = 0;
> if (a)
> ? print(i)
> 
> 
> is I believe illegal.

But it's *not* illegal in Modula 3.  You can't prohibit it without 
making a serious language change. However much we might desire to.

-- hendrik


From jay.krell at cornell.edu  Fri Jun  4 01:59:01 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 3 Jun 2010 23:59:01 +0000
Subject: [M3devel] warning for uninitialized variables?
In-Reply-To: <20100603233021.GA11727@topoi.pooq.com>
References: <20100602035226.43C1F1A208F@async.async.caltech.edu>,
	<COL101-W59770EAA64E52A966D79F3E6D00@phx.gbl>,
	<20100603233021.GA11727@topoi.pooq.com>
Message-ID: <COL101-W62E2D97D9F353F3DACDC1AE6D10@phx.gbl>


> The NORETURN type would have no values 
 
 
Everyone else seems to do with pragma-ish things.
I don't know what is best.
Visual C++ has __declspec(noreturn).
gcc has __attribute__((noreturn)) or somesuch. Maybe it is named something else.
Visual C++ puts a breakpoint instruction after any call to a noreturn function.
abort() for example is noreturn.
 
 
 
>> I'm also nervous about us not taking a hard line on integer overflow. 
> I agree. But I do need a way to turn it off for specific operations so 
> Perhaps also a specific type for wrap-around arithmetic? 
 
 
Yes. Or a new module.
And I believe a bunch more is needed in general.
  Signed and unsigned.
  And overflow should do one:
    return an "error" code (boolean? true for success? or true for overflow? Booleans can be so ambiguous..) 
    raise an exception 
    silently wraparound 
 
 
 
I have to look into Modula-3 generics.
Ideally this can be implemented with generics and not actually writing all N combinations.
And without any "runtime switching".
 
 
For example, the generic parameters would be
  "Word"
  "Error"
 
 
 
Word would look like Word.
Except all the functions would probably return BOOLEAN to indicate overflow.
  Even if that isn't the actual "error code".
 
 
Error would expose type T that the actual implementation would return.
Oh, wait, no, Modula-3 can't do that -- there is no "VOID" type.
 
 
So..instead.. decide what the "error code" form is -- probably returning FALSE.
The Error module would expose one function, OnError.
 
 
The main code when it recieves false from "Word" would call Error.OnError.
There'd be two Error's versions. In one, OnError would do nothing. In the other, it would raise an exception.
 
 
Hm.
If Modula-3 didn't have this pesky "eval" thing, you'd be done.
Silent wraparound would be calling the "OnError donothing" form, but you'd just ignore the error.
 
 
This is unfortunate I think.
 
 
Btw, C++ folks eventually realized you need to be able to write code like this:
 
PROCEDURE F1();
 
PROCEDURE F2() = 
BEGIN
  RETURN F1();
END F1;
 
 
for reasons related to templates/generics.
You need to be able to return the result of a function you call, without knowing the return type, and the return type possibly being void. The need for this feature is obvious once you spend a few days using templates/generics.
 
 
Anyway, for silent overflow you'd have to layer over the bool version, just prepending eval.
Something like that.
 
 
The lowest level implementation probably returns bool.
 
 
The Error module could also expose a type ErrorType and some constants like OverflowError and NoError.
 
 
Maybe I'll code this up soon in pure Modula-3.
 
 
Where/who/when are the interface police?
We can add stuff to m3core or libm3 at will? As long as don't extend or change stuff in the green book?
 
 
 - Jay


----------------------------------------
> Date: Thu, 3 Jun 2010 19:30:22 -0400
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] warning for uninitialized variables?
>
> On Wed, Jun 02, 2010 at 04:50:28AM +0000, Jay K wrote:
>>
>> Wow. You really surprise me Mika.
>>
>>
>> To warn on this kind of thing, to me, there is no question.
>>
>>
>> Limting the affects by virtue of being safe isn't much consolation.
>> The program can easily go down a "safe" but very incorrect path.
>>
>>
>> There are several forms.
>> In fact, sometimes the compiler says something "is" used uninitialized.
>> Sometimes it says "maybe".
>>
>>
>> In your example, generally, once the address is taken of a variable,
>> the compiler gives up. Esp. if that address is passed to a function it doesn't "see".
>>
>>
>> However compilers are getting better.
>> Windows headers are now annotated with "in" and "out", etc. with
>> a calculus behind them, not just informal human definitions.
>>
>>
>> So if you pass something by pointer to "in" you should a warning/error.
>> If it is "out", ok.
>>
>>
>> The annotations can even be checked, if you write to something that is "in"
>> you should get a warning/error.
>>
>>
>> There are many more warnings in the tree than I have yet looked at.
>> I've seen a few forms.
>> Some are because the compiler doesn't know that some functions don't return.
>> I'll see about improving that. Though I think there's a limit to how good I can manage,
>> unless we add a <* noreturn *> pragma.
>
> Or a new type that has *no* values at all, and therefore can never be
> returned by anything. If it'e the type of an expression, that
> expression can never return a value.
>
> Notice, that if you were to let statements have a type (Algol 68 does,
> calling it the VOID type) that type would *not* be the type with no
> values at all. The VOID type has one value, and needs log(1) = 0 bits
> to store it.
>
> The NORETURN type would have no values, is never stored. log(0) doesn't
> give a meaningful numper of bits, which is right.
>
>>
>> I grant that by initializing to 0, I haven't necessarily made the code correct either.
>> But at least it is now consistent.
>
> It's very useful for code execution to ne repeatable.
>
>>
>>
>> Even better would be runtime checks that stop if a variable is read
>> before written.
>
> Takes extra storage, unless there are bit patterns that are known to fit
> in the available space *and* be invalid values for the type.
>
>>
>>
>> Uninitialized values can be different run to run.
>> Repeatability and consistency are important.
>
> *VERY*
>
>> I'm also nervous about us not taking a hard line on integer overflow.
>> Overflown math doesn't necessarily lead to array out of bounds soon or ever.
>> It too can lead to incorrect but safe behavior.
>
> I agree. But I do need a way to turn it off for specific operations so
> I get modulo results. Perhaps also a specific type for wrap-around
> arithmetic?
>
> -- hendrik
> 		 	   		  

From jay.krell at cornell.edu  Fri Jun  4 02:14:14 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 4 Jun 2010 00:14:14 +0000
Subject: [M3devel] warning for uninitialized variables?
In-Reply-To: <20100603235102.GD11727@topoi.pooq.com>
References: <16413179-F84C-42BF-AB09-2D8294EB4782@cs.purdue.edu>,
	<COL101-W44444F6A175254747767CFE6D00@phx.gbl>,
	<20100603235102.GD11727@topoi.pooq.com>
Message-ID: <COL101-W58390B33633452C34384DDE6D20@phx.gbl>


Search the web for "visual C++ /rtc".
 
You'll find that Visual C++ has the ideal feature here, not enabled by default. Not efficient.
 
If you compile with /RTCu:
  an extra byte local is created for each local variable 
  It is initialized to zero.
  Writes to the variable write 1 to the extra. (taking the address does to, the documentation spends a lot of space explaining) 
  Reads of the variable check if the extra is 0 or not and if it 0 a function is called to report the error.
 
 
It's pretty cool imho.
 
 
And it appears if the compiler can prove the variable isn't initialized, the checking is omitted.
Given decent code, that should make it very affordable to always be enabled.
 
 
 - Jay


----------------------------------------
> Date: Thu, 3 Jun 2010 19:51:03 -0400
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] warning for uninitialized variables?
>
> On Wed, Jun 02, 2010 at 02:52:55PM +0000, Jay K wrote:
>>
>> Running with a consistent initialized/uninitialized 0 is better than running with a "random" value that you get from no initialization.
>> They are both "bad".
>> The 0 is agreed misleading, because it might look initialized.
>> But it still better than a value that can change from run to run.
>
> Initializing it to cosistent gibberish won't look as initialized. The
> University of Waterloo WATFOR compiler initialized all of memory to a
> consistent bit pattern that was *not* a printable character in the
> character set, and was *not* a valid exponent for a floating-point
> number. It was a valid integer, though. That much was OK, and would
> provide consistency with a high probability of misbehaviour on error.
>
> But they went further and regularly checked for that value on reads. It
> took time, it found errors, and it was a rare day that anyone needed
> that value. But it did happen, and I consider the test a mistake for
> types that an validly assume all bit patterns.
>>
>> Programs are written for humans to read, true, but programs that read programs are much more diligent, energetic, and often smarter (and slowly getting smarter with age, often the opposite of humans).
>> Compilers really do have a big "leg" up on humans, since they can harness fast digital processor with big storage.
>> Granted, neither is always better than the other. But compilers/computers have far more capacity for code reading than humans and I know from experience that most code is never read by a human, not even once, until I get to it :), because the bugs I readily see wouldn't survive even a glance...
>> (and the compilers often fail too, granted).
>>
>>
>> Again I'm quite surprised we want to leave uninitialized variables
>> that get used uninitialized. The one in cm3ide for example, if the
>> input is malformed, I believe it uses uninitialized data.
>> I don't see how this can be deemed anything other than a bug to be
>> fixed, and that we should be glad the compiler (finally) found it..now
>> that I'm working on removing the rampant volatile...
>>
>>
>> If we can invest in runtime checks to immediately catch reads of
>> unwritten data, then I'd favor that instead.
>
> The hard part is distinguishing the truly uninitialized variable from a
> variable that pappens to validly get assigned a computed bit pattern
> that just happens to be the marker for "uninitialized".
>
> But being able to turn on such a run-time check during debugging might
> make it wasier to find a *lot* of uninitialized variables, with only anb
> occasional false positive.
>
> -- hendrik 		 	   		  

From jay.krell at cornell.edu  Fri Jun  4 18:29:34 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 4 Jun 2010 16:29:34 +0000
Subject: [M3devel] optimizer problems
Message-ID: <COL101-W915873EEE558B40A8F280E6D20@phx.gbl>


Just a note that I have found at least two pieces of code that fail to compile with optimization enabled, even in the release branch.

One is a simple case involving unused nested functions.
One is a complicated not really understood case.


To fix these I have pessimized the optimizer in the release branch but turning off two optimizations.


It would be nice to find a better fix for the first.
Even something sleazy like having the front end report up front to the backend if there are any nested functions in the unit, and only pessimizing such units.
There is probably also a fix to gcc around preserving nested functions. I thought code in varasm.c was suspicious but couldn't get it to work quickly.


The other fix seems to always involve exception handling, so something sleazy might be appropriate there -- only turn off the optimization in units that use exception handling. Longer term, we should use the gcc exception handling support if possible, even if that involves configure -enable-sjlj-exceptions (presumably not on all targets).

?- Jay


 		 	   		  

From hosking at cs.purdue.edu  Fri Jun  4 18:37:45 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 4 Jun 2010 12:37:45 -0400
Subject: [M3devel] optimizer problems
In-Reply-To: <COL101-W915873EEE558B40A8F280E6D20@phx.gbl>
References: <COL101-W915873EEE558B40A8F280E6D20@phx.gbl>
Message-ID: <282D3F06-9C5A-4525-B1D0-77E59B12D833@cs.purdue.edu>

You should be able to mark it as used.

On 4 Jun 2010, at 12:29, Jay K wrote:

> 
> Just a note that I have found at least two pieces of code that fail to compile with optimization enabled, even in the release branch.
> 
> One is a simple case involving unused nested functions.
> One is a complicated not really understood case.
> 
> 
> To fix these I have pessimized the optimizer in the release branch but turning off two optimizations.
> 
> 
> It would be nice to find a better fix for the first.
> Even something sleazy like having the front end report up front to the backend if there are any nested functions in the unit, and only pessimizing such units.
> There is probably also a fix to gcc around preserving nested functions. I thought code in varasm.c was suspicious but couldn't get it to work quickly.



From jay.krell at cornell.edu  Fri Jun  4 19:06:25 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 4 Jun 2010 17:06:25 +0000
Subject: [M3devel] optimizer problems
In-Reply-To: <282D3F06-9C5A-4525-B1D0-77E59B12D833@cs.purdue.edu>
References: <COL101-W915873EEE558B40A8F280E6D20@phx.gbl>,
	<282D3F06-9C5A-4525-B1D0-77E59B12D833@cs.purdue.edu>
Message-ID: <COL101-W5966EA54CF4DA49BC6D74E6D20@phx.gbl>


I already tried that.. :(
 
 
 - Jay


----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Fri, 4 Jun 2010 12:37:45 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] optimizer problems
>
> You should be able to mark it as used.
>
> On 4 Jun 2010, at 12:29, Jay K wrote:
>
>>
>> Just a note that I have found at least two pieces of code that fail to compile with optimization enabled, even in the release branch.
>>
>> One is a simple case involving unused nested functions.
>> One is a complicated not really understood case.
>>
>>
>> To fix these I have pessimized the optimizer in the release branch but turning off two optimizations.
>>
>>
>> It would be nice to find a better fix for the first.
>> Even something sleazy like having the front end report up front to the backend if there are any nested functions in the unit, and only pessimizing such units.
>> There is probably also a fix to gcc around preserving nested functions. I thought code in varasm.c was suspicious but couldn't get it to work quickly.
> 		 	   		  

From hosking at cs.purdue.edu  Fri Jun  4 19:56:44 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 4 Jun 2010 13:56:44 -0400
Subject: [M3devel] optimizer problems
In-Reply-To: <COL101-W5966EA54CF4DA49BC6D74E6D20@phx.gbl>
References: <COL101-W915873EEE558B40A8F280E6D20@phx.gbl>,
	<282D3F06-9C5A-4525-B1D0-77E59B12D833@cs.purdue.edu>
	<COL101-W5966EA54CF4DA49BC6D74E6D20@phx.gbl>
Message-ID: <1B0AB99B-837F-464E-9BE7-140DAEB59E5E@cs.purdue.edu>

Or "external".  I assume it is getting dead code eliminated.

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




On 4 Jun 2010, at 13:06, Jay K wrote:

> 
> I already tried that.. :(
> 
> 
> - Jay
> 
> 
> ----------------------------------------
>> From: hosking at cs.purdue.edu
>> Date: Fri, 4 Jun 2010 12:37:45 -0400
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] optimizer problems
>> 
>> You should be able to mark it as used.
>> 
>> On 4 Jun 2010, at 12:29, Jay K wrote:
>> 
>>> 
>>> Just a note that I have found at least two pieces of code that fail to compile with optimization enabled, even in the release branch.
>>> 
>>> One is a simple case involving unused nested functions.
>>> One is a complicated not really understood case.
>>> 
>>> 
>>> To fix these I have pessimized the optimizer in the release branch but turning off two optimizations.
>>> 
>>> 
>>> It would be nice to find a better fix for the first.
>>> Even something sleazy like having the front end report up front to the backend if there are any nested functions in the unit, and only pessimizing such units.
>>> There is probably also a fix to gcc around preserving nested functions. I thought code in varasm.c was suspicious but couldn't get it to work quickly.
>> 		 	   		  

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

From jay.krell at cornell.edu  Fri Jun  4 21:55:30 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 4 Jun 2010 19:55:30 +0000
Subject: [M3devel] optimizer problems
In-Reply-To: <1B0AB99B-837F-464E-9BE7-140DAEB59E5E@cs.purdue.edu>
References: <COL101-W915873EEE558B40A8F280E6D20@phx.gbl>, ,
	<282D3F06-9C5A-4525-B1D0-77E59B12D833@cs.purdue.edu>,
	<COL101-W5966EA54CF4DA49BC6D74E6D20@phx.gbl>,
	<1B0AB99B-837F-464E-9BE7-140DAEB59E5E@cs.purdue.edu>
Message-ID: <COL101-W57AFCFC65554B7DD84A092E6D20@phx.gbl>


I will experiment more.
I don't remember if I tried as much as "exported", which is clearly wrong, but it'd be interesting to see if *some* way can preserve it. Should also be easy to find the code that removes it.
 
 
 
I have more questions..not well formed..not having researched a lot..so have held off..but..like..what is it about our trees? What is it you refer to as the missing type information and the problems with alias analysis? I understand to some extent. But we do actually mostly seem to build reasonable and reasonably typed trees.
Granted, I haven't compared to C trees.
I guess using the various dump option for C trees and our trees would be good.
 
 
 
I think one place we fail is access globals, and indeed accessing structs.
We just offset from them I think, instead of accessing fields.
Is that what you mean??
 
 
For "scalar" locals and globals, our trees seem ok, right?
 
 
 
As I aid, I should just use more of the gcc dump options and compare.
 
 
TYPE T1 = RECORD a,b:INTEGER END;
 
global:T1{3,4};
 
PROCEDURE F1() =
VAR local:T1{1,2};
BEGIN
  local.a := global.b;
  globa.a := local.b;
END;
 
 
typedef struct {ptrdiff_t a,b;}T1;
T1 global = {3,4};
 
void F1()
{
  T1 local = {1,2};
  local.a = global.b;
  global.a = local.b;
}
 
 
I should probably compile each of these and dump their "generic" trees and compare?
And strive to have them match?
 
 
More importantly though is loophole and float.
 
 
TYPE T1 = RECORD a,b:int END;
TYPE T2 = RECORD a,b:float END;
 
 
global:T1{3,4};
 
 
PROCEDURE F1() =
VAR local:T2{0.0,0.0;
BEGIN
  LOOPHOLE(local, T1).a := global.b;
  LOOPHOLE(global, T2).a := local.b;
END;
 
 
typedef struct {int a,b;}T1;
typedef struct {float a,b;}T2;
T1 global = {3,4};
 
 
void F1()
{
  T2 local = {0,0};
  ((T1*)&local)->a = global.b;
  ((T2*)&global)->a = local.b;
}
 
 
stuff like that?
Get those C and Modula-3 trees to match?
 
 
I assume as part of this, if it seems "necessary" to add volatile store/load to all loophole uses,
in order to remove volatile from floats, that is probably an ok compromise.
Even when loophole is acting on non-floats.
Maybe the problem is loophole and structs though. That seems likely.
Ideally loopholing between integers and pointers doesn't require store/load, as it currently doesn't.
 
 
Again, really, though I've removed a lot of volatile, I'm still quite bothered, since I still put it on every floating point use.
 
 
The vrp/fre/pre stuff I think will be more difficult, but maybe I can figure those out.
vrp I just know results in a broken compiler. I haven't looked at it beyond that.
I guess the thing to do is compile some chunk of code, e.g. m3core, with vrp being the only variable, and see what varies, and go from there.
 
 
Given how much optimization does work now, I doubt the effort is very worthwhile on the lingering view I disabled, except, again, for unit at a time and volatile float. We'll see..
 
 
I was doing kind of dumb slow unscientific work before. There are many optimization flags and I wanted to narrow them down more than one at a time, so I'd guess, switch a few on, upgrade, if it worked proceed, if it failed, alter the guess some.
 
 
And there's still Solaris/sparc32 to do similar with..
Should be more automated but my current methods are quite tedious.. :(
 
 
 
 - Jay











________________________________
> From: hosking at cs.purdue.edu
> Date: Fri, 4 Jun 2010 13:56:44 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] optimizer problems
>
>
>
> Or "external". I assume it is getting dead code eliminated.
>
>
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
>
>
>
>
>
>
> On 4 Jun 2010, at 13:06, Jay K wrote:
>
>
> I already tried that.. :(
>
>
> - Jay
>
>
> ----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Fri, 4 Jun 2010 12:37:45 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] optimizer problems
>
> You should be able to mark it as used.
>
> On 4 Jun 2010, at 12:29, Jay K wrote:
>
>
> Just a note that I have found at least two pieces of code that fail to compile with optimization enabled, even in the release branch.
>
> One is a simple case involving unused nested functions.
> One is a complicated not really understood case.
>
>
> To fix these I have pessimized the optimizer in the release branch but turning off two optimizations.
>
>
> It would be nice to find a better fix for the first.
> Even something sleazy like having the front end report up front to the backend if there are any nested functions in the unit, and only pessimizing such units.
> There is probably also a fix to gcc around preserving nested functions. I thought code in varasm.c was suspicious but couldn't get it to work quickly.
>
> 		 	   		  

From jay.krell at cornell.edu  Sat Jun  5 21:23:24 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 5 Jun 2010 19:23:24 +0000
Subject: [M3devel] cvs down?
Message-ID: <COL101-W60FFAA82EE18F721A82159E6D30@phx.gbl>


My last commit didn't send mail.
cvs diff and update aren't working.

?- Jay




 		 	   		  

From jay.krell at cornell.edu  Sat Jun  5 22:52:34 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 5 Jun 2010 20:52:34 +0000
Subject: [M3devel] further removal of volatile
Message-ID: <COL101-W4299A2A8F51F83263BDF87E6D30@phx.gbl>


Tony, Currently we still put volatile on all floating point loads and/or stores.
I removed it from all the other types.
The main problem I was having is that CopySign in m3core would fail to compile.
?It is loophoing a float as a struct with bitfields I believe.
? I didn't look at what the equivalent C tree would be, though that is probably a good idea.


With this it seems I don't need the volatile:


static void
m3_load_1 (tree v, int o, tree src_t, m3_type src_T, tree dst_t, m3_type dst_T,
?????????? bool volatil)
{
? if (o != 0 || TREE_TYPE (v) != src_t)
? {
??? if (GCC42 || (src_T != dst_T))?? <<< 
??? {
????? /* failsafe, but inefficient */
????? v = m3_build1 (ADDR_EXPR, t_addr, v);
????? v = m3_build2 (PLUS_EXPR, t_addr, v, size_int (o / BITS_PER_UNIT));
????? v = m3_build1 (INDIRECT_REF, src_t,
????? m3_cast (m3_build_pointer_type (src_t), v));
??? }
??? else
??? {
????? v = m3_build3 (BIT_FIELD_REF, src_t, v, TYPE_SIZE (src_t),
???????????????????? bitsize_int (o));
??? }
? }
?...



static void
m3_store_1 (tree v, int o, tree src_t, m3_type src_T, tree dst_t, m3_type dst_T,
??????????? bool volatil)
{
? tree val;
? if (o != 0 || TREE_TYPE (v) != dst_t)
? {
??? if (GCC42 || (src_T != dst_T))?? <<<< 
??? {
????? /* failsafe, but inefficient */
????? v = m3_build1 (ADDR_EXPR, t_addr, v);
????? v = m3_build2 (PLUS_EXPR, t_addr, v, size_int (o / BITS_PER_UNIT));
????? v = m3_build1 (INDIRECT_REF, dst_t,
???????????????????? m3_cast (m3_build_pointer_type (dst_t), v));
??? }
??? else
??? {
????? v = m3_build3 (BIT_FIELD_REF, dst_t, v, TYPE_SIZE (dst_t),
???????????????????? bitsize_int (o));
??? }
? }..

Previously, the code was the equivalent of saying if GCC42 there.


Good enough?


You know, this bitfield stuff has been a recurring problem.

I could probably narrow it down more.
? Like maybe if the types are the same size or both integers, still go down the old faster path.
??? Though I thought I had tried if they were either float going slow and that didn't work.
???? It might relate to structs as well.


However inefficient the non-bitfield ref path is, I can hope/assume it isn't as bad now without volatile.
But I could look a bit at the code.


?- Jay
 		 	   		  

From hosking at cs.purdue.edu  Sat Jun  5 23:46:00 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 5 Jun 2010 17:46:00 -0400
Subject: [M3devel] further removal of volatile
In-Reply-To: <COL101-W4299A2A8F51F83263BDF87E6D30@phx.gbl>
References: <COL101-W4299A2A8F51F83263BDF87E6D30@phx.gbl>
Message-ID: <37F7DB2D-2415-425D-BD64-3811174969C4@cs.purdue.edu>

But what sort of code do you get not using the BIT_FIELD_REF?


On 5 Jun 2010, at 16:52, Jay K wrote:

> 
> Tony, Currently we still put volatile on all floating point loads and/or stores.
> I removed it from all the other types.
> The main problem I was having is that CopySign in m3core would fail to compile.
>  It is loophoing a float as a struct with bitfields I believe.
>   I didn't look at what the equivalent C tree would be, though that is probably a good idea.
> 
> 
> With this it seems I don't need the volatile:
> 
> 
> static void
> m3_load_1 (tree v, int o, tree src_t, m3_type src_T, tree dst_t, m3_type dst_T,
>            bool volatil)
> {
>   if (o != 0 || TREE_TYPE (v) != src_t)
>   {
>     if (GCC42 || (src_T != dst_T))   <<< 
>     {
>       /* failsafe, but inefficient */
>       v = m3_build1 (ADDR_EXPR, t_addr, v);
>       v = m3_build2 (PLUS_EXPR, t_addr, v, size_int (o / BITS_PER_UNIT));
>       v = m3_build1 (INDIRECT_REF, src_t,
>       m3_cast (m3_build_pointer_type (src_t), v));
>     }
>     else
>     {
>       v = m3_build3 (BIT_FIELD_REF, src_t, v, TYPE_SIZE (src_t),
>                      bitsize_int (o));
>     }
>   }
>  ...
> 
> 
> 
> static void
> m3_store_1 (tree v, int o, tree src_t, m3_type src_T, tree dst_t, m3_type dst_T,
>             bool volatil)
> {
>   tree val;
>   if (o != 0 || TREE_TYPE (v) != dst_t)
>   {
>     if (GCC42 || (src_T != dst_T))   <<<< 
>     {
>       /* failsafe, but inefficient */
>       v = m3_build1 (ADDR_EXPR, t_addr, v);
>       v = m3_build2 (PLUS_EXPR, t_addr, v, size_int (o / BITS_PER_UNIT));
>       v = m3_build1 (INDIRECT_REF, dst_t,
>                      m3_cast (m3_build_pointer_type (dst_t), v));
>     }
>     else
>     {
>       v = m3_build3 (BIT_FIELD_REF, dst_t, v, TYPE_SIZE (dst_t),
>                      bitsize_int (o));
>     }
>   }..
> 
> Previously, the code was the equivalent of saying if GCC42 there.
> 
> 
> Good enough?
> 
> 
> You know, this bitfield stuff has been a recurring problem.
> 
> I could probably narrow it down more.
>   Like maybe if the types are the same size or both integers, still go down the old faster path.
>     Though I thought I had tried if they were either float going slow and that didn't work.
>      It might relate to structs as well.
> 
> 
> However inefficient the non-bitfield ref path is, I can hope/assume it isn't as bad now without volatile.
> But I could look a bit at the code.
> 
> 
>  - Jay
> 		 	   		  



From jay.krell at cornell.edu  Sun Jun  6 00:16:49 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 5 Jun 2010 22:16:49 +0000
Subject: [M3devel] further removal of volatile
In-Reply-To: <37F7DB2D-2415-425D-BD64-3811174969C4@cs.purdue.edu>
References: <COL101-W4299A2A8F51F83263BDF87E6D30@phx.gbl>,
	<37F7DB2D-2415-425D-BD64-3811174969C4@cs.purdue.edu>
Message-ID: <COL101-W49F94907D04D32B1EF7421E6D30@phx.gbl>


I didn't look...but darn..one problem seemingly present here:

/Users/jay/dev2/cm3/caltech-parser/parserlib/klex/AMD64_DARWIN/klex ../src/Calc.l -o CalcLex.i3 -t ../src/Calc.t -ti3 CalcTok.i3


***
*** runtime error:
***??? Segmentation violation - possible attempt to dereference NIL
***??? pc = 0x100012fa7 = Output + 0x17 in ../src/NFA.m3
***

"/cm3.amd64/pkg/cit_util/src/generics.tmpl", line 38: quake runtime error: exit 1536: /Users/jay/dev2/cm3/caltech-parser/parserlib/klex/AMD64_DARWIN/klex ../src/Calc.l -o CalcLex.i3 -t ../src/Calc.t -ti3 CalcTok.i3

ugh.

Later..
?- Jay


----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Sat, 5 Jun 2010 17:46:00 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] further removal of volatile
>
> But what sort of code do you get not using the BIT_FIELD_REF?
>
>
> On 5 Jun 2010, at 16:52, Jay K wrote:
>
>>
>> Tony, Currently we still put volatile on all floating point loads and/or stores.
>> I removed it from all the other types.
>> The main problem I was having is that CopySign in m3core would fail to compile.
>> It is loophoing a float as a struct with bitfields I believe.
>> I didn't look at what the equivalent C tree would be, though that is probably a good idea.
>>
>>
>> With this it seems I don't need the volatile:
>>
>>
>> static void
>> m3_load_1 (tree v, int o, tree src_t, m3_type src_T, tree dst_t, m3_type dst_T,
>> bool volatil)
>> {
>> if (o != 0 || TREE_TYPE (v) != src_t)
>> {
>> if (GCC42 || (src_T != dst_T)) <<<
>> {
>> /* failsafe, but inefficient */
>> v = m3_build1 (ADDR_EXPR, t_addr, v);
>> v = m3_build2 (PLUS_EXPR, t_addr, v, size_int (o / BITS_PER_UNIT));
>> v = m3_build1 (INDIRECT_REF, src_t,
>> m3_cast (m3_build_pointer_type (src_t), v));
>> }
>> else
>> {
>> v = m3_build3 (BIT_FIELD_REF, src_t, v, TYPE_SIZE (src_t),
>> bitsize_int (o));
>> }
>> }
>> ...
>>
>>
>>
>> static void
>> m3_store_1 (tree v, int o, tree src_t, m3_type src_T, tree dst_t, m3_type dst_T,
>> bool volatil)
>> {
>> tree val;
>> if (o != 0 || TREE_TYPE (v) != dst_t)
>> {
>> if (GCC42 || (src_T != dst_T)) <<<<
>> {
>> /* failsafe, but inefficient */
>> v = m3_build1 (ADDR_EXPR, t_addr, v);
>> v = m3_build2 (PLUS_EXPR, t_addr, v, size_int (o / BITS_PER_UNIT));
>> v = m3_build1 (INDIRECT_REF, dst_t,
>> m3_cast (m3_build_pointer_type (dst_t), v));
>> }
>> else
>> {
>> v = m3_build3 (BIT_FIELD_REF, dst_t, v, TYPE_SIZE (dst_t),
>> bitsize_int (o));
>> }
>> }..
>>
>> Previously, the code was the equivalent of saying if GCC42 there.
>>
>>
>> Good enough?
>>
>>
>> You know, this bitfield stuff has been a recurring problem.
>>
>> I could probably narrow it down more.
>> Like maybe if the types are the same size or both integers, still go down the old faster path.
>> Though I thought I had tried if they were either float going slow and that didn't work.
>> It might relate to structs as well.
>>
>>
>> However inefficient the non-bitfield ref path is, I can hope/assume it isn't as bad now without volatile.
>> But I could look a bit at the code.
>>
>>
>> - Jay
>>
>
 		 	   		  

From jay.krell at cornell.edu  Sun Jun  6 02:53:52 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 6 Jun 2010 00:53:52 +0000
Subject: [M3devel] cvs down?
Message-ID: <COL101-W4496C59304ACFEC817DC7BE6D40@phx.gbl>


It is back.

----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Subject: cvs down?
> Date: Sat, 5 Jun 2010 19:23:24 +0000
>
>
> My last commit didn't send mail.
> cvs diff and update aren't working.
>
>  - Jay
 		 	   		  

From jay.krell at cornell.edu  Wed Jun  9 09:07:18 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 9 Jun 2010 07:07:18 +0000
Subject: [M3devel] maybe volatile is "good"?
Message-ID: <COL101-W117095721973381CF1CEA6E6D70@phx.gbl>


A friend was asking about the portability of the system, and the "ptrdiff_t problem" -- where the optimizer might generate code whereby pointers exist but aren't evident in any registers or on the stack, because instead some pointer difference is being applied. I can't describe this well, but I know what he was referring to. A posting by David Chase mentions it. The result is that the garbage collector doesn't realize something is live and prematurely frees it, or moves it and doesn't update references...ok here is the link:

http://compilers.iecc.com/comparch/article/90-08-046

"...Worse things can happen; in some situations, it

may profit to use &a[-100] to reference elements of a, or to use

&b[0]-&a[0] to generate references to b"

So, this makes me nervous about my recent removal of making all loads and stores volatile.

Maybe best to put them back?

I know the optimized codegen was terrible, but..

?- Jay




 		 	   		  

From hosking at cs.purdue.edu  Wed Jun  9 14:13:21 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 9 Jun 2010 08:13:21 -0400
Subject: [M3devel] maybe volatile is "good"?
In-Reply-To: <COL101-W117095721973381CF1CEA6E6D70@phx.gbl>
References: <COL101-W117095721973381CF1CEA6E6D70@phx.gbl>
Message-ID: <FF22799E-E5D2-4C69-82E9-2EA35EEF3954@cs.purdue.edu>

This is not a problem.   gcc doesn't perform these optimisations, as far as I know.

On 9 Jun 2010, at 03:07, Jay K wrote:

> 
> A friend was asking about the portability of the system, and the "ptrdiff_t problem" -- where the optimizer might generate code whereby pointers exist but aren't evident in any registers or on the stack, because instead some pointer difference is being applied. I can't describe this well, but I know what he was referring to. A posting by David Chase mentions it. The result is that the garbage collector doesn't realize something is live and prematurely frees it, or moves it and doesn't update references...ok here is the link:
> 
> http://compilers.iecc.com/comparch/article/90-08-046
> 
> "...Worse things can happen; in some situations, it
> 
> may profit to use &a[-100] to reference elements of a, or to use
> 
> &b[0]-&a[0] to generate references to b"
> 
> So, this makes me nervous about my recent removal of making all loads and stores volatile.
> 
> Maybe best to put them back?
> 
> I know the optimized codegen was terrible, but..
> 
>  - Jay
> 
> 
> 
> 
> 		 	   		  



From jay.krell at cornell.edu  Sat Jun 12 17:11:42 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 12 Jun 2010 15:11:42 +0000
Subject: [M3devel] size vs. speed set_member / set_singleton serialized on
	NT386
Message-ID: <COL101-W447DCAFDF282BFB9A659D7E6DA0@phx.gbl>


We used to have (still in release branch):

m3-libs/m3core/src/Csupport/Common/parse.c:

void __cdecl set_singleton
??? ANSI((????? long a, ulong* s))
????? KR((a, s) long a; ulong* s;)
{
? long a_word = a / SET_GRAIN;
? long a_bit? = a % SET_GRAIN;
? s[a_word] |= (1UL << a_bit);
}


long __cdecl set_member
??? ANSI((????????? long elt, ulong* set))
????? KR((elt, set) long elt; ulong* set;)
{
? register long word = elt / SET_GRAIN;
? register long bit? = elt % SET_GRAIN;
? return (set[word] & (1UL << bit)) != 0;
}

Both backends generate calls to these functions.


In the gcc backend we now inline the equivalent.
In the NT backend, I use the bt and bts instructions.
?The resulting code is very size optimized.
? bt and bts do the shift, the index, the and/or. All in one.

I don't think I knew it at the time, but bt/bts are interlocked/seralized/atomic -- slow.

Maybe the wrong choice here?
Should instead inline the equivalent mask/index/and/or like the gcc backend does?


?- Jay
 		 	   		  

From jay.krell at cornell.edu  Sat Jun 12 22:24:57 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 12 Jun 2010 20:24:57 +0000
Subject: [M3devel] Modula-3 on Alpha/osf
Message-ID: <COL101-W6299CB615484EB3A70C44CE6DA0@phx.gbl>


It can compile itself. No stack walker currently.
User threads were used accidentally and worked. pthreads now.
No gui apps tested.

Compiling m3-libs/arithmetic:

Program received signal SIGFPE, Arithmetic exception.
0x00000001203c8c80 in TFloat__Multiply ()
(gdb) bt
#0? 0x00000001203c8c80 in TFloat__Multiply ()
#1? 0x000000012034a334 in ReelExpr__Multiply ()
#2? 0x0000000120373e10 in MultiplyExpr__Fold ()
#3? 0x00000001201ff810 in Expr__ConstValue ()
#4? 0x0000000120203744 in Constant__Check ()
#5? 0x0000000120163100 in Value__TypeCheck ()
#6? 0x00000001201853b4 in Scope__TypeCheck ()
#7? 0x000000012017cfdc in Module__TypeCheck ()
#8? 0x0000000120159b14 in M3Front__DoCompile ()
#9? 0x00000001201589f8 in M3Front__Compile ()
#10 0x0000000120059418 in Builder__RunM3 ()


Really, not all that interesting, the system has proven very portable.


Untested min distribution (with above bug):
http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-ALPHA_OSF-d5.8.2-20100612.tar.gz

Thanks to Mika for running the hardware/OS.


more later,
?- Jay
 		 	   		  

From jay.krell at cornell.edu  Sun Jun 13 00:39:18 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 12 Jun 2010 22:39:18 +0000
Subject: [M3devel] integer overflow
Message-ID: <COL101-W35BD9898C6B5DE9BC5A498E6DA0@phx.gbl>


Been reading about Alpha:


Alpha and Programming Languages 
Alpha is an attractive architecture for compiling a large variety of programming languages. 
Alpha has been carefull y desi gned to avoi d bi as t oward one or two progra mmi ng languages. 
For example: 
? Alpha does not contain a subroutine call instruction that moves a register window by a 
fixed amount. Thus, Alpha is a good match for programming languages with many 
parameters and programming languages with no parameters. 
? Alpha does not contain a global integer overflow enable bit. Such a bit would need to 
be changed at every subroutine boundary when a FORTRAN program calls a C pro- 
gram. 







...


Integer Operate Instructions 
...Integer overfl ow tr ap enable is encoded in t he functi on fie ld of ea ch instruct ion, ra ther t han 
kept in a global state bit. Thus, for example, both ADDQ/V and ADDQ opcodes exist for spec- 
ifying 64-bi t ADD with and without overflow checking. That makes it easier to pipe line 
implementations. 



?- Jay
 		 	   		  

From jay.krell at cornell.edu  Sun Jun 13 07:44:17 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 13 Jun 2010 05:44:17 +0000
Subject: [M3devel] Modula-3 on Alpha/osf
Message-ID: <COL101-W49D9DFBDF25B81EC171D18E6DB0@phx.gbl>


Ok, the floating point problem is fixed well enough now. Mika reports several X apps work.


http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-all-ALPHA_OSF-d5.8.2-20100612.tar.gz
http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-all-ALPHA_OSF-d5.8.2-20100612.tar.xz
http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-ALPHA_OSF-d5.8.2-20100612.tar.gz
http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-ALPHA_OSF-d5.8.2-20100612.tar.xz

I admit I forgot to remove $HOME/bin from $PATH when building these and it likely mattered.
Though "stock" install should suffice to use it.


These builds maybe lack most symbols.

?- Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com; mika at async.async.caltech.edu
> Subject: Modula-3 on Alpha/osf
> Date: Sat, 12 Jun 2010 20:24:57 +0000
>
>
> It can compile itself. No stack walker currently.
> User threads were used accidentally and worked. pthreads now.
> No gui apps tested.
>
> Compiling m3-libs/arithmetic:
>
> Program received signal SIGFPE, Arithmetic exception.
> 0x00000001203c8c80 in TFloat__Multiply ()
> (gdb) bt
> #0  0x00000001203c8c80 in TFloat__Multiply ()
> #1  0x000000012034a334 in ReelExpr__Multiply ()
> #2  0x0000000120373e10 in MultiplyExpr__Fold ()
> #3  0x00000001201ff810 in Expr__ConstValue ()
> #4  0x0000000120203744 in Constant__Check ()
> #5  0x0000000120163100 in Value__TypeCheck ()
> #6  0x00000001201853b4 in Scope__TypeCheck ()
> #7  0x000000012017cfdc in Module__TypeCheck ()
> #8  0x0000000120159b14 in M3Front__DoCompile ()
> #9  0x00000001201589f8 in M3Front__Compile ()
> #10 0x0000000120059418 in Builder__RunM3 ()
>
>
> Really, not all that interesting, the system has proven very portable.
>
>
> Untested min distribution (with above bug):
> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-ALPHA_OSF-d5.8.2-20100612.tar.gz
>
> Thanks to Mika for running the hardware/OS.
>
>
> more later,
>  - Jay
>
 		 	   		  

From jay.krell at cornell.edu  Sun Jun 13 07:46:14 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 13 Jun 2010 05:46:14 +0000
Subject: [M3devel] interesting osf cc option for uninitialized variables
Message-ID: <COL101-W7E2AF461FEDBCE3741EE6E6DB0@phx.gbl>


? -trapuv
????? Forces all uninitialized stack variables to be initialized with
????? 0xfff58005fff58005. When this value is used as a floating-point vari-
????? able, it is treated as a floating-point NaN and causes a floating-point
????? trap.? When it is used as a pointer, an address or segmentation viola-
????? tion usually occurs.


Relates to recent discussion.
This should probably be how longreals are initialize for this target.
Though in reality I'm not very motivated to make this target esp. better than any others.
It is interesting to see though what features people have put into C compilers.


?- Jay





 		 	   		  

From rodney_bates at lcwb.coop  Sun Jun 13 17:08:15 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Sun, 13 Jun 2010 10:08:15 -0500
Subject: [M3devel] interesting osf cc option for uninitialized variables
In-Reply-To: <COL101-W7E2AF461FEDBCE3741EE6E6DB0@phx.gbl>
References: <COL101-W7E2AF461FEDBCE3741EE6E6DB0@phx.gbl>
Message-ID: <4C14F45F.2090709@lcwb.coop>



Jay K wrote:
>   -trapuv
>       Forces all uninitialized stack variables to be initialized with
>       0xfff58005fff58005. When this value is used as a floating-point vari-
>       able, it is treated as a floating-point NaN and causes a floating-point
>       trap.  When it is used as a pointer, an address or segmentation viola-
>       tion usually occurs.

In the case of a pointer, doing this would violate the Modula-3 language rule
that all variables are initialized to a bit pattern that represents a valid
member of the variable's type.  For a pointer, this would have to be either
the address of an allocated heap object or NIL.  Only the NIL makes any sense.

I like the idea for floats, though, and I consider a NaN to be a valid member
of the type.

> 
> 
> Relates to recent discussion.
> This should probably be how longreals are initialize for this target.
> Though in reality I'm not very motivated to make this target esp. better than any others.
> It is interesting to see though what features people have put into C compilers.
> 
> 
>  - Jay
> 
> 
> 
> 
> 
>  		 	   		  


From rodney_bates at lcwb.coop  Sun Jun 13 17:12:54 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Sun, 13 Jun 2010 10:12:54 -0500
Subject: [M3devel] integer overflow
In-Reply-To: <COL101-W35BD9898C6B5DE9BC5A498E6DA0@phx.gbl>
References: <COL101-W35BD9898C6B5DE9BC5A498E6DA0@phx.gbl>
Message-ID: <4C14F576.5000104@lcwb.coop>



Jay K wrote:
> Been reading about Alpha:
> 
> 
> Alpha and Programming Languages 
> Alpha is an attractive architecture for compiling a large variety of programming languages. 
> Alpha has been carefull y desi gned to avoi d bi as t oward one or two progra mmi ng languages. 
> For example: 
> ? Alpha does not contain a subroutine call instruction that moves a register window by a 
> fixed amount. Thus, Alpha is a good match for programming languages with many 
> parameters and programming languages with no parameters. 
> ? Alpha does not contain a global integer overflow enable bit. Such a bit would need to 
> be changed at every subroutine boundary when a FORTRAN program calls a C pro- 
> gram. 
> 
> 
> 
> 
> 
> 
> 
> ...
> 
> 
> Integer Operate Instructions 
> ...Integer overfl ow tr ap enable is encoded in t he functi on fie ld of ea ch instruct ion, ra ther t han 
> kept in a global state bit. Thus, for example, both ADDQ/V and ADDQ opcodes exist for spec- 
> ifying 64-bi t ADD with and without overflow checking. That makes it easier to pipe line 
> implementations. 
> 
> 

I'm all for trapping integer overflows, if the performance penalty isn't just horrible.  I doubt
that in more than a tiny minority of cases, integer overflows that silently wrap around (or
silently do anything else) are cases the original programmer knew were correct or even thought
about the possibility they might happen.

> 
>  - Jay
>  		 	   		  


From jay.krell at cornell.edu  Sun Jun 13 22:43:22 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 13 Jun 2010 20:43:22 +0000
Subject: [M3devel] -rpath/origin/CM3_INSTALL on osf
Message-ID: <COL101-W3A566B3FC93FA0C3C7817E6DB0@phx.gbl>


OSF, at least the older version that Mika is running, supports -rpath /foo/bar and -rpath ${arbitrary_environment_variable}, but not -rpath $origin.


Therefore I believe we should pick an arbitrary_environment_variable.


I'd like CM3_ROOT, but that is already somewhat/optionally in use for the root of the source tree.
CM3_INSTALL is somewhat/optionally in use to mean what we want here.
So CM3_INSTALL should probably be it.


Alternatively we could pick something really new, OSF_CM3_RPATH or such, and drop in wrapper scripts that set it to their location.


As well, OSF still has the "old" structure where all the .so files are strewn around pkg instead of flattened into lib.
I'll fix that shortly.


You know, the distributions I uploaded have /home/jayk presumably all around them.


We could also "stage" installs to somewhere unique/arbitrary and require user to set LD_LIBRARY_PATH.
But CM3_INSTALL seems adequate, maybe better.


Possibly CM3_INSTALL_5_8, CM3_INSTALL_5_9, etc.
? Though really, better than that is probably wrapper scripts that set CM3_INSTALL.
And wrapper scripts could be executables, put the real executables in lib or such.


?- Jay
 		 	   		  

From jay.krell at cornell.edu  Mon Jun 14 09:05:26 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 14 Jun 2010 07:05:26 +0000
Subject: [M3devel] -rpath/origin/CM3_INSTALL on osf
Message-ID: <COL101-W67A6DC7F1AAB8224C9C67E6DC0@phx.gbl>


It looks like you can't use $FOO/t, just $FOO.
So I'll probably use CM3_RPATH.

?- Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Subject: -rpath/origin/CM3_INSTALL on osf
> Date: Sun, 13 Jun 2010 20:43:22 +0000
>
>
> OSF, at least the older version that Mika is running, supports -rpath /foo/bar and -rpath ${arbitrary_environment_variable}, but not -rpath $origin.
>
>
> Therefore I believe we should pick an arbitrary_environment_variable.
>
>
> I'd like CM3_ROOT, but that is already somewhat/optionally in use for the root of the source tree.
> CM3_INSTALL is somewhat/optionally in use to mean what we want here.
> So CM3_INSTALL should probably be it.
>
>
> Alternatively we could pick something really new, OSF_CM3_RPATH or such, and drop in wrapper scripts that set it to their location.
>
>
> As well, OSF still has the "old" structure where all the .so files are strewn around pkg instead of flattened into lib.
> I'll fix that shortly.
>
>
> You know, the distributions I uploaded have /home/jayk presumably all around them.
>
>
> We could also "stage" installs to somewhere unique/arbitrary and require user to set LD_LIBRARY_PATH.
> But CM3_INSTALL seems adequate, maybe better.
>
>
> Possibly CM3_INSTALL_5_8, CM3_INSTALL_5_9, etc.
>   Though really, better than that is probably wrapper scripts that set CM3_INSTALL.
> And wrapper scripts could be executables, put the real executables in lib or such.
>
>
>  - Jay
>
 		 	   		  

From jay.krell at cornell.edu  Mon Jun 14 23:04:35 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 14 Jun 2010 21:04:35 +0000
Subject: [M3devel] -rpath/origin/CM3_INSTALL on osf
Message-ID: <COL101-W1739F3FDC24AB9E1B858FAE6DC0@phx.gbl>


I'm strongly considering dropping in bin stubs that calculate and set CM3_RPATH and then exec the actual files, in cm3/lib.
Thoughts?
It'd only be for OSF.
And only for shared executables -- wouldn't break cm3 finding config files.
Whether or not argv[0] "lies" and remains as bin, or is "truth" and set to lib, unsure.


Alternatively, relink on upon ship/install?
? That I believe is not unusual practise. It'd also fix NetBSD 4.0..
??? And it is in some ways better than the current use of $ORIGIN on all other systems.
? Augment "boot1.py" to build the entire system, and build a makefile that rebuilds and ships all libraries/executables?
? Well, what that probably looks like is augmenting it with Olaf's packaging.
?? Use that layout, and the method of using cd+cm3, but include all the .c and .s files and have cm3 run assemble/make_lib/ship.
?? We likely want that anyway, as a more complete form of cross build. Where I define "cross build" in an odd way -- compiling
?? all the Modula-3 to assembly, but not compiling any of the C or running the assembler or linking.
?? 
There are possible other options, like have the stub determine all the files to load and put them in _RLD_LIST.

Or just don't support shared libraries on OSF?

Or just distribute existing "boot" for OSF, and require people (Mika) to run scripts/python/boot2.sh?
?This is maybe the best short term choice. Doesn't require any work, supports shared libraries.
?I think I'll "try" that. Upload a current boot and if Mika can get it to work from there and doesn't mind it, good enough.

?- Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Subject: RE: -rpath/origin/CM3_INSTALL on osf
> Date: Mon, 14 Jun 2010 07:05:26 +0000
>
>
> It looks like you can't use $FOO/t, just $FOO.
> So I'll probably use CM3_RPATH.
>
>  - Jay
>
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: m3devel at elegosoft.com
>> Subject: -rpath/origin/CM3_INSTALL on osf
>> Date: Sun, 13 Jun 2010 20:43:22 +0000
>>
>>
>> OSF, at least the older version that Mika is running, supports -rpath /foo/bar and -rpath ${arbitrary_environment_variable}, but not -rpath $origin.
>>
>>
>> Therefore I believe we should pick an arbitrary_environment_variable.
>>
>>
>> I'd like CM3_ROOT, but that is already somewhat/optionally in use for the root of the source tree.
>> CM3_INSTALL is somewhat/optionally in use to mean what we want here.
>> So CM3_INSTALL should probably be it.
>>
>>
>> Alternatively we could pick something really new, OSF_CM3_RPATH or such, and drop in wrapper scripts that set it to their location.
>>
>>
>> As well, OSF still has the "old" structure where all the .so files are strewn around pkg instead of flattened into lib.
>> I'll fix that shortly.
>>
>>
>> You know, the distributions I uploaded have /home/jayk presumably all around them.
>>
>>
>> We could also "stage" installs to somewhere unique/arbitrary and require user to set LD_LIBRARY_PATH.
>> But CM3_INSTALL seems adequate, maybe better.
>>
>>
>> Possibly CM3_INSTALL_5_8, CM3_INSTALL_5_9, etc.
>> Though really, better than that is probably wrapper scripts that set CM3_INSTALL.
>> And wrapper scripts could be executables, put the real executables in lib or such.
>>
>>
>> - Jay
>>
>
 		 	   		  

From wagner at elegosoft.com  Tue Jun 15 11:04:21 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Tue, 15 Jun 2010 11:04:21 +0200
Subject: [M3devel] -rpath/origin/CM3_INSTALL on osf
In-Reply-To: <COL101-W1739F3FDC24AB9E1B858FAE6DC0@phx.gbl>
References: <COL101-W1739F3FDC24AB9E1B858FAE6DC0@phx.gbl>
Message-ID: <20100615110421.7sika6yr4sskso4g@mail.elegosoft.com>

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

> I'm strongly considering dropping in bin stubs that calculate and   
> set CM3_RPATH and then exec the actual files, in cm3/lib.
> Thoughts?
> It'd only be for OSF.
> And only for shared executables -- wouldn't break cm3 finding config files.
> Whether or not argv[0] "lies" and remains as bin, or is "truth" and   
> set to lib, unsure.
>
>
> Alternatively, relink on upon ship/install?
> ? That I believe is not unusual practise. It'd also fix NetBSD 4.0..
> ??? And it is in some ways better than the current use of $ORIGIN on  
>  all other systems.
> ? Augment "boot1.py" to build the entire system, and build a   
> makefile that rebuilds and ships all libraries/executables?
> ? Well, what that probably looks like is augmenting it with Olaf's packaging.
> ?? Use that layout, and the method of using cd+cm3, but include all   
> the .c and .s files and have cm3 run assemble/make_lib/ship.
> ?? We likely want that anyway, as a more complete form of cross   
> build. Where I define "cross build" in an odd way -- compiling
> ?? all the Modula-3 to assembly, but not compiling any of the C or   
> running the assembler or linking.

I think `relink upon ship' would be interesting as an experimental
option. I'm still not sure if we should really do that or not,
but if it can be done with little effort, we may play with it.
  ??
> There are possible other options, like have the stub determine all   
> the files to load and put them in _RLD_LIST.
>
> Or just don't support shared libraries on OSF?

Sounds lame :-)

> Or just distribute existing "boot" for OSF, and require people   
> (Mika) to run scripts/python/boot2.sh?
> ?This is maybe the best short term choice. Doesn't require any work,  
>  supports shared libraries.
> ?I think I'll "try" that. Upload a current boot and if Mika can get   
> it to work from there and doesn't mind it, good enough.

OK with me, too, for now, if all users are satisfied with that.
We're only talking about ALPHA_OSF, aren't we?

Olaf

> ?- Jay
>
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: m3devel at elegosoft.com
>> Subject: RE: -rpath/origin/CM3_INSTALL on osf
>> Date: Mon, 14 Jun 2010 07:05:26 +0000
>>
>>
>> It looks like you can't use $FOO/t, just $FOO.
>> So I'll probably use CM3_RPATH.
>>
>>  - Jay
>>
>> ----------------------------------------
>>> From: jay.krell at cornell.edu
>>> To: m3devel at elegosoft.com
>>> Subject: -rpath/origin/CM3_INSTALL on osf
>>> Date: Sun, 13 Jun 2010 20:43:22 +0000
>>>
>>>
>>> OSF, at least the older version that Mika is running, supports   
>>> -rpath /foo/bar and -rpath ${arbitrary_environment_variable}, but   
>>> not -rpath $origin.
>>>
>>>
>>> Therefore I believe we should pick an arbitrary_environment_variable.
>>>
>>>
>>> I'd like CM3_ROOT, but that is already somewhat/optionally in use   
>>> for the root of the source tree.
>>> CM3_INSTALL is somewhat/optionally in use to mean what we want here.
>>> So CM3_INSTALL should probably be it.
>>>
>>>
>>> Alternatively we could pick something really new, OSF_CM3_RPATH or  
>>>  such, and drop in wrapper scripts that set it to their location.
>>>
>>>
>>> As well, OSF still has the "old" structure where all the .so files  
>>>  are strewn around pkg instead of flattened into lib.
>>> I'll fix that shortly.
>>>
>>>
>>> You know, the distributions I uploaded have /home/jayk presumably   
>>> all around them.
>>>
>>>
>>> We could also "stage" installs to somewhere unique/arbitrary and   
>>> require user to set LD_LIBRARY_PATH.
>>> But CM3_INSTALL seems adequate, maybe better.
>>>
>>>
>>> Possibly CM3_INSTALL_5_8, CM3_INSTALL_5_9, etc.
>>> Though really, better than that is probably wrapper scripts that   
>>> set CM3_INSTALL.
>>> And wrapper scripts could be executables, put the real executables  
>>>  in lib or such.
>>>
>>>
>>> - 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 jay.krell at cornell.edu  Wed Jun 16 09:01:28 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 16 Jun 2010 07:01:28 +0000
Subject: [M3devel] -rpath/origin/CM3_INSTALL on osf
In-Reply-To: <20100615110421.7sika6yr4sskso4g@mail.elegosoft.com>
References: <COL101-W1739F3FDC24AB9E1B858FAE6DC0@phx.gbl>,
	<20100615110421.7sika6yr4sskso4g@mail.elegosoft.com>
Message-ID: <COL101-W4A6E5C8BBFA0272B893F7E6DE0@phx.gbl>


Yes it is mainly about OSF.
Though it is also about running unshipped binaries on all systems -- dynamically linked ones.
For now I'll probably do nothing. Except put this in a todo.txt file I'm going to checkin, I think.
Other stuff first I think.

?- Jay

----------------------------------------
> Date: Tue, 15 Jun 2010 11:04:21 +0200
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] -rpath/origin/CM3_INSTALL on osf
>
> Quoting Jay K :
>
>> I'm strongly considering dropping in bin stubs that calculate and
>> set CM3_RPATH and then exec the actual files, in cm3/lib.
>> Thoughts?
>> It'd only be for OSF.
>> And only for shared executables -- wouldn't break cm3 finding config files.
>> Whether or not argv[0] "lies" and remains as bin, or is "truth" and
>> set to lib, unsure.
>>
>>
>> Alternatively, relink on upon ship/install?
>>   That I believe is not unusual practise. It'd also fix NetBSD 4.0..
>>     And it is in some ways better than the current use of $ORIGIN on
>> all other systems.
>>   Augment "boot1.py" to build the entire system, and build a
>> makefile that rebuilds and ships all libraries/executables?
>>   Well, what that probably looks like is augmenting it with Olaf's packaging.
>>    Use that layout, and the method of using cd+cm3, but include all
>> the .c and .s files and have cm3 run assemble/make_lib/ship.
>>    We likely want that anyway, as a more complete form of cross
>> build. Where I define "cross build" in an odd way -- compiling
>>    all the Modula-3 to assembly, but not compiling any of the C or
>> running the assembler or linking.
>
> I think `relink upon ship' would be interesting as an experimental
> option. I'm still not sure if we should really do that or not,
> but if it can be done with little effort, we may play with it.
>
>> There are possible other options, like have the stub determine all
>> the files to load and put them in _RLD_LIST.
>>
>> Or just don't support shared libraries on OSF?
>
> Sounds lame :-)
>
>> Or just distribute existing "boot" for OSF, and require people
>> (Mika) to run scripts/python/boot2.sh?
>>  This is maybe the best short term choice. Doesn't require any work,
>> supports shared libraries.
>>  I think I'll "try" that. Upload a current boot and if Mika can get
>> it to work from there and doesn't mind it, good enough.
>
> OK with me, too, for now, if all users are satisfied with that.
> We're only talking about ALPHA_OSF, aren't we?
>
> Olaf
>
>>  - Jay
>>
>> ----------------------------------------
>>> From: jay.krell at cornell.edu
>>> To: m3devel at elegosoft.com
>>> Subject: RE: -rpath/origin/CM3_INSTALL on osf
>>> Date: Mon, 14 Jun 2010 07:05:26 +0000
>>>
>>>
>>> It looks like you can't use $FOO/t, just $FOO.
>>> So I'll probably use CM3_RPATH.
>>>
>>> - Jay
>>>
>>> ----------------------------------------
>>>> From: jay.krell at cornell.edu
>>>> To: m3devel at elegosoft.com
>>>> Subject: -rpath/origin/CM3_INSTALL on osf
>>>> Date: Sun, 13 Jun 2010 20:43:22 +0000
>>>>
>>>>
>>>> OSF, at least the older version that Mika is running, supports
>>>> -rpath /foo/bar and -rpath ${arbitrary_environment_variable}, but
>>>> not -rpath $origin.
>>>>
>>>>
>>>> Therefore I believe we should pick an arbitrary_environment_variable.
>>>>
>>>>
>>>> I'd like CM3_ROOT, but that is already somewhat/optionally in use
>>>> for the root of the source tree.
>>>> CM3_INSTALL is somewhat/optionally in use to mean what we want here.
>>>> So CM3_INSTALL should probably be it.
>>>>
>>>>
>>>> Alternatively we could pick something really new, OSF_CM3_RPATH or
>>>> such, and drop in wrapper scripts that set it to their location.
>>>>
>>>>
>>>> As well, OSF still has the "old" structure where all the .so files
>>>> are strewn around pkg instead of flattened into lib.
>>>> I'll fix that shortly.
>>>>
>>>>
>>>> You know, the distributions I uploaded have /home/jayk presumably
>>>> all around them.
>>>>
>>>>
>>>> We could also "stage" installs to somewhere unique/arbitrary and
>>>> require user to set LD_LIBRARY_PATH.
>>>> But CM3_INSTALL seems adequate, maybe better.
>>>>
>>>>
>>>> Possibly CM3_INSTALL_5_8, CM3_INSTALL_5_9, etc.
>>>> Though really, better than that is probably wrapper scripts that
>>>> set CM3_INSTALL.
>>>> And wrapper scripts could be executables, put the real executables
>>>> in lib or such.
>>>>
>>>>
>>>> - 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 darko at darko.org  Fri Jun 18 03:08:14 2010
From: darko at darko.org (Darko)
Date: Thu, 17 Jun 2010 18:08:14 -0700
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>
References: <1274350133.8902.0.camel@localhost>
	<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>
Message-ID: <2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>

I've been interested in an ARM port for some time. If you (or anyone else) are interested  in doing the port I can send you one of these, which looks like a good platform since it runs Linux and Android, has 512K memory and looks well supported: http://beagleboard.org/hardware



On 20/05/2010, at 4:47 AM, 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? 
> 
		 	   		  



From jay.krell at cornell.edu  Fri Jun 18 06:15:05 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 18 Jun 2010 04:15:05 +0000
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>
References: <1274350133.8902.0.camel@localhost>,
	<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>,
	<2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>
Message-ID: <COL101-W580FCB4C956AC658A851ABE6C00@phx.gbl>


My preference would be if you can set it up on the internet and allow me ssh access.
gcc only recently got support for Android's C library "bionic", I believe post-gcc 4.5.
I'm not sure if that matters much or not.
I'm not sure how much the C library of the target matters to gcc.
 
 
Anything with pthreads and gcc support is quite easy to port to these days. In the past the biggest thing you had to do was rewrite /usr/include in Modula-3. There was a tendency to rewrite far more of it than necessary. These days, none of it is needed.
 
 
Now you just have to
  - pick a target name 
  - find the jmpbuf size, word size, endian 
  - write a much small "config" file
  - respond to each error that occurs -- fill in the platform in a few tables sprinkled around the tree 
 
 
Even systems without pthreads or with not very good pthreads (OpenBSD) are easy now, as the user thread support is much more portable. It used to be, for user threads, you had to poke around in the jmpbuf.
 
 
I would encourage anyone else to try it out.
 
 
Maybe soon there will be a C generating backend, and we'll just have one distribution format that is a bunch of C, and then gcc support won't even be needed (e.g. IA64_NT).
 
 
Thanks,
 - Jay

----------------------------------------
> From: darko at darko.org
> Date: Thu, 17 Jun 2010 18:08:14 -0700
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Linux/ARM? Android?
>
> I've been interested in an ARM port for some time. If you (or anyone else) are interested in doing the port I can send you one of these, which looks like a good platform since it runs Linux and Android, has 512K memory and looks well supported: http://beagleboard.org/hardware
>
>
>
> On 20/05/2010, at 4:47 AM, 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?
>>
>
> 		 	   		  

From darko at darko.org  Fri Jun 18 06:41:59 2010
From: darko at darko.org (Darko)
Date: Thu, 17 Jun 2010 21:41:59 -0700
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <COL101-W580FCB4C956AC658A851ABE6C00@phx.gbl>
References: <1274350133.8902.0.camel@localhost>,
	<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>,
	<2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>
	<COL101-W580FCB4C956AC658A851ABE6C00@phx.gbl>
Message-ID: <44CCDCF6-BACE-4B58-A1F5-EF68A852E2A5@darko.org>

Ok, the link here is about 20/4Mbs so it shouldn't be too bad and the latency is good. I'm in Mountain View, CA. Unfortunately the board has only 128MB of main memory but I assume that's enough, I think a self hosted compiler has no point.

I'll post the details when it's up and running.


On 17/06/2010, at 9:15 PM, Jay K wrote:


My preference would be if you can set it up on the internet and allow me ssh access.
gcc only recently got support for Android's C library "bionic", I believe post-gcc 4.5.
I'm not sure if that matters much or not.
I'm not sure how much the C library of the target matters to gcc.


Anything with pthreads and gcc support is quite easy to port to these days. In the past the biggest thing you had to do was rewrite /usr/include in Modula-3. There was a tendency to rewrite far more of it than necessary. These days, none of it is needed.


Now you just have to
 - pick a target name 
 - find the jmpbuf size, word size, endian 
 - write a much small "config" file
 - respond to each error that occurs -- fill in the platform in a few tables sprinkled around the tree 


Even systems without pthreads or with not very good pthreads (OpenBSD) are easy now, as the user thread support is much more portable. It used to be, for user threads, you had to poke around in the jmpbuf.


I would encourage anyone else to try it out.


Maybe soon there will be a C generating backend, and we'll just have one distribution format that is a bunch of C, and then gcc support won't even be needed (e.g. IA64_NT).


Thanks,
- Jay

----------------------------------------
> From: darko at darko.org
> Date: Thu, 17 Jun 2010 18:08:14 -0700
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Linux/ARM? Android?
> 
> I've been interested in an ARM port for some time. If you (or anyone else) are interested in doing the port I can send you one of these, which looks like a good platform since it runs Linux and Android, has 512K memory and looks well supported: http://beagleboard.org/hardware
> 
> 
> 
> On 20/05/2010, at 4:47 AM, 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?
>> 
> 
> 		 	   		  



From jay.krell at cornell.edu  Sat Jun 19 07:04:28 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 19 Jun 2010 05:04:28 +0000
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <44CCDCF6-BACE-4B58-A1F5-EF68A852E2A5@darko.org>
References: <1274350133.8902.0.camel@localhost>, ,
	<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>, ,
	<2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>,
	<COL101-W580FCB4C956AC658A851ABE6C00@phx.gbl>,
	<44CCDCF6-BACE-4B58-A1F5-EF68A852E2A5@darko.org>
Message-ID: <COL101-W493D8FFD71EB43948CBE8CE6C10@phx.gbl>


Thanks. I'll give qemu a go as well.
Hey, maybe we can get mips also. (there's decent modern mips/linux hardware now, Chinese laptops)

?- Jay

----------------------------------------
> From: darko at darko.org
> Date: Thu, 17 Jun 2010 21:41:59 -0700
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Linux/ARM? Android?
>
> Ok, the link here is about 20/4Mbs so it shouldn't be too bad and the latency is good. I'm in Mountain View, CA. Unfortunately the board has only 128MB of main memory but I assume that's enough, I think a self hosted compiler has no point.
>
> I'll post the details when it's up and running.
>
>
> On 17/06/2010, at 9:15 PM, Jay K wrote:
>
>
> My preference would be if you can set it up on the internet and allow me ssh access.
> gcc only recently got support for Android's C library "bionic", I believe post-gcc 4.5.
> I'm not sure if that matters much or not.
> I'm not sure how much the C library of the target matters to gcc.
>
>
> Anything with pthreads and gcc support is quite easy to port to these days. In the past the biggest thing you had to do was rewrite /usr/include in Modula-3. There was a tendency to rewrite far more of it than necessary. These days, none of it is needed.
>
>
> Now you just have to
> - pick a target name
> - find the jmpbuf size, word size, endian
> - write a much small "config" file
> - respond to each error that occurs -- fill in the platform in a few tables sprinkled around the tree
>
>
> Even systems without pthreads or with not very good pthreads (OpenBSD) are easy now, as the user thread support is much more portable. It used to be, for user threads, you had to poke around in the jmpbuf.
>
>
> I would encourage anyone else to try it out.
>
>
> Maybe soon there will be a C generating backend, and we'll just have one distribution format that is a bunch of C, and then gcc support won't even be needed (e.g. IA64_NT).
>
>
> Thanks,
> - Jay
>
> ----------------------------------------
>> From: darko at darko.org
>> Date: Thu, 17 Jun 2010 18:08:14 -0700
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Linux/ARM? Android?
>>
>> I've been interested in an ARM port for some time. If you (or anyone else) are interested in doing the port I can send you one of these, which looks like a good platform since it runs Linux and Android, has 512K memory and looks well supported: http://beagleboard.org/hardware
>>
>>
>>
>> On 20/05/2010, at 4:47 AM, 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?
>>>
>>
>>
>
 		 	   		  

From darko at darko.org  Sat Jun 19 07:13:43 2010
From: darko at darko.org (Darko)
Date: Fri, 18 Jun 2010 22:13:43 -0700
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <COL101-W493D8FFD71EB43948CBE8CE6C10@phx.gbl>
References: <1274350133.8902.0.camel@localhost>, ,
	<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>, ,
	<2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>,
	<COL101-W580FCB4C956AC658A851ABE6C00@phx.gbl>,
	<44CCDCF6-BACE-4B58-A1F5-EF68A852E2A5@darko.org>
	<COL101-W493D8FFD71EB43948CBE8CE6C10@phx.gbl>
Message-ID: <B4638299-A29A-454B-9931-4F296F9AD3DB@darko.org>

If you use qemu, this might be useful: http://free-electrons.com/community/demos/qemu-arm-directfb/

I'm currently looking at some cheap laptops (around $100) which have ethernet plus screen, keyboard, battery, etc which would work well as hosts. Just trying to find one that runs both Linux and Android.


On 18/06/2010, at 10:04 PM, Jay K wrote:


Thanks. I'll give qemu a go as well.
Hey, maybe we can get mips also. (there's decent modern mips/linux hardware now, Chinese laptops)

 - Jay

----------------------------------------
> From: darko at darko.org
> Date: Thu, 17 Jun 2010 21:41:59 -0700
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Linux/ARM? Android?
> 
> Ok, the link here is about 20/4Mbs so it shouldn't be too bad and the latency is good. I'm in Mountain View, CA. Unfortunately the board has only 128MB of main memory but I assume that's enough, I think a self hosted compiler has no point.
> 
> I'll post the details when it's up and running.
> 
> 
> On 17/06/2010, at 9:15 PM, Jay K wrote:
> 
> 
> My preference would be if you can set it up on the internet and allow me ssh access.
> gcc only recently got support for Android's C library "bionic", I believe post-gcc 4.5.
> I'm not sure if that matters much or not.
> I'm not sure how much the C library of the target matters to gcc.
> 
> 
> Anything with pthreads and gcc support is quite easy to port to these days. In the past the biggest thing you had to do was rewrite /usr/include in Modula-3. There was a tendency to rewrite far more of it than necessary. These days, none of it is needed.
> 
> 
> Now you just have to
> - pick a target name
> - find the jmpbuf size, word size, endian
> - write a much small "config" file
> - respond to each error that occurs -- fill in the platform in a few tables sprinkled around the tree
> 
> 
> Even systems without pthreads or with not very good pthreads (OpenBSD) are easy now, as the user thread support is much more portable. It used to be, for user threads, you had to poke around in the jmpbuf.
> 
> 
> I would encourage anyone else to try it out.
> 
> 
> Maybe soon there will be a C generating backend, and we'll just have one distribution format that is a bunch of C, and then gcc support won't even be needed (e.g. IA64_NT).
> 
> 
> Thanks,
> - Jay
> 
> ----------------------------------------
>> From: darko at darko.org
>> Date: Thu, 17 Jun 2010 18:08:14 -0700
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Linux/ARM? Android?
>> 
>> I've been interested in an ARM port for some time. If you (or anyone else) are interested in doing the port I can send you one of these, which looks like a good platform since it runs Linux and Android, has 512K memory and looks well supported: http://beagleboard.org/hardware
>> 
>> 
>> 
>> On 20/05/2010, at 4:47 AM, 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?
>>> 
>> 
>> 
> 
		 	   		  



From jay.krell at cornell.edu  Sat Jun 19 07:44:55 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 19 Jun 2010 05:44:55 +0000
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <B4638299-A29A-454B-9931-4F296F9AD3DB@darko.org>
References: <1274350133.8902.0.camel@localhost>,
	,,<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>,
	, , <2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>, ,
	<COL101-W580FCB4C956AC658A851ABE6C00@phx.gbl>, ,
	<44CCDCF6-BACE-4B58-A1F5-EF68A852E2A5@darko.org>,
	<COL101-W493D8FFD71EB43948CBE8CE6C10@phx.gbl>,
	<B4638299-A29A-454B-9931-4F296F9AD3DB@darko.org>
Message-ID: <COL101-W7F2C05F30E9F3525E482DE6C10@phx.gbl>


Interesting, thanks.
But it looks like it needs to use local console for output?
I need something over the network/X.
It looks like there's an qemu option for usemode only too.

?- Jay

----------------------------------------
> From: darko at darko.org
> Date: Fri, 18 Jun 2010 22:13:43 -0700
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Linux/ARM? Android?
>
> If you use qemu, this might be useful: http://free-electrons.com/community/demos/qemu-arm-directfb/
>
> I'm currently looking at some cheap laptops (around $100) which have ethernet plus screen, keyboard, battery, etc which would work well as hosts. Just trying to find one that runs both Linux and Android.
>
>
> On 18/06/2010, at 10:04 PM, Jay K wrote:
>
>
> Thanks. I'll give qemu a go as well.
> Hey, maybe we can get mips also. (there's decent modern mips/linux hardware now, Chinese laptops)
>
> - Jay
>
> ----------------------------------------
>> From: darko at darko.org
>> Date: Thu, 17 Jun 2010 21:41:59 -0700
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Linux/ARM? Android?
>>
>> Ok, the link here is about 20/4Mbs so it shouldn't be too bad and the latency is good. I'm in Mountain View, CA. Unfortunately the board has only 128MB of main memory but I assume that's enough, I think a self hosted compiler has no point.
>>
>> I'll post the details when it's up and running.
>>
>>
>> On 17/06/2010, at 9:15 PM, Jay K wrote:
>>
>>
>> My preference would be if you can set it up on the internet and allow me ssh access.
>> gcc only recently got support for Android's C library "bionic", I believe post-gcc 4.5.
>> I'm not sure if that matters much or not.
>> I'm not sure how much the C library of the target matters to gcc.
>>
>>
>> Anything with pthreads and gcc support is quite easy to port to these days. In the past the biggest thing you had to do was rewrite /usr/include in Modula-3. There was a tendency to rewrite far more of it than necessary. These days, none of it is needed.
>>
>>
>> Now you just have to
>> - pick a target name
>> - find the jmpbuf size, word size, endian
>> - write a much small "config" file
>> - respond to each error that occurs -- fill in the platform in a few tables sprinkled around the tree
>>
>>
>> Even systems without pthreads or with not very good pthreads (OpenBSD) are easy now, as the user thread support is much more portable. It used to be, for user threads, you had to poke around in the jmpbuf.
>>
>>
>> I would encourage anyone else to try it out.
>>
>>
>> Maybe soon there will be a C generating backend, and we'll just have one distribution format that is a bunch of C, and then gcc support won't even be needed (e.g. IA64_NT).
>>
>>
>> Thanks,
>> - Jay
>>
>> ----------------------------------------
>>> From: darko at darko.org
>>> Date: Thu, 17 Jun 2010 18:08:14 -0700
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>
>>> I've been interested in an ARM port for some time. If you (or anyone else) are interested in doing the port I can send you one of these, which looks like a good platform since it runs Linux and Android, has 512K memory and looks well supported: http://beagleboard.org/hardware
>>>
>>>
>>>
>>> On 20/05/2010, at 4:47 AM, 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?
>>>>
>>>
>>>
>>
>
>
 		 	   		  

From darko at darko.org  Sat Jun 19 07:55:24 2010
From: darko at darko.org (Darko)
Date: Fri, 18 Jun 2010 22:55:24 -0700
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <COL101-W7F2C05F30E9F3525E482DE6C10@phx.gbl>
References: <1274350133.8902.0.camel@localhost>, , ,
	<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>, , ,
	<2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>, ,
	<COL101-W580FCB4C956AC658A851ABE6C00@phx.gbl>, ,
	<44CCDCF6-BACE-4B58-A1F5-EF68A852E2A5@darko.org>,
	<COL101-W493D8FFD71EB43948CBE8CE6C10@phx.gbl>,
	<B4638299-A29A-454B-9931-4F296F9AD3DB@darko.org>
	<COL101-W7F2C05F30E9F3525E482DE6C10@phx.gbl>
Message-ID: <ED46DCAD-C84A-488C-BF6F-70CA1F24AF3B@darko.org>

Yeah I've got it working on the console but I agree it needs the network.

Try: http://www.oszoo.org/wiki/index.php/Category:ARM_images
Also: http://www.armedslack.org/ 

What platform are you running on these days?




On 18/06/2010, at 10:44 PM, Jay K wrote:


Interesting, thanks.
But it looks like it needs to use local console for output?
I need something over the network/X.
It looks like there's an qemu option for usemode only too.

 - Jay

----------------------------------------
> From: darko at darko.org
> Date: Fri, 18 Jun 2010 22:13:43 -0700
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Linux/ARM? Android?
> 
> If you use qemu, this might be useful: http://free-electrons.com/community/demos/qemu-arm-directfb/
> 
> I'm currently looking at some cheap laptops (around $100) which have ethernet plus screen, keyboard, battery, etc which would work well as hosts. Just trying to find one that runs both Linux and Android.
> 
> 
> On 18/06/2010, at 10:04 PM, Jay K wrote:
> 
> 
> Thanks. I'll give qemu a go as well.
> Hey, maybe we can get mips also. (there's decent modern mips/linux hardware now, Chinese laptops)
> 
> - Jay
> 
> ----------------------------------------
>> From: darko at darko.org
>> Date: Thu, 17 Jun 2010 21:41:59 -0700
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Linux/ARM? Android?
>> 
>> Ok, the link here is about 20/4Mbs so it shouldn't be too bad and the latency is good. I'm in Mountain View, CA. Unfortunately the board has only 128MB of main memory but I assume that's enough, I think a self hosted compiler has no point.
>> 
>> I'll post the details when it's up and running.
>> 
>> 
>> On 17/06/2010, at 9:15 PM, Jay K wrote:
>> 
>> 
>> My preference would be if you can set it up on the internet and allow me ssh access.
>> gcc only recently got support for Android's C library "bionic", I believe post-gcc 4.5.
>> I'm not sure if that matters much or not.
>> I'm not sure how much the C library of the target matters to gcc.
>> 
>> 
>> Anything with pthreads and gcc support is quite easy to port to these days. In the past the biggest thing you had to do was rewrite /usr/include in Modula-3. There was a tendency to rewrite far more of it than necessary. These days, none of it is needed.
>> 
>> 
>> Now you just have to
>> - pick a target name
>> - find the jmpbuf size, word size, endian
>> - write a much small "config" file
>> - respond to each error that occurs -- fill in the platform in a few tables sprinkled around the tree
>> 
>> 
>> Even systems without pthreads or with not very good pthreads (OpenBSD) are easy now, as the user thread support is much more portable. It used to be, for user threads, you had to poke around in the jmpbuf.
>> 
>> 
>> I would encourage anyone else to try it out.
>> 
>> 
>> Maybe soon there will be a C generating backend, and we'll just have one distribution format that is a bunch of C, and then gcc support won't even be needed (e.g. IA64_NT).
>> 
>> 
>> Thanks,
>> - Jay
>> 
>> ----------------------------------------
>>> From: darko at darko.org
>>> Date: Thu, 17 Jun 2010 18:08:14 -0700
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>> 
>>> I've been interested in an ARM port for some time. If you (or anyone else) are interested in doing the port I can send you one of these, which looks like a good platform since it runs Linux and Android, has 512K memory and looks well supported: http://beagleboard.org/hardware
>>> 
>>> 
>>> 
>>> On 20/05/2010, at 4:47 AM, 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?
>>>> 
>>> 
>>> 
>> 
> 
> 
		 	   		  



From jay.krell at cornell.edu  Sat Jun 19 08:18:50 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 19 Jun 2010 06:18:50 +0000
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <ED46DCAD-C84A-488C-BF6F-70CA1F24AF3B@darko.org>
References: <1274350133.8902.0.camel@localhost>, ,
	,,<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>, ,
	,,<2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>,
	,,<COL101-W580FCB4C956AC658A851ABE6C00@phx.gbl>,
	, , <44CCDCF6-BACE-4B58-A1F5-EF68A852E2A5@darko.org>, ,
	<COL101-W493D8FFD71EB43948CBE8CE6C10@phx.gbl>, ,
	<B4638299-A29A-454B-9931-4F296F9AD3DB@darko.org>,
	<COL101-W7F2C05F30E9F3525E482DE6C10@phx.gbl>,
	<ED46DCAD-C84A-488C-BF6F-70CA1F24AF3B@darko.org>
Message-ID: <COL101-W5474F17968788325FFA76CE6C10@phx.gbl>


XP when I can; nothing else comes close for searching and editing text, I've tried many.
? Visual C++ 5.0.
? I recently learned how to copy/paste in vi, which helps, but I'm not sure I remember now.


Darwin/amd64 when I need/want posix/fastfork, which unfortunately is often.
? Cygwin is slow.
? TextWrangler usually there, though it is awful compared to Visual C++ 5.0.
? KomodoEdit is cross platform but also fairly impaired.
ssh access to a variety
Linux=Debian, it has among the best support for a variety of platforms.
Gentoo comes close or better (ppc64) but I've never been able to get it to install -- booting always fails.
Debian/x86 easy to get cross compiler, qemu, etc.


X Windows apps are never very good imho, so just give up and make do with the even worse command line..
?I find things as basic as scrollbars do not work well -- which button do I press when?
?The Modula-3 GUI apps suffer from this problem as well.
? Further damage due to needing three buttons but not having them.


Mouse button clicking is actually broken on modern Macs too -- they removed the mouse button from all the laptops, leaving
just a big pad, prone to accidental clicks at any location.. also prone to accidental multitouch gestures due to resting
a twitchy thumb where the button is supposed to be. Amazing, really, the mouse, one of their key initial advantages,
is now broken. (see also Finder and file open dialogs, two other former strengths that are now not so great.)
Multitouch scroll is nice though.


?- Jay

----------------------------------------
> From: darko at darko.org
> Date: Fri, 18 Jun 2010 22:55:24 -0700
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Linux/ARM? Android?
>
> Yeah I've got it working on the console but I agree it needs the network.
>
> Try: http://www.oszoo.org/wiki/index.php/Category:ARM_images
> Also: http://www.armedslack.org/
>
> What platform are you running on these days?
>
>
>
>
> On 18/06/2010, at 10:44 PM, Jay K wrote:
>
>
> Interesting, thanks.
> But it looks like it needs to use local console for output?
> I need something over the network/X.
> It looks like there's an qemu option for usemode only too.
>
> - Jay
>
> ----------------------------------------
>> From: darko at darko.org
>> Date: Fri, 18 Jun 2010 22:13:43 -0700
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Linux/ARM? Android?
>>
>> If you use qemu, this might be useful: http://free-electrons.com/community/demos/qemu-arm-directfb/
>>
>> I'm currently looking at some cheap laptops (around $100) which have ethernet plus screen, keyboard, battery, etc which would work well as hosts. Just trying to find one that runs both Linux and Android.
>>
>>
>> On 18/06/2010, at 10:04 PM, Jay K wrote:
>>
>>
>> Thanks. I'll give qemu a go as well.
>> Hey, maybe we can get mips also. (there's decent modern mips/linux hardware now, Chinese laptops)
>>
>> - Jay
>>
>> ----------------------------------------
>>> From: darko at darko.org
>>> Date: Thu, 17 Jun 2010 21:41:59 -0700
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>
>>> Ok, the link here is about 20/4Mbs so it shouldn't be too bad and the latency is good. I'm in Mountain View, CA. Unfortunately the board has only 128MB of main memory but I assume that's enough, I think a self hosted compiler has no point.
>>>
>>> I'll post the details when it's up and running.
>>>
>>>
>>> On 17/06/2010, at 9:15 PM, Jay K wrote:
>>>
>>>
>>> My preference would be if you can set it up on the internet and allow me ssh access.
>>> gcc only recently got support for Android's C library "bionic", I believe post-gcc 4.5.
>>> I'm not sure if that matters much or not.
>>> I'm not sure how much the C library of the target matters to gcc.
>>>
>>>
>>> Anything with pthreads and gcc support is quite easy to port to these days. In the past the biggest thing you had to do was rewrite /usr/include in Modula-3. There was a tendency to rewrite far more of it than necessary. These days, none of it is needed.
>>>
>>>
>>> Now you just have to
>>> - pick a target name
>>> - find the jmpbuf size, word size, endian
>>> - write a much small "config" file
>>> - respond to each error that occurs -- fill in the platform in a few tables sprinkled around the tree
>>>
>>>
>>> Even systems without pthreads or with not very good pthreads (OpenBSD) are easy now, as the user thread support is much more portable. It used to be, for user threads, you had to poke around in the jmpbuf.
>>>
>>>
>>> I would encourage anyone else to try it out.
>>>
>>>
>>> Maybe soon there will be a C generating backend, and we'll just have one distribution format that is a bunch of C, and then gcc support won't even be needed (e.g. IA64_NT).
>>>
>>>
>>> Thanks,
>>> - Jay
>>>
>>> ----------------------------------------
>>>> From: darko at darko.org
>>>> Date: Thu, 17 Jun 2010 18:08:14 -0700
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>
>>>> I've been interested in an ARM port for some time. If you (or anyone else) are interested in doing the port I can send you one of these, which looks like a good platform since it runs Linux and Android, has 512K memory and looks well supported: http://beagleboard.org/hardware
>>>>
>>>>
>>>>
>>>> On 20/05/2010, at 4:47 AM, 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?
>>>>>
>>>>
>>>>
>>>
>>
>>
>
>
 		 	   		  

From darko at darko.org  Sat Jun 19 09:13:53 2010
From: darko at darko.org (Darko)
Date: Sat, 19 Jun 2010 00:13:53 -0700
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <COL101-W5474F17968788325FFA76CE6C10@phx.gbl>
References: <1274350133.8902.0.camel@localhost>, , , ,
	<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>, , , ,
	<2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>, , ,
	<COL101-W580FCB4C956AC658A851ABE6C00@phx.gbl>, , ,
	<44CCDCF6-BACE-4B58-A1F5-EF68A852E2A5@darko.org>, ,
	<COL101-W493D8FFD71EB43948CBE8CE6C10@phx.gbl>, ,
	<B4638299-A29A-454B-9931-4F296F9AD3DB@darko.org>,
	<COL101-W7F2C05F30E9F3525E482DE6C10@phx.gbl>,
	<ED46DCAD-C84A-488C-BF6F-70CA1F24AF3B@darko.org>
	<COL101-W5474F17968788325FFA76CE6C10@phx.gbl>
Message-ID: <5E055C3D-78F6-4C08-86D9-8B8CA86B11A1@darko.org>

I got the first Debian image on http://www.oszoo.org/wiki/index.php/Category:ARM_images to run with a GUI, and it connect to the network. I'm using Q on my 2.4Ghz MacBook 13" and it's surprisingly fast. Note that it's a 10GB image (450MB download).

There are also images for Debian MIPS on that site too.

I agree that the new MacBook trackpad is not perfect and since moving from my previous machine that had a separate button I now get a lot of stray gestures doing odd things. The general solution is not to use the button at all and use taps. The new momentum scrolling with the gesture is neat but needs more "weight". Unfortunately Apple crosses over into form-over-function territory from time to time and this is one of those times.


On 18/06/2010, at 11:18 PM, Jay K wrote:


XP when I can; nothing else comes close for searching and editing text, I've tried many.
  Visual C++ 5.0.
  I recently learned how to copy/paste in vi, which helps, but I'm not sure I remember now.


Darwin/amd64 when I need/want posix/fastfork, which unfortunately is often.
  Cygwin is slow.
  TextWrangler usually there, though it is awful compared to Visual C++ 5.0.
  KomodoEdit is cross platform but also fairly impaired.
ssh access to a variety
Linux=Debian, it has among the best support for a variety of platforms.
Gentoo comes close or better (ppc64) but I've never been able to get it to install -- booting always fails.
Debian/x86 easy to get cross compiler, qemu, etc.


X Windows apps are never very good imho, so just give up and make do with the even worse command line..
 I find things as basic as scrollbars do not work well -- which button do I press when?
 The Modula-3 GUI apps suffer from this problem as well.
  Further damage due to needing three buttons but not having them.


Mouse button clicking is actually broken on modern Macs too -- they removed the mouse button from all the laptops, leaving
just a big pad, prone to accidental clicks at any location.. also prone to accidental multitouch gestures due to resting
a twitchy thumb where the button is supposed to be. Amazing, really, the mouse, one of their key initial advantages,
is now broken. (see also Finder and file open dialogs, two other former strengths that are now not so great.)
Multitouch scroll is nice though.


 - Jay

----------------------------------------
> From: darko at darko.org
> Date: Fri, 18 Jun 2010 22:55:24 -0700
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Linux/ARM? Android?
> 
> Yeah I've got it working on the console but I agree it needs the network.
> 
> Try: http://www.oszoo.org/wiki/index.php/Category:ARM_images
> Also: http://www.armedslack.org/
> 
> What platform are you running on these days?
> 
> 
> 
> 
> On 18/06/2010, at 10:44 PM, Jay K wrote:
> 
> 
> Interesting, thanks.
> But it looks like it needs to use local console for output?
> I need something over the network/X.
> It looks like there's an qemu option for usemode only too.
> 
> - Jay
> 
> ----------------------------------------
>> From: darko at darko.org
>> Date: Fri, 18 Jun 2010 22:13:43 -0700
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Linux/ARM? Android?
>> 
>> If you use qemu, this might be useful: http://free-electrons.com/community/demos/qemu-arm-directfb/
>> 
>> I'm currently looking at some cheap laptops (around $100) which have ethernet plus screen, keyboard, battery, etc which would work well as hosts. Just trying to find one that runs both Linux and Android.
>> 
>> 
>> On 18/06/2010, at 10:04 PM, Jay K wrote:
>> 
>> 
>> Thanks. I'll give qemu a go as well.
>> Hey, maybe we can get mips also. (there's decent modern mips/linux hardware now, Chinese laptops)
>> 
>> - Jay
>> 
>> ----------------------------------------
>>> From: darko at darko.org
>>> Date: Thu, 17 Jun 2010 21:41:59 -0700
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>> 
>>> Ok, the link here is about 20/4Mbs so it shouldn't be too bad and the latency is good. I'm in Mountain View, CA. Unfortunately the board has only 128MB of main memory but I assume that's enough, I think a self hosted compiler has no point.
>>> 
>>> I'll post the details when it's up and running.
>>> 
>>> 
>>> On 17/06/2010, at 9:15 PM, Jay K wrote:
>>> 
>>> 
>>> My preference would be if you can set it up on the internet and allow me ssh access.
>>> gcc only recently got support for Android's C library "bionic", I believe post-gcc 4.5.
>>> I'm not sure if that matters much or not.
>>> I'm not sure how much the C library of the target matters to gcc.
>>> 
>>> 
>>> Anything with pthreads and gcc support is quite easy to port to these days. In the past the biggest thing you had to do was rewrite /usr/include in Modula-3. There was a tendency to rewrite far more of it than necessary. These days, none of it is needed.
>>> 
>>> 
>>> Now you just have to
>>> - pick a target name
>>> - find the jmpbuf size, word size, endian
>>> - write a much small "config" file
>>> - respond to each error that occurs -- fill in the platform in a few tables sprinkled around the tree
>>> 
>>> 
>>> Even systems without pthreads or with not very good pthreads (OpenBSD) are easy now, as the user thread support is much more portable. It used to be, for user threads, you had to poke around in the jmpbuf.
>>> 
>>> 
>>> I would encourage anyone else to try it out.
>>> 
>>> 
>>> Maybe soon there will be a C generating backend, and we'll just have one distribution format that is a bunch of C, and then gcc support won't even be needed (e.g. IA64_NT).
>>> 
>>> 
>>> Thanks,
>>> - Jay
>>> 
>>> ----------------------------------------
>>>> From: darko at darko.org
>>>> Date: Thu, 17 Jun 2010 18:08:14 -0700
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>> 
>>>> I've been interested in an ARM port for some time. If you (or anyone else) are interested in doing the port I can send you one of these, which looks like a good platform since it runs Linux and Android, has 512K memory and looks well supported: http://beagleboard.org/hardware
>>>> 
>>>> 
>>>> 
>>>> On 20/05/2010, at 4:47 AM, 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?
>>>>> 
>>>> 
>>>> 
>>> 
>> 
>> 
> 
> 
		 	   		  



From jay.krell at cornell.edu  Sat Jun 19 10:44:04 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 19 Jun 2010 08:44:04 +0000
Subject: [M3devel] div/mod helpers for pair of negative numbers?
Message-ID: <COL101-W60CEC449B32E4D2297E8F0E6C10@phx.gbl>


Tony, I'm not going to change the release branch, but this is seemingly relevant to ARM on head:


? if ((b == 'P' && a == 'P') || IS_WORD_TYPE(T)) {
??? EXPR_REF (-2) = m3_build2 (FLOOR_MOD_EXPR, t,
??? ??? ??? ?????? m3_cast (t, EXPR_REF (-2)),
??? ??? ??? ?????? m3_cast (t, EXPR_REF (-1)));
??? EXPR_POP ();


is better off as:

? if ((b == a) || IS_WORD_TYPE(T)) {
??? EXPR_REF (-2) = m3_build2 (FLOOR_MOD_EXPR, t,
??? ??? ??? ?????? m3_cast (t, EXPR_REF (-2)),
??? ??? ??? ?????? m3_cast (t, EXPR_REF (-1)));
??? EXPR_POP ();

right?

That, consider..well..the historical modL function is close to that:


int64 __cdecl m3_modL
??? ANSI((????? int64 b, int64 a))
????? KR((b, a) int64 b; int64 a;)
{
? register int64 c;
? if ((a == 0) && (b != 0)) {? c = 0;
? } else if (a> 0)? {? c = (b>= 0) ? a % b : b + 1 + (a-1) % (-b);
? } else /* a < 0 */ {? c = (b>= 0) ? b - 1 - (-1-a) % (b) : - ((-a) % (-b));
? }
? return c;
}


for a < 0 and b < 0, it returns - ((-a) % (-b));.
which isn't exactly a % b as far as I know.

But if you consider my rewritten mod64 function, which I believe I tested thoroughly:

int64
__stdcall
m3_mod64(int64 b, int64 a)
{
? typedef? int64 ST; /* signed type */
? typedef uint64 UT; /* unsigned type */
? int aneg = (a < 0);
? int bneg = (b < 0);
? if (aneg == bneg || a == 0 || b == 0)
??? return (a % b);
? else
? {
??? UT ua = (aneg ? M3_POS(UT, a) : (UT)a);
??? UT ub = (bneg ? M3_POS(UT, b) : (UT)b);
??? a = (ST)(ub - 1 - (ua + ub - 1) % ub);
??? return (bneg ? -a : a);
? }
}



It seems 64bit floor mod doesn't work on ARM, so I'm putting back calling functions, sometimes -- only for 64bit mod on ARM.
div also if I found it is needed.
All other targets will keep using gcc's builtin support, whatever that is.


I guess I'll just have to go back and make sure there is test coverage here and compare release with head.


?- Jay

 		 	   		  

From darko at darko.org  Sat Jun 19 11:15:17 2010
From: darko at darko.org (Darko)
Date: Sat, 19 Jun 2010 02:15:17 -0700
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <5E055C3D-78F6-4C08-86D9-8B8CA86B11A1@darko.org>
References: <1274350133.8902.0.camel@localhost>, , , ,
	<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>, , , ,
	<2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>, , ,
	<COL101-W580FCB4C956AC658A851ABE6C00@phx.gbl>, , ,
	<44CCDCF6-BACE-4B58-A1F5-EF68A852E2A5@darko.org>, ,
	<COL101-W493D8FFD71EB43948CBE8CE6C10@phx.gbl>, ,
	<B4638299-A29A-454B-9931-4F296F9AD3DB@darko.org>,
	<COL101-W7F2C05F30E9F3525E482DE6C10@phx.gbl>,
	<ED46DCAD-C84A-488C-BF6F-70CA1F24AF3B@darko.org>
	<COL101-W5474F17968788325FFA76CE6C10@phx.gbl>
	<5E055C3D-78F6-4C08-86D9-8B8CA86B11A1@darko.org>
Message-ID: <C76EF524-6048-4C61-9744-6797BBA6C552@darko.org>

I should also mention that the Android SDK has a QEMU based emulator for testing applications and the adb (Android Bridge) tool can provide shell access.


On 19/06/2010, at 12:13 AM, Darko wrote:

I got the first Debian image on http://www.oszoo.org/wiki/index.php/Category:ARM_images to run with a GUI, and it connect to the network. I'm using Q on my 2.4Ghz MacBook 13" and it's surprisingly fast. Note that it's a 10GB image (450MB download).

There are also images for Debian MIPS on that site too.

I agree that the new MacBook trackpad is not perfect and since moving from my previous machine that had a separate button I now get a lot of stray gestures doing odd things. The general solution is not to use the button at all and use taps. The new momentum scrolling with the gesture is neat but needs more "weight". Unfortunately Apple crosses over into form-over-function territory from time to time and this is one of those times.


On 18/06/2010, at 11:18 PM, Jay K wrote:


XP when I can; nothing else comes close for searching and editing text, I've tried many.
 Visual C++ 5.0.
 I recently learned how to copy/paste in vi, which helps, but I'm not sure I remember now.


Darwin/amd64 when I need/want posix/fastfork, which unfortunately is often.
 Cygwin is slow.
 TextWrangler usually there, though it is awful compared to Visual C++ 5.0.
 KomodoEdit is cross platform but also fairly impaired.
ssh access to a variety
Linux=Debian, it has among the best support for a variety of platforms.
Gentoo comes close or better (ppc64) but I've never been able to get it to install -- booting always fails.
Debian/x86 easy to get cross compiler, qemu, etc.


X Windows apps are never very good imho, so just give up and make do with the even worse command line..
I find things as basic as scrollbars do not work well -- which button do I press when?
The Modula-3 GUI apps suffer from this problem as well.
 Further damage due to needing three buttons but not having them.


Mouse button clicking is actually broken on modern Macs too -- they removed the mouse button from all the laptops, leaving
just a big pad, prone to accidental clicks at any location.. also prone to accidental multitouch gestures due to resting
a twitchy thumb where the button is supposed to be. Amazing, really, the mouse, one of their key initial advantages,
is now broken. (see also Finder and file open dialogs, two other former strengths that are now not so great.)
Multitouch scroll is nice though.


- Jay

----------------------------------------
> From: darko at darko.org
> Date: Fri, 18 Jun 2010 22:55:24 -0700
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Linux/ARM? Android?
> 
> Yeah I've got it working on the console but I agree it needs the network.
> 
> Try: http://www.oszoo.org/wiki/index.php/Category:ARM_images
> Also: http://www.armedslack.org/
> 
> What platform are you running on these days?
> 
> 
> 
> 
> On 18/06/2010, at 10:44 PM, Jay K wrote:
> 
> 
> Interesting, thanks.
> But it looks like it needs to use local console for output?
> I need something over the network/X.
> It looks like there's an qemu option for usemode only too.
> 
> - Jay
> 
> ----------------------------------------
>> From: darko at darko.org
>> Date: Fri, 18 Jun 2010 22:13:43 -0700
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Linux/ARM? Android?
>> 
>> If you use qemu, this might be useful: http://free-electrons.com/community/demos/qemu-arm-directfb/
>> 
>> I'm currently looking at some cheap laptops (around $100) which have ethernet plus screen, keyboard, battery, etc which would work well as hosts. Just trying to find one that runs both Linux and Android.
>> 
>> 
>> On 18/06/2010, at 10:04 PM, Jay K wrote:
>> 
>> 
>> Thanks. I'll give qemu a go as well.
>> Hey, maybe we can get mips also. (there's decent modern mips/linux hardware now, Chinese laptops)
>> 
>> - Jay
>> 
>> ----------------------------------------
>>> From: darko at darko.org
>>> Date: Thu, 17 Jun 2010 21:41:59 -0700
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>> 
>>> Ok, the link here is about 20/4Mbs so it shouldn't be too bad and the latency is good. I'm in Mountain View, CA. Unfortunately the board has only 128MB of main memory but I assume that's enough, I think a self hosted compiler has no point.
>>> 
>>> I'll post the details when it's up and running.
>>> 
>>> 
>>> On 17/06/2010, at 9:15 PM, Jay K wrote:
>>> 
>>> 
>>> My preference would be if you can set it up on the internet and allow me ssh access.
>>> gcc only recently got support for Android's C library "bionic", I believe post-gcc 4.5.
>>> I'm not sure if that matters much or not.
>>> I'm not sure how much the C library of the target matters to gcc.
>>> 
>>> 
>>> Anything with pthreads and gcc support is quite easy to port to these days. In the past the biggest thing you had to do was rewrite /usr/include in Modula-3. There was a tendency to rewrite far more of it than necessary. These days, none of it is needed.
>>> 
>>> 
>>> Now you just have to
>>> - pick a target name
>>> - find the jmpbuf size, word size, endian
>>> - write a much small "config" file
>>> - respond to each error that occurs -- fill in the platform in a few tables sprinkled around the tree
>>> 
>>> 
>>> Even systems without pthreads or with not very good pthreads (OpenBSD) are easy now, as the user thread support is much more portable. It used to be, for user threads, you had to poke around in the jmpbuf.
>>> 
>>> 
>>> I would encourage anyone else to try it out.
>>> 
>>> 
>>> Maybe soon there will be a C generating backend, and we'll just have one distribution format that is a bunch of C, and then gcc support won't even be needed (e.g. IA64_NT).
>>> 
>>> 
>>> Thanks,
>>> - Jay
>>> 
>>> ----------------------------------------
>>>> From: darko at darko.org
>>>> Date: Thu, 17 Jun 2010 18:08:14 -0700
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>> 
>>>> I've been interested in an ARM port for some time. If you (or anyone else) are interested in doing the port I can send you one of these, which looks like a good platform since it runs Linux and Android, has 512K memory and looks well supported: http://beagleboard.org/hardware
>>>> 
>>>> 
>>>> 
>>>> On 20/05/2010, at 4:47 AM, 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?
>>>>> 
>>>> 
>>>> 
>>> 
>> 
>> 
> 
> 
		 	   		  




From jay.krell at cornell.edu  Sat Jun 19 11:51:50 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 19 Jun 2010 09:51:50 +0000
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <C76EF524-6048-4C61-9744-6797BBA6C552@darko.org>
References: <1274350133.8902.0.camel@localhost>, , ,
	,,<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>, , ,
	,,<2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>, ,
	,,<COL101-W580FCB4C956AC658A851ABE6C00@phx.gbl>, ,
	,,<44CCDCF6-BACE-4B58-A1F5-EF68A852E2A5@darko.org>,
	,,<COL101-W493D8FFD71EB43948CBE8CE6C10@phx.gbl>,
	, , <B4638299-A29A-454B-9931-4F296F9AD3DB@darko.org>, ,
	<COL101-W7F2C05F30E9F3525E482DE6C10@phx.gbl>, ,
	<ED46DCAD-C84A-488C-BF6F-70CA1F24AF3B@darko.org>,
	<COL101-W5474F17968788325FFA76CE6C10@phx.gbl>,
	<5E055C3D-78F6-4C08-86D9-8B8CA86B11A1@darko.org>,
	<C76EF524-6048-4C61-9744-6797BBA6C552@darko.org>
Message-ID: <COL101-W31787A72294920C0484E63E6C10@phx.gbl>


Eh I guess I should try that then. Ok. Thanks. Gotta take a break for a while.
?cd wherever 
?cvs -z3 upd -dAP? 
?cd scripts/python? 
?./boot1.py ARMEL_LINUX? 
? => cm3-boot-ARMEL_LINUX...tgz 
? extract that on a machine with cross tools (e.g. arm-linux-gnueabi-gcc, arm-linux-gnueabi-as), possibly the same machine as already on 
? cd into it? 
? make? 
? => arm cm3 


I got that far.
I can't claim it is right for Android.


Then put that cm3 onto a real (or emulated) ARM system and...
(cvs checkout, put the cm3 in /cm3/bin or such, add that to $PATH, and scripts/python/boot2.sh)


Moving forward to gcc 4.5 will get us atomics for ARM, sort of, at least on Linux, see:
?http://gcc.gnu.org/wiki/Atomic 


?- Jay

----------------------------------------
> From: darko at darko.org
> Date: Sat, 19 Jun 2010 02:15:17 -0700
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Linux/ARM? Android?
>
> I should also mention that the Android SDK has a QEMU based emulator for testing applications and the adb (Android Bridge) tool can provide shell access.
>
>
> On 19/06/2010, at 12:13 AM, Darko wrote:
>
> I got the first Debian image on http://www.oszoo.org/wiki/index.php/Category:ARM_images to run with a GUI, and it connect to the network. I'm using Q on my 2.4Ghz MacBook 13" and it's surprisingly fast. Note that it's a 10GB image (450MB download).
>
> There are also images for Debian MIPS on that site too.
>
> I agree that the new MacBook trackpad is not perfect and since moving from my previous machine that had a separate button I now get a lot of stray gestures doing odd things. The general solution is not to use the button at all and use taps. The new momentum scrolling with the gesture is neat but needs more "weight". Unfortunately Apple crosses over into form-over-function territory from time to time and this is one of those times.
>
>
> On 18/06/2010, at 11:18 PM, Jay K wrote:
>
>
> XP when I can; nothing else comes close for searching and editing text, I've tried many.
> Visual C++ 5.0.
> I recently learned how to copy/paste in vi, which helps, but I'm not sure I remember now.
>
>
> Darwin/amd64 when I need/want posix/fastfork, which unfortunately is often.
> Cygwin is slow.
> TextWrangler usually there, though it is awful compared to Visual C++ 5.0.
> KomodoEdit is cross platform but also fairly impaired.
> ssh access to a variety
> Linux=Debian, it has among the best support for a variety of platforms.
> Gentoo comes close or better (ppc64) but I've never been able to get it to install -- booting always fails.
> Debian/x86 easy to get cross compiler, qemu, etc.
>
>
> X Windows apps are never very good imho, so just give up and make do with the even worse command line..
> I find things as basic as scrollbars do not work well -- which button do I press when?
> The Modula-3 GUI apps suffer from this problem as well.
> Further damage due to needing three buttons but not having them.
>
>
> Mouse button clicking is actually broken on modern Macs too -- they removed the mouse button from all the laptops, leaving
> just a big pad, prone to accidental clicks at any location.. also prone to accidental multitouch gestures due to resting
> a twitchy thumb where the button is supposed to be. Amazing, really, the mouse, one of their key initial advantages,
> is now broken. (see also Finder and file open dialogs, two other former strengths that are now not so great.)
> Multitouch scroll is nice though.
>
>
> - Jay
>
> ----------------------------------------
>> From: darko at darko.org
>> Date: Fri, 18 Jun 2010 22:55:24 -0700
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Linux/ARM? Android?
>>
>> Yeah I've got it working on the console but I agree it needs the network.
>>
>> Try: http://www.oszoo.org/wiki/index.php/Category:ARM_images
>> Also: http://www.armedslack.org/
>>
>> What platform are you running on these days?
>>
>>
>>
>>
>> On 18/06/2010, at 10:44 PM, Jay K wrote:
>>
>>
>> Interesting, thanks.
>> But it looks like it needs to use local console for output?
>> I need something over the network/X.
>> It looks like there's an qemu option for usemode only too.
>>
>> - Jay
>>
>> ----------------------------------------
>>> From: darko at darko.org
>>> Date: Fri, 18 Jun 2010 22:13:43 -0700
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>
>>> If you use qemu, this might be useful: http://free-electrons.com/community/demos/qemu-arm-directfb/
>>>
>>> I'm currently looking at some cheap laptops (around $100) which have ethernet plus screen, keyboard, battery, etc which would work well as hosts. Just trying to find one that runs both Linux and Android.
>>>
>>>
>>> On 18/06/2010, at 10:04 PM, Jay K wrote:
>>>
>>>
>>> Thanks. I'll give qemu a go as well.
>>> Hey, maybe we can get mips also. (there's decent modern mips/linux hardware now, Chinese laptops)
>>>
>>> - Jay
>>>
>>> ----------------------------------------
>>>> From: darko at darko.org
>>>> Date: Thu, 17 Jun 2010 21:41:59 -0700
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>
>>>> Ok, the link here is about 20/4Mbs so it shouldn't be too bad and the latency is good. I'm in Mountain View, CA. Unfortunately the board has only 128MB of main memory but I assume that's enough, I think a self hosted compiler has no point.
>>>>
>>>> I'll post the details when it's up and running.
>>>>
>>>>
>>>> On 17/06/2010, at 9:15 PM, Jay K wrote:
>>>>
>>>>
>>>> My preference would be if you can set it up on the internet and allow me ssh access.
>>>> gcc only recently got support for Android's C library "bionic", I believe post-gcc 4.5.
>>>> I'm not sure if that matters much or not.
>>>> I'm not sure how much the C library of the target matters to gcc.
>>>>
>>>>
>>>> Anything with pthreads and gcc support is quite easy to port to these days. In the past the biggest thing you had to do was rewrite /usr/include in Modula-3. There was a tendency to rewrite far more of it than necessary. These days, none of it is needed.
>>>>
>>>>
>>>> Now you just have to
>>>> - pick a target name
>>>> - find the jmpbuf size, word size, endian
>>>> - write a much small "config" file
>>>> - respond to each error that occurs -- fill in the platform in a few tables sprinkled around the tree
>>>>
>>>>
>>>> Even systems without pthreads or with not very good pthreads (OpenBSD) are easy now, as the user thread support is much more portable. It used to be, for user threads, you had to poke around in the jmpbuf.
>>>>
>>>>
>>>> I would encourage anyone else to try it out.
>>>>
>>>>
>>>> Maybe soon there will be a C generating backend, and we'll just have one distribution format that is a bunch of C, and then gcc support won't even be needed (e.g. IA64_NT).
>>>>
>>>>
>>>> Thanks,
>>>> - Jay
>>>>
>>>> ----------------------------------------
>>>>> From: darko at darko.org
>>>>> Date: Thu, 17 Jun 2010 18:08:14 -0700
>>>>> To: jay.krell at cornell.edu
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>>
>>>>> I've been interested in an ARM port for some time. If you (or anyone else) are interested in doing the port I can send you one of these, which looks like a good platform since it runs Linux and Android, has 512K memory and looks well supported: http://beagleboard.org/hardware
>>>>>
>>>>>
>>>>>
>>>>> On 20/05/2010, at 4:47 AM, 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?
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>
>
>
 		 	   		  

From jay.krell at cornell.edu  Sat Jun 19 12:29:23 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 19 Jun 2010 10:29:23 +0000
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <C76EF524-6048-4C61-9744-6797BBA6C552@darko.org>
References: <1274350133.8902.0.camel@localhost>, ,
	,,,,<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>, ,
	,,,,<2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>,
	,,,,<COL101-W580FCB4C956AC658A851ABE6C00@phx.gbl>,
	, , , , <44CCDCF6-BACE-4B58-A1F5-EF68A852E2A5@darko.org>, , , ,
	<COL101-W493D8FFD71EB43948CBE8CE6C10@phx.gbl>, , , ,
	<B4638299-A29A-454B-9931-4F296F9AD3DB@darko.org>, ,
	<COL101-W7F2C05F30E9F3525E482DE6C10@phx.gbl>, ,
	<ED46DCAD-C84A-488C-BF6F-70CA1F24AF3B@darko.org>,
	<COL101-W5474F17968788325FFA76CE6C10@phx.gbl>,
	<5E055C3D-78F6-4C08-86D9-8B8CA86B11A1@darko.org>,
	<C76EF524-6048-4C61-9744-6797BBA6C552@darko.org>
Message-ID: <COL101-W18EA6CF8E4C3963769265EE6C10@phx.gbl>


Interesting to notice that they have their own pthread library..related to how I suggested we implement Modula-3 threads on top of Linux kernel interfaces instead of pthreads..

?- Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: darko at darko.org
> CC: m3devel at elegosoft.com
> Subject: RE: [M3devel] Linux/ARM? Android?
> Date: Sat, 19 Jun 2010 09:51:50 +0000
>
>
> Eh I guess I should try that then. Ok. Thanks. Gotta take a break for a while.
>  cd wherever
>  cvs -z3 upd -dAP
>  cd scripts/python
>  ./boot1.py ARMEL_LINUX
>   => cm3-boot-ARMEL_LINUX...tgz
>   extract that on a machine with cross tools (e.g. arm-linux-gnueabi-gcc, arm-linux-gnueabi-as), possibly the same machine as already on
>   cd into it
>   make
>   => arm cm3
>
>
> I got that far.
> I can't claim it is right for Android.
>
>
> Then put that cm3 onto a real (or emulated) ARM system and...
> (cvs checkout, put the cm3 in /cm3/bin or such, add that to $PATH, and scripts/python/boot2.sh)
>
>
> Moving forward to gcc 4.5 will get us atomics for ARM, sort of, at least on Linux, see:
>  http://gcc.gnu.org/wiki/Atomic
>
>
>  - Jay
>
> ----------------------------------------
>> From: darko at darko.org
>> Date: Sat, 19 Jun 2010 02:15:17 -0700
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Linux/ARM? Android?
>>
>> I should also mention that the Android SDK has a QEMU based emulator for testing applications and the adb (Android Bridge) tool can provide shell access.
>>
>>
>> On 19/06/2010, at 12:13 AM, Darko wrote:
>>
>> I got the first Debian image on http://www.oszoo.org/wiki/index.php/Category:ARM_images to run with a GUI, and it connect to the network. I'm using Q on my 2.4Ghz MacBook 13" and it's surprisingly fast. Note that it's a 10GB image (450MB download).
>>
>> There are also images for Debian MIPS on that site too.
>>
>> I agree that the new MacBook trackpad is not perfect and since moving from my previous machine that had a separate button I now get a lot of stray gestures doing odd things. The general solution is not to use the button at all and use taps. The new momentum scrolling with the gesture is neat but needs more "weight". Unfortunately Apple crosses over into form-over-function territory from time to time and this is one of those times.
>>
>>
>> On 18/06/2010, at 11:18 PM, Jay K wrote:
>>
>>
>> XP when I can; nothing else comes close for searching and editing text, I've tried many.
>> Visual C++ 5.0.
>> I recently learned how to copy/paste in vi, which helps, but I'm not sure I remember now.
>>
>>
>> Darwin/amd64 when I need/want posix/fastfork, which unfortunately is often.
>> Cygwin is slow.
>> TextWrangler usually there, though it is awful compared to Visual C++ 5.0.
>> KomodoEdit is cross platform but also fairly impaired.
>> ssh access to a variety
>> Linux=Debian, it has among the best support for a variety of platforms.
>> Gentoo comes close or better (ppc64) but I've never been able to get it to install -- booting always fails.
>> Debian/x86 easy to get cross compiler, qemu, etc.
>>
>>
>> X Windows apps are never very good imho, so just give up and make do with the even worse command line..
>> I find things as basic as scrollbars do not work well -- which button do I press when?
>> The Modula-3 GUI apps suffer from this problem as well.
>> Further damage due to needing three buttons but not having them.
>>
>>
>> Mouse button clicking is actually broken on modern Macs too -- they removed the mouse button from all the laptops, leaving
>> just a big pad, prone to accidental clicks at any location.. also prone to accidental multitouch gestures due to resting
>> a twitchy thumb where the button is supposed to be. Amazing, really, the mouse, one of their key initial advantages,
>> is now broken. (see also Finder and file open dialogs, two other former strengths that are now not so great.)
>> Multitouch scroll is nice though.
>>
>>
>> - Jay
>>
>> ----------------------------------------
>>> From: darko at darko.org
>>> Date: Fri, 18 Jun 2010 22:55:24 -0700
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>
>>> Yeah I've got it working on the console but I agree it needs the network.
>>>
>>> Try: http://www.oszoo.org/wiki/index.php/Category:ARM_images
>>> Also: http://www.armedslack.org/
>>>
>>> What platform are you running on these days?
>>>
>>>
>>>
>>>
>>> On 18/06/2010, at 10:44 PM, Jay K wrote:
>>>
>>>
>>> Interesting, thanks.
>>> But it looks like it needs to use local console for output?
>>> I need something over the network/X.
>>> It looks like there's an qemu option for usemode only too.
>>>
>>> - Jay
>>>
>>> ----------------------------------------
>>>> From: darko at darko.org
>>>> Date: Fri, 18 Jun 2010 22:13:43 -0700
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>
>>>> If you use qemu, this might be useful: http://free-electrons.com/community/demos/qemu-arm-directfb/
>>>>
>>>> I'm currently looking at some cheap laptops (around $100) which have ethernet plus screen, keyboard, battery, etc which would work well as hosts. Just trying to find one that runs both Linux and Android.
>>>>
>>>>
>>>> On 18/06/2010, at 10:04 PM, Jay K wrote:
>>>>
>>>>
>>>> Thanks. I'll give qemu a go as well.
>>>> Hey, maybe we can get mips also. (there's decent modern mips/linux hardware now, Chinese laptops)
>>>>
>>>> - Jay
>>>>
>>>> ----------------------------------------
>>>>> From: darko at darko.org
>>>>> Date: Thu, 17 Jun 2010 21:41:59 -0700
>>>>> To: jay.krell at cornell.edu
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>>
>>>>> Ok, the link here is about 20/4Mbs so it shouldn't be too bad and the latency is good. I'm in Mountain View, CA. Unfortunately the board has only 128MB of main memory but I assume that's enough, I think a self hosted compiler has no point.
>>>>>
>>>>> I'll post the details when it's up and running.
>>>>>
>>>>>
>>>>> On 17/06/2010, at 9:15 PM, Jay K wrote:
>>>>>
>>>>>
>>>>> My preference would be if you can set it up on the internet and allow me ssh access.
>>>>> gcc only recently got support for Android's C library "bionic", I believe post-gcc 4.5.
>>>>> I'm not sure if that matters much or not.
>>>>> I'm not sure how much the C library of the target matters to gcc.
>>>>>
>>>>>
>>>>> Anything with pthreads and gcc support is quite easy to port to these days. In the past the biggest thing you had to do was rewrite /usr/include in Modula-3. There was a tendency to rewrite far more of it than necessary. These days, none of it is needed.
>>>>>
>>>>>
>>>>> Now you just have to
>>>>> - pick a target name
>>>>> - find the jmpbuf size, word size, endian
>>>>> - write a much small "config" file
>>>>> - respond to each error that occurs -- fill in the platform in a few tables sprinkled around the tree
>>>>>
>>>>>
>>>>> Even systems without pthreads or with not very good pthreads (OpenBSD) are easy now, as the user thread support is much more portable. It used to be, for user threads, you had to poke around in the jmpbuf.
>>>>>
>>>>>
>>>>> I would encourage anyone else to try it out.
>>>>>
>>>>>
>>>>> Maybe soon there will be a C generating backend, and we'll just have one distribution format that is a bunch of C, and then gcc support won't even be needed (e.g. IA64_NT).
>>>>>
>>>>>
>>>>> Thanks,
>>>>> - Jay
>>>>>
>>>>> ----------------------------------------
>>>>>> From: darko at darko.org
>>>>>> Date: Thu, 17 Jun 2010 18:08:14 -0700
>>>>>> To: jay.krell at cornell.edu
>>>>>> CC: m3devel at elegosoft.com
>>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>>>
>>>>>> I've been interested in an ARM port for some time. If you (or anyone else) are interested in doing the port I can send you one of these, which looks like a good platform since it runs Linux and Android, has 512K memory and looks well supported: http://beagleboard.org/hardware
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 20/05/2010, at 4:47 AM, 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?
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>
 		 	   		  

From darko at darko.org  Sat Jun 19 12:32:33 2010
From: darko at darko.org (Darko)
Date: Sat, 19 Jun 2010 03:32:33 -0700
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <COL101-W18EA6CF8E4C3963769265EE6C10@phx.gbl>
References: <1274350133.8902.0.camel@localhost>, , , , , ,
	<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>, , , , , ,
	<2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>, , , , ,
	<COL101-W580FCB4C956AC658A851ABE6C00@phx.gbl>, , , , ,
	<44CCDCF6-BACE-4B58-A1F5-EF68A852E2A5@darko.org>, , , ,
	<COL101-W493D8FFD71EB43948CBE8CE6C10@phx.gbl>, , , ,
	<B4638299-A29A-454B-9931-4F296F9AD3DB@darko.org>, ,
	<COL101-W7F2C05F30E9F3525E482DE6C10@phx.gbl>, ,
	<ED46DCAD-C84A-488C-BF6F-70CA1F24AF3B@darko.org>,
	<COL101-W5474F17968788325FFA76CE6C10@phx.gbl>,
	<5E055C3D-78F6-4C08-86D9-8B8CA86B11A1@darko.org>,
	<C76EF524-6048-4C61-9744-6797BBA6C552@darko.org>
	<COL101-W18EA6CF8E4C3963769265EE6C10@phx.gbl>
Message-ID: <8F3CF5B8-4F17-4D43-AB51-BF960B05BA80@darko.org>

Has it got something to do with integration with Java?

On 19/06/2010, at 3:29 AM, Jay K wrote:


Interesting to notice that they have their own pthread library..related to how I suggested we implement Modula-3 threads on top of Linux kernel interfaces instead of pthreads..

 - Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: darko at darko.org
> CC: m3devel at elegosoft.com
> Subject: RE: [M3devel] Linux/ARM? Android?
> Date: Sat, 19 Jun 2010 09:51:50 +0000
> 
> 
> Eh I guess I should try that then. Ok. Thanks. Gotta take a break for a while.
> cd wherever
> cvs -z3 upd -dAP
> cd scripts/python
> ./boot1.py ARMEL_LINUX
>  => cm3-boot-ARMEL_LINUX...tgz
>  extract that on a machine with cross tools (e.g. arm-linux-gnueabi-gcc, arm-linux-gnueabi-as), possibly the same machine as already on
>  cd into it
>  make
>  => arm cm3
> 
> 
> I got that far.
> I can't claim it is right for Android.
> 
> 
> Then put that cm3 onto a real (or emulated) ARM system and...
> (cvs checkout, put the cm3 in /cm3/bin or such, add that to $PATH, and scripts/python/boot2.sh)
> 
> 
> Moving forward to gcc 4.5 will get us atomics for ARM, sort of, at least on Linux, see:
> http://gcc.gnu.org/wiki/Atomic
> 
> 
> - Jay
> 
> ----------------------------------------
>> From: darko at darko.org
>> Date: Sat, 19 Jun 2010 02:15:17 -0700
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Linux/ARM? Android?
>> 
>> I should also mention that the Android SDK has a QEMU based emulator for testing applications and the adb (Android Bridge) tool can provide shell access.
>> 
>> 
>> On 19/06/2010, at 12:13 AM, Darko wrote:
>> 
>> I got the first Debian image on http://www.oszoo.org/wiki/index.php/Category:ARM_images to run with a GUI, and it connect to the network. I'm using Q on my 2.4Ghz MacBook 13" and it's surprisingly fast. Note that it's a 10GB image (450MB download).
>> 
>> There are also images for Debian MIPS on that site too.
>> 
>> I agree that the new MacBook trackpad is not perfect and since moving from my previous machine that had a separate button I now get a lot of stray gestures doing odd things. The general solution is not to use the button at all and use taps. The new momentum scrolling with the gesture is neat but needs more "weight". Unfortunately Apple crosses over into form-over-function territory from time to time and this is one of those times.
>> 
>> 
>> On 18/06/2010, at 11:18 PM, Jay K wrote:
>> 
>> 
>> XP when I can; nothing else comes close for searching and editing text, I've tried many.
>> Visual C++ 5.0.
>> I recently learned how to copy/paste in vi, which helps, but I'm not sure I remember now.
>> 
>> 
>> Darwin/amd64 when I need/want posix/fastfork, which unfortunately is often.
>> Cygwin is slow.
>> TextWrangler usually there, though it is awful compared to Visual C++ 5.0.
>> KomodoEdit is cross platform but also fairly impaired.
>> ssh access to a variety
>> Linux=Debian, it has among the best support for a variety of platforms.
>> Gentoo comes close or better (ppc64) but I've never been able to get it to install -- booting always fails.
>> Debian/x86 easy to get cross compiler, qemu, etc.
>> 
>> 
>> X Windows apps are never very good imho, so just give up and make do with the even worse command line..
>> I find things as basic as scrollbars do not work well -- which button do I press when?
>> The Modula-3 GUI apps suffer from this problem as well.
>> Further damage due to needing three buttons but not having them.
>> 
>> 
>> Mouse button clicking is actually broken on modern Macs too -- they removed the mouse button from all the laptops, leaving
>> just a big pad, prone to accidental clicks at any location.. also prone to accidental multitouch gestures due to resting
>> a twitchy thumb where the button is supposed to be. Amazing, really, the mouse, one of their key initial advantages,
>> is now broken. (see also Finder and file open dialogs, two other former strengths that are now not so great.)
>> Multitouch scroll is nice though.
>> 
>> 
>> - Jay
>> 
>> ----------------------------------------
>>> From: darko at darko.org
>>> Date: Fri, 18 Jun 2010 22:55:24 -0700
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>> 
>>> Yeah I've got it working on the console but I agree it needs the network.
>>> 
>>> Try: http://www.oszoo.org/wiki/index.php/Category:ARM_images
>>> Also: http://www.armedslack.org/
>>> 
>>> What platform are you running on these days?
>>> 
>>> 
>>> 
>>> 
>>> On 18/06/2010, at 10:44 PM, Jay K wrote:
>>> 
>>> 
>>> Interesting, thanks.
>>> But it looks like it needs to use local console for output?
>>> I need something over the network/X.
>>> It looks like there's an qemu option for usemode only too.
>>> 
>>> - Jay
>>> 
>>> ----------------------------------------
>>>> From: darko at darko.org
>>>> Date: Fri, 18 Jun 2010 22:13:43 -0700
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>> 
>>>> If you use qemu, this might be useful: http://free-electrons.com/community/demos/qemu-arm-directfb/
>>>> 
>>>> I'm currently looking at some cheap laptops (around $100) which have ethernet plus screen, keyboard, battery, etc which would work well as hosts. Just trying to find one that runs both Linux and Android.
>>>> 
>>>> 
>>>> On 18/06/2010, at 10:04 PM, Jay K wrote:
>>>> 
>>>> 
>>>> Thanks. I'll give qemu a go as well.
>>>> Hey, maybe we can get mips also. (there's decent modern mips/linux hardware now, Chinese laptops)
>>>> 
>>>> - Jay
>>>> 
>>>> ----------------------------------------
>>>>> From: darko at darko.org
>>>>> Date: Thu, 17 Jun 2010 21:41:59 -0700
>>>>> To: jay.krell at cornell.edu
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>> 
>>>>> Ok, the link here is about 20/4Mbs so it shouldn't be too bad and the latency is good. I'm in Mountain View, CA. Unfortunately the board has only 128MB of main memory but I assume that's enough, I think a self hosted compiler has no point.
>>>>> 
>>>>> I'll post the details when it's up and running.
>>>>> 
>>>>> 
>>>>> On 17/06/2010, at 9:15 PM, Jay K wrote:
>>>>> 
>>>>> 
>>>>> My preference would be if you can set it up on the internet and allow me ssh access.
>>>>> gcc only recently got support for Android's C library "bionic", I believe post-gcc 4.5.
>>>>> I'm not sure if that matters much or not.
>>>>> I'm not sure how much the C library of the target matters to gcc.
>>>>> 
>>>>> 
>>>>> Anything with pthreads and gcc support is quite easy to port to these days. In the past the biggest thing you had to do was rewrite /usr/include in Modula-3. There was a tendency to rewrite far more of it than necessary. These days, none of it is needed.
>>>>> 
>>>>> 
>>>>> Now you just have to
>>>>> - pick a target name
>>>>> - find the jmpbuf size, word size, endian
>>>>> - write a much small "config" file
>>>>> - respond to each error that occurs -- fill in the platform in a few tables sprinkled around the tree
>>>>> 
>>>>> 
>>>>> Even systems without pthreads or with not very good pthreads (OpenBSD) are easy now, as the user thread support is much more portable. It used to be, for user threads, you had to poke around in the jmpbuf.
>>>>> 
>>>>> 
>>>>> I would encourage anyone else to try it out.
>>>>> 
>>>>> 
>>>>> Maybe soon there will be a C generating backend, and we'll just have one distribution format that is a bunch of C, and then gcc support won't even be needed (e.g. IA64_NT).
>>>>> 
>>>>> 
>>>>> Thanks,
>>>>> - Jay
>>>>> 
>>>>> ----------------------------------------
>>>>>> From: darko at darko.org
>>>>>> Date: Thu, 17 Jun 2010 18:08:14 -0700
>>>>>> To: jay.krell at cornell.edu
>>>>>> CC: m3devel at elegosoft.com
>>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>>> 
>>>>>> I've been interested in an ARM port for some time. If you (or anyone else) are interested in doing the port I can send you one of these, which looks like a good platform since it runs Linux and Android, has 512K memory and looks well supported: http://beagleboard.org/hardware
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On 20/05/2010, at 4:47 AM, 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?
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
>> 
> 
		 	   		  



From jay.krell at cornell.edu  Sat Jun 19 18:56:54 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 19 Jun 2010 16:56:54 +0000
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <8F3CF5B8-4F17-4D43-AB51-BF960B05BA80@darko.org>
References: <1274350133.8902.0.camel@localhost>, , , , ,
	,,<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>, , , , ,
	,,<2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>, , , ,
	,,<COL101-W580FCB4C956AC658A851ABE6C00@phx.gbl>, , , ,
	,,<44CCDCF6-BACE-4B58-A1F5-EF68A852E2A5@darko.org>, , ,
	,,<COL101-W493D8FFD71EB43948CBE8CE6C10@phx.gbl>, , ,
	,,<B4638299-A29A-454B-9931-4F296F9AD3DB@darko.org>,
	,,<COL101-W7F2C05F30E9F3525E482DE6C10@phx.gbl>,
	, , <ED46DCAD-C84A-488C-BF6F-70CA1F24AF3B@darko.org>, ,
	<COL101-W5474F17968788325FFA76CE6C10@phx.gbl>, ,
	<5E055C3D-78F6-4C08-86D9-8B8CA86B11A1@darko.org>, ,
	<C76EF524-6048-4C61-9744-6797BBA6C552@darko.org>,
	<COL101-W18EA6CF8E4C3963769265EE6C10@phx.gbl>,
	<8F3CF5B8-4F17-4D43-AB51-BF960B05BA80@darko.org>
Message-ID: <COL101-W84E06E7B4D04EE7BE3FC8E6C10@phx.gbl>


I don't think so. Replacing glibc is a popular activity, mostly for efficiency.
See android-ndk-r4/docs/system/libc/overview.txt.

Even Debian no longer uses glibc, sort of.
http://www.osnews.com/story/21441/Debian_Switching_to_EGLIBC
http://www.eglibc.org/home

?- Jay

----------------------------------------
> From: darko at darko.org
> Date: Sat, 19 Jun 2010 03:32:33 -0700
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Linux/ARM? Android?
>
> Has it got something to do with integration with Java?
>
> On 19/06/2010, at 3:29 AM, Jay K wrote:
>
>
> Interesting to notice that they have their own pthread library..related to how I suggested we implement Modula-3 threads on top of Linux kernel interfaces instead of pthreads..
>
> - Jay
>
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: darko at darko.org
>> CC: m3devel at elegosoft.com
>> Subject: RE: [M3devel] Linux/ARM? Android?
>> Date: Sat, 19 Jun 2010 09:51:50 +0000
>>
>>
>> Eh I guess I should try that then. Ok. Thanks. Gotta take a break for a while.
>> cd wherever
>> cvs -z3 upd -dAP
>> cd scripts/python
>> ./boot1.py ARMEL_LINUX
>> => cm3-boot-ARMEL_LINUX...tgz
>> extract that on a machine with cross tools (e.g. arm-linux-gnueabi-gcc, arm-linux-gnueabi-as), possibly the same machine as already on
>> cd into it
>> make
>> => arm cm3
>>
>>
>> I got that far.
>> I can't claim it is right for Android.
>>
>>
>> Then put that cm3 onto a real (or emulated) ARM system and...
>> (cvs checkout, put the cm3 in /cm3/bin or such, add that to $PATH, and scripts/python/boot2.sh)
>>
>>
>> Moving forward to gcc 4.5 will get us atomics for ARM, sort of, at least on Linux, see:
>> http://gcc.gnu.org/wiki/Atomic
>>
>>
>> - Jay
>>
>> ----------------------------------------
>>> From: darko at darko.org
>>> Date: Sat, 19 Jun 2010 02:15:17 -0700
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>
>>> I should also mention that the Android SDK has a QEMU based emulator for testing applications and the adb (Android Bridge) tool can provide shell access.
>>>
>>>
>>> On 19/06/2010, at 12:13 AM, Darko wrote:
>>>
>>> I got the first Debian image on http://www.oszoo.org/wiki/index.php/Category:ARM_images to run with a GUI, and it connect to the network. I'm using Q on my 2.4Ghz MacBook 13" and it's surprisingly fast. Note that it's a 10GB image (450MB download).
>>>
>>> There are also images for Debian MIPS on that site too.
>>>
>>> I agree that the new MacBook trackpad is not perfect and since moving from my previous machine that had a separate button I now get a lot of stray gestures doing odd things. The general solution is not to use the button at all and use taps. The new momentum scrolling with the gesture is neat but needs more "weight". Unfortunately Apple crosses over into form-over-function territory from time to time and this is one of those times.
>>>
>>>
>>> On 18/06/2010, at 11:18 PM, Jay K wrote:
>>>
>>>
>>> XP when I can; nothing else comes close for searching and editing text, I've tried many.
>>> Visual C++ 5.0.
>>> I recently learned how to copy/paste in vi, which helps, but I'm not sure I remember now.
>>>
>>>
>>> Darwin/amd64 when I need/want posix/fastfork, which unfortunately is often.
>>> Cygwin is slow.
>>> TextWrangler usually there, though it is awful compared to Visual C++ 5.0.
>>> KomodoEdit is cross platform but also fairly impaired.
>>> ssh access to a variety
>>> Linux=Debian, it has among the best support for a variety of platforms.
>>> Gentoo comes close or better (ppc64) but I've never been able to get it to install -- booting always fails.
>>> Debian/x86 easy to get cross compiler, qemu, etc.
>>>
>>>
>>> X Windows apps are never very good imho, so just give up and make do with the even worse command line..
>>> I find things as basic as scrollbars do not work well -- which button do I press when?
>>> The Modula-3 GUI apps suffer from this problem as well.
>>> Further damage due to needing three buttons but not having them.
>>>
>>>
>>> Mouse button clicking is actually broken on modern Macs too -- they removed the mouse button from all the laptops, leaving
>>> just a big pad, prone to accidental clicks at any location.. also prone to accidental multitouch gestures due to resting
>>> a twitchy thumb where the button is supposed to be. Amazing, really, the mouse, one of their key initial advantages,
>>> is now broken. (see also Finder and file open dialogs, two other former strengths that are now not so great.)
>>> Multitouch scroll is nice though.
>>>
>>>
>>> - Jay
>>>
>>> ----------------------------------------
>>>> From: darko at darko.org
>>>> Date: Fri, 18 Jun 2010 22:55:24 -0700
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>
>>>> Yeah I've got it working on the console but I agree it needs the network.
>>>>
>>>> Try: http://www.oszoo.org/wiki/index.php/Category:ARM_images
>>>> Also: http://www.armedslack.org/
>>>>
>>>> What platform are you running on these days?
>>>>
>>>>
>>>>
>>>>
>>>> On 18/06/2010, at 10:44 PM, Jay K wrote:
>>>>
>>>>
>>>> Interesting, thanks.
>>>> But it looks like it needs to use local console for output?
>>>> I need something over the network/X.
>>>> It looks like there's an qemu option for usemode only too.
>>>>
>>>> - Jay
>>>>
>>>> ----------------------------------------
>>>>> From: darko at darko.org
>>>>> Date: Fri, 18 Jun 2010 22:13:43 -0700
>>>>> To: jay.krell at cornell.edu
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>>
>>>>> If you use qemu, this might be useful: http://free-electrons.com/community/demos/qemu-arm-directfb/
>>>>>
>>>>> I'm currently looking at some cheap laptops (around $100) which have ethernet plus screen, keyboard, battery, etc which would work well as hosts. Just trying to find one that runs both Linux and Android.
>>>>>
>>>>>
>>>>> On 18/06/2010, at 10:04 PM, Jay K wrote:
>>>>>
>>>>>
>>>>> Thanks. I'll give qemu a go as well.
>>>>> Hey, maybe we can get mips also. (there's decent modern mips/linux hardware now, Chinese laptops)
>>>>>
>>>>> - Jay
>>>>>
>>>>> ----------------------------------------
>>>>>> From: darko at darko.org
>>>>>> Date: Thu, 17 Jun 2010 21:41:59 -0700
>>>>>> To: jay.krell at cornell.edu
>>>>>> CC: m3devel at elegosoft.com
>>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>>>
>>>>>> Ok, the link here is about 20/4Mbs so it shouldn't be too bad and the latency is good. I'm in Mountain View, CA. Unfortunately the board has only 128MB of main memory but I assume that's enough, I think a self hosted compiler has no point.
>>>>>>
>>>>>> I'll post the details when it's up and running.
>>>>>>
>>>>>>
>>>>>> On 17/06/2010, at 9:15 PM, Jay K wrote:
>>>>>>
>>>>>>
>>>>>> My preference would be if you can set it up on the internet and allow me ssh access.
>>>>>> gcc only recently got support for Android's C library "bionic", I believe post-gcc 4.5.
>>>>>> I'm not sure if that matters much or not.
>>>>>> I'm not sure how much the C library of the target matters to gcc.
>>>>>>
>>>>>>
>>>>>> Anything with pthreads and gcc support is quite easy to port to these days. In the past the biggest thing you had to do was rewrite /usr/include in Modula-3. There was a tendency to rewrite far more of it than necessary. These days, none of it is needed.
>>>>>>
>>>>>>
>>>>>> Now you just have to
>>>>>> - pick a target name
>>>>>> - find the jmpbuf size, word size, endian
>>>>>> - write a much small "config" file
>>>>>> - respond to each error that occurs -- fill in the platform in a few tables sprinkled around the tree
>>>>>>
>>>>>>
>>>>>> Even systems without pthreads or with not very good pthreads (OpenBSD) are easy now, as the user thread support is much more portable. It used to be, for user threads, you had to poke around in the jmpbuf.
>>>>>>
>>>>>>
>>>>>> I would encourage anyone else to try it out.
>>>>>>
>>>>>>
>>>>>> Maybe soon there will be a C generating backend, and we'll just have one distribution format that is a bunch of C, and then gcc support won't even be needed (e.g. IA64_NT).
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> - Jay
>>>>>>
>>>>>> ----------------------------------------
>>>>>>> From: darko at darko.org
>>>>>>> Date: Thu, 17 Jun 2010 18:08:14 -0700
>>>>>>> To: jay.krell at cornell.edu
>>>>>>> CC: m3devel at elegosoft.com
>>>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>>>>
>>>>>>> I've been interested in an ARM port for some time. If you (or anyone else) are interested in doing the port I can send you one of these, which looks like a good platform since it runs Linux and Android, has 512K memory and looks well supported: http://beagleboard.org/hardware
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 20/05/2010, at 4:47 AM, 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?
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>
>
 		 	   		  

From darko at darko.org  Sun Jun 20 00:47:24 2010
From: darko at darko.org (Darko)
Date: Sat, 19 Jun 2010 15:47:24 -0700
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <COL101-W31787A72294920C0484E63E6C10@phx.gbl>
References: <1274350133.8902.0.camel@localhost>, , , , ,
	<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>, , , , ,
	<2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>, , , ,
	<COL101-W580FCB4C956AC658A851ABE6C00@phx.gbl>, , , ,
	<44CCDCF6-BACE-4B58-A1F5-EF68A852E2A5@darko.org>, , ,
	<COL101-W493D8FFD71EB43948CBE8CE6C10@phx.gbl>, , ,
	<B4638299-A29A-454B-9931-4F296F9AD3DB@darko.org>, ,
	<COL101-W7F2C05F30E9F3525E482DE6C10@phx.gbl>, ,
	<ED46DCAD-C84A-488C-BF6F-70CA1F24AF3B@darko.org>,
	<COL101-W5474F17968788325FFA76CE6C10@phx.gbl>,
	<5E055C3D-78F6-4C08-86D9-8B8CA86B11A1@darko.org>,
	<C76EF524-6048-4C61-9744-6797BBA6C552@darko.org>
	<COL101-W31787A72294920C0484E63E6C10@phx.gbl>
Message-ID: <C1506F07-DE5E-4712-B15E-CB220A087D1A@darko.org>

Fantasic, thanks. There are some ARM cross tools available under DarwinPorts which I'm going to give this a try with.


On 19/06/2010, at 2:51 AM, Jay K wrote:


Eh I guess I should try that then. Ok. Thanks. Gotta take a break for a while.
 cd wherever 
 cvs -z3 upd -dAP  
 cd scripts/python  
 ./boot1.py ARMEL_LINUX  
  => cm3-boot-ARMEL_LINUX...tgz 
  extract that on a machine with cross tools (e.g. arm-linux-gnueabi-gcc, arm-linux-gnueabi-as), possibly the same machine as already on 
  cd into it  
  make  
  => arm cm3 


I got that far.
I can't claim it is right for Android.


Then put that cm3 onto a real (or emulated) ARM system and...
(cvs checkout, put the cm3 in /cm3/bin or such, add that to $PATH, and scripts/python/boot2.sh)


Moving forward to gcc 4.5 will get us atomics for ARM, sort of, at least on Linux, see:
 http://gcc.gnu.org/wiki/Atomic 


 - Jay

----------------------------------------
> From: darko at darko.org
> Date: Sat, 19 Jun 2010 02:15:17 -0700
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Linux/ARM? Android?
> 
> I should also mention that the Android SDK has a QEMU based emulator for testing applications and the adb (Android Bridge) tool can provide shell access.
> 
> 
> On 19/06/2010, at 12:13 AM, Darko wrote:
> 
> I got the first Debian image on http://www.oszoo.org/wiki/index.php/Category:ARM_images to run with a GUI, and it connect to the network. I'm using Q on my 2.4Ghz MacBook 13" and it's surprisingly fast. Note that it's a 10GB image (450MB download).
> 
> There are also images for Debian MIPS on that site too.
> 
> I agree that the new MacBook trackpad is not perfect and since moving from my previous machine that had a separate button I now get a lot of stray gestures doing odd things. The general solution is not to use the button at all and use taps. The new momentum scrolling with the gesture is neat but needs more "weight". Unfortunately Apple crosses over into form-over-function territory from time to time and this is one of those times.
> 
> 
> On 18/06/2010, at 11:18 PM, Jay K wrote:
> 
> 
> XP when I can; nothing else comes close for searching and editing text, I've tried many.
> Visual C++ 5.0.
> I recently learned how to copy/paste in vi, which helps, but I'm not sure I remember now.
> 
> 
> Darwin/amd64 when I need/want posix/fastfork, which unfortunately is often.
> Cygwin is slow.
> TextWrangler usually there, though it is awful compared to Visual C++ 5.0.
> KomodoEdit is cross platform but also fairly impaired.
> ssh access to a variety
> Linux=Debian, it has among the best support for a variety of platforms.
> Gentoo comes close or better (ppc64) but I've never been able to get it to install -- booting always fails.
> Debian/x86 easy to get cross compiler, qemu, etc.
> 
> 
> X Windows apps are never very good imho, so just give up and make do with the even worse command line..
> I find things as basic as scrollbars do not work well -- which button do I press when?
> The Modula-3 GUI apps suffer from this problem as well.
> Further damage due to needing three buttons but not having them.
> 
> 
> Mouse button clicking is actually broken on modern Macs too -- they removed the mouse button from all the laptops, leaving
> just a big pad, prone to accidental clicks at any location.. also prone to accidental multitouch gestures due to resting
> a twitchy thumb where the button is supposed to be. Amazing, really, the mouse, one of their key initial advantages,
> is now broken. (see also Finder and file open dialogs, two other former strengths that are now not so great.)
> Multitouch scroll is nice though.
> 
> 
> - Jay
> 
> ----------------------------------------
>> From: darko at darko.org
>> Date: Fri, 18 Jun 2010 22:55:24 -0700
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Linux/ARM? Android?
>> 
>> Yeah I've got it working on the console but I agree it needs the network.
>> 
>> Try: http://www.oszoo.org/wiki/index.php/Category:ARM_images
>> Also: http://www.armedslack.org/
>> 
>> What platform are you running on these days?
>> 
>> 
>> 
>> 
>> On 18/06/2010, at 10:44 PM, Jay K wrote:
>> 
>> 
>> Interesting, thanks.
>> But it looks like it needs to use local console for output?
>> I need something over the network/X.
>> It looks like there's an qemu option for usemode only too.
>> 
>> - Jay
>> 
>> ----------------------------------------
>>> From: darko at darko.org
>>> Date: Fri, 18 Jun 2010 22:13:43 -0700
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>> 
>>> If you use qemu, this might be useful: http://free-electrons.com/community/demos/qemu-arm-directfb/
>>> 
>>> I'm currently looking at some cheap laptops (around $100) which have ethernet plus screen, keyboard, battery, etc which would work well as hosts. Just trying to find one that runs both Linux and Android.
>>> 
>>> 
>>> On 18/06/2010, at 10:04 PM, Jay K wrote:
>>> 
>>> 
>>> Thanks. I'll give qemu a go as well.
>>> Hey, maybe we can get mips also. (there's decent modern mips/linux hardware now, Chinese laptops)
>>> 
>>> - Jay
>>> 
>>> ----------------------------------------
>>>> From: darko at darko.org
>>>> Date: Thu, 17 Jun 2010 21:41:59 -0700
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>> 
>>>> Ok, the link here is about 20/4Mbs so it shouldn't be too bad and the latency is good. I'm in Mountain View, CA. Unfortunately the board has only 128MB of main memory but I assume that's enough, I think a self hosted compiler has no point.
>>>> 
>>>> I'll post the details when it's up and running.
>>>> 
>>>> 
>>>> On 17/06/2010, at 9:15 PM, Jay K wrote:
>>>> 
>>>> 
>>>> My preference would be if you can set it up on the internet and allow me ssh access.
>>>> gcc only recently got support for Android's C library "bionic", I believe post-gcc 4.5.
>>>> I'm not sure if that matters much or not.
>>>> I'm not sure how much the C library of the target matters to gcc.
>>>> 
>>>> 
>>>> Anything with pthreads and gcc support is quite easy to port to these days. In the past the biggest thing you had to do was rewrite /usr/include in Modula-3. There was a tendency to rewrite far more of it than necessary. These days, none of it is needed.
>>>> 
>>>> 
>>>> Now you just have to
>>>> - pick a target name
>>>> - find the jmpbuf size, word size, endian
>>>> - write a much small "config" file
>>>> - respond to each error that occurs -- fill in the platform in a few tables sprinkled around the tree
>>>> 
>>>> 
>>>> Even systems without pthreads or with not very good pthreads (OpenBSD) are easy now, as the user thread support is much more portable. It used to be, for user threads, you had to poke around in the jmpbuf.
>>>> 
>>>> 
>>>> I would encourage anyone else to try it out.
>>>> 
>>>> 
>>>> Maybe soon there will be a C generating backend, and we'll just have one distribution format that is a bunch of C, and then gcc support won't even be needed (e.g. IA64_NT).
>>>> 
>>>> 
>>>> Thanks,
>>>> - Jay
>>>> 
>>>> ----------------------------------------
>>>>> From: darko at darko.org
>>>>> Date: Thu, 17 Jun 2010 18:08:14 -0700
>>>>> To: jay.krell at cornell.edu
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>> 
>>>>> I've been interested in an ARM port for some time. If you (or anyone else) are interested in doing the port I can send you one of these, which looks like a good platform since it runs Linux and Android, has 512K memory and looks well supported: http://beagleboard.org/hardware
>>>>> 
>>>>> 
>>>>> 
>>>>> On 20/05/2010, at 4:47 AM, 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?
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
> 
> 
> 
		 	   		  



From jay.krell at cornell.edu  Sun Jun 20 01:42:16 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 19 Jun 2010 23:42:16 +0000
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <C1506F07-DE5E-4712-B15E-CB220A087D1A@darko.org>
References: <1274350133.8902.0.camel@localhost>, , , ,
	,,<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>, , , ,
	,,<2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>, , ,
	,,<COL101-W580FCB4C956AC658A851ABE6C00@phx.gbl>, , ,
	,,<44CCDCF6-BACE-4B58-A1F5-EF68A852E2A5@darko.org>, ,
	,,<COL101-W493D8FFD71EB43948CBE8CE6C10@phx.gbl>, ,
	,,<B4638299-A29A-454B-9931-4F296F9AD3DB@darko.org>,
	,,<COL101-W7F2C05F30E9F3525E482DE6C10@phx.gbl>,
	, , <ED46DCAD-C84A-488C-BF6F-70CA1F24AF3B@darko.org>, ,
	<COL101-W5474F17968788325FFA76CE6C10@phx.gbl>, ,
	<5E055C3D-78F6-4C08-86D9-8B8CA86B11A1@darko.org>, ,
	<C76EF524-6048-4C61-9744-6797BBA6C552@darko.org>,
	<COL101-W31787A72294920C0484E63E6C10@phx.gbl>,
	<C1506F07-DE5E-4712-B15E-CB220A087D1A@darko.org>
Message-ID: <COL101-W29BA9D3680CFB903430A43E6C10@phx.gbl>


I should point out, actually, with cross gcc/as, you should be able to easily enough build the whole system cross.
ie: your apps instead of cm3.
I can try that -- building the whole tree cross, including compiling C and linking.


Notice m3-sys/cminstall/src/config-no-install/ARMEL_LINUX:


SYSTEM_CC = "arm-linux-gnueabi-gcc -gstabs+ -fPIC" % C compiler
SYSTEM_ASM = "arm-linux-gnueabi-as" % Assembler


I get to:
jay at xlin2:~/cm3-boot-ARMEL_LINUX-d5.8.2-20100619$ file cm3
cm3: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.14, not stripped
jay at xlin2:~/cm3-boot-ARMEL_LINUX-d5.8.2-20100619$ qemu-arm ./cm3
/lib/ld-linux.so.3: No such file or directory


My QEmu setup isn't complete..


I got the crosstools from hereabouts:
? http://www.emdebian.org/tools/crosstools.html


crosstool, scratchbox, buildroot may also be good options.


This reminds me though, I have a Western Digital MyBook World Edition.
Haven't powered it on in a while, slightly flaky device.
But it runs Linux/arm (oldabi).
I could/should power it on or get a new one something.


Also note/reminder, Android seems a bit different, at least in terms of finding C headers and libraries, maybe not for generating assembly, than "regular" Linux/arm.
Really "Linux/arm" seems a pretty fractured thing.
Newer architectures have floating point, for one thing.


?- Jay

----------------------------------------
> From: darko at darko.org
> Date: Sat, 19 Jun 2010 15:47:24 -0700
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Linux/ARM? Android?
>
> Fantasic, thanks. There are some ARM cross tools available under DarwinPorts which I'm going to give this a try with.
>
>
> On 19/06/2010, at 2:51 AM, Jay K wrote:
>
>
> Eh I guess I should try that then. Ok. Thanks. Gotta take a break for a while.
> cd wherever
> cvs -z3 upd -dAP
> cd scripts/python
> ./boot1.py ARMEL_LINUX
> => cm3-boot-ARMEL_LINUX...tgz
> extract that on a machine with cross tools (e.g. arm-linux-gnueabi-gcc, arm-linux-gnueabi-as), possibly the same machine as already on
> cd into it
> make
> => arm cm3
>
>
> I got that far.
> I can't claim it is right for Android.
>
>
> Then put that cm3 onto a real (or emulated) ARM system and...
> (cvs checkout, put the cm3 in /cm3/bin or such, add that to $PATH, and scripts/python/boot2.sh)
>
>
> Moving forward to gcc 4.5 will get us atomics for ARM, sort of, at least on Linux, see:
> http://gcc.gnu.org/wiki/Atomic
>
>
> - Jay
>
> ----------------------------------------
>> From: darko at darko.org
>> Date: Sat, 19 Jun 2010 02:15:17 -0700
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Linux/ARM? Android?
>>
>> I should also mention that the Android SDK has a QEMU based emulator for testing applications and the adb (Android Bridge) tool can provide shell access.
>>
>>
>> On 19/06/2010, at 12:13 AM, Darko wrote:
>>
>> I got the first Debian image on http://www.oszoo.org/wiki/index.php/Category:ARM_images to run with a GUI, and it connect to the network. I'm using Q on my 2.4Ghz MacBook 13" and it's surprisingly fast. Note that it's a 10GB image (450MB download).
>>
>> There are also images for Debian MIPS on that site too.
>>
>> I agree that the new MacBook trackpad is not perfect and since moving from my previous machine that had a separate button I now get a lot of stray gestures doing odd things. The general solution is not to use the button at all and use taps. The new momentum scrolling with the gesture is neat but needs more "weight". Unfortunately Apple crosses over into form-over-function territory from time to time and this is one of those times.
>>
>>
>> On 18/06/2010, at 11:18 PM, Jay K wrote:
>>
>>
>> XP when I can; nothing else comes close for searching and editing text, I've tried many.
>> Visual C++ 5.0.
>> I recently learned how to copy/paste in vi, which helps, but I'm not sure I remember now.
>>
>>
>> Darwin/amd64 when I need/want posix/fastfork, which unfortunately is often.
>> Cygwin is slow.
>> TextWrangler usually there, though it is awful compared to Visual C++ 5.0.
>> KomodoEdit is cross platform but also fairly impaired.
>> ssh access to a variety
>> Linux=Debian, it has among the best support for a variety of platforms.
>> Gentoo comes close or better (ppc64) but I've never been able to get it to install -- booting always fails.
>> Debian/x86 easy to get cross compiler, qemu, etc.
>>
>>
>> X Windows apps are never very good imho, so just give up and make do with the even worse command line..
>> I find things as basic as scrollbars do not work well -- which button do I press when?
>> The Modula-3 GUI apps suffer from this problem as well.
>> Further damage due to needing three buttons but not having them.
>>
>>
>> Mouse button clicking is actually broken on modern Macs too -- they removed the mouse button from all the laptops, leaving
>> just a big pad, prone to accidental clicks at any location.. also prone to accidental multitouch gestures due to resting
>> a twitchy thumb where the button is supposed to be. Amazing, really, the mouse, one of their key initial advantages,
>> is now broken. (see also Finder and file open dialogs, two other former strengths that are now not so great.)
>> Multitouch scroll is nice though.
>>
>>
>> - Jay
>>
>> ----------------------------------------
>>> From: darko at darko.org
>>> Date: Fri, 18 Jun 2010 22:55:24 -0700
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>
>>> Yeah I've got it working on the console but I agree it needs the network.
>>>
>>> Try: http://www.oszoo.org/wiki/index.php/Category:ARM_images
>>> Also: http://www.armedslack.org/
>>>
>>> What platform are you running on these days?
>>>
>>>
>>>
>>>
>>> On 18/06/2010, at 10:44 PM, Jay K wrote:
>>>
>>>
>>> Interesting, thanks.
>>> But it looks like it needs to use local console for output?
>>> I need something over the network/X.
>>> It looks like there's an qemu option for usemode only too.
>>>
>>> - Jay
>>>
>>> ----------------------------------------
>>>> From: darko at darko.org
>>>> Date: Fri, 18 Jun 2010 22:13:43 -0700
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>
>>>> If you use qemu, this might be useful: http://free-electrons.com/community/demos/qemu-arm-directfb/
>>>>
>>>> I'm currently looking at some cheap laptops (around $100) which have ethernet plus screen, keyboard, battery, etc which would work well as hosts. Just trying to find one that runs both Linux and Android.
>>>>
>>>>
>>>> On 18/06/2010, at 10:04 PM, Jay K wrote:
>>>>
>>>>
>>>> Thanks. I'll give qemu a go as well.
>>>> Hey, maybe we can get mips also. (there's decent modern mips/linux hardware now, Chinese laptops)
>>>>
>>>> - Jay
>>>>
>>>> ----------------------------------------
>>>>> From: darko at darko.org
>>>>> Date: Thu, 17 Jun 2010 21:41:59 -0700
>>>>> To: jay.krell at cornell.edu
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>>
>>>>> Ok, the link here is about 20/4Mbs so it shouldn't be too bad and the latency is good. I'm in Mountain View, CA. Unfortunately the board has only 128MB of main memory but I assume that's enough, I think a self hosted compiler has no point.
>>>>>
>>>>> I'll post the details when it's up and running.
>>>>>
>>>>>
>>>>> On 17/06/2010, at 9:15 PM, Jay K wrote:
>>>>>
>>>>>
>>>>> My preference would be if you can set it up on the internet and allow me ssh access.
>>>>> gcc only recently got support for Android's C library "bionic", I believe post-gcc 4.5.
>>>>> I'm not sure if that matters much or not.
>>>>> I'm not sure how much the C library of the target matters to gcc.
>>>>>
>>>>>
>>>>> Anything with pthreads and gcc support is quite easy to port to these days. In the past the biggest thing you had to do was rewrite /usr/include in Modula-3. There was a tendency to rewrite far more of it than necessary. These days, none of it is needed.
>>>>>
>>>>>
>>>>> Now you just have to
>>>>> - pick a target name
>>>>> - find the jmpbuf size, word size, endian
>>>>> - write a much small "config" file
>>>>> - respond to each error that occurs -- fill in the platform in a few tables sprinkled around the tree
>>>>>
>>>>>
>>>>> Even systems without pthreads or with not very good pthreads (OpenBSD) are easy now, as the user thread support is much more portable. It used to be, for user threads, you had to poke around in the jmpbuf.
>>>>>
>>>>>
>>>>> I would encourage anyone else to try it out.
>>>>>
>>>>>
>>>>> Maybe soon there will be a C generating backend, and we'll just have one distribution format that is a bunch of C, and then gcc support won't even be needed (e.g. IA64_NT).
>>>>>
>>>>>
>>>>> Thanks,
>>>>> - Jay
>>>>>
>>>>> ----------------------------------------
>>>>>> From: darko at darko.org
>>>>>> Date: Thu, 17 Jun 2010 18:08:14 -0700
>>>>>> To: jay.krell at cornell.edu
>>>>>> CC: m3devel at elegosoft.com
>>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>>>
>>>>>> I've been interested in an ARM port for some time. If you (or anyone else) are interested in doing the port I can send you one of these, which looks like a good platform since it runs Linux and Android, has 512K memory and looks well supported: http://beagleboard.org/hardware
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 20/05/2010, at 4:47 AM, 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?
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>
>
 		 	   		  

From darko at darko.org  Sun Jun 20 02:06:11 2010
From: darko at darko.org (Darko)
Date: Sat, 19 Jun 2010 17:06:11 -0700
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <COL101-W29BA9D3680CFB903430A43E6C10@phx.gbl>
References: <1274350133.8902.0.camel@localhost>, , , , , ,
	<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>, , , , , ,
	<2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>, , , , ,
	<COL101-W580FCB4C956AC658A851ABE6C00@phx.gbl>, , , , ,
	<44CCDCF6-BACE-4B58-A1F5-EF68A852E2A5@darko.org>, , , ,
	<COL101-W493D8FFD71EB43948CBE8CE6C10@phx.gbl>, , , ,
	<B4638299-A29A-454B-9931-4F296F9AD3DB@darko.org>, , ,
	<COL101-W7F2C05F30E9F3525E482DE6C10@phx.gbl>, , ,
	<ED46DCAD-C84A-488C-BF6F-70CA1F24AF3B@darko.org>, ,
	<COL101-W5474F17968788325FFA76CE6C10@phx.gbl>, ,
	<5E055C3D-78F6-4C08-86D9-8B8CA86B11A1@darko.org>, ,
	<C76EF524-6048-4C61-9744-6797BBA6C552@darko.org>,
	<COL101-W31787A72294920C0484E63E6C10@phx.gbl>,
	<C1506F07-DE5E-4712-B15E-CB220A087D1A@darko.org>
	<COL101-W29BA9D3680CFB903430A43E6C10@phx.gbl>
Message-ID: <6DCF6CCC-D3D3-4777-9585-243366375634@darko.org>

A fully crossed system would be the goal since mostly the target devices are ARM are phones, tablets and embedded devices. What distribution are you running on QEmu? Is it the Lenny-lxde one?

Linux/ARM is definitely fractured because of the variety of ARM cores, SoC chips and devices on which it's used. I'm not sure what the best way to approach it is.


On 19/06/2010, at 4:42 PM, Jay K wrote:


I should point out, actually, with cross gcc/as, you should be able to easily enough build the whole system cross.
ie: your apps instead of cm3.
I can try that -- building the whole tree cross, including compiling C and linking.


Notice m3-sys/cminstall/src/config-no-install/ARMEL_LINUX:


SYSTEM_CC = "arm-linux-gnueabi-gcc -gstabs+ -fPIC" % C compiler
SYSTEM_ASM = "arm-linux-gnueabi-as" % Assembler


I get to:
jay at xlin2:~/cm3-boot-ARMEL_LINUX-d5.8.2-20100619$ file cm3
cm3: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.14, not stripped
jay at xlin2:~/cm3-boot-ARMEL_LINUX-d5.8.2-20100619$ qemu-arm ./cm3
/lib/ld-linux.so.3: No such file or directory


My QEmu setup isn't complete..


I got the crosstools from hereabouts:
  http://www.emdebian.org/tools/crosstools.html


crosstool, scratchbox, buildroot may also be good options.


This reminds me though, I have a Western Digital MyBook World Edition.
Haven't powered it on in a while, slightly flaky device.
But it runs Linux/arm (oldabi).
I could/should power it on or get a new one something.


Also note/reminder, Android seems a bit different, at least in terms of finding C headers and libraries, maybe not for generating assembly, than "regular" Linux/arm.
Really "Linux/arm" seems a pretty fractured thing.
Newer architectures have floating point, for one thing.


 - Jay

----------------------------------------
> From: darko at darko.org
> Date: Sat, 19 Jun 2010 15:47:24 -0700
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Linux/ARM? Android?
> 
> Fantasic, thanks. There are some ARM cross tools available under DarwinPorts which I'm going to give this a try with.
> 
> 
> On 19/06/2010, at 2:51 AM, Jay K wrote:
> 
> 
> Eh I guess I should try that then. Ok. Thanks. Gotta take a break for a while.
> cd wherever
> cvs -z3 upd -dAP
> cd scripts/python
> ./boot1.py ARMEL_LINUX
> => cm3-boot-ARMEL_LINUX...tgz
> extract that on a machine with cross tools (e.g. arm-linux-gnueabi-gcc, arm-linux-gnueabi-as), possibly the same machine as already on
> cd into it
> make
> => arm cm3
> 
> 
> I got that far.
> I can't claim it is right for Android.
> 
> 
> Then put that cm3 onto a real (or emulated) ARM system and...
> (cvs checkout, put the cm3 in /cm3/bin or such, add that to $PATH, and scripts/python/boot2.sh)
> 
> 
> Moving forward to gcc 4.5 will get us atomics for ARM, sort of, at least on Linux, see:
> http://gcc.gnu.org/wiki/Atomic
> 
> 
> - Jay
> 
> ----------------------------------------
>> From: darko at darko.org
>> Date: Sat, 19 Jun 2010 02:15:17 -0700
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Linux/ARM? Android?
>> 
>> I should also mention that the Android SDK has a QEMU based emulator for testing applications and the adb (Android Bridge) tool can provide shell access.
>> 
>> 
>> On 19/06/2010, at 12:13 AM, Darko wrote:
>> 
>> I got the first Debian image on http://www.oszoo.org/wiki/index.php/Category:ARM_images to run with a GUI, and it connect to the network. I'm using Q on my 2.4Ghz MacBook 13" and it's surprisingly fast. Note that it's a 10GB image (450MB download).
>> 
>> There are also images for Debian MIPS on that site too.
>> 
>> I agree that the new MacBook trackpad is not perfect and since moving from my previous machine that had a separate button I now get a lot of stray gestures doing odd things. The general solution is not to use the button at all and use taps. The new momentum scrolling with the gesture is neat but needs more "weight". Unfortunately Apple crosses over into form-over-function territory from time to time and this is one of those times.
>> 
>> 
>> On 18/06/2010, at 11:18 PM, Jay K wrote:
>> 
>> 
>> XP when I can; nothing else comes close for searching and editing text, I've tried many.
>> Visual C++ 5.0.
>> I recently learned how to copy/paste in vi, which helps, but I'm not sure I remember now.
>> 
>> 
>> Darwin/amd64 when I need/want posix/fastfork, which unfortunately is often.
>> Cygwin is slow.
>> TextWrangler usually there, though it is awful compared to Visual C++ 5.0.
>> KomodoEdit is cross platform but also fairly impaired.
>> ssh access to a variety
>> Linux=Debian, it has among the best support for a variety of platforms.
>> Gentoo comes close or better (ppc64) but I've never been able to get it to install -- booting always fails.
>> Debian/x86 easy to get cross compiler, qemu, etc.
>> 
>> 
>> X Windows apps are never very good imho, so just give up and make do with the even worse command line..
>> I find things as basic as scrollbars do not work well -- which button do I press when?
>> The Modula-3 GUI apps suffer from this problem as well.
>> Further damage due to needing three buttons but not having them.
>> 
>> 
>> Mouse button clicking is actually broken on modern Macs too -- they removed the mouse button from all the laptops, leaving
>> just a big pad, prone to accidental clicks at any location.. also prone to accidental multitouch gestures due to resting
>> a twitchy thumb where the button is supposed to be. Amazing, really, the mouse, one of their key initial advantages,
>> is now broken. (see also Finder and file open dialogs, two other former strengths that are now not so great.)
>> Multitouch scroll is nice though.
>> 
>> 
>> - Jay
>> 
>> ----------------------------------------
>>> From: darko at darko.org
>>> Date: Fri, 18 Jun 2010 22:55:24 -0700
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>> 
>>> Yeah I've got it working on the console but I agree it needs the network.
>>> 
>>> Try: http://www.oszoo.org/wiki/index.php/Category:ARM_images
>>> Also: http://www.armedslack.org/
>>> 
>>> What platform are you running on these days?
>>> 
>>> 
>>> 
>>> 
>>> On 18/06/2010, at 10:44 PM, Jay K wrote:
>>> 
>>> 
>>> Interesting, thanks.
>>> But it looks like it needs to use local console for output?
>>> I need something over the network/X.
>>> It looks like there's an qemu option for usemode only too.
>>> 
>>> - Jay
>>> 
>>> ----------------------------------------
>>>> From: darko at darko.org
>>>> Date: Fri, 18 Jun 2010 22:13:43 -0700
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>> 
>>>> If you use qemu, this might be useful: http://free-electrons.com/community/demos/qemu-arm-directfb/
>>>> 
>>>> I'm currently looking at some cheap laptops (around $100) which have ethernet plus screen, keyboard, battery, etc which would work well as hosts. Just trying to find one that runs both Linux and Android.
>>>> 
>>>> 
>>>> On 18/06/2010, at 10:04 PM, Jay K wrote:
>>>> 
>>>> 
>>>> Thanks. I'll give qemu a go as well.
>>>> Hey, maybe we can get mips also. (there's decent modern mips/linux hardware now, Chinese laptops)
>>>> 
>>>> - Jay
>>>> 
>>>> ----------------------------------------
>>>>> From: darko at darko.org
>>>>> Date: Thu, 17 Jun 2010 21:41:59 -0700
>>>>> To: jay.krell at cornell.edu
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>> 
>>>>> Ok, the link here is about 20/4Mbs so it shouldn't be too bad and the latency is good. I'm in Mountain View, CA. Unfortunately the board has only 128MB of main memory but I assume that's enough, I think a self hosted compiler has no point.
>>>>> 
>>>>> I'll post the details when it's up and running.
>>>>> 
>>>>> 
>>>>> On 17/06/2010, at 9:15 PM, Jay K wrote:
>>>>> 
>>>>> 
>>>>> My preference would be if you can set it up on the internet and allow me ssh access.
>>>>> gcc only recently got support for Android's C library "bionic", I believe post-gcc 4.5.
>>>>> I'm not sure if that matters much or not.
>>>>> I'm not sure how much the C library of the target matters to gcc.
>>>>> 
>>>>> 
>>>>> Anything with pthreads and gcc support is quite easy to port to these days. In the past the biggest thing you had to do was rewrite /usr/include in Modula-3. There was a tendency to rewrite far more of it than necessary. These days, none of it is needed.
>>>>> 
>>>>> 
>>>>> Now you just have to
>>>>> - pick a target name
>>>>> - find the jmpbuf size, word size, endian
>>>>> - write a much small "config" file
>>>>> - respond to each error that occurs -- fill in the platform in a few tables sprinkled around the tree
>>>>> 
>>>>> 
>>>>> Even systems without pthreads or with not very good pthreads (OpenBSD) are easy now, as the user thread support is much more portable. It used to be, for user threads, you had to poke around in the jmpbuf.
>>>>> 
>>>>> 
>>>>> I would encourage anyone else to try it out.
>>>>> 
>>>>> 
>>>>> Maybe soon there will be a C generating backend, and we'll just have one distribution format that is a bunch of C, and then gcc support won't even be needed (e.g. IA64_NT).
>>>>> 
>>>>> 
>>>>> Thanks,
>>>>> - Jay
>>>>> 
>>>>> ----------------------------------------
>>>>>> From: darko at darko.org
>>>>>> Date: Thu, 17 Jun 2010 18:08:14 -0700
>>>>>> To: jay.krell at cornell.edu
>>>>>> CC: m3devel at elegosoft.com
>>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>>> 
>>>>>> I've been interested in an ARM port for some time. If you (or anyone else) are interested in doing the port I can send you one of these, which looks like a good platform since it runs Linux and Android, has 512K memory and looks well supported: http://beagleboard.org/hardware
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On 20/05/2010, at 4:47 AM, 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?
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
>> 
> 
> 
		 	   		  



From jay.krell at cornell.edu  Sun Jun 20 02:26:04 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 20 Jun 2010 00:26:04 +0000
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <6DCF6CCC-D3D3-4777-9585-243366375634@darko.org>
References: <1274350133.8902.0.camel@localhost>, , , , ,
	,,<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>, , , , ,
	,,<2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>, , , ,
	,,<COL101-W580FCB4C956AC658A851ABE6C00@phx.gbl>, , , ,
	,,<44CCDCF6-BACE-4B58-A1F5-EF68A852E2A5@darko.org>, , ,
	,,<COL101-W493D8FFD71EB43948CBE8CE6C10@phx.gbl>, , ,
	,,<B4638299-A29A-454B-9931-4F296F9AD3DB@darko.org>, ,
	,,<COL101-W7F2C05F30E9F3525E482DE6C10@phx.gbl>, ,
	,,<ED46DCAD-C84A-488C-BF6F-70CA1F24AF3B@darko.org>,
	,,<COL101-W5474F17968788325FFA76CE6C10@phx.gbl>,
	,,<5E055C3D-78F6-4C08-86D9-8B8CA86B11A1@darko.org>,
	, , <C76EF524-6048-4C61-9744-6797BBA6C552@darko.org>, ,
	<COL101-W31787A72294920C0484E63E6C10@phx.gbl>, ,
	<C1506F07-DE5E-4712-B15E-CB220A087D1A@darko.org>,
	<COL101-W29BA9D3680CFB903430A43E6C10@phx.gbl>,
	<6DCF6CCC-D3D3-4777-9585-243366375634@darko.org>
Message-ID: <COL101-W475B32E6802996894EA650E6C20@phx.gbl>


I didn't know what "lxde" is, but Debian 5.0 x86 "Lenny". Minimal install plus apt-get install whatever.

?- Jay

----------------------------------------
> From: darko at darko.org
> Date: Sat, 19 Jun 2010 17:06:11 -0700
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Linux/ARM? Android?
>
> A fully crossed system would be the goal since mostly the target devices are ARM are phones, tablets and embedded devices. What distribution are you running on QEmu? Is it the Lenny-lxde one?
>
> Linux/ARM is definitely fractured because of the variety of ARM cores, SoC chips and devices on which it's used. I'm not sure what the best way to approach it is.
>
>
> On 19/06/2010, at 4:42 PM, Jay K wrote:
>
>
> I should point out, actually, with cross gcc/as, you should be able to easily enough build the whole system cross.
> ie: your apps instead of cm3.
> I can try that -- building the whole tree cross, including compiling C and linking.
>
>
> Notice m3-sys/cminstall/src/config-no-install/ARMEL_LINUX:
>
>
> SYSTEM_CC = "arm-linux-gnueabi-gcc -gstabs+ -fPIC" % C compiler
> SYSTEM_ASM = "arm-linux-gnueabi-as" % Assembler
>
>
> I get to:
> jay at xlin2:~/cm3-boot-ARMEL_LINUX-d5.8.2-20100619$ file cm3
> cm3: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.14, not stripped
> jay at xlin2:~/cm3-boot-ARMEL_LINUX-d5.8.2-20100619$ qemu-arm ./cm3
> /lib/ld-linux.so.3: No such file or directory
>
>
> My QEmu setup isn't complete..
>
>
> I got the crosstools from hereabouts:
> http://www.emdebian.org/tools/crosstools.html
>
>
> crosstool, scratchbox, buildroot may also be good options.
>
>
> This reminds me though, I have a Western Digital MyBook World Edition.
> Haven't powered it on in a while, slightly flaky device.
> But it runs Linux/arm (oldabi).
> I could/should power it on or get a new one something.
>
>
> Also note/reminder, Android seems a bit different, at least in terms of finding C headers and libraries, maybe not for generating assembly, than "regular" Linux/arm.
> Really "Linux/arm" seems a pretty fractured thing.
> Newer architectures have floating point, for one thing.
>
>
> - Jay
>
> ----------------------------------------
>> From: darko at darko.org
>> Date: Sat, 19 Jun 2010 15:47:24 -0700
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Linux/ARM? Android?
>>
>> Fantasic, thanks. There are some ARM cross tools available under DarwinPorts which I'm going to give this a try with.
>>
>>
>> On 19/06/2010, at 2:51 AM, Jay K wrote:
>>
>>
>> Eh I guess I should try that then. Ok. Thanks. Gotta take a break for a while.
>> cd wherever
>> cvs -z3 upd -dAP
>> cd scripts/python
>> ./boot1.py ARMEL_LINUX
>> => cm3-boot-ARMEL_LINUX...tgz
>> extract that on a machine with cross tools (e.g. arm-linux-gnueabi-gcc, arm-linux-gnueabi-as), possibly the same machine as already on
>> cd into it
>> make
>> => arm cm3
>>
>>
>> I got that far.
>> I can't claim it is right for Android.
>>
>>
>> Then put that cm3 onto a real (or emulated) ARM system and...
>> (cvs checkout, put the cm3 in /cm3/bin or such, add that to $PATH, and scripts/python/boot2.sh)
>>
>>
>> Moving forward to gcc 4.5 will get us atomics for ARM, sort of, at least on Linux, see:
>> http://gcc.gnu.org/wiki/Atomic
>>
>>
>> - Jay
>>
>> ----------------------------------------
>>> From: darko at darko.org
>>> Date: Sat, 19 Jun 2010 02:15:17 -0700
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>
>>> I should also mention that the Android SDK has a QEMU based emulator for testing applications and the adb (Android Bridge) tool can provide shell access.
>>>
>>>
>>> On 19/06/2010, at 12:13 AM, Darko wrote:
>>>
>>> I got the first Debian image on http://www.oszoo.org/wiki/index.php/Category:ARM_images to run with a GUI, and it connect to the network. I'm using Q on my 2.4Ghz MacBook 13" and it's surprisingly fast. Note that it's a 10GB image (450MB download).
>>>
>>> There are also images for Debian MIPS on that site too.
>>>
>>> I agree that the new MacBook trackpad is not perfect and since moving from my previous machine that had a separate button I now get a lot of stray gestures doing odd things. The general solution is not to use the button at all and use taps. The new momentum scrolling with the gesture is neat but needs more "weight". Unfortunately Apple crosses over into form-over-function territory from time to time and this is one of those times.
>>>
>>>
>>> On 18/06/2010, at 11:18 PM, Jay K wrote:
>>>
>>>
>>> XP when I can; nothing else comes close for searching and editing text, I've tried many.
>>> Visual C++ 5.0.
>>> I recently learned how to copy/paste in vi, which helps, but I'm not sure I remember now.
>>>
>>>
>>> Darwin/amd64 when I need/want posix/fastfork, which unfortunately is often.
>>> Cygwin is slow.
>>> TextWrangler usually there, though it is awful compared to Visual C++ 5.0.
>>> KomodoEdit is cross platform but also fairly impaired.
>>> ssh access to a variety
>>> Linux=Debian, it has among the best support for a variety of platforms.
>>> Gentoo comes close or better (ppc64) but I've never been able to get it to install -- booting always fails.
>>> Debian/x86 easy to get cross compiler, qemu, etc.
>>>
>>>
>>> X Windows apps are never very good imho, so just give up and make do with the even worse command line..
>>> I find things as basic as scrollbars do not work well -- which button do I press when?
>>> The Modula-3 GUI apps suffer from this problem as well.
>>> Further damage due to needing three buttons but not having them.
>>>
>>>
>>> Mouse button clicking is actually broken on modern Macs too -- they removed the mouse button from all the laptops, leaving
>>> just a big pad, prone to accidental clicks at any location.. also prone to accidental multitouch gestures due to resting
>>> a twitchy thumb where the button is supposed to be. Amazing, really, the mouse, one of their key initial advantages,
>>> is now broken. (see also Finder and file open dialogs, two other former strengths that are now not so great.)
>>> Multitouch scroll is nice though.
>>>
>>>
>>> - Jay
>>>
>>> ----------------------------------------
>>>> From: darko at darko.org
>>>> Date: Fri, 18 Jun 2010 22:55:24 -0700
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>
>>>> Yeah I've got it working on the console but I agree it needs the network.
>>>>
>>>> Try: http://www.oszoo.org/wiki/index.php/Category:ARM_images
>>>> Also: http://www.armedslack.org/
>>>>
>>>> What platform are you running on these days?
>>>>
>>>>
>>>>
>>>>
>>>> On 18/06/2010, at 10:44 PM, Jay K wrote:
>>>>
>>>>
>>>> Interesting, thanks.
>>>> But it looks like it needs to use local console for output?
>>>> I need something over the network/X.
>>>> It looks like there's an qemu option for usemode only too.
>>>>
>>>> - Jay
>>>>
>>>> ----------------------------------------
>>>>> From: darko at darko.org
>>>>> Date: Fri, 18 Jun 2010 22:13:43 -0700
>>>>> To: jay.krell at cornell.edu
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>>
>>>>> If you use qemu, this might be useful: http://free-electrons.com/community/demos/qemu-arm-directfb/
>>>>>
>>>>> I'm currently looking at some cheap laptops (around $100) which have ethernet plus screen, keyboard, battery, etc which would work well as hosts. Just trying to find one that runs both Linux and Android.
>>>>>
>>>>>
>>>>> On 18/06/2010, at 10:04 PM, Jay K wrote:
>>>>>
>>>>>
>>>>> Thanks. I'll give qemu a go as well.
>>>>> Hey, maybe we can get mips also. (there's decent modern mips/linux hardware now, Chinese laptops)
>>>>>
>>>>> - Jay
>>>>>
>>>>> ----------------------------------------
>>>>>> From: darko at darko.org
>>>>>> Date: Thu, 17 Jun 2010 21:41:59 -0700
>>>>>> To: jay.krell at cornell.edu
>>>>>> CC: m3devel at elegosoft.com
>>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>>>
>>>>>> Ok, the link here is about 20/4Mbs so it shouldn't be too bad and the latency is good. I'm in Mountain View, CA. Unfortunately the board has only 128MB of main memory but I assume that's enough, I think a self hosted compiler has no point.
>>>>>>
>>>>>> I'll post the details when it's up and running.
>>>>>>
>>>>>>
>>>>>> On 17/06/2010, at 9:15 PM, Jay K wrote:
>>>>>>
>>>>>>
>>>>>> My preference would be if you can set it up on the internet and allow me ssh access.
>>>>>> gcc only recently got support for Android's C library "bionic", I believe post-gcc 4.5.
>>>>>> I'm not sure if that matters much or not.
>>>>>> I'm not sure how much the C library of the target matters to gcc.
>>>>>>
>>>>>>
>>>>>> Anything with pthreads and gcc support is quite easy to port to these days. In the past the biggest thing you had to do was rewrite /usr/include in Modula-3. There was a tendency to rewrite far more of it than necessary. These days, none of it is needed.
>>>>>>
>>>>>>
>>>>>> Now you just have to
>>>>>> - pick a target name
>>>>>> - find the jmpbuf size, word size, endian
>>>>>> - write a much small "config" file
>>>>>> - respond to each error that occurs -- fill in the platform in a few tables sprinkled around the tree
>>>>>>
>>>>>>
>>>>>> Even systems without pthreads or with not very good pthreads (OpenBSD) are easy now, as the user thread support is much more portable. It used to be, for user threads, you had to poke around in the jmpbuf.
>>>>>>
>>>>>>
>>>>>> I would encourage anyone else to try it out.
>>>>>>
>>>>>>
>>>>>> Maybe soon there will be a C generating backend, and we'll just have one distribution format that is a bunch of C, and then gcc support won't even be needed (e.g. IA64_NT).
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> - Jay
>>>>>>
>>>>>> ----------------------------------------
>>>>>>> From: darko at darko.org
>>>>>>> Date: Thu, 17 Jun 2010 18:08:14 -0700
>>>>>>> To: jay.krell at cornell.edu
>>>>>>> CC: m3devel at elegosoft.com
>>>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>>>>
>>>>>>> I've been interested in an ARM port for some time. If you (or anyone else) are interested in doing the port I can send you one of these, which looks like a good platform since it runs Linux and Android, has 512K memory and looks well supported: http://beagleboard.org/hardware
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 20/05/2010, at 4:47 AM, 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?
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>
 		 	   		  

From darko at darko.org  Sun Jun 20 02:30:12 2010
From: darko at darko.org (Darko)
Date: Sat, 19 Jun 2010 17:30:12 -0700
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <COL101-W475B32E6802996894EA650E6C20@phx.gbl>
References: <1274350133.8902.0.camel@localhost>, , , , , , ,
	<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>, , , , , , ,
	<2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>, , , , , ,
	<COL101-W580FCB4C956AC658A851ABE6C00@phx.gbl>, , , , , ,
	<44CCDCF6-BACE-4B58-A1F5-EF68A852E2A5@darko.org>, , , , ,
	<COL101-W493D8FFD71EB43948CBE8CE6C10@phx.gbl>, , , , ,
	<B4638299-A29A-454B-9931-4F296F9AD3DB@darko.org>, , , ,
	<COL101-W7F2C05F30E9F3525E482DE6C10@phx.gbl>, , , ,
	<ED46DCAD-C84A-488C-BF6F-70CA1F24AF3B@darko.org>, , ,
	<COL101-W5474F17968788325FFA76CE6C10@phx.gbl>, , ,
	<5E055C3D-78F6-4C08-86D9-8B8CA86B11A1@darko.org>, , ,
	<C76EF524-6048-4C61-9744-6797BBA6C552@darko.org>, ,
	<COL101-W31787A72294920C0484E63E6C10@phx.gbl>, ,
	<C1506F07-DE5E-4712-B15E-CB220A087D1A@darko.org>,
	<COL101-W29BA9D3680CFB903430A43E6C10@phx.gbl>,
	<6DCF6CCC-D3D3-4777-9585-243366375634@darko.org>
	<COL101-W475B32E6802996894EA650E6C20@phx.gbl>
Message-ID: <12B75D75-60FC-48DD-9364-2F22E04CA598@darko.org>

I mean as your ARM platform. Which ARM distribution are you running on QEmu?


On 19/06/2010, at 5:26 PM, Jay K wrote:


I didn't know what "lxde" is, but Debian 5.0 x86 "Lenny". Minimal install plus apt-get install whatever.

 - Jay

----------------------------------------
> From: darko at darko.org
> Date: Sat, 19 Jun 2010 17:06:11 -0700
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Linux/ARM? Android?
> 
> A fully crossed system would be the goal since mostly the target devices are ARM are phones, tablets and embedded devices. What distribution are you running on QEmu? Is it the Lenny-lxde one?
> 
> Linux/ARM is definitely fractured because of the variety of ARM cores, SoC chips and devices on which it's used. I'm not sure what the best way to approach it is.
> 
> 
> On 19/06/2010, at 4:42 PM, Jay K wrote:
> 
> 
> I should point out, actually, with cross gcc/as, you should be able to easily enough build the whole system cross.
> ie: your apps instead of cm3.
> I can try that -- building the whole tree cross, including compiling C and linking.
> 
> 
> Notice m3-sys/cminstall/src/config-no-install/ARMEL_LINUX:
> 
> 
> SYSTEM_CC = "arm-linux-gnueabi-gcc -gstabs+ -fPIC" % C compiler
> SYSTEM_ASM = "arm-linux-gnueabi-as" % Assembler
> 
> 
> I get to:
> jay at xlin2:~/cm3-boot-ARMEL_LINUX-d5.8.2-20100619$ file cm3
> cm3: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.14, not stripped
> jay at xlin2:~/cm3-boot-ARMEL_LINUX-d5.8.2-20100619$ qemu-arm ./cm3
> /lib/ld-linux.so.3: No such file or directory
> 
> 
> My QEmu setup isn't complete..
> 
> 
> I got the crosstools from hereabouts:
> http://www.emdebian.org/tools/crosstools.html
> 
> 
> crosstool, scratchbox, buildroot may also be good options.
> 
> 
> This reminds me though, I have a Western Digital MyBook World Edition.
> Haven't powered it on in a while, slightly flaky device.
> But it runs Linux/arm (oldabi).
> I could/should power it on or get a new one something.
> 
> 
> Also note/reminder, Android seems a bit different, at least in terms of finding C headers and libraries, maybe not for generating assembly, than "regular" Linux/arm.
> Really "Linux/arm" seems a pretty fractured thing.
> Newer architectures have floating point, for one thing.
> 
> 
> - Jay
> 
> ----------------------------------------
>> From: darko at darko.org
>> Date: Sat, 19 Jun 2010 15:47:24 -0700
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Linux/ARM? Android?
>> 
>> Fantasic, thanks. There are some ARM cross tools available under DarwinPorts which I'm going to give this a try with.
>> 
>> 
>> On 19/06/2010, at 2:51 AM, Jay K wrote:
>> 
>> 
>> Eh I guess I should try that then. Ok. Thanks. Gotta take a break for a while.
>> cd wherever
>> cvs -z3 upd -dAP
>> cd scripts/python
>> ./boot1.py ARMEL_LINUX
>> => cm3-boot-ARMEL_LINUX...tgz
>> extract that on a machine with cross tools (e.g. arm-linux-gnueabi-gcc, arm-linux-gnueabi-as), possibly the same machine as already on
>> cd into it
>> make
>> => arm cm3
>> 
>> 
>> I got that far.
>> I can't claim it is right for Android.
>> 
>> 
>> Then put that cm3 onto a real (or emulated) ARM system and...
>> (cvs checkout, put the cm3 in /cm3/bin or such, add that to $PATH, and scripts/python/boot2.sh)
>> 
>> 
>> Moving forward to gcc 4.5 will get us atomics for ARM, sort of, at least on Linux, see:
>> http://gcc.gnu.org/wiki/Atomic
>> 
>> 
>> - Jay
>> 
>> ----------------------------------------
>>> From: darko at darko.org
>>> Date: Sat, 19 Jun 2010 02:15:17 -0700
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>> 
>>> I should also mention that the Android SDK has a QEMU based emulator for testing applications and the adb (Android Bridge) tool can provide shell access.
>>> 
>>> 
>>> On 19/06/2010, at 12:13 AM, Darko wrote:
>>> 
>>> I got the first Debian image on http://www.oszoo.org/wiki/index.php/Category:ARM_images to run with a GUI, and it connect to the network. I'm using Q on my 2.4Ghz MacBook 13" and it's surprisingly fast. Note that it's a 10GB image (450MB download).
>>> 
>>> There are also images for Debian MIPS on that site too.
>>> 
>>> I agree that the new MacBook trackpad is not perfect and since moving from my previous machine that had a separate button I now get a lot of stray gestures doing odd things. The general solution is not to use the button at all and use taps. The new momentum scrolling with the gesture is neat but needs more "weight". Unfortunately Apple crosses over into form-over-function territory from time to time and this is one of those times.
>>> 
>>> 
>>> On 18/06/2010, at 11:18 PM, Jay K wrote:
>>> 
>>> 
>>> XP when I can; nothing else comes close for searching and editing text, I've tried many.
>>> Visual C++ 5.0.
>>> I recently learned how to copy/paste in vi, which helps, but I'm not sure I remember now.
>>> 
>>> 
>>> Darwin/amd64 when I need/want posix/fastfork, which unfortunately is often.
>>> Cygwin is slow.
>>> TextWrangler usually there, though it is awful compared to Visual C++ 5.0.
>>> KomodoEdit is cross platform but also fairly impaired.
>>> ssh access to a variety
>>> Linux=Debian, it has among the best support for a variety of platforms.
>>> Gentoo comes close or better (ppc64) but I've never been able to get it to install -- booting always fails.
>>> Debian/x86 easy to get cross compiler, qemu, etc.
>>> 
>>> 
>>> X Windows apps are never very good imho, so just give up and make do with the even worse command line..
>>> I find things as basic as scrollbars do not work well -- which button do I press when?
>>> The Modula-3 GUI apps suffer from this problem as well.
>>> Further damage due to needing three buttons but not having them.
>>> 
>>> 
>>> Mouse button clicking is actually broken on modern Macs too -- they removed the mouse button from all the laptops, leaving
>>> just a big pad, prone to accidental clicks at any location.. also prone to accidental multitouch gestures due to resting
>>> a twitchy thumb where the button is supposed to be. Amazing, really, the mouse, one of their key initial advantages,
>>> is now broken. (see also Finder and file open dialogs, two other former strengths that are now not so great.)
>>> Multitouch scroll is nice though.
>>> 
>>> 
>>> - Jay
>>> 
>>> ----------------------------------------
>>>> From: darko at darko.org
>>>> Date: Fri, 18 Jun 2010 22:55:24 -0700
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>> 
>>>> Yeah I've got it working on the console but I agree it needs the network.
>>>> 
>>>> Try: http://www.oszoo.org/wiki/index.php/Category:ARM_images
>>>> Also: http://www.armedslack.org/
>>>> 
>>>> What platform are you running on these days?
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On 18/06/2010, at 10:44 PM, Jay K wrote:
>>>> 
>>>> 
>>>> Interesting, thanks.
>>>> But it looks like it needs to use local console for output?
>>>> I need something over the network/X.
>>>> It looks like there's an qemu option for usemode only too.
>>>> 
>>>> - Jay
>>>> 
>>>> ----------------------------------------
>>>>> From: darko at darko.org
>>>>> Date: Fri, 18 Jun 2010 22:13:43 -0700
>>>>> To: jay.krell at cornell.edu
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>> 
>>>>> If you use qemu, this might be useful: http://free-electrons.com/community/demos/qemu-arm-directfb/
>>>>> 
>>>>> I'm currently looking at some cheap laptops (around $100) which have ethernet plus screen, keyboard, battery, etc which would work well as hosts. Just trying to find one that runs both Linux and Android.
>>>>> 
>>>>> 
>>>>> On 18/06/2010, at 10:04 PM, Jay K wrote:
>>>>> 
>>>>> 
>>>>> Thanks. I'll give qemu a go as well.
>>>>> Hey, maybe we can get mips also. (there's decent modern mips/linux hardware now, Chinese laptops)
>>>>> 
>>>>> - Jay
>>>>> 
>>>>> ----------------------------------------
>>>>>> From: darko at darko.org
>>>>>> Date: Thu, 17 Jun 2010 21:41:59 -0700
>>>>>> To: jay.krell at cornell.edu
>>>>>> CC: m3devel at elegosoft.com
>>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>>> 
>>>>>> Ok, the link here is about 20/4Mbs so it shouldn't be too bad and the latency is good. I'm in Mountain View, CA. Unfortunately the board has only 128MB of main memory but I assume that's enough, I think a self hosted compiler has no point.
>>>>>> 
>>>>>> I'll post the details when it's up and running.
>>>>>> 
>>>>>> 
>>>>>> On 17/06/2010, at 9:15 PM, Jay K wrote:
>>>>>> 
>>>>>> 
>>>>>> My preference would be if you can set it up on the internet and allow me ssh access.
>>>>>> gcc only recently got support for Android's C library "bionic", I believe post-gcc 4.5.
>>>>>> I'm not sure if that matters much or not.
>>>>>> I'm not sure how much the C library of the target matters to gcc.
>>>>>> 
>>>>>> 
>>>>>> Anything with pthreads and gcc support is quite easy to port to these days. In the past the biggest thing you had to do was rewrite /usr/include in Modula-3. There was a tendency to rewrite far more of it than necessary. These days, none of it is needed.
>>>>>> 
>>>>>> 
>>>>>> Now you just have to
>>>>>> - pick a target name
>>>>>> - find the jmpbuf size, word size, endian
>>>>>> - write a much small "config" file
>>>>>> - respond to each error that occurs -- fill in the platform in a few tables sprinkled around the tree
>>>>>> 
>>>>>> 
>>>>>> Even systems without pthreads or with not very good pthreads (OpenBSD) are easy now, as the user thread support is much more portable. It used to be, for user threads, you had to poke around in the jmpbuf.
>>>>>> 
>>>>>> 
>>>>>> I would encourage anyone else to try it out.
>>>>>> 
>>>>>> 
>>>>>> Maybe soon there will be a C generating backend, and we'll just have one distribution format that is a bunch of C, and then gcc support won't even be needed (e.g. IA64_NT).
>>>>>> 
>>>>>> 
>>>>>> Thanks,
>>>>>> - Jay
>>>>>> 
>>>>>> ----------------------------------------
>>>>>>> From: darko at darko.org
>>>>>>> Date: Thu, 17 Jun 2010 18:08:14 -0700
>>>>>>> To: jay.krell at cornell.edu
>>>>>>> CC: m3devel at elegosoft.com
>>>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>>>> 
>>>>>>> I've been interested in an ARM port for some time. If you (or anyone else) are interested in doing the port I can send you one of these, which looks like a good platform since it runs Linux and Android, has 512K memory and looks well supported: http://beagleboard.org/hardware
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On 20/05/2010, at 4:47 AM, 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?
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> 
>> 
>> 
> 
> 
		 	   		  



From jay.krell at cornell.edu  Sun Jun 20 02:33:17 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 20 Jun 2010 00:33:17 +0000
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <12B75D75-60FC-48DD-9364-2F22E04CA598@darko.org>
References: <1274350133.8902.0.camel@localhost>, , , , , ,
	,,<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>, , , , , ,
	,,<2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>, , , , ,
	,,<COL101-W580FCB4C956AC658A851ABE6C00@phx.gbl>, , , , ,
	,,<44CCDCF6-BACE-4B58-A1F5-EF68A852E2A5@darko.org>, , , ,
	,,<COL101-W493D8FFD71EB43948CBE8CE6C10@phx.gbl>, , , ,
	,,<B4638299-A29A-454B-9931-4F296F9AD3DB@darko.org>, , ,
	,,<COL101-W7F2C05F30E9F3525E482DE6C10@phx.gbl>, , ,
	,,<ED46DCAD-C84A-488C-BF6F-70CA1F24AF3B@darko.org>, ,
	,,<COL101-W5474F17968788325FFA76CE6C10@phx.gbl>, ,
	,,<5E055C3D-78F6-4C08-86D9-8B8CA86B11A1@darko.org>, ,
	,,<C76EF524-6048-4C61-9744-6797BBA6C552@darko.org>,
	,,<COL101-W31787A72294920C0484E63E6C10@phx.gbl>,
	, , <C1506F07-DE5E-4712-B15E-CB220A087D1A@darko.org>, ,
	<COL101-W29BA9D3680CFB903430A43E6C10@phx.gbl>, ,
	<6DCF6CCC-D3D3-4777-9585-243366375634@darko.org>,
	<COL101-W475B32E6802996894EA650E6C20@phx.gbl>,
	<12B75D75-60FC-48DD-9364-2F22E04CA598@darko.org>
Message-ID: <COL101-W197BF4F7E1E4A1A24B1469E6C20@phx.gbl>


None?
None yet?
You are supposed to be able run user mode stuff without installing any kernel or anything.
If I emulate an entire system, can the display be remoted over X?
I never go to the Linux "console", just ssh or X over ssh.

?- Jay

----------------------------------------
> From: darko at darko.org
> Date: Sat, 19 Jun 2010 17:30:12 -0700
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Linux/ARM? Android?
>
> I mean as your ARM platform. Which ARM distribution are you running on QEmu?
>
>
> On 19/06/2010, at 5:26 PM, Jay K wrote:
>
>
> I didn't know what "lxde" is, but Debian 5.0 x86 "Lenny". Minimal install plus apt-get install whatever.
>
> - Jay
>
> ----------------------------------------
>> From: darko at darko.org
>> Date: Sat, 19 Jun 2010 17:06:11 -0700
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Linux/ARM? Android?
>>
>> A fully crossed system would be the goal since mostly the target devices are ARM are phones, tablets and embedded devices. What distribution are you running on QEmu? Is it the Lenny-lxde one?
>>
>> Linux/ARM is definitely fractured because of the variety of ARM cores, SoC chips and devices on which it's used. I'm not sure what the best way to approach it is.
>>
>>
>> On 19/06/2010, at 4:42 PM, Jay K wrote:
>>
>>
>> I should point out, actually, with cross gcc/as, you should be able to easily enough build the whole system cross.
>> ie: your apps instead of cm3.
>> I can try that -- building the whole tree cross, including compiling C and linking.
>>
>>
>> Notice m3-sys/cminstall/src/config-no-install/ARMEL_LINUX:
>>
>>
>> SYSTEM_CC = "arm-linux-gnueabi-gcc -gstabs+ -fPIC" % C compiler
>> SYSTEM_ASM = "arm-linux-gnueabi-as" % Assembler
>>
>>
>> I get to:
>> jay at xlin2:~/cm3-boot-ARMEL_LINUX-d5.8.2-20100619$ file cm3
>> cm3: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.14, not stripped
>> jay at xlin2:~/cm3-boot-ARMEL_LINUX-d5.8.2-20100619$ qemu-arm ./cm3
>> /lib/ld-linux.so.3: No such file or directory
>>
>>
>> My QEmu setup isn't complete..
>>
>>
>> I got the crosstools from hereabouts:
>> http://www.emdebian.org/tools/crosstools.html
>>
>>
>> crosstool, scratchbox, buildroot may also be good options.
>>
>>
>> This reminds me though, I have a Western Digital MyBook World Edition.
>> Haven't powered it on in a while, slightly flaky device.
>> But it runs Linux/arm (oldabi).
>> I could/should power it on or get a new one something.
>>
>>
>> Also note/reminder, Android seems a bit different, at least in terms of finding C headers and libraries, maybe not for generating assembly, than "regular" Linux/arm.
>> Really "Linux/arm" seems a pretty fractured thing.
>> Newer architectures have floating point, for one thing.
>>
>>
>> - Jay
>>
>> ----------------------------------------
>>> From: darko at darko.org
>>> Date: Sat, 19 Jun 2010 15:47:24 -0700
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>
>>> Fantasic, thanks. There are some ARM cross tools available under DarwinPorts which I'm going to give this a try with.
>>>
>>>
>>> On 19/06/2010, at 2:51 AM, Jay K wrote:
>>>
>>>
>>> Eh I guess I should try that then. Ok. Thanks. Gotta take a break for a while.
>>> cd wherever
>>> cvs -z3 upd -dAP
>>> cd scripts/python
>>> ./boot1.py ARMEL_LINUX
>>> => cm3-boot-ARMEL_LINUX...tgz
>>> extract that on a machine with cross tools (e.g. arm-linux-gnueabi-gcc, arm-linux-gnueabi-as), possibly the same machine as already on
>>> cd into it
>>> make
>>> => arm cm3
>>>
>>>
>>> I got that far.
>>> I can't claim it is right for Android.
>>>
>>>
>>> Then put that cm3 onto a real (or emulated) ARM system and...
>>> (cvs checkout, put the cm3 in /cm3/bin or such, add that to $PATH, and scripts/python/boot2.sh)
>>>
>>>
>>> Moving forward to gcc 4.5 will get us atomics for ARM, sort of, at least on Linux, see:
>>> http://gcc.gnu.org/wiki/Atomic
>>>
>>>
>>> - Jay
>>>
>>> ----------------------------------------
>>>> From: darko at darko.org
>>>> Date: Sat, 19 Jun 2010 02:15:17 -0700
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>
>>>> I should also mention that the Android SDK has a QEMU based emulator for testing applications and the adb (Android Bridge) tool can provide shell access.
>>>>
>>>>
>>>> On 19/06/2010, at 12:13 AM, Darko wrote:
>>>>
>>>> I got the first Debian image on http://www.oszoo.org/wiki/index.php/Category:ARM_images to run with a GUI, and it connect to the network. I'm using Q on my 2.4Ghz MacBook 13" and it's surprisingly fast. Note that it's a 10GB image (450MB download).
>>>>
>>>> There are also images for Debian MIPS on that site too.
>>>>
>>>> I agree that the new MacBook trackpad is not perfect and since moving from my previous machine that had a separate button I now get a lot of stray gestures doing odd things. The general solution is not to use the button at all and use taps. The new momentum scrolling with the gesture is neat but needs more "weight". Unfortunately Apple crosses over into form-over-function territory from time to time and this is one of those times.
>>>>
>>>>
>>>> On 18/06/2010, at 11:18 PM, Jay K wrote:
>>>>
>>>>
>>>> XP when I can; nothing else comes close for searching and editing text, I've tried many.
>>>> Visual C++ 5.0.
>>>> I recently learned how to copy/paste in vi, which helps, but I'm not sure I remember now.
>>>>
>>>>
>>>> Darwin/amd64 when I need/want posix/fastfork, which unfortunately is often.
>>>> Cygwin is slow.
>>>> TextWrangler usually there, though it is awful compared to Visual C++ 5.0.
>>>> KomodoEdit is cross platform but also fairly impaired.
>>>> ssh access to a variety
>>>> Linux=Debian, it has among the best support for a variety of platforms.
>>>> Gentoo comes close or better (ppc64) but I've never been able to get it to install -- booting always fails.
>>>> Debian/x86 easy to get cross compiler, qemu, etc.
>>>>
>>>>
>>>> X Windows apps are never very good imho, so just give up and make do with the even worse command line..
>>>> I find things as basic as scrollbars do not work well -- which button do I press when?
>>>> The Modula-3 GUI apps suffer from this problem as well.
>>>> Further damage due to needing three buttons but not having them.
>>>>
>>>>
>>>> Mouse button clicking is actually broken on modern Macs too -- they removed the mouse button from all the laptops, leaving
>>>> just a big pad, prone to accidental clicks at any location.. also prone to accidental multitouch gestures due to resting
>>>> a twitchy thumb where the button is supposed to be. Amazing, really, the mouse, one of their key initial advantages,
>>>> is now broken. (see also Finder and file open dialogs, two other former strengths that are now not so great.)
>>>> Multitouch scroll is nice though.
>>>>
>>>>
>>>> - Jay
>>>>
>>>> ----------------------------------------
>>>>> From: darko at darko.org
>>>>> Date: Fri, 18 Jun 2010 22:55:24 -0700
>>>>> To: jay.krell at cornell.edu
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>>
>>>>> Yeah I've got it working on the console but I agree it needs the network.
>>>>>
>>>>> Try: http://www.oszoo.org/wiki/index.php/Category:ARM_images
>>>>> Also: http://www.armedslack.org/
>>>>>
>>>>> What platform are you running on these days?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 18/06/2010, at 10:44 PM, Jay K wrote:
>>>>>
>>>>>
>>>>> Interesting, thanks.
>>>>> But it looks like it needs to use local console for output?
>>>>> I need something over the network/X.
>>>>> It looks like there's an qemu option for usemode only too.
>>>>>
>>>>> - Jay
>>>>>
>>>>> ----------------------------------------
>>>>>> From: darko at darko.org
>>>>>> Date: Fri, 18 Jun 2010 22:13:43 -0700
>>>>>> To: jay.krell at cornell.edu
>>>>>> CC: m3devel at elegosoft.com
>>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>>>
>>>>>> If you use qemu, this might be useful: http://free-electrons.com/community/demos/qemu-arm-directfb/
>>>>>>
>>>>>> I'm currently looking at some cheap laptops (around $100) which have ethernet plus screen, keyboard, battery, etc which would work well as hosts. Just trying to find one that runs both Linux and Android.
>>>>>>
>>>>>>
>>>>>> On 18/06/2010, at 10:04 PM, Jay K wrote:
>>>>>>
>>>>>>
>>>>>> Thanks. I'll give qemu a go as well.
>>>>>> Hey, maybe we can get mips also. (there's decent modern mips/linux hardware now, Chinese laptops)
>>>>>>
>>>>>> - Jay
>>>>>>
>>>>>> ----------------------------------------
>>>>>>> From: darko at darko.org
>>>>>>> Date: Thu, 17 Jun 2010 21:41:59 -0700
>>>>>>> To: jay.krell at cornell.edu
>>>>>>> CC: m3devel at elegosoft.com
>>>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>>>>
>>>>>>> Ok, the link here is about 20/4Mbs so it shouldn't be too bad and the latency is good. I'm in Mountain View, CA. Unfortunately the board has only 128MB of main memory but I assume that's enough, I think a self hosted compiler has no point.
>>>>>>>
>>>>>>> I'll post the details when it's up and running.
>>>>>>>
>>>>>>>
>>>>>>> On 17/06/2010, at 9:15 PM, Jay K wrote:
>>>>>>>
>>>>>>>
>>>>>>> My preference would be if you can set it up on the internet and allow me ssh access.
>>>>>>> gcc only recently got support for Android's C library "bionic", I believe post-gcc 4.5.
>>>>>>> I'm not sure if that matters much or not.
>>>>>>> I'm not sure how much the C library of the target matters to gcc.
>>>>>>>
>>>>>>>
>>>>>>> Anything with pthreads and gcc support is quite easy to port to these days. In the past the biggest thing you had to do was rewrite /usr/include in Modula-3. There was a tendency to rewrite far more of it than necessary. These days, none of it is needed.
>>>>>>>
>>>>>>>
>>>>>>> Now you just have to
>>>>>>> - pick a target name
>>>>>>> - find the jmpbuf size, word size, endian
>>>>>>> - write a much small "config" file
>>>>>>> - respond to each error that occurs -- fill in the platform in a few tables sprinkled around the tree
>>>>>>>
>>>>>>>
>>>>>>> Even systems without pthreads or with not very good pthreads (OpenBSD) are easy now, as the user thread support is much more portable. It used to be, for user threads, you had to poke around in the jmpbuf.
>>>>>>>
>>>>>>>
>>>>>>> I would encourage anyone else to try it out.
>>>>>>>
>>>>>>>
>>>>>>> Maybe soon there will be a C generating backend, and we'll just have one distribution format that is a bunch of C, and then gcc support won't even be needed (e.g. IA64_NT).
>>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>> - Jay
>>>>>>>
>>>>>>> ----------------------------------------
>>>>>>>> From: darko at darko.org
>>>>>>>> Date: Thu, 17 Jun 2010 18:08:14 -0700
>>>>>>>> To: jay.krell at cornell.edu
>>>>>>>> CC: m3devel at elegosoft.com
>>>>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>>>>>
>>>>>>>> I've been interested in an ARM port for some time. If you (or anyone else) are interested in doing the port I can send you one of these, which looks like a good platform since it runs Linux and Android, has 512K memory and looks well supported: http://beagleboard.org/hardware
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 20/05/2010, at 4:47 AM, 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?
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
 		 	   		  

From darko at darko.org  Sun Jun 20 02:37:50 2010
From: darko at darko.org (Darko)
Date: Sat, 19 Jun 2010 17:37:50 -0700
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <COL101-W197BF4F7E1E4A1A24B1469E6C20@phx.gbl>
References: <1274350133.8902.0.camel@localhost>, , , , , , , ,
	<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>, , , , , , , ,
	<2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>, , , , , , ,
	<COL101-W580FCB4C956AC658A851ABE6C00@phx.gbl>, , , , , , ,
	<44CCDCF6-BACE-4B58-A1F5-EF68A852E2A5@darko.org>, , , , , ,
	<COL101-W493D8FFD71EB43948CBE8CE6C10@phx.gbl>, , , , , ,
	<B4638299-A29A-454B-9931-4F296F9AD3DB@darko.org>, , , , ,
	<COL101-W7F2C05F30E9F3525E482DE6C10@phx.gbl>, , , , ,
	<ED46DCAD-C84A-488C-BF6F-70CA1F24AF3B@darko.org>, , , ,
	<COL101-W5474F17968788325FFA76CE6C10@phx.gbl>, , , ,
	<5E055C3D-78F6-4C08-86D9-8B8CA86B11A1@darko.org>, , , ,
	<C76EF524-6048-4C61-9744-6797BBA6C552@darko.org>, , ,
	<COL101-W31787A72294920C0484E63E6C10@phx.gbl>, , ,
	<C1506F07-DE5E-4712-B15E-CB220A087D1A@darko.org>, ,
	<COL101-W29BA9D3680CFB903430A43E6C10@phx.gbl>, ,
	<6DCF6CCC-D3D3-4777-9585-243366375634@darko.org>,
	<COL101-W475B32E6802996894EA650E6C20@phx.gbl>,
	<12B75D75-60FC-48DD-9364-2F22E04CA598@darko.org>
	<COL101-W197BF4F7E1E4A1A24B1469 E6C20@phx.gbl>
Message-ID: <2DCB0C6D-D4AF-46B0-B24A-2D4F257C0696@darko.org>

This one runs X and sshd straight out of the box, on QEmu: http://www.oszoo.org/wiki/index.php/Debian_Lenny_Arm_%28Armel%29_-_with_lxde


On 19/06/2010, at 5:33 PM, Jay K wrote:


None?
None yet?
You are supposed to be able run user mode stuff without installing any kernel or anything.
If I emulate an entire system, can the display be remoted over X?
I never go to the Linux "console", just ssh or X over ssh.

 - Jay

----------------------------------------
> From: darko at darko.org
> Date: Sat, 19 Jun 2010 17:30:12 -0700
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Linux/ARM? Android?
> 
> I mean as your ARM platform. Which ARM distribution are you running on QEmu?
> 
> 
> On 19/06/2010, at 5:26 PM, Jay K wrote:
> 
> 
> I didn't know what "lxde" is, but Debian 5.0 x86 "Lenny". Minimal install plus apt-get install whatever.
> 
> - Jay
> 
> ----------------------------------------
>> From: darko at darko.org
>> Date: Sat, 19 Jun 2010 17:06:11 -0700
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Linux/ARM? Android?
>> 
>> A fully crossed system would be the goal since mostly the target devices are ARM are phones, tablets and embedded devices. What distribution are you running on QEmu? Is it the Lenny-lxde one?
>> 
>> Linux/ARM is definitely fractured because of the variety of ARM cores, SoC chips and devices on which it's used. I'm not sure what the best way to approach it is.
>> 
>> 
>> On 19/06/2010, at 4:42 PM, Jay K wrote:
>> 
>> 
>> I should point out, actually, with cross gcc/as, you should be able to easily enough build the whole system cross.
>> ie: your apps instead of cm3.
>> I can try that -- building the whole tree cross, including compiling C and linking.
>> 
>> 
>> Notice m3-sys/cminstall/src/config-no-install/ARMEL_LINUX:
>> 
>> 
>> SYSTEM_CC = "arm-linux-gnueabi-gcc -gstabs+ -fPIC" % C compiler
>> SYSTEM_ASM = "arm-linux-gnueabi-as" % Assembler
>> 
>> 
>> I get to:
>> jay at xlin2:~/cm3-boot-ARMEL_LINUX-d5.8.2-20100619$ file cm3
>> cm3: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.14, not stripped
>> jay at xlin2:~/cm3-boot-ARMEL_LINUX-d5.8.2-20100619$ qemu-arm ./cm3
>> /lib/ld-linux.so.3: No such file or directory
>> 
>> 
>> My QEmu setup isn't complete..
>> 
>> 
>> I got the crosstools from hereabouts:
>> http://www.emdebian.org/tools/crosstools.html
>> 
>> 
>> crosstool, scratchbox, buildroot may also be good options.
>> 
>> 
>> This reminds me though, I have a Western Digital MyBook World Edition.
>> Haven't powered it on in a while, slightly flaky device.
>> But it runs Linux/arm (oldabi).
>> I could/should power it on or get a new one something.
>> 
>> 
>> Also note/reminder, Android seems a bit different, at least in terms of finding C headers and libraries, maybe not for generating assembly, than "regular" Linux/arm.
>> Really "Linux/arm" seems a pretty fractured thing.
>> Newer architectures have floating point, for one thing.
>> 
>> 
>> - Jay
>> 
>> ----------------------------------------
>>> From: darko at darko.org
>>> Date: Sat, 19 Jun 2010 15:47:24 -0700
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>> 
>>> Fantasic, thanks. There are some ARM cross tools available under DarwinPorts which I'm going to give this a try with.
>>> 
>>> 
>>> On 19/06/2010, at 2:51 AM, Jay K wrote:
>>> 
>>> 
>>> Eh I guess I should try that then. Ok. Thanks. Gotta take a break for a while.
>>> cd wherever
>>> cvs -z3 upd -dAP
>>> cd scripts/python
>>> ./boot1.py ARMEL_LINUX
>>> => cm3-boot-ARMEL_LINUX...tgz
>>> extract that on a machine with cross tools (e.g. arm-linux-gnueabi-gcc, arm-linux-gnueabi-as), possibly the same machine as already on
>>> cd into it
>>> make
>>> => arm cm3
>>> 
>>> 
>>> I got that far.
>>> I can't claim it is right for Android.
>>> 
>>> 
>>> Then put that cm3 onto a real (or emulated) ARM system and...
>>> (cvs checkout, put the cm3 in /cm3/bin or such, add that to $PATH, and scripts/python/boot2.sh)
>>> 
>>> 
>>> Moving forward to gcc 4.5 will get us atomics for ARM, sort of, at least on Linux, see:
>>> http://gcc.gnu.org/wiki/Atomic
>>> 
>>> 
>>> - Jay
>>> 
>>> ----------------------------------------
>>>> From: darko at darko.org
>>>> Date: Sat, 19 Jun 2010 02:15:17 -0700
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>> 
>>>> I should also mention that the Android SDK has a QEMU based emulator for testing applications and the adb (Android Bridge) tool can provide shell access.
>>>> 
>>>> 
>>>> On 19/06/2010, at 12:13 AM, Darko wrote:
>>>> 
>>>> I got the first Debian image on http://www.oszoo.org/wiki/index.php/Category:ARM_images to run with a GUI, and it connect to the network. I'm using Q on my 2.4Ghz MacBook 13" and it's surprisingly fast. Note that it's a 10GB image (450MB download).
>>>> 
>>>> There are also images for Debian MIPS on that site too.
>>>> 
>>>> I agree that the new MacBook trackpad is not perfect and since moving from my previous machine that had a separate button I now get a lot of stray gestures doing odd things. The general solution is not to use the button at all and use taps. The new momentum scrolling with the gesture is neat but needs more "weight". Unfortunately Apple crosses over into form-over-function territory from time to time and this is one of those times.
>>>> 
>>>> 
>>>> On 18/06/2010, at 11:18 PM, Jay K wrote:
>>>> 
>>>> 
>>>> XP when I can; nothing else comes close for searching and editing text, I've tried many.
>>>> Visual C++ 5.0.
>>>> I recently learned how to copy/paste in vi, which helps, but I'm not sure I remember now.
>>>> 
>>>> 
>>>> Darwin/amd64 when I need/want posix/fastfork, which unfortunately is often.
>>>> Cygwin is slow.
>>>> TextWrangler usually there, though it is awful compared to Visual C++ 5.0.
>>>> KomodoEdit is cross platform but also fairly impaired.
>>>> ssh access to a variety
>>>> Linux=Debian, it has among the best support for a variety of platforms.
>>>> Gentoo comes close or better (ppc64) but I've never been able to get it to install -- booting always fails.
>>>> Debian/x86 easy to get cross compiler, qemu, etc.
>>>> 
>>>> 
>>>> X Windows apps are never very good imho, so just give up and make do with the even worse command line..
>>>> I find things as basic as scrollbars do not work well -- which button do I press when?
>>>> The Modula-3 GUI apps suffer from this problem as well.
>>>> Further damage due to needing three buttons but not having them.
>>>> 
>>>> 
>>>> Mouse button clicking is actually broken on modern Macs too -- they removed the mouse button from all the laptops, leaving
>>>> just a big pad, prone to accidental clicks at any location.. also prone to accidental multitouch gestures due to resting
>>>> a twitchy thumb where the button is supposed to be. Amazing, really, the mouse, one of their key initial advantages,
>>>> is now broken. (see also Finder and file open dialogs, two other former strengths that are now not so great.)
>>>> Multitouch scroll is nice though.
>>>> 
>>>> 
>>>> - Jay
>>>> 
>>>> ----------------------------------------
>>>>> From: darko at darko.org
>>>>> Date: Fri, 18 Jun 2010 22:55:24 -0700
>>>>> To: jay.krell at cornell.edu
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>> 
>>>>> Yeah I've got it working on the console but I agree it needs the network.
>>>>> 
>>>>> Try: http://www.oszoo.org/wiki/index.php/Category:ARM_images
>>>>> Also: http://www.armedslack.org/
>>>>> 
>>>>> What platform are you running on these days?
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On 18/06/2010, at 10:44 PM, Jay K wrote:
>>>>> 
>>>>> 
>>>>> Interesting, thanks.
>>>>> But it looks like it needs to use local console for output?
>>>>> I need something over the network/X.
>>>>> It looks like there's an qemu option for usemode only too.
>>>>> 
>>>>> - Jay
>>>>> 
>>>>> ----------------------------------------
>>>>>> From: darko at darko.org
>>>>>> Date: Fri, 18 Jun 2010 22:13:43 -0700
>>>>>> To: jay.krell at cornell.edu
>>>>>> CC: m3devel at elegosoft.com
>>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>>> 
>>>>>> If you use qemu, this might be useful: http://free-electrons.com/community/demos/qemu-arm-directfb/
>>>>>> 
>>>>>> I'm currently looking at some cheap laptops (around $100) which have ethernet plus screen, keyboard, battery, etc which would work well as hosts. Just trying to find one that runs both Linux and Android.
>>>>>> 
>>>>>> 
>>>>>> On 18/06/2010, at 10:04 PM, Jay K wrote:
>>>>>> 
>>>>>> 
>>>>>> Thanks. I'll give qemu a go as well.
>>>>>> Hey, maybe we can get mips also. (there's decent modern mips/linux hardware now, Chinese laptops)
>>>>>> 
>>>>>> - Jay
>>>>>> 
>>>>>> ----------------------------------------
>>>>>>> From: darko at darko.org
>>>>>>> Date: Thu, 17 Jun 2010 21:41:59 -0700
>>>>>>> To: jay.krell at cornell.edu
>>>>>>> CC: m3devel at elegosoft.com
>>>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>>>> 
>>>>>>> Ok, the link here is about 20/4Mbs so it shouldn't be too bad and the latency is good. I'm in Mountain View, CA. Unfortunately the board has only 128MB of main memory but I assume that's enough, I think a self hosted compiler has no point.
>>>>>>> 
>>>>>>> I'll post the details when it's up and running.
>>>>>>> 
>>>>>>> 
>>>>>>> On 17/06/2010, at 9:15 PM, Jay K wrote:
>>>>>>> 
>>>>>>> 
>>>>>>> My preference would be if you can set it up on the internet and allow me ssh access.
>>>>>>> gcc only recently got support for Android's C library "bionic", I believe post-gcc 4.5.
>>>>>>> I'm not sure if that matters much or not.
>>>>>>> I'm not sure how much the C library of the target matters to gcc.
>>>>>>> 
>>>>>>> 
>>>>>>> Anything with pthreads and gcc support is quite easy to port to these days. In the past the biggest thing you had to do was rewrite /usr/include in Modula-3. There was a tendency to rewrite far more of it than necessary. These days, none of it is needed.
>>>>>>> 
>>>>>>> 
>>>>>>> Now you just have to
>>>>>>> - pick a target name
>>>>>>> - find the jmpbuf size, word size, endian
>>>>>>> - write a much small "config" file
>>>>>>> - respond to each error that occurs -- fill in the platform in a few tables sprinkled around the tree
>>>>>>> 
>>>>>>> 
>>>>>>> Even systems without pthreads or with not very good pthreads (OpenBSD) are easy now, as the user thread support is much more portable. It used to be, for user threads, you had to poke around in the jmpbuf.
>>>>>>> 
>>>>>>> 
>>>>>>> I would encourage anyone else to try it out.
>>>>>>> 
>>>>>>> 
>>>>>>> Maybe soon there will be a C generating backend, and we'll just have one distribution format that is a bunch of C, and then gcc support won't even be needed (e.g. IA64_NT).
>>>>>>> 
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> - Jay
>>>>>>> 
>>>>>>> ----------------------------------------
>>>>>>>> From: darko at darko.org
>>>>>>>> Date: Thu, 17 Jun 2010 18:08:14 -0700
>>>>>>>> To: jay.krell at cornell.edu
>>>>>>>> CC: m3devel at elegosoft.com
>>>>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>>>>> 
>>>>>>>> I've been interested in an ARM port for some time. If you (or anyone else) are interested in doing the port I can send you one of these, which looks like a good platform since it runs Linux and Android, has 512K memory and looks well supported: http://beagleboard.org/hardware
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On 20/05/2010, at 4:47 AM, 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?
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
> 
> 
		 	   		  



From jay.krell at cornell.edu  Sun Jun 20 04:07:21 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 20 Jun 2010 02:07:21 +0000
Subject: [M3devel] div/mod gcc builtin vs. m3core function
Message-ID: <COL101-W19658E57C608B58952727CE6C20@phx.gbl>


So..I'm debugging why 64bit mod on ARM doesn't work..changed the C compiler to use floor instead of trunc, see if it fails..see what it does.
? If it fails, I could report that as a bug.


Now, I'm nervous.
I'm nervous that gcc might sometimes use libgcc functions for div or mod, with the assumption that trunc is needed.
This would clearly be a bug in gcc.
But I'm nervous.

The implementation of div/mod varies a lot -- sometimes a function call in gcc, sometimes not.

I tested some architectures at the time..but I wonder now.

Maybe safest to just always use our functions?

I might try to prove gcc does it wrong, e.g. for ARM, with a modified C front end..but so far I can't run ARM code.

Thoughts?


jbook2:gcc jay$ grep sdiv_optab? */*/*/* 
gcc/config/alpha/alpha.c:????? set_optab_libfunc (sdiv_optab, SImode, 0);
gcc/config/alpha/alpha.c:????? set_optab_libfunc (sdiv_optab, DImode, "$sldiv");
gcc/config/alpha/alpha.c:????? set_optab_libfunc (sdiv_optab, SImode, "OTS$DIV_I");
gcc/config/alpha/alpha.c:????? set_optab_libfunc (sdiv_optab, DImode, "OTS$DIV_L");
gcc/config/alpha/alpha.md:? div = expand_binop (DImode, sdiv_optab, operands[1], operands[2],
gcc/config/arm/arm.c:? set_optab_libfunc (sdiv_optab, DFmode, "__aeabi_ddiv");
gcc/config/arm/arm.c:? set_optab_libfunc (sdiv_optab, SFmode, "__aeabi_fdiv");
gcc/config/arm/arm.c:? set_optab_libfunc (sdiv_optab, DImode, "__aeabi_ldivmod");
gcc/config/arm/arm.c:? set_optab_libfunc (sdiv_optab, SImode, "__aeabi_idiv");
gcc/config/cris/cris.c:? set_optab_libfunc (sdiv_optab, SImode, "__Div");
gcc/config/frv/frv.c:? set_optab_libfunc (sdiv_optab,???? DImode, "__divll");
gcc/config/frv/frv.c:? set_optab_libfunc (sdiv_optab,???? SFmode, "__divf");
gcc/config/frv/frv.c:? set_optab_libfunc (sdiv_optab,???? DFmode, "__divd");
gcc/config/h8300/h8300.c:? set_optab_libfunc (sdiv_optab, HImode, "__divhi3");
gcc/config/ia64/ia64.c:? set_optab_libfunc (sdiv_optab, SImode, "__divsi3");
gcc/config/ia64/ia64.c:? set_optab_libfunc (sdiv_optab, TFmode, "_U_Qfdiv");
gcc/config/ia64/ia64.c:? set_optab_libfunc (sdiv_optab, SImode, 0);
gcc/config/ia64/ia64.c:? set_optab_libfunc (sdiv_optab, DImode, "__milli_divI");
gcc/config/ia64/ia64.c:? set_optab_libfunc (sdiv_optab, SImode, "OTS$DIV_I");
gcc/config/ia64/ia64.c:? set_optab_libfunc (sdiv_optab, DImode, "OTS$DIV_L");
gcc/config/mips/mips.c:????? set_optab_libfunc (sdiv_optab, SImode, "__vr4120_divsi3");
gcc/config/mips/mips.c:????? set_optab_libfunc (sdiv_optab, SFmode, "__mips16_divsf3");
gcc/config/mips/mips.c:??? ? set_optab_libfunc (sdiv_optab, DFmode, "__mips16_divdf3");
gcc/config/pa/pa.c:? set_optab_libfunc (sdiv_optab, TFmode, "_U_Qfdiv");
gcc/config/rs6000/rs6000.c:??? set_optab_libfunc (sdiv_optab, TFmode, "__gcc_qdiv");
gcc/config/rs6000/rs6000.c:??? set_optab_libfunc (sdiv_optab, TFmode, "_xlqdiv");
gcc/config/rs6000/rs6000.c:????? set_optab_libfunc (sdiv_optab, TFmode, "_q_div");
gcc/config/sparc/sparc.c:????? set_optab_libfunc (sdiv_optab, SImode, "*.div");
gcc/config/sparc/sparc.c:????? set_optab_libfunc (sdiv_optab, TFmode, "_Q_div");
gcc/config/sparc/sparc.c:????? set_optab_libfunc (sdiv_optab, SImode, 0);
gcc/config/sparc/sparc.c:??? ? set_optab_libfunc (sdiv_optab, DImode, "__div64");
gcc/config/spu/spu.c:? set_optab_libfunc (sdiv_optab, DImode, "__divdi3");
j



?- Jay




 		 	   		  

From dabenavidesd at yahoo.es  Sun Jun 20 05:17:03 2010
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Sun, 20 Jun 2010 03:17:03 +0000 (GMT)
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <COL101-W197BF4F7E1E4A1A24B1469E6C20@phx.gbl>
Message-ID: <847521.56337.qm@web23602.mail.ird.yahoo.com>

Hi:
yes, you can if you wish, that is, you can redirect the x window session and get access through a host different port (see info below) from a new x client or even forwarding x over a ssh session or separated (ideal if you wish), I haven't  tried to do it (I have old hardware, I guess you should be able to virtualize some very decent and cheap system as see below SuSE article points out) but you should be able to do that. Please see this article for the first (the qemu-system- -redir command option):
http://www.ibm.com/developerworks/opensource/library/l-qemu-development/index.html?ca=drs-
you can select the window manager you wish I remember a friend used to talk about WindowMaker he said it was very cheap in terms of RAM and it allowed to do your work just out of the box (he had a very old i486 laptop with it I guess with < 64 MB RAM just to monitor other servers).
There is a bright idea about clustering with OpenMosix (which used to work years ago now there is http://en.wikipedia.org/wiki/LinuxPMI for that purpose) using QEMU, see this old article http://www.novell.com/coolsolutions/feature/14951.html 
you might get some old machines back into life with a net interface in a cluster and mount your disk too.
Hope it helps.

 

--- El s?b, 19/6/10, Jay K <jay.krell at cornell.edu> escribi?:

> De: Jay K <jay.krell at cornell.edu>
> Asunto: Re: [M3devel] Linux/ARM? Android?
> Para: "Darko (M3)" <darko at darko.org>
> CC: "m3devel" <m3devel at elegosoft.com>
> Fecha: s?bado, 19 de junio, 2010 19:33
> 
> None?
> None yet?
> You are supposed to be able run user mode stuff without
> installing any kernel or anything.
> If I emulate an entire system, can the display be remoted
> over X?
> I never go to the Linux "console", just ssh or X over ssh.
> 
>  - Jay
> 
> ----------------------------------------
> > From: darko at darko.org
> > Date: Sat, 19 Jun 2010 17:30:12 -0700
> > To: jay.krell at cornell.edu
> > CC: m3devel at elegosoft.com
> > Subject: Re: [M3devel] Linux/ARM? Android?
> >
> > I mean as your ARM platform. Which ARM distribution
> are you running on QEmu?
> >
> >
> > On 19/06/2010, at 5:26 PM, Jay K wrote:
> >
> >
> > I didn't know what "lxde" is, but Debian 5.0 x86
> "Lenny". Minimal install plus apt-get install whatever.
> >
> > - Jay
> >
> > ----------------------------------------
> >> From: darko at darko.org
> >> Date: Sat, 19 Jun 2010 17:06:11 -0700
> >> To: jay.krell at cornell.edu
> >> CC: m3devel at elegosoft.com
> >> Subject: Re: [M3devel] Linux/ARM? Android?
> >>
> >> A fully crossed system would be the goal since
> mostly the target devices are ARM are phones, tablets and
> embedded devices. What distribution are you running on QEmu?
> Is it the Lenny-lxde one?
> >>
> >> Linux/ARM is definitely fractured because of the
> variety of ARM cores, SoC chips and devices on which it's
> used. I'm not sure what the best way to approach it is.
> >>
> >>
> >> On 19/06/2010, at 4:42 PM, Jay K wrote:
> >>
> >>
> >> I should point out, actually, with cross gcc/as,
> you should be able to easily enough build the whole system
> cross.
> >> ie: your apps instead of cm3.
> >> I can try that -- building the whole tree cross,
> including compiling C and linking.
> >>
> >>
> >> Notice
> m3-sys/cminstall/src/config-no-install/ARMEL_LINUX:
> >>
> >>
> >> SYSTEM_CC = "arm-linux-gnueabi-gcc -gstabs+ -fPIC"
> % C compiler
> >> SYSTEM_ASM = "arm-linux-gnueabi-as" % Assembler
> >>
> >>
> >> I get to:
> >> jay at xlin2:~/cm3-boot-ARMEL_LINUX-d5.8.2-20100619$
> file cm3
> >> cm3: ELF 32-bit LSB executable, ARM, version 1
> (SYSV), dynamically linked (uses shared libs), for GNU/Linux
> 2.6.14, not stripped
> >> jay at xlin2:~/cm3-boot-ARMEL_LINUX-d5.8.2-20100619$
> qemu-arm ./cm3
> >> /lib/ld-linux.so.3: No such file or directory
> >>
> >>
> >> My QEmu setup isn't complete..
> >>
> >>
> >> I got the crosstools from hereabouts:
> >> http://www.emdebian.org/tools/crosstools.html
> >>
> >>
> >> crosstool, scratchbox, buildroot may also be good
> options.
> >>
> >>
> >> This reminds me though, I have a Western Digital
> MyBook World Edition.
> >> Haven't powered it on in a while, slightly flaky
> device.
> >> But it runs Linux/arm (oldabi).
> >> I could/should power it on or get a new one
> something.
> >>
> >>
> >> Also note/reminder, Android seems a bit different,
> at least in terms of finding C headers and libraries, maybe
> not for generating assembly, than "regular" Linux/arm.
> >> Really "Linux/arm" seems a pretty fractured
> thing.
> >> Newer architectures have floating point, for one
> thing.
> >>
> >>
> >> - Jay
> >>
> >> ----------------------------------------
> >>> From: darko at darko.org
> >>> Date: Sat, 19 Jun 2010 15:47:24 -0700
> >>> To: jay.krell at cornell.edu
> >>> CC: m3devel at elegosoft.com
> >>> Subject: Re: [M3devel] Linux/ARM? Android?
> >>>
> >>> Fantasic, thanks. There are some ARM cross
> tools available under DarwinPorts which I'm going to give
> this a try with.
> >>>
> >>>
> >>> On 19/06/2010, at 2:51 AM, Jay K wrote:
> >>>
> >>>
> >>> Eh I guess I should try that then. Ok. Thanks.
> Gotta take a break for a while.
> >>> cd wherever
> >>> cvs -z3 upd -dAP
> >>> cd scripts/python
> >>> ./boot1.py ARMEL_LINUX
> >>> => cm3-boot-ARMEL_LINUX...tgz
> >>> extract that on a machine with cross tools
> (e.g. arm-linux-gnueabi-gcc, arm-linux-gnueabi-as), possibly
> the same machine as already on
> >>> cd into it
> >>> make
> >>> => arm cm3
> >>>
> >>>
> >>> I got that far.
> >>> I can't claim it is right for Android.
> >>>
> >>>
> >>> Then put that cm3 onto a real (or emulated)
> ARM system and...
> >>> (cvs checkout, put the cm3 in /cm3/bin or
> such, add that to $PATH, and scripts/python/boot2.sh)
> >>>
> >>>
> >>> Moving forward to gcc 4.5 will get us atomics
> for ARM, sort of, at least on Linux, see:
> >>> http://gcc.gnu.org/wiki/Atomic
> >>>
> >>>
> >>> - Jay
> >>>
> >>> ----------------------------------------
> >>>> From: darko at darko.org
> >>>> Date: Sat, 19 Jun 2010 02:15:17 -0700
> >>>> To: jay.krell at cornell.edu
> >>>> CC: m3devel at elegosoft.com
> >>>> Subject: Re: [M3devel] Linux/ARM?
> Android?
> >>>>
> >>>> I should also mention that the Android SDK
> has a QEMU based emulator for testing applications and the
> adb (Android Bridge) tool can provide shell access.
> >>>>
> >>>>
> >>>> On 19/06/2010, at 12:13 AM, Darko wrote:
> >>>>
> >>>> I got the first Debian image on http://www.oszoo.org/wiki/index.php/Category:ARM_images
> to run with a GUI, and it connect to the network. I'm using
> Q on my 2.4Ghz MacBook 13" and it's surprisingly fast. Note
> that it's a 10GB image (450MB download).
> >>>>
> >>>> There are also images for Debian MIPS on
> that site too.
> >>>>
> >>>> I agree that the new MacBook trackpad is
> not perfect and since moving from my previous machine that
> had a separate button I now get a lot of stray gestures
> doing odd things. The general solution is not to use the
> button at all and use taps. The new momentum scrolling with
> the gesture is neat but needs more "weight". Unfortunately
> Apple crosses over into form-over-function territory from
> time to time and this is one of those times.
> >>>>
> >>>>
> >>>> On 18/06/2010, at 11:18 PM, Jay K wrote:
> >>>>
> >>>>
> >>>> XP when I can; nothing else comes close
> for searching and editing text, I've tried many.
> >>>> Visual C++ 5.0.
> >>>> I recently learned how to copy/paste in
> vi, which helps, but I'm not sure I remember now.
> >>>>
> >>>>
> >>>> Darwin/amd64 when I need/want
> posix/fastfork, which unfortunately is often.
> >>>> Cygwin is slow.
> >>>> TextWrangler usually there, though it is
> awful compared to Visual C++ 5.0.
> >>>> KomodoEdit is cross platform but also
> fairly impaired.
> >>>> ssh access to a variety
> >>>> Linux=Debian, it has among the best
> support for a variety of platforms.
> >>>> Gentoo comes close or better (ppc64) but
> I've never been able to get it to install -- booting always
> fails.
> >>>> Debian/x86 easy to get cross compiler,
> qemu, etc.
> >>>>
> >>>>
> >>>> X Windows apps are never very good imho,
> so just give up and make do with the even worse command
> line..
> >>>> I find things as basic as scrollbars do
> not work well -- which button do I press when?
> >>>> The Modula-3 GUI apps suffer from this
> problem as well.
> >>>> Further damage due to needing three
> buttons but not having them.
> >>>>
> >>>>
> >>>> Mouse button clicking is actually broken
> on modern Macs too -- they removed the mouse button from all
> the laptops, leaving
> >>>> just a big pad, prone to accidental clicks
> at any location.. also prone to accidental multitouch
> gestures due to resting
> >>>> a twitchy thumb where the button is
> supposed to be. Amazing, really, the mouse, one of their key
> initial advantages,
> >>>> is now broken. (see also Finder and file
> open dialogs, two other former strengths that are now not so
> great.)
> >>>> Multitouch scroll is nice though.
> >>>>
> >>>>
> >>>> - Jay
> >>>>
> >>>> ----------------------------------------
> >>>>> From: darko at darko.org
> >>>>> Date: Fri, 18 Jun 2010 22:55:24 -0700
> >>>>> To: jay.krell at cornell.edu
> >>>>> CC: m3devel at elegosoft.com
> >>>>> Subject: Re: [M3devel] Linux/ARM?
> Android?
> >>>>>
> >>>>> Yeah I've got it working on the
> console but I agree it needs the network.
> >>>>>
> >>>>> Try: http://www.oszoo.org/wiki/index.php/Category:ARM_images
> >>>>> Also: http://www.armedslack.org/
> >>>>>
> >>>>> What platform are you running on these
> days?
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 18/06/2010, at 10:44 PM, Jay K
> wrote:
> >>>>>
> >>>>>
> >>>>> Interesting, thanks.
> >>>>> But it looks like it needs to use
> local console for output?
> >>>>> I need something over the network/X.
> >>>>> It looks like there's an qemu option
> for usemode only too.
> >>>>>
> >>>>> - Jay
> >>>>>
> >>>>>
> ----------------------------------------
> >>>>>> From: darko at darko.org
> >>>>>> Date: Fri, 18 Jun 2010 22:13:43
> -0700
> >>>>>> To: jay.krell at cornell.edu
> >>>>>> CC: m3devel at elegosoft.com
> >>>>>> Subject: Re: [M3devel] Linux/ARM?
> Android?
> >>>>>>
> >>>>>> If you use qemu, this might be
> useful: http://free-electrons.com/community/demos/qemu-arm-directfb/
> >>>>>>
> >>>>>> I'm currently looking at some
> cheap laptops (around $100) which have ethernet plus screen,
> keyboard, battery, etc which would work well as hosts. Just
> trying to find one that runs both Linux and Android.
> >>>>>>
> >>>>>>
> >>>>>> On 18/06/2010, at 10:04 PM, Jay K
> wrote:
> >>>>>>
> >>>>>>
> >>>>>> Thanks. I'll give qemu a go as
> well.
> >>>>>> Hey, maybe we can get mips also.
> (there's decent modern mips/linux hardware now, Chinese
> laptops)
> >>>>>>
> >>>>>> - Jay
> >>>>>>
> >>>>>>
> ----------------------------------------
> >>>>>>> From: darko at darko.org
> >>>>>>> Date: Thu, 17 Jun 2010
> 21:41:59 -0700
> >>>>>>> To: jay.krell at cornell.edu
> >>>>>>> CC: m3devel at elegosoft.com
> >>>>>>> Subject: Re: [M3devel]
> Linux/ARM? Android?
> >>>>>>>
> >>>>>>> Ok, the link here is about
> 20/4Mbs so it shouldn't be too bad and the latency is good.
> I'm in Mountain View, CA. Unfortunately the board has only
> 128MB of main memory but I assume that's enough, I think a
> self hosted compiler has no point.
> >>>>>>>
> >>>>>>> I'll post the details when
> it's up and running.
> >>>>>>>
> >>>>>>>
> >>>>>>> On 17/06/2010, at 9:15 PM, Jay
> K wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>> My preference would be if you
> can set it up on the internet and allow me ssh access.
> >>>>>>> gcc only recently got support
> for Android's C library "bionic", I believe post-gcc 4.5.
> >>>>>>> I'm not sure if that matters
> much or not.
> >>>>>>> I'm not sure how much the C
> library of the target matters to gcc.
> >>>>>>>
> >>>>>>>
> >>>>>>> Anything with pthreads and gcc
> support is quite easy to port to these days. In the past the
> biggest thing you had to do was rewrite /usr/include in
> Modula-3. There was a tendency to rewrite far more of it
> than necessary. These days, none of it is needed.
> >>>>>>>
> >>>>>>>
> >>>>>>> Now you just have to
> >>>>>>> - pick a target name
> >>>>>>> - find the jmpbuf size, word
> size, endian
> >>>>>>> - write a much small "config"
> file
> >>>>>>> - respond to each error that
> occurs -- fill in the platform in a few tables sprinkled
> around the tree
> >>>>>>>
> >>>>>>>
> >>>>>>> Even systems without pthreads
> or with not very good pthreads (OpenBSD) are easy now, as
> the user thread support is much more portable. It used to
> be, for user threads, you had to poke around in the jmpbuf.
> >>>>>>>
> >>>>>>>
> >>>>>>> I would encourage anyone else
> to try it out.
> >>>>>>>
> >>>>>>>
> >>>>>>> Maybe soon there will be a C
> generating backend, and we'll just have one distribution
> format that is a bunch of C, and then gcc support won't even
> be needed (e.g. IA64_NT).
> >>>>>>>
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> - Jay
> >>>>>>>
> >>>>>>>
> ----------------------------------------
> >>>>>>>> From: darko at darko.org
> >>>>>>>> Date: Thu, 17 Jun 2010
> 18:08:14 -0700
> >>>>>>>> To: jay.krell at cornell.edu
> >>>>>>>> CC: m3devel at elegosoft.com
> >>>>>>>> Subject: Re: [M3devel]
> Linux/ARM? Android?
> >>>>>>>>
> >>>>>>>> I've been interested in an
> ARM port for some time. If you (or anyone else) are
> interested in doing the port I can send you one of these,
> which looks like a good platform since it runs Linux and
> Android, has 512K memory and looks well supported: http://beagleboard.org/hardware
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 20/05/2010, at 4:47 AM,
> 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?
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>
> >>
> >
> >
>     
>         
>           
>   


      


From m3 at sol42.com  Sun Jun 20 11:21:03 2010
From: m3 at sol42.com (m3 at sol42.com)
Date: Sun, 20 Jun 2010 11:21:03 +0200
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <COL101-W493D8FFD71EB43948CBE8CE6C10@phx.gbl>
References: <1274350133.8902.0.camel@localhost>, ,
	<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>, ,
	<2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>,
	<COL101-W580FCB4C956AC658A851ABE6C00@phx.gbl>,
	<44CCDCF6-BACE-4B58-A1F5-EF68A852E2A5@darko.org>
	<COL101-W493D8FFD71EB43948CBE8CE6C10@phx.gbl>
Message-ID: <5CEB90C2-DC07-4D4C-9E90-FCCEA356E065@sol42.com>

On 19 Jun 2010, at 7:04, Jay K wrote:
> Hey, maybe we can get mips also. (there's decent modern mips/linux hardware now, Chinese laptops)
Hmm, I have decent ancient mips/irix hardware I'd love to get m3 running on.  Will have to give it a try when I get some free time.  Is gcc 4 required (I have 3.3)?
Regards.
-Daniel

From dabenavidesd at yahoo.es  Sun Jun 20 20:54:49 2010
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Sun, 20 Jun 2010 18:54:49 +0000 (GMT)
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <5CEB90C2-DC07-4D4C-9E90-FCCEA356E065@sol42.com>
Message-ID: <974011.74052.qm@web23608.mail.ird.yahoo.com>

Hi:
if you mean the c "native" compiler shouldn't be a problem, but one would expect differences between efficiency of both m3cg builds, I believe buildable for gcc 4 and 3 but nonetheless it shouldn't be the same in terms of the generated m3cg but for the M3 code which is what one is interested would be more like the same. If it is necessary to work with it I believe the process of installing a new gcc for c lang only is not too painful and is straight forward after you have a previous version to build a gcc 4 with a bootstrap compiler to build a self hosted c compiler.
I don't know how much of the building process of m3cg is done by the gcc c compiler if it could be done at the same time such a build with current tree (which if there is I think is doable just selecting the proper options in the configure program command parameters, although not sure to build a full self hosted c gcc 4 compiler, but doable if you start with a bootstrap gcc 4 c compiler).
Hope it helps and thanks in adavance
 
--- El dom, 20/6/10, m3 at sol42.com <m3 at sol42.com> escribi?:

> De: m3 at sol42.com <m3 at sol42.com>
> Asunto: Re: [M3devel] Linux/ARM? Android?
> Para: m3devel at elegosoft.com
> Fecha: domingo, 20 de junio, 2010 04:21
> On 19 Jun 2010, at 7:04, Jay K
> wrote:
> > Hey, maybe we can get mips also. (there's decent
> modern mips/linux hardware now, Chinese laptops)
> Hmm, I have decent ancient mips/irix hardware I'd love to
> get m3 running on.  Will have to give it a try when I
> get some free time.  Is gcc 4 required (I have 3.3)?
> Regards.
> -Daniel


      


From jay.krell at cornell.edu  Sun Jun 20 21:16:27 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 20 Jun 2010 19:16:27 +0000
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <5CEB90C2-DC07-4D4C-9E90-FCCEA356E065@sol42.com>
References: <1274350133.8902.0.camel@localhost>,
	,,<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>,
	, , <2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>, ,
	<COL101-W580FCB4C956AC658A851ABE6C00@phx.gbl>, ,
	<44CCDCF6-BACE-4B58-A1F5-EF68A852E2A5@darko.org>,
	<COL101-W493D8FFD71EB43948CBE8CE6C10@phx.gbl>,
	<5CEB90C2-DC07-4D4C-9E90-FCCEA356E065@sol42.com>
Message-ID: <COL101-W70CBF569D6E232E7CAD5BE6C20@phx.gbl>


No gcc 4 is not required.
What is required is that gcc 4.3 support your machine -- since that is currently what m3cg is based on -- but you don't need gcc 4.
You just need some C compiler.
gcc 4.3 does support Irix/mips I believe.
Irix 6.5.

?- Jay

----------------------------------------
> From: m3 at sol42.com
> Date: Sun, 20 Jun 2010 11:21:03 +0200
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] Linux/ARM? Android?
>
> On 19 Jun 2010, at 7:04, Jay K wrote:
>> Hey, maybe we can get mips also. (there's decent modern mips/linux hardware now, Chinese laptops)
> Hmm, I have decent ancient mips/irix hardware I'd love to get m3 running on. Will have to give it a try when I get some free time. Is gcc 4 required (I have 3.3)?
> Regards.
> -Daniel
 		 	   		  

From jay.krell at cornell.edu  Sun Jun 20 21:43:57 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 20 Jun 2010 19:43:57 +0000
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <974011.74052.qm@web23608.mail.ird.yahoo.com>
References: <5CEB90C2-DC07-4D4C-9E90-FCCEA356E065@sol42.com>,
	<974011.74052.qm@web23608.mail.ird.yahoo.com>
Message-ID: <COL101-W190990CE2CFAD02AC0CBC0E6C20@phx.gbl>


True, that m3cg is "most" buildable by gcc itself. That gets the most testing by gcc developers.
Almost any version will do though.
But it is buildable by other C compilers, such as Sun cc and OSF/1's C compiler.
Going forward, like to gcc 4.6, a C++ compiler might be needed.
OpenBSD uses gcc 3.x on most platforms and 2.x on some older ones.
gcc 4.4 and 4.5 actually require a C9x compiler but that is an accidental regression and getting fixed.
I found it using OSF/1 cc on Mika's machine. :)


On Irix I found some wierd old undocumented "O32" compiler and I think was able to use it eventually
to build modern gcc. It required some small patches to some tools, and it seemed to
perhaps even miscompile things, such that they had to later be rebuilt with gcc.


On HP-UX on HPPA the? bundled compiler is K&R. It can be used to build some gcc 3.x, which
can then be used to build gcc 4.x and/or presumably m3cg. I don't remember how far I got.
This "need" to go through gcc 3.x is documented on the gcc web pages.


?- Jay

----------------------------------------
> Date: Sun, 20 Jun 2010 18:54:49 +0000
> From: dabenavidesd at yahoo.es
> To: m3devel at elegosoft.com; m3 at sol42.com
> Subject: Re: [M3devel] Linux/ARM? Android?
>
> Hi:
> if you mean the c "native" compiler shouldn't be a problem, but one would expect differences between efficiency of both m3cg builds, I believe buildable for gcc 4 and 3 but nonetheless it shouldn't be the same in terms of the generated m3cg but for the M3 code which is what one is interested would be more like the same. If it is necessary to work with it I believe the process of installing a new gcc for c lang only is not too painful and is straight forward after you have a previous version to build a gcc 4 with a bootstrap compiler to build a self hosted c compiler.
> I don't know how much of the building process of m3cg is done by the gcc c compiler if it could be done at the same time such a build with current tree (which if there is I think is doable just selecting the proper options in the configure program command parameters, although not sure to build a full self hosted c gcc 4 compiler, but doable if you start with a bootstrap gcc 4 c compiler).
> Hope it helps and thanks in adavance
>
> --- El dom, 20/6/10, m3 at sol42.com  escribi?:
>
>> De: m3 at sol42.com 
>> Asunto: Re: [M3devel] Linux/ARM? Android?
>> Para: m3devel at elegosoft.com
>> Fecha: domingo, 20 de junio, 2010 04:21
>> On 19 Jun 2010, at 7:04, Jay K
>> wrote:
>>> Hey, maybe we can get mips also. (there's decent
>> modern mips/linux hardware now, Chinese laptops)
>> Hmm, I have decent ancient mips/irix hardware I'd love to
>> get m3 running on. Will have to give it a try when I
>> get some free time. Is gcc 4 required (I have 3.3)?
>> Regards.
>> -Daniel
>
>
>
 		 	   		  

From dragisha at m3w.org  Sun Jun 20 22:38:26 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Sun, 20 Jun 2010 22:38:26 +0200
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <COL101-W190990CE2CFAD02AC0CBC0E6C20@phx.gbl>
References: <5CEB90C2-DC07-4D4C-9E90-FCCEA356E065@sol42.com>
	, <974011.74052.qm@web23608.mail.ird.yahoo.com>
	<COL101-W190990CE2CFAD02AC0CBC0E6C20@phx.gbl>
Message-ID: <1277066306.5571.4.camel@localhost>

It's cheaper to support platforms through m3gc (meaning gcc) than
through C. Going native so as to get "broader base than gcc"? Do we
really have that wide userbase? Not to mention developer base...

And why're you looking retro to C? Why not invest yourself on LLVM? JIT
comes to mind....

On Sun, 2010-06-20 at 19:43 +0000, Jay K wrote:
> True, that m3cg is "most" buildable by gcc itself. That gets the most
> testing by gcc developers.
> Almost any version will do though.
> But it is buildable by other C compilers, such as Sun cc and OSF/1's C
> compiler.
> Going forward, like to gcc 4.6, a C++ compiler might be needed.
> OpenBSD uses gcc 3.x on most platforms and 2.x on some older ones.
> gcc 4.4 and 4.5 actually require a C9x compiler but that is an
> accidental regression and getting fixed.
> I found it using OSF/1 cc on Mika's machine. :) 
-- 
Dragi?a Duri? <dragisha at m3w.org>



From jay.krell at cornell.edu  Mon Jun 21 00:40:54 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 20 Jun 2010 22:40:54 +0000
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <1277066306.5571.4.camel@localhost>
References: <5CEB90C2-DC07-4D4C-9E90-FCCEA356E065@sol42.com>,,
	<974011.74052.qm@web23608.mail.ird.yahoo.com>,
	<COL101-W190990CE2CFAD02AC0CBC0E6C20@phx.gbl>,
	<1277066306.5571.4.camel@localhost>
Message-ID: <COL101-W59EAC8AC1D2D1DC0678DA1E6C20@phx.gbl>


If you generate C, you get one very portable distribution format -- a bunch of C in .tar.gz.
Far more portable than what we have today.
You get possibly better optimization.
Possibly better debugging.
A much smaller source tree -- no need for m3cc or m3gdb.
You highly likely get more efficient portable exception handling -- generate C++.
? (On Win32, C suffices. Similarly on OSF/1 and VMS I believe.)
Granted, C++ with exception handling is less portable than C -- there could still be an option to use setjmp/longjmp.
I imagine it'd be wrapped up in some #defines.
Consider all the platforms that aren't well supported by gcc or LLVM.


You might get slower compilation, granted.


You could also use this as a hybrid approach. Consider that we already have two sort of backends.
This would be a third.
Anyone want Alpha, ARM, MIPS, IA64 etc. -- already done, or at least signficantly.


Consider how much work it takes to port "Hello world". None.
This would drive us toward that.
With some benefits and maybe some drawbacks.


?- Jay

----------------------------------------
> From: dragisha at m3w.org
> To: jay.krell at cornell.edu
> Date: Sun, 20 Jun 2010 22:38:26 +0200
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Linux/ARM? Android?
>
> It's cheaper to support platforms through m3gc (meaning gcc) than
> through C. Going native so as to get "broader base than gcc"? Do we
> really have that wide userbase? Not to mention developer base...
>
> And why're you looking retro to C? Why not invest yourself on LLVM? JIT
> comes to mind....
>
> On Sun, 2010-06-20 at 19:43 +0000, Jay K wrote:
>> True, that m3cg is "most" buildable by gcc itself. That gets the most
>> testing by gcc developers.
>> Almost any version will do though.
>> But it is buildable by other C compilers, such as Sun cc and OSF/1's C
>> compiler.
>> Going forward, like to gcc 4.6, a C++ compiler might be needed.
>> OpenBSD uses gcc 3.x on most platforms and 2.x on some older ones.
>> gcc 4.4 and 4.5 actually require a C9x compiler but that is an
>> accidental regression and getting fixed.
>> I found it using OSF/1 cc on Mika's machine. :)
> --
> Dragi?a Duri? 
>
 		 	   		  

From dragisha at m3w.org  Mon Jun 21 08:32:22 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Mon, 21 Jun 2010 08:32:22 +0200
Subject: [M3devel] ***SPAM*** RE:  Linux/ARM? Android?
In-Reply-To: <COL101-W59EAC8AC1D2D1DC0678DA1E6C20@phx.gbl>
References: <5CEB90C2-DC07-4D4C-9E90-FCCEA356E065@sol42.com>
	,, <974011.74052.qm@web23608.mail.ird.yahoo.com>
	,<COL101-W190990CE2CFAD02AC0CBC0E6C20@phx.gbl>
	,<1277066306.5571.4.camel@localhost>
	<COL101-W59EAC8AC1D2D1DC0678DA1E6C20@phx.gbl>
Message-ID: <1277101942.5571.83.camel@localhost>

Is there such thing as overportability ?:) Are we really so desperate to
reach for users and supporters to fight for ones using most obsolete and
obscure hardware/OSes? Outside of what gcc covers?

My mention of LLVM was not "get more platforms" but "get new angle".

On Sun, 2010-06-20 at 22:40 +0000, Jay K wrote:
> 
> If you generate C, you get one very portable distribution format -- a
> bunch of C in .tar.gz.
> Far more portable than what we have today.

  If we all just stick to C, we'll have that, minus all learning and
programming and debugging and packaging and marketing effort for
Modula-3. Don't you think so? And this compares because...

> You get possibly better optimization.
> Possibly better debugging.
> A much smaller source tree -- no need for m3cc or m3gdb.

  And you get to talk C with your program when debugging, instead of
M3... How nice :). We can have Modula-3 developers in teams who don't
even need to know Modula-3? 

  m3gdb we need, that is for sure. As for m3cc... There comes LLVM
also... What we need is coordinated effort with gcc|LLVM people so we
can get recognition and "officiality" of our patches. And once for all
stop running behind in versions used.

> Consider all the platforms that aren't well supported by gcc or LLVM.

  All that hardware people are throwing away....

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



From jay.krell at cornell.edu  Mon Jun 21 09:55:19 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 21 Jun 2010 07:55:19 +0000
Subject: [M3devel] checking function pointers for null?
Message-ID: <COL101-W351A37DF7AC3C7A9A9E1ACE6C30@phx.gbl>


This is code that calls a function pointer:


??????? testq?? %rbx, %rbx ; test function pointer for null
??????? je????? L6
??????? cmpq??? $-1, (%rbx) ; check for closure marker
??????? jne???? L6? ; if not a closure, goto L6
??????? movq??? 16(%rbx), %r13 ; r13=static chain (ought to use r10?) 
??????? movq??? 8(%rbx), %rax ; rax=actual function pointer
??????? jmp???? L8
L6:
??????? movq??? %rbx, %rax ; rax=actual function pointer
L8:
??????? movq??? %r13, %r10 ; r10=static chain (it should have just used r10 in the first place? or is r13 otherwise the previous static chain?)
??????? call??? *%rax


What is the point of the initial testq/je, if we are just going to jump to the address anyway?
Should we do something else if in fact the function pointer is null? Or just let a jump to null fail as it will?
You know -- it seems me we should do either more or less here.
More: report a null deref by calling m3_fault
Less: remove the null check 


?- Jay
 		 	   		  

From hosking at cs.purdue.edu  Mon Jun 21 16:26:31 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 21 Jun 2010 10:26:31 -0400
Subject: [M3devel] checking function pointers for null?
In-Reply-To: <COL101-W351A37DF7AC3C7A9A9E1ACE6C30@phx.gbl>
References: <COL101-W351A37DF7AC3C7A9A9E1ACE6C30@phx.gbl>
Message-ID: <3A74ECDB-2F76-4B7A-B7F3-CAEBA38F129B@cs.purdue.edu>

Is this code from M3CG or the Windows native backend?

If from M3CG perhaps you can show us the M3CG IR code.

On 21 Jun 2010, at 03:55, Jay K wrote:

> 
> This is code that calls a function pointer:
> 
> 
>         testq   %rbx, %rbx ; test function pointer for null
>         je      L6
>         cmpq    $-1, (%rbx) ; check for closure marker
>         jne     L6  ; if not a closure, goto L6
>         movq    16(%rbx), %r13 ; r13=static chain (ought to use r10?) 
>         movq    8(%rbx), %rax ; rax=actual function pointer
>         jmp     L8
> L6:
>         movq    %rbx, %rax ; rax=actual function pointer
> L8:
>         movq    %r13, %r10 ; r10=static chain (it should have just used r10 in the first place? or is r13 otherwise the previous static chain?)
>         call    *%rax
> 
> 
> What is the point of the initial testq/je, if we are just going to jump to the address anyway?
> Should we do something else if in fact the function pointer is null? Or just let a jump to null fail as it will?
> You know -- it seems me we should do either more or less here.
> More: report a null deref by calling m3_fault
> Less: remove the null check 
> 
> 
>  - Jay
> 		 	   		  



From jay.krell at cornell.edu  Mon Jun 21 19:47:48 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 21 Jun 2010 17:47:48 +0000
Subject: [M3devel] checking function pointers for null?
In-Reply-To: <3A74ECDB-2F76-4B7A-B7F3-CAEBA38F129B@cs.purdue.edu>
References: <COL101-W351A37DF7AC3C7A9A9E1ACE6C30@phx.gbl>,
	<3A74ECDB-2F76-4B7A-B7F3-CAEBA38F129B@cs.purdue.edu>
Message-ID: <COL101-W499F828D94ADA12FF53275E6C30@phx.gbl>

Neither backend would add these checks themself, it is m3cg, IR later.

> Subject: Re: [M3devel] checking function pointers for null?
> From: hosking at cs.purdue.edu
> Date: Mon, 21 Jun 2010 10:26:31 -0400
> CC: m3devel at elegosoft.com
> To: jay.krell at cornell.edu
> 
> Is this code from M3CG or the Windows native backend?
> 
> If from M3CG perhaps you can show us the M3CG IR code.
> 
> On 21 Jun 2010, at 03:55, Jay K wrote:
> 
> > 
> > This is code that calls a function pointer:
> > 
> > 
> >         testq   %rbx, %rbx ; test function pointer for null
> >         je      L6
> >         cmpq    $-1, (%rbx) ; check for closure marker
> >         jne     L6  ; if not a closure, goto L6
> >         movq    16(%rbx), %r13 ; r13=static chain (ought to use r10?) 
> >         movq    8(%rbx), %rax ; rax=actual function pointer
> >         jmp     L8
> > L6:
> >         movq    %rbx, %rax ; rax=actual function pointer
> > L8:
> >         movq    %r13, %r10 ; r10=static chain (it should have just used r10 in the first place? or is r13 otherwise the previous static chain?)
> >         call    *%rax
> > 
> > 
> > What is the point of the initial testq/je, if we are just going to jump to the address anyway?
> > Should we do something else if in fact the function pointer is null? Or just let a jump to null fail as it will?
> > You know -- it seems me we should do either more or less here.
> > More: report a null deref by calling m3_fault
> > Less: remove the null check 
> > 
> > 
> >  - Jay
> > 		 	   		  
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100621/13be0de5/attachment.html>

From jay.krell at cornell.edu  Mon Jun 21 22:55:06 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 21 Jun 2010 20:55:06 +0000
Subject: [M3devel] checking function pointers for null?
In-Reply-To: <3A74ECDB-2F76-4B7A-B7F3-CAEBA38F129B@cs.purdue.edu>
References: <COL101-W351A37DF7AC3C7A9A9E1ACE6C30@phx.gbl>,
	<3A74ECDB-2F76-4B7A-B7F3-CAEBA38F129B@cs.purdue.edu>
Message-ID: <COL101-W35300463AE825ED4FE7EB5E6C30@phx.gbl>


The backend is doing what the front/middle end asks.
My original question stands: The check for NULL is worthless, right?
Either it should do more: call m3_fault
Or it should do less: don't bother checking, let the hardware do it at the call or marker check (the marker check, in reality)
?

I can understand the stance that the software does all the checking. That we don't/shouldn't depend on hardware checking.
? Though that isn't true -- the rationale for "Target.first_readable_address" or such is that hardware checks for NULL deref,
?? and even "small deref" -- anything in the first page at least.

But this seems in between -- it avoids the null deref for the marker check but doesn't avoid it for the call.
Perhaps there is an idea that the hardware checking is somehow different for data vs. code??


MODULE Main;

TYPE Function = PROCEDURE ();

PROCEDURE C(a:Function) =
BEGIN
?a();
END C;

BEGIN
END Main.


(23) begin_procedure
? procedure Main__C
?Main__C(24) set_source_line
? source line??? 6
(25) set_source_line
? source line??? 7
(26) load
? type:addr
? type:addr
? m3cg_load (M3_CQL02D_a): offset 0x0, convert addr -> addr
(27) declare_temp
? type:addr
? temp var type:addr size:0x40 alignment:0x40
(28) store
? type:addr
? type:addr
? store (noname) offset:0x0 src_t:addr dst_t:addr
(29) start_call_indirect
? type:void
? start call procedure indirect type:void
(30) load
? type:addr
? type:addr
? m3cg_load (noname): offset 0x0, convert addr -> addr
(31) load_nil??? ***
(32) if_eq???????? ***
? type:addr
? label 1
(33) load
? type:addr
? type:addr
? m3cg_load (noname): offset 0x0, convert addr -> addr
(34) load_indirect
? type:int64
? type:int64
? load address offset:0x0 src_t:int64 dst_t:int64
(35) load_integer
? type:int64
? integer i:0xfe n_bytes:0x1 0x00000000000000001 sign -1
(36) if_ne
? type:int64
? label 1
(37) set_label
? label 2
(38) load
? type:addr
? type:addr
? m3cg_load (noname): offset 0x0, convert addr -> addr
(39) load_indirect
? type:addr
? type:addr
? load address offset:0x80 src_t:addr dst_t:addr
(40) pop_static_link
(41) load
? type:addr
? type:addr
? m3cg_load (noname): offset 0x0, convert addr -> addr
(42) load_indirect
? type:addr
? type:addr
? load address offset:0x40 src_t:addr dst_t:addr
(43) store
? type:addr
? type:addr
? store (noname) offset:0x0 src_t:addr dst_t:addr
(44) set_label
? label 1
(45) load
? type:addr
? type:addr
? m3cg_load (noname): offset 0x0, convert addr -> addr
(46) call_indirect
? type:void
? call procedure indirect type:void
(47) set_source_line
? source line??? 8
(48) exit_proc
? type:void
(49) free_temp
(50) end_procedure
? procedure Main__C

?- Jay


________________________________
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com
> Subject: RE: [M3devel] checking function pointers for null?
> Date: Mon, 21 Jun 2010 17:47:48 +0000
>
>
>
>
>
>
>
> Neither backend would add these checks themself, it is m3cg, IR later.
>
>> Subject: Re: [M3devel] checking function pointers for null?
>> From: hosking at cs.purdue.edu
>> Date: Mon, 21 Jun 2010 10:26:31 -0400
>> CC: m3devel at elegosoft.com
>> To: jay.krell at cornell.edu
>>
>> Is this code from M3CG or the Windows native backend?
>>
>> If from M3CG perhaps you can show us the M3CG IR code.
>>
>> On 21 Jun 2010, at 03:55, Jay K wrote:
>>
>>>
>>> This is code that calls a function pointer:
>>>
>>>
>>> testq %rbx, %rbx ; test function pointer for null
>>> je L6
>>> cmpq $-1, (%rbx) ; check for closure marker
>>> jne L6 ; if not a closure, goto L6
>>> movq 16(%rbx), %r13 ; r13=static chain (ought to use r10?)
>>> movq 8(%rbx), %rax ; rax=actual function pointer
>>> jmp L8
>>> L6:
>>> movq %rbx, %rax ; rax=actual function pointer
>>> L8:
>>> movq %r13, %r10 ; r10=static chain (it should have just used r10 in the first place? or is r13 otherwise the previous static chain?)
>>> call *%rax
>>>
>>>
>>> What is the point of the initial testq/je, if we are just going to jump to the address anyway?
>>> Should we do something else if in fact the function pointer is null? Or just let a jump to null fail as it will?
>>> You know -- it seems me we should do either more or less here.
>>> More: report a null deref by calling m3_fault
>>> Less: remove the null check
>>>
>>>
>>> - Jay
>>>
>>
 		 	   		  

From hosking at cs.purdue.edu  Mon Jun 21 23:09:08 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 21 Jun 2010 17:09:08 -0400
Subject: [M3devel] checking function pointers for null?
In-Reply-To: <COL101-W35300463AE825ED4FE7EB5E6C30@phx.gbl>
References: <COL101-W351A37DF7AC3C7A9A9E1ACE6C30@phx.gbl>,
	<3A74ECDB-2F76-4B7A-B7F3-CAEBA38F129B@cs.purdue.edu>
	<COL101-W35300463AE825ED4FE7EB5E6C30@phx.gbl>
Message-ID: <8A2BCF94-43E9-44F5-9C63-AC71A4563E0B@cs.purdue.edu>

I want to see the IR.


On 21 Jun 2010, at 16:55, Jay K wrote:

> 
> The backend is doing what the front/middle end asks.
> My original question stands: The check for NULL is worthless, right?
> Either it should do more: call m3_fault
> Or it should do less: don't bother checking, let the hardware do it at the call or marker check (the marker check, in reality)
> ?
> 
> I can understand the stance that the software does all the checking. That we don't/shouldn't depend on hardware checking.
>  Though that isn't true -- the rationale for "Target.first_readable_address" or such is that hardware checks for NULL deref,
>   and even "small deref" -- anything in the first page at least.
> 
> But this seems in between -- it avoids the null deref for the marker check but doesn't avoid it for the call.
> Perhaps there is an idea that the hardware checking is somehow different for data vs. code??
> 
> 
> MODULE Main;
> 
> TYPE Function = PROCEDURE ();
> 
> PROCEDURE C(a:Function) =
> BEGIN
> a();
> END C;
> 
> BEGIN
> END Main.
> 
> 
> (23) begin_procedure
>  procedure Main__C
> Main__C(24) set_source_line
>  source line    6
> (25) set_source_line
>  source line    7
> (26) load
>  type:addr
>  type:addr
>  m3cg_load (M3_CQL02D_a): offset 0x0, convert addr -> addr
> (27) declare_temp
>  type:addr
>  temp var type:addr size:0x40 alignment:0x40
> (28) store
>  type:addr
>  type:addr
>  store (noname) offset:0x0 src_t:addr dst_t:addr
> (29) start_call_indirect
>  type:void
>  start call procedure indirect type:void
> (30) load
>  type:addr
>  type:addr
>  m3cg_load (noname): offset 0x0, convert addr -> addr
> (31) load_nil    ***
> (32) if_eq         ***
>  type:addr
>  label 1
> (33) load
>  type:addr
>  type:addr
>  m3cg_load (noname): offset 0x0, convert addr -> addr
> (34) load_indirect
>  type:int64
>  type:int64
>  load address offset:0x0 src_t:int64 dst_t:int64
> (35) load_integer
>  type:int64
>  integer i:0xfe n_bytes:0x1 0x00000000000000001 sign -1
> (36) if_ne
>  type:int64
>  label 1
> (37) set_label
>  label 2
> (38) load
>  type:addr
>  type:addr
>  m3cg_load (noname): offset 0x0, convert addr -> addr
> (39) load_indirect
>  type:addr
>  type:addr
>  load address offset:0x80 src_t:addr dst_t:addr
> (40) pop_static_link
> (41) load
>  type:addr
>  type:addr
>  m3cg_load (noname): offset 0x0, convert addr -> addr
> (42) load_indirect
>  type:addr
>  type:addr
>  load address offset:0x40 src_t:addr dst_t:addr
> (43) store
>  type:addr
>  type:addr
>  store (noname) offset:0x0 src_t:addr dst_t:addr
> (44) set_label
>  label 1
> (45) load
>  type:addr
>  type:addr
>  m3cg_load (noname): offset 0x0, convert addr -> addr
> (46) call_indirect
>  type:void
>  call procedure indirect type:void
> (47) set_source_line
>  source line    8
> (48) exit_proc
>  type:void
> (49) free_temp
> (50) end_procedure
>  procedure Main__C
> 
> - Jay
> 
> 
> ________________________________
>> From: jay.krell at cornell.edu
>> To: hosking at cs.purdue.edu
>> CC: m3devel at elegosoft.com
>> Subject: RE: [M3devel] checking function pointers for null?
>> Date: Mon, 21 Jun 2010 17:47:48 +0000
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> Neither backend would add these checks themself, it is m3cg, IR later.
>> 
>>> Subject: Re: [M3devel] checking function pointers for null?
>>> From: hosking at cs.purdue.edu
>>> Date: Mon, 21 Jun 2010 10:26:31 -0400
>>> CC: m3devel at elegosoft.com
>>> To: jay.krell at cornell.edu
>>> 
>>> Is this code from M3CG or the Windows native backend?
>>> 
>>> If from M3CG perhaps you can show us the M3CG IR code.
>>> 
>>> On 21 Jun 2010, at 03:55, Jay K wrote:
>>> 
>>>> 
>>>> This is code that calls a function pointer:
>>>> 
>>>> 
>>>> testq %rbx, %rbx ; test function pointer for null
>>>> je L6
>>>> cmpq $-1, (%rbx) ; check for closure marker
>>>> jne L6 ; if not a closure, goto L6
>>>> movq 16(%rbx), %r13 ; r13=static chain (ought to use r10?)
>>>> movq 8(%rbx), %rax ; rax=actual function pointer
>>>> jmp L8
>>>> L6:
>>>> movq %rbx, %rax ; rax=actual function pointer
>>>> L8:
>>>> movq %r13, %r10 ; r10=static chain (it should have just used r10 in the first place? or is r13 otherwise the previous static chain?)
>>>> call *%rax
>>>> 
>>>> 
>>>> What is the point of the initial testq/je, if we are just going to jump to the address anyway?
>>>> Should we do something else if in fact the function pointer is null? Or just let a jump to null fail as it will?
>>>> You know -- it seems me we should do either more or less here.
>>>> More: report a null deref by calling m3_fault
>>>> Less: remove the null check
>>>> 
>>>> 
>>>> - Jay
>>>> 
>>> 
> 		 	   		  



From jay.krell at cornell.edu  Tue Jun 22 02:38:37 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 22 Jun 2010 00:38:37 +0000
Subject: [M3devel] checking function pointers for null?
In-Reply-To: <8A2BCF94-43E9-44F5-9C63-AC71A4563E0B@cs.purdue.edu>
References: <COL101-W351A37DF7AC3C7A9A9E1ACE6C30@phx.gbl>, ,
	<3A74ECDB-2F76-4B7A-B7F3-CAEBA38F129B@cs.purdue.edu>,
	<COL101-W35300463AE825ED4FE7EB5E6C30@phx.gbl>,
	<8A2BCF94-43E9-44F5-9C63-AC71A4563E0B@cs.purdue.edu>
Message-ID: <COL101-W28069DAED40F76BDA6CA4FE6C40@phx.gbl>


Isn't that the cm3cg -y output below?
It's all fairly obvious.
 
 
I looked, I might have the names wrong, but there is a function is_closure in the frontend. It is used by more than just call, e.g. it is used for function pointer comparison. So the "silent null check" is sometimes required, but I think it is dubious for call. (And comparing function pointers to other than null is dubious, and often doesn't "work" in the face of dynamic linking.)
 
 
 - Jay


----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Mon, 21 Jun 2010 17:09:08 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] checking function pointers for null?
>
> I want to see the IR.
>
>
> On 21 Jun 2010, at 16:55, Jay K wrote:
>
>>
>> The backend is doing what the front/middle end asks.
>> My original question stands: The check for NULL is worthless, right?
>> Either it should do more: call m3_fault
>> Or it should do less: don't bother checking, let the hardware do it at the call or marker check (the marker check, in reality)
>> ?
>>
>> I can understand the stance that the software does all the checking. That we don't/shouldn't depend on hardware checking.
>> Though that isn't true -- the rationale for "Target.first_readable_address" or such is that hardware checks for NULL deref,
>> and even "small deref" -- anything in the first page at least.
>>
>> But this seems in between -- it avoids the null deref for the marker check but doesn't avoid it for the call.
>> Perhaps there is an idea that the hardware checking is somehow different for data vs. code??
>>
>>
>> MODULE Main;
>>
>> TYPE Function = PROCEDURE ();
>>
>> PROCEDURE C(a:Function) =
>> BEGIN
>> a();
>> END C;
>>
>> BEGIN
>> END Main.
>>
>>
>> (23) begin_procedure
>> procedure Main__C
>> Main__C(24) set_source_line
>> source line 6
>> (25) set_source_line
>> source line 7
>> (26) load
>> type:addr
>> type:addr
>> m3cg_load (M3_CQL02D_a): offset 0x0, convert addr -> addr
>> (27) declare_temp
>> type:addr
>> temp var type:addr size:0x40 alignment:0x40
>> (28) store
>> type:addr
>> type:addr
>> store (noname) offset:0x0 src_t:addr dst_t:addr
>> (29) start_call_indirect
>> type:void
>> start call procedure indirect type:void
>> (30) load
>> type:addr
>> type:addr
>> m3cg_load (noname): offset 0x0, convert addr -> addr
>> (31) load_nil ***
>> (32) if_eq ***
>> type:addr
>> label 1
>> (33) load
>> type:addr
>> type:addr
>> m3cg_load (noname): offset 0x0, convert addr -> addr
>> (34) load_indirect
>> type:int64
>> type:int64
>> load address offset:0x0 src_t:int64 dst_t:int64
>> (35) load_integer
>> type:int64
>> integer i:0xfe n_bytes:0x1 0x00000000000000001 sign -1
>> (36) if_ne
>> type:int64
>> label 1
>> (37) set_label
>> label 2
>> (38) load
>> type:addr
>> type:addr
>> m3cg_load (noname): offset 0x0, convert addr -> addr
>> (39) load_indirect
>> type:addr
>> type:addr
>> load address offset:0x80 src_t:addr dst_t:addr
>> (40) pop_static_link
>> (41) load
>> type:addr
>> type:addr
>> m3cg_load (noname): offset 0x0, convert addr -> addr
>> (42) load_indirect
>> type:addr
>> type:addr
>> load address offset:0x40 src_t:addr dst_t:addr
>> (43) store
>> type:addr
>> type:addr
>> store (noname) offset:0x0 src_t:addr dst_t:addr
>> (44) set_label
>> label 1
>> (45) load
>> type:addr
>> type:addr
>> m3cg_load (noname): offset 0x0, convert addr -> addr
>> (46) call_indirect
>> type:void
>> call procedure indirect type:void
>> (47) set_source_line
>> source line 8
>> (48) exit_proc
>> type:void
>> (49) free_temp
>> (50) end_procedure
>> procedure Main__C
>>
>> - Jay
>>
>>
>> ________________________________
>>> From: jay.krell at cornell.edu
>>> To: hosking at cs.purdue.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: RE: [M3devel] checking function pointers for null?
>>> Date: Mon, 21 Jun 2010 17:47:48 +0000
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Neither backend would add these checks themself, it is m3cg, IR later.
>>>
>>>> Subject: Re: [M3devel] checking function pointers for null?
>>>> From: hosking at cs.purdue.edu
>>>> Date: Mon, 21 Jun 2010 10:26:31 -0400
>>>> CC: m3devel at elegosoft.com
>>>> To: jay.krell at cornell.edu
>>>>
>>>> Is this code from M3CG or the Windows native backend?
>>>>
>>>> If from M3CG perhaps you can show us the M3CG IR code.
>>>>
>>>> On 21 Jun 2010, at 03:55, Jay K wrote:
>>>>
>>>>>
>>>>> This is code that calls a function pointer:
>>>>>
>>>>>
>>>>> testq %rbx, %rbx ; test function pointer for null
>>>>> je L6
>>>>> cmpq $-1, (%rbx) ; check for closure marker
>>>>> jne L6 ; if not a closure, goto L6
>>>>> movq 16(%rbx), %r13 ; r13=static chain (ought to use r10?)
>>>>> movq 8(%rbx), %rax ; rax=actual function pointer
>>>>> jmp L8
>>>>> L6:
>>>>> movq %rbx, %rax ; rax=actual function pointer
>>>>> L8:
>>>>> movq %r13, %r10 ; r10=static chain (it should have just used r10 in the first place? or is r13 otherwise the previous static chain?)
>>>>> call *%rax
>>>>>
>>>>>
>>>>> What is the point of the initial testq/je, if we are just going to jump to the address anyway?
>>>>> Should we do something else if in fact the function pointer is null? Or just let a jump to null fail as it will?
>>>>> You know -- it seems me we should do either more or less here.
>>>>> More: report a null deref by calling m3_fault
>>>>> Less: remove the null check
>>>>>
>>>>>
>>>>> - Jay
>>>>>
>>>>
>>
> 		 	   		  

From jay.krell at cornell.edu  Wed Jun 23 15:40:35 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 23 Jun 2010 13:40:35 +0000
Subject: [M3devel] CHAR vs. Ctypes.char?
Message-ID: <COL101-W44D06778829668CD8100FDE6C50@phx.gbl>


Is it deliberate that CHAR and Ctypes.char don't match?
I'm building the tree with -new_adr.
"Many" of the breaks are due to this mismatch. Not real bugs. I use LOOPHOLE to let it compile.
"Many" are due to socklen_t. Real bugs on 64bit problems, at least in head.
I'm not sure there are any others yet.

?- Jay
 		 	   		  

From hosking at cs.purdue.edu  Wed Jun 23 15:57:04 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 23 Jun 2010 09:57:04 -0400
Subject: [M3devel] CHAR vs. Ctypes.char?
In-Reply-To: <COL101-W44D06778829668CD8100FDE6C50@phx.gbl>
References: <COL101-W44D06778829668CD8100FDE6C50@phx.gbl>
Message-ID: <9FB15BB1-E00A-4AB4-A580-71981F0A65C0@cs.purdue.edu>

CHAR is an enumeration.
Ctypes.char is a subrange.

Never the twain shall meet.

On 23 Jun 2010, at 09:40, Jay K wrote:

> 
> Is it deliberate that CHAR and Ctypes.char don't match?
> I'm building the tree with -new_adr.
> "Many" of the breaks are due to this mismatch. Not real bugs. I use LOOPHOLE to let it compile.
> "Many" are due to socklen_t. Real bugs on 64bit problems, at least in head.
> I'm not sure there are any others yet.
> 
>  - Jay
> 		 	   		  



From jay.krell at cornell.edu  Thu Jun 24 00:52:25 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 23 Jun 2010 22:52:25 +0000
Subject: [M3devel] CHAR vs. Ctypes.char?
In-Reply-To: <9FB15BB1-E00A-4AB4-A580-71981F0A65C0@cs.purdue.edu>
References: <COL101-W44D06778829668CD8100FDE6C50@phx.gbl>,
	<9FB15BB1-E00A-4AB4-A580-71981F0A65C0@cs.purdue.edu>
Message-ID: <COL101-W4372CBD0AF692D3E5990CCE6C50@phx.gbl>


Something should change.
I'm not sure exactly what but I'll make some suggestions.


char_star changed from UNTRACED REF char to UNTRACED REF CHAR
? Probably not this.
? Possibly introduce Utypes.char_star = UNTRACED REF CHAR
? but leave Ctypes.char_star alone. Possibly. This is I think the least
? likely option.
? 

and/or


Utypes.CHAR_star introduced = UNTRACED REF CHAR
many uses of char_star in m3core/src/unix changed to CHAR_star


and/or


Text.i3 already has FromChars that takes array of CHAR
add function FromCChars or somesuch that takes array of Ctypes.char
This I think is most likely.
Even though it adds to a "standard" interface.
It could be TextEx or TextExtras or such if that helps.


In particular, we often have:


Unix.i3: PROCEDURE GetFoo(char_star);


Wrapper.i3:
PROCEDURE GetFoo():TEXT=
VAR buff; ARRAY [0..N] of CHAR;
BEGIN
? Unix.GetFoo(ADR(buff[0]));
? RETURN Text.FromChars(buff);
END GetFoo;


This doesn't work with -new_adr.
? because ADR(CHAR) != ADR(char).
? 

At a minimum you have to:
? Unix.GetFoo(LOOPHOLE(ADR(buff[0]), ADDRESS));


but I'd much rather something more typesafe.


e.g.:
Wrapper.i3:
PROCEDURE GetFoo():TEXT=
VAR buff; ARRAY [0..N] of Ctypes.char;
BEGIN
? Unix.GetFoo(ADR(buff[0]));
? RETURN Text.FromCChars(buff);
END GetFoo;

or

Unix.i3:
PROCEDURE GetFoo(CHAR_star);

Wrapper.i3:
PROCEDURE GetFoo():TEXT=
VAR buff; ARRAY [0..N] of CHAR;
BEGIN
? Unix.GetFoo(ADR(buff[0]));
? RETURN Text.FromChars(buff);
END GetFoo;


or even something fancier like:


Unix.i3:
PROCEDURE GetFoo():TEXT; !



To whatever extent this occurs in sysutils, if at all, probably have to just LOOPHOLE,
since it needs to be compatible with a mix of compilers and m3core.


?- Jay









----------------------------------------
> Subject: Re: [M3devel] CHAR vs. Ctypes.char?
> From: hosking at cs.purdue.edu
> Date: Wed, 23 Jun 2010 09:57:04 -0400
> CC: m3devel at elegosoft.com
> To: jay.krell at cornell.edu
>
> CHAR is an enumeration.
> Ctypes.char is a subrange.
>
> Never the twain shall meet.
>
> On 23 Jun 2010, at 09:40, Jay K wrote:
>
>>
>> Is it deliberate that CHAR and Ctypes.char don't match?
>> I'm building the tree with -new_adr.
>> "Many" of the breaks are due to this mismatch. Not real bugs. I use LOOPHOLE to let it compile.
>> "Many" are due to socklen_t. Real bugs on 64bit problems, at least in head.
>> I'm not sure there are any others yet.
>>
>> - Jay
>>
>
 		 	   		  

From jay.krell at cornell.edu  Thu Jun 24 00:59:10 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 23 Jun 2010 22:59:10 +0000
Subject: [M3devel] -new_adr the default?
Message-ID: <COL101-W54C167232C5F9B2A6C4963E6C50@phx.gbl>


I'd like to make -new_adr the default.
It is more typesafe than the current way and finds bugs.
? Granted, so far I think only bugs that I introduced.


First I will make the tree compile either way.
?Such as by fixing the bugs and resolving somehow the char vs. CHAR breaks.


Changing this does break code, albeit only unsafe code.
? There isn't much of that? Right? :)
Sometimes that code had bugs, sometimes not.


I believe type safety and static checking (and sometimes runtime checking) do have a place in unsafe code.
?Maybe not as much as in safe code, but definitely still something.


The old way is that ADR return ADDRESS, similar to void*, and it is silently convertable to any pointer type. I think.


The new way is that ADR(T) returns UNTRACED REF T is is only silently convertable to ADDRESS? Or nothing at all?
?Esp. not silently convertable to UNTRACED REF U.


So there are buggy places that do:
PROCEDURE Foo(UNTRACED REF T);

PROCEDURE Bar()
VAR u: U;
BEGIN
?Foo(ADR(u));
END Bar;


That compile with old ADR but not with new ADR.
As I changed socklent_t between int and INTEGER, such code silently kept compiling.
? But possibly silently corrupting the stack or producing the wrong data.


This -new_adr feature was already implemented in the compiler unknown long ago.
? I didn't know but Tony pointed it out.
We should probably look at its impementation make sure we aren't switching on some buggy unused code.
So far switching it on I've only seen correct new errors.


?- Jay
 		 	   		  

From hosking at cs.purdue.edu  Thu Jun 24 01:09:35 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 23 Jun 2010 19:09:35 -0400
Subject: [M3devel] CHAR vs. Ctypes.char?
In-Reply-To: <COL101-W4372CBD0AF692D3E5990CCE6C50@phx.gbl>
References: <COL101-W44D06778829668CD8100FDE6C50@phx.gbl>,
	<9FB15BB1-E00A-4AB4-A580-71981F0A65C0@cs.purdue.edu>
	<COL101-W4372CBD0AF692D3E5990CCE6C50@phx.gbl>
Message-ID: <44BE3590-165E-42A2-AB10-4330DBE45205@cs.purdue.edu>

ADR isn't safe so why not just LOOPHOLE?

Sent from my iPhone

On Jun 23, 2010, at 6:52 PM, Jay K <jay.krell at cornell.edu> wrote:

>
> Something should change.
> I'm not sure exactly what but I'll make some suggestions.
>
>
> char_star changed from UNTRACED REF char to UNTRACED REF CHAR
>   Probably not this.
>   Possibly introduce Utypes.char_star = UNTRACED REF CHAR
>   but leave Ctypes.char_star alone. Possibly. This is I think the  
> least
>   likely option.
>
>
> and/or
>
>
> Utypes.CHAR_star introduced = UNTRACED REF CHAR
> many uses of char_star in m3core/src/unix changed to CHAR_star
>
>
> and/or
>
>
> Text.i3 already has FromChars that takes array of CHAR
> add function FromCChars or somesuch that takes array of Ctypes.char
> This I think is most likely.
> Even though it adds to a "standard" interface.
> It could be TextEx or TextExtras or such if that helps.
>
>
> In particular, we often have:
>
>
> Unix.i3: PROCEDURE GetFoo(char_star);
>
>
> Wrapper.i3:
> PROCEDURE GetFoo():TEXT=
> VAR buff; ARRAY [0..N] of CHAR;
> BEGIN
>   Unix.GetFoo(ADR(buff[0]));
>   RETURN Text.FromChars(buff);
> END GetFoo;
>
>
> This doesn't work with -new_adr.
>   because ADR(CHAR) != ADR(char).
>
>
> At a minimum you have to:
>   Unix.GetFoo(LOOPHOLE(ADR(buff[0]), ADDRESS));
>
>
> but I'd much rather something more typesafe.
>
>
> e.g.:
> Wrapper.i3:
> PROCEDURE GetFoo():TEXT=
> VAR buff; ARRAY [0..N] of Ctypes.char;
> BEGIN
>   Unix.GetFoo(ADR(buff[0]));
>   RETURN Text.FromCChars(buff);
> END GetFoo;
>
> or
>
> Unix.i3:
> PROCEDURE GetFoo(CHAR_star);
>
> Wrapper.i3:
> PROCEDURE GetFoo():TEXT=
> VAR buff; ARRAY [0..N] of CHAR;
> BEGIN
>   Unix.GetFoo(ADR(buff[0]));
>   RETURN Text.FromChars(buff);
> END GetFoo;
>
>
> or even something fancier like:
>
>
> Unix.i3:
> PROCEDURE GetFoo():TEXT; !
>
>
>
> To whatever extent this occurs in sysutils, if at all, probably have  
> to just LOOPHOLE,
> since it needs to be compatible with a mix of compilers and m3core.
>
>
>  - Jay
>
>
>
>
>
>
>
>
>
> ----------------------------------------
>> Subject: Re: [M3devel] CHAR vs. Ctypes.char?
>> From: hosking at cs.purdue.edu
>> Date: Wed, 23 Jun 2010 09:57:04 -0400
>> CC: m3devel at elegosoft.com
>> To: jay.krell at cornell.edu
>>
>> CHAR is an enumeration.
>> Ctypes.char is a subrange.
>>
>> Never the twain shall meet.
>>
>> On 23 Jun 2010, at 09:40, Jay K wrote:
>>
>>>
>>> Is it deliberate that CHAR and Ctypes.char don't match?
>>> I'm building the tree with -new_adr.
>>> "Many" of the breaks are due to this mismatch. Not real bugs. I  
>>> use LOOPHOLE to let it compile.
>>> "Many" are due to socklen_t. Real bugs on 64bit problems, at least  
>>> in head.
>>> I'm not sure there are any others yet.
>>>
>>> - Jay
>>>
>>
>


From jay.krell at cornell.edu  Thu Jun 24 04:24:47 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 24 Jun 2010 02:24:47 +0000
Subject: [M3devel] CHAR vs. Ctypes.char?
In-Reply-To: <44BE3590-165E-42A2-AB10-4330DBE45205@cs.purdue.edu>
References: <COL101-W44D06778829668CD8100FDE6C50@phx.gbl>, ,
	<9FB15BB1-E00A-4AB4-A580-71981F0A65C0@cs.purdue.edu>,
	<COL101-W4372CBD0AF692D3E5990CCE6C50@phx.gbl>,
	<44BE3590-165E-42A2-AB10-4330DBE45205@cs.purdue.edu>
Message-ID: <COL101-W53DD740C001143B75A1426E6C60@phx.gbl>


ADR should be "less unsafe".
Perhaps in general Modula-3 "unsafe" can/should be "less unsafe".
e.g. "Only as unsafe as needed to get the 'usual' job done, and no more".
 
 
Imagine if the types involved actually changed in some other way.
LOOPHOLE would likely make almost anything compile.
Whereas my other suggestions add a significant amount of type checking and deliberately fail to compile many incorrect forms.
 
 
There is not, or should be, this "harsh" line where there are no rules or static checking in unsafe code.
There is still a significant amount of checking and a significant confidence that if it compiles, it has a certain amount of correctness and "odds" of working. I've written a lot of C code, even recently. It's not just a lost cause.
 
 
 
 - Jay

----------------------------------------
> From: hosking at cs.purdue.edu
> To: jay.krell at cornell.edu
> Date: Wed, 23 Jun 2010 19:09:35 -0400
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] CHAR vs. Ctypes.char?
>
> ADR isn't safe so why not just LOOPHOLE?
>
> Sent from my iPhone
>
> On Jun 23, 2010, at 6:52 PM, Jay K wrote:
>
>>
>> Something should change.
>> I'm not sure exactly what but I'll make some suggestions.
>>
>>
>> char_star changed from UNTRACED REF char to UNTRACED REF CHAR
>> Probably not this.
>> Possibly introduce Utypes.char_star = UNTRACED REF CHAR
>> but leave Ctypes.char_star alone. Possibly. This is I think the
>> least
>> likely option.
>>
>>
>> and/or
>>
>>
>> Utypes.CHAR_star introduced = UNTRACED REF CHAR
>> many uses of char_star in m3core/src/unix changed to CHAR_star
>>
>>
>> and/or
>>
>>
>> Text.i3 already has FromChars that takes array of CHAR
>> add function FromCChars or somesuch that takes array of Ctypes.char
>> This I think is most likely.
>> Even though it adds to a "standard" interface.
>> It could be TextEx or TextExtras or such if that helps.
>>
>>
>> In particular, we often have:
>>
>>
>> Unix.i3: PROCEDURE GetFoo(char_star);
>>
>>
>> Wrapper.i3:
>> PROCEDURE GetFoo():TEXT=
>> VAR buff; ARRAY [0..N] of CHAR;
>> BEGIN
>> Unix.GetFoo(ADR(buff[0]));
>> RETURN Text.FromChars(buff);
>> END GetFoo;
>>
>>
>> This doesn't work with -new_adr.
>> because ADR(CHAR) != ADR(char).
>>
>>
>> At a minimum you have to:
>> Unix.GetFoo(LOOPHOLE(ADR(buff[0]), ADDRESS));
>>
>>
>> but I'd much rather something more typesafe.
>>
>>
>> e.g.:
>> Wrapper.i3:
>> PROCEDURE GetFoo():TEXT=
>> VAR buff; ARRAY [0..N] of Ctypes.char;
>> BEGIN
>> Unix.GetFoo(ADR(buff[0]));
>> RETURN Text.FromCChars(buff);
>> END GetFoo;
>>
>> or
>>
>> Unix.i3:
>> PROCEDURE GetFoo(CHAR_star);
>>
>> Wrapper.i3:
>> PROCEDURE GetFoo():TEXT=
>> VAR buff; ARRAY [0..N] of CHAR;
>> BEGIN
>> Unix.GetFoo(ADR(buff[0]));
>> RETURN Text.FromChars(buff);
>> END GetFoo;
>>
>>
>> or even something fancier like:
>>
>>
>> Unix.i3:
>> PROCEDURE GetFoo():TEXT; !
>>
>>
>>
>> To whatever extent this occurs in sysutils, if at all, probably have
>> to just LOOPHOLE,
>> since it needs to be compatible with a mix of compilers and m3core.
>>
>>
>> - Jay
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> ----------------------------------------
>>> Subject: Re: [M3devel] CHAR vs. Ctypes.char?
>>> From: hosking at cs.purdue.edu
>>> Date: Wed, 23 Jun 2010 09:57:04 -0400
>>> CC: m3devel at elegosoft.com
>>> To: jay.krell at cornell.edu
>>>
>>> CHAR is an enumeration.
>>> Ctypes.char is a subrange.
>>>
>>> Never the twain shall meet.
>>>
>>> On 23 Jun 2010, at 09:40, Jay K wrote:
>>>
>>>>
>>>> Is it deliberate that CHAR and Ctypes.char don't match?
>>>> I'm building the tree with -new_adr.
>>>> "Many" of the breaks are due to this mismatch. Not real bugs. I
>>>> use LOOPHOLE to let it compile.
>>>> "Many" are due to socklen_t. Real bugs on 64bit problems, at least
>>>> in head.
>>>> I'm not sure there are any others yet.
>>>>
>>>> - Jay
>>>>
>>>
>> 		 	   		  

From jay.krell at cornell.edu  Thu Jun 24 04:27:31 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 24 Jun 2010 02:27:31 +0000
Subject: [M3devel] CHAR vs. Ctypes.char?
In-Reply-To: <COL101-W53DD740C001143B75A1426E6C60@phx.gbl>
References: <COL101-W44D06778829668CD8100FDE6C50@phx.gbl>,
	, , <9FB15BB1-E00A-4AB4-A580-71981F0A65C0@cs.purdue.edu>, ,
	<COL101-W4372CBD0AF692D3E5990CCE6C50@phx.gbl>, ,
	<44BE3590-165E-42A2-AB10-4330DBE45205@cs.purdue.edu>,
	<COL101-W53DD740C001143B75A1426E6C60@phx.gbl>
Message-ID: <COL101-W3D4D5225FE282315363ECE6C60@phx.gbl>


oops...perhaps LOOPHOLE to "CHAR_star" or "char_star" not so bad.
  Program can read locally and decide quickly that basically char==CHAR and casting related to moving between them not so bad. If the types "really" change, it'd be to WCHAR or such and the LOOPHOLE to CHAR/char_star would still fail to compile.
 
LOOPHOLE to ADDRESS is what I'm avoiding.
 
?
 
Still, I like the idea of Text.FromCtypesChars() or such.
 
 
 - Jay


----------------------------------------
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> Date: Thu, 24 Jun 2010 02:24:47 +0000
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] CHAR vs. Ctypes.char?
>
>
> ADR should be "less unsafe".
> Perhaps in general Modula-3 "unsafe" can/should be "less unsafe".
> e.g. "Only as unsafe as needed to get the 'usual' job done, and no more".
>
>
> Imagine if the types involved actually changed in some other way.
> LOOPHOLE would likely make almost anything compile.
> Whereas my other suggestions add a significant amount of type checking and deliberately fail to compile many incorrect forms.
>
>
> There is not, or should be, this "harsh" line where there are no rules or static checking in unsafe code.
> There is still a significant amount of checking and a significant confidence that if it compiles, it has a certain amount of correctness and "odds" of working. I've written a lot of C code, even recently. It's not just a lost cause.
>
>
>
> - Jay
>
> ----------------------------------------
>> From: hosking at cs.purdue.edu
>> To: jay.krell at cornell.edu
>> Date: Wed, 23 Jun 2010 19:09:35 -0400
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] CHAR vs. Ctypes.char?
>>
>> ADR isn't safe so why not just LOOPHOLE?
>>
>> Sent from my iPhone
>>
>> On Jun 23, 2010, at 6:52 PM, Jay K wrote:
>>
>>>
>>> Something should change.
>>> I'm not sure exactly what but I'll make some suggestions.
>>>
>>>
>>> char_star changed from UNTRACED REF char to UNTRACED REF CHAR
>>> Probably not this.
>>> Possibly introduce Utypes.char_star = UNTRACED REF CHAR
>>> but leave Ctypes.char_star alone. Possibly. This is I think the
>>> least
>>> likely option.
>>>
>>>
>>> and/or
>>>
>>>
>>> Utypes.CHAR_star introduced = UNTRACED REF CHAR
>>> many uses of char_star in m3core/src/unix changed to CHAR_star
>>>
>>>
>>> and/or
>>>
>>>
>>> Text.i3 already has FromChars that takes array of CHAR
>>> add function FromCChars or somesuch that takes array of Ctypes.char
>>> This I think is most likely.
>>> Even though it adds to a "standard" interface.
>>> It could be TextEx or TextExtras or such if that helps.
>>>
>>>
>>> In particular, we often have:
>>>
>>>
>>> Unix.i3: PROCEDURE GetFoo(char_star);
>>>
>>>
>>> Wrapper.i3:
>>> PROCEDURE GetFoo():TEXT=
>>> VAR buff; ARRAY [0..N] of CHAR;
>>> BEGIN
>>> Unix.GetFoo(ADR(buff[0]));
>>> RETURN Text.FromChars(buff);
>>> END GetFoo;
>>>
>>>
>>> This doesn't work with -new_adr.
>>> because ADR(CHAR) != ADR(char).
>>>
>>>
>>> At a minimum you have to:
>>> Unix.GetFoo(LOOPHOLE(ADR(buff[0]), ADDRESS));
>>>
>>>
>>> but I'd much rather something more typesafe.
>>>
>>>
>>> e.g.:
>>> Wrapper.i3:
>>> PROCEDURE GetFoo():TEXT=
>>> VAR buff; ARRAY [0..N] of Ctypes.char;
>>> BEGIN
>>> Unix.GetFoo(ADR(buff[0]));
>>> RETURN Text.FromCChars(buff);
>>> END GetFoo;
>>>
>>> or
>>>
>>> Unix.i3:
>>> PROCEDURE GetFoo(CHAR_star);
>>>
>>> Wrapper.i3:
>>> PROCEDURE GetFoo():TEXT=
>>> VAR buff; ARRAY [0..N] of CHAR;
>>> BEGIN
>>> Unix.GetFoo(ADR(buff[0]));
>>> RETURN Text.FromChars(buff);
>>> END GetFoo;
>>>
>>>
>>> or even something fancier like:
>>>
>>>
>>> Unix.i3:
>>> PROCEDURE GetFoo():TEXT; !
>>>
>>>
>>>
>>> To whatever extent this occurs in sysutils, if at all, probably have
>>> to just LOOPHOLE,
>>> since it needs to be compatible with a mix of compilers and m3core.
>>>
>>>
>>> - Jay
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ----------------------------------------
>>>> Subject: Re: [M3devel] CHAR vs. Ctypes.char?
>>>> From: hosking at cs.purdue.edu
>>>> Date: Wed, 23 Jun 2010 09:57:04 -0400
>>>> CC: m3devel at elegosoft.com
>>>> To: jay.krell at cornell.edu
>>>>
>>>> CHAR is an enumeration.
>>>> Ctypes.char is a subrange.
>>>>
>>>> Never the twain shall meet.
>>>>
>>>> On 23 Jun 2010, at 09:40, Jay K wrote:
>>>>
>>>>>
>>>>> Is it deliberate that CHAR and Ctypes.char don't match?
>>>>> I'm building the tree with -new_adr.
>>>>> "Many" of the breaks are due to this mismatch. Not real bugs. I
>>>>> use LOOPHOLE to let it compile.
>>>>> "Many" are due to socklen_t. Real bugs on 64bit problems, at least
>>>>> in head.
>>>>> I'm not sure there are any others yet.
>>>>>
>>>>> - Jay
>>>>>
>>>>
>>> 		 	   		  

From jay.krell at cornell.edu  Thu Jun 24 11:46:27 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 24 Jun 2010 09:46:27 +0000
Subject: [M3devel] alignment in X.i3?
Message-ID: <COL101-W191F4612D5170DE1634C24E6C60@phx.gbl>


I don't suppose anyone else is seeing this?

-- building in AMD64_DARWIN ---

ignoring ../src/m3overrides

new source -> compiling XMachine.i3
new source -> compiling X.i3
"../src/Common/X.i3", line 1376: Could not find a legal alignment for the packed type.
"../src/Common/X.i3", line 1010: Could not find a legal alignment for the packed type.
2 errors encountered
new source -> compiling Xatom.i3
new source -> compiling Xmbuf.i3

I'll keep digging..
?- Jay

 		 	   		  

From jay.krell at cornell.edu  Thu Jun 24 12:01:10 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 24 Jun 2010 10:01:10 +0000
Subject: [M3devel] alignment in X.i3?
In-Reply-To: <COL101-W191F4612D5170DE1634C24E6C60@phx.gbl>
References: <COL101-W191F4612D5170DE1634C24E6C60@phx.gbl>
Message-ID: <COL101-W32744492F5C2FFF711E089E6C60@phx.gbl>


While I did this to myself by accident, there is a "real" question buried here.
I forgot I was experimenting with:

Index: 32BITS/BasicCtypes.i3
===================================================================
RCS file: /usr/cvs/cm3/m3-libs/m3core/src/C/32BITS/BasicCtypes.i3,v
retrieving revision 1.13
diff -u -r1.13 BasicCtypes.i3
--- 32BITS/BasicCtypes.i3??? 11 Feb 2010 12:24:33 -0000??? 1.13
+++ 32BITS/BasicCtypes.i3??? 24 Jun 2010 09:54:01 -0000
@@ -11,15 +11,15 @@
?
?TYPE
?? (* the four signed integer types *)
-? signed_char??????? = [-16_7f-1 .. 16_7f];
-? short_int????????? = [-16_7fff-1 .. 16_7fff];
-? int??????????????? = [-16_7fffffff-1 .. 16_7fffffff];
-? long_int?????????? = [-16_7fffffff-1 .. 16_7fffffff];
-? long_long????????? = [-16_7fffffffffffffffL-1L .. 16_7fffffffffffffffL];
+? signed_char??????? = BITS 8 FOR [-16_7f-1 .. 16_7f];
+? short_int????????? = BITS 16 FOR [-16_7fff-1 .. 16_7fff];
+? int??????????????? = BITS 32 FOR [-16_7fffffff-1 .. 16_7fffffff];
+? long_int?????????? = BITS 32 FOR [-16_7fffffff-1 .. 16_7fffffff];
+? long_long????????? = BITS 64 FOR [-16_7fffffffffffffffL-1L .. 16_7fffffffffffffffL];
?
?? (* the four unsigned integer types *)
-? unsigned_char????? = [16_0 .. 16_ff];
-? unsigned_short_int = [16_0 .. 16_ffff];
+? unsigned_char????? = BITS 8 FOR [16_0 .. 16_ff];
+? unsigned_short_int = BITS 16 FOR [16_0 .. 16_ffff];
?? unsigned_int?????? = Word.T;
?? unsigned_long_int? = Word.T;
?? unsigned_long_long = Long.T;
@@ -33,5 +33,3 @@
?? char?????????????? = signed_char;
?
?END BasicCtypes.
-
-
Index: 64BITS/BasicCtypes.i3
===================================================================
RCS file: /usr/cvs/cm3/m3-libs/m3core/src/C/64BITS/BasicCtypes.i3,v
retrieving revision 1.8
diff -u -r1.8 BasicCtypes.i3
--- 64BITS/BasicCtypes.i3??? 13 Apr 2008 19:44:02 -0000??? 1.8
+++ 64BITS/BasicCtypes.i3??? 24 Jun 2010 09:54:01 -0000
@@ -11,16 +11,16 @@
?
?TYPE
?? (* the four signed integer types *)
-? signed_char??????? = [-16_7f-1 .. 16_7f];
-? short_int????????? = [-16_7fff-1 .. 16_7fff];
-? int??????????????? = [-16_7fffffff-1 .. 16_7fffffff];
-? long_int?????????? = [-16_7fffffffffffffff -1? .. 16_7fffffffffffffff ];
-? long_long????????? = [-16_7fffffffffffffffL-1L .. 16_7fffffffffffffffL];
+? signed_char??????? = BITS 8 FOR [-16_7f-1 .. 16_7f];
+? short_int????????? = BITS 16 FOR [-16_7fff-1 .. 16_7fff];
+? int??????????????? = BITS 32 FOR [-16_7fffffff-1 .. 16_7fffffff];
+? long_int?????????? = BITS 64 FOR [-16_7fffffffffffffff -1? .. 16_7fffffffffffffff ];
+? long_long????????? = BITS 64 FOR [-16_7fffffffffffffffL-1L .. 16_7fffffffffffffffL];
?
?? (* the four unsigned integer types *)
-? unsigned_char????? = [16_0 .. 16_ff];
-? unsigned_short_int = [16_0 .. 16_ffff];
-? unsigned_int?????? = [16_0 .. 16_ffffffff];
+? unsigned_char????? = BITS 8 FOR [16_0 .. 16_ff];
+? unsigned_short_int = BITS 16 FOR [16_0 .. 16_ffff];
+? unsigned_int?????? = BITS 32 FOR [16_0 .. 16_ffffffff];
?? unsigned_long_int? = Word.T;
?? unsigned_long_long = Long.T;
?
@@ -33,5 +33,3 @@
?? char?????????????? = signed_char;
?
?END BasicCtypes.

and then I think there is a "hole" here:

? Int = int; Short = short; Long = long; Char = char;
? Bool????? = Int;

? XMotionEvent = RECORD
???? type: Int;???????????? (* of event *)

(* 32bits padding for alignment here likely *)

???? serial: unsigned_long; (* # of last request processed by server *)
???? send_event: Bool;????? (* true if this came from a SendEvent request *)

(* 32bits padding for alignment here likely also *)


???? display: DisplayStar;? (* Display the event was read from *)
???? window: Window;??????? (* "event" window reported relative to *)
???? root: Window;????????? (* root window that the event occured on *)
???? subwindow: Window;???? (* child window *)
???? time: Time;??????????? (* milliseconds *)
???? x, y: Int;???????????? (* pointer x, y coordinates in event window *)
???? x_root, y_root: Int;?? (* coordinates relative to root *)
???? state: unsigned_int;?? (* key or button mask *)
???? is_hint: Char;???????? (* detail *)
???? same_screen: Bool????? (* same screen flag *)
? END;


Am I write to be concerned with this cloning of header files?
Modula-3 probably inserts the holes/padding just like the C compiler probably inserts the holes/padding,
but it an area that deserves some extra close checking?


Like by passing the size of the record to some C that compares it to the size of the C type?
Or more aggressively the size/offset of each field?


Or maybe introducing a "more portable" C layer, where the "smallest" fields is an INTEGER or a LONGINT?


Or maybe soon someone else will apply some swig-like automation here, and generate the checks?


?- Jay


----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Date: Thu, 24 Jun 2010 09:46:27 +0000
> Subject: [M3devel] alignment in X.i3?
>
>
> I don't suppose anyone else is seeing this?
>
> -- building in AMD64_DARWIN ---
>
> ignoring ../src/m3overrides
>
> new source -> compiling XMachine.i3
> new source -> compiling X.i3
> "../src/Common/X.i3", line 1376: Could not find a legal alignment for the packed type.
> "../src/Common/X.i3", line 1010: Could not find a legal alignment for the packed type.
> 2 errors encountered
> new source -> compiling Xatom.i3
> new source -> compiling Xmbuf.i3
>
> I'll keep digging..
>  - Jay
>
>
 		 	   		  

From rodney_bates at lcwb.coop  Thu Jun 24 23:44:58 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Thu, 24 Jun 2010 16:44:58 -0500
Subject: [M3devel] alignment in X.i3?
In-Reply-To: <COL101-W32744492F5C2FFF711E089E6C60@phx.gbl>
References: <COL101-W191F4612D5170DE1634C24E6C60@phx.gbl>
	<COL101-W32744492F5C2FFF711E089E6C60@phx.gbl>
Message-ID: <4C23D1DA.60407@lcwb.coop>



Jay K wrote:
> While I did this to myself by accident, there is a "real" question buried here.
> I forgot I was experimenting with:
> 
> Index: 32BITS/BasicCtypes.i3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-libs/m3core/src/C/32BITS/BasicCtypes.i3,v
> retrieving revision 1.13
> diff -u -r1.13 BasicCtypes.i3
> --- 32BITS/BasicCtypes.i3    11 Feb 2010 12:24:33 -0000    1.13
> +++ 32BITS/BasicCtypes.i3    24 Jun 2010 09:54:01 -0000
> @@ -11,15 +11,15 @@
>  
>  TYPE
>    (* the four signed integer types *)
> -  signed_char        = [-16_7f-1 .. 16_7f];
> -  short_int          = [-16_7fff-1 .. 16_7fff];
> -  int                = [-16_7fffffff-1 .. 16_7fffffff];
> -  long_int           = [-16_7fffffff-1 .. 16_7fffffff];
> -  long_long          = [-16_7fffffffffffffffL-1L .. 16_7fffffffffffffffL];
> +  signed_char        = BITS 8 FOR [-16_7f-1 .. 16_7f];
> +  short_int          = BITS 16 FOR [-16_7fff-1 .. 16_7fff];
> +  int                = BITS 32 FOR [-16_7fffffff-1 .. 16_7fffffff];
> +  long_int           = BITS 32 FOR [-16_7fffffff-1 .. 16_7fffffff];
> +  long_long          = BITS 64 FOR [-16_7fffffffffffffffL-1L .. 16_7fffffffffffffffL];

This is a block I've been around before.  Packed (BITS) types are not what many
people seem to think.

1) They don't do anything at all for whole variables, parameters, etc. (Except
    create some non-assignabilities).  They *only* apply when used as the type of
    a record field, object field, or array element.

2) When they do apply, they require the compiler not only to use exactly the given
    number of bits, but also, to *add no padding* ahead of the field/element.

If 2) conflicts with normal alignment rules, or any other discretionary rules
the compiler uses (e.g., fields/elements cannot cross native word boundaries),
it may/must refuse.  And this means what you really need will vary from one
record/array to another.  This whole system  is really intended
only for explicit control of bit layouts of records and arrays.

I have finally gotten it that I never want to use BITS in a named type that
could be used in more than one place.  Instead, I always put the BITS in as
an anonymous part of the type of the field or element.  This avoids this
problem.  E.g.:

TYPE T = ...;
...
TYPE R = RECORD
            ...
            F: BITS 8 FOR T;
            ...
          END;

I really think this kind of explicit layout control is, for the most part,
incompatible with writing portable code.  Certainly, the original language
designers seem to have thought so.

It does raise another question.  To use LOOPHOLE, you have to know that the
BITSIZE values of the two types match up.  And what those are is implementation-
dependent.  So if, e.g., BITS 16 FOR [0..16_FF] must occupy 16 bits when a
field of a record, but the compiler might likely give it only 8 when an
autonomous variable (as it does now for [0..16_FF]), what is BITSIZE of
this type?  And I don't just mean what does the current implementation
do here.  I don't believe the language specifies this.

>  
>    (* the four unsigned integer types *)
> -  unsigned_char      = [16_0 .. 16_ff];
> -  unsigned_short_int = [16_0 .. 16_ffff];
> +  unsigned_char      = BITS 8 FOR [16_0 .. 16_ff];
> +  unsigned_short_int = BITS 16 FOR [16_0 .. 16_ffff];
>    unsigned_int       = Word.T;
>    unsigned_long_int  = Word.T;
>    unsigned_long_long = Long.T;
> @@ -33,5 +33,3 @@
>    char               = signed_char;
>  
>  END BasicCtypes.
> -
> -
> Index: 64BITS/BasicCtypes.i3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-libs/m3core/src/C/64BITS/BasicCtypes.i3,v
> retrieving revision 1.8
> diff -u -r1.8 BasicCtypes.i3
> --- 64BITS/BasicCtypes.i3    13 Apr 2008 19:44:02 -0000    1.8
> +++ 64BITS/BasicCtypes.i3    24 Jun 2010 09:54:01 -0000
> @@ -11,16 +11,16 @@
>  
>  TYPE
>    (* the four signed integer types *)
> -  signed_char        = [-16_7f-1 .. 16_7f];
> -  short_int          = [-16_7fff-1 .. 16_7fff];
> -  int                = [-16_7fffffff-1 .. 16_7fffffff];
> -  long_int           = [-16_7fffffffffffffff -1  .. 16_7fffffffffffffff ];
> -  long_long          = [-16_7fffffffffffffffL-1L .. 16_7fffffffffffffffL];
> +  signed_char        = BITS 8 FOR [-16_7f-1 .. 16_7f];
> +  short_int          = BITS 16 FOR [-16_7fff-1 .. 16_7fff];
> +  int                = BITS 32 FOR [-16_7fffffff-1 .. 16_7fffffff];
> +  long_int           = BITS 64 FOR [-16_7fffffffffffffff -1  .. 16_7fffffffffffffff ];
> +  long_long          = BITS 64 FOR [-16_7fffffffffffffffL-1L .. 16_7fffffffffffffffL];
>  
>    (* the four unsigned integer types *)
> -  unsigned_char      = [16_0 .. 16_ff];
> -  unsigned_short_int = [16_0 .. 16_ffff];
> -  unsigned_int       = [16_0 .. 16_ffffffff];
> +  unsigned_char      = BITS 8 FOR [16_0 .. 16_ff];
> +  unsigned_short_int = BITS 16 FOR [16_0 .. 16_ffff];
> +  unsigned_int       = BITS 32 FOR [16_0 .. 16_ffffffff];
>    unsigned_long_int  = Word.T;
>    unsigned_long_long = Long.T;
>  
> @@ -33,5 +33,3 @@
>    char               = signed_char;
>  
>  END BasicCtypes.
> 
> and then I think there is a "hole" here:
> 
>   Int = int; Short = short; Long = long; Char = char;
>   Bool      = Int;
> 
>   XMotionEvent = RECORD
>      type: Int;             (* of event *)
> 
> (* 32bits padding for alignment here likely *)
> 
>      serial: unsigned_long; (* # of last request processed by server *)
>      send_event: Bool;      (* true if this came from a SendEvent request *)
> 
> (* 32bits padding for alignment here likely also *)
> 
> 
>      display: DisplayStar;  (* Display the event was read from *)
>      window: Window;        (* "event" window reported relative to *)
>      root: Window;          (* root window that the event occured on *)
>      subwindow: Window;     (* child window *)
>      time: Time;            (* milliseconds *)
>      x, y: Int;             (* pointer x, y coordinates in event window *)
>      x_root, y_root: Int;   (* coordinates relative to root *)
>      state: unsigned_int;   (* key or button mask *)
>      is_hint: Char;         (* detail *)
>      same_screen: Bool      (* same screen flag *)
>   END;
> 
> 
> Am I write to be concerned with this cloning of header files?
> Modula-3 probably inserts the holes/padding just like the C compiler probably inserts the holes/padding,
> but it an area that deserves some extra close checking?
> 
> 
> Like by passing the size of the record to some C that compares it to the size of the C type?
> Or more aggressively the size/offset of each field?
> 
> 
> Or maybe introducing a "more portable" C layer, where the "smallest" fields is an INTEGER or a LONGINT?
> 
> 
> Or maybe soon someone else will apply some swig-like automation here, and generate the checks?
> 
> 
>  - Jay
> 
> 
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: m3devel at elegosoft.com
>> Date: Thu, 24 Jun 2010 09:46:27 +0000
>> Subject: [M3devel] alignment in X.i3?
>>
>>
>> I don't suppose anyone else is seeing this?
>>
>> -- building in AMD64_DARWIN ---
>>
>> ignoring ../src/m3overrides
>>
>> new source -> compiling XMachine.i3
>> new source -> compiling X.i3
>> "../src/Common/X.i3", line 1376: Could not find a legal alignment for the packed type.
>> "../src/Common/X.i3", line 1010: Could not find a legal alignment for the packed type.
>> 2 errors encountered
>> new source -> compiling Xatom.i3
>> new source -> compiling Xmbuf.i3
>>
>> I'll keep digging..
>>  - Jay
>>
>>
>  		 	   		  


From rodney_bates at lcwb.coop  Fri Jun 25 00:03:55 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Thu, 24 Jun 2010 17:03:55 -0500
Subject: [M3devel] LOOPHOLE and open array types
Message-ID: <4C23D64B.6050600@lcwb.coop>

The language definition says:
-------------------------------------------------------------------
An unchecked type transfer operation has the form:

     LOOPHOLE(e, T)

where e is an expression whose type is not an open array type and
T is a type.  It denotes e's bit pattern interpreted as a
variable or value of type T.  It is a designator if e is, and is
writable if e is.  An unchecked runtime error can occur if e's
bit pattern is not a legal T, or if e is a designator and some
legal bit pattern for T is not legal for e.

If T is not an open array type, BITSIZE(e) must equal
BITSIZE(T).  If T is an open array type, its element type must
not be an open array type, and e's bit pattern is interpreted as an
array whose length is BITSIZE(e) divided by BITSIZE(the element
type of T).  The division must come out even.
-------------------------------------------------------------------

Is there any reason not to allow e to have an open array type
*if* T is an open array type?  Element size of T would have to
evenly divide element size of e, to avoid runtime checks.

Other rules being the same, this would allow, e.g.:

PROCEDURE FromCtypes_chars (F: ARRAY OF Ctypes.char): TEXT

= BEGIN
     RETURN Text.FromChars(LOOPHOLE(F, ARRAY OF CHAR))
   END FromCtypes_chars

It would take a bit more implementation to handle the RT size of
e, but there is already the capability to produce a result value
of open array type.  The only difference would be the element
count would be element count of e times a constant instead of
just a constant.


From rodney_bates at lcwb.coop  Fri Jun 25 00:25:02 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Thu, 24 Jun 2010 17:25:02 -0500
Subject: [M3devel] -new_adr the default?
In-Reply-To: <COL101-W54C167232C5F9B2A6C4963E6C50@phx.gbl>
References: <COL101-W54C167232C5F9B2A6C4963E6C50@phx.gbl>
Message-ID: <4C23DB3E.7010603@lcwb.coop>



Jay K wrote:
> I'd like to make -new_adr the default.
> It is more typesafe than the current way and finds bugs.
>   Granted, so far I think only bugs that I introduced.
> 
> 
> First I will make the tree compile either way.
>  Such as by fixing the bugs and resolving somehow the char vs. CHAR breaks.
> 
> 
> Changing this does break code, albeit only unsafe code.
>   There isn't much of that? Right? :)
> Sometimes that code had bugs, sometimes not.
> 
> 
> I believe type safety and static checking (and sometimes runtime checking) do have a place in unsafe code.
>  Maybe not as much as in safe code, but definitely still something.
> 
> 
> The old way is that ADR return ADDRESS, similar to void*, and it is silently convertable to any pointer type. I think.
                                                                 ^
Yes, but only in UNSAFE code.  OtherPointerType <: ADDRESS.
> 
> 
> The new way is that ADR(T) returns UNTRACED REF T is is only silently convertable to ADDRESS? 
                                                        ^
Yes, even in safe code, because of the same subtype relation.

Or nothing at all?
>  Esp. not silently convertable to UNTRACED REF U.
Yes, this would require an explicit LOOPHOLE.  Or, you could convert in two steps,
to a variable of ADDRESS first, then to UNTRACED REF U.  Both require UNSAFE.

> 
> 
> So there are buggy places that do:
> PROCEDURE Foo(UNTRACED REF T);
> 
> PROCEDURE Bar()
> VAR u: U;

Not sure what this is doing, but it seems like just changing to VAR u: T; ought
to work too.  It would compile with either semantics of ADR.

> BEGIN
>  Foo(ADR(u));
> END Bar;
> 
> 
> That compile with old ADR but not with new ADR.
> As I changed socklent_t between int and INTEGER, such code silently kept compiling.
>   But possibly silently corrupting the stack or producing the wrong data.
> 
> 
> This -new_adr feature was already implemented in the compiler unknown long ago.
>   I didn't know but Tony pointed it out.
> We should probably look at its impementation make sure we aren't switching on some buggy unused code.
> So far switching it on I've only seen correct new errors.
> 
> 
>  - Jay
>  		 	   		  


From jay.krell at cornell.edu  Fri Jun 25 11:48:48 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 25 Jun 2010 09:48:48 +0000
Subject: [M3devel] gcc 4.5 static chain
Message-ID: <COL101-W4975CA91E3B1ED2707FA48E6C70@phx.gbl>


Here's some background as to why it is taking me so long to
get gcc 4.5 working.


Two of gcc's internal data structures are "tree" and "gimple".


"tree" is a somewhat intuitive structure that roughly
corresponds to a C AST ("abstract syntax tree").
It has stuff like plus, and call.
I believe it is meant to support any gcc frontend: Ada, Java, etc.


"tree" is produced by the C frontend and our "parse.c"
?(The Modula-3 gcc backend is structured as a gcc frontend,
?producing similar in-memory data as the C frontend. "backend"
?and "frontend" get confused.)


I believe "tree" has been there "forever", for as long
as DEC SRC Modula-3 has had a gcc backend.
(2.x presumably)


"gimple" is very much like tree, but it is less general.
it is more amenable to optimization.
Things like loops are deconstructed into goto.
I think.


"gimple" is newer, like dating to gcc 4.x.
Previously optimization operated on tree and/or rtx and neither was great.
rtx is too low level. tree is too high level.


Gimple I think was originally just exactly tree but with
some of the node types not used. Confusing. Faster to write it,
reused the tree code, but confusing. Gives "tree" multiple meanings.
In 4.4 or 4.5 they made it its own type.
I think, for one thing, it now is made up of nodes with small arrays
instead of nodes with node pointers.



Or something like this.
I'm mostly just repeating what you can read online elsewhere from
?more authoritative and clearer sources.
?

So, at some point, "tree" is converted to "gimple".
? Though, this is a very confusing point to me.
? It appears that really the compiler deals with a significant
? mix of "tree" and "gimple". Perhaps that is inevitable. Perhaps
? tree can only be gradually converted to gimple.
? 

Anyway, among the "tree codes" such as plus, call, etc., we add one.
We add to load a static link.
For the current function?
For a specific function to be called?
I find this point not obvious.


So then, given that we have introduced a tree code, we must teach
other parts of gcc about it.


Tangent.


tree-nested.c converts nested functions into non-nested functions.
As needed, it moves locals into structs, adds "display" parameters
to nested functions, changes references to outer locals into
accesses through the "display", etc.


Again, this is a transformation we probably could/should make ourselves in m3front.


Only the locals that are actually accessed are moved into a local struct.
Presumably only nested functions that reference outer locals get the extra parameter.
And so on.


In gcc-4.3/tree-nested.c we deal with our tree code.
We appear to do two things:
?
?- we ensure that the function we are getting a static link for has one
??? I don't understand that actually. gcc is already doing similar.
??? Why do we need to do more? 
? 
? - it replaces the load of the static link with, uh, the load of the
??? static link -- it replaces the tree node with our custom tree code
??? with the tree node representing actually computing/getting the value we want
??? It is a little fishy to me btw how this is done.
??? Is overwriting *tp really the way?
??? In 4.5 there are functions to insert/after/replace within the gimple
??? iterator. I wonder if there is similar in 4.3.


Now, the difference in 4.5 is that "gimplification" happens earlier.
The code in 4.3 that we change to deal with tree and our custom tree code,
is now dealing with gimple instead.


Therefore, I believe part of the 4.5 change is a simple translation
of the tree code to a new gimple code.


And then some corresponding change in 4.5.


Btw, it appears gimplify_expr is also a "lang hook", which means
more of our code can move out of line to parse.c.


I haven't figured it all out yet.


I should further note that gcc's notion of a nested function is almost
identical to Modula-3's.


You know, this movement of locals into a local struct, the accepting
an extra parameter pointing to that struct in nested functions, gcc
and Modula-3 are the same.


Therefore tree-nested.c does a lot of work and it is almost all useful/relevant
to us.


The difference is only what happens when you take the address of a nested function.
Or perhaps when you call them.


gcc generates a little bit of code at runtime to add the static link parameter
?(e.g. on x86/AMD64 to load into a designated register: r10 for AMD64, ecx for x86,
?see the function ix86_static_chain).
Modula-3 generates a little bit of data: marker, function pointer, static chain,
and the caller does extra work.


There are significant tradeoffs either way and there is, I'm convinced,
absolutely no good way to do this.
gcc generates code at runtime, generally on the stack.
? These days the stack is not by default executable, in order to
? protect against viruses etc. overflowing buffers on the stack
? and writing code to the stack.
Modula-3 has to check function pointers before calling them.


As I said, neither is good, there's no good solution.
? Better perhaps to do the transform yourself. Then you have
? the option of putting the context on the stack or heap as well.
? Better perhaps to expose programmer to the cost. Perhaps.


Perhaps the C ABIs could have reserved a register for this, but I'm not sure
that makes sense. Would you load it up and it remains preserved until changed?


But I digressed.


?- Jay 		 	   		  

From ttmrichter at gmail.com  Fri Jun 25 17:07:21 2010
From: ttmrichter at gmail.com (Michael Richter)
Date: Fri, 25 Jun 2010 23:07:21 +0800
Subject: [M3devel] gcc vs. clang as back-end
Message-ID: <AANLkTik63tUQqujL3yUi5MH8rOApxcqj8hMl5LuXTpqu@mail.gmail.com>

I've just read Jay K's long message about problems integrating with gcc 4.5.
 The LLVM project has clang out now which is ready for prime time as a C or
Objective-C compiler (not yet there for C++, but that's out of scope for CM3
I'd guess).  Since clang was specifically designed, as one of its goals, to
be easy to use as a form of library, would it not perhaps be better to start
using clang as a back-end instead of any version of gcc (which is
notoriously difficult to write front-ends, back-ends or tools for)?

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

From hosking at cs.purdue.edu  Fri Jun 25 17:46:39 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 25 Jun 2010 11:46:39 -0400
Subject: [M3devel] gcc vs. clang as back-end
In-Reply-To: <AANLkTik63tUQqujL3yUi5MH8rOApxcqj8hMl5LuXTpqu@mail.gmail.com>
References: <AANLkTik63tUQqujL3yUi5MH8rOApxcqj8hMl5LuXTpqu@mail.gmail.com>
Message-ID: <FDE20D78-F7CA-40B3-B2D4-66A0AA8CF274@cs.purdue.edu>

Hi Michael,

CM3 has a front-end compiler written in Modula-3 that targets an M3-specific IR.  Currently, that M3 IR is parsed and compiled by a simple front-end to gcc to generate assembler.  It's not clear that Clang itself is the way to go.  Rather, I think it would be better to build a translator from M3 IR to LLVM IR.

It would be much more effort to build a whole new M3 front-end around Clang.  Or do I misunderstand your suggestion?

-- Tony

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 25 Jun 2010, at 11:07, Michael Richter wrote:

> I've just read Jay K's long message about problems integrating with gcc 4.5.  The LLVM project has clang out now which is ready for prime time as a C or Objective-C compiler (not yet there for C++, but that's out of scope for CM3 I'd guess).  Since clang was specifically designed, as one of its goals, to be easy to use as a form of library, would it not perhaps be better to start using clang as a back-end instead of any version of gcc (which is notoriously difficult to write front-ends, back-ends or tools for)?
> 
> -- 
> "Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot."
> --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra.

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

From jay.krell at cornell.edu  Sat Jun 26 03:53:45 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 26 Jun 2010 01:53:45 +0000
Subject: [M3devel] gcc vs. clang as back-end
In-Reply-To: <FDE20D78-F7CA-40B3-B2D4-66A0AA8CF274@cs.purdue.edu>
References: <AANLkTik63tUQqujL3yUi5MH8rOApxcqj8hMl5LuXTpqu@mail.gmail.com>,
	<FDE20D78-F7CA-40B3-B2D4-66A0AA8CF274@cs.purdue.edu>
Message-ID: <COL101-W22F8C5289770196CD70115E6C80@phx.gbl>


gcc probably isn't as bad as people say.
?Most people are talking about C or C++ compilation, which is architecturally very problematic due the lack of a well designed module system. The same content gets parsed countless times.

? Any speed up you can make, apparently clang has made a few, will be multiplied by a very large amount.


clang doesn't make sense, for a Modula-3 backend.
LLVM does.
Anyone, yes, please feel free to contribute an LLVM backend.


I'll keep poking at the static chain stuff for now.


Thanks,
?- Jay

________________________________
> From: hosking at cs.purdue.edu
> Date: Fri, 25 Jun 2010 11:46:39 -0400
> To: ttmrichter at gmail.com
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] gcc vs. clang as back-end
>
>
>
> Hi Michael,
>
> CM3 has a front-end compiler written in Modula-3 that targets an M3-specific IR. Currently, that M3 IR is parsed and compiled by a simple front-end to gcc to generate assembler. It's not clear that Clang itself is the way to go. Rather, I think it would be better to build a translator from M3 IR to LLVM IR.
>
> It would be much more effort to build a whole new M3 front-end around Clang. Or do I misunderstand your suggestion?
>
> -- Tony
>
>
>
> 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 25 Jun 2010, at 11:07, Michael Richter wrote:
>
> I've just read Jay K's long message about problems integrating with gcc 4.5. The LLVM project has clang out now which is ready for prime time as a C or Objective-C compiler (not yet there for C++, but that's out of scope for CM3 I'd guess). Since clang was specifically designed, as one of its goals, to be easy to use as a form of library, would it not perhaps be better to start using clang as a back-end instead of any version of gcc (which is notoriously difficult to write front-ends, back-ends or tools for)?
>
>
> --
> "Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot."
>
>
> --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra.
>
>
 		 	   		  

From jay.krell at cornell.edu  Sat Jun 26 14:51:47 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 26 Jun 2010 12:51:47 +0000
Subject: [M3devel] gcc 4.5 and how to pass the static link
Message-ID: <COL101-W17562D51BBB958218397FFE6C80@phx.gbl>


ok, I got "man vs. boy" to work.


Now I'm going back and revisiting some diffs I have, try to reduce them.
There isn't much.


I'm going to commit something that will seem odd,
and isn't easy to explain, and that I might not fully understand.


Here is what I suspect though.


In gcc 4.3, how to pass a static chain is always the same for each architecture.
?I think.
?
?
In 4.5, it depends on the function being called. At least for some architectures.
See the function ix86_static_chain.
x86 functions can have varying calling conventions, so how to pass
the static chain can vary from function to function.


This doesn't make complete sense for Modula-3 though.
We pass the static chain for function pointers as well.
?And gcc never does, because function pointers are "flattened" via "trampolines".
?That is, the caller of a function pointer doesn't have to pass a static link.
?A trampoline is built to pass it.
?Err. It does make partial sense. Function pointers still have calling conventions.


calls.c:prepare_call_address:
? if (static_chain_value != 0)
??? {
????? rtx chain;

????? gcc_assert (fndecl);
????? chain = targetm.calls.static_chain (fndecl, false);
????? static_chain_value = convert_memory_address (Pmode, static_chain_value);

????? emit_move_insn (chain, static_chain_value);
????? if (REG_P (chain))
??? use_reg (call_fusage, chain);
??? }


the assertion fails here:

m3-sys/m3link:

PROCEDURE ForEachUnit (VAR s: State;? p: UnitProc) =
? VAR x: MxMap.Contents;? u: Mx.Unit;
? BEGIN
??? x := MxMap.GetData (s.base.interfaces);
??? FOR i := 0 TO LAST (x^) DO
????? u := x[i].value;
????? IF (u # NIL) THEN p (s, u) END;??? *** here ***
??? END;
??? x := MxMap.GetData (s.base.modules);
??? FOR i := 0 TO LAST (x^) DO
????? u := x[i].value;
????? IF (u # NIL) THEN p (s, u) END;
??? END;
??? x := MxMap.GetData (s.base.virtuals);
??? FOR i := 0 TO LAST (x^) DO
????? u := x[i].value;
????? IF (u # NIL) THEN p (s, u) END;
??? END;
? END ForEachUnit;
? 
? 
So I'm going to quite alter that code to allow null and in such case
use the register 4.3 would have (ECX).


Arguably even for non-null we should do that.
We only support __cdecl and __stdcall, and ECX is correct for either.
gcc supports __fastcall and it appears possibly custom calling conventions.


?- Jay
 		 	   		  

From rcolebur at SCIRES.COM  Sat Jun 26 18:00:57 2010
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Sat, 26 Jun 2010 12:00:57 -0400
Subject: [M3devel] syntax errs in hand.c
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E605DBF557@ATLEX02-SRV.SCIRES.LOCAL>

Jay:

I'm getting compile errors in hand.c on Windows from the HEAD branch.

Regards,
Randy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100626/e067ca9f/attachment.html>

From jay.krell at cornell.edu  Sun Jun 27 03:05:37 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 27 Jun 2010 01:05:37 +0000
Subject: [M3devel] syntax errs in hand.c
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E605DBF557@ATLEX02-SRV.SCIRES.LOCAL>
References: <D67F02DDC62F7545A6B84C285F88F3E605DBF557@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <COL101-W368E851606052D84250E89E6C90@phx.gbl>


Randy, can you please fix them?

Thanks,
?- Jay

________________________________
> From: rcolebur at SCIRES.COM
> To: m3devel at elegosoft.com
> Date: Sat, 26 Jun 2010 12:00:57 -0400
> Subject: [M3devel] syntax errs in hand.c
>
> Jay:
>
> I?m getting compile errors in hand.c on Windows from
> the HEAD branch.
>
> Regards,
>> Randy
 		 	   		  

From jay.krell at cornell.edu  Sun Jun 27 10:12:54 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 27 Jun 2010 08:12:54 +0000
Subject: [M3devel] m3cg 4.5 problem
Message-ID: <COL101-W728051433DA06972261F1E6C90@phx.gbl>


This tiny bit of code, which is cut down from m3front, causes an assertion failure in a 4.5 m3cg:
MODULE TypeCaseStmt;
IMPORT M3ID, CG, Expr, Stmt, StmtRep, Type, Variable, Scope;
PROCEDURE GetOutcomex (): Stmt.Outcomes =  VAR oc := Stmt.Outcomes {};  line 6  BEGIN    RETURN oc;  END GetOutcomex;
BEGINEND TypeCaseStmt.
../src/stmts/TypeCaseStmt.m3:6:0: internal compiler error: in gimplify_expr, at gimplify.c:7315Please submit a full bug report,

(1) begin_unit(2) set_source_file(3) set_source_line  source line    1(4) comment  comment: `module global constants'(5) declare_segment  segment L_1 typeid 0xffffffff(6) comment  comment: `module global data'(7) declare_segment  segment MM_TypeCaseStmt typeid 0xffffffff(8) set_source_line  source line   11(9) declare_procedure  type:addr  procedure:TypeCaseStmt_M3 nparams:0x1 rettype:addr lev:0 exported:1(10) declare_param  type:int64  param M3_AcxOUs_mode type:int64 typeid:0x195c2a74 bytesize:0x40 alignment:0x40 in_memory:0x0 up_level:0x0  mode 0x11 (DImode)(11) import_procedure  type:addr  procedure:TypeCaseStmt_I3 nparams:0x0 rettype:addr(12) export_unit(13) import_procedure  type:addr  procedure:Scope_I3 nparams:0x0 rettype:addr(14) import_unit(15) import_procedure  type:addr  procedure:Variable_I3 nparams:0x0 rettype:addr(16) import_unit(17) import_procedure  type:addr  procedure:Type_I3 nparams:0x0 rettype:addr(18) import_unit(19) import_procedure  type:addr  procedure:StmtRep_I3 nparams:0x0 rettype:addr(20) import_unit(21) import_procedure  type:addr  procedure:Stmt_I3 nparams:0x0 rettype:addr(22) import_unit(23) import_procedure  type:addr  procedure:Expr_I3 nparams:0x0 rettype:addr(24) import_unit(25) import_procedure  type:addr  procedure:CG_I3 nparams:0x0 rettype:addr(26) import_unit(27) import_procedure  type:addr  procedure:M3ID_I3 nparams:0x0 rettype:addr(28) import_unit(29) import_procedure  type:addr  procedure:RTHooks_I3 nparams:0x0 rettype:addr(30) import_unit(31) declare_procedure  type:word64  procedure:TypeCaseStmt__GetOutcomex nparams:0x0 rettype:word64 lev:0 exported:0(32) declare_local  type:word64  local var M3_EXQtd6_oc type:word64 size:0x40 alignment:0x40(33) declare_local  type:word64  local var M3_EXQtd6__result type:word64 size:0x40 alignment:0x40(34) comment  comment: `GetOutcomex'(35) set_source_line  source line    5(36) begin_procedure  procedure TypeCaseStmt__GetOutcomex TypeCaseStmt__GetOutcomex(37) set_source_line  source line    6(38) load_integer  type:int64  integer:0x0(39) store  type:int64  type:int64  store (M3_EXQtd6_oc) offset:0x0 src_t:int64 dst_t:int64(40) set_source_line  source line    8(41) load  type:word64  type:int64  m3cg_load (M3_EXQtd6_oc): offset 0x0, convert word64 -> int64(42) exit_proc  type:word64(43) end_procedure  procedure TypeCaseStmt__GetOutcomex

Breakpoint 1, fancy_abort (file=0x1009f0c6f "../../gcc-4.5/gcc/gimplify.c", line=7315, function=0x1009f1242 "gimplify_expr") at ../../gcc-4.5/gcc/diagnostic.c:763763	  internal_error ("in %s, at %s:%d", function, trim_filename (file), line);(gdb) bt#0  fancy_abort (file=0x1009f0c6f "../../gcc-4.5/gcc/gimplify.c", line=7315, function=0x1009f1242 "gimplify_expr") at ../../gcc-4.5/gcc/diagnostic.c:763#1  0x00000001004cc4d6 in gimplify_expr (expr_p=0x1410e2060, pre_p=0x7fff5fbff420, post_p=0x7fff5fbfeff8, gimple_test_f=0x1004aac7f <is_gimple_lvalue>, fallback=2) at ../../gcc-4.5/gcc/gimplify.c:7315#2  0x00000001004c5ad3 in gimplify_modify_expr (expr_p=0x1416a5f28, pre_p=0x7fff5fbff420, post_p=0x7fff5fbfeff8, want_value=0 '\0') at ../../gcc-4.5/gcc/gimplify.c:4444#3  0x00000001004caafc in gimplify_expr (expr_p=0x1416a5f28, pre_p=0x7fff5fbff420, post_p=0x7fff5fbfeff8, gimple_test_f=0x1004ab1a6 <is_gimple_stmt>, fallback=0) at ../../gcc-4.5/gcc/gimplify.c:6619#4  0x00000001004c7800 in gimplify_stmt (stmt_p=0x1416a5f28, seq_p=0x7fff5fbff420) at ../../gcc-4.5/gcc/gimplify.c:5264#5  0x00000001004be376 in gimplify_statement_list (expr_p=0x1416c4030, pre_p=0x7fff5fbff420) at ../../gcc-4.5/gcc/gimplify.c:1382#6  0x00000001004cb6f5 in gimplify_expr (expr_p=0x1416c4030, pre_p=0x7fff5fbff420, post_p=0x7fff5fbff2e8, gimple_test_f=0x1004ab1a6 <is_gimple_stmt>, fallback=0) at ../../gcc-4.5/gcc/gimplify.c:6935#7  0x00000001004c7800 in gimplify_stmt (stmt_p=0x1416c4030, seq_p=0x7fff5fbff420) at ../../gcc-4.5/gcc/gimplify.c:5264#8  0x00000001004bdb6c in gimplify_bind_expr (expr_p=0x1416c2298, pre_p=0x7fff5fbff778) at ../../gcc-4.5/gcc/gimplify.c:1127#9  0x00000001004cae2b in gimplify_expr (expr_p=0x1416c2298, pre_p=0x7fff5fbff778, post_p=0x7fff5fbff618, gimple_test_f=0x1004ab1a6 <is_gimple_stmt>, fallback=0) at ../../gcc-4.5/gcc/gimplify.c:6719#10 0x00000001004c7800 in gimplify_stmt (stmt_p=0x1416c2298, seq_p=0x7fff5fbff778) at ../../gcc-4.5/gcc/gimplify.c:5264#11 0x00000001004ccbe6 in gimplify_body (body_p=0x1416c2298, fndecl=0x1416c2200, do_parms=1 '\001') at ../../gcc-4.5/gcc/gimplify.c:7528#12 0x00000001004cceae in gimplify_function_tree (fndecl=0x1416c2200) at ../../gcc-4.5/gcc/gimplify.c:7624#13 0x00000001000069c7 in m3_gimplify_function (fndecl=0x1416c2200) at ../../gcc-4.5/gcc/m3cg/parse.c:2370#14 0x0000000100009cb4 in m3cg_end_procedure () at ../../gcc-4.5/gcc/m3cg/parse.c:3642#15 0x000000010000feb5 in m3_parse_file (xx=0) at ../../gcc-4.5/gcc/m3cg/parse.c:5550#16 0x00000001006be6a2 in compile_file () at ../../gcc-4.5/gcc/toplev.c:1053#17 0x00000001006c0e19 in do_compile () at ../../gcc-4.5/gcc/toplev.c:2415#18 0x00000001006c0ee0 in toplev_main (argc=3, argv=0x7fff5fbff930) at ../../gcc-4.5/gcc/toplev.c:2457#19 0x000000010001743b in main (argc=3, argv=0x7fff5fbff930) at ../../gcc-4.5/gcc/main.c:35(

Wierd, huh?
The only thing I can think of an int/word mismatch.I did change one instance of Integer to Word, after finding this.Stmt.Outcomes is an enumeration.So presumably Stmt.Outcomes { } is 0.Enumerations should work equally well as Integer or Word, right?Clearly above there is still a mix. I can try changing them all to Word.

I'll keep digging.

Maybe dump the entire function generic tree for this and similar C.

 - Jay 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100627/1814fee7/attachment.html>

From jay.krell at cornell.edu  Sun Jun 27 11:23:13 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 27 Jun 2010 09:23:13 +0000
Subject: [M3devel] m3cg 4.5 problem
In-Reply-To: <COL101-W728051433DA06972261F1E6C90@phx.gbl>
References: <COL101-W728051433DA06972261F1E6C90@phx.gbl>
Message-ID: <COL101-W2519C65D63208BF55620CE6C90@phx.gbl>


I was a bit off. It is actually set of enum. Like this:
MODULE TypeCaseStmt;
TYPE T1 = {A,B};TYPE T2 = SET OF T1; PROCEDURE GetOutcomex (): T2 =  VAR oc := T2 {};  BEGIN    RETURN oc;  END GetOutcomex;
BEGINEND TypeCaseStmt.
 - Jay
From: jay.krell at cornell.edu
To: m3devel at elegosoft.com; hosking at cs.purdue.edu
Date: Sun, 27 Jun 2010 08:12:54 +0000
Subject: [M3devel] m3cg 4.5 problem








This tiny bit of code, which is cut down from m3front, causes an assertion failure in a 4.5 m3cg:
MODULE TypeCaseStmt;
IMPORT M3ID, CG, Expr, Stmt, StmtRep, Type, Variable, Scope;
PROCEDURE GetOutcomex (): Stmt.Outcomes =  VAR oc := Stmt.Outcomes {};  line 6  BEGIN    RETURN oc;  END GetOutcomex;
BEGINEND TypeCaseStmt.
../src/stmts/TypeCaseStmt.m3:6:0: internal compiler error: in gimplify_expr, at gimplify.c:7315Please submit a full bug report,

(1) begin_unit(2) set_source_file(3) set_source_line  source line    1(4) comment  comment: `module global constants'(5) declare_segment  segment L_1 typeid 0xffffffff(6) comment  comment: `module global data'(7) declare_segment  segment MM_TypeCaseStmt typeid 0xffffffff(8) set_source_line  source line   11(9) declare_procedure  type:addr  procedure:TypeCaseStmt_M3 nparams:0x1 rettype:addr lev:0 exported:1(10) declare_param  type:int64  param M3_AcxOUs_mode type:int64 typeid:0x195c2a74 bytesize:0x40 alignment:0x40 in_memory:0x0 up_level:0x0  mode 0x11 (DImode)(11) import_procedure  type:addr  procedure:TypeCaseStmt_I3 nparams:0x0 rettype:addr(12) export_unit(13) import_procedure  type:addr  procedure:Scope_I3 nparams:0x0 rettype:addr(14) import_unit(15) import_procedure  type:addr  procedure:Variable_I3 nparams:0x0 rettype:addr(16) import_unit(17) import_procedure  type:addr  procedure:Type_I3 nparams:0x0 rettype:addr(18) import_unit(19) import_procedure  type:addr  procedure:StmtRep_I3 nparams:0x0 rettype:addr(20) import_unit(21) import_procedure  type:addr  procedure:Stmt_I3 nparams:0x0 rettype:addr(22) import_unit(23) import_procedure  type:addr  procedure:Expr_I3 nparams:0x0 rettype:addr(24) import_unit(25) import_procedure  type:addr  procedure:CG_I3 nparams:0x0 rettype:addr(26) import_unit(27) import_procedure  type:addr  procedure:M3ID_I3 nparams:0x0 rettype:addr(28) import_unit(29) import_procedure  type:addr  procedure:RTHooks_I3 nparams:0x0 rettype:addr(30) import_unit(31) declare_procedure  type:word64  procedure:TypeCaseStmt__GetOutcomex nparams:0x0 rettype:word64 lev:0 exported:0(32) declare_local  type:word64  local var M3_EXQtd6_oc type:word64 size:0x40 alignment:0x40(33) declare_local  type:word64  local var M3_EXQtd6__result type:word64 size:0x40 alignment:0x40(34) comment  comment: `GetOutcomex'(35) set_source_line  source line    5(36) begin_procedure  procedure TypeCaseStmt__GetOutcomex TypeCaseStmt__GetOutcomex(37) set_source_line  source line    6(38) load_integer  type:int64  integer:0x0(39) store  type:int64  type:int64  store (M3_EXQtd6_oc) offset:0x0 src_t:int64 dst_t:int64(40) set_source_line  source line    8(41) load  type:word64  type:int64  m3cg_load (M3_EXQtd6_oc): offset 0x0, convert word64 -> int64(42) exit_proc  type:word64(43) end_procedure  procedure TypeCaseStmt__GetOutcomex

Breakpoint 1, fancy_abort (file=0x1009f0c6f "../../gcc-4.5/gcc/gimplify.c", line=7315, function=0x1009f1242 "gimplify_expr") at ../../gcc-4.5/gcc/diagnostic.c:763763	  internal_error ("in %s, at %s:%d", function, trim_filename (file), line);(gdb) bt#0  fancy_abort (file=0x1009f0c6f "../../gcc-4.5/gcc/gimplify.c", line=7315, function=0x1009f1242 "gimplify_expr") at ../../gcc-4.5/gcc/diagnostic.c:763#1  0x00000001004cc4d6 in gimplify_expr (expr_p=0x1410e2060, pre_p=0x7fff5fbff420, post_p=0x7fff5fbfeff8, gimple_test_f=0x1004aac7f <is_gimple_lvalue>, fallback=2) at ../../gcc-4.5/gcc/gimplify.c:7315#2  0x00000001004c5ad3 in gimplify_modify_expr (expr_p=0x1416a5f28, pre_p=0x7fff5fbff420, post_p=0x7fff5fbfeff8, want_value=0 '\0') at ../../gcc-4.5/gcc/gimplify.c:4444#3  0x00000001004caafc in gimplify_expr (expr_p=0x1416a5f28, pre_p=0x7fff5fbff420, post_p=0x7fff5fbfeff8, gimple_test_f=0x1004ab1a6 <is_gimple_stmt>, fallback=0) at ../../gcc-4.5/gcc/gimplify.c:6619#4  0x00000001004c7800 in gimplify_stmt (stmt_p=0x1416a5f28, seq_p=0x7fff5fbff420) at ../../gcc-4.5/gcc/gimplify.c:5264#5  0x00000001004be376 in gimplify_statement_list (expr_p=0x1416c4030, pre_p=0x7fff5fbff420) at ../../gcc-4.5/gcc/gimplify.c:1382#6  0x00000001004cb6f5 in gimplify_expr (expr_p=0x1416c4030, pre_p=0x7fff5fbff420, post_p=0x7fff5fbff2e8, gimple_test_f=0x1004ab1a6 <is_gimple_stmt>, fallback=0) at ../../gcc-4.5/gcc/gimplify.c:6935#7  0x00000001004c7800 in gimplify_stmt (stmt_p=0x1416c4030, seq_p=0x7fff5fbff420) at ../../gcc-4.5/gcc/gimplify.c:5264#8  0x00000001004bdb6c in gimplify_bind_expr (expr_p=0x1416c2298, pre_p=0x7fff5fbff778) at ../../gcc-4.5/gcc/gimplify.c:1127#9  0x00000001004cae2b in gimplify_expr (expr_p=0x1416c2298, pre_p=0x7fff5fbff778, post_p=0x7fff5fbff618, gimple_test_f=0x1004ab1a6 <is_gimple_stmt>, fallback=0) at ../../gcc-4.5/gcc/gimplify.c:6719#10 0x00000001004c7800 in gimplify_stmt (stmt_p=0x1416c2298, seq_p=0x7fff5fbff778) at ../../gcc-4.5/gcc/gimplify.c:5264#11 0x00000001004ccbe6 in gimplify_body (body_p=0x1416c2298, fndecl=0x1416c2200, do_parms=1 '\001') at ../../gcc-4.5/gcc/gimplify.c:7528#12 0x00000001004cceae in gimplify_function_tree (fndecl=0x1416c2200) at ../../gcc-4.5/gcc/gimplify.c:7624#13 0x00000001000069c7 in m3_gimplify_function (fndecl=0x1416c2200) at ../../gcc-4.5/gcc/m3cg/parse.c:2370#14 0x0000000100009cb4 in m3cg_end_procedure () at ../../gcc-4.5/gcc/m3cg/parse.c:3642#15 0x000000010000feb5 in m3_parse_file (xx=0) at ../../gcc-4.5/gcc/m3cg/parse.c:5550#16 0x00000001006be6a2 in compile_file () at ../../gcc-4.5/gcc/toplev.c:1053#17 0x00000001006c0e19 in do_compile () at ../../gcc-4.5/gcc/toplev.c:2415#18 0x00000001006c0ee0 in toplev_main (argc=3, argv=0x7fff5fbff930) at ../../gcc-4.5/gcc/toplev.c:2457#19 0x000000010001743b in main (argc=3, argv=0x7fff5fbff930) at ../../gcc-4.5/gcc/main.c:35(

Wierd, huh?
The only thing I can think of an int/word mismatch.I did change one instance of Integer to Word, after finding this.Stmt.Outcomes is an enumeration.So presumably Stmt.Outcomes { } is 0.Enumerations should work equally well as Integer or Word, right?Clearly above there is still a mix. I can try changing them all to Word.

I'll keep digging.

Maybe dump the entire function generic tree for this and similar C.

 - Jay 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100627/2ee35f81/attachment.html>

From ttmrichter at gmail.com  Sun Jun 27 12:54:30 2010
From: ttmrichter at gmail.com (Michael Richter)
Date: Sun, 27 Jun 2010 18:54:30 +0800
Subject: [M3devel] cm3ide and Chrome
Message-ID: <AANLkTim77ivruVuNT21PtStijrhMlRD-bNc9VOIH669d@mail.gmail.com>

Is there a trick to making cm3ide work with Google Chrome?  The problem
seems to be that Google Chrome returns *immediately* upon invocation where
the default, Firefox, does not.  Cm3ide waits for the browser to exit to
decide that it's time to end, so what winds up happening for me when
specifying Chrome as the browser is that cm3ide starts, Chrome starts,
cm3ide starts serving up some content, Chrome's launcher returns
immediately, cm3ide dies.  The result is a partial opening page and nothing
else.

Also, when specifying the browser (any browser), it doesn't like me giving
options to the browser command line: it rejects "/usr/bin/google-chrome
--new-window" as an option when asking for the browser if I delete the
configuration file.  I have to go /usr/bin/google-chrome and then manually
edit the configuration file to include any command line switches I want to
use.

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

From jay.krell at cornell.edu  Sun Jun 27 13:07:06 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 27 Jun 2010 11:07:06 +0000
Subject: [M3devel] extra temporaries?
Message-ID: <COL101-W63DC70E1561934607F902CE6C90@phx.gbl>


Why all these extra temporaries?

static voidm3cg_max (void){  MTYPE (t);
  tree t1 = declare_temp (t);  tree t2 = declare_temp (t);
  add_stmt (m3_build2 (MODIFY_EXPR, t, t1, EXPR_REF (-1)));  add_stmt (m3_build2 (MODIFY_EXPR, t, t2, EXPR_REF (-2)));
  EXPR_REF (-2) = m3_build3 (COND_EXPR, t,                             m3_build2 (LE_EXPR, boolean_type_node, t2, t1),                             t1, t2);  EXPR_POP ();}

static voidm3cg_min (void){  MTYPE (t);
  tree t1 = declare_temp (t);  tree t2 = declare_temp (t);
  add_stmt (m3_build2 (MODIFY_EXPR, t, t1, EXPR_REF (-1)));  add_stmt (m3_build2 (MODIFY_EXPR, t, t2, EXPR_REF (-2)));
  EXPR_REF (-2) = m3_build3 (COND_EXPR, t,                             m3_build2 (LE_EXPR, boolean_type_node, t1, t2),                             t1, t2);  EXPR_POP ();}


static voidm3cg_check_nil (void){  INTEGER (code);
  tree temp1 = declare_temp (t_addr);
  m3_store (temp1, 0, t_addr, T_addr, t_addr, T_addr);  EXPR_PUSH (temp1);  add_stmt (build3 (COND_EXPR, t_void,                    m3_build2 (EQ_EXPR, boolean_type_node, temp1, v_null),                    generate_fault (code),                    NULL_TREE));}


static voidm3cg_check_lo (void){  MTYPE2         (t, T);  TARGET_INTEGER (a);  INTEGER        (code);
  tree temp1 = declare_temp (t);
  a = convert (t, a);
  if (option_exprs_trace)    fprintf (stderr, "  check low type:%s code:0x%lx\n", m3cg_typename(T), code);
  if (TREE_TYPE (EXPR_REF (-1)) != t)    EXPR_REF (-1) = m3_build1 (CONVERT_EXPR, t, EXPR_REF (-1));
  m3_store (temp1, 0, t, T, t, T);  EXPR_PUSH (temp1);  add_stmt (build3 (COND_EXPR, t_void,                    m3_build2 (LT_EXPR, boolean_type_node, temp1, a),                    generate_fault (code),                    NULL_TREE));}

static voidm3cg_check_hi (void){  MTYPE2         (t, T);  TARGET_INTEGER (a);  INTEGER        (code);
  tree temp1 = declare_temp (t);
  a = convert (t, a);
  if (option_exprs_trace)    fprintf (stderr, "  check high type:%s code:0x%lx\n", m3cg_typename(T), code);
  if (TREE_TYPE (EXPR_REF (-1)) != t)    EXPR_REF (-1) = m3_build1 (CONVERT_EXPR, t, EXPR_REF (-1));
  m3_store (temp1, 0, t, T, t, T);  EXPR_PUSH (temp1);  add_stmt (build3 (COND_EXPR, t_void,                    m3_build2 (GT_EXPR, boolean_type_node, temp1, a),                    generate_fault (code),                    NULL_TREE));}

static voidm3cg_check_range (void){  MTYPE2         (t, T);  TARGET_INTEGER (a);  TARGET_INTEGER (b);  INTEGER        (code);
  tree temp1 = declare_temp (t);
  a = convert (t, a);  b = convert (t, b);
  if (option_exprs_trace)    fprintf (stderr, "  check range type:%s code:0x%lx\n", m3cg_typename(T), code);
  if (TREE_TYPE (EXPR_REF (-1)) != t)    EXPR_REF (-1) = m3_build1 (CONVERT_EXPR, t, EXPR_REF (-1));
  m3_store (temp1, 0, t, T, t, T);  EXPR_PUSH (temp1);  add_stmt (build3 (COND_EXPR, t_void,                    m3_build2 (TRUTH_ORIF_EXPR, boolean_type_node,                               m3_build2 (LT_EXPR,                                          boolean_type_node, temp1, a),                               m3_build2 (GT_EXPR,                                          boolean_type_node, temp1, b)),                    generate_fault (code),                    NULL_TREE));}

static voidm3cg_check_eq (void){  MTYPE2  (t, T);  INTEGER (code);
  tree temp1 = declare_temp (t);  tree temp2 = declare_temp (t);
  m3_store (temp1, 0, t, T, t, T);  m3_store (temp2, 0, t, T, t, T);  add_stmt (build3 (COND_EXPR, t_void,                    m3_build2 (NE_EXPR, boolean_type_node, temp1, temp2),                    generate_fault (code),                    NULL_TREE));}

seem kind of wasteful.

 - Jay

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

From jay.krell at cornell.edu  Sun Jun 27 13:15:13 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 27 Jun 2010 11:15:13 +0000
Subject: [M3devel] cm3ide and Chrome
In-Reply-To: <AANLkTim77ivruVuNT21PtStijrhMlRD-bNc9VOIH669d@mail.gmail.com>
References: <AANLkTim77ivruVuNT21PtStijrhMlRD-bNc9VOIH669d@mail.gmail.com>
Message-ID: <COL101-W43C485848DE91DF690DFF3E6C90@phx.gbl>


Similar? stuff has been discussed. Like, Internet Explorer returning or continuing to run depends on if there is already an instance."start /wait" prefixed to the command line might help.
"When specifying the browser.." you mean cminstall?  You might try manually editing c:\cm3\bin\cm3.cfg or c:\cm3\bin\config\NT386* after running it.  cminstall is just making small edits to them.
 - Jay

Date: Sun, 27 Jun 2010 18:54:30 +0800
From: ttmrichter at gmail.com
To: m3devel at elegosoft.com
Subject: [M3devel] cm3ide and Chrome

Is there a trick to making cm3ide work with Google Chrome?  The problem seems to be that Google Chrome returns immediately upon invocation where the default, Firefox, does not.  Cm3ide waits for the browser to exit to decide that it's time to end, so what winds up happening for me when specifying Chrome as the browser is that cm3ide starts, Chrome starts, cm3ide starts serving up some content, Chrome's launcher returns immediately, cm3ide dies.  The result is a partial opening page and nothing else.

Also, when specifying the browser (any browser), it doesn't like me giving options to the browser command line: it rejects "/usr/bin/google-chrome --new-window" as an option when asking for the browser if I delete the configuration file.  I have to go /usr/bin/google-chrome and then manually edit the configuration file to include any command line switches I want to use.

-- 
"Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot."

--Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra.

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

From rcolebur at SCIRES.COM  Sun Jun 27 13:25:55 2010
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Sun, 27 Jun 2010 07:25:55 -0400
Subject: [M3devel] cm3ide and Chrome
In-Reply-To: <AANLkTim77ivruVuNT21PtStijrhMlRD-bNc9VOIH669d@mail.gmail.com>
References: <AANLkTim77ivruVuNT21PtStijrhMlRD-bNc9VOIH669d@mail.gmail.com>
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E605DBF572@ATLEX02-SRV.SCIRES.LOCAL>

Michael:

You can edit the cm3ide configuration file to change the behavior.  This file is usually located in ..\Documents\CM3_IDE_Home\CM3_IDE.cfg0 or CM3_IDE.cfg1

Find the ?start_browser? proc.  Change the return value to be FALSE.

FALSE means CM3_IDE should stay running when the browser terminates, whereas TRUE causes it to terminate when the browser terminates.

If you want to give command line options to the browser, you can specify them in the start_browser proc as well.

Regards,
Randy Coleburn

From: Michael Richter [mailto:ttmrichter at gmail.com]
Sent: Sunday, June 27, 2010 6:55 AM
To: m3devel
Subject: [M3devel] cm3ide and Chrome

Is there a trick to making cm3ide work with Google Chrome?  The problem seems to be that Google Chrome returns immediately upon invocation where the default, Firefox, does not.  Cm3ide waits for the browser to exit to decide that it's time to end, so what winds up happening for me when specifying Chrome as the browser is that cm3ide starts, Chrome starts, cm3ide starts serving up some content, Chrome's launcher returns immediately, cm3ide dies.  The result is a partial opening page and nothing else.

Also, when specifying the browser (any browser), it doesn't like me giving options to the browser command line: it rejects "/usr/bin/google-chrome --new-window" as an option when asking for the browser if I delete the configuration file.  I have to go /usr/bin/google-chrome and then manually edit the configuration file to include any command line switches I want to use.

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

From rcolebur at SCIRES.COM  Sun Jun 27 13:27:41 2010
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Sun, 27 Jun 2010 07:27:41 -0400
Subject: [M3devel] cm3ide and Chrome
In-Reply-To: <COL101-W43C485848DE91DF690DFF3E6C90@phx.gbl>
References: <AANLkTim77ivruVuNT21PtStijrhMlRD-bNc9VOIH669d@mail.gmail.com>
	<COL101-W43C485848DE91DF690DFF3E6C90@phx.gbl>
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E605DBF573@ATLEX02-SRV.SCIRES.LOCAL>

See my prior post instead.
--Randy

From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Sunday, June 27, 2010 7:15 AM
To: ttmrichter at gmail.com; m3devel
Subject: Re: [M3devel] cm3ide and Chrome

Similar? stuff has been discussed.
 Like, Internet Explorer returning or continuing to run depends on if there is already an instance.
"start /wait" prefixed to the command line might help.

"When specifying the browser.." you mean cminstall?
  You might try manually editing c:\cm3\bin\cm3.cfg or c:\cm3\bin\config\NT386* after running it.
  cminstall is just making small edits to them.

 - Jay

________________________________
Date: Sun, 27 Jun 2010 18:54:30 +0800
From: ttmrichter at gmail.com
To: m3devel at elegosoft.com
Subject: [M3devel] cm3ide and Chrome

Is there a trick to making cm3ide work with Google Chrome?  The problem seems to be that Google Chrome returns immediately upon invocation where the default, Firefox, does not.  Cm3ide waits for the browser to exit to decide that it's time to end, so what winds up happening for me when specifying Chrome as the browser is that cm3ide starts, Chrome starts, cm3ide starts serving up some content, Chrome's launcher returns immediately, cm3ide dies.  The result is a partial opening page and nothing else.

Also, when specifying the browser (any browser), it doesn't like me giving options to the browser command line: it rejects "/usr/bin/google-chrome --new-window" as an option when asking for the browser if I delete the configuration file.  I have to go /usr/bin/google-chrome and then manually edit the configuration file to include any command line switches I want to use.

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

From jay.krell at cornell.edu  Sun Jun 27 14:39:45 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 27 Jun 2010 12:39:45 +0000
Subject: [M3devel] div/mod?
Message-ID: <COL101-W52D2A18F8772E0667B8746E6C90@phx.gbl>


implementing div/mod?
The historical implementation is "ok". advantages:   stable   doesn't do any div/mod of negative numbers disadvantages:   I believe it gets a few cases wrong, e.g. involving minimal inputs   relies on silent overflow of signed math     There are gcc flags that warn about this,     and I think also optimizations that break it.

"new" C implementation:  advantages:    avoids silent overflow overflow of signed numbers (no warnings from gcc)    I believe it fixes the incorrect cases in the historical implementation.  disadvantages:    one nagging part of it is how it deals with two negative    inputs; it assumes C matches Modula-3

INTEGER__stdcallm3_div(INTEGER b, INTEGER a){  int aneg = (a < 0);  int bneg = (b < 0);  if (aneg == bneg || a == 0 || b == 0)    return (a / b);...
INTEGER__stdcallm3_mod(INTEGER b, INTEGER a){  int aneg = (a < 0);  int bneg = (b < 0);  if (aneg == bneg || a == 0 || b == 0)    return (a % b);...

This makes me a bit nervous regarding the case of aneg && bneg.Generally, as was said, everyone defines div/mod the same for positive inputs,but once either (or both?) inputs are negative, there are several options.But it seems to test out ok. At least on AMD64_DARWIN. I could test more platforms.

gcc "opcodes" (tree codes, there are different ones for   trunc/round/floor/ceil div/mod)  presumably fastest option    and maybe smallest though probably not  presumably not much used  64bit path doesn't work for ARM, for a mostly understood reason,     compiler goes down path of wanting 128bit integers ("TImode"), though     I suspect it doesn't really need them, either it ends     up doing something else, or they are a way of     moving around a pair of int64

Could go back to the hybrid I had briefly: always use gcc "opcodes", except 64bit operations on ARM or could even fix 64bit on ARM?   ?

Notice that m3back has always implemented 32bit div/mod inline.  But always calls the C for 64bit.Also my confidence in gcc "opcodes" was briefly shakenby noticing it still uses the "normal" helper functions, butupon closer inspection, it does "wrap" them in various formsof rounding, depending on the exact operation requested.
 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100627/22b0ff30/attachment.html>

From ttmrichter at gmail.com  Sun Jun 27 14:47:12 2010
From: ttmrichter at gmail.com (Michael Richter)
Date: Sun, 27 Jun 2010 20:47:12 +0800
Subject: [M3devel] cm3ide and Chrome
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E605DBF572@ATLEX02-SRV.SCIRES.LOCAL>
References: <AANLkTim77ivruVuNT21PtStijrhMlRD-bNc9VOIH669d@mail.gmail.com>
	<D67F02DDC62F7545A6B84C285F88F3E605DBF572@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <AANLkTilNwMZJUnptlIJXPhbc7TJxw5PL4T0IotuE0VHD@mail.gmail.com>

On 27 June 2010 19:25, Coleburn, Randy <rcolebur at scires.com> wrote:

>  You can edit the cm3ide configuration file to change the behavior.  This
> file is usually located in ..\Documents\CM3_IDE_Home\*CM3_IDE.cfg0* or *
> CM3_IDE.cfg1*
>
> Find the ?*start_browser*? proc.  Change the return value to be *FALSE*.
>
I found the .cfg* file but I didn't catch that TRUE/FALSE return value
thing.  That makes a huge difference!  Thanks a lot.

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

From jay.krell at cornell.edu  Sun Jun 27 15:44:06 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 27 Jun 2010 13:44:06 +0000
Subject: [M3devel] m3cg 4.5 problem
In-Reply-To: <COL101-W2519C65D63208BF55620CE6C90@phx.gbl>
References: <COL101-W728051433DA06972261F1E6C90@phx.gbl>,
	<COL101-W2519C65D63208BF55620CE6C90@phx.gbl>
Message-ID: <COL101-W24F2979E24DCCB1CDD09B3E6C90@phx.gbl>


I almost have this figured out.

4.5:
(gdb) break is_gimple_lvalue(gdb) runBreakpoint 2, is_gimple_lvalue (t=0x414653b8) at ../../gcc-4.5/gcc/gimple.c:24562456	  return (is_gimple_addressable (t)(gdb) call debug_tree(t) <nop_expr 0x414653b8    type <integer_type 0x41417360 int_64 public DI        size <integer_cst 0x41405340 constant 64>        unit size <integer_cst 0x41405360 constant 8>        align 64 symtab 0 alias set -1 canonical type 0x41417360 precision 64 min <integer_cst 0x414052e0 -9223372036854775808> max <integer_cst 0x41405300 9223372036854775807>>       arg 0 <var_decl 0x414680b8 M3_DxNB17_oc        type <integer_type 0x414173c0 word_64 sizes-gimplified public unsigned DI size <integer_cst 0x41405340 64> unit size <integer_cst 0x41405360 8>            align 64 symtab 0 alias set -1 canonical type 0x414173c0 precision 64 min <integer_cst 0x41405380 0> max <integer_cst 0x41405320 18446744073709551615>>        unsigned DI file ../src/stmts/TypeCaseStmt.m3 line 12 col 0 size <integer_cst 0x41405340 64> unit size <integer_cst 0x41405360 8>        align 64 context <function_decl 0x41466400 TypeCaseStmt__GetOutcomex>>>


(gdb) finishRun till exit from #0  is_gimple_lvalue (t=0x414653b8) at ../../gcc-4.5/gcc/gimple.c:24560x004ea8bc in gimplify_expr (expr_p=0x41456218, pre_p=0xbffff510, post_p=0xbffff230, gimple_test_f=0x4c9bd5 <is_gimple_lvalue>, fallback=2) at ../../gcc-4.5/gcc/gimplify.c:72627262	gimple_test_f) (*expr_p))Value returned is $13 = 0 '\0'

4.3:(gdb) break is_gimple_lvalueBreakpoint 1 at 0x5708e3: file ../../gcc/gcc/tree-gimple.c, line 147.(gdb) runStarting program: /Users/jay/dev2/cm3/m3-sys/m3cc/I386_DARWIN-I386_DARWIN-4.3/gcc/m3cgc1 -m64 TypeCaseStmt.mcReading symbols for shared libraries ++. done TypeCaseStmt__GetOutcomexBreakpoint 1, is_gimple_lvalue (t=0x41141060) at ../../gcc/gcc/tree-gimple.c:147147	  return (is_gimple_addressable (t)(gdb) call debug_tree(t) <var_decl 0x41141060 M3_DxNB17_oc    type <integer_type 0x41111460 word_64 sizes-gimplified public unsigned DI        size <integer_cst 0x40b2d6f0 constant invariant 64>        unit size <integer_cst 0x40b2d720 constant invariant 8>        align 64 symtab 0 alias set -1 canonical type 0x41111460 precision 64 min <integer_cst 0x40b2d750 0> max <integer_cst 0x40b2d6c0 18446744073709551615>>    unsigned DI file ../src/stmts/TypeCaseStmt.m3 line 12 col 0 size <integer_cst 0x40b2d6f0 64> unit size <integer_cst 0x40b2d720 8>    align 64 context <function_decl 0x4113e100 TypeCaseStmt__GetOutcomex>>(gdb) finishRun till exit from #0  is_gimple_lvalue (t=0x41141060) at ../../gcc/gcc/tree-gimple.c:1470x003d7541 in gimplify_expr (expr_p=0x4113d16c, pre_p=0xbffff350, post_p=0xbffff34c, gimple_test_f=0x5708dd <is_gimple_lvalue>, fallback=fb_either) at ../../gcc/gcc/gimplify.c:6240warning: Source file is more recent than executable.6240	  if (!internal_post && (*gimple_test_f) (*expr_p))Value returned is $1 = 1 '\001'

nop_expr is what we use for casting.We are casting int64 to word64.The result of a cast is not an lvalue.I suspect 4.3 has removed this as a "useless conversion"...
In 4.5 we have: gdb: call debug_tree(*expr_p)
        stmt <modify_expr 0x41456200 type <integer_type 0x41417360 int_64>            side-effects used            arg 0 <nop_expr 0x414653b8 type <integer_type 0x41417360 int_64>                arg 0 <var_decl 0x414680b8 M3_DxNB17_oc>>            arg 1 <integer_cst 0x414057e0 constant 0>            ../src/stmts/TypeCaseStmt.m3:7:0>

in 4.3 we have:
        stmt <modify_expr 0x4113d180 type <integer_type 0x411113f0 int_64>            side-effects used            arg 0 <bit_field_ref 0x4113d150 type <integer_type 0x411113f0 int_64>                arg 0 <var_decl 0x41141060 M3_DxNB17_oc>                arg 1 <integer_cst 0x40b2d6f0 64>                arg 2 <integer_cst 0x40b2da20 constant invariant 0>>            arg 1 <integer_cst 0x40b2dde0 constant invariant 0>            ../src/stmts/TypeCaseStmt.m3:7:0> Again, 4.5 reads: (int64)oc = 0;
4.3 reads:  (bit field ref)oc = 0;
int64 cast is not an lvalue, bit field ref is. Something like that.
Either one of the #if GCC45 I have or gcc has done a transform in the meantime..
I'll keep digging.
I don't believe we need the cast -- we should just get the type right in the first place.But fixing that isn't necessarily what I'm going to do.I have to see where 4.3 vs. 4.5 difference comes from first..

 - Jay


From: jay.krell at cornell.edu
To: m3devel at elegosoft.com; hosking at cs.purdue.edu
Date: Sun, 27 Jun 2010 09:23:13 +0000
Subject: Re: [M3devel] m3cg 4.5 problem








I was a bit off. It is actually set of enum. Like this:
MODULE TypeCaseStmt;
TYPE T1 = {A,B};TYPE T2 = SET OF T1; PROCEDURE GetOutcomex (): T2 =  VAR oc := T2 {};  BEGIN    RETURN oc;  END GetOutcomex;
BEGINEND TypeCaseStmt.
 - Jay
From: jay.krell at cornell.edu
To: m3devel at elegosoft.com; hosking at cs.purdue.edu
Date: Sun, 27 Jun 2010 08:12:54 +0000
Subject: [M3devel] m3cg 4.5 problem








This tiny bit of code, which is cut down from m3front, causes an assertion failure in a 4.5 m3cg:
MODULE TypeCaseStmt;
IMPORT M3ID, CG, Expr, Stmt, StmtRep, Type, Variable, Scope;
PROCEDURE GetOutcomex (): Stmt.Outcomes =  VAR oc := Stmt.Outcomes {};  line 6  BEGIN    RETURN oc;  END GetOutcomex;
BEGINEND TypeCaseStmt.
../src/stmts/TypeCaseStmt.m3:6:0: internal compiler error: in gimplify_expr, at gimplify.c:7315Please submit a full bug report,

(1) begin_unit(2) set_source_file(3) set_source_line  source line    1(4) comment  comment: `module global constants'(5) declare_segment  segment L_1 typeid 0xffffffff(6) comment  comment: `module global data'(7) declare_segment  segment MM_TypeCaseStmt typeid 0xffffffff(8) set_source_line  source line   11(9) declare_procedure  type:addr  procedure:TypeCaseStmt_M3 nparams:0x1 rettype:addr lev:0 exported:1(10) declare_param  type:int64  param M3_AcxOUs_mode type:int64 typeid:0x195c2a74 bytesize:0x40 alignment:0x40 in_memory:0x0 up_level:0x0  mode 0x11 (DImode)(11) import_procedure  type:addr  procedure:TypeCaseStmt_I3 nparams:0x0 rettype:addr(12) export_unit(13) import_procedure  type:addr  procedure:Scope_I3 nparams:0x0 rettype:addr(14) import_unit(15) import_procedure  type:addr  procedure:Variable_I3 nparams:0x0 rettype:addr(16) import_unit(17) import_procedure  type:addr  procedure:Type_I3 nparams:0x0 rettype:addr(18) import_unit(19) import_procedure  type:addr  procedure:StmtRep_I3 nparams:0x0 rettype:addr(20) import_unit(21) import_procedure  type:addr  procedure:Stmt_I3 nparams:0x0 rettype:addr(22) import_unit(23) import_procedure  type:addr  procedure:Expr_I3 nparams:0x0 rettype:addr(24) import_unit(25) import_procedure  type:addr  procedure:CG_I3 nparams:0x0 rettype:addr(26) import_unit(27) import_procedure  type:addr  procedure:M3ID_I3 nparams:0x0 rettype:addr(28) import_unit(29) import_procedure  type:addr  procedure:RTHooks_I3 nparams:0x0 rettype:addr(30) import_unit(31) declare_procedure  type:word64  procedure:TypeCaseStmt__GetOutcomex nparams:0x0 rettype:word64 lev:0 exported:0(32) declare_local  type:word64  local var M3_EXQtd6_oc type:word64 size:0x40 alignment:0x40(33) declare_local  type:word64  local var M3_EXQtd6__result type:word64 size:0x40 alignment:0x40(34) comment  comment: `GetOutcomex'(35) set_source_line  source line    5(36) begin_procedure  procedure TypeCaseStmt__GetOutcomex TypeCaseStmt__GetOutcomex(37) set_source_line  source line    6(38) load_integer  type:int64  integer:0x0(39) store  type:int64  type:int64  store (M3_EXQtd6_oc) offset:0x0 src_t:int64 dst_t:int64(40) set_source_line  source line    8(41) load  type:word64  type:int64  m3cg_load (M3_EXQtd6_oc): offset 0x0, convert word64 -> int64(42) exit_proc  type:word64(43) end_procedure  procedure TypeCaseStmt__GetOutcomex

Breakpoint 1, fancy_abort (file=0x1009f0c6f "../../gcc-4.5/gcc/gimplify.c", line=7315, function=0x1009f1242 "gimplify_expr") at ../../gcc-4.5/gcc/diagnostic.c:763763	  internal_error ("in %s, at %s:%d", function, trim_filename (file), line);(gdb) bt#0  fancy_abort (file=0x1009f0c6f "../../gcc-4.5/gcc/gimplify.c", line=7315, function=0x1009f1242 "gimplify_expr") at ../../gcc-4.5/gcc/diagnostic.c:763#1  0x00000001004cc4d6 in gimplify_expr (expr_p=0x1410e2060, pre_p=0x7fff5fbff420, post_p=0x7fff5fbfeff8, gimple_test_f=0x1004aac7f <is_gimple_lvalue>, fallback=2) at ../../gcc-4.5/gcc/gimplify.c:7315#2  0x00000001004c5ad3 in gimplify_modify_expr (expr_p=0x1416a5f28, pre_p=0x7fff5fbff420, post_p=0x7fff5fbfeff8, want_value=0 '\0') at ../../gcc-4.5/gcc/gimplify.c:4444#3  0x00000001004caafc in gimplify_expr (expr_p=0x1416a5f28, pre_p=0x7fff5fbff420, post_p=0x7fff5fbfeff8, gimple_test_f=0x1004ab1a6 <is_gimple_stmt>, fallback=0) at ../../gcc-4.5/gcc/gimplify.c:6619#4  0x00000001004c7800 in gimplify_stmt (stmt_p=0x1416a5f28, seq_p=0x7fff5fbff420) at ../../gcc-4.5/gcc/gimplify.c:5264#5  0x00000001004be376 in gimplify_statement_list (expr_p=0x1416c4030, pre_p=0x7fff5fbff420) at ../../gcc-4.5/gcc/gimplify.c:1382#6  0x00000001004cb6f5 in gimplify_expr (expr_p=0x1416c4030, pre_p=0x7fff5fbff420, post_p=0x7fff5fbff2e8, gimple_test_f=0x1004ab1a6 <is_gimple_stmt>, fallback=0) at ../../gcc-4.5/gcc/gimplify.c:6935#7  0x00000001004c7800 in gimplify_stmt (stmt_p=0x1416c4030, seq_p=0x7fff5fbff420) at ../../gcc-4.5/gcc/gimplify.c:5264#8  0x00000001004bdb6c in gimplify_bind_expr (expr_p=0x1416c2298, pre_p=0x7fff5fbff778) at ../../gcc-4.5/gcc/gimplify.c:1127#9  0x00000001004cae2b in gimplify_expr (expr_p=0x1416c2298, pre_p=0x7fff5fbff778, post_p=0x7fff5fbff618, gimple_test_f=0x1004ab1a6 <is_gimple_stmt>, fallback=0) at ../../gcc-4.5/gcc/gimplify.c:6719#10 0x00000001004c7800 in gimplify_stmt (stmt_p=0x1416c2298, seq_p=0x7fff5fbff778) at ../../gcc-4.5/gcc/gimplify.c:5264#11 0x00000001004ccbe6 in gimplify_body (body_p=0x1416c2298, fndecl=0x1416c2200, do_parms=1 '\001') at ../../gcc-4.5/gcc/gimplify.c:7528#12 0x00000001004cceae in gimplify_function_tree (fndecl=0x1416c2200) at ../../gcc-4.5/gcc/gimplify.c:7624#13 0x00000001000069c7 in m3_gimplify_function (fndecl=0x1416c2200) at ../../gcc-4.5/gcc/m3cg/parse.c:2370#14 0x0000000100009cb4 in m3cg_end_procedure () at ../../gcc-4.5/gcc/m3cg/parse.c:3642#15 0x000000010000feb5 in m3_parse_file (xx=0) at ../../gcc-4.5/gcc/m3cg/parse.c:5550#16 0x00000001006be6a2 in compile_file () at ../../gcc-4.5/gcc/toplev.c:1053#17 0x00000001006c0e19 in do_compile () at ../../gcc-4.5/gcc/toplev.c:2415#18 0x00000001006c0ee0 in toplev_main (argc=3, argv=0x7fff5fbff930) at ../../gcc-4.5/gcc/toplev.c:2457#19 0x000000010001743b in main (argc=3, argv=0x7fff5fbff930) at ../../gcc-4.5/gcc/main.c:35(

Wierd, huh?
The only thing I can think of an int/word mismatch.I did change one instance of Integer to Word, after finding this.Stmt.Outcomes is an enumeration.So presumably Stmt.Outcomes { } is 0.Enumerations should work equally well as Integer or Word, right?Clearly above there is still a mix. I can try changing them all to Word.

I'll keep digging.

Maybe dump the entire function generic tree for this and similar C.

 - Jay 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100627/47649ec6/attachment.html>

From jay.krell at cornell.edu  Sun Jun 27 17:04:59 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 27 Jun 2010 15:04:59 +0000
Subject: [M3devel] m3cg 4.5 problem
In-Reply-To: <COL101-W24F2979E24DCCB1CDD09B3E6C90@phx.gbl>
References: <COL101-W728051433DA06972261F1E6C90@phx.gbl>, ,
	<COL101-W2519C65D63208BF55620CE6C90@phx.gbl>,
	<COL101-W24F2979E24DCCB1CDD09B3E6C90@phx.gbl>
Message-ID: <COL101-W327A4E4C62AF02A66F7138E6C90@phx.gbl>


Problem seems to be here:

fold-const.c:fold_ternary_loc
...  switch (code)...    case BIT_FIELD_REF:...      /* A bit-field-ref that referenced the full argument can be stripped.  */      if (INTEGRAL_TYPE_P (TREE_TYPE (arg0))	  && TYPE_PRECISION (TREE_TYPE (arg0)) == tree_low_cst (arg1, 1)	  && integer_zerop (op2))	return fold_convert_loc (loc, type, arg0);

Turning our bit field refs which are lvalues into casts (nop_expr) which are not.For now I'll #if this out.Further investigation: see how it compares to trunk; see if we can get the types right.
 - Jay
From: jay.krell at cornell.edu
To: m3devel at elegosoft.com; hosking at cs.purdue.edu
Date: Sun, 27 Jun 2010 13:44:06 +0000
Subject: Re: [M3devel] m3cg 4.5 problem








I almost have this figured out.

4.5:
(gdb) break is_gimple_lvalue(gdb) runBreakpoint 2, is_gimple_lvalue (t=0x414653b8) at ../../gcc-4.5/gcc/gimple.c:24562456	  return (is_gimple_addressable (t)(gdb) call debug_tree(t) <nop_expr 0x414653b8    type <integer_type 0x41417360 int_64 public DI        size <integer_cst 0x41405340 constant 64>        unit size <integer_cst 0x41405360 constant 8>        align 64 symtab 0 alias set -1 canonical type 0x41417360 precision 64 min <integer_cst 0x414052e0 -9223372036854775808> max <integer_cst 0x41405300 9223372036854775807>>       arg 0 <var_decl 0x414680b8 M3_DxNB17_oc        type <integer_type 0x414173c0 word_64 sizes-gimplified public unsigned DI size <integer_cst 0x41405340 64> unit size <integer_cst 0x41405360 8>            align 64 symtab 0 alias set -1 canonical type 0x414173c0 precision 64 min <integer_cst 0x41405380 0> max <integer_cst 0x41405320 18446744073709551615>>        unsigned DI file ../src/stmts/TypeCaseStmt.m3 line 12 col 0 size <integer_cst 0x41405340 64> unit size <integer_cst 0x41405360 8>        align 64 context <function_decl 0x41466400 TypeCaseStmt__GetOutcomex>>>


(gdb) finishRun till exit from #0  is_gimple_lvalue (t=0x414653b8) at ../../gcc-4.5/gcc/gimple.c:24560x004ea8bc in gimplify_expr (expr_p=0x41456218, pre_p=0xbffff510, post_p=0xbffff230, gimple_test_f=0x4c9bd5 <is_gimple_lvalue>, fallback=2) at ../../gcc-4.5/gcc/gimplify.c:72627262	gimple_test_f) (*expr_p))Value returned is $13 = 0 '\0'

4.3:(gdb) break is_gimple_lvalueBreakpoint 1 at 0x5708e3: file ../../gcc/gcc/tree-gimple.c, line 147.(gdb) runStarting program: /Users/jay/dev2/cm3/m3-sys/m3cc/I386_DARWIN-I386_DARWIN-4.3/gcc/m3cgc1 -m64 TypeCaseStmt.mcReading symbols for shared libraries ++. done TypeCaseStmt__GetOutcomexBreakpoint 1, is_gimple_lvalue (t=0x41141060) at ../../gcc/gcc/tree-gimple.c:147147	  return (is_gimple_addressable (t)(gdb) call debug_tree(t) <var_decl 0x41141060 M3_DxNB17_oc    type <integer_type 0x41111460 word_64 sizes-gimplified public unsigned DI        size <integer_cst 0x40b2d6f0 constant invariant 64>        unit size <integer_cst 0x40b2d720 constant invariant 8>        align 64 symtab 0 alias set -1 canonical type 0x41111460 precision 64 min <integer_cst 0x40b2d750 0> max <integer_cst 0x40b2d6c0 18446744073709551615>>    unsigned DI file ../src/stmts/TypeCaseStmt.m3 line 12 col 0 size <integer_cst 0x40b2d6f0 64> unit size <integer_cst 0x40b2d720 8>    align 64 context <function_decl 0x4113e100 TypeCaseStmt__GetOutcomex>>(gdb) finishRun till exit from #0  is_gimple_lvalue (t=0x41141060) at ../../gcc/gcc/tree-gimple.c:1470x003d7541 in gimplify_expr (expr_p=0x4113d16c, pre_p=0xbffff350, post_p=0xbffff34c, gimple_test_f=0x5708dd <is_gimple_lvalue>, fallback=fb_either) at ../../gcc/gcc/gimplify.c:6240warning: Source file is more recent than executable.6240	  if (!internal_post && (*gimple_test_f) (*expr_p))Value returned is $1 = 1 '\001'

nop_expr is what we use for casting.We are casting int64 to word64.The result of a cast is not an lvalue.I suspect 4.3 has removed this as a "useless conversion"...
In 4.5 we have: gdb: call debug_tree(*expr_p)
        stmt <modify_expr 0x41456200 type <integer_type 0x41417360 int_64>            side-effects used            arg 0 <nop_expr 0x414653b8 type <integer_type 0x41417360 int_64>                arg 0 <var_decl 0x414680b8 M3_DxNB17_oc>>            arg 1 <integer_cst 0x414057e0 constant 0>            ../src/stmts/TypeCaseStmt.m3:7:0>

in 4.3 we have:
        stmt <modify_expr 0x4113d180 type <integer_type 0x411113f0 int_64>            side-effects used            arg 0 <bit_field_ref 0x4113d150 type <integer_type 0x411113f0 int_64>                arg 0 <var_decl 0x41141060 M3_DxNB17_oc>                arg 1 <integer_cst 0x40b2d6f0 64>                arg 2 <integer_cst 0x40b2da20 constant invariant 0>>            arg 1 <integer_cst 0x40b2dde0 constant invariant 0>            ../src/stmts/TypeCaseStmt.m3:7:0> Again, 4.5 reads: (int64)oc = 0;
4.3 reads:  (bit field ref)oc = 0;
int64 cast is not an lvalue, bit field ref is. Something like that.
Either one of the #if GCC45 I have or gcc has done a transform in the meantime..
I'll keep digging.
I don't believe we need the cast -- we should just get the type right in the first place.But fixing that isn't necessarily what I'm going to do.I have to see where 4.3 vs. 4.5 difference comes from first..

 - Jay


From: jay.krell at cornell.edu
To: m3devel at elegosoft.com; hosking at cs.purdue.edu
Date: Sun, 27 Jun 2010 09:23:13 +0000
Subject: Re: [M3devel] m3cg 4.5 problem








I was a bit off. It is actually set of enum. Like this:
MODULE TypeCaseStmt;
TYPE T1 = {A,B};TYPE T2 = SET OF T1; PROCEDURE GetOutcomex (): T2 =  VAR oc := T2 {};  BEGIN    RETURN oc;  END GetOutcomex;
BEGINEND TypeCaseStmt.
 - Jay
From: jay.krell at cornell.edu
To: m3devel at elegosoft.com; hosking at cs.purdue.edu
Date: Sun, 27 Jun 2010 08:12:54 +0000
Subject: [M3devel] m3cg 4.5 problem








This tiny bit of code, which is cut down from m3front, causes an assertion failure in a 4.5 m3cg:
MODULE TypeCaseStmt;
IMPORT M3ID, CG, Expr, Stmt, StmtRep, Type, Variable, Scope;
PROCEDURE GetOutcomex (): Stmt.Outcomes =  VAR oc := Stmt.Outcomes {};  line 6  BEGIN    RETURN oc;  END GetOutcomex;
BEGINEND TypeCaseStmt.
../src/stmts/TypeCaseStmt.m3:6:0: internal compiler error: in gimplify_expr, at gimplify.c:7315Please submit a full bug report,

(1) begin_unit(2) set_source_file(3) set_source_line  source line    1(4) comment  comment: `module global constants'(5) declare_segment  segment L_1 typeid 0xffffffff(6) comment  comment: `module global data'(7) declare_segment  segment MM_TypeCaseStmt typeid 0xffffffff(8) set_source_line  source line   11(9) declare_procedure  type:addr  procedure:TypeCaseStmt_M3 nparams:0x1 rettype:addr lev:0 exported:1(10) declare_param  type:int64  param M3_AcxOUs_mode type:int64 typeid:0x195c2a74 bytesize:0x40 alignment:0x40 in_memory:0x0 up_level:0x0  mode 0x11 (DImode)(11) import_procedure  type:addr  procedure:TypeCaseStmt_I3 nparams:0x0 rettype:addr(12) export_unit(13) import_procedure  type:addr  procedure:Scope_I3 nparams:0x0 rettype:addr(14) import_unit(15) import_procedure  type:addr  procedure:Variable_I3 nparams:0x0 rettype:addr(16) import_unit(17) import_procedure  type:addr  procedure:Type_I3 nparams:0x0 rettype:addr(18) import_unit(19) import_procedure  type:addr  procedure:StmtRep_I3 nparams:0x0 rettype:addr(20) import_unit(21) import_procedure  type:addr  procedure:Stmt_I3 nparams:0x0 rettype:addr(22) import_unit(23) import_procedure  type:addr  procedure:Expr_I3 nparams:0x0 rettype:addr(24) import_unit(25) import_procedure  type:addr  procedure:CG_I3 nparams:0x0 rettype:addr(26) import_unit(27) import_procedure  type:addr  procedure:M3ID_I3 nparams:0x0 rettype:addr(28) import_unit(29) import_procedure  type:addr  procedure:RTHooks_I3 nparams:0x0 rettype:addr(30) import_unit(31) declare_procedure  type:word64  procedure:TypeCaseStmt__GetOutcomex nparams:0x0 rettype:word64 lev:0 exported:0(32) declare_local  type:word64  local var M3_EXQtd6_oc type:word64 size:0x40 alignment:0x40(33) declare_local  type:word64  local var M3_EXQtd6__result type:word64 size:0x40 alignment:0x40(34) comment  comment: `GetOutcomex'(35) set_source_line  source line    5(36) begin_procedure  procedure TypeCaseStmt__GetOutcomex TypeCaseStmt__GetOutcomex(37) set_source_line  source line    6(38) load_integer  type:int64  integer:0x0(39) store  type:int64  type:int64  store (M3_EXQtd6_oc) offset:0x0 src_t:int64 dst_t:int64(40) set_source_line  source line    8(41) load  type:word64  type:int64  m3cg_load (M3_EXQtd6_oc): offset 0x0, convert word64 -> int64(42) exit_proc  type:word64(43) end_procedure  procedure TypeCaseStmt__GetOutcomex

Breakpoint 1, fancy_abort (file=0x1009f0c6f "../../gcc-4.5/gcc/gimplify.c", line=7315, function=0x1009f1242 "gimplify_expr") at ../../gcc-4.5/gcc/diagnostic.c:763763	  internal_error ("in %s, at %s:%d", function, trim_filename (file), line);(gdb) bt#0  fancy_abort (file=0x1009f0c6f "../../gcc-4.5/gcc/gimplify.c", line=7315, function=0x1009f1242 "gimplify_expr") at ../../gcc-4.5/gcc/diagnostic.c:763#1  0x00000001004cc4d6 in gimplify_expr (expr_p=0x1410e2060, pre_p=0x7fff5fbff420, post_p=0x7fff5fbfeff8, gimple_test_f=0x1004aac7f <is_gimple_lvalue>, fallback=2) at ../../gcc-4.5/gcc/gimplify.c:7315#2  0x00000001004c5ad3 in gimplify_modify_expr (expr_p=0x1416a5f28, pre_p=0x7fff5fbff420, post_p=0x7fff5fbfeff8, want_value=0 '\0') at ../../gcc-4.5/gcc/gimplify.c:4444#3  0x00000001004caafc in gimplify_expr (expr_p=0x1416a5f28, pre_p=0x7fff5fbff420, post_p=0x7fff5fbfeff8, gimple_test_f=0x1004ab1a6 <is_gimple_stmt>, fallback=0) at ../../gcc-4.5/gcc/gimplify.c:6619#4  0x00000001004c7800 in gimplify_stmt (stmt_p=0x1416a5f28, seq_p=0x7fff5fbff420) at ../../gcc-4.5/gcc/gimplify.c:5264#5  0x00000001004be376 in gimplify_statement_list (expr_p=0x1416c4030, pre_p=0x7fff5fbff420) at ../../gcc-4.5/gcc/gimplify.c:1382#6  0x00000001004cb6f5 in gimplify_expr (expr_p=0x1416c4030, pre_p=0x7fff5fbff420, post_p=0x7fff5fbff2e8, gimple_test_f=0x1004ab1a6 <is_gimple_stmt>, fallback=0) at ../../gcc-4.5/gcc/gimplify.c:6935#7  0x00000001004c7800 in gimplify_stmt (stmt_p=0x1416c4030, seq_p=0x7fff5fbff420) at ../../gcc-4.5/gcc/gimplify.c:5264#8  0x00000001004bdb6c in gimplify_bind_expr (expr_p=0x1416c2298, pre_p=0x7fff5fbff778) at ../../gcc-4.5/gcc/gimplify.c:1127#9  0x00000001004cae2b in gimplify_expr (expr_p=0x1416c2298, pre_p=0x7fff5fbff778, post_p=0x7fff5fbff618, gimple_test_f=0x1004ab1a6 <is_gimple_stmt>, fallback=0) at ../../gcc-4.5/gcc/gimplify.c:6719#10 0x00000001004c7800 in gimplify_stmt (stmt_p=0x1416c2298, seq_p=0x7fff5fbff778) at ../../gcc-4.5/gcc/gimplify.c:5264#11 0x00000001004ccbe6 in gimplify_body (body_p=0x1416c2298, fndecl=0x1416c2200, do_parms=1 '\001') at ../../gcc-4.5/gcc/gimplify.c:7528#12 0x00000001004cceae in gimplify_function_tree (fndecl=0x1416c2200) at ../../gcc-4.5/gcc/gimplify.c:7624#13 0x00000001000069c7 in m3_gimplify_function (fndecl=0x1416c2200) at ../../gcc-4.5/gcc/m3cg/parse.c:2370#14 0x0000000100009cb4 in m3cg_end_procedure () at ../../gcc-4.5/gcc/m3cg/parse.c:3642#15 0x000000010000feb5 in m3_parse_file (xx=0) at ../../gcc-4.5/gcc/m3cg/parse.c:5550#16 0x00000001006be6a2 in compile_file () at ../../gcc-4.5/gcc/toplev.c:1053#17 0x00000001006c0e19 in do_compile () at ../../gcc-4.5/gcc/toplev.c:2415#18 0x00000001006c0ee0 in toplev_main (argc=3, argv=0x7fff5fbff930) at ../../gcc-4.5/gcc/toplev.c:2457#19 0x000000010001743b in main (argc=3, argv=0x7fff5fbff930) at ../../gcc-4.5/gcc/main.c:35(

Wierd, huh?
The only thing I can think of an int/word mismatch.I did change one instance of Integer to Word, after finding this.Stmt.Outcomes is an enumeration.So presumably Stmt.Outcomes { } is 0.Enumerations should work equally well as Integer or Word, right?Clearly above there is still a mix. I can try changing them all to Word.

I'll keep digging.

Maybe dump the entire function generic tree for this and similar C.

 - Jay 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100627/0a29baa9/attachment.html>

From jay.krell at cornell.edu  Mon Jun 28 03:39:35 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 28 Jun 2010 01:39:35 +0000
Subject: [M3devel] gcc 4.5 status
Message-ID: <COL101-W56446A25BC09D1C25A5AD9E6CA0@phx.gbl>


Gcc 4.5 complains about a few similar aspects of our trees.
These would all be errors but I hacked the gcc source to make them warnings.


Running cm3 build with gcc 4.5 crashes early in sysutils => PathReprCommon => Text.Length.


I think I'll try to fix up these type issues first.
You can see they aren't all that interesting, either widening an unsigned integer or
changing the signedness but not the width of an integer.

It's likely this checking isn't on by default, but that I enabled it, and that the errors/warnings are true,
?even though my enabling might have been by hacking the #idefs instead of the configure command.


I assume upgrading to gcc 4.5 is considered fairly unilaterly uncontroversially good.
I chose working on it for that reason.


D.1401 = TextClass__GetChar (M3_Bd56fi_t.11, M3_Cwb5VA_i.10);

cm3cg: warning: type mismatch in indirect reference
word_64

<unnamed type>

D.1408 = *D.1407;

cm3cg: warning: verify_gimple failed
../src/cm3/TextUtils.m3: In function 'TextUtils__SkipRight':
cm3cg: warning: invalid conversion in gimple call
word_8

word_64

D.1481 = TextClass__GetChar (M3_Bd56fi_t.36, D.1479);

cm3cg: warning: type mismatch in indirect reference
word_64

<unnamed type>

D.1488 = *D.1487;

cm3cg: warning: verify_gimple failed
../src/cm3/TextUtils.m3: In function 'TextUtils__Compress':
cm3cg: warning: invalid conversion in gimple call
word_8

word_64

D.1553 = TextClass__GetChar (M3_Bd56fi_t.59, M3_Cwb5VA_i.58);

cm3cg: warning: type mismatch in indirect reference
word_64

<unnamed type>

D.1560 = *D.1559;

cm3cg: warning: invalid conversion in gimple call
word_8

word_64

D.1591 = TextClass__GetChar (M3_Bd56fi_t.67, D.1589);

cm3cg: warning: type mismatch in indirect reference
word_64

<unnamed type>

D.1598 = *D.1597;

cm3cg: warning: verify_gimple failed
../src/cm3/TextUtils.m3: In function 'TextUtils__SubstChar':
cm3cg: warning: invalid conversion in gimple call
word_8

word_64

D.1683 = TextClass__GetChar (M3_Bd56fi_t.99, D.1681);

cm3cg: warning: type mismatch in binary expression
word_64

int_64

int_64

D.1701 = D.1700 & 1;

cm3cg: warning: type mismatch in binary expression
word_64

int_64

int_64






 		 	   		  

From dabenavidesd at yahoo.es  Mon Jun 28 04:37:11 2010
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Mon, 28 Jun 2010 02:37:11 +0000 (GMT)
Subject: [M3devel] gcc 4.5 status
In-Reply-To: <COL101-W56446A25BC09D1C25A5AD9E6CA0@phx.gbl>
Message-ID: <619968.30896.qm@web23605.mail.ird.yahoo.com>

Hi all:
please let me investigate before you make the simple changes you are trying because as I understand the type of the ADR operator might be of an unsafe module but that doesn't mean you can hack it to do your program better compile (that would be like use an ill behaved program to make "well" behaved ones). I mean is good to discard that the type system (the set of sound type rules that make a program compile run and if safely guarded do its work flawlessly, that is, the set of safe and well behaved programs without ill behaved in there) is not "hacked" hard coded to expect the type of ADR to be ADDRESS instead of the UNTRACED REF T.
I would like to be pointed out the way you are trying to solve the initial problem, I mean it is easy to see that ADR operator might return ADDRESS but probably not in all cases (programs) to be UNTRACED REF T though your programs show yes, changes reveal there is a problem indeed with current tree.
Anyway this needs to confirm there is a change in the type rules a check of original m3tk as before had happened with the new types or type introductions rules.
I might need explanations about your rationale behind the new ADR type so if you don't mind just tell me what are the reasons to do the mentioned changes if you don't mind. I know there are this emails:
https://mail.elegosoft.com/pipermail/m3devel/2010-June/007241.html
and
https://mail.elegosoft.com/pipermail/m3devel/2010-June/007249.html
BTW are the m3-sys/cm3/m3test shipped to the source browser in Elego web pages, I might need to check this test cases before the actual code, see:
http://opencm3.net/doc/help/gen_html/INDEX.html
If not we better make some ones testing UNSAFE features if they aren't shipped and/or already done (just to proof well behaved programs properties in UNSAFE modules to see if they actually work and if not why do they fail, I know there might be less panic with them but is better to have them than nothing, we might make some directory of them if somebody can point out where I can put then I have Elego ssh keys so I can see what I can do about it).

Thanks for your attention


--- El dom, 27/6/10, Jay K <jay.krell at cornell.edu> escribi?:

> De: Jay K <jay.krell at cornell.edu>
> Asunto: [M3devel] gcc 4.5 status
> Para: "m3devel" <m3devel at elegosoft.com>
> Fecha: domingo, 27 de junio, 2010 20:39
> 
> Gcc 4.5 complains about a few similar aspects of our
> trees.
> These would all be errors but I hacked the gcc source to
> make them warnings.
> 
> 
> Running cm3 build with gcc 4.5 crashes early in sysutils
> => PathReprCommon => Text.Length.
> 
> 
> I think I'll try to fix up these type issues first.
> You can see they aren't all that interesting, either
> widening an unsigned integer or
> changing the signedness but not the width of an integer.
> 
> It's likely this checking isn't on by default, but that I
> enabled it, and that the errors/warnings are true,
>  even though my enabling might have been by hacking the
> #idefs instead of the configure command.
> 
> 
> I assume upgrading to gcc 4.5 is considered fairly
> unilaterly uncontroversially good.
> I chose working on it for that reason.
> 
> 
> D.1401 = TextClass__GetChar (M3_Bd56fi_t.11,
> M3_Cwb5VA_i.10);
> 
> cm3cg: warning: type mismatch in indirect reference
> word_64
> 
> <unnamed type>
> 
> D.1408 = *D.1407;
> 
> cm3cg: warning: verify_gimple failed
> ../src/cm3/TextUtils.m3: In function
> 'TextUtils__SkipRight':
> cm3cg: warning: invalid conversion in gimple call
> word_8
> 
> word_64
> 
> D.1481 = TextClass__GetChar (M3_Bd56fi_t.36, D.1479);
> 
> cm3cg: warning: type mismatch in indirect reference
> word_64
> 
> <unnamed type>
> 
> D.1488 = *D.1487;
> 
> cm3cg: warning: verify_gimple failed
> ../src/cm3/TextUtils.m3: In function
> 'TextUtils__Compress':
> cm3cg: warning: invalid conversion in gimple call
> word_8
> 
> word_64
> 
> D.1553 = TextClass__GetChar (M3_Bd56fi_t.59,
> M3_Cwb5VA_i.58);
> 
> cm3cg: warning: type mismatch in indirect reference
> word_64
> 
> <unnamed type>
> 
> D.1560 = *D.1559;
> 
> cm3cg: warning: invalid conversion in gimple call
> word_8
> 
> word_64
> 
> D.1591 = TextClass__GetChar (M3_Bd56fi_t.67, D.1589);
> 
> cm3cg: warning: type mismatch in indirect reference
> word_64
> 
> <unnamed type>
> 
> D.1598 = *D.1597;
> 
> cm3cg: warning: verify_gimple failed
> ../src/cm3/TextUtils.m3: In function
> 'TextUtils__SubstChar':
> cm3cg: warning: invalid conversion in gimple call
> word_8
> 
> word_64
> 
> D.1683 = TextClass__GetChar (M3_Bd56fi_t.99, D.1681);
> 
> cm3cg: warning: type mismatch in binary expression
> word_64
> 
> int_64
> 
> int_64
> 
> D.1701 = D.1700 & 1;
> 
> cm3cg: warning: type mismatch in binary expression
> word_64
> 
> int_64
> 
> int_64
> 
> 
> 
> 
> 
> 
>     
>         
>           
>   


      


From jay.krell at cornell.edu  Mon Jun 28 10:08:13 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 28 Jun 2010 08:08:13 +0000
Subject: [M3devel] gcc 4.5 status
In-Reply-To: <619968.30896.qm@web23605.mail.ird.yahoo.com>
References: <COL101-W56446A25BC09D1C25A5AD9E6CA0@phx.gbl>,
	<619968.30896.qm@web23605.mail.ird.yahoo.com>
Message-ID: <COL101-W395F243446FE921432E2E3E6CA0@phx.gbl>


Daniel, I'm afraid I generally don't understand much that you say.
True, m3tools/m3tk should ideally follow the compiler's definition of ADR.
Moving to gcc 4.5 has nothing to do with changing the meaning of ADR. Granted, I jump around a bit.

current/old ADR return ADDRESS, which is silently assignable to any UNTRACED REF type.
new ADR(t) returns UNTRACED REF t.

Consider C.
In C, void* is assignable to any pointer type. (not so in C++)
In C, &T returns T*, not void*.
So &T is NOT assignable to any pointer type, only T* and void*.

The idea here would be elevate unsafe Modula-3 to C's level of safety.
Instead of being even less safe.

Despite the lack of safety, a certain amount of static checking is a good idea.


?- Jay

----------------------------------------
> Date: Mon, 28 Jun 2010 02:37:11 +0000
> From: dabenavidesd at yahoo.es
> To: m3devel at elegosoft.com; jay.krell at cornell.edu
> Subject: Re: [M3devel] gcc 4.5 status
>
> Hi all:
> please let me investigate before you make the simple changes you are trying because as I understand the type of the ADR operator might be of an unsafe module but that doesn't mean you can hack it to do your program better compile (that would be like use an ill behaved program to make "well" behaved ones). I mean is good to discard that the type system (the set of sound type rules that make a program compile run and if safely guarded do its work flawlessly, that is, the set of safe and well behaved programs without ill behaved in there) is not "hacked" hard coded to expect the type of ADR to be ADDRESS instead of the UNTRACED REF T.
> I would like to be pointed out the way you are trying to solve the initial problem, I mean it is easy to see that ADR operator might return ADDRESS but probably not in all cases (programs) to be UNTRACED REF T though your programs show yes, changes reveal there is a problem indeed with current tree.
> Anyway this needs to confirm there is a change in the type rules a check of original m3tk as before had happened with the new types or type introductions rules.
> I might need explanations about your rationale behind the new ADR type so if you don't mind just tell me what are the reasons to do the mentioned changes if you don't mind. I know there are this emails:
> https://mail.elegosoft.com/pipermail/m3devel/2010-June/007241.html
> and
> https://mail.elegosoft.com/pipermail/m3devel/2010-June/007249.html
> BTW are the m3-sys/cm3/m3test shipped to the source browser in Elego web pages, I might need to check this test cases before the actual code, see:
> http://opencm3.net/doc/help/gen_html/INDEX.html
> If not we better make some ones testing UNSAFE features if they aren't shipped and/or already done (just to proof well behaved programs properties in UNSAFE modules to see if they actually work and if not why do they fail, I know there might be less panic with them but is better to have them than nothing, we might make some directory of them if somebody can point out where I can put then I have Elego ssh keys so I can see what I can do about it).
>
> Thanks for your attention
>
>
> --- El dom, 27/6/10, Jay K  escribi?:
>
>> De: Jay K 
>> Asunto: [M3devel] gcc 4.5 status
>> Para: "m3devel" 
>> Fecha: domingo, 27 de junio, 2010 20:39
>>
>> Gcc 4.5 complains about a few similar aspects of our
>> trees.
>> These would all be errors but I hacked the gcc source to
>> make them warnings.
>>
>>
>> Running cm3 build with gcc 4.5 crashes early in sysutils
>> => PathReprCommon => Text.Length.
>>
>>
>> I think I'll try to fix up these type issues first.
>> You can see they aren't all that interesting, either
>> widening an unsigned integer or
>> changing the signedness but not the width of an integer.
>>
>> It's likely this checking isn't on by default, but that I
>> enabled it, and that the errors/warnings are true,
>> even though my enabling might have been by hacking the
>> #idefs instead of the configure command.
>>
>>
>> I assume upgrading to gcc 4.5 is considered fairly
>> unilaterly uncontroversially good.
>> I chose working on it for that reason.
>>
>>
>> D.1401 = TextClass__GetChar (M3_Bd56fi_t.11,
>> M3_Cwb5VA_i.10);
>>
>> cm3cg: warning: type mismatch in indirect reference
>> word_64
>>
>> 
>>
>> D.1408 = *D.1407;
>>
>> cm3cg: warning: verify_gimple failed
>> ../src/cm3/TextUtils.m3: In function
>> 'TextUtils__SkipRight':
>> cm3cg: warning: invalid conversion in gimple call
>> word_8
>>
>> word_64
>>
>> D.1481 = TextClass__GetChar (M3_Bd56fi_t.36, D.1479);
>>
>> cm3cg: warning: type mismatch in indirect reference
>> word_64
>>
>> 
>>
>> D.1488 = *D.1487;
>>
>> cm3cg: warning: verify_gimple failed
>> ../src/cm3/TextUtils.m3: In function
>> 'TextUtils__Compress':
>> cm3cg: warning: invalid conversion in gimple call
>> word_8
>>
>> word_64
>>
>> D.1553 = TextClass__GetChar (M3_Bd56fi_t.59,
>> M3_Cwb5VA_i.58);
>>
>> cm3cg: warning: type mismatch in indirect reference
>> word_64
>>
>> 
>>
>> D.1560 = *D.1559;
>>
>> cm3cg: warning: invalid conversion in gimple call
>> word_8
>>
>> word_64
>>
>> D.1591 = TextClass__GetChar (M3_Bd56fi_t.67, D.1589);
>>
>> cm3cg: warning: type mismatch in indirect reference
>> word_64
>>
>> 
>>
>> D.1598 = *D.1597;
>>
>> cm3cg: warning: verify_gimple failed
>> ../src/cm3/TextUtils.m3: In function
>> 'TextUtils__SubstChar':
>> cm3cg: warning: invalid conversion in gimple call
>> word_8
>>
>> word_64
>>
>> D.1683 = TextClass__GetChar (M3_Bd56fi_t.99, D.1681);
>>
>> cm3cg: warning: type mismatch in binary expression
>> word_64
>>
>> int_64
>>
>> int_64
>>
>> D.1701 = D.1700 & 1;
>>
>> cm3cg: warning: type mismatch in binary expression
>> word_64
>>
>> int_64
>>
>> int_64
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
 		 	   		  

From dabenavidesd at yahoo.es  Mon Jun 28 13:31:36 2010
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Mon, 28 Jun 2010 11:31:36 +0000 (GMT)
Subject: [M3devel] gcc 4.5 status
In-Reply-To: <COL101-W395F243446FE921432E2E3E6CA0@phx.gbl>
Message-ID: <760071.93937.qm@web23605.mail.ird.yahoo.com>

Hi:
ok, here is a good reference of type systems by Luca Cardelli, it is sort of familiar language with better conceptualization
http://lucacardelli.name/Papers/TypeSystems.pdf
Hope it helps and thanks for the answer let me know if the above paper is a proper clarification (I think it is, specially pages 1-4).
Thanks for the info, hope it helps 

--- El lun, 28/6/10, Jay K <jay.krell at cornell.edu> escribi?:

> De: Jay K <jay.krell at cornell.edu>
> Asunto: RE: [M3devel] gcc 4.5 status
> Para: "Daniel (M3)" <dabenavidesd at yahoo.es>, "m3devel" <m3devel at elegosoft.com>
> Fecha: lunes, 28 de junio, 2010 03:08
> 
> Daniel, I'm afraid I generally don't understand much that
> you say.
> True, m3tools/m3tk should ideally follow the compiler's
> definition of ADR.
> Moving to gcc 4.5 has nothing to do with changing the
> meaning of ADR. Granted, I jump around a bit.
> 
> current/old ADR return ADDRESS, which is silently
> assignable to any UNTRACED REF type.
> new ADR(t) returns UNTRACED REF t.
> 
> Consider C.
> In C, void* is assignable to any pointer type. (not so in
> C++)
> In C, &T returns T*, not void*.
> So &T is NOT assignable to any pointer type, only T*
> and void*.
> 
> The idea here would be elevate unsafe Modula-3 to C's level
> of safety.
> Instead of being even less safe.
> 
> Despite the lack of safety, a certain amount of static
> checking is a good idea.
> 
> 
>  - Jay
> 
> ----------------------------------------
> > Date: Mon, 28 Jun 2010 02:37:11 +0000
> > From: dabenavidesd at yahoo.es
> > To: m3devel at elegosoft.com;
> jay.krell at cornell.edu
> > Subject: Re: [M3devel] gcc 4.5 status
> >
> > Hi all:
> > please let me investigate before you make the simple
> changes you are trying because as I understand the type of
> the ADR operator might be of an unsafe module but that
> doesn't mean you can hack it to do your program better
> compile (that would be like use an ill behaved program to
> make "well" behaved ones). I mean is good to discard that
> the type system (the set of sound type rules that make a
> program compile run and if safely guarded do its work
> flawlessly, that is, the set of safe and well behaved
> programs without ill behaved in there) is not "hacked" hard
> coded to expect the type of ADR to be ADDRESS instead of the
> UNTRACED REF T.
> > I would like to be pointed out the way you are trying
> to solve the initial problem, I mean it is easy to see that
> ADR operator might return ADDRESS but probably not in all
> cases (programs) to be UNTRACED REF T though your programs
> show yes, changes reveal there is a problem indeed with
> current tree.
> > Anyway this needs to confirm there is a change in the
> type rules a check of original m3tk as before had happened
> with the new types or type introductions rules.
> > I might need explanations about your rationale behind
> the new ADR type so if you don't mind just tell me what are
> the reasons to do the mentioned changes if you don't mind. I
> know there are this emails:
> > https://mail.elegosoft.com/pipermail/m3devel/2010-June/007241.html
> > and
> > https://mail.elegosoft.com/pipermail/m3devel/2010-June/007249.html
> > BTW are the m3-sys/cm3/m3test shipped to the source
> browser in Elego web pages, I might need to check this test
> cases before the actual code, see:
> > http://opencm3.net/doc/help/gen_html/INDEX.html
> > If not we better make some ones testing UNSAFE
> features if they aren't shipped and/or already done (just to
> proof well behaved programs properties in UNSAFE modules to
> see if they actually work and if not why do they fail, I
> know there might be less panic with them but is better to
> have them than nothing, we might make some directory of them
> if somebody can point out where I can put then I have Elego
> ssh keys so I can see what I can do about it).
> >
> > Thanks for your attention
> >
> >
> > --- El dom, 27/6/10, Jay K  escribi?:
> >
> >> De: Jay K 
> >> Asunto: [M3devel] gcc 4.5 status
> >> Para: "m3devel" 
> >> Fecha: domingo, 27 de junio, 2010 20:39
> >>
> >> Gcc 4.5 complains about a few similar aspects of
> our
> >> trees.
> >> These would all be errors but I hacked the gcc
> source to
> >> make them warnings.
> >>
> >>
> >> Running cm3 build with gcc 4.5 crashes early in
> sysutils
> >> => PathReprCommon => Text.Length.
> >>
> >>
> >> I think I'll try to fix up these type issues
> first.
> >> You can see they aren't all that interesting,
> either
> >> widening an unsigned integer or
> >> changing the signedness but not the width of an
> integer.
> >>
> >> It's likely this checking isn't on by default, but
> that I
> >> enabled it, and that the errors/warnings are
> true,
> >> even though my enabling might have been by hacking
> the
> >> #idefs instead of the configure command.
> >>
> >>
> >> I assume upgrading to gcc 4.5 is considered
> fairly
> >> unilaterly uncontroversially good.
> >> I chose working on it for that reason.
> >>
> >>
> >> D.1401 = TextClass__GetChar (M3_Bd56fi_t.11,
> >> M3_Cwb5VA_i.10);
> >>
> >> cm3cg: warning: type mismatch in indirect
> reference
> >> word_64
> >>
> >> 
> >>
> >> D.1408 = *D.1407;
> >>
> >> cm3cg: warning: verify_gimple failed
> >> ../src/cm3/TextUtils.m3: In function
> >> 'TextUtils__SkipRight':
> >> cm3cg: warning: invalid conversion in gimple call
> >> word_8
> >>
> >> word_64
> >>
> >> D.1481 = TextClass__GetChar (M3_Bd56fi_t.36,
> D.1479);
> >>
> >> cm3cg: warning: type mismatch in indirect
> reference
> >> word_64
> >>
> >> 
> >>
> >> D.1488 = *D.1487;
> >>
> >> cm3cg: warning: verify_gimple failed
> >> ../src/cm3/TextUtils.m3: In function
> >> 'TextUtils__Compress':
> >> cm3cg: warning: invalid conversion in gimple call
> >> word_8
> >>
> >> word_64
> >>
> >> D.1553 = TextClass__GetChar (M3_Bd56fi_t.59,
> >> M3_Cwb5VA_i.58);
> >>
> >> cm3cg: warning: type mismatch in indirect
> reference
> >> word_64
> >>
> >> 
> >>
> >> D.1560 = *D.1559;
> >>
> >> cm3cg: warning: invalid conversion in gimple call
> >> word_8
> >>
> >> word_64
> >>
> >> D.1591 = TextClass__GetChar (M3_Bd56fi_t.67,
> D.1589);
> >>
> >> cm3cg: warning: type mismatch in indirect
> reference
> >> word_64
> >>
> >> 
> >>
> >> D.1598 = *D.1597;
> >>
> >> cm3cg: warning: verify_gimple failed
> >> ../src/cm3/TextUtils.m3: In function
> >> 'TextUtils__SubstChar':
> >> cm3cg: warning: invalid conversion in gimple call
> >> word_8
> >>
> >> word_64
> >>
> >> D.1683 = TextClass__GetChar (M3_Bd56fi_t.99,
> D.1681);
> >>
> >> cm3cg: warning: type mismatch in binary
> expression
> >> word_64
> >>
> >> int_64
> >>
> >> int_64
> >>
> >> D.1701 = D.1700 & 1;
> >>
> >> cm3cg: warning: type mismatch in binary
> expression
> >> word_64
> >>
> >> int_64
> >>
> >> int_64
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
>     
>         
>           
>   


      


From jay.krell at cornell.edu  Mon Jun 28 14:08:47 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 28 Jun 2010 12:08:47 +0000
Subject: [M3devel] "the tree problems"
Message-ID: <COL101-W50F7EF3F8B51097C14CDF9E6CA0@phx.gbl>


The "tree problems" exist with gcc 4.3 also.
I'd like to clear these up ahead of most other work.
? Enable configure -enable-checking=something unconditionally.

There a few. Some are more trivial than others.

Here is a start that I'm testing:
It can be broken into two parts, "bit operations (and/or/xor/not)" and index_address.

Index: parse.c
===================================================================
RCS file: /usr/cvs/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c,v
retrieving revision 1.201
diff -u -5 -r1.201 parse.c
--- parse.c??? 27 Jun 2010 14:09:32 -0000??? 1.201
+++ parse.c??? 28 Jun 2010 12:04:49 -0000
@@ -4404,41 +4404,43 @@
?static void
?m3cg_not (void)
?{
?? MTYPE (t);
?
-? EXPR_REF (-1) = m3_build1 (BIT_NOT_EXPR, m3_unsigned_type (t),
-???????????????????????????? EXPR_REF (-1));
+? EXPR_REF (-1) = m3_build1 (BIT_NOT_EXPR, t, m3_cast (t, EXPR_REF (-1)));
?}
?
?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_REF (-2) = m3_build2 (BIT_AND_EXPR, t,
+???????????????????????????? m3_cast (t, EXPR_REF (-2)),
+???????????????????????????? m3_cast (t, EXPR_REF (-1)));
?? EXPR_POP ();
?}
?
?static void
?m3cg_or (void)
?{
?? MTYPE (t);
?
-? EXPR_REF (-2) = m3_build2 (BIT_IOR_EXPR, m3_unsigned_type (t),
-???????????????????????????? EXPR_REF (-2), EXPR_REF (-1));
+? EXPR_REF (-2) = m3_build2 (BIT_IOR_EXPR, t,
+???????????????????????????? m3_cast (t, EXPR_REF (-2)),
+???????????????????????????? m3_cast (t, EXPR_REF (-1)));
?? EXPR_POP ();
?}
?
?static void
?m3cg_xor (void)
?{
?? MTYPE (t);
?
-? EXPR_REF (-2) = m3_build2 (BIT_XOR_EXPR, m3_unsigned_type (t),
-???????????????????????????? EXPR_REF (-2), EXPR_REF (-1));
+? EXPR_REF (-2) = m3_build2 (BIT_XOR_EXPR, t,
+???????????????????????????? m3_cast (t, EXPR_REF (-2)),
+???????????????????????????? m3_cast (t, EXPR_REF (-1)));
?? EXPR_POP ();
?}
?
?static void
?m3cg_shift (void)
@@ -4972,28 +4974,29 @@
?}
?
?static void
?m3cg_index_address (void)
?{
-? enum tree_code plus = (GCC45 ? POINTER_PLUS_EXPR : PLUS_EXPR);
-? tree a = { 0 };
?? MTYPE2?? (t, T);
-? BYTESIZE (n);
+? BYTESIZE (bits);
+? long bytes = bits / BITS_PER_UNIT;
+? bool signd = IS_INTEGER_TYPE_TREE(t);? 
+? tree a = (signd ? ssize_int (bytes) : ssize_int (bytes));
?
?? if (option_vars_trace)
-??? fprintf(stderr, "? index address n:0x%lx n_bytes:0x%lx type:%s\n",
-??????????? n, n / BITS_PER_UNIT, m3cg_typename(T));
+??? fprintf(stderr, "? index address n_bytes:0x%lx type:%s\n",
+??????????? bytes, m3cg_typename(T));
?
-? a = m3_build2 (MULT_EXPR, t, EXPR_REF (-1), size_int (n / BITS_PER_UNIT));
-? if (GCC45)
-? {
-??? gcc_assert(IS_INTEGER_TYPE_TREE(t) || IS_WORD_TYPE_TREE(t));
-??? if (IS_INTEGER_TYPE_TREE(t))
-????? a = m3_cast(ssizetype, a);
-??? a = m3_cast(sizetype, a);
-? }
-? EXPR_REF (-2) = m3_build2 (plus, t_addr, m3_cast (t_addr, EXPR_REF (-2)), a);
+? gcc_assert(signd || IS_WORD_TYPE_TREE(t));
+? gcc_assert(bits>= 0);
+? gcc_assert(bytes>= 0);
+? 
+? a = m3_build2 (MULT_EXPR, t, m3_cast(t, EXPR_REF (-1)), a);
+? if (signd)
+??? a = m3_cast(ssizetype, a);
+? a = m3_cast(sizetype, a);
+? EXPR_REF (-2) = m3_build2 (POINTER_PLUS_EXPR, t_addr, m3_cast (t_addr, EXPR_REF (-2)), a);
?? EXPR_POP ();
?}
?

alternatively we could try like:


+? EXPR_REF (-2) = m3_build2 (BIT_AND_EXPR, t,

+???????????????????????????? EXPR_REF (-2),

+???????????????????????????? EXPR_REF (-1));



which is nicer, if it works.


Though I believe the more "forceful" (cast-ful) interpretation is what Tony described a while ago, in describing what the NT/x86 backend does wrong.
These "bit" are fairly uniquely uninteresting, since they don't vary for signed vs. unsigned.


There are more problems in shifting, where I'm treading more carefully, since right shift's and "extract" are affected by signed vs. unsigned.


? - Jay
 		 	   		  

From rcolebur at SCIRES.COM  Mon Jun 28 21:26:18 2010
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Mon, 28 Jun 2010 15:26:18 -0400
Subject: [M3devel] m3core compilation errors on HEAD branch
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E62F8D76D1@ATLEX02-SRV.SCIRES.LOCAL>

Jay:

I'm getting a bunch of compile errors on m3core package.

These are all from various "C" files, not modula-3.

Regards,
Randy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100628/b04b23d6/attachment.html>

From jay.krell at cornell.edu  Mon Jun 28 22:04:41 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 28 Jun 2010 20:04:41 +0000
Subject: [M3devel] m3core compilation errors on HEAD branch
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E62F8D76D1@ATLEX02-SRV.SCIRES.LOCAL>
References: <D67F02DDC62F7545A6B84C285F88F3E62F8D76D1@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <COL101-W482011876B9BE028B81FB4E6CA0@phx.gbl>


I fixed hand.c.
I'll look at the rest later.

?- Jay


________________________________
> From: rcolebur at SCIRES.COM
> To: m3devel at elegosoft.com
> Date: Mon, 28 Jun 2010 15:26:18 -0400
> Subject: [M3devel] m3core compilation errors on HEAD branch
>
> Jay:
>
> I?m getting a bunch of compile errors on m3core
> package.
>
> These are all from various ?C? files, not
> modula-3.
>
> Regards,

> Randy
>
>
 		 	   		  

From jay.krell at cornell.edu  Mon Jun 28 22:49:53 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 28 Jun 2010 20:49:53 +0000
Subject: [M3devel] windows msi, file ownership
Message-ID: <COL101-W4607C2990464A09FC2013DE6CA0@phx.gbl>


I'm using the msi and I noticed the files are owned by nt authority\system.
Kind of annoying. A little harder to replace than "normal".
Probably should be changed to administrator.

?- Jay




 		 	   		  

From jay.krell at cornell.edu  Tue Jun 29 11:25:37 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 29 Jun 2010 09:25:37 +0000
Subject: [M3devel] gcc tree checking
Message-ID: <COL101-W5454413A2730ED2963AFD1E6CB0@phx.gbl>


One of the (series of) tree type mismatches is like:


m3cgc1: warning: verify_gimple failed
?TextUtils__TextExtras_FindCharSet
../src/cm3/TextUtils.m3: In function 'TextUtils__TextExtras_FindCharSet':
m3cgc1: warning: invalid conversion in gimple call
word_8
word_64
D.3538 = Text__GetChar (M3_Bd56fi_t, M3_Cwb5VA_i.322);

GetChar returns word_8 but the call is asserted to return word_64.

I believe this comes from:

PROCEDURE EmitCall (t: T) =
? VAR result := ProcType.CGResult (t.signature);
? BEGIN
??? IF (t.impl_peer # NIL) THEN t := t.impl_peer; END;
??? CG.Call_direct (t.cg_proc, result);
??? EVAL Marker.EmitExceptionTest (t.signature, need_value := FALSE);
? END EmitCall;

PROCEDURE CGResult (t: Type.T): CG.Type =
? VAR p := Reduce (t);
? BEGIN
??? IF (p = NIL) OR (p.result = NIL) THEN
????? RETURN CG.Type.Void;
??? ELSIF NOT LargeResult (p.result) THEN
????? RETURN Type.CGType (p.result, in_memory := TRUE);
????? (*** 2/27/96 WKK:? in_memory = TRUE => so that Win32 code generator
?????????? can convert register return values to their full 32-bit width! ***)
??? ELSIF p.callConv.standard_structs THEN
????? RETURN CG.Type.Void;
??? ELSE
????? RETURN CG.Type.Struct;
??? END;
? END CGResult;

PROCEDURE CGType (t: T;? in_memory: BOOLEAN): CG.Type =
? BEGIN
??? t := Check (t);
??? IF (in_memory)
????? THEN RETURN t.info.mem_type;
????? ELSE RETURN t.info.stk_type;
??? END;
? END CGType;


I think in_memory needs to be FALSE, and the Win32 codegen should
I believe act the same, but I can check/fix that either way.

I'm thinking maybe I should make a test case that thoroughly exercise
each m3cg opcode and verifies that the output assembly is unchanged,
for a few architectures.

I believe this area really should be fixed, but almost must be very careful.. (like in everything..).

?- Jay

 		 	   		  

From jay.krell at cornell.edu  Tue Jun 29 14:17:27 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 29 Jun 2010 12:17:27 +0000
Subject: [M3devel] gcc tree checking
In-Reply-To: <COL101-W5454413A2730ED2963AFD1E6CB0@phx.gbl>
References: <COL101-W5454413A2730ED2963AFD1E6CB0@phx.gbl>
Message-ID: <COL101-W3C343C13C41DE503EDAE8E6CB0@phx.gbl>


Changing in_memory breaks cm3.
The fix is therefore probably in parse.c to cast or convert, similar to what m3back does.

?- Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Subject: gcc tree checking
> Date: Tue, 29 Jun 2010 09:25:37 +0000
>
>
> One of the (series of) tree type mismatches is like:
>
>
> m3cgc1: warning: verify_gimple failed
>  TextUtils__TextExtras_FindCharSet
> ../src/cm3/TextUtils.m3: In function 'TextUtils__TextExtras_FindCharSet':
> m3cgc1: warning: invalid conversion in gimple call
> word_8
> word_64
> D.3538 = Text__GetChar (M3_Bd56fi_t, M3_Cwb5VA_i.322);
>
> GetChar returns word_8 but the call is asserted to return word_64.
>
> I believe this comes from:
>
> PROCEDURE EmitCall (t: T) =
>   VAR result := ProcType.CGResult (t.signature);
>   BEGIN
>     IF (t.impl_peer # NIL) THEN t := t.impl_peer; END;
>     CG.Call_direct (t.cg_proc, result);
>     EVAL Marker.EmitExceptionTest (t.signature, need_value := FALSE);
>   END EmitCall;
>
> PROCEDURE CGResult (t: Type.T): CG.Type =
>   VAR p := Reduce (t);
>   BEGIN
>     IF (p = NIL) OR (p.result = NIL) THEN
>       RETURN CG.Type.Void;
>     ELSIF NOT LargeResult (p.result) THEN
>       RETURN Type.CGType (p.result, in_memory := TRUE);
>       (*** 2/27/96 WKK:  in_memory = TRUE => so that Win32 code generator
>            can convert register return values to their full 32-bit width! ***)
>     ELSIF p.callConv.standard_structs THEN
>       RETURN CG.Type.Void;
>     ELSE
>       RETURN CG.Type.Struct;
>     END;
>   END CGResult;
>
> PROCEDURE CGType (t: T;  in_memory: BOOLEAN): CG.Type =
>   BEGIN
>     t := Check (t);
>     IF (in_memory)
>       THEN RETURN t.info.mem_type;
>       ELSE RETURN t.info.stk_type;
>     END;
>   END CGType;
>
>
> I think in_memory needs to be FALSE, and the Win32 codegen should
> I believe act the same, but I can check/fix that either way.
>
> I'm thinking maybe I should make a test case that thoroughly exercise
> each m3cg opcode and verifies that the output assembly is unchanged,
> for a few architectures.
>
> I believe this area really should be fixed, but almost must be very careful.. (like in everything..).
>
>  - Jay
>
>
 		 	   		  

From rodney_bates at lcwb.coop  Tue Jun 29 19:59:01 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Tue, 29 Jun 2010 12:59:01 -0500
Subject: [M3devel] gcc tree checking
In-Reply-To: <COL101-W5454413A2730ED2963AFD1E6CB0@phx.gbl>
References: <COL101-W5454413A2730ED2963AFD1E6CB0@phx.gbl>
Message-ID: <4C2A3465.1080308@lcwb.coop>



Jay K wrote:
> One of the (series of) tree type mismatches is like:
> 
> 
> m3cgc1: warning: verify_gimple failed
>  TextUtils__TextExtras_FindCharSet
> ../src/cm3/TextUtils.m3: In function 'TextUtils__TextExtras_FindCharSet':
> m3cgc1: warning: invalid conversion in gimple call
> word_8
> word_64
> D.3538 = Text__GetChar (M3_Bd56fi_t, M3_Cwb5VA_i.322);
> 
> GetChar returns word_8 but the call is asserted to return word_64.
> 
> I believe this comes from:
> 
> PROCEDURE EmitCall (t: T) =
>   VAR result := ProcType.CGResult (t.signature);
>   BEGIN
>     IF (t.impl_peer # NIL) THEN t := t.impl_peer; END;
>     CG.Call_direct (t.cg_proc, result);
>     EVAL Marker.EmitExceptionTest (t.signature, need_value := FALSE);
>   END EmitCall;
> 
> PROCEDURE CGResult (t: Type.T): CG.Type =
>   VAR p := Reduce (t);
>   BEGIN
>     IF (p = NIL) OR (p.result = NIL) THEN
>       RETURN CG.Type.Void;
>     ELSIF NOT LargeResult (p.result) THEN
>       RETURN Type.CGType (p.result, in_memory := TRUE);
>       (*** 2/27/96 WKK:  in_memory = TRUE => so that Win32 code generator
>            can convert register return values to their full 32-bit width! ***)
>     ELSIF p.callConv.standard_structs THEN
>       RETURN CG.Type.Void;
>     ELSE
>       RETURN CG.Type.Struct;
>     END;
>   END CGResult;
> 
> PROCEDURE CGType (t: T;  in_memory: BOOLEAN): CG.Type =
>   BEGIN
>     t := Check (t);
>     IF (in_memory)
>       THEN RETURN t.info.mem_type;
>       ELSE RETURN t.info.stk_type;
>     END;
>   END CGType;
> 
> 
> I think in_memory needs to be FALSE, and the Win32 codegen should
> I believe act the same, but I can check/fix that either way.
> 
> I'm thinking maybe I should make a test case that thoroughly exercise
> each m3cg opcode and verifies that the output assembly is unchanged,
> for a few architectures.

This is a very good idea.  It may be a lot of work, but I have found
many times over that regression testing tools of this kind pay for
themselves in the (not so) long run.  Some of the changes found will
be legitimate, but that's a lot easier to verify than to chase obscure
bugs from end symptoms.

> 
> I believe this area really should be fixed, but almost must be very careful.. (like in everything..).
> 
>  - Jay
> 
>  		 	   		  


From jay.krell at cornell.edu  Tue Jun 29 22:28:53 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 29 Jun 2010 20:28:53 +0000
Subject: [M3devel] gcc tree checking
In-Reply-To: <4C2A3465.1080308@lcwb.coop>
References: <COL101-W5454413A2730ED2963AFD1E6CB0@phx.gbl>,
	<4C2A3465.1080308@lcwb.coop>
Message-ID: <COL101-W622BF57F65B4D5A9A22DF2E6CB0@phx.gbl>


I staked a claim, put in the start of something and made it work.
But then got lazy. I've been using m3core as my test.
Compiling all of it with cm3 -keep.
mv AMD64_DARWIN AMD64_DARWIN.1
make a compiler change
cm3 -keep again
diff -u AMD64_DARWIN.1 AMD64_DARWIN

And then often recompiling compiler with itself to push the change further.
?Hoping the compiler itself gets pretty good coverage, which has proven
? right and wrong through the years.

The test I put in can still be developed further.

?- Jay


----------------------------------------
> Date: Tue, 29 Jun 2010 12:59:01 -0500
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] gcc tree checking
>
>
>
> Jay K wrote:
>> One of the (series of) tree type mismatches is like:
>>
>>
>> m3cgc1: warning: verify_gimple failed
>> TextUtils__TextExtras_FindCharSet
>> ../src/cm3/TextUtils.m3: In function 'TextUtils__TextExtras_FindCharSet':
>> m3cgc1: warning: invalid conversion in gimple call
>> word_8
>> word_64
>> D.3538 = Text__GetChar (M3_Bd56fi_t, M3_Cwb5VA_i.322);
>>
>> GetChar returns word_8 but the call is asserted to return word_64.
>>
>> I believe this comes from:
>>
>> PROCEDURE EmitCall (t: T) =
>> VAR result := ProcType.CGResult (t.signature);
>> BEGIN
>> IF (t.impl_peer # NIL) THEN t := t.impl_peer; END;
>> CG.Call_direct (t.cg_proc, result);
>> EVAL Marker.EmitExceptionTest (t.signature, need_value := FALSE);
>> END EmitCall;
>>
>> PROCEDURE CGResult (t: Type.T): CG.Type =
>> VAR p := Reduce (t);
>> BEGIN
>> IF (p = NIL) OR (p.result = NIL) THEN
>> RETURN CG.Type.Void;
>> ELSIF NOT LargeResult (p.result) THEN
>> RETURN Type.CGType (p.result, in_memory := TRUE);
>> (*** 2/27/96 WKK: in_memory = TRUE => so that Win32 code generator
>> can convert register return values to their full 32-bit width! ***)
>> ELSIF p.callConv.standard_structs THEN
>> RETURN CG.Type.Void;
>> ELSE
>> RETURN CG.Type.Struct;
>> END;
>> END CGResult;
>>
>> PROCEDURE CGType (t: T; in_memory: BOOLEAN): CG.Type =
>> BEGIN
>> t := Check (t);
>> IF (in_memory)
>> THEN RETURN t.info.mem_type;
>> ELSE RETURN t.info.stk_type;
>> END;
>> END CGType;
>>
>>
>> I think in_memory needs to be FALSE, and the Win32 codegen should
>> I believe act the same, but I can check/fix that either way.
>>
>> I'm thinking maybe I should make a test case that thoroughly exercise
>> each m3cg opcode and verifies that the output assembly is unchanged,
>> for a few architectures.
>
> This is a very good idea. It may be a lot of work, but I have found
> many times over that regression testing tools of this kind pay for
> themselves in the (not so) long run. Some of the changes found will
> be legitimate, but that's a lot easier to verify than to chase obscure
> bugs from end symptoms.
>
>>
>> I believe this area really should be fixed, but almost must be very careful.. (like in everything..).
>>
>> - Jay
>>
>>
 		 	   		  

From wagner at elegosoft.com  Wed Jun 30 09:06:31 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Wed, 30 Jun 2010 09:06:31 +0200
Subject: [M3devel] gcc tree checking
In-Reply-To: <4C2A3465.1080308@lcwb.coop>
References: <COL101-W5454413A2730ED2963AFD1E6CB0@phx.gbl>
	<4C2A3465.1080308@lcwb.coop>
Message-ID: <20100630090631.10m2uzg52cs40sc8@mail.elegosoft.com>

Quoting "Rodney M. Bates" <rodney_bates at lcwb.coop>:

> Jay K wrote:
[...]
>> I'm thinking maybe I should make a test case that thoroughly exercise
>> each m3cg opcode and verifies that the output assembly is unchanged,
>> for a few architectures.
>
> This is a very good idea.  It may be a lot of work, but I have found
> many times over that regression testing tools of this kind pay for
> themselves in the (not so) long run.  Some of the changes found will
> be legitimate, but that's a lot easier to verify than to chase obscure
> bugs from end symptoms.

I second that. Regression testing for the generated code would be
great and give us much more safefy when changing the compiler.

So anybody who'd like to work in this area is greatly encouraged.

Of course a general easily extensible framework would be nice :-)
Preferrably written in quake and M3.

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  Tue Jun  1 11:03:01 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Tue, 01 Jun 2010 11:03:01 +0200
Subject: [M3devel] OS for CM3
In-Reply-To: <20100522215317.E428D1A2096@async.async.caltech.edu>
References: <20100522215317.E428D1A2096@async.async.caltech.edu>
Message-ID: <20100601110301.g7805qomqskk4wws@mail.elegosoft.com>

Quoting Mika Nystrom <mika at 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?

Do you have simple test programs we could use to regularly measure
the performance of multithreading on different target platforms?

FreeBSD should support scaling via threads, but I've no idea about
actual performance yet.

I've been using FreeBSD/amd64 for about half a year now at home
(due to sudden death of my old hardware) and it's running OK,
except for the occasional suprise after a source upgrade ;-)

I second your feeling of dismay about loss of traditional system
administration conventions... no time to keep up-to-date with
everything.

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  Tue Jun  1 13:16:16 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 1 Jun 2010 11:16:16 +0000
Subject: [M3devel] m3cg_pop checks for side effects on the wrong thing
Message-ID: <COL101-W3186CD99E2045404ED5924E6EF0@phx.gbl>


Tony, I started looking at the effect of fixing the m3cg_pop "bug", where it checks for tree_side_effects on the wrong thing.
? You know -- is it significant? Should it be fixed in release?
In every case I looked at, optimized and not, all the fix did was add unnecessary code.
So I took another step: I tried removing the add_stmt there all together.
I built m3core before and after that, optimized and not.
Again, the code appears to be equivalent either way, just that add_stmt adds unnecessary code.


I'm going to try building the compiler and the rest of the system with this change.
If that works, I think this is an ok change.
? And we can rest easy about release.


?- Jay




 		 	   		  

From jay.krell at cornell.edu  Tue Jun  1 18:00:41 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 1 Jun 2010 16:00:41 +0000
Subject: [M3devel] uninitialized + insert_mn
Message-ID: <COL101-W235ED30E74DF1BC021F7CBE6EF0@phx.gbl>


../src/runtime/common/RTCollector.m3: In function 'RTCollector__CleanOlderRefSanityCheck':
../src/runtime/common/RTCollector.m3:1724: warning: 'M3_EB9wjE_tc' is used uninitialized in this function
../src/runtime/common/RTCollector.m3: In function 'RTCollector__RefSanityCheck':
../src/runtime/common/RTCollector.m3:1702: warning: 'M3_EB9wjE_tc' is used uninitialized in this function


PROCEDURE RefSanityCheck (<*UNUSED*>v: RTHeapMap.Visitor;? cp? : ADDRESS) =
? VAR ref := LOOPHOLE(cp, UNTRACED REF RefReferent)^;
? BEGIN
??? IF ref # NIL THEN
????? VAR
??????? h? := HeaderOf(ref);
??????? tc := h.typecode;
????? BEGIN


It is actually *kind of* true.
The store to tc uses load tc, insert_mn, store tc.


Any idea what to do?
offset=0
count=20


I'm willing to just go without -Wuninitialized, or look into turning it off for any function that uses insert.
Maybe look into what gcc uses -- hey, maybe bitfield refs? Yeah yeah, I'm half serious.
Of course I remember they caused a problem.
Perhaps we can use them, just be sure to twiddle the bit offsets depending on endian?


What I'm really doing is looking into removing the heavy use of volatile.


?- Jay

 		 	   		  

From jay.krell at cornell.edu  Tue Jun  1 18:10:11 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 1 Jun 2010 16:10:11 +0000
Subject: [M3devel] uninitialized + insert_mn
In-Reply-To: <COL101-W235ED30E74DF1BC021F7CBE6EF0@phx.gbl>
References: <COL101-W235ED30E74DF1BC021F7CBE6EF0@phx.gbl>
Message-ID: <COL101-W336E3972DCE285DA3850A7E6EF0@phx.gbl>


I found the lame hack that volatizing whatever store follows an insert_mn works.
If it suffices for the entire tree I'll go with it for now.

?- Jay


----------------------------------------
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu; m3devel at elegosoft.com
> Date: Tue, 1 Jun 2010 16:00:41 +0000
> Subject: [M3devel] uninitialized + insert_mn
>
>
> ../src/runtime/common/RTCollector.m3: In function 'RTCollector__CleanOlderRefSanityCheck':
> ../src/runtime/common/RTCollector.m3:1724: warning: 'M3_EB9wjE_tc' is used uninitialized in this function
> ../src/runtime/common/RTCollector.m3: In function 'RTCollector__RefSanityCheck':
> ../src/runtime/common/RTCollector.m3:1702: warning: 'M3_EB9wjE_tc' is used uninitialized in this function
>
>
> PROCEDURE RefSanityCheck (<*UNUSED*>v: RTHeapMap.Visitor;  cp  : ADDRESS) =
>   VAR ref := LOOPHOLE(cp, UNTRACED REF RefReferent)^;
>   BEGIN
>     IF ref # NIL THEN
>       VAR
>         h  := HeaderOf(ref);
>         tc := h.typecode;
>       BEGIN
>
>
> It is actually *kind of* true.
> The store to tc uses load tc, insert_mn, store tc.
>
>
> Any idea what to do?
> offset=0
> count=20
>
>
> I'm willing to just go without -Wuninitialized, or look into turning it off for any function that uses insert.
> Maybe look into what gcc uses -- hey, maybe bitfield refs? Yeah yeah, I'm half serious.
> Of course I remember they caused a problem.
> Perhaps we can use them, just be sure to twiddle the bit offsets depending on endian?
>
>
> What I'm really doing is looking into removing the heavy use of volatile.
>
>
>  - Jay
>
>
 		 	   		  

From jay.krell at cornell.edu  Tue Jun  1 19:16:46 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 1 Jun 2010 17:16:46 +0000
Subject: [M3devel] reducing use of volatile in backend?
Message-ID: <COL101-W17AA739AA2DE2050C6CCD0E6EF0@phx.gbl>


Tony, would we maybe be better off not using volatile everywhere but
selectively turning off optimizations in m3_post_options?
You know, using volatile probably disables more than necessary?
I'm experimenting with this.

?- Jay




 		 	   		  

From jay.krell at cornell.edu  Tue Jun  1 19:58:50 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 1 Jun 2010 17:58:50 +0000
Subject: [M3devel] optimizer doesn't do much?
Message-ID: <COL101-W32EFB0D6FFF6C0D451CC7FE6EF0@phx.gbl>


Here's a version from cm3cg with lots of optimizations turned on, a few turned off, *and* volatile generally removed:

??? xorl??? %eax, %eax
??? testq??? %rdi, %rdi
??? movq??? %rsi, %rdx
??? je??? L3
??? cmpq??? $-1, (%rdi)
??? movq??? %rdi, %rax
??? jne??? L3
??? movq??? 16(%rdi), %rax
??? movq??? %rax, -16(%rsp)
??? movq??? 8(%rdi), %rax
L3:
??? movq??? -16(%rsp), %r10
??? movq??? %rdx, %rdi
??? movq??? %rax, %r11
??? jmp??? *%r11

Much better!

?- Jay


----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Subject: optimizer doesn't do much?
> Date: Sun, 30 May 2010 18:11:26 +0000
>
>
> 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  Tue Jun  1 21:21:47 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 1 Jun 2010 19:21:47 +0000
Subject: [M3devel] unreachable code
Message-ID: <COL101-W43E6ACB5FD4C86FB00CA6FE6EF0@phx.gbl>


Here's nice stuff the compiler reports:

"../src/misc/stochastic/RandomImprovedMcGill.m3", line 63: warning: unreachable statement
"../src/misc/stochastic/RandomSubtractiveFibo2.m3", line 51: warning: unreachable statement

??? <* ASSERT Word.Size = 32 *>

Probably they just need to use Cstdint.uint32_t and mask sometimes..

?..Jay
 		 	   		  

From hosking at cs.purdue.edu  Tue Jun  1 23:05:30 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Tue, 1 Jun 2010 16:05:30 -0500
Subject: [M3devel] reducing use of volatile in backend?
In-Reply-To: <COL101-W17AA739AA2DE2050C6CCD0E6EF0@phx.gbl>
References: <COL101-W17AA739AA2DE2050C6CCD0E6EF0@phx.gbl>
Message-ID: <AA1F4490-A9C7-4F94-8E03-65A5E9031424@cs.purdue.edu>

We don't want to disable optimisations for types where it makes sense  
to have them. Better to smarten up typebased alias analysis instead so  
we can get rid of volatile properly.

Sent from my iPhone

On Jun 1, 2010, at 12:16 PM, Jay K <jay.krell at cornell.edu> wrote:

>
> Tony, would we maybe be better off not using volatile everywhere but
> selectively turning off optimizations in m3_post_options?
> You know, using volatile probably disables more than necessary?
> I'm experimenting with this.
>
>  - Jay
>
>
>
>
>


From jay.krell at cornell.edu  Tue Jun  1 23:55:31 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 1 Jun 2010 21:55:31 +0000
Subject: [M3devel] reducing use of volatile in backend?
In-Reply-To: <AA1F4490-A9C7-4F94-8E03-65A5E9031424@cs.purdue.edu>
References: <COL101-W17AA739AA2DE2050C6CCD0E6EF0@phx.gbl>,
	<AA1F4490-A9C7-4F94-8E03-65A5E9031424@cs.purdue.edu>
Message-ID: <COL101-W405F0F081CEA577B80A523E6EF0@phx.gbl>


I've had *a lot* of success here the past few hours.
 
 
There is an assert starting up mentor I need to look at, possibly out of data binaries.
  The one in socket.c assert(lossless_socklen || socklen == null || socklen < 1<<30.
 
 
Compiler seems to work.
  Lots of things do break it, so that is something.
 
 
Various gui apps startup.
  Some of the gui apps don't work, but nor did older copies I had -- fours, badbricks, and I think columns, wouldn't take any mouse clicks. I have to test older versions. Could be unrelated.
 
 
 
Here is what I have:
 
  The vast vast majority of optimizations can be enabled.
 
  Nearly all uses of volatile can be removed.
 
  Just a few optimizations "need" to be disabled.
 
In particular:
 I only have volatile remaining:
    on store after insert_mn (special case)
 
    floating point (huh? wierd)
     compile errors without this 
 
    in functions that call setjmp or vfork
      This is very reasonable, but we should try to limit it to not all the variables, only what are accessed after the second return (I'm not sure how that computes for vfork, but for setjmp it makes sense to me.
 
 
    on the load/store in loophole
      compile errors without this; perhaps redundant with the floating point check
 
 
    on load link, else it gets uninitialized warning 
 
 
 
Also I found a likely bug.
In functions that call setjmp/vfork, we volatize already seen parameters and locals, but we don't volatize not yet seen locals (in nested blocks) and temporaries. I fixed that.
 
  
 
 
 The optimizations I disabled, from memory:
 
 
  pre - partial redundancy elimination 
 
 
  fre - full redundancy elimination (these are related) 
    One or both of these causes the compiler to access violate in the optimizer, compiling libm3/Formatter.mc, but otherwise I think they compile m3core and libm3 entirely
 
 
  loop im (induction motion) - caused a compile error in Trestle 
 
  vrp - value range propagation
     This seems to be the biggest problem, no compile errors but "random" runtime malfunction, usually starting up cm3.
 
 
  insn_sched - wierd, caused a compile break
    but insn_sched_after_reload ok
 
 
 That's about it. All the ones with "alias" in them, only like two, I enabled, seemed ok.
  salias and strict_alias. I left strict alias till late in experimentation but really it seems ok.
 
 
I can compile the entire system, though I get lots of warnings about uninitialized variables.
I pass the backend the -Wuninitialized flag.
 
 
I test it out more -- the gui non-interaction, the mentor assert, and test other platforms.
But I think we'll have volatile mostly gone and just a small number of optimizations turned off fairly soon.
We can iterate more on the remaining optimizations.
 
 
Getting good typeinfo would be good so that gdb can debug.
And maybe so that other than stabs works.
 
 
 - Jay




----------------------------------------
> From: hosking at cs.purdue.edu
> To: jay.krell at cornell.edu
> Date: Tue, 1 Jun 2010 16:05:30 -0500
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] reducing use of volatile in backend?
>
> We don't want to disable optimisations for types where it makes sense
> to have them. Better to smarten up typebased alias analysis instead so
> we can get rid of volatile properly.
>
> Sent from my iPhone
>
> On Jun 1, 2010, at 12:16 PM, Jay K wrote:
>
>>
>> Tony, would we maybe be better off not using volatile everywhere but
>> selectively turning off optimizations in m3_post_options?
>> You know, using volatile probably disables more than necessary?
>> I'm experimenting with this.
>>
>> - Jay
>>
>>
>>
>>
>> 		 	   		  

From mika at async.async.caltech.edu  Wed Jun  2 05:52:26 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Tue, 01 Jun 2010 20:52:26 -0700
Subject: [M3devel] [M3commit] CVS Update: cm3
In-Reply-To: <COL101-W3678C92B3A9FA07AD57BF2E6D00@phx.gbl> 
References: <20100601124200.8E42B2474003@birch.elegosoft.com>,
	<E86D485E-C5D5-4B7A-8142-5E0BE31280DD@cs.purdue.edu>
	<COL101-W58EC381F7DE75AC44CFB57E6EF0@phx.gbl>,
	<5458A114-F000-4A90-9998-FD7DF63E06C0@cs.purdue.edu>
	<COL101-W3678C92B3A9FA07AD57BF2E6D00@phx.gbl>
Message-ID: <20100602035226.43C1F1A208F@async.async.caltech.edu>


Safety is important in that it allows you to limit the possible effects
of bugs.  Getting programs bug-free is of course a very difficult problem
no matter what you do.

But no I don't think warnings for uninitialized use of variables is 
something one should do in general in Modula-3.  The safety guarantees
lead to different idioms from in C---not so many compiler warnings
are required to get your code right.  And if you do screw up 
an uninitialized variable, the effect is going to be limited.
Unlike what happens in C, where if you screw up the initialization
of a pointer, for instance, all hell breaks loose.

Your example is contrived.  Usually the code looks like this

VAR
  x : T;
BEGIN
  IF cond1 THEN x := ... END; 
  ...
  IF cond2 THEN (* use x *) END
END

where the programmer knows that cond2 logically implies cond1.

I think the presence of VAR parameter passing makes these sorts of
warnings also less useful in Modula-3.   Is the following OK?

PROCEDURE InitializeIt(VAR a : T);
PROCEUDRE UseIt(VALUE a : T);

VAR x : T;
BEGIN
  InitializeIt(x);
  UseIt(x)
END

I would think your compiler can't prove that x is initialized.  Warning
or not?  I say no: this is actually very reasonable Modula-3 code.
But then do you want a warning for the IF?  It's logically the same.

There's a chapter in 
EWD's Discipline of Programming that deals with the problem in 
detail.  I think he winds up with six different "modes" for variables.

     Mika

Jay K writes:
>
>ok=2C so in C:
>=20
>int F()
>{
>  int i=3B
>  return i=3B
>}
>=20
>should warn or not?
>Prevailing wisdom is definitely.
>Main known exception is code to generate random numbers.
>  I believe this is how Debian broke key generation.
>=20
>=20
>Modula-3:
>=20
>=20
>PROCEDURE F(): INTEGER =3D=20
> VAR i: INTEGER=3B
>BEGIN
>  RETURN i=3B
>END F=3B
>=20
>=20
>Should warn or not?
>Since this identical to the C=2C prevailing wisdom is definitely.
>=20
>=20
>They are=2C I guess=2C "safe"=2C but most likely=2C incorrect.
>=20
>=20
>The compiler may have made "safety" guarantees=2C and they are significant=
>=2C
>but safe is far from correct=2C and however smart the compiler can be to lo=
>ok for correctness issues=2C is also nice.
>=20
>=20
>=20
>(Friend of mine conjectured something like: Safety guarantees have people d=
>eluded. Software will still have plenty of bugs and be plenty difficult to =
>get correct and require plenty of testing. Safety guarantees help=2C but th=
>ey are only a small step toward actual correctness.)
>=20
>=20
>=20
> - Jay
>
>
>----------------------------------------
>> Subject: Re: [M3commit] CVS Update: cm3
>> From: hosking at cs.purdue.edu
>> Date: Tue=2C 1 Jun 2010 20:04:00 -0400
>> CC: jkrell at elego.de=3B m3commit at elegosoft.com
>> To: jay.krell at cornell.edu
>>
>> Sure=2C an INTEGER is a valid value whatever the bits.
>>
>>
>> On 1 Jun 2010=2C at 17:44=2C Jay K wrote:
>>
>>>
>>> Start removing the rampant use of volatile in the backend and these warn=
>ings show up.
>>>
>>> Volatile quashes the uninitialized checks in the backend.
>>>
>>> Is it really ok for an INTEGER to be uninitialized? I realize it contain=
>s an "integer" value=2C as all bit patterns are.
>>>
>>> Some of these really do seem like bugs. Some do not.
>>> I'll try making fault_proc noreturn=2C which should remove some of them.
>>>
>>>
>>> - Jay
>>>
>>>
>>>
>>>
>>> ----------------------------------------
>>>> From: hosking at cs.purdue.edu
>>>> To: jkrell at elego.de
>>>> Date: Tue=2C 1 Jun 2010 16:29:20 -0500
>>>> CC: m3commit at elegosoft.com
>>>> Subject: Re: [M3commit] CVS Update: cm3
>>>>
>>>> This is bogus. The M3 compiler guarantees all variables are initialized=
>.
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On Jun 1=2C 2010=2C at 2:42 PM=2C jkrell at elego.de (Jay Krell) wrote:
>>>>
>>>>> CVSROOT: /usr/cvs
>>>>> Changes by: jkrell at birch. 10/06/01 14:42:00
>>>>>
>>>>> Modified files:
>>>>> cm3/m3-libs/m3core/src/convert/: Convert.m3
>>>>>
>>>>> Log message:
>>>>> initialize locals=3B I get warnings that some not quite all=2C are
>>>>> used uninitialized if I remove the volatile/sideeffects on every
>>>>> load/store in parse.c
>> 		 	   		  =


From jay.krell at cornell.edu  Wed Jun  2 06:50:28 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 2 Jun 2010 04:50:28 +0000
Subject: [M3devel] warning for uninitialized variables?
In-Reply-To: <20100602035226.43C1F1A208F@async.async.caltech.edu>
References: <20100601124200.8E42B2474003@birch.elegosoft.com>, ,
	<E86D485E-C5D5-4B7A-8142-5E0BE31280DD@cs.purdue.edu>,
	<COL101-W58EC381F7DE75AC44CFB57E6EF0@phx.gbl>, ,
	<5458A114-F000-4A90-9998-FD7DF63E06C0@cs.purdue.edu>,
	<COL101-W3678C92B3A9FA07AD57BF2E6D00@phx.gbl>,
	<20100602035226.43C1F1A208F@async.async.caltech.edu>
Message-ID: <COL101-W59770EAA64E52A966D79F3E6D00@phx.gbl>


Wow. You really surprise me Mika.


To warn on this kind of thing, to me, there is no question.


Limting the affects by virtue of being safe isn't much consolation.
The program can easily go down a "safe" but very incorrect path.


There are several forms.
In fact, sometimes the compiler says something "is" used uninitialized.
Sometimes it says "maybe".


In your example, generally, once the address is taken of a variable,
the compiler gives up. Esp. if that address is passed to a function it doesn't "see".


However compilers are getting better.
Windows headers are now annotated with "in" and "out", etc. with
a calculus behind them, not just informal human definitions.


So if you pass something by pointer to "in" you should a warning/error.
If it is "out", ok.


The annotations can even be checked, if you write to something that is "in"
you should get a warning/error.


There are many more warnings in the tree than I have yet looked at.
I've seen a few forms.
Some are because the compiler doesn't know that some functions don't return.
I'll see about improving that. Though I think there's a limit to how good I can manage,
unless we add a <* noreturn *> pragma.


One form is:
a: INTEGER
if cond
? a := 1;
...
if cond
? use a
?

When the compiler is really unsure, it doesn't bother saying anything.


If code is lucky, it gets one smart human to study it carefully when it is first written.
However all code is lucky to have a smart and generally getting smarter compiler
look at it repeatedly.
We shouldn't throw away this tool so rapidly, the gcc optimizer and its data flow analysis.


I grant that by initializing to 0, I haven't necessarily made the code correct either.
But at least it is now consistent.


Even better would be runtime checks that stop if a variable is read before written.


See also the rules in Java and C# that require the compiler to be able to prove
a variable is written before read. Possibly even verifiable at load time.


Other forms look related to going "through" a switch statement with no arms handling the value.
I think I can address that by marking fault_proc as noreturn.


One form apparently in cm3ide would use uninitialized data if presented with a malformed file.
Good software doesn't depend on the well formedness of its input.

There are many more warnings like this in the tree.


My inclination is at least to temporarily hardcode the gcc backend to always optimize,
and always produce these warnings. People can look over them maybe and decide.
Or they can look over my "fixes".


Or I guess if people really really really really prefer, we can always turn off the warnings
and let the code lie. I really think that is the wrong answer.


I have been burned too much by uninitialized locals in C.
I put " = { 0 }" after everything.
Again, that isn't necessarily "correct", but at least the incorrect paths are consistent.
If they don't work and I happen down them, they will guaranteeably not work.


Uninitialized values can be different run to run.
Repeatability and consistency are important.


I'm also nervous about us not taking a hard line on integer overflow.
Overflown math doesn't necessarily lead to array out of bounds soon or ever.
It too can lead to incorrect but safe behavior.


?- Jay


----------------------------------------
> To: jay.krell at cornell.edu
> Date: Tue, 1 Jun 2010 20:52:26 -0700
> From: mika at async.async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] [M3commit] CVS Update: cm3
>
>
> Safety is important in that it allows you to limit the possible effects
> of bugs. Getting programs bug-free is of course a very difficult problem
> no matter what you do.
>
> But no I don't think warnings for uninitialized use of variables is
> something one should do in general in Modula-3. The safety guarantees
> lead to different idioms from in C---not so many compiler warnings
> are required to get your code right. And if you do screw up
> an uninitialized variable, the effect is going to be limited.
> Unlike what happens in C, where if you screw up the initialization
> of a pointer, for instance, all hell breaks loose.
>
> Your example is contrived. Usually the code looks like this
>
> VAR
> x : T;
> BEGIN
> IF cond1 THEN x := ... END;
> ...
> IF cond2 THEN (* use x *) END
> END
>
> where the programmer knows that cond2 logically implies cond1.
>
> I think the presence of VAR parameter passing makes these sorts of
> warnings also less useful in Modula-3. Is the following OK?
>
> PROCEDURE InitializeIt(VAR a : T);
> PROCEUDRE UseIt(VALUE a : T);
>
> VAR x : T;
> BEGIN
> InitializeIt(x);
> UseIt(x)
> END
>
> I would think your compiler can't prove that x is initialized. Warning
> or not? I say no: this is actually very reasonable Modula-3 code.
> But then do you want a warning for the IF? It's logically the same.
>
> There's a chapter in
> EWD's Discipline of Programming that deals with the problem in
> detail. I think he winds up with six different "modes" for variables.
>
> Mika
>
> Jay K writes:
>>
>>ok=2C so in C:
>>=20
>>int F()
>>{
>> int i=3B
>> return i=3B
>>}
>>=20
>>should warn or not?
>>Prevailing wisdom is definitely.
>>Main known exception is code to generate random numbers.
>> I believe this is how Debian broke key generation.
>>=20
>>=20
>>Modula-3:
>>=20
>>=20
>>PROCEDURE F(): INTEGER =3D=20
>> VAR i: INTEGER=3B
>>BEGIN
>> RETURN i=3B
>>END F=3B
>>=20
>>=20
>>Should warn or not?
>>Since this identical to the C=2C prevailing wisdom is definitely.
>>=20
>>=20
>>They are=2C I guess=2C "safe"=2C but most likely=2C incorrect.
>>=20
>>=20
>>The compiler may have made "safety" guarantees=2C and they are significant=
>>=2C
>>but safe is far from correct=2C and however smart the compiler can be to lo=
>>ok for correctness issues=2C is also nice.
>>=20
>>=20
>>=20
>>(Friend of mine conjectured something like: Safety guarantees have people d=
>>eluded. Software will still have plenty of bugs and be plenty difficult to =
>>get correct and require plenty of testing. Safety guarantees help=2C but th=
>>ey are only a small step toward actual correctness.)
>>=20
>>=20
>>=20
>> - Jay
>>
>>
>>----------------------------------------
>>> Subject: Re: [M3commit] CVS Update: cm3
>>> From: hosking at cs.purdue.edu
>>> Date: Tue=2C 1 Jun 2010 20:04:00 -0400
>>> CC: jkrell at elego.de=3B m3commit at elegosoft.com
>>> To: jay.krell at cornell.edu
>>>
>>> Sure=2C an INTEGER is a valid value whatever the bits.
>>>
>>>
>>> On 1 Jun 2010=2C at 17:44=2C Jay K wrote:
>>>
>>>>
>>>> Start removing the rampant use of volatile in the backend and these warn=
>>ings show up.
>>>>
>>>> Volatile quashes the uninitialized checks in the backend.
>>>>
>>>> Is it really ok for an INTEGER to be uninitialized? I realize it contain=
>>s an "integer" value=2C as all bit patterns are.
>>>>
>>>> Some of these really do seem like bugs. Some do not.
>>>> I'll try making fault_proc noreturn=2C which should remove some of them.
>>>>
>>>>
>>>> - Jay
>>>>
>>>>
>>>>
>>>>
>>>> ----------------------------------------
>>>>> From: hosking at cs.purdue.edu
>>>>> To: jkrell at elego.de
>>>>> Date: Tue=2C 1 Jun 2010 16:29:20 -0500
>>>>> CC: m3commit at elegosoft.com
>>>>> Subject: Re: [M3commit] CVS Update: cm3
>>>>>
>>>>> This is bogus. The M3 compiler guarantees all variables are initialized=
>>.
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>> On Jun 1=2C 2010=2C at 2:42 PM=2C jkrell at elego.de (Jay Krell) wrote:
>>>>>
>>>>>> CVSROOT: /usr/cvs
>>>>>> Changes by: jkrell at birch. 10/06/01 14:42:00
>>>>>>
>>>>>> Modified files:
>>>>>> cm3/m3-libs/m3core/src/convert/: Convert.m3
>>>>>>
>>>>>> Log message:
>>>>>> initialize locals=3B I get warnings that some not quite all=2C are
>>>>>> used uninitialized if I remove the volatile/sideeffects on every
>>>>>> load/store in parse.c
>>> =
 		 	   		  

From jay.krell at cornell.edu  Wed Jun  2 09:41:33 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 2 Jun 2010 07:41:33 +0000
Subject: [M3devel] ADR is *too* unsafe..
Message-ID: <COL101-W617B9602E6CAA0BBE5BE25E6D00@phx.gbl>


(*
Wow, ADR generates a plain ADDRESS, not an untraced ref to a specific type?
Doesn't this seem wrong? Doesn't unsafe code deserve a little better, say,
? to be at least as typesafe as C?
http://www.cs.purdue.edu/homes/hosking/m3/reference/unsafe.html

This is why 64bit m3-comm/tcp/src/TCP.m3 breaks randomly
on some platforms on an assertion failure in C. And the
compiler isn't going to help me find these type mismatches? Ugh.

This seems wrong. :(

I guess I should really really use VAR then.
*)


UNSAFE MODULE Main;
IMPORT Ctypes, Cstddef;


PROCEDURE F1(a:UNTRACED REF Ctypes.int) =
BEGIN
? F2(a); (* error, expected *)
END F1;


PROCEDURE F2(a:UNTRACED REF Cstddef.size_t) =
BEGIN
? F1(a); (* error, expected *)
END F2;


VAR c:Ctypes.int;
??? d:Cstddef.size_t;

??? 
BEGIN
? F1(ADR(c)); (* ok *)
? F1(ADR(d)); (* error expected but no *)
? F2(ADR(c)); (* error expected but no *)
? F2(ADR(d)); (* ok *)
END Main.



?- Jay
 		 	   		  

From mika at async.async.caltech.edu  Wed Jun  2 14:44:22 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Wed, 02 Jun 2010 05:44:22 -0700
Subject: [M3devel] warning for uninitialized variables?
In-Reply-To: <COL101-W59770EAA64E52A966D79F3E6D00@phx.gbl> 
References: <20100601124200.8E42B2474003@birch.elegosoft.com>, ,
	<E86D485E-C5D5-4B7A-8142-5E0BE31280DD@cs.purdue.edu>,
	<COL101-W58EC381F7DE75AC44CFB57E6EF0@phx.gbl>, ,
	<5458A114-F000-4A90-9998-FD7DF63E06C0@cs.purdue.edu>,
	<COL101-W3678C92B3A9FA07AD57BF2E6D00@phx.gbl>,
	<20100602035226.43C1F1A208F@async.async.caltech.edu>
	<COL101-W59770EAA64E52A966D79F3E6D00@phx.gbl>
Message-ID: <20100602124422.11C6D1A209A@async.async.caltech.edu>

Jay K writes:
>
>Wow. You really surprise me Mika.
>
>
>To warn on this kind of thing=2C to me=2C there is no question.
>
>
>Limting the affects by virtue of being safe isn't much consolation.
>The program can easily go down a "safe" but very incorrect path.

It is, though!  Do you always know what value to initialize the
variables to?  If not, you're just picking some value to shut up
the compiler, and now your code no longer expresses---to a human
reader---that x is uninitialized.

Remember, code is mainly written for humans!  Computers don't care
about fancy structuring, declarations, etc.  When you write a program,
you write it to be read by a human.  The fact that a variable is
uninitialized is a part of the design of the program.

It's an unfortunate fact that our languages don't have all the 
mechanisms necessary to deal properly with uninitialized variables.
Retrofitting mechanisms to something that just isn't expressive
enough to solve the problem I really don't think is the way to go.

EWD's book chapter... read it.  "An essay on the scope of variables"
I think it is called.


>
>
>There are several forms.
>In fact=2C sometimes the compiler says something "is" used uninitialized.
>Sometimes it says "maybe".
>
>
>In your example=2C generally=2C once the address is taken of a variable=2C
>the compiler gives up. Esp. if that address is passed to a function it does=
>n't "see".

As long as this doesn't raise warnings I can live with your warnings...

...
>
>
>There are many more warnings in the tree than I have yet looked at.
>I've seen a few forms.
>Some are because the compiler doesn't know that some functions don't return=
>.
>I'll see about improving that. Though I think there's a limit to how good I=
> can manage=2C
>unless we add a <* noreturn *> pragma.

adding <*ASSERT FALSE*> in the right places might fix these warnings.

...
>
>
>I grant that by initializing to 0=2C I haven't necessarily made the code co=
>rrect either.
>But at least it is now consistent.
>
>
>Even better would be runtime checks that stop if a variable is read before =
>written.

Which you have just defeated with your initialization!

I know that my Modula code will outlive its current compiler.  Probably
by a long time.  Once you add the initialization you're talking about,
you can't go back.  It no longer expresses the useful property you're
trying to check.  When the new compiler comes along with its runtime
check, it will miss that my variables are actually uninitialized.

>
>
>See also the rules in Java and C# that require the compiler to be able to p=
>rove
>a variable is written before read. Possibly even verifiable at load time.

I *hate* this.  See above.  

What's next?  The compiler refuses to compile loops that it can't
prove will terminate???  Hogwash!

>
>
>Other forms look related to going "through" a switch statement with no arms=
> handling the value.
>I think I can address that by marking fault_proc as noreturn.
>
>
>One form apparently in cm3ide would use uninitialized data if presented wit=
>h a malformed file.
>Good software doesn't depend on the well formedness of its input.
>
>There are many more warnings like this in the tree.
>
>
>My inclination is at least to temporarily hardcode the gcc backend to alway=
>s optimize=2C
>and always produce these warnings. People can look over them maybe and deci=
>de.
>Or they can look over my "fixes".
>
>
>Or I guess if people really really really really prefer=2C we can always tu=
>rn off the warnings
>and let the code lie. I really think that is the wrong answer.
>
>
>I have been burned too much by uninitialized locals in C.
>I put " =3D { 0 }" after everything.
>Again=2C that isn't necessarily "correct"=2C but at least the incorrect pat=
>hs are consistent.
>If they don't work and I happen down them=2C they will guaranteeably not wo=
>rk.

No they will just consistently not work.  Not "guaranteeably".  You have
to initialize them to some specific value for that to be the case.
Using "0" often will just give you the wrong answer!  

>
>
>Uninitialized values can be different run to run.
>Repeatability and consistency are important.

Not forcing the programmer to obscure the meaning of the code I think
is more important.

>
>
>I'm also nervous about us not taking a hard line on integer overflow.
>Overflown math doesn't necessarily lead to array out of bounds soon or ever=
>.
>It too can lead to incorrect but safe behavior.

Similar situation is it not?  You don't generate a compiler warning
for math that "might overflow".  

I think we can all agree that error on integer overflow, error on
use of uninitialized variable, at runtime, would both be good things?

     Mika

>
>
>=A0- Jay
>
>
>----------------------------------------
>> To: jay.krell at cornell.edu
>> Date: Tue=2C 1 Jun 2010 20:52:26 -0700
>> From: mika at async.async.caltech.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] [M3commit] CVS Update: cm3
>>
>>
>> Safety is important in that it allows you to limit the possible effects
>> of bugs. Getting programs bug-free is of course a very difficult problem
>> no matter what you do.
>>
>> But no I don't think warnings for uninitialized use of variables is
>> something one should do in general in Modula-3. The safety guarantees
>> lead to different idioms from in C---not so many compiler warnings
>> are required to get your code right. And if you do screw up
>> an uninitialized variable=2C the effect is going to be limited.
>> Unlike what happens in C=2C where if you screw up the initialization
>> of a pointer=2C for instance=2C all hell breaks loose.
>>
>> Your example is contrived. Usually the code looks like this
>>
>> VAR
>> x : T=3B
>> BEGIN
>> IF cond1 THEN x :=3D ... END=3B
>> ...
>> IF cond2 THEN (* use x *) END
>> END
>>
>> where the programmer knows that cond2 logically implies cond1.
>>
>> I think the presence of VAR parameter passing makes these sorts of
>> warnings also less useful in Modula-3. Is the following OK?
>>
>> PROCEDURE InitializeIt(VAR a : T)=3B
>> PROCEUDRE UseIt(VALUE a : T)=3B
>>
>> VAR x : T=3B
>> BEGIN
>> InitializeIt(x)=3B
>> UseIt(x)
>> END
>>
>> I would think your compiler can't prove that x is initialized. Warning
>> or not? I say no: this is actually very reasonable Modula-3 code.
>> But then do you want a warning for the IF? It's logically the same.
>>
>> There's a chapter in
>> EWD's Discipline of Programming that deals with the problem in
>> detail. I think he winds up with six different "modes" for variables.
>>
>> Mika
>>
>> Jay K writes:
>>>
>>>ok=3D2C so in C:
>>>=3D20
>>>int F()
>>>{
>>> int i=3D3B
>>> return i=3D3B
>>>}
>>>=3D20
>>>should warn or not?
>>>Prevailing wisdom is definitely.
>>>Main known exception is code to generate random numbers.
>>> I believe this is how Debian broke key generation.
>>>=3D20
>>>=3D20
>>>Modula-3:
>>>=3D20
>>>=3D20
>>>PROCEDURE F(): INTEGER =3D3D=3D20
>>> VAR i: INTEGER=3D3B
>>>BEGIN
>>> RETURN i=3D3B
>>>END F=3D3B
>>>=3D20
>>>=3D20
>>>Should warn or not?
>>>Since this identical to the C=3D2C prevailing wisdom is definitely.
>>>=3D20
>>>=3D20
>>>They are=3D2C I guess=3D2C "safe"=3D2C but most likely=3D2C incorrect.
>>>=3D20
>>>=3D20
>>>The compiler may have made "safety" guarantees=3D2C and they are signific=
>ant=3D
>>>=3D2C
>>>but safe is far from correct=3D2C and however smart the compiler can be t=
>o lo=3D
>>>ok for correctness issues=3D2C is also nice.
>>>=3D20
>>>=3D20
>>>=3D20
>>>(Friend of mine conjectured something like: Safety guarantees have people=
> d=3D
>>>eluded. Software will still have plenty of bugs and be plenty difficult t=
>o =3D
>>>get correct and require plenty of testing. Safety guarantees help=3D2C bu=
>t th=3D
>>>ey are only a small step toward actual correctness.)
>>>=3D20
>>>=3D20
>>>=3D20
>>> - Jay
>>>
>>>
>>>----------------------------------------
>>>> Subject: Re: [M3commit] CVS Update: cm3
>>>> From: hosking at cs.purdue.edu
>>>> Date: Tue=3D2C 1 Jun 2010 20:04:00 -0400
>>>> CC: jkrell at elego.de=3D3B m3commit at elegosoft.com
>>>> To: jay.krell at cornell.edu
>>>>
>>>> Sure=3D2C an INTEGER is a valid value whatever the bits.
>>>>
>>>>
>>>> On 1 Jun 2010=3D2C at 17:44=3D2C Jay K wrote:
>>>>
>>>>>
>>>>> Start removing the rampant use of volatile in the backend and these wa=
>rn=3D
>>>ings show up.
>>>>>
>>>>> Volatile quashes the uninitialized checks in the backend.
>>>>>
>>>>> Is it really ok for an INTEGER to be uninitialized? I realize it conta=
>in=3D
>>>s an "integer" value=3D2C as all bit patterns are.
>>>>>
>>>>> Some of these really do seem like bugs. Some do not.
>>>>> I'll try making fault_proc noreturn=3D2C which should remove some of t=
>hem.
>>>>>
>>>>>
>>>>> - Jay
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ----------------------------------------
>>>>>> From: hosking at cs.purdue.edu
>>>>>> To: jkrell at elego.de
>>>>>> Date: Tue=3D2C 1 Jun 2010 16:29:20 -0500
>>>>>> CC: m3commit at elegosoft.com
>>>>>> Subject: Re: [M3commit] CVS Update: cm3
>>>>>>
>>>>>> This is bogus. The M3 compiler guarantees all variables are initializ=
>ed=3D
>>>.
>>>>>>
>>>>>> Sent from my iPhone
>>>>>>
>>>>>> On Jun 1=3D2C 2010=3D2C at 2:42 PM=3D2C jkrell at elego.de (Jay Krell) w=
>rote:
>>>>>>
>>>>>>> CVSROOT: /usr/cvs
>>>>>>> Changes by: jkrell at birch. 10/06/01 14:42:00
>>>>>>>
>>>>>>> Modified files:
>>>>>>> cm3/m3-libs/m3core/src/convert/: Convert.m3
>>>>>>>
>>>>>>> Log message:
>>>>>>> initialize locals=3D3B I get warnings that some not quite all=3D2C a=
>re
>>>>>>> used uninitialized if I remove the volatile/sideeffects on every
>>>>>>> load/store in parse.c
>>>> =3D
> 		 	   		  =



From jay.krell at cornell.edu  Wed Jun  2 15:01:38 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 2 Jun 2010 13:01:38 +0000
Subject: [M3devel] SOLgnu/SOLsun -O1/-O2/-O3
Message-ID: <COL101-W26B2AF5D865D1A694793DAE6D00@phx.gbl>


Anyone recall if SOLgnu/sun work with any optimization?
? You know -- the platforms that have a stack walker and don't use setjmp.
I tried leaving them having all loads/stores be volatile, except handling still doesn't work -- cm3 gets an unhandled exception instead of saying cm3.cfg not found.
I'll have to test with an old clean version.
Could be I'm missing something, or maybe the m3cg_pop change broke them.


?- Jay

 		 	   		  

From jay.krell at cornell.edu  Wed Jun  2 14:59:45 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 2 Jun 2010 12:59:45 +0000
Subject: [M3devel] warning for uninitialized variables?
In-Reply-To: <20100602124422.11C6D1A209A@async.async.caltech.edu>
References: <20100601124200.8E42B2474003@birch.elegosoft.com>, ,
	<E86D485E-C5D5-4B7A-8142-5E0BE31280DD@cs.purdue.edu>,
	<COL101-W58EC381F7DE75AC44CFB57E6EF0@phx.gbl>, ,
	<5458A114-F000-4A90-9998-FD7DF63E06C0@cs.purdue.edu>,
	<COL101-W3678C92B3A9FA07AD57BF2E6D00@phx.gbl>,
	<20100602035226.43C1F1A208F@async.async.caltech.edu>
	<COL101-W59770EAA64E52A966D79F3E6D00@phx.gbl>,
	<20100602124422.11C6D1A209A@async.async.caltech.edu>
Message-ID: <COL101-W5343011FD0FA7BCC8C42AEE6D00@phx.gbl>


I grant that an immediate runtime error upon reading an unwritten value is ideal.
But absent that possibility, I want something consistent.
Heck, here's a crazy idea: reserve the current FIRST(INTEGER) as "invalid", initialize locals to it, any read (or generation/write) of that value trigger a runtime error.
CARDINAL could work this way more easily since it has many values to spare.


?- Jay

----------------------------------------
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] warning for uninitialized variables?
> Date: Wed, 2 Jun 2010 05:44:22 -0700
> From: mika at async.async.caltech.edu
>
> Jay K writes:
>>
>>Wow. You really surprise me Mika.
>>
>>
>>To warn on this kind of thing=2C to me=2C there is no question.
>>
>>
>>Limting the affects by virtue of being safe isn't much consolation.
>>The program can easily go down a "safe" but very incorrect path.
>
> It is, though! Do you always know what value to initialize the
> variables to? If not, you're just picking some value to shut up
> the compiler, and now your code no longer expresses---to a human
> reader---that x is uninitialized.
>
> Remember, code is mainly written for humans! Computers don't care
> about fancy structuring, declarations, etc. When you write a program,
> you write it to be read by a human. The fact that a variable is
> uninitialized is a part of the design of the program.
>
> It's an unfortunate fact that our languages don't have all the
> mechanisms necessary to deal properly with uninitialized variables.
> Retrofitting mechanisms to something that just isn't expressive
> enough to solve the problem I really don't think is the way to go.
>
> EWD's book chapter... read it. "An essay on the scope of variables"
> I think it is called.
>
>
>>
>>
>>There are several forms.
>>In fact=2C sometimes the compiler says something "is" used uninitialized.
>>Sometimes it says "maybe".
>>
>>
>>In your example=2C generally=2C once the address is taken of a variable=2C
>>the compiler gives up. Esp. if that address is passed to a function it does=
>>n't "see".
>
> As long as this doesn't raise warnings I can live with your warnings...
>
> ...
>>
>>
>>There are many more warnings in the tree than I have yet looked at.
>>I've seen a few forms.
>>Some are because the compiler doesn't know that some functions don't return=
>>.
>>I'll see about improving that. Though I think there's a limit to how good I=
>> can manage=2C
>>unless we add a <* noreturn *> pragma.
>
> adding <*ASSERT FALSE*> in the right places might fix these warnings.
>
> ...
>>
>>
>>I grant that by initializing to 0=2C I haven't necessarily made the code co=
>>rrect either.
>>But at least it is now consistent.
>>
>>
>>Even better would be runtime checks that stop if a variable is read before =
>>written.
>
> Which you have just defeated with your initialization!
>
> I know that my Modula code will outlive its current compiler. Probably
> by a long time. Once you add the initialization you're talking about,
> you can't go back. It no longer expresses the useful property you're
> trying to check. When the new compiler comes along with its runtime
> check, it will miss that my variables are actually uninitialized.
>
>>
>>
>>See also the rules in Java and C# that require the compiler to be able to p=
>>rove
>>a variable is written before read. Possibly even verifiable at load time.
>
> I *hate* this. See above.
>
> What's next? The compiler refuses to compile loops that it can't
> prove will terminate??? Hogwash!
>
>>
>>
>>Other forms look related to going "through" a switch statement with no arms=
>> handling the value.
>>I think I can address that by marking fault_proc as noreturn.
>>
>>
>>One form apparently in cm3ide would use uninitialized data if presented wit=
>>h a malformed file.
>>Good software doesn't depend on the well formedness of its input.
>>
>>There are many more warnings like this in the tree.
>>
>>
>>My inclination is at least to temporarily hardcode the gcc backend to alway=
>>s optimize=2C
>>and always produce these warnings. People can look over them maybe and deci=
>>de.
>>Or they can look over my "fixes".
>>
>>
>>Or I guess if people really really really really prefer=2C we can always tu=
>>rn off the warnings
>>and let the code lie. I really think that is the wrong answer.
>>
>>
>>I have been burned too much by uninitialized locals in C.
>>I put " =3D { 0 }" after everything.
>>Again=2C that isn't necessarily "correct"=2C but at least the incorrect pat=
>>hs are consistent.
>>If they don't work and I happen down them=2C they will guaranteeably not wo=
>>rk.
>
> No they will just consistently not work. Not "guaranteeably". You have
> to initialize them to some specific value for that to be the case.
> Using "0" often will just give you the wrong answer!
>
>>
>>
>>Uninitialized values can be different run to run.
>>Repeatability and consistency are important.
>
> Not forcing the programmer to obscure the meaning of the code I think
> is more important.
>
>>
>>
>>I'm also nervous about us not taking a hard line on integer overflow.
>>Overflown math doesn't necessarily lead to array out of bounds soon or ever=
>>.
>>It too can lead to incorrect but safe behavior.
>
> Similar situation is it not? You don't generate a compiler warning
> for math that "might overflow".
>
> I think we can all agree that error on integer overflow, error on
> use of uninitialized variable, at runtime, would both be good things?
>
> Mika
>
>>
>>
>>=A0- Jay
>>
>>
>>----------------------------------------
>>> To: jay.krell at cornell.edu
>>> Date: Tue=2C 1 Jun 2010 20:52:26 -0700
>>> From: mika at async.async.caltech.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] [M3commit] CVS Update: cm3
>>>
>>>
>>> Safety is important in that it allows you to limit the possible effects
>>> of bugs. Getting programs bug-free is of course a very difficult problem
>>> no matter what you do.
>>>
>>> But no I don't think warnings for uninitialized use of variables is
>>> something one should do in general in Modula-3. The safety guarantees
>>> lead to different idioms from in C---not so many compiler warnings
>>> are required to get your code right. And if you do screw up
>>> an uninitialized variable=2C the effect is going to be limited.
>>> Unlike what happens in C=2C where if you screw up the initialization
>>> of a pointer=2C for instance=2C all hell breaks loose.
>>>
>>> Your example is contrived. Usually the code looks like this
>>>
>>> VAR
>>> x : T=3B
>>> BEGIN
>>> IF cond1 THEN x :=3D ... END=3B
>>> ...
>>> IF cond2 THEN (* use x *) END
>>> END
>>>
>>> where the programmer knows that cond2 logically implies cond1.
>>>
>>> I think the presence of VAR parameter passing makes these sorts of
>>> warnings also less useful in Modula-3. Is the following OK?
>>>
>>> PROCEDURE InitializeIt(VAR a : T)=3B
>>> PROCEUDRE UseIt(VALUE a : T)=3B
>>>
>>> VAR x : T=3B
>>> BEGIN
>>> InitializeIt(x)=3B
>>> UseIt(x)
>>> END
>>>
>>> I would think your compiler can't prove that x is initialized. Warning
>>> or not? I say no: this is actually very reasonable Modula-3 code.
>>> But then do you want a warning for the IF? It's logically the same.
>>>
>>> There's a chapter in
>>> EWD's Discipline of Programming that deals with the problem in
>>> detail. I think he winds up with six different "modes" for variables.
>>>
>>> Mika
>>>
>>> Jay K writes:
>>>>
>>>>ok=3D2C so in C:
>>>>=3D20
>>>>int F()
>>>>{
>>>> int i=3D3B
>>>> return i=3D3B
>>>>}
>>>>=3D20
>>>>should warn or not?
>>>>Prevailing wisdom is definitely.
>>>>Main known exception is code to generate random numbers.
>>>> I believe this is how Debian broke key generation.
>>>>=3D20
>>>>=3D20
>>>>Modula-3:
>>>>=3D20
>>>>=3D20
>>>>PROCEDURE F(): INTEGER =3D3D=3D20
>>>> VAR i: INTEGER=3D3B
>>>>BEGIN
>>>> RETURN i=3D3B
>>>>END F=3D3B
>>>>=3D20
>>>>=3D20
>>>>Should warn or not?
>>>>Since this identical to the C=3D2C prevailing wisdom is definitely.
>>>>=3D20
>>>>=3D20
>>>>They are=3D2C I guess=3D2C "safe"=3D2C but most likely=3D2C incorrect.
>>>>=3D20
>>>>=3D20
>>>>The compiler may have made "safety" guarantees=3D2C and they are signific=
>>ant=3D
>>>>=3D2C
>>>>but safe is far from correct=3D2C and however smart the compiler can be t=
>>o lo=3D
>>>>ok for correctness issues=3D2C is also nice.
>>>>=3D20
>>>>=3D20
>>>>=3D20
>>>>(Friend of mine conjectured something like: Safety guarantees have people=
>> d=3D
>>>>eluded. Software will still have plenty of bugs and be plenty difficult t=
>>o =3D
>>>>get correct and require plenty of testing. Safety guarantees help=3D2C bu=
>>t th=3D
>>>>ey are only a small step toward actual correctness.)
>>>>=3D20
>>>>=3D20
>>>>=3D20
>>>> - Jay
>>>>
>>>>
>>>>----------------------------------------
>>>>> Subject: Re: [M3commit] CVS Update: cm3
>>>>> From: hosking at cs.purdue.edu
>>>>> Date: Tue=3D2C 1 Jun 2010 20:04:00 -0400
>>>>> CC: jkrell at elego.de=3D3B m3commit at elegosoft.com
>>>>> To: jay.krell at cornell.edu
>>>>>
>>>>> Sure=3D2C an INTEGER is a valid value whatever the bits.
>>>>>
>>>>>
>>>>> On 1 Jun 2010=3D2C at 17:44=3D2C Jay K wrote:
>>>>>
>>>>>>
>>>>>> Start removing the rampant use of volatile in the backend and these wa=
>>rn=3D
>>>>ings show up.
>>>>>>
>>>>>> Volatile quashes the uninitialized checks in the backend.
>>>>>>
>>>>>> Is it really ok for an INTEGER to be uninitialized? I realize it conta=
>>in=3D
>>>>s an "integer" value=3D2C as all bit patterns are.
>>>>>>
>>>>>> Some of these really do seem like bugs. Some do not.
>>>>>> I'll try making fault_proc noreturn=3D2C which should remove some of t=
>>hem.
>>>>>>
>>>>>>
>>>>>> - Jay
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ----------------------------------------
>>>>>>> From: hosking at cs.purdue.edu
>>>>>>> To: jkrell at elego.de
>>>>>>> Date: Tue=3D2C 1 Jun 2010 16:29:20 -0500
>>>>>>> CC: m3commit at elegosoft.com
>>>>>>> Subject: Re: [M3commit] CVS Update: cm3
>>>>>>>
>>>>>>> This is bogus. The M3 compiler guarantees all variables are initializ=
>>ed=3D
>>>>.
>>>>>>>
>>>>>>> Sent from my iPhone
>>>>>>>
>>>>>>> On Jun 1=3D2C 2010=3D2C at 2:42 PM=3D2C jkrell at elego.de (Jay Krell) w=
>>rote:
>>>>>>>
>>>>>>>> CVSROOT: /usr/cvs
>>>>>>>> Changes by: jkrell at birch. 10/06/01 14:42:00
>>>>>>>>
>>>>>>>> Modified files:
>>>>>>>> cm3/m3-libs/m3core/src/convert/: Convert.m3
>>>>>>>>
>>>>>>>> Log message:
>>>>>>>> initialize locals=3D3B I get warnings that some not quite all=3D2C a=
>>re
>>>>>>>> used uninitialized if I remove the volatile/sideeffects on every
>>>>>>>> load/store in parse.c
>>>>> =3D
>> =
>
 		 	   		  

From hosking at cs.purdue.edu  Wed Jun  2 16:01:09 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 2 Jun 2010 10:01:09 -0400
Subject: [M3devel] ADR is *too* unsafe..
In-Reply-To: <COL101-W617B9602E6CAA0BBE5BE25E6D00@phx.gbl>
References: <COL101-W617B9602E6CAA0BBE5BE25E6D00@phx.gbl>
Message-ID: <A8CEEB02-D279-4C90-B8D3-5D163619C748@cs.purdue.edu>

Why does the compiler break?
Yes, VAR is *much* safer.

On 2 Jun 2010, at 03:41, Jay K wrote:

> 
> (*
> Wow, ADR generates a plain ADDRESS, not an untraced ref to a specific type?
> Doesn't this seem wrong? Doesn't unsafe code deserve a little better, say,
>   to be at least as typesafe as C?
> http://www.cs.purdue.edu/homes/hosking/m3/reference/unsafe.html
> 
> This is why 64bit m3-comm/tcp/src/TCP.m3 breaks randomly
> on some platforms on an assertion failure in C. And the
> compiler isn't going to help me find these type mismatches? Ugh.
> 
> This seems wrong. :(
> 
> I guess I should really really use VAR then.
> *)
> 
> 
> UNSAFE MODULE Main;
> IMPORT Ctypes, Cstddef;
> 
> 
> PROCEDURE F1(a:UNTRACED REF Ctypes.int) =
> BEGIN
>   F2(a); (* error, expected *)
> END F1;
> 
> 
> PROCEDURE F2(a:UNTRACED REF Cstddef.size_t) =
> BEGIN
>   F1(a); (* error, expected *)
> END F2;
> 
> 
> VAR c:Ctypes.int;
>     d:Cstddef.size_t;
> 
>     
> BEGIN
>   F1(ADR(c)); (* ok *)
>   F1(ADR(d)); (* error expected but no *)
>   F2(ADR(c)); (* error expected but no *)
>   F2(ADR(d)); (* ok *)
> END Main.
> 
> 
> 
>  - Jay
> 		 	   		  



From jay.krell at cornell.edu  Wed Jun  2 16:07:02 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 2 Jun 2010 14:07:02 +0000
Subject: [M3devel] ADR is *too* unsafe..
In-Reply-To: <A8CEEB02-D279-4C90-B8D3-5D163619C748@cs.purdue.edu>
References: <COL101-W617B9602E6CAA0BBE5BE25E6D00@phx.gbl>,
	<A8CEEB02-D279-4C90-B8D3-5D163619C748@cs.purdue.edu>
Message-ID: <COL101-W444318DF7FE046C2AE542AE6D00@phx.gbl>


The compiler doesn't break. Mentor does, networking stuff. I fixed it. But I would have
expected the compiler to have told me about it.
It is unfortunate. ADR should be *slightly* safer.
Maybe we can get a warning for this? passing ADR(foo) to untraced ref bar?
It seems...quite unfortunate that the language is defined this way..

?- Jay


----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Wed, 2 Jun 2010 10:01:09 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] ADR is *too* unsafe..
>
> Why does the compiler break?
> Yes, VAR is *much* safer.
>
> On 2 Jun 2010, at 03:41, Jay K wrote:
>
>>
>> (*
>> Wow, ADR generates a plain ADDRESS, not an untraced ref to a specific type?
>> Doesn't this seem wrong? Doesn't unsafe code deserve a little better, say,
>> to be at least as typesafe as C?
>> http://www.cs.purdue.edu/homes/hosking/m3/reference/unsafe.html
>>
>> This is why 64bit m3-comm/tcp/src/TCP.m3 breaks randomly
>> on some platforms on an assertion failure in C. And the
>> compiler isn't going to help me find these type mismatches? Ugh.
>>
>> This seems wrong. :(
>>
>> I guess I should really really use VAR then.
>> *)
>>
>>
>> UNSAFE MODULE Main;
>> IMPORT Ctypes, Cstddef;
>>
>>
>> PROCEDURE F1(a:UNTRACED REF Ctypes.int) =
>> BEGIN
>> F2(a); (* error, expected *)
>> END F1;
>>
>>
>> PROCEDURE F2(a:UNTRACED REF Cstddef.size_t) =
>> BEGIN
>> F1(a); (* error, expected *)
>> END F2;
>>
>>
>> VAR c:Ctypes.int;
>> d:Cstddef.size_t;
>>
>>
>> BEGIN
>> F1(ADR(c)); (* ok *)
>> F1(ADR(d)); (* error expected but no *)
>> F2(ADR(c)); (* error expected but no *)
>> F2(ADR(d)); (* ok *)
>> END Main.
>>
>>
>>
>> - Jay
>>
>
 		 	   		  

From jay.krell at cornell.edu  Wed Jun  2 16:07:35 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 2 Jun 2010 14:07:35 +0000
Subject: [M3devel] SOLgnu/SOLsun -O1/-O2/-O3
Message-ID: <COL101-W16BB57F49DB4CD5964A0A1E6D00@phx.gbl>


It looks like -O2 does work.
I need to keep digging.

?- Jay


----------------------------------------
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu; m3devel at elegosoft.com
> Subject: SOLgnu/SOLsun -O1/-O2/-O3
> Date: Wed, 2 Jun 2010 13:01:38 +0000
>
>
> Anyone recall if SOLgnu/sun work with any optimization?
>   You know -- the platforms that have a stack walker and don't use setjmp.
> I tried leaving them having all loads/stores be volatile, except handling still doesn't work -- cm3 gets an unhandled exception instead of saying cm3.cfg not found.
> I'll have to test with an old clean version.
> Could be I'm missing something, or maybe the m3cg_pop change broke them.
>
>
>  - Jay
>
>
 		 	   		  

From jay.krell at cornell.edu  Wed Jun  2 16:30:05 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 2 Jun 2010 14:30:05 +0000
Subject: [M3devel] reducing use of volatile in backend?
In-Reply-To: <AA1F4490-A9C7-4F94-8E03-65A5E9031424@cs.purdue.edu>
References: <COL101-W17AA739AA2DE2050C6CCD0E6EF0@phx.gbl>,
	<AA1F4490-A9C7-4F94-8E03-65A5E9031424@cs.purdue.edu>
Message-ID: <COL101-W35361E5B4C86598DB49C90E6D00@phx.gbl>


attached is the diff I'm working on.


It works well on a few platforms.
I've been using it on AMD64_DARWIN.
Cross I386_LINUX, PPC_DARWIN cm3 startup and give
? the correct message, which requires exception handling to work.


SOLgnu exception handling doesn't work.
MIPS64_OPENBSD internal errors a bunch in the compiler.
? Probably don't care. Don't know if it was working before.


Still to do:
? figure out what is up with SOLgnu/SOLsun


Not ideal but I think ok for now:
? volatizing all floating point
??? We already were, though granted possibly with more optimizations.
? flag_unit_at_a_time = 0

? 
flag_unit_at_a_time isn't "tricky" or subtle,
but it does remove a function we want to take the address of.
I couldn't find a way to get it to keep the function.


What I think is fine for a while:
? flag_tree_vrp = 0;
? flag_tree_pre = 0;
? flag_tree_fre = 0;

? 
Maybe it doesn't take much to let them work?
Maybe wait until 4.5 is working and try again there?
? In particular pre/fre only fail in one file among m3core/libm3, Formater.m3.
? vrp is what silently produces non-working code.
? It is either the only one, or one of pre/fre also do.
? At least one of pre/fre crash, accessing null pointer.

?
and probably also ok for a "while":
?flag_tree_loop_im = 0
?flag_schedule_insns = 0

?
though for flag_schedule_insns = 0 to fail seems odd,
and flag_tree_loop_im only broke in a little code, should
probably look at that code.


Oh and I still need to see about fours/badbricks recieving mouse clicks.
Mine aren't.


The TREE_ADDRESSABLE change in m3_write_globals was needed to get SOLgnu
to compiler. The assert failed.


We might want to have the frontend tell the backend if the
target has a stack walker, instead of the logic I have here.


While it is not ideal, I think this will let -O1/2/3 generate code much more like people expect, without
constantly reloading registers from the stack.


?- Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com
> Subject: RE: [M3devel] reducing use of volatile in backend?
> Date: Tue, 1 Jun 2010 21:55:31 +0000
>
>
> I've had *a lot* of success here the past few hours.
>
>
> There is an assert starting up mentor I need to look at, possibly out of data binaries.
> The one in socket.c assert(lossless_socklen || socklen == null || socklen < 1<<30.
>
>
> Compiler seems to work.
> Lots of things do break it, so that is something.
>
>
> Various gui apps startup.
> Some of the gui apps don't work, but nor did older copies I had -- fours, badbricks, and I think columns, wouldn't take any mouse clicks. I have to test older versions. Could be unrelated.
>
>
>
> Here is what I have:
>
> The vast vast majority of optimizations can be enabled.
>
> Nearly all uses of volatile can be removed.
>
> Just a few optimizations "need" to be disabled.
>
> In particular:
> I only have volatile remaining:
> on store after insert_mn (special case)
>
> floating point (huh? wierd)
> compile errors without this
>
> in functions that call setjmp or vfork
> This is very reasonable, but we should try to limit it to not all the variables, only what are accessed after the second return (I'm not sure how that computes for vfork, but for setjmp it makes sense to me.
>
>
> on the load/store in loophole
> compile errors without this; perhaps redundant with the floating point check
>
>
> on load link, else it gets uninitialized warning
>
>
>
> Also I found a likely bug.
> In functions that call setjmp/vfork, we volatize already seen parameters and locals, but we don't volatize not yet seen locals (in nested blocks) and temporaries. I fixed that.
>
>
>
>
> The optimizations I disabled, from memory:
>
>
> pre - partial redundancy elimination
>
>
> fre - full redundancy elimination (these are related)
> One or both of these causes the compiler to access violate in the optimizer, compiling libm3/Formatter.mc, but otherwise I think they compile m3core and libm3 entirely
>
>
> loop im (induction motion) - caused a compile error in Trestle
>
> vrp - value range propagation
> This seems to be the biggest problem, no compile errors but "random" runtime malfunction, usually starting up cm3.
>
>
> insn_sched - wierd, caused a compile break
> but insn_sched_after_reload ok
>
>
> That's about it. All the ones with "alias" in them, only like two, I enabled, seemed ok.
> salias and strict_alias. I left strict alias till late in experimentation but really it seems ok.
>
>
> I can compile the entire system, though I get lots of warnings about uninitialized variables.
> I pass the backend the -Wuninitialized flag.
>
>
> I test it out more -- the gui non-interaction, the mentor assert, and test other platforms.
> But I think we'll have volatile mostly gone and just a small number of optimizations turned off fairly soon.
> We can iterate more on the remaining optimizations.
>
>
> Getting good typeinfo would be good so that gdb can debug.
> And maybe so that other than stabs works.
>
>
> - Jay
>
>
>
>
> ----------------------------------------
>> From: hosking at cs.purdue.edu
>> To: jay.krell at cornell.edu
>> Date: Tue, 1 Jun 2010 16:05:30 -0500
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] reducing use of volatile in backend?
>>
>> We don't want to disable optimisations for types where it makes sense
>> to have them. Better to smarten up typebased alias analysis instead so
>> we can get rid of volatile properly.
>>
>> Sent from my iPhone
>>
>> On Jun 1, 2010, at 12:16 PM, Jay K wrote:
>>
>>>
>>> Tony, would we maybe be better off not using volatile everywhere but
>>> selectively turning off optimizations in m3_post_options?
>>> You know, using volatile probably disables more than necessary?
>>> I'm experimenting with this.
>>>
>>> - Jay
>>>
>>>
>>>
>>>
>>>
 		 	   		  
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: less-volatile.txt
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100602/59c4b762/attachment-0001.txt>

From hosking at cs.purdue.edu  Wed Jun  2 16:41:47 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 2 Jun 2010 10:41:47 -0400
Subject: [M3devel] warning for uninitialized variables?
In-Reply-To: <20100602124422.11C6D1A209A@async.async.caltech.edu>
References: <20100601124200.8E42B2474003@birch.elegosoft.com>, ,
	<E86D485E-C5D5-4B7A-8142-5E0BE31280DD@cs.purdue.edu>,
	<COL101-W58EC381F7DE75AC44CFB57E6EF0@phx.gbl>, ,
	<5458A114-F000-4A90-9998-FD7DF63E06C0@cs.purdue.edu>,
	<COL101-W3678C92B3A9FA07AD57BF2E6D00@phx.gbl>,
	<20100602035226.43C1F1A208F@async.async.caltech.edu>
	<COL101-W59770EAA64E52A966D79F3E6D00@phx.gbl>
	<20100602124422.11C6D1A209A@async.async.caltech.edu>
Message-ID: <16413179-F84C-42BF-AB09-2D8294EB4782@cs.purdue.edu>

Hear, hear!

On 2 Jun 2010, at 08:44, Mika Nystrom wrote:

> Jay K writes:
>> 
>> Wow. You really surprise me Mika.
>> 
>> 
>> To warn on this kind of thing=2C to me=2C there is no question.
>> 
>> 
>> Limting the affects by virtue of being safe isn't much consolation.
>> The program can easily go down a "safe" but very incorrect path.
> 
> It is, though!  Do you always know what value to initialize the
> variables to?  If not, you're just picking some value to shut up
> the compiler, and now your code no longer expresses---to a human
> reader---that x is uninitialized.
> 
> Remember, code is mainly written for humans!  Computers don't care
> about fancy structuring, declarations, etc.  When you write a program,
> you write it to be read by a human.  The fact that a variable is
> uninitialized is a part of the design of the program.
> 
> It's an unfortunate fact that our languages don't have all the 
> mechanisms necessary to deal properly with uninitialized variables.
> Retrofitting mechanisms to something that just isn't expressive
> enough to solve the problem I really don't think is the way to go.
> 
> EWD's book chapter... read it.  "An essay on the scope of variables"
> I think it is called.
> 
> 
>> 
>> 
>> There are several forms.
>> In fact=2C sometimes the compiler says something "is" used uninitialized.
>> Sometimes it says "maybe".
>> 
>> 
>> In your example=2C generally=2C once the address is taken of a variable=2C
>> the compiler gives up. Esp. if that address is passed to a function it does=
>> n't "see".
> 
> As long as this doesn't raise warnings I can live with your warnings...
> 
> ...
>> 
>> 
>> There are many more warnings in the tree than I have yet looked at.
>> I've seen a few forms.
>> Some are because the compiler doesn't know that some functions don't return=
>> .
>> I'll see about improving that. Though I think there's a limit to how good I=
>> can manage=2C
>> unless we add a <* noreturn *> pragma.
> 
> adding <*ASSERT FALSE*> in the right places might fix these warnings.
> 
> ...
>> 
>> 
>> I grant that by initializing to 0=2C I haven't necessarily made the code co=
>> rrect either.
>> But at least it is now consistent.
>> 
>> 
>> Even better would be runtime checks that stop if a variable is read before =
>> written.
> 
> Which you have just defeated with your initialization!
> 
> I know that my Modula code will outlive its current compiler.  Probably
> by a long time.  Once you add the initialization you're talking about,
> you can't go back.  It no longer expresses the useful property you're
> trying to check.  When the new compiler comes along with its runtime
> check, it will miss that my variables are actually uninitialized.
> 
>> 
>> 
>> See also the rules in Java and C# that require the compiler to be able to p=
>> rove
>> a variable is written before read. Possibly even verifiable at load time.
> 
> I *hate* this.  See above.  
> 
> What's next?  The compiler refuses to compile loops that it can't
> prove will terminate???  Hogwash!
> 
>> 
>> 
>> Other forms look related to going "through" a switch statement with no arms=
>> handling the value.
>> I think I can address that by marking fault_proc as noreturn.
>> 
>> 
>> One form apparently in cm3ide would use uninitialized data if presented wit=
>> h a malformed file.
>> Good software doesn't depend on the well formedness of its input.
>> 
>> There are many more warnings like this in the tree.
>> 
>> 
>> My inclination is at least to temporarily hardcode the gcc backend to alway=
>> s optimize=2C
>> and always produce these warnings. People can look over them maybe and deci=
>> de.
>> Or they can look over my "fixes".
>> 
>> 
>> Or I guess if people really really really really prefer=2C we can always tu=
>> rn off the warnings
>> and let the code lie. I really think that is the wrong answer.
>> 
>> 
>> I have been burned too much by uninitialized locals in C.
>> I put " =3D { 0 }" after everything.
>> Again=2C that isn't necessarily "correct"=2C but at least the incorrect pat=
>> hs are consistent.
>> If they don't work and I happen down them=2C they will guaranteeably not wo=
>> rk.
> 
> No they will just consistently not work.  Not "guaranteeably".  You have
> to initialize them to some specific value for that to be the case.
> Using "0" often will just give you the wrong answer!  
> 
>> 
>> 
>> Uninitialized values can be different run to run.
>> Repeatability and consistency are important.
> 
> Not forcing the programmer to obscure the meaning of the code I think
> is more important.
> 
>> 
>> 
>> I'm also nervous about us not taking a hard line on integer overflow.
>> Overflown math doesn't necessarily lead to array out of bounds soon or ever=
>> .
>> It too can lead to incorrect but safe behavior.
> 
> Similar situation is it not?  You don't generate a compiler warning
> for math that "might overflow".  
> 
> I think we can all agree that error on integer overflow, error on
> use of uninitialized variable, at runtime, would both be good things?
> 
>     Mika
> 
>> 
>> 
>> =A0- Jay
>> 
>> 
>> ----------------------------------------
>>> To: jay.krell at cornell.edu
>>> Date: Tue=2C 1 Jun 2010 20:52:26 -0700
>>> From: mika at async.async.caltech.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] [M3commit] CVS Update: cm3
>>> 
>>> 
>>> Safety is important in that it allows you to limit the possible effects
>>> of bugs. Getting programs bug-free is of course a very difficult problem
>>> no matter what you do.
>>> 
>>> But no I don't think warnings for uninitialized use of variables is
>>> something one should do in general in Modula-3. The safety guarantees
>>> lead to different idioms from in C---not so many compiler warnings
>>> are required to get your code right. And if you do screw up
>>> an uninitialized variable=2C the effect is going to be limited.
>>> Unlike what happens in C=2C where if you screw up the initialization
>>> of a pointer=2C for instance=2C all hell breaks loose.
>>> 
>>> Your example is contrived. Usually the code looks like this
>>> 
>>> VAR
>>> x : T=3B
>>> BEGIN
>>> IF cond1 THEN x :=3D ... END=3B
>>> ...
>>> IF cond2 THEN (* use x *) END
>>> END
>>> 
>>> where the programmer knows that cond2 logically implies cond1.
>>> 
>>> I think the presence of VAR parameter passing makes these sorts of
>>> warnings also less useful in Modula-3. Is the following OK?
>>> 
>>> PROCEDURE InitializeIt(VAR a : T)=3B
>>> PROCEUDRE UseIt(VALUE a : T)=3B
>>> 
>>> VAR x : T=3B
>>> BEGIN
>>> InitializeIt(x)=3B
>>> UseIt(x)
>>> END
>>> 
>>> I would think your compiler can't prove that x is initialized. Warning
>>> or not? I say no: this is actually very reasonable Modula-3 code.
>>> But then do you want a warning for the IF? It's logically the same.
>>> 
>>> There's a chapter in
>>> EWD's Discipline of Programming that deals with the problem in
>>> detail. I think he winds up with six different "modes" for variables.
>>> 
>>> Mika
>>> 
>>> Jay K writes:
>>>> 
>>>> ok=3D2C so in C:
>>>> =3D20
>>>> int F()
>>>> {
>>>> int i=3D3B
>>>> return i=3D3B
>>>> }
>>>> =3D20
>>>> should warn or not?
>>>> Prevailing wisdom is definitely.
>>>> Main known exception is code to generate random numbers.
>>>> I believe this is how Debian broke key generation.
>>>> =3D20
>>>> =3D20
>>>> Modula-3:
>>>> =3D20
>>>> =3D20
>>>> PROCEDURE F(): INTEGER =3D3D=3D20
>>>> VAR i: INTEGER=3D3B
>>>> BEGIN
>>>> RETURN i=3D3B
>>>> END F=3D3B
>>>> =3D20
>>>> =3D20
>>>> Should warn or not?
>>>> Since this identical to the C=3D2C prevailing wisdom is definitely.
>>>> =3D20
>>>> =3D20
>>>> They are=3D2C I guess=3D2C "safe"=3D2C but most likely=3D2C incorrect.
>>>> =3D20
>>>> =3D20
>>>> The compiler may have made "safety" guarantees=3D2C and they are signific=
>> ant=3D
>>>> =3D2C
>>>> but safe is far from correct=3D2C and however smart the compiler can be t=
>> o lo=3D
>>>> ok for correctness issues=3D2C is also nice.
>>>> =3D20
>>>> =3D20
>>>> =3D20
>>>> (Friend of mine conjectured something like: Safety guarantees have people=
>> d=3D
>>>> eluded. Software will still have plenty of bugs and be plenty difficult t=
>> o =3D
>>>> get correct and require plenty of testing. Safety guarantees help=3D2C bu=
>> t th=3D
>>>> ey are only a small step toward actual correctness.)
>>>> =3D20
>>>> =3D20
>>>> =3D20
>>>> - Jay
>>>> 
>>>> 
>>>> ----------------------------------------
>>>>> Subject: Re: [M3commit] CVS Update: cm3
>>>>> From: hosking at cs.purdue.edu
>>>>> Date: Tue=3D2C 1 Jun 2010 20:04:00 -0400
>>>>> CC: jkrell at elego.de=3D3B m3commit at elegosoft.com
>>>>> To: jay.krell at cornell.edu
>>>>> 
>>>>> Sure=3D2C an INTEGER is a valid value whatever the bits.
>>>>> 
>>>>> 
>>>>> On 1 Jun 2010=3D2C at 17:44=3D2C Jay K wrote:
>>>>> 
>>>>>> 
>>>>>> Start removing the rampant use of volatile in the backend and these wa=
>> rn=3D
>>>> ings show up.
>>>>>> 
>>>>>> Volatile quashes the uninitialized checks in the backend.
>>>>>> 
>>>>>> Is it really ok for an INTEGER to be uninitialized? I realize it conta=
>> in=3D
>>>> s an "integer" value=3D2C as all bit patterns are.
>>>>>> 
>>>>>> Some of these really do seem like bugs. Some do not.
>>>>>> I'll try making fault_proc noreturn=3D2C which should remove some of t=
>> hem.
>>>>>> 
>>>>>> 
>>>>>> - Jay
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> ----------------------------------------
>>>>>>> From: hosking at cs.purdue.edu
>>>>>>> To: jkrell at elego.de
>>>>>>> Date: Tue=3D2C 1 Jun 2010 16:29:20 -0500
>>>>>>> CC: m3commit at elegosoft.com
>>>>>>> Subject: Re: [M3commit] CVS Update: cm3
>>>>>>> 
>>>>>>> This is bogus. The M3 compiler guarantees all variables are initializ=
>> ed=3D
>>>> .
>>>>>>> 
>>>>>>> Sent from my iPhone
>>>>>>> 
>>>>>>> On Jun 1=3D2C 2010=3D2C at 2:42 PM=3D2C jkrell at elego.de (Jay Krell) w=
>> rote:
>>>>>>> 
>>>>>>>> CVSROOT: /usr/cvs
>>>>>>>> Changes by: jkrell at birch. 10/06/01 14:42:00
>>>>>>>> 
>>>>>>>> Modified files:
>>>>>>>> cm3/m3-libs/m3core/src/convert/: Convert.m3
>>>>>>>> 
>>>>>>>> Log message:
>>>>>>>> initialize locals=3D3B I get warnings that some not quite all=3D2C a=
>> re
>>>>>>>> used uninitialized if I remove the volatile/sideeffects on every
>>>>>>>> load/store in parse.c
>>>>> =3D
>> 		 	   		  =



From jay.krell at cornell.edu  Wed Jun  2 16:52:55 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 2 Jun 2010 14:52:55 +0000
Subject: [M3devel] warning for uninitialized variables?
In-Reply-To: <16413179-F84C-42BF-AB09-2D8294EB4782@cs.purdue.edu>
References: <20100601124200.8E42B2474003@birch.elegosoft.com>,
	, , <E86D485E-C5D5-4B7A-8142-5E0BE31280DD@cs.purdue.edu>, ,
	<COL101-W58EC381F7DE75AC44CFB57E6EF0@phx.gbl>, 
	, , <5458A114-F000-4A90-9998-FD7DF63E06C0@cs.purdue.edu>, ,
	<COL101-W3678C92B3A9FA07AD57BF2E6D00@phx.gbl>, ,
	<20100602035226.43C1F1A208F@async.async.caltech.edu>,
	<COL101-W59770EAA64E52A966D79F3E6D00@phx.gbl>,
	<20100602124422.11C6D1A209A@async.async.caltech.edu>,
	<16413179-F84C-42BF-AB09-2D8294EB4782@cs.purdue.edu>
Message-ID: <COL101-W44444F6A175254747767CFE6D00@phx.gbl>


Running with a consistent initialized/uninitialized 0 is better than running with a "random" value that you get from no initialization.
?They are both "bad".
?The 0 is agreed misleading, because it might look initialized.
? But it still better than a value that can change from run to run.


C int (or ptrdiff_t) and Modula-3 INTEGER are equivalent. They both are "valid" for any bit pattern.
C programmers always consider it a bug to use uninitialized values, except, the case I pointed out, looking for entropy to generate random numbers.

?>> The fact that a variable is uninitialized is a part of the design of the program.

Not if it can be used uninitialized.
Some of the warnings from gcc are definitive -- the values *are* used uninitialized.
Sometimes it says "is used uninitialized", sometimes it says "might be used initialized", and usually it is quiet, either because it knows it isn't used uninitialized or because it is too uncertain.


Programs are written for humans to read, true, but programs that read programs are much more diligent, energetic, and often smarter (and slowly getting smarter with age, often the opposite of humans).
Compilers really do have a big "leg" up on humans, since they can harness fast digital processor with big storage.
Granted, neither is always better than the other. But compilers/computers have far more capacity for code reading than humans and I know from experience that most code is never read by a human, not even once, until I get to it :), because the bugs I readily see wouldn't survive even a glance...
?(and the compilers often fail too, granted).


Again I'm quite surprised we want to leave uninitialized variables that get used uninitialized.
The one in cm3ide for example, if the input is malformed, I believe it uses uninitialized data.
I don't see how this can be deemed anything other than a bug to be fixed, and that we should be glad the compiler (finally) found it..now that I'm working on removing the rampant volatile...


If we can invest in runtime checks to immediately catch reads of unwritten data, then I'd favor that instead.


?- Jay

----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Wed, 2 Jun 2010 10:41:47 -0400
> To: mika at async.async.caltech.edu
> CC: m3devel at elegosoft.com; jay.krell at cornell.edu
> Subject: Re: [M3devel] warning for uninitialized variables?
>
> Hear, hear!
>
> On 2 Jun 2010, at 08:44, Mika Nystrom wrote:
>
>> Jay K writes:
>>>
>>> Wow. You really surprise me Mika.
>>>
>>>
>>> To warn on this kind of thing=2C to me=2C there is no question.
>>>
>>>
>>> Limting the affects by virtue of being safe isn't much consolation.
>>> The program can easily go down a "safe" but very incorrect path.
>>
>> It is, though! Do you always know what value to initialize the
>> variables to? If not, you're just picking some value to shut up
>> the compiler, and now your code no longer expresses---to a human
>> reader---that x is uninitialized.
>>
>> Remember, code is mainly written for humans! Computers don't care
>> about fancy structuring, declarations, etc. When you write a program,
>> you write it to be read by a human. The fact that a variable is
>> uninitialized is a part of the design of the program.
>>
>> It's an unfortunate fact that our languages don't have all the
>> mechanisms necessary to deal properly with uninitialized variables.
>> Retrofitting mechanisms to something that just isn't expressive
>> enough to solve the problem I really don't think is the way to go.
>>
>> EWD's book chapter... read it. "An essay on the scope of variables"
>> I think it is called.
>>
>>
>>>
>>>
>>> There are several forms.
>>> In fact=2C sometimes the compiler says something "is" used uninitialized.
>>> Sometimes it says "maybe".
>>>
>>>
>>> In your example=2C generally=2C once the address is taken of a variable=2C
>>> the compiler gives up. Esp. if that address is passed to a function it does=
>>> n't "see".
>>
>> As long as this doesn't raise warnings I can live with your warnings...
>>
>> ...
>>>
>>>
>>> There are many more warnings in the tree than I have yet looked at.
>>> I've seen a few forms.
>>> Some are because the compiler doesn't know that some functions don't return=
>>> .
>>> I'll see about improving that. Though I think there's a limit to how good I=
>>> can manage=2C
>>> unless we add a <* noreturn *> pragma.
>>
>> adding <*ASSERT FALSE*> in the right places might fix these warnings.
>>
>> ...
>>>
>>>
>>> I grant that by initializing to 0=2C I haven't necessarily made the code co=
>>> rrect either.
>>> But at least it is now consistent.
>>>
>>>
>>> Even better would be runtime checks that stop if a variable is read before =
>>> written.
>>
>> Which you have just defeated with your initialization!
>>
>> I know that my Modula code will outlive its current compiler. Probably
>> by a long time. Once you add the initialization you're talking about,
>> you can't go back. It no longer expresses the useful property you're
>> trying to check. When the new compiler comes along with its runtime
>> check, it will miss that my variables are actually uninitialized.
>>
>>>
>>>
>>> See also the rules in Java and C# that require the compiler to be able to p=
>>> rove
>>> a variable is written before read. Possibly even verifiable at load time.
>>
>> I *hate* this. See above.
>>
>> What's next? The compiler refuses to compile loops that it can't
>> prove will terminate??? Hogwash!
>>
>>>
>>>
>>> Other forms look related to going "through" a switch statement with no arms=
>>> handling the value.
>>> I think I can address that by marking fault_proc as noreturn.
>>>
>>>
>>> One form apparently in cm3ide would use uninitialized data if presented wit=
>>> h a malformed file.
>>> Good software doesn't depend on the well formedness of its input.
>>>
>>> There are many more warnings like this in the tree.
>>>
>>>
>>> My inclination is at least to temporarily hardcode the gcc backend to alway=
>>> s optimize=2C
>>> and always produce these warnings. People can look over them maybe and deci=
>>> de.
>>> Or they can look over my "fixes".
>>>
>>>
>>> Or I guess if people really really really really prefer=2C we can always tu=
>>> rn off the warnings
>>> and let the code lie. I really think that is the wrong answer.
>>>
>>>
>>> I have been burned too much by uninitialized locals in C.
>>> I put " =3D { 0 }" after everything.
>>> Again=2C that isn't necessarily "correct"=2C but at least the incorrect pat=
>>> hs are consistent.
>>> If they don't work and I happen down them=2C they will guaranteeably not wo=
>>> rk.
>>
>> No they will just consistently not work. Not "guaranteeably". You have
>> to initialize them to some specific value for that to be the case.
>> Using "0" often will just give you the wrong answer!
>>
>>>
>>>
>>> Uninitialized values can be different run to run.
>>> Repeatability and consistency are important.
>>
>> Not forcing the programmer to obscure the meaning of the code I think
>> is more important.
>>
>>>
>>>
>>> I'm also nervous about us not taking a hard line on integer overflow.
>>> Overflown math doesn't necessarily lead to array out of bounds soon or ever=
>>> .
>>> It too can lead to incorrect but safe behavior.
>>
>> Similar situation is it not? You don't generate a compiler warning
>> for math that "might overflow".
>>
>> I think we can all agree that error on integer overflow, error on
>> use of uninitialized variable, at runtime, would both be good things?
>>
>> Mika
>>
>>>
>>>
>>> =A0- Jay
>>>
>>>
>>> ----------------------------------------
>>>> To: jay.krell at cornell.edu
>>>> Date: Tue=2C 1 Jun 2010 20:52:26 -0700
>>>> From: mika at async.async.caltech.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] [M3commit] CVS Update: cm3
>>>>
>>>>
>>>> Safety is important in that it allows you to limit the possible effects
>>>> of bugs. Getting programs bug-free is of course a very difficult problem
>>>> no matter what you do.
>>>>
>>>> But no I don't think warnings for uninitialized use of variables is
>>>> something one should do in general in Modula-3. The safety guarantees
>>>> lead to different idioms from in C---not so many compiler warnings
>>>> are required to get your code right. And if you do screw up
>>>> an uninitialized variable=2C the effect is going to be limited.
>>>> Unlike what happens in C=2C where if you screw up the initialization
>>>> of a pointer=2C for instance=2C all hell breaks loose.
>>>>
>>>> Your example is contrived. Usually the code looks like this
>>>>
>>>> VAR
>>>> x : T=3B
>>>> BEGIN
>>>> IF cond1 THEN x :=3D ... END=3B
>>>> ...
>>>> IF cond2 THEN (* use x *) END
>>>> END
>>>>
>>>> where the programmer knows that cond2 logically implies cond1.
>>>>
>>>> I think the presence of VAR parameter passing makes these sorts of
>>>> warnings also less useful in Modula-3. Is the following OK?
>>>>
>>>> PROCEDURE InitializeIt(VAR a : T)=3B
>>>> PROCEUDRE UseIt(VALUE a : T)=3B
>>>>
>>>> VAR x : T=3B
>>>> BEGIN
>>>> InitializeIt(x)=3B
>>>> UseIt(x)
>>>> END
>>>>
>>>> I would think your compiler can't prove that x is initialized. Warning
>>>> or not? I say no: this is actually very reasonable Modula-3 code.
>>>> But then do you want a warning for the IF? It's logically the same.
>>>>
>>>> There's a chapter in
>>>> EWD's Discipline of Programming that deals with the problem in
>>>> detail. I think he winds up with six different "modes" for variables.
>>>>
>>>> Mika
>>>>
>>>> Jay K writes:
>>>>>
>>>>> ok=3D2C so in C:
>>>>> =3D20
>>>>> int F()
>>>>> {
>>>>> int i=3D3B
>>>>> return i=3D3B
>>>>> }
>>>>> =3D20
>>>>> should warn or not?
>>>>> Prevailing wisdom is definitely.
>>>>> Main known exception is code to generate random numbers.
>>>>> I believe this is how Debian broke key generation.
>>>>> =3D20
>>>>> =3D20
>>>>> Modula-3:
>>>>> =3D20
>>>>> =3D20
>>>>> PROCEDURE F(): INTEGER =3D3D=3D20
>>>>> VAR i: INTEGER=3D3B
>>>>> BEGIN
>>>>> RETURN i=3D3B
>>>>> END F=3D3B
>>>>> =3D20
>>>>> =3D20
>>>>> Should warn or not?
>>>>> Since this identical to the C=3D2C prevailing wisdom is definitely.
>>>>> =3D20
>>>>> =3D20
>>>>> They are=3D2C I guess=3D2C "safe"=3D2C but most likely=3D2C incorrect.
>>>>> =3D20
>>>>> =3D20
>>>>> The compiler may have made "safety" guarantees=3D2C and they are signific=
>>> ant=3D
>>>>> =3D2C
>>>>> but safe is far from correct=3D2C and however smart the compiler can be t=
>>> o lo=3D
>>>>> ok for correctness issues=3D2C is also nice.
>>>>> =3D20
>>>>> =3D20
>>>>> =3D20
>>>>> (Friend of mine conjectured something like: Safety guarantees have people=
>>> d=3D
>>>>> eluded. Software will still have plenty of bugs and be plenty difficult t=
>>> o =3D
>>>>> get correct and require plenty of testing. Safety guarantees help=3D2C bu=
>>> t th=3D
>>>>> ey are only a small step toward actual correctness.)
>>>>> =3D20
>>>>> =3D20
>>>>> =3D20
>>>>> - Jay
>>>>>
>>>>>
>>>>> ----------------------------------------
>>>>>> Subject: Re: [M3commit] CVS Update: cm3
>>>>>> From: hosking at cs.purdue.edu
>>>>>> Date: Tue=3D2C 1 Jun 2010 20:04:00 -0400
>>>>>> CC: jkrell at elego.de=3D3B m3commit at elegosoft.com
>>>>>> To: jay.krell at cornell.edu
>>>>>>
>>>>>> Sure=3D2C an INTEGER is a valid value whatever the bits.
>>>>>>
>>>>>>
>>>>>> On 1 Jun 2010=3D2C at 17:44=3D2C Jay K wrote:
>>>>>>
>>>>>>>
>>>>>>> Start removing the rampant use of volatile in the backend and these wa=
>>> rn=3D
>>>>> ings show up.
>>>>>>>
>>>>>>> Volatile quashes the uninitialized checks in the backend.
>>>>>>>
>>>>>>> Is it really ok for an INTEGER to be uninitialized? I realize it conta=
>>> in=3D
>>>>> s an "integer" value=3D2C as all bit patterns are.
>>>>>>>
>>>>>>> Some of these really do seem like bugs. Some do not.
>>>>>>> I'll try making fault_proc noreturn=3D2C which should remove some of t=
>>> hem.
>>>>>>>
>>>>>>>
>>>>>>> - Jay
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ----------------------------------------
>>>>>>>> From: hosking at cs.purdue.edu
>>>>>>>> To: jkrell at elego.de
>>>>>>>> Date: Tue=3D2C 1 Jun 2010 16:29:20 -0500
>>>>>>>> CC: m3commit at elegosoft.com
>>>>>>>> Subject: Re: [M3commit] CVS Update: cm3
>>>>>>>>
>>>>>>>> This is bogus. The M3 compiler guarantees all variables are initializ=
>>> ed=3D
>>>>> .
>>>>>>>>
>>>>>>>> Sent from my iPhone
>>>>>>>>
>>>>>>>> On Jun 1=3D2C 2010=3D2C at 2:42 PM=3D2C jkrell at elego.de (Jay Krell) w=
>>> rote:
>>>>>>>>
>>>>>>>>> CVSROOT: /usr/cvs
>>>>>>>>> Changes by: jkrell at birch. 10/06/01 14:42:00
>>>>>>>>>
>>>>>>>>> Modified files:
>>>>>>>>> cm3/m3-libs/m3core/src/convert/: Convert.m3
>>>>>>>>>
>>>>>>>>> Log message:
>>>>>>>>> initialize locals=3D3B I get warnings that some not quite all=3D2C a=
>>> re
>>>>>>>>> used uninitialized if I remove the volatile/sideeffects on every
>>>>>>>>> load/store in parse.c
>>>>>> =3D
>>> =
>
 		 	   		  

From hosking at cs.purdue.edu  Wed Jun  2 17:02:15 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 2 Jun 2010 11:02:15 -0400
Subject: [M3devel] ADR is *too* unsafe..
In-Reply-To: <COL101-W444318DF7FE046C2AE542AE6D00@phx.gbl>
References: <COL101-W617B9602E6CAA0BBE5BE25E6D00@phx.gbl>,
	<A8CEEB02-D279-4C90-B8D3-5D163619C748@cs.purdue.edu>
	<COL101-W444318DF7FE046C2AE542AE6D00@phx.gbl>
Message-ID: <67147BA0-0307-45FB-B646-588B55EDACC3@cs.purdue.edu>

Actually, the compiler already has support to do exactly what you want.  Take a look at the flag Host.new_adr.  This implements:

ADR (t: T): UNTRACED REF T



On 2 Jun 2010, at 10:07, Jay K wrote:

> 
> The compiler doesn't break. Mentor does, networking stuff. I fixed it. But I would have
> expected the compiler to have told me about it.
> It is unfortunate. ADR should be *slightly* safer.
> Maybe we can get a warning for this? passing ADR(foo) to untraced ref bar?
> It seems...quite unfortunate that the language is defined this way..
> 
>  - Jay
> 
> 
> ----------------------------------------
>> From: hosking at cs.purdue.edu
>> Date: Wed, 2 Jun 2010 10:01:09 -0400
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] ADR is *too* unsafe..
>> 
>> Why does the compiler break?
>> Yes, VAR is *much* safer.
>> 
>> On 2 Jun 2010, at 03:41, Jay K wrote:
>> 
>>> 
>>> (*
>>> Wow, ADR generates a plain ADDRESS, not an untraced ref to a specific type?
>>> Doesn't this seem wrong? Doesn't unsafe code deserve a little better, say,
>>> to be at least as typesafe as C?
>>> http://www.cs.purdue.edu/homes/hosking/m3/reference/unsafe.html
>>> 
>>> This is why 64bit m3-comm/tcp/src/TCP.m3 breaks randomly
>>> on some platforms on an assertion failure in C. And the
>>> compiler isn't going to help me find these type mismatches? Ugh.
>>> 
>>> This seems wrong. :(
>>> 
>>> I guess I should really really use VAR then.
>>> *)
>>> 
>>> 
>>> UNSAFE MODULE Main;
>>> IMPORT Ctypes, Cstddef;
>>> 
>>> 
>>> PROCEDURE F1(a:UNTRACED REF Ctypes.int) =
>>> BEGIN
>>> F2(a); (* error, expected *)
>>> END F1;
>>> 
>>> 
>>> PROCEDURE F2(a:UNTRACED REF Cstddef.size_t) =
>>> BEGIN
>>> F1(a); (* error, expected *)
>>> END F2;
>>> 
>>> 
>>> VAR c:Ctypes.int;
>>> d:Cstddef.size_t;
>>> 
>>> 
>>> BEGIN
>>> F1(ADR(c)); (* ok *)
>>> F1(ADR(d)); (* error expected but no *)
>>> F2(ADR(c)); (* error expected but no *)
>>> F2(ADR(d)); (* ok *)
>>> END Main.
>>> 
>>> 
>>> 
>>> - Jay
>>> 
>> 
> 		 	   		  



From hosking at cs.purdue.edu  Wed Jun  2 17:02:54 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 2 Jun 2010 11:02:54 -0400
Subject: [M3devel] SOLgnu/SOLsun -O1/-O2/-O3
In-Reply-To: <COL101-W26B2AF5D865D1A694793DAE6D00@phx.gbl>
References: <COL101-W26B2AF5D865D1A694793DAE6D00@phx.gbl>
Message-ID: <C793D9CD-5C57-49D8-927D-26EBDEAFE0AB@cs.purdue.edu>

Yes, worked for me using -O3.


On 2 Jun 2010, at 09:01, Jay K wrote:

> 
> Anyone recall if SOLgnu/sun work with any optimization?
>   You know -- the platforms that have a stack walker and don't use setjmp.
> I tried leaving them having all loads/stores be volatile, except handling still doesn't work -- cm3 gets an unhandled exception instead of saying cm3.cfg not found.
> I'll have to test with an old clean version.
> Could be I'm missing something, or maybe the m3cg_pop change broke them.
> 
> 
>  - Jay
> 
> 		 	   		  



From hosking at cs.purdue.edu  Wed Jun  2 17:04:09 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 2 Jun 2010 11:04:09 -0400
Subject: [M3devel] reducing use of volatile in backend?
In-Reply-To: <COL101-W35361E5B4C86598DB49C90E6D00@phx.gbl>
References: <COL101-W17AA739AA2DE2050C6CCD0E6EF0@phx.gbl>,
	<AA1F4490-A9C7-4F94-8E03-65A5E9031424@cs.purdue.edu>
	<COL101-W35361E5B4C86598DB49C90E6D00@phx.gbl>
Message-ID: <B09FDA2E-FBC9-473F-B311-283F9D573568@cs.purdue.edu>



On 2 Jun 2010, at 10:30, Jay K wrote:

> 
> attached is the diff I'm working on.
> 
> 
> It works well on a few platforms.
> I've been using it on AMD64_DARWIN.
> Cross I386_LINUX, PPC_DARWIN cm3 startup and give
>   the correct message, which requires exception handling to work.
> 
> 
> SOLgnu exception handling doesn't work.

Possibly needs a register window flush?  I'm only speculating here.

> MIPS64_OPENBSD internal errors a bunch in the compiler.
>   Probably don't care. Don't know if it was working before.
> 
> Still to do:
>   figure out what is up with SOLgnu/SOLsun
> 
> 
> Not ideal but I think ok for now:
>   volatizing all floating point
>     We already were, though granted possibly with more optimizations.
>   flag_unit_at_a_time = 0
> 
>   
> flag_unit_at_a_time isn't "tricky" or subtle,
> but it does remove a function we want to take the address of.
> I couldn't find a way to get it to keep the function.
> 
> 
> What I think is fine for a while:
>   flag_tree_vrp = 0;
>   flag_tree_pre = 0;
>   flag_tree_fre = 0;
> 
>   
> Maybe it doesn't take much to let them work?
> Maybe wait until 4.5 is working and try again there?
>   In particular pre/fre only fail in one file among m3core/libm3, Formater.m3.
>   vrp is what silently produces non-working code.
>   It is either the only one, or one of pre/fre also do.
>   At least one of pre/fre crash, accessing null pointer.
> 
>  
> and probably also ok for a "while":
>  flag_tree_loop_im = 0
>  flag_schedule_insns = 0
> 
>  
> though for flag_schedule_insns = 0 to fail seems odd,
> and flag_tree_loop_im only broke in a little code, should
> probably look at that code.
> 
> 
> Oh and I still need to see about fours/badbricks recieving mouse clicks.
> Mine aren't.
> 
> 
> The TREE_ADDRESSABLE change in m3_write_globals was needed to get SOLgnu
> to compiler. The assert failed.
> 
> 
> We might want to have the frontend tell the backend if the
> target has a stack walker, instead of the logic I have here.
> 
> 
> While it is not ideal, I think this will let -O1/2/3 generate code much more like people expect, without
> constantly reloading registers from the stack.
> 
> 
>  - Jay
> 
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: hosking at cs.purdue.edu
>> CC: m3devel at elegosoft.com
>> Subject: RE: [M3devel] reducing use of volatile in backend?
>> Date: Tue, 1 Jun 2010 21:55:31 +0000
>> 
>> 
>> I've had *a lot* of success here the past few hours.
>> 
>> 
>> There is an assert starting up mentor I need to look at, possibly out of data binaries.
>> The one in socket.c assert(lossless_socklen || socklen == null || socklen < 1<<30.
>> 
>> 
>> Compiler seems to work.
>> Lots of things do break it, so that is something.
>> 
>> 
>> Various gui apps startup.
>> Some of the gui apps don't work, but nor did older copies I had -- fours, badbricks, and I think columns, wouldn't take any mouse clicks. I have to test older versions. Could be unrelated.
>> 
>> 
>> 
>> Here is what I have:
>> 
>> The vast vast majority of optimizations can be enabled.
>> 
>> Nearly all uses of volatile can be removed.
>> 
>> Just a few optimizations "need" to be disabled.
>> 
>> In particular:
>> I only have volatile remaining:
>> on store after insert_mn (special case)
>> 
>> floating point (huh? wierd)
>> compile errors without this
>> 
>> in functions that call setjmp or vfork
>> This is very reasonable, but we should try to limit it to not all the variables, only what are accessed after the second return (I'm not sure how that computes for vfork, but for setjmp it makes sense to me.
>> 
>> 
>> on the load/store in loophole
>> compile errors without this; perhaps redundant with the floating point check
>> 
>> 
>> on load link, else it gets uninitialized warning
>> 
>> 
>> 
>> Also I found a likely bug.
>> In functions that call setjmp/vfork, we volatize already seen parameters and locals, but we don't volatize not yet seen locals (in nested blocks) and temporaries. I fixed that.
>> 
>> 
>> 
>> 
>> The optimizations I disabled, from memory:
>> 
>> 
>> pre - partial redundancy elimination
>> 
>> 
>> fre - full redundancy elimination (these are related)
>> One or both of these causes the compiler to access violate in the optimizer, compiling libm3/Formatter.mc, but otherwise I think they compile m3core and libm3 entirely
>> 
>> 
>> loop im (induction motion) - caused a compile error in Trestle
>> 
>> vrp - value range propagation
>> This seems to be the biggest problem, no compile errors but "random" runtime malfunction, usually starting up cm3.
>> 
>> 
>> insn_sched - wierd, caused a compile break
>> but insn_sched_after_reload ok
>> 
>> 
>> That's about it. All the ones with "alias" in them, only like two, I enabled, seemed ok.
>> salias and strict_alias. I left strict alias till late in experimentation but really it seems ok.
>> 
>> 
>> I can compile the entire system, though I get lots of warnings about uninitialized variables.
>> I pass the backend the -Wuninitialized flag.
>> 
>> 
>> I test it out more -- the gui non-interaction, the mentor assert, and test other platforms.
>> But I think we'll have volatile mostly gone and just a small number of optimizations turned off fairly soon.
>> We can iterate more on the remaining optimizations.
>> 
>> 
>> Getting good typeinfo would be good so that gdb can debug.
>> And maybe so that other than stabs works.
>> 
>> 
>> - Jay
>> 
>> 
>> 
>> 
>> ----------------------------------------
>>> From: hosking at cs.purdue.edu
>>> To: jay.krell at cornell.edu
>>> Date: Tue, 1 Jun 2010 16:05:30 -0500
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] reducing use of volatile in backend?
>>> 
>>> We don't want to disable optimisations for types where it makes sense
>>> to have them. Better to smarten up typebased alias analysis instead so
>>> we can get rid of volatile properly.
>>> 
>>> Sent from my iPhone
>>> 
>>> On Jun 1, 2010, at 12:16 PM, Jay K wrote:
>>> 
>>>> 
>>>> Tony, would we maybe be better off not using volatile everywhere but
>>>> selectively turning off optimizations in m3_post_options?
>>>> You know, using volatile probably disables more than necessary?
>>>> I'm experimenting with this.
>>>> 
>>>> - Jay
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
> 		 	   		  <less-volatile.txt>

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

From hosking at cs.purdue.edu  Wed Jun  2 17:06:23 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 2 Jun 2010 11:06:23 -0400
Subject: [M3devel] warning for uninitialized variables?
In-Reply-To: <COL101-W44444F6A175254747767CFE6D00@phx.gbl>
References: <20100601124200.8E42B2474003@birch.elegosoft.com>, , ,
	<E86D485E-C5D5-4B7A-8142-5E0BE31280DD@cs.purdue.edu>, ,
	<COL101-W58EC381F7DE75AC44CFB57E6EF0@phx.gbl>, , ,
	<5458A114-F000-4A90-9998-FD7DF63E06C0@cs.purdue.edu>, ,
	<COL101-W3678C92B3A9FA07AD57BF2E6D00@phx.gbl>, ,
	<20100602035226.43C1F1A208F@async.async.caltech.edu>,
	<COL101-W59770EAA64E52A966D79F3E6D00@phx.gbl>,
	<20100602124422.11C6D1A209A@async.async.caltech.edu>,
	<16413179-F84C-42BF-AB09-2D8294EB4782@cs.purdue.edu>
	<COL101-W44444F6A175254747767CFE6D00@phx.gbl>
Message-ID: <5EDDD7E5-C33E-4BD1-A036-2D3561F08277@cs.purdue.edu>

On 2 Jun 2010, at 10:52, Jay K wrote:

> If we can invest in runtime checks to immediately catch reads of unwritten data, then I'd favor that instead.

YUCK!



From hosking at cs.purdue.edu  Wed Jun  2 17:08:55 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 2 Jun 2010 11:08:55 -0400
Subject: [M3devel] ADR is *too* unsafe..
In-Reply-To: <67147BA0-0307-45FB-B646-588B55EDACC3@cs.purdue.edu>
References: <COL101-W617B9602E6CAA0BBE5BE25E6D00@phx.gbl>,
	<A8CEEB02-D279-4C90-B8D3-5D163619C748@cs.purdue.edu>
	<COL101-W444318DF7FE046C2AE542AE6D00@phx.gbl>
	<67147BA0-0307-45FB-B646-588B55EDACC3@cs.purdue.edu>
Message-ID: <833AEC0D-7CAD-4E2E-A99D-C12F5C0DD870@cs.purdue.edu>

Also, I meant to point to:

http://www.modula3.org/threads/3/#advancedTopic

On 2 Jun 2010, at 11:02, Tony Hosking wrote:

> Actually, the compiler already has support to do exactly what you want.  Take a look at the flag Host.new_adr.  This implements:
> 
> ADR (t: T): UNTRACED REF T
> 
> 
> 
> On 2 Jun 2010, at 10:07, Jay K wrote:
> 
>> 
>> The compiler doesn't break. Mentor does, networking stuff. I fixed it. But I would have
>> expected the compiler to have told me about it.
>> It is unfortunate. ADR should be *slightly* safer.
>> Maybe we can get a warning for this? passing ADR(foo) to untraced ref bar?
>> It seems...quite unfortunate that the language is defined this way..
>> 
>> - Jay
>> 
>> 
>> ----------------------------------------
>>> From: hosking at cs.purdue.edu
>>> Date: Wed, 2 Jun 2010 10:01:09 -0400
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] ADR is *too* unsafe..
>>> 
>>> Why does the compiler break?
>>> Yes, VAR is *much* safer.
>>> 
>>> On 2 Jun 2010, at 03:41, Jay K wrote:
>>> 
>>>> 
>>>> (*
>>>> Wow, ADR generates a plain ADDRESS, not an untraced ref to a specific type?
>>>> Doesn't this seem wrong? Doesn't unsafe code deserve a little better, say,
>>>> to be at least as typesafe as C?
>>>> http://www.cs.purdue.edu/homes/hosking/m3/reference/unsafe.html
>>>> 
>>>> This is why 64bit m3-comm/tcp/src/TCP.m3 breaks randomly
>>>> on some platforms on an assertion failure in C. And the
>>>> compiler isn't going to help me find these type mismatches? Ugh.
>>>> 
>>>> This seems wrong. :(
>>>> 
>>>> I guess I should really really use VAR then.
>>>> *)
>>>> 
>>>> 
>>>> UNSAFE MODULE Main;
>>>> IMPORT Ctypes, Cstddef;
>>>> 
>>>> 
>>>> PROCEDURE F1(a:UNTRACED REF Ctypes.int) =
>>>> BEGIN
>>>> F2(a); (* error, expected *)
>>>> END F1;
>>>> 
>>>> 
>>>> PROCEDURE F2(a:UNTRACED REF Cstddef.size_t) =
>>>> BEGIN
>>>> F1(a); (* error, expected *)
>>>> END F2;
>>>> 
>>>> 
>>>> VAR c:Ctypes.int;
>>>> d:Cstddef.size_t;
>>>> 
>>>> 
>>>> BEGIN
>>>> F1(ADR(c)); (* ok *)
>>>> F1(ADR(d)); (* error expected but no *)
>>>> F2(ADR(c)); (* error expected but no *)
>>>> F2(ADR(d)); (* ok *)
>>>> END Main.
>>>> 
>>>> 
>>>> 
>>>> - Jay
>>>> 
>>> 
>> 		 	   		  
> 



From jay.krell at cornell.edu  Wed Jun  2 17:13:55 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 2 Jun 2010 15:13:55 +0000
Subject: [M3devel] warning for uninitialized variables?
In-Reply-To: <5EDDD7E5-C33E-4BD1-A036-2D3561F08277@cs.purdue.edu>
References: <20100601124200.8E42B2474003@birch.elegosoft.com>, ,
	,,<E86D485E-C5D5-4B7A-8142-5E0BE31280DD@cs.purdue.edu>,
	,,<COL101-W58EC381F7DE75AC44CFB57E6EF0@phx.gbl>, ,
	,,<5458A114-F000-4A90-9998-FD7DF63E06C0@cs.purdue.edu>,
	,,<COL101-W3678C92B3A9FA07AD57BF2E6D00@phx.gbl>,
	, , <20100602035226.43C1F1A208F@async.async.caltech.edu>, ,
	<COL101-W59770EAA64E52A966D79F3E6D00@phx.gbl>, ,
	<20100602124422.11C6D1A209A@async.async.caltech.edu>, ,
	<16413179-F84C-42BF-AB09-2D8294EB4782@cs.purdue.edu>,
	<COL101-W44444F6A175254747767CFE6D00@phx.gbl>,
	<5EDDD7E5-C33E-4BD1-A036-2D3561F08277@cs.purdue.edu>
Message-ID: <COL101-W40BE08A256108863A44C5FE6D00@phx.gbl>


Well, I'm certainly not lobbying hard for that, presumably there is no efficient implementation, esp. for full range integers.

Wikipedia has a nice article. "nice" means "agrees with me".


http://en.wikipedia.org/wiki/Uninitialized_variable
"it is a programming error and a common source of bugs in software."


And then they point out how Java requires mechanically verified initialization of locals.

The code:
void F(bool a)
?int i;
?if (a)
?? i = 0;
if (a)
? print(i)


is I believe illegal.


?- Jay


----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Wed, 2 Jun 2010 11:06:23 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] warning for uninitialized variables?
>
> On 2 Jun 2010, at 10:52, Jay K wrote:
>
>> If we can invest in runtime checks to immediately catch reads of unwritten data, then I'd favor that instead.
>
> YUCK!
>
 		 	   		  

From jay.krell at cornell.edu  Wed Jun  2 17:18:22 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 2 Jun 2010 15:18:22 +0000
Subject: [M3devel] ADR is *too* unsafe..
In-Reply-To: <833AEC0D-7CAD-4E2E-A99D-C12F5C0DD870@cs.purdue.edu>
References: <COL101-W617B9602E6CAA0BBE5BE25E6D00@phx.gbl>, ,
	<A8CEEB02-D279-4C90-B8D3-5D163619C748@cs.purdue.edu>,
	<COL101-W444318DF7FE046C2AE542AE6D00@phx.gbl>,
	<67147BA0-0307-45FB-B646-588B55EDACC3@cs.purdue.edu>,
	<833AEC0D-7CAD-4E2E-A99D-C12F5C0DD870@cs.purdue.edu>
Message-ID: <COL101-W259EC30CD3362F448A983DE6D00@phx.gbl>


Cool.

?> but also modified the front-end of the compiler to generate C
header files for Modula-3 interface files.
?> This way, procedures exported via a
Modula-3 interface can be called directly from C using "module dot method"
syntax


I've been wanting that. :)

?> "CVAR"

Sounds like a good small change?

?- Jay


----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Wed, 2 Jun 2010 11:08:55 -0400
> To: hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com; jay.krell at cornell.edu
> Subject: Re: [M3devel] ADR is *too* unsafe..
>
> Also, I meant to point to:
>
> http://www.modula3.org/threads/3/#advancedTopic
>
> On 2 Jun 2010, at 11:02, Tony Hosking wrote:
>
>> Actually, the compiler already has support to do exactly what you want. Take a look at the flag Host.new_adr. This implements:
>>
>> ADR (t: T): UNTRACED REF T
>>
>>
>>
>> On 2 Jun 2010, at 10:07, Jay K wrote:
>>
>>>
>>> The compiler doesn't break. Mentor does, networking stuff. I fixed it. But I would have
>>> expected the compiler to have told me about it.
>>> It is unfortunate. ADR should be *slightly* safer.
>>> Maybe we can get a warning for this? passing ADR(foo) to untraced ref bar?
>>> It seems...quite unfortunate that the language is defined this way..
>>>
>>> - Jay
>>>
>>>
>>> ----------------------------------------
>>>> From: hosking at cs.purdue.edu
>>>> Date: Wed, 2 Jun 2010 10:01:09 -0400
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] ADR is *too* unsafe..
>>>>
>>>> Why does the compiler break?
>>>> Yes, VAR is *much* safer.
>>>>
>>>> On 2 Jun 2010, at 03:41, Jay K wrote:
>>>>
>>>>>
>>>>> (*
>>>>> Wow, ADR generates a plain ADDRESS, not an untraced ref to a specific type?
>>>>> Doesn't this seem wrong? Doesn't unsafe code deserve a little better, say,
>>>>> to be at least as typesafe as C?
>>>>> http://www.cs.purdue.edu/homes/hosking/m3/reference/unsafe.html
>>>>>
>>>>> This is why 64bit m3-comm/tcp/src/TCP.m3 breaks randomly
>>>>> on some platforms on an assertion failure in C. And the
>>>>> compiler isn't going to help me find these type mismatches? Ugh.
>>>>>
>>>>> This seems wrong. :(
>>>>>
>>>>> I guess I should really really use VAR then.
>>>>> *)
>>>>>
>>>>>
>>>>> UNSAFE MODULE Main;
>>>>> IMPORT Ctypes, Cstddef;
>>>>>
>>>>>
>>>>> PROCEDURE F1(a:UNTRACED REF Ctypes.int) =
>>>>> BEGIN
>>>>> F2(a); (* error, expected *)
>>>>> END F1;
>>>>>
>>>>>
>>>>> PROCEDURE F2(a:UNTRACED REF Cstddef.size_t) =
>>>>> BEGIN
>>>>> F1(a); (* error, expected *)
>>>>> END F2;
>>>>>
>>>>>
>>>>> VAR c:Ctypes.int;
>>>>> d:Cstddef.size_t;
>>>>>
>>>>>
>>>>> BEGIN
>>>>> F1(ADR(c)); (* ok *)
>>>>> F1(ADR(d)); (* error expected but no *)
>>>>> F2(ADR(c)); (* error expected but no *)
>>>>> F2(ADR(d)); (* ok *)
>>>>> END Main.
>>>>>
>>>>>
>>>>>
>>>>> - Jay
>>>>>
>>>>
>>>
>>
>
 		 	   		  

From mika at async.async.caltech.edu  Wed Jun  2 17:32:20 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Wed, 02 Jun 2010 08:32:20 -0700
Subject: [M3devel] warning for uninitialized variables?
In-Reply-To: <COL101-W40BE08A256108863A44C5FE6D00@phx.gbl> 
Message-ID: <20100602153220.A4A041A209D@async.async.caltech.edu>

Jay K writes:
>
>Well=2C I'm certainly not lobbying hard for that=2C presumably there is no =
>efficient implementation=2C esp. for full range integers.
>
>Wikipedia has a nice article. "nice" means "agrees with me".
>
>
>http://en.wikipedia.org/wiki/Uninitialized_variable
>"it is a programming error and a common source of bugs in software."

I don't think anyone disagrees too strongly with that, Jay, but
the question is what can be done about it.  I think the sad answer
is, "not much."

>
>
>And then they point out how Java requires mechanically verified initializat=
>ion of locals.

One might equally well say that an infinite loop is a programming error
and a common source of bugs in software.

Some good people, accordingly, insist that every loop be accompanied by
a proof of termination.

The difference is, of course, that it is obvious that there are
useful loops that we cannot ever expect a compiler to be able to prove
termination of (on its own), whereas "some people feel" that there are
no useful ways of initializing variables that could not be verified
correct by a particular implementation of the Java compiler.

I think that if you take a step back from the problems you will see
they are in fact the same problem: they both breach the "undecidability
barrier".  This is because we haven't put enough information in the
variable declarations themselves to deduce what is wanted.  EWD's chapter
is a start on that---how to do this statically.  (That's the last time
I'm going to plug that chapter, I promise.) 

Modula-3 actually has some very nice mechanisms for avoiding uninitialized
variables.  The ability to declare/initialize a variable from an
expression without providing an explicit type is one.  WITH is another.
I almost never have problems with uninitialized variables in my Modula-3
programs.  Almost...

    Mika


From mika at async.async.caltech.edu  Wed Jun  2 17:37:04 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Wed, 02 Jun 2010 08:37:04 -0700
Subject: [M3devel] ADR is *too* unsafe..
In-Reply-To: <COL101-W259EC30CD3362F448A983DE6D00@phx.gbl> 
References: <COL101-W617B9602E6CAA0BBE5BE25E6D00@phx.gbl>, ,
	<A8CEEB02-D279-4C90-B8D3-5D163619C748@cs.purdue.edu>,
	<COL101-W444318DF7FE046C2AE542AE6D00@phx.gbl>,
	<67147BA0-0307-45FB-B646-588B55EDACC3@cs.purdue.edu>,
	<833AEC0D-7CAD-4E2E-A99D-C12F5C0DD870@cs.purdue.edu>
	<COL101-W259EC30CD3362F448A983DE6D00@phx.gbl>
Message-ID: <20100602153704.7645A1A209F@async.async.caltech.edu>

Jay K writes:
>
>Cool.
>
>=A0> but also modified the front-end of the compiler to generate C
>header files for Modula-3 interface files.
>=A0> This way=2C procedures exported via a
>Modula-3 interface can be called directly from C using "module dot method"
>syntax
>
>
>I've been wanting that. :)

What do you want it to do?

My Modula-Scheme system does this for Scheme already.. in fact it's
probably doing something even more complicated than what you want... hmm.
I've been meaning to check it in somewhere for a long time.

     Mika

>
>=A0> "CVAR"
>
>Sounds like a good small change?
>
>=A0- Jay
>
>
...


From jay.krell at cornell.edu  Wed Jun  2 17:42:41 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 2 Jun 2010 15:42:41 +0000
Subject: [M3devel] warning for uninitialized variables?
In-Reply-To: <20100602153220.A4A041A209D@async.async.caltech.edu>
References: <COL101-W40BE08A256108863A44C5FE6D00@phx.gbl>
	,<20100602153220.A4A041A209D@async.async.caltech.edu>
Message-ID: <COL101-W5218B47FE71F77410C9668E6D00@phx.gbl>


I've looked but can't quite find the paper. I found its "number".
Modula-3 ... I think beats C, because I can specify initializers for records, and subranges and enums are initialized.
C++ is more general and nice though since I can specificy initialization functions for types. Not as unenforced convention as in Modula-3, but enforced because the compiler makes the calls. Though Modula-3 does at least have the compiler generally do some initialization.


"what to do about it", well, compilers these days can tell us.
I/we have to go through the warnings that my upcoming change generate. A fair number.
But I/we should wait until I also have fault_proc marked as "noreturn", since that should help reduce them.
And maybe maybe even add <* noreturn *> pragma or such, since I know there cases like:
? (possibly the front end figures it out by seeing what you call, but still need to communicate it down)


if x = 0
? i = 0
else if x = 1
? i = 2
else if x = 2
? i = 4
else
? error(); (* probably noreturn *)
print i (* compiler complains it might be uninitialized, from the error case *)


?- Jay


----------------------------------------
> To: jay.krell at cornell.edu
> Date: Wed, 2 Jun 2010 08:32:20 -0700
> From: mika at async.async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] warning for uninitialized variables?
>
> Jay K writes:
>>
>>Well=2C I'm certainly not lobbying hard for that=2C presumably there is no =
>>efficient implementation=2C esp. for full range integers.
>>
>>Wikipedia has a nice article. "nice" means "agrees with me".
>>
>>
>>http://en.wikipedia.org/wiki/Uninitialized_variable
>>"it is a programming error and a common source of bugs in software."
>
> I don't think anyone disagrees too strongly with that, Jay, but
> the question is what can be done about it. I think the sad answer
> is, "not much."
>
>>
>>
>>And then they point out how Java requires mechanically verified initializat=
>>ion of locals.
>
> One might equally well say that an infinite loop is a programming error
> and a common source of bugs in software.
>
> Some good people, accordingly, insist that every loop be accompanied by
> a proof of termination.
>
> The difference is, of course, that it is obvious that there are
> useful loops that we cannot ever expect a compiler to be able to prove
> termination of (on its own), whereas "some people feel" that there are
> no useful ways of initializing variables that could not be verified
> correct by a particular implementation of the Java compiler.
>
> I think that if you take a step back from the problems you will see
> they are in fact the same problem: they both breach the "undecidability
> barrier". This is because we haven't put enough information in the
> variable declarations themselves to deduce what is wanted. EWD's chapter
> is a start on that---how to do this statically. (That's the last time
> I'm going to plug that chapter, I promise.)
>
> Modula-3 actually has some very nice mechanisms for avoiding uninitialized
> variables. The ability to declare/initialize a variable from an
> expression without providing an explicit type is one. WITH is another.
> I almost never have problems with uninitialized variables in my Modula-3
> programs. Almost...
>
> Mika
 		 	   		  

From jay.krell at cornell.edu  Wed Jun  2 17:48:56 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 2 Jun 2010 15:48:56 +0000
Subject: [M3devel] ADR is *too* unsafe..
In-Reply-To: <20100602153704.7645A1A209F@async.async.caltech.edu>
References: <COL101-W617B9602E6CAA0BBE5BE25E6D00@phx.gbl>, ,
	<A8CEEB02-D279-4C90-B8D3-5D163619C748@cs.purdue.edu>,
	<COL101-W444318DF7FE046C2AE542AE6D00@phx.gbl>,
	<67147BA0-0307-45FB-B646-588B55EDACC3@cs.purdue.edu>,
	<833AEC0D-7CAD-4E2E-A99D-C12F5C0DD870@cs.purdue.edu>
	<COL101-W259EC30CD3362F448A983DE6D00@phx.gbl>,
	<20100602153704.7645A1A209F@async.async.caltech.edu>
Message-ID: <COL101-W3271AE47A4F3E15973FAB3E6D00@phx.gbl>


for example:

/dev2/cm3/m3-libs/m3core/src/unix/Common/Ustat.i3

TYPE
? struct_stat = RECORD
(*
This MUST match UstatC.c.

Sorted by size, then by name; make everything LONGINT if possible, else INTEGER;
Limit on LONGINT is compatibility with existing Modula-3 code. Blowing up the sizes
larger than necessary is a slight deoptimization for the sake of simplicity and
commonality. *)
??? st_dev?? : LONGINT; (* Utypes.dev_t?? *)
??? st_ino?? : LONGINT; (* Utypes.ino_t?? *)
??? st_mtime : LONGINT; (* not time_t???? *)
??? st_nlink : LONGINT; (* Utypes.nlink_t *)
??? st_rdev? : LONGINT; (* Utypes.dev_t?? *)
??? st_size? : LONGINT; (* Utypes.off_t?? *)
??? st_flags : INTEGER; (* only on some platforms: Darwin, FreeBSD, OpenBSD, NetBSD, else 0 *)
??? st_gid?? : INTEGER; (* Utypes.gid_t?? *)
??? st_mode? : INTEGER; (* Utypes.mode_t? *)
??? st_uid?? : INTEGER; (* Utypes.uid_t?? *)
? END;
? struct_stat_star = UNTRACED REF struct_stat;


/dev2/cm3/m3-libs/m3core/src/unix/Common/UstatC.c 

struct _m3_stat_t
{
/*
This MUST match Ustat.i3.

Sorted by size, then by name; make everything LONGINT if possible, else INTEGER;
Limit on LONGINT is compatibility with existing Modula-3 code. Blowing up the sizes
larger than necessary is a slight deoptimization for the sake of simplicity and
commonality.
??? 
"st_" prefix is omitted from the names in case they are macros, which does happen */

??? LONGINT dev;
??? LONGINT ino;
??? LONGINT mtime;
??? LONGINT nlink;
??? LONGINT rdev;
??? LONGINT size;
??? INTEGER flags;
??? INTEGER gid;
??? INTEGER mode;
??? INTEGER uid;
};


We used to clone headers through careful reading of multiple platform-specified #ifdefed-to-heck headers.
Now we clone them through easier reading of simple platform-independent #ifdef-free headers.
This is progress, it is easier for programmer to get it right and eyeball it and believe it is right.


But what should actually happen is compiler should generate Ustat.h from Ustat.i3.
The only mechanical duplicate that should occur, should be done by programs.
Comments that say "must match" are the signature of a compromise, that I made.


Similarly but less obviously how, Uconstants.c should be generated.
Given a list of symbols, the C code should just #ifdef foo const bar__foo = foo #endif tc.


Such generation should happen every time one builds.
?Not just once and check them in and hope they stay current (as many folks are prone to, not necessarily present company)


?- Jay

----------------------------------------
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] ADR is *too* unsafe..
> Date: Wed, 2 Jun 2010 08:37:04 -0700
> From: mika at async.async.caltech.edu
>
> Jay K writes:
>>
>>Cool.
>>
>>=A0> but also modified the front-end of the compiler to generate C
>>header files for Modula-3 interface files.
>>=A0> This way=2C procedures exported via a
>>Modula-3 interface can be called directly from C using "module dot method"
>>syntax
>>
>>
>>I've been wanting that. :)
>
> What do you want it to do?
>
> My Modula-Scheme system does this for Scheme already.. in fact it's
> probably doing something even more complicated than what you want... hmm.
> I've been meaning to check it in somewhere for a long time.
>
> Mika
>
>>
>>=A0> "CVAR"
>>
>>Sounds like a good small change?
>>
>>=A0- Jay
>>
>>
> ...
 		 	   		  

From mika at async.async.caltech.edu  Wed Jun  2 18:08:11 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Wed, 02 Jun 2010 09:08:11 -0700
Subject: [M3devel] ADR is *too* unsafe..
In-Reply-To: <COL101-W3271AE47A4F3E15973FAB3E6D00@phx.gbl> 
References: <COL101-W617B9602E6CAA0BBE5BE25E6D00@phx.gbl>, ,
	<A8CEEB02-D279-4C90-B8D3-5D163619C748@cs.purdue.edu>,
	<COL101-W444318DF7FE046C2AE542AE6D00@phx.gbl>,
	<67147BA0-0307-45FB-B646-588B55EDACC3@cs.purdue.edu>,
	<833AEC0D-7CAD-4E2E-A99D-C12F5C0DD870@cs.purdue.edu>
	<COL101-W259EC30CD3362F448A983DE6D00@phx.gbl>,
	<20100602153704.7645A1A209F@async.async.caltech.edu>
	<COL101-W3271AE47A4F3E15973FAB3E6D00@phx.gbl>
Message-ID: <20100602160811.9FCE71A209C@async.async.caltech.edu>


That shouldn't be hard, provided you're willing to write some
Scheme code :-)

     Mika

Jay K writes:
>
>for example:
>
>/dev2/cm3/m3-libs/m3core/src/unix/Common/Ustat.i3
>
>TYPE
>=A0 struct_stat =3D RECORD
>(*
>This MUST match UstatC.c.
>
>Sorted by size=2C then by name=3B make everything LONGINT if possible=2C el=
>se INTEGER=3B
>Limit on LONGINT is compatibility with existing Modula-3 code. Blowing up t=
>he sizes
>larger than necessary is a slight deoptimization for the sake of simplicity=
> and
>commonality. *)
>=A0=A0=A0 st_dev=A0=A0 : LONGINT=3B (* Utypes.dev_t=A0=A0 *)
>=A0=A0=A0 st_ino=A0=A0 : LONGINT=3B (* Utypes.ino_t=A0=A0 *)
>=A0=A0=A0 st_mtime : LONGINT=3B (* not time_t=A0=A0=A0=A0 *)
>=A0=A0=A0 st_nlink : LONGINT=3B (* Utypes.nlink_t *)
>=A0=A0=A0 st_rdev=A0 : LONGINT=3B (* Utypes.dev_t=A0=A0 *)
>=A0=A0=A0 st_size=A0 : LONGINT=3B (* Utypes.off_t=A0=A0 *)
>=A0=A0=A0 st_flags : INTEGER=3B (* only on some platforms: Darwin=2C FreeBS=
>D=2C OpenBSD=2C NetBSD=2C else 0 *)
>=A0=A0=A0 st_gid=A0=A0 : INTEGER=3B (* Utypes.gid_t=A0=A0 *)
>=A0=A0=A0 st_mode=A0 : INTEGER=3B (* Utypes.mode_t=A0 *)
>=A0=A0=A0 st_uid=A0=A0 : INTEGER=3B (* Utypes.uid_t=A0=A0 *)
>=A0 END=3B
>=A0 struct_stat_star =3D UNTRACED REF struct_stat=3B
>
>
>/dev2/cm3/m3-libs/m3core/src/unix/Common/UstatC.c=20
>
>struct _m3_stat_t
>{
>/*
>This MUST match Ustat.i3.
>
>Sorted by size=2C then by name=3B make everything LONGINT if possible=2C el=
>se INTEGER=3B
>Limit on LONGINT is compatibility with existing Modula-3 code. Blowing up t=
>he sizes
>larger than necessary is a slight deoptimization for the sake of simplicity=
> and
>commonality.
>=A0=A0=A0=20
>"st_" prefix is omitted from the names in case they are macros=2C which doe=
>s happen */
>
>=A0=A0=A0 LONGINT dev=3B
>=A0=A0=A0 LONGINT ino=3B
>=A0=A0=A0 LONGINT mtime=3B
>=A0=A0=A0 LONGINT nlink=3B
>=A0=A0=A0 LONGINT rdev=3B
>=A0=A0=A0 LONGINT size=3B
>=A0=A0=A0 INTEGER flags=3B
>=A0=A0=A0 INTEGER gid=3B
>=A0=A0=A0 INTEGER mode=3B
>=A0=A0=A0 INTEGER uid=3B
>}=3B
>
>
>We used to clone headers through careful reading of multiple platform-speci=
>fied #ifdefed-to-heck headers.
>Now we clone them through easier reading of simple platform-independent #if=
>def-free headers.
>This is progress=2C it is easier for programmer to get it right and eyeball=
> it and believe it is right.
>
>
>But what should actually happen is compiler should generate Ustat.h from Us=
>tat.i3.
>The only mechanical duplicate that should occur=2C should be done by progra=
>ms.
>Comments that say "must match" are the signature of a compromise=2C that I =
>made.
>
>
>Similarly but less obviously how=2C Uconstants.c should be generated.
>Given a list of symbols=2C the C code should just #ifdef foo const bar__foo=
> =3D foo #endif tc.
>
>
>Such generation should happen every time one builds.
>=A0Not just once and check them in and hope they stay current (as many folk=
>s are prone to=2C not necessarily present company)
>
>
>=A0- Jay
>
>----------------------------------------
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] ADR is *too* unsafe..
>> Date: Wed=2C 2 Jun 2010 08:37:04 -0700
>> From: mika at async.async.caltech.edu
>>
>> Jay K writes:
>>>
>>>Cool.
>>>
>>>=3DA0> but also modified the front-end of the compiler to generate C
>>>header files for Modula-3 interface files.
>>>=3DA0> This way=3D2C procedures exported via a
>>>Modula-3 interface can be called directly from C using "module dot method=
>"
>>>syntax
>>>
>>>
>>>I've been wanting that. :)
>>
>> What do you want it to do?
>>
>> My Modula-Scheme system does this for Scheme already.. in fact it's
>> probably doing something even more complicated than what you want... hmm.
>> I've been meaning to check it in somewhere for a long time.
>>
>> Mika
>>
>>>
>>>=3DA0> "CVAR"
>>>
>>>Sounds like a good small change?
>>>
>>>=3DA0- Jay
>>>
>>>
>> ...
> 		 	   		  =


From jay.krell at cornell.edu  Wed Jun  2 18:54:45 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 2 Jun 2010 16:54:45 +0000
Subject: [M3devel] ADR is *too* unsafe..
In-Reply-To: <20100602160811.9FCE71A209C@async.async.caltech.edu>
References: <COL101-W617B9602E6CAA0BBE5BE25E6D00@phx.gbl>, ,
	<A8CEEB02-D279-4C90-B8D3-5D163619C748@cs.purdue.edu>,
	<COL101-W444318DF7FE046C2AE542AE6D00@phx.gbl>,
	<67147BA0-0307-45FB-B646-588B55EDACC3@cs.purdue.edu>,
	<833AEC0D-7CAD-4E2E-A99D-C12F5C0DD870@cs.purdue.edu>
	<COL101-W259EC30CD3362F448A983DE6D00@phx.gbl>,
	<20100602153704.7645A1A209F@async.async.caltech.edu>
	<COL101-W3271AE47A4F3E15973FAB3E6D00@phx.gbl>,
	<20100602160811.9FCE71A209C@async.async.caltech.edu>
Message-ID: <COL101-W2141AC09F05E54A393E48BE6D00@phx.gbl>


As long as I describe the interface just once, and you then spit out both .i3 and .h, and
they are pretty much "guaranteed to match", ok.
(Or maybe it can interface with the Modula-3 compiler at a lower level in-memory, instead
of out to text and then parsed back into something else; I have no similar hope for C..)

?- Jay


----------------------------------------
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] ADR is *too* unsafe..
> Date: Wed, 2 Jun 2010 09:08:11 -0700
> From: mika at async.async.caltech.edu
>
>
> That shouldn't be hard, provided you're willing to write some
> Scheme code :-)
>
> Mika
>
> Jay K writes:
>>
>>for example:
>>
>>/dev2/cm3/m3-libs/m3core/src/unix/Common/Ustat.i3
>>
>>TYPE
>>=A0 struct_stat =3D RECORD
>>(*
>>This MUST match UstatC.c.
>>
>>Sorted by size=2C then by name=3B make everything LONGINT if possible=2C el=
>>se INTEGER=3B
>>Limit on LONGINT is compatibility with existing Modula-3 code. Blowing up t=
>>he sizes
>>larger than necessary is a slight deoptimization for the sake of simplicity=
>> and
>>commonality. *)
>>=A0=A0=A0 st_dev=A0=A0 : LONGINT=3B (* Utypes.dev_t=A0=A0 *)
>>=A0=A0=A0 st_ino=A0=A0 : LONGINT=3B (* Utypes.ino_t=A0=A0 *)
>>=A0=A0=A0 st_mtime : LONGINT=3B (* not time_t=A0=A0=A0=A0 *)
>>=A0=A0=A0 st_nlink : LONGINT=3B (* Utypes.nlink_t *)
>>=A0=A0=A0 st_rdev=A0 : LONGINT=3B (* Utypes.dev_t=A0=A0 *)
>>=A0=A0=A0 st_size=A0 : LONGINT=3B (* Utypes.off_t=A0=A0 *)
>>=A0=A0=A0 st_flags : INTEGER=3B (* only on some platforms: Darwin=2C FreeBS=
>>D=2C OpenBSD=2C NetBSD=2C else 0 *)
>>=A0=A0=A0 st_gid=A0=A0 : INTEGER=3B (* Utypes.gid_t=A0=A0 *)
>>=A0=A0=A0 st_mode=A0 : INTEGER=3B (* Utypes.mode_t=A0 *)
>>=A0=A0=A0 st_uid=A0=A0 : INTEGER=3B (* Utypes.uid_t=A0=A0 *)
>>=A0 END=3B
>>=A0 struct_stat_star =3D UNTRACED REF struct_stat=3B
>>
>>
>>/dev2/cm3/m3-libs/m3core/src/unix/Common/UstatC.c=20
>>
>>struct _m3_stat_t
>>{
>>/*
>>This MUST match Ustat.i3.
>>
>>Sorted by size=2C then by name=3B make everything LONGINT if possible=2C el=
>>se INTEGER=3B
>>Limit on LONGINT is compatibility with existing Modula-3 code. Blowing up t=
>>he sizes
>>larger than necessary is a slight deoptimization for the sake of simplicity=
>> and
>>commonality.
>>=A0=A0=A0=20
>>"st_" prefix is omitted from the names in case they are macros=2C which doe=
>>s happen */
>>
>>=A0=A0=A0 LONGINT dev=3B
>>=A0=A0=A0 LONGINT ino=3B
>>=A0=A0=A0 LONGINT mtime=3B
>>=A0=A0=A0 LONGINT nlink=3B
>>=A0=A0=A0 LONGINT rdev=3B
>>=A0=A0=A0 LONGINT size=3B
>>=A0=A0=A0 INTEGER flags=3B
>>=A0=A0=A0 INTEGER gid=3B
>>=A0=A0=A0 INTEGER mode=3B
>>=A0=A0=A0 INTEGER uid=3B
>>}=3B
>>
>>
>>We used to clone headers through careful reading of multiple platform-speci=
>>fied #ifdefed-to-heck headers.
>>Now we clone them through easier reading of simple platform-independent #if=
>>def-free headers.
>>This is progress=2C it is easier for programmer to get it right and eyeball=
>> it and believe it is right.
>>
>>
>>But what should actually happen is compiler should generate Ustat.h from Us=
>>tat.i3.
>>The only mechanical duplicate that should occur=2C should be done by progra=
>>ms.
>>Comments that say "must match" are the signature of a compromise=2C that I =
>>made.
>>
>>
>>Similarly but less obviously how=2C Uconstants.c should be generated.
>>Given a list of symbols=2C the C code should just #ifdef foo const bar__foo=
>> =3D foo #endif tc.
>>
>>
>>Such generation should happen every time one builds.
>>=A0Not just once and check them in and hope they stay current (as many folk=
>>s are prone to=2C not necessarily present company)
>>
>>
>>=A0- Jay
>>
>>----------------------------------------
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] ADR is *too* unsafe..
>>> Date: Wed=2C 2 Jun 2010 08:37:04 -0700
>>> From: mika at async.async.caltech.edu
>>>
>>> Jay K writes:
>>>>
>>>>Cool.
>>>>
>>>>=3DA0> but also modified the front-end of the compiler to generate C
>>>>header files for Modula-3 interface files.
>>>>=3DA0> This way=3D2C procedures exported via a
>>>>Modula-3 interface can be called directly from C using "module dot method=
>>"
>>>>syntax
>>>>
>>>>
>>>>I've been wanting that. :)
>>>
>>> What do you want it to do?
>>>
>>> My Modula-Scheme system does this for Scheme already.. in fact it's
>>> probably doing something even more complicated than what you want... hmm.
>>> I've been meaning to check it in somewhere for a long time.
>>>
>>> Mika
>>>
>>>>
>>>>=3DA0> "CVAR"
>>>>
>>>>Sounds like a good small change?
>>>>
>>>>=3DA0- Jay
>>>>
>>>>
>>> ...
>> =
 		 	   		  

From hendrik at topoi.pooq.com  Fri Jun  4 01:30:22 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Thu, 3 Jun 2010 19:30:22 -0400
Subject: [M3devel] warning for uninitialized variables?
In-Reply-To: <COL101-W59770EAA64E52A966D79F3E6D00@phx.gbl>
References: <20100602035226.43C1F1A208F@async.async.caltech.edu>
	<COL101-W59770EAA64E52A966D79F3E6D00@phx.gbl>
Message-ID: <20100603233021.GA11727@topoi.pooq.com>

On Wed, Jun 02, 2010 at 04:50:28AM +0000, Jay K wrote:
> 
> Wow. You really surprise me Mika.
> 
> 
> To warn on this kind of thing, to me, there is no question.
> 
> 
> Limting the affects by virtue of being safe isn't much consolation.
> The program can easily go down a "safe" but very incorrect path.
> 
> 
> There are several forms.
> In fact, sometimes the compiler says something "is" used uninitialized.
> Sometimes it says "maybe".
> 
> 
> In your example, generally, once the address is taken of a variable,
> the compiler gives up. Esp. if that address is passed to a function it doesn't "see".
> 
> 
> However compilers are getting better.
> Windows headers are now annotated with "in" and "out", etc. with
> a calculus behind them, not just informal human definitions.
> 
> 
> So if you pass something by pointer to "in" you should a warning/error.
> If it is "out", ok.
> 
> 
> The annotations can even be checked, if you write to something that is "in"
> you should get a warning/error.
> 
> 
> There are many more warnings in the tree than I have yet looked at.
> I've seen a few forms.
> Some are because the compiler doesn't know that some functions don't return.
> I'll see about improving that. Though I think there's a limit to how good I can manage,
> unless we add a <* noreturn *> pragma.

Or a new type that has *no* values at all, and therefore can never be 
returned by anything.  If it'e the type of an expression, that 
expression can never return a value.

Notice, that if you were to let statements have a type (Algol 68 does, 
calling it the VOID type) that type would *not* be the type with no 
values at all.  The VOID type has one value, and needs log(1) = 0 bits 
to store it.

The NORETURN type would have no values, is never stored.  log(0) doesn't 
give a meaningful numper of bits, which is right.

> 
> I grant that by initializing to 0, I haven't necessarily made the code correct either.
> But at least it is now consistent.

It's very useful for code execution to ne repeatable.

> 
> 
> Even better would be runtime checks that stop if a variable is read 
> before written.

Takes extra storage, unless there are bit patterns that are known to fit 
in the available space *and* be invalid values for the type.

> 
> 
> Uninitialized values can be different run to run.
> Repeatability and consistency are important.

*VERY*

> I'm also nervous about us not taking a hard line on integer overflow.
> Overflown math doesn't necessarily lead to array out of bounds soon or ever.
> It too can lead to incorrect but safe behavior.

I agree.  But I do need a way to turn it off for specific operations so 
I get modulo results.  Perhaps also a specific type for wrap-around 
arithmetic?

-- hendrik



From hendrik at topoi.pooq.com  Fri Jun  4 01:36:14 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Thu, 3 Jun 2010 19:36:14 -0400
Subject: [M3devel] warning for uninitialized variables?
In-Reply-To: <20100602124422.11C6D1A209A@async.async.caltech.edu>
References: <20100602035226.43C1F1A208F@async.async.caltech.edu>
	<COL101-W59770EAA64E52A966D79F3E6D00@phx.gbl>
	<20100602124422.11C6D1A209A@async.async.caltech.edu>
Message-ID: <20100603233614.GB11727@topoi.pooq.com>

On Wed, Jun 02, 2010 at 05:44:22AM -0700, Mika Nystrom wrote:
> Jay K writes:
> >
> >Limting the affects by virtue of being safe isn't much consolation.
> >The program can easily go down a "safe" but very incorrect path.
> 
> It is, though!  Do you always know what value to initialize the
> variables to?  If not, you're just picking some value to shut up
> the compiler, and now your code no longer expresses---to a human
> reader---that x is uninitialized.

Not initializing it because thats your intent is OK in the cource code.
But letting the compiler initialize it to some or other value in a 
consistent manner gives the consistency that makes your code more 
rerunnable therefore more debuggable. 

> 
> Remember, code is mainly written for humans!  Computers don't care
> about fancy structuring, declarations, etc.  When you write a program,
> you write it to be read by a human.  The fact that a variable is
> uninitialized is a part of the design of the program.
> 
> It's an unfortunate fact that our languages don't have all the 
> mechanisms necessary to deal properly with uninitialized variables.
> Retrofitting mechanisms to something that just isn't expressive
> enough to solve the problem I really don't think is the way to go.

That's why I like to declare variables at the very point they are 
initialized.  If they are in scope, they are OK.  (Actually, there are 
still a very few cases where you want to declare a variable other than 
where it's initialized.  But that's quite rare).

But Modula 3 has chosen a different path, and I don't think this is 
really retrofittable.

-- hendrik


From hendrik at topoi.pooq.com  Fri Jun  4 01:41:02 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Thu, 3 Jun 2010 19:41:02 -0400
Subject: [M3devel] warning for uninitialized variables?
In-Reply-To: <COL101-W5343011FD0FA7BCC8C42AEE6D00@phx.gbl>
References: <20100602035226.43C1F1A208F@async.async.caltech.edu>
	<20100602124422.11C6D1A209A@async.async.caltech.edu>
	<COL101-W5343011FD0FA7BCC8C42AEE6D00@phx.gbl>
Message-ID: <20100603234102.GC11727@topoi.pooq.com>

On Wed, Jun 02, 2010 at 12:59:45PM +0000, Jay K wrote:
> 
> I grant that an immediate runtime error upon reading an unwritten value is ideal.

One of the variables in a cryptographic-quality random number generator 
was uninitialized.  Someone in Debian "fixed" that.  The random number 
generator was n longer of cryptographic quality.  It turns out is was 
relying on the variable being garbage.

So we still need to be able to use uninitialized stuff..  But not by 
accident.

> But absent that possibility, I want something consistent.
> Heck, here's a crazy idea: reserve the current FIRST(INTEGER) as 
> "invalid", initialize locals to it, any read (or generation/write) of 
> that value trigger a runtime error.
> CARDINAL could work this way more easily since it has many values to spare.

And if instead of a load, your machine had a load absolute value, a 
hardware overflow trap could catch the error at no additional run time.
That's a hack I planned to use for a NULL check on an IBM 360 long long 
ago.

-- hendrik


From hendrik at topoi.pooq.com  Fri Jun  4 01:51:03 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Thu, 3 Jun 2010 19:51:03 -0400
Subject: [M3devel] warning for uninitialized variables?
In-Reply-To: <COL101-W44444F6A175254747767CFE6D00@phx.gbl>
References: <16413179-F84C-42BF-AB09-2D8294EB4782@cs.purdue.edu>
	<COL101-W44444F6A175254747767CFE6D00@phx.gbl>
Message-ID: <20100603235102.GD11727@topoi.pooq.com>

On Wed, Jun 02, 2010 at 02:52:55PM +0000, Jay K wrote:
> 
> Running with a consistent initialized/uninitialized 0 is better than running with a "random" value that you get from no initialization.
> ?They are both "bad".
> ?The 0 is agreed misleading, because it might look initialized.
> ? But it still better than a value that can change from run to run.

Initializing it to cosistent gibberish won't look as initialized.  The 
University of Waterloo WATFOR compiler initialized all of memory to a 
consistent bit pattern that was *not* a printable character in the 
character set, and was *not* a valid exponent for a floating-point 
number.  It was a valid integer, though.  That much was OK, and would 
provide consistency with a high probability of misbehaviour on error.

But they went further and regularly checked for that value on reads.  It 
took time, it found errors, and it was a rare day that anyone needed 
that value.  But it did happen, and I consider the test a mistake for 
types that an validly assume all bit patterns.
> 
> Programs are written for humans to read, true, but programs that read programs are much more diligent, energetic, and often smarter (and slowly getting smarter with age, often the opposite of humans).
> Compilers really do have a big "leg" up on humans, since they can harness fast digital processor with big storage.
> Granted, neither is always better than the other. But compilers/computers have far more capacity for code reading than humans and I know from experience that most code is never read by a human, not even once, until I get to it :), because the bugs I readily see wouldn't survive even a glance...
> ?(and the compilers often fail too, granted).
> 
> 
> Again I'm quite surprised we want to leave uninitialized variables 
> that get used uninitialized.  The one in cm3ide for example, if the 
> input is malformed, I believe it uses uninitialized data.
> I don't see how this can be deemed anything other than a bug to be 
> fixed, and that we should be glad the compiler (finally) found it..now 
> that I'm working on removing the rampant volatile...
> 
> 
> If we can invest in runtime checks to immediately catch reads of 
> unwritten data, then I'd favor that instead.

The hard part is distinguishing the truly uninitialized variable from a 
variable that pappens to validly get assigned a computed bit pattern 
that just happens to be the marker for "uninitialized".

But being able to turn on such a run-time check during debugging might 
make it wasier to find a *lot* of uninitialized variables, with only anb 
occasional false positive.

-- hendrik


From jay.krell at cornell.edu  Fri Jun  4 01:47:00 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 3 Jun 2010 23:47:00 +0000
Subject: [M3devel] warning for uninitialized variables?
In-Reply-To: <20100603233614.GB11727@topoi.pooq.com>
References: <20100602035226.43C1F1A208F@async.async.caltech.edu>,
	<COL101-W59770EAA64E52A966D79F3E6D00@phx.gbl>,
	<20100602124422.11C6D1A209A@async.async.caltech.edu>,
	<20100603233614.GB11727@topoi.pooq.com>
Message-ID: <COL101-W2394F109BD07DCB14C61EBE6D10@phx.gbl>


Declare at initialization is good.
  Exactly what C++ supports and it is considered completely uncontroversial and maybe C9x even supports it.
 
 
Modula-3 supports it, both with "WITH..DO" and "VAR..BEGIN" but at too high a syntactic cost -- having to indent for each new block of variables, or to use begin/end without indenting.
 
 
Heck, C supports the same thing -- you can introduce braces anywhere, and then variables after any left brace.
 
 
I would rather move all my variables to the top of the function and initialize them with 0 than to indent every time I want a new variable. Really. I have learned to accept much about Modula-3's syntax, but not this.
 
 
 
 - Jay


----------------------------------------
> Date: Thu, 3 Jun 2010 19:36:14 -0400
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] warning for uninitialized variables?
>
> On Wed, Jun 02, 2010 at 05:44:22AM -0700, Mika Nystrom wrote:
>> Jay K writes:
>>>
>>>Limting the affects by virtue of being safe isn't much consolation.
>>>The program can easily go down a "safe" but very incorrect path.
>>
>> It is, though! Do you always know what value to initialize the
>> variables to? If not, you're just picking some value to shut up
>> the compiler, and now your code no longer expresses---to a human
>> reader---that x is uninitialized.
>
> Not initializing it because thats your intent is OK in the cource code.
> But letting the compiler initialize it to some or other value in a
> consistent manner gives the consistency that makes your code more
> rerunnable therefore more debuggable.
>
>>
>> Remember, code is mainly written for humans! Computers don't care
>> about fancy structuring, declarations, etc. When you write a program,
>> you write it to be read by a human. The fact that a variable is
>> uninitialized is a part of the design of the program.
>>
>> It's an unfortunate fact that our languages don't have all the
>> mechanisms necessary to deal properly with uninitialized variables.
>> Retrofitting mechanisms to something that just isn't expressive
>> enough to solve the problem I really don't think is the way to go.
>
> That's why I like to declare variables at the very point they are
> initialized. If they are in scope, they are OK. (Actually, there are
> still a very few cases where you want to declare a variable other than
> where it's initialized. But that's quite rare).
>
> But Modula 3 has chosen a different path, and I don't think this is
> really retrofittable.
>
> -- hendrik 		 	   		  

From hendrik at topoi.pooq.com  Fri Jun  4 01:54:55 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Thu, 3 Jun 2010 19:54:55 -0400
Subject: [M3devel] warning for uninitialized variables?
In-Reply-To: <COL101-W40BE08A256108863A44C5FE6D00@phx.gbl>
References: <5EDDD7E5-C33E-4BD1-A036-2D3561F08277@cs.purdue.edu>
	<COL101-W40BE08A256108863A44C5FE6D00@phx.gbl>
Message-ID: <20100603235455.GE11727@topoi.pooq.com>

On Wed, Jun 02, 2010 at 03:13:55PM +0000, Jay K wrote:
> 
> Well, I'm certainly not lobbying hard for that, presumably there is no efficient implementation, esp. for full range integers.
> 
> Wikipedia has a nice article. "nice" means "agrees with me".
> 
> 
> http://en.wikipedia.org/wiki/Uninitialized_variable
> "it is a programming error and a common source of bugs in software."
> 
> 
> And then they point out how Java requires mechanically verified initialization of locals.
> 
> The code:
> void F(bool a)
> ?int i;
> ?if (a)
> ?? i = 0;
> if (a)
> ? print(i)
> 
> 
> is I believe illegal.

But it's *not* illegal in Modula 3.  You can't prohibit it without 
making a serious language change. However much we might desire to.

-- hendrik


From jay.krell at cornell.edu  Fri Jun  4 01:59:01 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 3 Jun 2010 23:59:01 +0000
Subject: [M3devel] warning for uninitialized variables?
In-Reply-To: <20100603233021.GA11727@topoi.pooq.com>
References: <20100602035226.43C1F1A208F@async.async.caltech.edu>,
	<COL101-W59770EAA64E52A966D79F3E6D00@phx.gbl>,
	<20100603233021.GA11727@topoi.pooq.com>
Message-ID: <COL101-W62E2D97D9F353F3DACDC1AE6D10@phx.gbl>


> The NORETURN type would have no values 
 
 
Everyone else seems to do with pragma-ish things.
I don't know what is best.
Visual C++ has __declspec(noreturn).
gcc has __attribute__((noreturn)) or somesuch. Maybe it is named something else.
Visual C++ puts a breakpoint instruction after any call to a noreturn function.
abort() for example is noreturn.
 
 
 
>> I'm also nervous about us not taking a hard line on integer overflow. 
> I agree. But I do need a way to turn it off for specific operations so 
> Perhaps also a specific type for wrap-around arithmetic? 
 
 
Yes. Or a new module.
And I believe a bunch more is needed in general.
  Signed and unsigned.
  And overflow should do one:
    return an "error" code (boolean? true for success? or true for overflow? Booleans can be so ambiguous..) 
    raise an exception 
    silently wraparound 
 
 
 
I have to look into Modula-3 generics.
Ideally this can be implemented with generics and not actually writing all N combinations.
And without any "runtime switching".
 
 
For example, the generic parameters would be
  "Word"
  "Error"
 
 
 
Word would look like Word.
Except all the functions would probably return BOOLEAN to indicate overflow.
  Even if that isn't the actual "error code".
 
 
Error would expose type T that the actual implementation would return.
Oh, wait, no, Modula-3 can't do that -- there is no "VOID" type.
 
 
So..instead.. decide what the "error code" form is -- probably returning FALSE.
The Error module would expose one function, OnError.
 
 
The main code when it recieves false from "Word" would call Error.OnError.
There'd be two Error's versions. In one, OnError would do nothing. In the other, it would raise an exception.
 
 
Hm.
If Modula-3 didn't have this pesky "eval" thing, you'd be done.
Silent wraparound would be calling the "OnError donothing" form, but you'd just ignore the error.
 
 
This is unfortunate I think.
 
 
Btw, C++ folks eventually realized you need to be able to write code like this:
 
PROCEDURE F1();
 
PROCEDURE F2() = 
BEGIN
  RETURN F1();
END F1;
 
 
for reasons related to templates/generics.
You need to be able to return the result of a function you call, without knowing the return type, and the return type possibly being void. The need for this feature is obvious once you spend a few days using templates/generics.
 
 
Anyway, for silent overflow you'd have to layer over the bool version, just prepending eval.
Something like that.
 
 
The lowest level implementation probably returns bool.
 
 
The Error module could also expose a type ErrorType and some constants like OverflowError and NoError.
 
 
Maybe I'll code this up soon in pure Modula-3.
 
 
Where/who/when are the interface police?
We can add stuff to m3core or libm3 at will? As long as don't extend or change stuff in the green book?
 
 
 - Jay


----------------------------------------
> Date: Thu, 3 Jun 2010 19:30:22 -0400
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] warning for uninitialized variables?
>
> On Wed, Jun 02, 2010 at 04:50:28AM +0000, Jay K wrote:
>>
>> Wow. You really surprise me Mika.
>>
>>
>> To warn on this kind of thing, to me, there is no question.
>>
>>
>> Limting the affects by virtue of being safe isn't much consolation.
>> The program can easily go down a "safe" but very incorrect path.
>>
>>
>> There are several forms.
>> In fact, sometimes the compiler says something "is" used uninitialized.
>> Sometimes it says "maybe".
>>
>>
>> In your example, generally, once the address is taken of a variable,
>> the compiler gives up. Esp. if that address is passed to a function it doesn't "see".
>>
>>
>> However compilers are getting better.
>> Windows headers are now annotated with "in" and "out", etc. with
>> a calculus behind them, not just informal human definitions.
>>
>>
>> So if you pass something by pointer to "in" you should a warning/error.
>> If it is "out", ok.
>>
>>
>> The annotations can even be checked, if you write to something that is "in"
>> you should get a warning/error.
>>
>>
>> There are many more warnings in the tree than I have yet looked at.
>> I've seen a few forms.
>> Some are because the compiler doesn't know that some functions don't return.
>> I'll see about improving that. Though I think there's a limit to how good I can manage,
>> unless we add a <* noreturn *> pragma.
>
> Or a new type that has *no* values at all, and therefore can never be
> returned by anything. If it'e the type of an expression, that
> expression can never return a value.
>
> Notice, that if you were to let statements have a type (Algol 68 does,
> calling it the VOID type) that type would *not* be the type with no
> values at all. The VOID type has one value, and needs log(1) = 0 bits
> to store it.
>
> The NORETURN type would have no values, is never stored. log(0) doesn't
> give a meaningful numper of bits, which is right.
>
>>
>> I grant that by initializing to 0, I haven't necessarily made the code correct either.
>> But at least it is now consistent.
>
> It's very useful for code execution to ne repeatable.
>
>>
>>
>> Even better would be runtime checks that stop if a variable is read
>> before written.
>
> Takes extra storage, unless there are bit patterns that are known to fit
> in the available space *and* be invalid values for the type.
>
>>
>>
>> Uninitialized values can be different run to run.
>> Repeatability and consistency are important.
>
> *VERY*
>
>> I'm also nervous about us not taking a hard line on integer overflow.
>> Overflown math doesn't necessarily lead to array out of bounds soon or ever.
>> It too can lead to incorrect but safe behavior.
>
> I agree. But I do need a way to turn it off for specific operations so
> I get modulo results. Perhaps also a specific type for wrap-around
> arithmetic?
>
> -- hendrik
> 		 	   		  

From jay.krell at cornell.edu  Fri Jun  4 02:14:14 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 4 Jun 2010 00:14:14 +0000
Subject: [M3devel] warning for uninitialized variables?
In-Reply-To: <20100603235102.GD11727@topoi.pooq.com>
References: <16413179-F84C-42BF-AB09-2D8294EB4782@cs.purdue.edu>,
	<COL101-W44444F6A175254747767CFE6D00@phx.gbl>,
	<20100603235102.GD11727@topoi.pooq.com>
Message-ID: <COL101-W58390B33633452C34384DDE6D20@phx.gbl>


Search the web for "visual C++ /rtc".
 
You'll find that Visual C++ has the ideal feature here, not enabled by default. Not efficient.
 
If you compile with /RTCu:
  an extra byte local is created for each local variable 
  It is initialized to zero.
  Writes to the variable write 1 to the extra. (taking the address does to, the documentation spends a lot of space explaining) 
  Reads of the variable check if the extra is 0 or not and if it 0 a function is called to report the error.
 
 
It's pretty cool imho.
 
 
And it appears if the compiler can prove the variable isn't initialized, the checking is omitted.
Given decent code, that should make it very affordable to always be enabled.
 
 
 - Jay


----------------------------------------
> Date: Thu, 3 Jun 2010 19:51:03 -0400
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] warning for uninitialized variables?
>
> On Wed, Jun 02, 2010 at 02:52:55PM +0000, Jay K wrote:
>>
>> Running with a consistent initialized/uninitialized 0 is better than running with a "random" value that you get from no initialization.
>> They are both "bad".
>> The 0 is agreed misleading, because it might look initialized.
>> But it still better than a value that can change from run to run.
>
> Initializing it to cosistent gibberish won't look as initialized. The
> University of Waterloo WATFOR compiler initialized all of memory to a
> consistent bit pattern that was *not* a printable character in the
> character set, and was *not* a valid exponent for a floating-point
> number. It was a valid integer, though. That much was OK, and would
> provide consistency with a high probability of misbehaviour on error.
>
> But they went further and regularly checked for that value on reads. It
> took time, it found errors, and it was a rare day that anyone needed
> that value. But it did happen, and I consider the test a mistake for
> types that an validly assume all bit patterns.
>>
>> Programs are written for humans to read, true, but programs that read programs are much more diligent, energetic, and often smarter (and slowly getting smarter with age, often the opposite of humans).
>> Compilers really do have a big "leg" up on humans, since they can harness fast digital processor with big storage.
>> Granted, neither is always better than the other. But compilers/computers have far more capacity for code reading than humans and I know from experience that most code is never read by a human, not even once, until I get to it :), because the bugs I readily see wouldn't survive even a glance...
>> (and the compilers often fail too, granted).
>>
>>
>> Again I'm quite surprised we want to leave uninitialized variables
>> that get used uninitialized. The one in cm3ide for example, if the
>> input is malformed, I believe it uses uninitialized data.
>> I don't see how this can be deemed anything other than a bug to be
>> fixed, and that we should be glad the compiler (finally) found it..now
>> that I'm working on removing the rampant volatile...
>>
>>
>> If we can invest in runtime checks to immediately catch reads of
>> unwritten data, then I'd favor that instead.
>
> The hard part is distinguishing the truly uninitialized variable from a
> variable that pappens to validly get assigned a computed bit pattern
> that just happens to be the marker for "uninitialized".
>
> But being able to turn on such a run-time check during debugging might
> make it wasier to find a *lot* of uninitialized variables, with only anb
> occasional false positive.
>
> -- hendrik 		 	   		  

From jay.krell at cornell.edu  Fri Jun  4 18:29:34 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 4 Jun 2010 16:29:34 +0000
Subject: [M3devel] optimizer problems
Message-ID: <COL101-W915873EEE558B40A8F280E6D20@phx.gbl>


Just a note that I have found at least two pieces of code that fail to compile with optimization enabled, even in the release branch.

One is a simple case involving unused nested functions.
One is a complicated not really understood case.


To fix these I have pessimized the optimizer in the release branch but turning off two optimizations.


It would be nice to find a better fix for the first.
Even something sleazy like having the front end report up front to the backend if there are any nested functions in the unit, and only pessimizing such units.
There is probably also a fix to gcc around preserving nested functions. I thought code in varasm.c was suspicious but couldn't get it to work quickly.


The other fix seems to always involve exception handling, so something sleazy might be appropriate there -- only turn off the optimization in units that use exception handling. Longer term, we should use the gcc exception handling support if possible, even if that involves configure -enable-sjlj-exceptions (presumably not on all targets).

?- Jay


 		 	   		  

From hosking at cs.purdue.edu  Fri Jun  4 18:37:45 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 4 Jun 2010 12:37:45 -0400
Subject: [M3devel] optimizer problems
In-Reply-To: <COL101-W915873EEE558B40A8F280E6D20@phx.gbl>
References: <COL101-W915873EEE558B40A8F280E6D20@phx.gbl>
Message-ID: <282D3F06-9C5A-4525-B1D0-77E59B12D833@cs.purdue.edu>

You should be able to mark it as used.

On 4 Jun 2010, at 12:29, Jay K wrote:

> 
> Just a note that I have found at least two pieces of code that fail to compile with optimization enabled, even in the release branch.
> 
> One is a simple case involving unused nested functions.
> One is a complicated not really understood case.
> 
> 
> To fix these I have pessimized the optimizer in the release branch but turning off two optimizations.
> 
> 
> It would be nice to find a better fix for the first.
> Even something sleazy like having the front end report up front to the backend if there are any nested functions in the unit, and only pessimizing such units.
> There is probably also a fix to gcc around preserving nested functions. I thought code in varasm.c was suspicious but couldn't get it to work quickly.



From jay.krell at cornell.edu  Fri Jun  4 19:06:25 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 4 Jun 2010 17:06:25 +0000
Subject: [M3devel] optimizer problems
In-Reply-To: <282D3F06-9C5A-4525-B1D0-77E59B12D833@cs.purdue.edu>
References: <COL101-W915873EEE558B40A8F280E6D20@phx.gbl>,
	<282D3F06-9C5A-4525-B1D0-77E59B12D833@cs.purdue.edu>
Message-ID: <COL101-W5966EA54CF4DA49BC6D74E6D20@phx.gbl>


I already tried that.. :(
 
 
 - Jay


----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Fri, 4 Jun 2010 12:37:45 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] optimizer problems
>
> You should be able to mark it as used.
>
> On 4 Jun 2010, at 12:29, Jay K wrote:
>
>>
>> Just a note that I have found at least two pieces of code that fail to compile with optimization enabled, even in the release branch.
>>
>> One is a simple case involving unused nested functions.
>> One is a complicated not really understood case.
>>
>>
>> To fix these I have pessimized the optimizer in the release branch but turning off two optimizations.
>>
>>
>> It would be nice to find a better fix for the first.
>> Even something sleazy like having the front end report up front to the backend if there are any nested functions in the unit, and only pessimizing such units.
>> There is probably also a fix to gcc around preserving nested functions. I thought code in varasm.c was suspicious but couldn't get it to work quickly.
> 		 	   		  

From hosking at cs.purdue.edu  Fri Jun  4 19:56:44 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 4 Jun 2010 13:56:44 -0400
Subject: [M3devel] optimizer problems
In-Reply-To: <COL101-W5966EA54CF4DA49BC6D74E6D20@phx.gbl>
References: <COL101-W915873EEE558B40A8F280E6D20@phx.gbl>,
	<282D3F06-9C5A-4525-B1D0-77E59B12D833@cs.purdue.edu>
	<COL101-W5966EA54CF4DA49BC6D74E6D20@phx.gbl>
Message-ID: <1B0AB99B-837F-464E-9BE7-140DAEB59E5E@cs.purdue.edu>

Or "external".  I assume it is getting dead code eliminated.

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




On 4 Jun 2010, at 13:06, Jay K wrote:

> 
> I already tried that.. :(
> 
> 
> - Jay
> 
> 
> ----------------------------------------
>> From: hosking at cs.purdue.edu
>> Date: Fri, 4 Jun 2010 12:37:45 -0400
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] optimizer problems
>> 
>> You should be able to mark it as used.
>> 
>> On 4 Jun 2010, at 12:29, Jay K wrote:
>> 
>>> 
>>> Just a note that I have found at least two pieces of code that fail to compile with optimization enabled, even in the release branch.
>>> 
>>> One is a simple case involving unused nested functions.
>>> One is a complicated not really understood case.
>>> 
>>> 
>>> To fix these I have pessimized the optimizer in the release branch but turning off two optimizations.
>>> 
>>> 
>>> It would be nice to find a better fix for the first.
>>> Even something sleazy like having the front end report up front to the backend if there are any nested functions in the unit, and only pessimizing such units.
>>> There is probably also a fix to gcc around preserving nested functions. I thought code in varasm.c was suspicious but couldn't get it to work quickly.
>> 		 	   		  

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

From jay.krell at cornell.edu  Fri Jun  4 21:55:30 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 4 Jun 2010 19:55:30 +0000
Subject: [M3devel] optimizer problems
In-Reply-To: <1B0AB99B-837F-464E-9BE7-140DAEB59E5E@cs.purdue.edu>
References: <COL101-W915873EEE558B40A8F280E6D20@phx.gbl>, ,
	<282D3F06-9C5A-4525-B1D0-77E59B12D833@cs.purdue.edu>,
	<COL101-W5966EA54CF4DA49BC6D74E6D20@phx.gbl>,
	<1B0AB99B-837F-464E-9BE7-140DAEB59E5E@cs.purdue.edu>
Message-ID: <COL101-W57AFCFC65554B7DD84A092E6D20@phx.gbl>


I will experiment more.
I don't remember if I tried as much as "exported", which is clearly wrong, but it'd be interesting to see if *some* way can preserve it. Should also be easy to find the code that removes it.
 
 
 
I have more questions..not well formed..not having researched a lot..so have held off..but..like..what is it about our trees? What is it you refer to as the missing type information and the problems with alias analysis? I understand to some extent. But we do actually mostly seem to build reasonable and reasonably typed trees.
Granted, I haven't compared to C trees.
I guess using the various dump option for C trees and our trees would be good.
 
 
 
I think one place we fail is access globals, and indeed accessing structs.
We just offset from them I think, instead of accessing fields.
Is that what you mean??
 
 
For "scalar" locals and globals, our trees seem ok, right?
 
 
 
As I aid, I should just use more of the gcc dump options and compare.
 
 
TYPE T1 = RECORD a,b:INTEGER END;
 
global:T1{3,4};
 
PROCEDURE F1() =
VAR local:T1{1,2};
BEGIN
  local.a := global.b;
  globa.a := local.b;
END;
 
 
typedef struct {ptrdiff_t a,b;}T1;
T1 global = {3,4};
 
void F1()
{
  T1 local = {1,2};
  local.a = global.b;
  global.a = local.b;
}
 
 
I should probably compile each of these and dump their "generic" trees and compare?
And strive to have them match?
 
 
More importantly though is loophole and float.
 
 
TYPE T1 = RECORD a,b:int END;
TYPE T2 = RECORD a,b:float END;
 
 
global:T1{3,4};
 
 
PROCEDURE F1() =
VAR local:T2{0.0,0.0;
BEGIN
  LOOPHOLE(local, T1).a := global.b;
  LOOPHOLE(global, T2).a := local.b;
END;
 
 
typedef struct {int a,b;}T1;
typedef struct {float a,b;}T2;
T1 global = {3,4};
 
 
void F1()
{
  T2 local = {0,0};
  ((T1*)&local)->a = global.b;
  ((T2*)&global)->a = local.b;
}
 
 
stuff like that?
Get those C and Modula-3 trees to match?
 
 
I assume as part of this, if it seems "necessary" to add volatile store/load to all loophole uses,
in order to remove volatile from floats, that is probably an ok compromise.
Even when loophole is acting on non-floats.
Maybe the problem is loophole and structs though. That seems likely.
Ideally loopholing between integers and pointers doesn't require store/load, as it currently doesn't.
 
 
Again, really, though I've removed a lot of volatile, I'm still quite bothered, since I still put it on every floating point use.
 
 
The vrp/fre/pre stuff I think will be more difficult, but maybe I can figure those out.
vrp I just know results in a broken compiler. I haven't looked at it beyond that.
I guess the thing to do is compile some chunk of code, e.g. m3core, with vrp being the only variable, and see what varies, and go from there.
 
 
Given how much optimization does work now, I doubt the effort is very worthwhile on the lingering view I disabled, except, again, for unit at a time and volatile float. We'll see..
 
 
I was doing kind of dumb slow unscientific work before. There are many optimization flags and I wanted to narrow them down more than one at a time, so I'd guess, switch a few on, upgrade, if it worked proceed, if it failed, alter the guess some.
 
 
And there's still Solaris/sparc32 to do similar with..
Should be more automated but my current methods are quite tedious.. :(
 
 
 
 - Jay











________________________________
> From: hosking at cs.purdue.edu
> Date: Fri, 4 Jun 2010 13:56:44 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] optimizer problems
>
>
>
> Or "external". I assume it is getting dead code eliminated.
>
>
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
>
>
>
>
>
>
> On 4 Jun 2010, at 13:06, Jay K wrote:
>
>
> I already tried that.. :(
>
>
> - Jay
>
>
> ----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Fri, 4 Jun 2010 12:37:45 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] optimizer problems
>
> You should be able to mark it as used.
>
> On 4 Jun 2010, at 12:29, Jay K wrote:
>
>
> Just a note that I have found at least two pieces of code that fail to compile with optimization enabled, even in the release branch.
>
> One is a simple case involving unused nested functions.
> One is a complicated not really understood case.
>
>
> To fix these I have pessimized the optimizer in the release branch but turning off two optimizations.
>
>
> It would be nice to find a better fix for the first.
> Even something sleazy like having the front end report up front to the backend if there are any nested functions in the unit, and only pessimizing such units.
> There is probably also a fix to gcc around preserving nested functions. I thought code in varasm.c was suspicious but couldn't get it to work quickly.
>
> 		 	   		  

From jay.krell at cornell.edu  Sat Jun  5 21:23:24 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 5 Jun 2010 19:23:24 +0000
Subject: [M3devel] cvs down?
Message-ID: <COL101-W60FFAA82EE18F721A82159E6D30@phx.gbl>


My last commit didn't send mail.
cvs diff and update aren't working.

?- Jay




 		 	   		  

From jay.krell at cornell.edu  Sat Jun  5 22:52:34 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 5 Jun 2010 20:52:34 +0000
Subject: [M3devel] further removal of volatile
Message-ID: <COL101-W4299A2A8F51F83263BDF87E6D30@phx.gbl>


Tony, Currently we still put volatile on all floating point loads and/or stores.
I removed it from all the other types.
The main problem I was having is that CopySign in m3core would fail to compile.
?It is loophoing a float as a struct with bitfields I believe.
? I didn't look at what the equivalent C tree would be, though that is probably a good idea.


With this it seems I don't need the volatile:


static void
m3_load_1 (tree v, int o, tree src_t, m3_type src_T, tree dst_t, m3_type dst_T,
?????????? bool volatil)
{
? if (o != 0 || TREE_TYPE (v) != src_t)
? {
??? if (GCC42 || (src_T != dst_T))?? <<< 
??? {
????? /* failsafe, but inefficient */
????? v = m3_build1 (ADDR_EXPR, t_addr, v);
????? v = m3_build2 (PLUS_EXPR, t_addr, v, size_int (o / BITS_PER_UNIT));
????? v = m3_build1 (INDIRECT_REF, src_t,
????? m3_cast (m3_build_pointer_type (src_t), v));
??? }
??? else
??? {
????? v = m3_build3 (BIT_FIELD_REF, src_t, v, TYPE_SIZE (src_t),
???????????????????? bitsize_int (o));
??? }
? }
?...



static void
m3_store_1 (tree v, int o, tree src_t, m3_type src_T, tree dst_t, m3_type dst_T,
??????????? bool volatil)
{
? tree val;
? if (o != 0 || TREE_TYPE (v) != dst_t)
? {
??? if (GCC42 || (src_T != dst_T))?? <<<< 
??? {
????? /* failsafe, but inefficient */
????? v = m3_build1 (ADDR_EXPR, t_addr, v);
????? v = m3_build2 (PLUS_EXPR, t_addr, v, size_int (o / BITS_PER_UNIT));
????? v = m3_build1 (INDIRECT_REF, dst_t,
???????????????????? m3_cast (m3_build_pointer_type (dst_t), v));
??? }
??? else
??? {
????? v = m3_build3 (BIT_FIELD_REF, dst_t, v, TYPE_SIZE (dst_t),
???????????????????? bitsize_int (o));
??? }
? }..

Previously, the code was the equivalent of saying if GCC42 there.


Good enough?


You know, this bitfield stuff has been a recurring problem.

I could probably narrow it down more.
? Like maybe if the types are the same size or both integers, still go down the old faster path.
??? Though I thought I had tried if they were either float going slow and that didn't work.
???? It might relate to structs as well.


However inefficient the non-bitfield ref path is, I can hope/assume it isn't as bad now without volatile.
But I could look a bit at the code.


?- Jay
 		 	   		  

From hosking at cs.purdue.edu  Sat Jun  5 23:46:00 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 5 Jun 2010 17:46:00 -0400
Subject: [M3devel] further removal of volatile
In-Reply-To: <COL101-W4299A2A8F51F83263BDF87E6D30@phx.gbl>
References: <COL101-W4299A2A8F51F83263BDF87E6D30@phx.gbl>
Message-ID: <37F7DB2D-2415-425D-BD64-3811174969C4@cs.purdue.edu>

But what sort of code do you get not using the BIT_FIELD_REF?


On 5 Jun 2010, at 16:52, Jay K wrote:

> 
> Tony, Currently we still put volatile on all floating point loads and/or stores.
> I removed it from all the other types.
> The main problem I was having is that CopySign in m3core would fail to compile.
>  It is loophoing a float as a struct with bitfields I believe.
>   I didn't look at what the equivalent C tree would be, though that is probably a good idea.
> 
> 
> With this it seems I don't need the volatile:
> 
> 
> static void
> m3_load_1 (tree v, int o, tree src_t, m3_type src_T, tree dst_t, m3_type dst_T,
>            bool volatil)
> {
>   if (o != 0 || TREE_TYPE (v) != src_t)
>   {
>     if (GCC42 || (src_T != dst_T))   <<< 
>     {
>       /* failsafe, but inefficient */
>       v = m3_build1 (ADDR_EXPR, t_addr, v);
>       v = m3_build2 (PLUS_EXPR, t_addr, v, size_int (o / BITS_PER_UNIT));
>       v = m3_build1 (INDIRECT_REF, src_t,
>       m3_cast (m3_build_pointer_type (src_t), v));
>     }
>     else
>     {
>       v = m3_build3 (BIT_FIELD_REF, src_t, v, TYPE_SIZE (src_t),
>                      bitsize_int (o));
>     }
>   }
>  ...
> 
> 
> 
> static void
> m3_store_1 (tree v, int o, tree src_t, m3_type src_T, tree dst_t, m3_type dst_T,
>             bool volatil)
> {
>   tree val;
>   if (o != 0 || TREE_TYPE (v) != dst_t)
>   {
>     if (GCC42 || (src_T != dst_T))   <<<< 
>     {
>       /* failsafe, but inefficient */
>       v = m3_build1 (ADDR_EXPR, t_addr, v);
>       v = m3_build2 (PLUS_EXPR, t_addr, v, size_int (o / BITS_PER_UNIT));
>       v = m3_build1 (INDIRECT_REF, dst_t,
>                      m3_cast (m3_build_pointer_type (dst_t), v));
>     }
>     else
>     {
>       v = m3_build3 (BIT_FIELD_REF, dst_t, v, TYPE_SIZE (dst_t),
>                      bitsize_int (o));
>     }
>   }..
> 
> Previously, the code was the equivalent of saying if GCC42 there.
> 
> 
> Good enough?
> 
> 
> You know, this bitfield stuff has been a recurring problem.
> 
> I could probably narrow it down more.
>   Like maybe if the types are the same size or both integers, still go down the old faster path.
>     Though I thought I had tried if they were either float going slow and that didn't work.
>      It might relate to structs as well.
> 
> 
> However inefficient the non-bitfield ref path is, I can hope/assume it isn't as bad now without volatile.
> But I could look a bit at the code.
> 
> 
>  - Jay
> 		 	   		  



From jay.krell at cornell.edu  Sun Jun  6 00:16:49 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 5 Jun 2010 22:16:49 +0000
Subject: [M3devel] further removal of volatile
In-Reply-To: <37F7DB2D-2415-425D-BD64-3811174969C4@cs.purdue.edu>
References: <COL101-W4299A2A8F51F83263BDF87E6D30@phx.gbl>,
	<37F7DB2D-2415-425D-BD64-3811174969C4@cs.purdue.edu>
Message-ID: <COL101-W49F94907D04D32B1EF7421E6D30@phx.gbl>


I didn't look...but darn..one problem seemingly present here:

/Users/jay/dev2/cm3/caltech-parser/parserlib/klex/AMD64_DARWIN/klex ../src/Calc.l -o CalcLex.i3 -t ../src/Calc.t -ti3 CalcTok.i3


***
*** runtime error:
***??? Segmentation violation - possible attempt to dereference NIL
***??? pc = 0x100012fa7 = Output + 0x17 in ../src/NFA.m3
***

"/cm3.amd64/pkg/cit_util/src/generics.tmpl", line 38: quake runtime error: exit 1536: /Users/jay/dev2/cm3/caltech-parser/parserlib/klex/AMD64_DARWIN/klex ../src/Calc.l -o CalcLex.i3 -t ../src/Calc.t -ti3 CalcTok.i3

ugh.

Later..
?- Jay


----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Sat, 5 Jun 2010 17:46:00 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] further removal of volatile
>
> But what sort of code do you get not using the BIT_FIELD_REF?
>
>
> On 5 Jun 2010, at 16:52, Jay K wrote:
>
>>
>> Tony, Currently we still put volatile on all floating point loads and/or stores.
>> I removed it from all the other types.
>> The main problem I was having is that CopySign in m3core would fail to compile.
>> It is loophoing a float as a struct with bitfields I believe.
>> I didn't look at what the equivalent C tree would be, though that is probably a good idea.
>>
>>
>> With this it seems I don't need the volatile:
>>
>>
>> static void
>> m3_load_1 (tree v, int o, tree src_t, m3_type src_T, tree dst_t, m3_type dst_T,
>> bool volatil)
>> {
>> if (o != 0 || TREE_TYPE (v) != src_t)
>> {
>> if (GCC42 || (src_T != dst_T)) <<<
>> {
>> /* failsafe, but inefficient */
>> v = m3_build1 (ADDR_EXPR, t_addr, v);
>> v = m3_build2 (PLUS_EXPR, t_addr, v, size_int (o / BITS_PER_UNIT));
>> v = m3_build1 (INDIRECT_REF, src_t,
>> m3_cast (m3_build_pointer_type (src_t), v));
>> }
>> else
>> {
>> v = m3_build3 (BIT_FIELD_REF, src_t, v, TYPE_SIZE (src_t),
>> bitsize_int (o));
>> }
>> }
>> ...
>>
>>
>>
>> static void
>> m3_store_1 (tree v, int o, tree src_t, m3_type src_T, tree dst_t, m3_type dst_T,
>> bool volatil)
>> {
>> tree val;
>> if (o != 0 || TREE_TYPE (v) != dst_t)
>> {
>> if (GCC42 || (src_T != dst_T)) <<<<
>> {
>> /* failsafe, but inefficient */
>> v = m3_build1 (ADDR_EXPR, t_addr, v);
>> v = m3_build2 (PLUS_EXPR, t_addr, v, size_int (o / BITS_PER_UNIT));
>> v = m3_build1 (INDIRECT_REF, dst_t,
>> m3_cast (m3_build_pointer_type (dst_t), v));
>> }
>> else
>> {
>> v = m3_build3 (BIT_FIELD_REF, dst_t, v, TYPE_SIZE (dst_t),
>> bitsize_int (o));
>> }
>> }..
>>
>> Previously, the code was the equivalent of saying if GCC42 there.
>>
>>
>> Good enough?
>>
>>
>> You know, this bitfield stuff has been a recurring problem.
>>
>> I could probably narrow it down more.
>> Like maybe if the types are the same size or both integers, still go down the old faster path.
>> Though I thought I had tried if they were either float going slow and that didn't work.
>> It might relate to structs as well.
>>
>>
>> However inefficient the non-bitfield ref path is, I can hope/assume it isn't as bad now without volatile.
>> But I could look a bit at the code.
>>
>>
>> - Jay
>>
>
 		 	   		  

From jay.krell at cornell.edu  Sun Jun  6 02:53:52 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 6 Jun 2010 00:53:52 +0000
Subject: [M3devel] cvs down?
Message-ID: <COL101-W4496C59304ACFEC817DC7BE6D40@phx.gbl>


It is back.

----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Subject: cvs down?
> Date: Sat, 5 Jun 2010 19:23:24 +0000
>
>
> My last commit didn't send mail.
> cvs diff and update aren't working.
>
>  - Jay
 		 	   		  

From jay.krell at cornell.edu  Wed Jun  9 09:07:18 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 9 Jun 2010 07:07:18 +0000
Subject: [M3devel] maybe volatile is "good"?
Message-ID: <COL101-W117095721973381CF1CEA6E6D70@phx.gbl>


A friend was asking about the portability of the system, and the "ptrdiff_t problem" -- where the optimizer might generate code whereby pointers exist but aren't evident in any registers or on the stack, because instead some pointer difference is being applied. I can't describe this well, but I know what he was referring to. A posting by David Chase mentions it. The result is that the garbage collector doesn't realize something is live and prematurely frees it, or moves it and doesn't update references...ok here is the link:

http://compilers.iecc.com/comparch/article/90-08-046

"...Worse things can happen; in some situations, it

may profit to use &a[-100] to reference elements of a, or to use

&b[0]-&a[0] to generate references to b"

So, this makes me nervous about my recent removal of making all loads and stores volatile.

Maybe best to put them back?

I know the optimized codegen was terrible, but..

?- Jay




 		 	   		  

From hosking at cs.purdue.edu  Wed Jun  9 14:13:21 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 9 Jun 2010 08:13:21 -0400
Subject: [M3devel] maybe volatile is "good"?
In-Reply-To: <COL101-W117095721973381CF1CEA6E6D70@phx.gbl>
References: <COL101-W117095721973381CF1CEA6E6D70@phx.gbl>
Message-ID: <FF22799E-E5D2-4C69-82E9-2EA35EEF3954@cs.purdue.edu>

This is not a problem.   gcc doesn't perform these optimisations, as far as I know.

On 9 Jun 2010, at 03:07, Jay K wrote:

> 
> A friend was asking about the portability of the system, and the "ptrdiff_t problem" -- where the optimizer might generate code whereby pointers exist but aren't evident in any registers or on the stack, because instead some pointer difference is being applied. I can't describe this well, but I know what he was referring to. A posting by David Chase mentions it. The result is that the garbage collector doesn't realize something is live and prematurely frees it, or moves it and doesn't update references...ok here is the link:
> 
> http://compilers.iecc.com/comparch/article/90-08-046
> 
> "...Worse things can happen; in some situations, it
> 
> may profit to use &a[-100] to reference elements of a, or to use
> 
> &b[0]-&a[0] to generate references to b"
> 
> So, this makes me nervous about my recent removal of making all loads and stores volatile.
> 
> Maybe best to put them back?
> 
> I know the optimized codegen was terrible, but..
> 
>  - Jay
> 
> 
> 
> 
> 		 	   		  



From jay.krell at cornell.edu  Sat Jun 12 17:11:42 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 12 Jun 2010 15:11:42 +0000
Subject: [M3devel] size vs. speed set_member / set_singleton serialized on
	NT386
Message-ID: <COL101-W447DCAFDF282BFB9A659D7E6DA0@phx.gbl>


We used to have (still in release branch):

m3-libs/m3core/src/Csupport/Common/parse.c:

void __cdecl set_singleton
??? ANSI((????? long a, ulong* s))
????? KR((a, s) long a; ulong* s;)
{
? long a_word = a / SET_GRAIN;
? long a_bit? = a % SET_GRAIN;
? s[a_word] |= (1UL << a_bit);
}


long __cdecl set_member
??? ANSI((????????? long elt, ulong* set))
????? KR((elt, set) long elt; ulong* set;)
{
? register long word = elt / SET_GRAIN;
? register long bit? = elt % SET_GRAIN;
? return (set[word] & (1UL << bit)) != 0;
}

Both backends generate calls to these functions.


In the gcc backend we now inline the equivalent.
In the NT backend, I use the bt and bts instructions.
?The resulting code is very size optimized.
? bt and bts do the shift, the index, the and/or. All in one.

I don't think I knew it at the time, but bt/bts are interlocked/seralized/atomic -- slow.

Maybe the wrong choice here?
Should instead inline the equivalent mask/index/and/or like the gcc backend does?


?- Jay
 		 	   		  

From jay.krell at cornell.edu  Sat Jun 12 22:24:57 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 12 Jun 2010 20:24:57 +0000
Subject: [M3devel] Modula-3 on Alpha/osf
Message-ID: <COL101-W6299CB615484EB3A70C44CE6DA0@phx.gbl>


It can compile itself. No stack walker currently.
User threads were used accidentally and worked. pthreads now.
No gui apps tested.

Compiling m3-libs/arithmetic:

Program received signal SIGFPE, Arithmetic exception.
0x00000001203c8c80 in TFloat__Multiply ()
(gdb) bt
#0? 0x00000001203c8c80 in TFloat__Multiply ()
#1? 0x000000012034a334 in ReelExpr__Multiply ()
#2? 0x0000000120373e10 in MultiplyExpr__Fold ()
#3? 0x00000001201ff810 in Expr__ConstValue ()
#4? 0x0000000120203744 in Constant__Check ()
#5? 0x0000000120163100 in Value__TypeCheck ()
#6? 0x00000001201853b4 in Scope__TypeCheck ()
#7? 0x000000012017cfdc in Module__TypeCheck ()
#8? 0x0000000120159b14 in M3Front__DoCompile ()
#9? 0x00000001201589f8 in M3Front__Compile ()
#10 0x0000000120059418 in Builder__RunM3 ()


Really, not all that interesting, the system has proven very portable.


Untested min distribution (with above bug):
http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-ALPHA_OSF-d5.8.2-20100612.tar.gz

Thanks to Mika for running the hardware/OS.


more later,
?- Jay
 		 	   		  

From jay.krell at cornell.edu  Sun Jun 13 00:39:18 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 12 Jun 2010 22:39:18 +0000
Subject: [M3devel] integer overflow
Message-ID: <COL101-W35BD9898C6B5DE9BC5A498E6DA0@phx.gbl>


Been reading about Alpha:


Alpha and Programming Languages 
Alpha is an attractive architecture for compiling a large variety of programming languages. 
Alpha has been carefull y desi gned to avoi d bi as t oward one or two progra mmi ng languages. 
For example: 
? Alpha does not contain a subroutine call instruction that moves a register window by a 
fixed amount. Thus, Alpha is a good match for programming languages with many 
parameters and programming languages with no parameters. 
? Alpha does not contain a global integer overflow enable bit. Such a bit would need to 
be changed at every subroutine boundary when a FORTRAN program calls a C pro- 
gram. 







...


Integer Operate Instructions 
...Integer overfl ow tr ap enable is encoded in t he functi on fie ld of ea ch instruct ion, ra ther t han 
kept in a global state bit. Thus, for example, both ADDQ/V and ADDQ opcodes exist for spec- 
ifying 64-bi t ADD with and without overflow checking. That makes it easier to pipe line 
implementations. 



?- Jay
 		 	   		  

From jay.krell at cornell.edu  Sun Jun 13 07:44:17 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 13 Jun 2010 05:44:17 +0000
Subject: [M3devel] Modula-3 on Alpha/osf
Message-ID: <COL101-W49D9DFBDF25B81EC171D18E6DB0@phx.gbl>


Ok, the floating point problem is fixed well enough now. Mika reports several X apps work.


http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-all-ALPHA_OSF-d5.8.2-20100612.tar.gz
http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-all-ALPHA_OSF-d5.8.2-20100612.tar.xz
http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-ALPHA_OSF-d5.8.2-20100612.tar.gz
http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-ALPHA_OSF-d5.8.2-20100612.tar.xz

I admit I forgot to remove $HOME/bin from $PATH when building these and it likely mattered.
Though "stock" install should suffice to use it.


These builds maybe lack most symbols.

?- Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com; mika at async.async.caltech.edu
> Subject: Modula-3 on Alpha/osf
> Date: Sat, 12 Jun 2010 20:24:57 +0000
>
>
> It can compile itself. No stack walker currently.
> User threads were used accidentally and worked. pthreads now.
> No gui apps tested.
>
> Compiling m3-libs/arithmetic:
>
> Program received signal SIGFPE, Arithmetic exception.
> 0x00000001203c8c80 in TFloat__Multiply ()
> (gdb) bt
> #0  0x00000001203c8c80 in TFloat__Multiply ()
> #1  0x000000012034a334 in ReelExpr__Multiply ()
> #2  0x0000000120373e10 in MultiplyExpr__Fold ()
> #3  0x00000001201ff810 in Expr__ConstValue ()
> #4  0x0000000120203744 in Constant__Check ()
> #5  0x0000000120163100 in Value__TypeCheck ()
> #6  0x00000001201853b4 in Scope__TypeCheck ()
> #7  0x000000012017cfdc in Module__TypeCheck ()
> #8  0x0000000120159b14 in M3Front__DoCompile ()
> #9  0x00000001201589f8 in M3Front__Compile ()
> #10 0x0000000120059418 in Builder__RunM3 ()
>
>
> Really, not all that interesting, the system has proven very portable.
>
>
> Untested min distribution (with above bug):
> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-ALPHA_OSF-d5.8.2-20100612.tar.gz
>
> Thanks to Mika for running the hardware/OS.
>
>
> more later,
>  - Jay
>
 		 	   		  

From jay.krell at cornell.edu  Sun Jun 13 07:46:14 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 13 Jun 2010 05:46:14 +0000
Subject: [M3devel] interesting osf cc option for uninitialized variables
Message-ID: <COL101-W7E2AF461FEDBCE3741EE6E6DB0@phx.gbl>


? -trapuv
????? Forces all uninitialized stack variables to be initialized with
????? 0xfff58005fff58005. When this value is used as a floating-point vari-
????? able, it is treated as a floating-point NaN and causes a floating-point
????? trap.? When it is used as a pointer, an address or segmentation viola-
????? tion usually occurs.


Relates to recent discussion.
This should probably be how longreals are initialize for this target.
Though in reality I'm not very motivated to make this target esp. better than any others.
It is interesting to see though what features people have put into C compilers.


?- Jay





 		 	   		  

From rodney_bates at lcwb.coop  Sun Jun 13 17:08:15 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Sun, 13 Jun 2010 10:08:15 -0500
Subject: [M3devel] interesting osf cc option for uninitialized variables
In-Reply-To: <COL101-W7E2AF461FEDBCE3741EE6E6DB0@phx.gbl>
References: <COL101-W7E2AF461FEDBCE3741EE6E6DB0@phx.gbl>
Message-ID: <4C14F45F.2090709@lcwb.coop>



Jay K wrote:
>   -trapuv
>       Forces all uninitialized stack variables to be initialized with
>       0xfff58005fff58005. When this value is used as a floating-point vari-
>       able, it is treated as a floating-point NaN and causes a floating-point
>       trap.  When it is used as a pointer, an address or segmentation viola-
>       tion usually occurs.

In the case of a pointer, doing this would violate the Modula-3 language rule
that all variables are initialized to a bit pattern that represents a valid
member of the variable's type.  For a pointer, this would have to be either
the address of an allocated heap object or NIL.  Only the NIL makes any sense.

I like the idea for floats, though, and I consider a NaN to be a valid member
of the type.

> 
> 
> Relates to recent discussion.
> This should probably be how longreals are initialize for this target.
> Though in reality I'm not very motivated to make this target esp. better than any others.
> It is interesting to see though what features people have put into C compilers.
> 
> 
>  - Jay
> 
> 
> 
> 
> 
>  		 	   		  


From rodney_bates at lcwb.coop  Sun Jun 13 17:12:54 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Sun, 13 Jun 2010 10:12:54 -0500
Subject: [M3devel] integer overflow
In-Reply-To: <COL101-W35BD9898C6B5DE9BC5A498E6DA0@phx.gbl>
References: <COL101-W35BD9898C6B5DE9BC5A498E6DA0@phx.gbl>
Message-ID: <4C14F576.5000104@lcwb.coop>



Jay K wrote:
> Been reading about Alpha:
> 
> 
> Alpha and Programming Languages 
> Alpha is an attractive architecture for compiling a large variety of programming languages. 
> Alpha has been carefull y desi gned to avoi d bi as t oward one or two progra mmi ng languages. 
> For example: 
> ? Alpha does not contain a subroutine call instruction that moves a register window by a 
> fixed amount. Thus, Alpha is a good match for programming languages with many 
> parameters and programming languages with no parameters. 
> ? Alpha does not contain a global integer overflow enable bit. Such a bit would need to 
> be changed at every subroutine boundary when a FORTRAN program calls a C pro- 
> gram. 
> 
> 
> 
> 
> 
> 
> 
> ...
> 
> 
> Integer Operate Instructions 
> ...Integer overfl ow tr ap enable is encoded in t he functi on fie ld of ea ch instruct ion, ra ther t han 
> kept in a global state bit. Thus, for example, both ADDQ/V and ADDQ opcodes exist for spec- 
> ifying 64-bi t ADD with and without overflow checking. That makes it easier to pipe line 
> implementations. 
> 
> 

I'm all for trapping integer overflows, if the performance penalty isn't just horrible.  I doubt
that in more than a tiny minority of cases, integer overflows that silently wrap around (or
silently do anything else) are cases the original programmer knew were correct or even thought
about the possibility they might happen.

> 
>  - Jay
>  		 	   		  


From jay.krell at cornell.edu  Sun Jun 13 22:43:22 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 13 Jun 2010 20:43:22 +0000
Subject: [M3devel] -rpath/origin/CM3_INSTALL on osf
Message-ID: <COL101-W3A566B3FC93FA0C3C7817E6DB0@phx.gbl>


OSF, at least the older version that Mika is running, supports -rpath /foo/bar and -rpath ${arbitrary_environment_variable}, but not -rpath $origin.


Therefore I believe we should pick an arbitrary_environment_variable.


I'd like CM3_ROOT, but that is already somewhat/optionally in use for the root of the source tree.
CM3_INSTALL is somewhat/optionally in use to mean what we want here.
So CM3_INSTALL should probably be it.


Alternatively we could pick something really new, OSF_CM3_RPATH or such, and drop in wrapper scripts that set it to their location.


As well, OSF still has the "old" structure where all the .so files are strewn around pkg instead of flattened into lib.
I'll fix that shortly.


You know, the distributions I uploaded have /home/jayk presumably all around them.


We could also "stage" installs to somewhere unique/arbitrary and require user to set LD_LIBRARY_PATH.
But CM3_INSTALL seems adequate, maybe better.


Possibly CM3_INSTALL_5_8, CM3_INSTALL_5_9, etc.
? Though really, better than that is probably wrapper scripts that set CM3_INSTALL.
And wrapper scripts could be executables, put the real executables in lib or such.


?- Jay
 		 	   		  

From jay.krell at cornell.edu  Mon Jun 14 09:05:26 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 14 Jun 2010 07:05:26 +0000
Subject: [M3devel] -rpath/origin/CM3_INSTALL on osf
Message-ID: <COL101-W67A6DC7F1AAB8224C9C67E6DC0@phx.gbl>


It looks like you can't use $FOO/t, just $FOO.
So I'll probably use CM3_RPATH.

?- Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Subject: -rpath/origin/CM3_INSTALL on osf
> Date: Sun, 13 Jun 2010 20:43:22 +0000
>
>
> OSF, at least the older version that Mika is running, supports -rpath /foo/bar and -rpath ${arbitrary_environment_variable}, but not -rpath $origin.
>
>
> Therefore I believe we should pick an arbitrary_environment_variable.
>
>
> I'd like CM3_ROOT, but that is already somewhat/optionally in use for the root of the source tree.
> CM3_INSTALL is somewhat/optionally in use to mean what we want here.
> So CM3_INSTALL should probably be it.
>
>
> Alternatively we could pick something really new, OSF_CM3_RPATH or such, and drop in wrapper scripts that set it to their location.
>
>
> As well, OSF still has the "old" structure where all the .so files are strewn around pkg instead of flattened into lib.
> I'll fix that shortly.
>
>
> You know, the distributions I uploaded have /home/jayk presumably all around them.
>
>
> We could also "stage" installs to somewhere unique/arbitrary and require user to set LD_LIBRARY_PATH.
> But CM3_INSTALL seems adequate, maybe better.
>
>
> Possibly CM3_INSTALL_5_8, CM3_INSTALL_5_9, etc.
>   Though really, better than that is probably wrapper scripts that set CM3_INSTALL.
> And wrapper scripts could be executables, put the real executables in lib or such.
>
>
>  - Jay
>
 		 	   		  

From jay.krell at cornell.edu  Mon Jun 14 23:04:35 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 14 Jun 2010 21:04:35 +0000
Subject: [M3devel] -rpath/origin/CM3_INSTALL on osf
Message-ID: <COL101-W1739F3FDC24AB9E1B858FAE6DC0@phx.gbl>


I'm strongly considering dropping in bin stubs that calculate and set CM3_RPATH and then exec the actual files, in cm3/lib.
Thoughts?
It'd only be for OSF.
And only for shared executables -- wouldn't break cm3 finding config files.
Whether or not argv[0] "lies" and remains as bin, or is "truth" and set to lib, unsure.


Alternatively, relink on upon ship/install?
? That I believe is not unusual practise. It'd also fix NetBSD 4.0..
??? And it is in some ways better than the current use of $ORIGIN on all other systems.
? Augment "boot1.py" to build the entire system, and build a makefile that rebuilds and ships all libraries/executables?
? Well, what that probably looks like is augmenting it with Olaf's packaging.
?? Use that layout, and the method of using cd+cm3, but include all the .c and .s files and have cm3 run assemble/make_lib/ship.
?? We likely want that anyway, as a more complete form of cross build. Where I define "cross build" in an odd way -- compiling
?? all the Modula-3 to assembly, but not compiling any of the C or running the assembler or linking.
?? 
There are possible other options, like have the stub determine all the files to load and put them in _RLD_LIST.

Or just don't support shared libraries on OSF?

Or just distribute existing "boot" for OSF, and require people (Mika) to run scripts/python/boot2.sh?
?This is maybe the best short term choice. Doesn't require any work, supports shared libraries.
?I think I'll "try" that. Upload a current boot and if Mika can get it to work from there and doesn't mind it, good enough.

?- Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Subject: RE: -rpath/origin/CM3_INSTALL on osf
> Date: Mon, 14 Jun 2010 07:05:26 +0000
>
>
> It looks like you can't use $FOO/t, just $FOO.
> So I'll probably use CM3_RPATH.
>
>  - Jay
>
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: m3devel at elegosoft.com
>> Subject: -rpath/origin/CM3_INSTALL on osf
>> Date: Sun, 13 Jun 2010 20:43:22 +0000
>>
>>
>> OSF, at least the older version that Mika is running, supports -rpath /foo/bar and -rpath ${arbitrary_environment_variable}, but not -rpath $origin.
>>
>>
>> Therefore I believe we should pick an arbitrary_environment_variable.
>>
>>
>> I'd like CM3_ROOT, but that is already somewhat/optionally in use for the root of the source tree.
>> CM3_INSTALL is somewhat/optionally in use to mean what we want here.
>> So CM3_INSTALL should probably be it.
>>
>>
>> Alternatively we could pick something really new, OSF_CM3_RPATH or such, and drop in wrapper scripts that set it to their location.
>>
>>
>> As well, OSF still has the "old" structure where all the .so files are strewn around pkg instead of flattened into lib.
>> I'll fix that shortly.
>>
>>
>> You know, the distributions I uploaded have /home/jayk presumably all around them.
>>
>>
>> We could also "stage" installs to somewhere unique/arbitrary and require user to set LD_LIBRARY_PATH.
>> But CM3_INSTALL seems adequate, maybe better.
>>
>>
>> Possibly CM3_INSTALL_5_8, CM3_INSTALL_5_9, etc.
>> Though really, better than that is probably wrapper scripts that set CM3_INSTALL.
>> And wrapper scripts could be executables, put the real executables in lib or such.
>>
>>
>> - Jay
>>
>
 		 	   		  

From wagner at elegosoft.com  Tue Jun 15 11:04:21 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Tue, 15 Jun 2010 11:04:21 +0200
Subject: [M3devel] -rpath/origin/CM3_INSTALL on osf
In-Reply-To: <COL101-W1739F3FDC24AB9E1B858FAE6DC0@phx.gbl>
References: <COL101-W1739F3FDC24AB9E1B858FAE6DC0@phx.gbl>
Message-ID: <20100615110421.7sika6yr4sskso4g@mail.elegosoft.com>

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

> I'm strongly considering dropping in bin stubs that calculate and   
> set CM3_RPATH and then exec the actual files, in cm3/lib.
> Thoughts?
> It'd only be for OSF.
> And only for shared executables -- wouldn't break cm3 finding config files.
> Whether or not argv[0] "lies" and remains as bin, or is "truth" and   
> set to lib, unsure.
>
>
> Alternatively, relink on upon ship/install?
> ? That I believe is not unusual practise. It'd also fix NetBSD 4.0..
> ??? And it is in some ways better than the current use of $ORIGIN on  
>  all other systems.
> ? Augment "boot1.py" to build the entire system, and build a   
> makefile that rebuilds and ships all libraries/executables?
> ? Well, what that probably looks like is augmenting it with Olaf's packaging.
> ?? Use that layout, and the method of using cd+cm3, but include all   
> the .c and .s files and have cm3 run assemble/make_lib/ship.
> ?? We likely want that anyway, as a more complete form of cross   
> build. Where I define "cross build" in an odd way -- compiling
> ?? all the Modula-3 to assembly, but not compiling any of the C or   
> running the assembler or linking.

I think `relink upon ship' would be interesting as an experimental
option. I'm still not sure if we should really do that or not,
but if it can be done with little effort, we may play with it.
  ??
> There are possible other options, like have the stub determine all   
> the files to load and put them in _RLD_LIST.
>
> Or just don't support shared libraries on OSF?

Sounds lame :-)

> Or just distribute existing "boot" for OSF, and require people   
> (Mika) to run scripts/python/boot2.sh?
> ?This is maybe the best short term choice. Doesn't require any work,  
>  supports shared libraries.
> ?I think I'll "try" that. Upload a current boot and if Mika can get   
> it to work from there and doesn't mind it, good enough.

OK with me, too, for now, if all users are satisfied with that.
We're only talking about ALPHA_OSF, aren't we?

Olaf

> ?- Jay
>
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: m3devel at elegosoft.com
>> Subject: RE: -rpath/origin/CM3_INSTALL on osf
>> Date: Mon, 14 Jun 2010 07:05:26 +0000
>>
>>
>> It looks like you can't use $FOO/t, just $FOO.
>> So I'll probably use CM3_RPATH.
>>
>>  - Jay
>>
>> ----------------------------------------
>>> From: jay.krell at cornell.edu
>>> To: m3devel at elegosoft.com
>>> Subject: -rpath/origin/CM3_INSTALL on osf
>>> Date: Sun, 13 Jun 2010 20:43:22 +0000
>>>
>>>
>>> OSF, at least the older version that Mika is running, supports   
>>> -rpath /foo/bar and -rpath ${arbitrary_environment_variable}, but   
>>> not -rpath $origin.
>>>
>>>
>>> Therefore I believe we should pick an arbitrary_environment_variable.
>>>
>>>
>>> I'd like CM3_ROOT, but that is already somewhat/optionally in use   
>>> for the root of the source tree.
>>> CM3_INSTALL is somewhat/optionally in use to mean what we want here.
>>> So CM3_INSTALL should probably be it.
>>>
>>>
>>> Alternatively we could pick something really new, OSF_CM3_RPATH or  
>>>  such, and drop in wrapper scripts that set it to their location.
>>>
>>>
>>> As well, OSF still has the "old" structure where all the .so files  
>>>  are strewn around pkg instead of flattened into lib.
>>> I'll fix that shortly.
>>>
>>>
>>> You know, the distributions I uploaded have /home/jayk presumably   
>>> all around them.
>>>
>>>
>>> We could also "stage" installs to somewhere unique/arbitrary and   
>>> require user to set LD_LIBRARY_PATH.
>>> But CM3_INSTALL seems adequate, maybe better.
>>>
>>>
>>> Possibly CM3_INSTALL_5_8, CM3_INSTALL_5_9, etc.
>>> Though really, better than that is probably wrapper scripts that   
>>> set CM3_INSTALL.
>>> And wrapper scripts could be executables, put the real executables  
>>>  in lib or such.
>>>
>>>
>>> - 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 jay.krell at cornell.edu  Wed Jun 16 09:01:28 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 16 Jun 2010 07:01:28 +0000
Subject: [M3devel] -rpath/origin/CM3_INSTALL on osf
In-Reply-To: <20100615110421.7sika6yr4sskso4g@mail.elegosoft.com>
References: <COL101-W1739F3FDC24AB9E1B858FAE6DC0@phx.gbl>,
	<20100615110421.7sika6yr4sskso4g@mail.elegosoft.com>
Message-ID: <COL101-W4A6E5C8BBFA0272B893F7E6DE0@phx.gbl>


Yes it is mainly about OSF.
Though it is also about running unshipped binaries on all systems -- dynamically linked ones.
For now I'll probably do nothing. Except put this in a todo.txt file I'm going to checkin, I think.
Other stuff first I think.

?- Jay

----------------------------------------
> Date: Tue, 15 Jun 2010 11:04:21 +0200
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] -rpath/origin/CM3_INSTALL on osf
>
> Quoting Jay K :
>
>> I'm strongly considering dropping in bin stubs that calculate and
>> set CM3_RPATH and then exec the actual files, in cm3/lib.
>> Thoughts?
>> It'd only be for OSF.
>> And only for shared executables -- wouldn't break cm3 finding config files.
>> Whether or not argv[0] "lies" and remains as bin, or is "truth" and
>> set to lib, unsure.
>>
>>
>> Alternatively, relink on upon ship/install?
>>   That I believe is not unusual practise. It'd also fix NetBSD 4.0..
>>     And it is in some ways better than the current use of $ORIGIN on
>> all other systems.
>>   Augment "boot1.py" to build the entire system, and build a
>> makefile that rebuilds and ships all libraries/executables?
>>   Well, what that probably looks like is augmenting it with Olaf's packaging.
>>    Use that layout, and the method of using cd+cm3, but include all
>> the .c and .s files and have cm3 run assemble/make_lib/ship.
>>    We likely want that anyway, as a more complete form of cross
>> build. Where I define "cross build" in an odd way -- compiling
>>    all the Modula-3 to assembly, but not compiling any of the C or
>> running the assembler or linking.
>
> I think `relink upon ship' would be interesting as an experimental
> option. I'm still not sure if we should really do that or not,
> but if it can be done with little effort, we may play with it.
>
>> There are possible other options, like have the stub determine all
>> the files to load and put them in _RLD_LIST.
>>
>> Or just don't support shared libraries on OSF?
>
> Sounds lame :-)
>
>> Or just distribute existing "boot" for OSF, and require people
>> (Mika) to run scripts/python/boot2.sh?
>>  This is maybe the best short term choice. Doesn't require any work,
>> supports shared libraries.
>>  I think I'll "try" that. Upload a current boot and if Mika can get
>> it to work from there and doesn't mind it, good enough.
>
> OK with me, too, for now, if all users are satisfied with that.
> We're only talking about ALPHA_OSF, aren't we?
>
> Olaf
>
>>  - Jay
>>
>> ----------------------------------------
>>> From: jay.krell at cornell.edu
>>> To: m3devel at elegosoft.com
>>> Subject: RE: -rpath/origin/CM3_INSTALL on osf
>>> Date: Mon, 14 Jun 2010 07:05:26 +0000
>>>
>>>
>>> It looks like you can't use $FOO/t, just $FOO.
>>> So I'll probably use CM3_RPATH.
>>>
>>> - Jay
>>>
>>> ----------------------------------------
>>>> From: jay.krell at cornell.edu
>>>> To: m3devel at elegosoft.com
>>>> Subject: -rpath/origin/CM3_INSTALL on osf
>>>> Date: Sun, 13 Jun 2010 20:43:22 +0000
>>>>
>>>>
>>>> OSF, at least the older version that Mika is running, supports
>>>> -rpath /foo/bar and -rpath ${arbitrary_environment_variable}, but
>>>> not -rpath $origin.
>>>>
>>>>
>>>> Therefore I believe we should pick an arbitrary_environment_variable.
>>>>
>>>>
>>>> I'd like CM3_ROOT, but that is already somewhat/optionally in use
>>>> for the root of the source tree.
>>>> CM3_INSTALL is somewhat/optionally in use to mean what we want here.
>>>> So CM3_INSTALL should probably be it.
>>>>
>>>>
>>>> Alternatively we could pick something really new, OSF_CM3_RPATH or
>>>> such, and drop in wrapper scripts that set it to their location.
>>>>
>>>>
>>>> As well, OSF still has the "old" structure where all the .so files
>>>> are strewn around pkg instead of flattened into lib.
>>>> I'll fix that shortly.
>>>>
>>>>
>>>> You know, the distributions I uploaded have /home/jayk presumably
>>>> all around them.
>>>>
>>>>
>>>> We could also "stage" installs to somewhere unique/arbitrary and
>>>> require user to set LD_LIBRARY_PATH.
>>>> But CM3_INSTALL seems adequate, maybe better.
>>>>
>>>>
>>>> Possibly CM3_INSTALL_5_8, CM3_INSTALL_5_9, etc.
>>>> Though really, better than that is probably wrapper scripts that
>>>> set CM3_INSTALL.
>>>> And wrapper scripts could be executables, put the real executables
>>>> in lib or such.
>>>>
>>>>
>>>> - 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 darko at darko.org  Fri Jun 18 03:08:14 2010
From: darko at darko.org (Darko)
Date: Thu, 17 Jun 2010 18:08:14 -0700
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>
References: <1274350133.8902.0.camel@localhost>
	<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>
Message-ID: <2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>

I've been interested in an ARM port for some time. If you (or anyone else) are interested  in doing the port I can send you one of these, which looks like a good platform since it runs Linux and Android, has 512K memory and looks well supported: http://beagleboard.org/hardware



On 20/05/2010, at 4:47 AM, 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? 
> 
		 	   		  



From jay.krell at cornell.edu  Fri Jun 18 06:15:05 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 18 Jun 2010 04:15:05 +0000
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>
References: <1274350133.8902.0.camel@localhost>,
	<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>,
	<2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>
Message-ID: <COL101-W580FCB4C956AC658A851ABE6C00@phx.gbl>


My preference would be if you can set it up on the internet and allow me ssh access.
gcc only recently got support for Android's C library "bionic", I believe post-gcc 4.5.
I'm not sure if that matters much or not.
I'm not sure how much the C library of the target matters to gcc.
 
 
Anything with pthreads and gcc support is quite easy to port to these days. In the past the biggest thing you had to do was rewrite /usr/include in Modula-3. There was a tendency to rewrite far more of it than necessary. These days, none of it is needed.
 
 
Now you just have to
  - pick a target name 
  - find the jmpbuf size, word size, endian 
  - write a much small "config" file
  - respond to each error that occurs -- fill in the platform in a few tables sprinkled around the tree 
 
 
Even systems without pthreads or with not very good pthreads (OpenBSD) are easy now, as the user thread support is much more portable. It used to be, for user threads, you had to poke around in the jmpbuf.
 
 
I would encourage anyone else to try it out.
 
 
Maybe soon there will be a C generating backend, and we'll just have one distribution format that is a bunch of C, and then gcc support won't even be needed (e.g. IA64_NT).
 
 
Thanks,
 - Jay

----------------------------------------
> From: darko at darko.org
> Date: Thu, 17 Jun 2010 18:08:14 -0700
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Linux/ARM? Android?
>
> I've been interested in an ARM port for some time. If you (or anyone else) are interested in doing the port I can send you one of these, which looks like a good platform since it runs Linux and Android, has 512K memory and looks well supported: http://beagleboard.org/hardware
>
>
>
> On 20/05/2010, at 4:47 AM, 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?
>>
>
> 		 	   		  

From darko at darko.org  Fri Jun 18 06:41:59 2010
From: darko at darko.org (Darko)
Date: Thu, 17 Jun 2010 21:41:59 -0700
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <COL101-W580FCB4C956AC658A851ABE6C00@phx.gbl>
References: <1274350133.8902.0.camel@localhost>,
	<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>,
	<2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>
	<COL101-W580FCB4C956AC658A851ABE6C00@phx.gbl>
Message-ID: <44CCDCF6-BACE-4B58-A1F5-EF68A852E2A5@darko.org>

Ok, the link here is about 20/4Mbs so it shouldn't be too bad and the latency is good. I'm in Mountain View, CA. Unfortunately the board has only 128MB of main memory but I assume that's enough, I think a self hosted compiler has no point.

I'll post the details when it's up and running.


On 17/06/2010, at 9:15 PM, Jay K wrote:


My preference would be if you can set it up on the internet and allow me ssh access.
gcc only recently got support for Android's C library "bionic", I believe post-gcc 4.5.
I'm not sure if that matters much or not.
I'm not sure how much the C library of the target matters to gcc.


Anything with pthreads and gcc support is quite easy to port to these days. In the past the biggest thing you had to do was rewrite /usr/include in Modula-3. There was a tendency to rewrite far more of it than necessary. These days, none of it is needed.


Now you just have to
 - pick a target name 
 - find the jmpbuf size, word size, endian 
 - write a much small "config" file
 - respond to each error that occurs -- fill in the platform in a few tables sprinkled around the tree 


Even systems without pthreads or with not very good pthreads (OpenBSD) are easy now, as the user thread support is much more portable. It used to be, for user threads, you had to poke around in the jmpbuf.


I would encourage anyone else to try it out.


Maybe soon there will be a C generating backend, and we'll just have one distribution format that is a bunch of C, and then gcc support won't even be needed (e.g. IA64_NT).


Thanks,
- Jay

----------------------------------------
> From: darko at darko.org
> Date: Thu, 17 Jun 2010 18:08:14 -0700
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Linux/ARM? Android?
> 
> I've been interested in an ARM port for some time. If you (or anyone else) are interested in doing the port I can send you one of these, which looks like a good platform since it runs Linux and Android, has 512K memory and looks well supported: http://beagleboard.org/hardware
> 
> 
> 
> On 20/05/2010, at 4:47 AM, 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?
>> 
> 
> 		 	   		  



From jay.krell at cornell.edu  Sat Jun 19 07:04:28 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 19 Jun 2010 05:04:28 +0000
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <44CCDCF6-BACE-4B58-A1F5-EF68A852E2A5@darko.org>
References: <1274350133.8902.0.camel@localhost>, ,
	<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>, ,
	<2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>,
	<COL101-W580FCB4C956AC658A851ABE6C00@phx.gbl>,
	<44CCDCF6-BACE-4B58-A1F5-EF68A852E2A5@darko.org>
Message-ID: <COL101-W493D8FFD71EB43948CBE8CE6C10@phx.gbl>


Thanks. I'll give qemu a go as well.
Hey, maybe we can get mips also. (there's decent modern mips/linux hardware now, Chinese laptops)

?- Jay

----------------------------------------
> From: darko at darko.org
> Date: Thu, 17 Jun 2010 21:41:59 -0700
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Linux/ARM? Android?
>
> Ok, the link here is about 20/4Mbs so it shouldn't be too bad and the latency is good. I'm in Mountain View, CA. Unfortunately the board has only 128MB of main memory but I assume that's enough, I think a self hosted compiler has no point.
>
> I'll post the details when it's up and running.
>
>
> On 17/06/2010, at 9:15 PM, Jay K wrote:
>
>
> My preference would be if you can set it up on the internet and allow me ssh access.
> gcc only recently got support for Android's C library "bionic", I believe post-gcc 4.5.
> I'm not sure if that matters much or not.
> I'm not sure how much the C library of the target matters to gcc.
>
>
> Anything with pthreads and gcc support is quite easy to port to these days. In the past the biggest thing you had to do was rewrite /usr/include in Modula-3. There was a tendency to rewrite far more of it than necessary. These days, none of it is needed.
>
>
> Now you just have to
> - pick a target name
> - find the jmpbuf size, word size, endian
> - write a much small "config" file
> - respond to each error that occurs -- fill in the platform in a few tables sprinkled around the tree
>
>
> Even systems without pthreads or with not very good pthreads (OpenBSD) are easy now, as the user thread support is much more portable. It used to be, for user threads, you had to poke around in the jmpbuf.
>
>
> I would encourage anyone else to try it out.
>
>
> Maybe soon there will be a C generating backend, and we'll just have one distribution format that is a bunch of C, and then gcc support won't even be needed (e.g. IA64_NT).
>
>
> Thanks,
> - Jay
>
> ----------------------------------------
>> From: darko at darko.org
>> Date: Thu, 17 Jun 2010 18:08:14 -0700
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Linux/ARM? Android?
>>
>> I've been interested in an ARM port for some time. If you (or anyone else) are interested in doing the port I can send you one of these, which looks like a good platform since it runs Linux and Android, has 512K memory and looks well supported: http://beagleboard.org/hardware
>>
>>
>>
>> On 20/05/2010, at 4:47 AM, 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?
>>>
>>
>>
>
 		 	   		  

From darko at darko.org  Sat Jun 19 07:13:43 2010
From: darko at darko.org (Darko)
Date: Fri, 18 Jun 2010 22:13:43 -0700
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <COL101-W493D8FFD71EB43948CBE8CE6C10@phx.gbl>
References: <1274350133.8902.0.camel@localhost>, ,
	<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>, ,
	<2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>,
	<COL101-W580FCB4C956AC658A851ABE6C00@phx.gbl>,
	<44CCDCF6-BACE-4B58-A1F5-EF68A852E2A5@darko.org>
	<COL101-W493D8FFD71EB43948CBE8CE6C10@phx.gbl>
Message-ID: <B4638299-A29A-454B-9931-4F296F9AD3DB@darko.org>

If you use qemu, this might be useful: http://free-electrons.com/community/demos/qemu-arm-directfb/

I'm currently looking at some cheap laptops (around $100) which have ethernet plus screen, keyboard, battery, etc which would work well as hosts. Just trying to find one that runs both Linux and Android.


On 18/06/2010, at 10:04 PM, Jay K wrote:


Thanks. I'll give qemu a go as well.
Hey, maybe we can get mips also. (there's decent modern mips/linux hardware now, Chinese laptops)

 - Jay

----------------------------------------
> From: darko at darko.org
> Date: Thu, 17 Jun 2010 21:41:59 -0700
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Linux/ARM? Android?
> 
> Ok, the link here is about 20/4Mbs so it shouldn't be too bad and the latency is good. I'm in Mountain View, CA. Unfortunately the board has only 128MB of main memory but I assume that's enough, I think a self hosted compiler has no point.
> 
> I'll post the details when it's up and running.
> 
> 
> On 17/06/2010, at 9:15 PM, Jay K wrote:
> 
> 
> My preference would be if you can set it up on the internet and allow me ssh access.
> gcc only recently got support for Android's C library "bionic", I believe post-gcc 4.5.
> I'm not sure if that matters much or not.
> I'm not sure how much the C library of the target matters to gcc.
> 
> 
> Anything with pthreads and gcc support is quite easy to port to these days. In the past the biggest thing you had to do was rewrite /usr/include in Modula-3. There was a tendency to rewrite far more of it than necessary. These days, none of it is needed.
> 
> 
> Now you just have to
> - pick a target name
> - find the jmpbuf size, word size, endian
> - write a much small "config" file
> - respond to each error that occurs -- fill in the platform in a few tables sprinkled around the tree
> 
> 
> Even systems without pthreads or with not very good pthreads (OpenBSD) are easy now, as the user thread support is much more portable. It used to be, for user threads, you had to poke around in the jmpbuf.
> 
> 
> I would encourage anyone else to try it out.
> 
> 
> Maybe soon there will be a C generating backend, and we'll just have one distribution format that is a bunch of C, and then gcc support won't even be needed (e.g. IA64_NT).
> 
> 
> Thanks,
> - Jay
> 
> ----------------------------------------
>> From: darko at darko.org
>> Date: Thu, 17 Jun 2010 18:08:14 -0700
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Linux/ARM? Android?
>> 
>> I've been interested in an ARM port for some time. If you (or anyone else) are interested in doing the port I can send you one of these, which looks like a good platform since it runs Linux and Android, has 512K memory and looks well supported: http://beagleboard.org/hardware
>> 
>> 
>> 
>> On 20/05/2010, at 4:47 AM, 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?
>>> 
>> 
>> 
> 
		 	   		  



From jay.krell at cornell.edu  Sat Jun 19 07:44:55 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 19 Jun 2010 05:44:55 +0000
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <B4638299-A29A-454B-9931-4F296F9AD3DB@darko.org>
References: <1274350133.8902.0.camel@localhost>,
	,,<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>,
	, , <2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>, ,
	<COL101-W580FCB4C956AC658A851ABE6C00@phx.gbl>, ,
	<44CCDCF6-BACE-4B58-A1F5-EF68A852E2A5@darko.org>,
	<COL101-W493D8FFD71EB43948CBE8CE6C10@phx.gbl>,
	<B4638299-A29A-454B-9931-4F296F9AD3DB@darko.org>
Message-ID: <COL101-W7F2C05F30E9F3525E482DE6C10@phx.gbl>


Interesting, thanks.
But it looks like it needs to use local console for output?
I need something over the network/X.
It looks like there's an qemu option for usemode only too.

?- Jay

----------------------------------------
> From: darko at darko.org
> Date: Fri, 18 Jun 2010 22:13:43 -0700
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Linux/ARM? Android?
>
> If you use qemu, this might be useful: http://free-electrons.com/community/demos/qemu-arm-directfb/
>
> I'm currently looking at some cheap laptops (around $100) which have ethernet plus screen, keyboard, battery, etc which would work well as hosts. Just trying to find one that runs both Linux and Android.
>
>
> On 18/06/2010, at 10:04 PM, Jay K wrote:
>
>
> Thanks. I'll give qemu a go as well.
> Hey, maybe we can get mips also. (there's decent modern mips/linux hardware now, Chinese laptops)
>
> - Jay
>
> ----------------------------------------
>> From: darko at darko.org
>> Date: Thu, 17 Jun 2010 21:41:59 -0700
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Linux/ARM? Android?
>>
>> Ok, the link here is about 20/4Mbs so it shouldn't be too bad and the latency is good. I'm in Mountain View, CA. Unfortunately the board has only 128MB of main memory but I assume that's enough, I think a self hosted compiler has no point.
>>
>> I'll post the details when it's up and running.
>>
>>
>> On 17/06/2010, at 9:15 PM, Jay K wrote:
>>
>>
>> My preference would be if you can set it up on the internet and allow me ssh access.
>> gcc only recently got support for Android's C library "bionic", I believe post-gcc 4.5.
>> I'm not sure if that matters much or not.
>> I'm not sure how much the C library of the target matters to gcc.
>>
>>
>> Anything with pthreads and gcc support is quite easy to port to these days. In the past the biggest thing you had to do was rewrite /usr/include in Modula-3. There was a tendency to rewrite far more of it than necessary. These days, none of it is needed.
>>
>>
>> Now you just have to
>> - pick a target name
>> - find the jmpbuf size, word size, endian
>> - write a much small "config" file
>> - respond to each error that occurs -- fill in the platform in a few tables sprinkled around the tree
>>
>>
>> Even systems without pthreads or with not very good pthreads (OpenBSD) are easy now, as the user thread support is much more portable. It used to be, for user threads, you had to poke around in the jmpbuf.
>>
>>
>> I would encourage anyone else to try it out.
>>
>>
>> Maybe soon there will be a C generating backend, and we'll just have one distribution format that is a bunch of C, and then gcc support won't even be needed (e.g. IA64_NT).
>>
>>
>> Thanks,
>> - Jay
>>
>> ----------------------------------------
>>> From: darko at darko.org
>>> Date: Thu, 17 Jun 2010 18:08:14 -0700
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>
>>> I've been interested in an ARM port for some time. If you (or anyone else) are interested in doing the port I can send you one of these, which looks like a good platform since it runs Linux and Android, has 512K memory and looks well supported: http://beagleboard.org/hardware
>>>
>>>
>>>
>>> On 20/05/2010, at 4:47 AM, 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?
>>>>
>>>
>>>
>>
>
>
 		 	   		  

From darko at darko.org  Sat Jun 19 07:55:24 2010
From: darko at darko.org (Darko)
Date: Fri, 18 Jun 2010 22:55:24 -0700
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <COL101-W7F2C05F30E9F3525E482DE6C10@phx.gbl>
References: <1274350133.8902.0.camel@localhost>, , ,
	<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>, , ,
	<2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>, ,
	<COL101-W580FCB4C956AC658A851ABE6C00@phx.gbl>, ,
	<44CCDCF6-BACE-4B58-A1F5-EF68A852E2A5@darko.org>,
	<COL101-W493D8FFD71EB43948CBE8CE6C10@phx.gbl>,
	<B4638299-A29A-454B-9931-4F296F9AD3DB@darko.org>
	<COL101-W7F2C05F30E9F3525E482DE6C10@phx.gbl>
Message-ID: <ED46DCAD-C84A-488C-BF6F-70CA1F24AF3B@darko.org>

Yeah I've got it working on the console but I agree it needs the network.

Try: http://www.oszoo.org/wiki/index.php/Category:ARM_images
Also: http://www.armedslack.org/ 

What platform are you running on these days?




On 18/06/2010, at 10:44 PM, Jay K wrote:


Interesting, thanks.
But it looks like it needs to use local console for output?
I need something over the network/X.
It looks like there's an qemu option for usemode only too.

 - Jay

----------------------------------------
> From: darko at darko.org
> Date: Fri, 18 Jun 2010 22:13:43 -0700
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Linux/ARM? Android?
> 
> If you use qemu, this might be useful: http://free-electrons.com/community/demos/qemu-arm-directfb/
> 
> I'm currently looking at some cheap laptops (around $100) which have ethernet plus screen, keyboard, battery, etc which would work well as hosts. Just trying to find one that runs both Linux and Android.
> 
> 
> On 18/06/2010, at 10:04 PM, Jay K wrote:
> 
> 
> Thanks. I'll give qemu a go as well.
> Hey, maybe we can get mips also. (there's decent modern mips/linux hardware now, Chinese laptops)
> 
> - Jay
> 
> ----------------------------------------
>> From: darko at darko.org
>> Date: Thu, 17 Jun 2010 21:41:59 -0700
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Linux/ARM? Android?
>> 
>> Ok, the link here is about 20/4Mbs so it shouldn't be too bad and the latency is good. I'm in Mountain View, CA. Unfortunately the board has only 128MB of main memory but I assume that's enough, I think a self hosted compiler has no point.
>> 
>> I'll post the details when it's up and running.
>> 
>> 
>> On 17/06/2010, at 9:15 PM, Jay K wrote:
>> 
>> 
>> My preference would be if you can set it up on the internet and allow me ssh access.
>> gcc only recently got support for Android's C library "bionic", I believe post-gcc 4.5.
>> I'm not sure if that matters much or not.
>> I'm not sure how much the C library of the target matters to gcc.
>> 
>> 
>> Anything with pthreads and gcc support is quite easy to port to these days. In the past the biggest thing you had to do was rewrite /usr/include in Modula-3. There was a tendency to rewrite far more of it than necessary. These days, none of it is needed.
>> 
>> 
>> Now you just have to
>> - pick a target name
>> - find the jmpbuf size, word size, endian
>> - write a much small "config" file
>> - respond to each error that occurs -- fill in the platform in a few tables sprinkled around the tree
>> 
>> 
>> Even systems without pthreads or with not very good pthreads (OpenBSD) are easy now, as the user thread support is much more portable. It used to be, for user threads, you had to poke around in the jmpbuf.
>> 
>> 
>> I would encourage anyone else to try it out.
>> 
>> 
>> Maybe soon there will be a C generating backend, and we'll just have one distribution format that is a bunch of C, and then gcc support won't even be needed (e.g. IA64_NT).
>> 
>> 
>> Thanks,
>> - Jay
>> 
>> ----------------------------------------
>>> From: darko at darko.org
>>> Date: Thu, 17 Jun 2010 18:08:14 -0700
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>> 
>>> I've been interested in an ARM port for some time. If you (or anyone else) are interested in doing the port I can send you one of these, which looks like a good platform since it runs Linux and Android, has 512K memory and looks well supported: http://beagleboard.org/hardware
>>> 
>>> 
>>> 
>>> On 20/05/2010, at 4:47 AM, 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?
>>>> 
>>> 
>>> 
>> 
> 
> 
		 	   		  



From jay.krell at cornell.edu  Sat Jun 19 08:18:50 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 19 Jun 2010 06:18:50 +0000
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <ED46DCAD-C84A-488C-BF6F-70CA1F24AF3B@darko.org>
References: <1274350133.8902.0.camel@localhost>, ,
	,,<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>, ,
	,,<2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>,
	,,<COL101-W580FCB4C956AC658A851ABE6C00@phx.gbl>,
	, , <44CCDCF6-BACE-4B58-A1F5-EF68A852E2A5@darko.org>, ,
	<COL101-W493D8FFD71EB43948CBE8CE6C10@phx.gbl>, ,
	<B4638299-A29A-454B-9931-4F296F9AD3DB@darko.org>,
	<COL101-W7F2C05F30E9F3525E482DE6C10@phx.gbl>,
	<ED46DCAD-C84A-488C-BF6F-70CA1F24AF3B@darko.org>
Message-ID: <COL101-W5474F17968788325FFA76CE6C10@phx.gbl>


XP when I can; nothing else comes close for searching and editing text, I've tried many.
? Visual C++ 5.0.
? I recently learned how to copy/paste in vi, which helps, but I'm not sure I remember now.


Darwin/amd64 when I need/want posix/fastfork, which unfortunately is often.
? Cygwin is slow.
? TextWrangler usually there, though it is awful compared to Visual C++ 5.0.
? KomodoEdit is cross platform but also fairly impaired.
ssh access to a variety
Linux=Debian, it has among the best support for a variety of platforms.
Gentoo comes close or better (ppc64) but I've never been able to get it to install -- booting always fails.
Debian/x86 easy to get cross compiler, qemu, etc.


X Windows apps are never very good imho, so just give up and make do with the even worse command line..
?I find things as basic as scrollbars do not work well -- which button do I press when?
?The Modula-3 GUI apps suffer from this problem as well.
? Further damage due to needing three buttons but not having them.


Mouse button clicking is actually broken on modern Macs too -- they removed the mouse button from all the laptops, leaving
just a big pad, prone to accidental clicks at any location.. also prone to accidental multitouch gestures due to resting
a twitchy thumb where the button is supposed to be. Amazing, really, the mouse, one of their key initial advantages,
is now broken. (see also Finder and file open dialogs, two other former strengths that are now not so great.)
Multitouch scroll is nice though.


?- Jay

----------------------------------------
> From: darko at darko.org
> Date: Fri, 18 Jun 2010 22:55:24 -0700
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Linux/ARM? Android?
>
> Yeah I've got it working on the console but I agree it needs the network.
>
> Try: http://www.oszoo.org/wiki/index.php/Category:ARM_images
> Also: http://www.armedslack.org/
>
> What platform are you running on these days?
>
>
>
>
> On 18/06/2010, at 10:44 PM, Jay K wrote:
>
>
> Interesting, thanks.
> But it looks like it needs to use local console for output?
> I need something over the network/X.
> It looks like there's an qemu option for usemode only too.
>
> - Jay
>
> ----------------------------------------
>> From: darko at darko.org
>> Date: Fri, 18 Jun 2010 22:13:43 -0700
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Linux/ARM? Android?
>>
>> If you use qemu, this might be useful: http://free-electrons.com/community/demos/qemu-arm-directfb/
>>
>> I'm currently looking at some cheap laptops (around $100) which have ethernet plus screen, keyboard, battery, etc which would work well as hosts. Just trying to find one that runs both Linux and Android.
>>
>>
>> On 18/06/2010, at 10:04 PM, Jay K wrote:
>>
>>
>> Thanks. I'll give qemu a go as well.
>> Hey, maybe we can get mips also. (there's decent modern mips/linux hardware now, Chinese laptops)
>>
>> - Jay
>>
>> ----------------------------------------
>>> From: darko at darko.org
>>> Date: Thu, 17 Jun 2010 21:41:59 -0700
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>
>>> Ok, the link here is about 20/4Mbs so it shouldn't be too bad and the latency is good. I'm in Mountain View, CA. Unfortunately the board has only 128MB of main memory but I assume that's enough, I think a self hosted compiler has no point.
>>>
>>> I'll post the details when it's up and running.
>>>
>>>
>>> On 17/06/2010, at 9:15 PM, Jay K wrote:
>>>
>>>
>>> My preference would be if you can set it up on the internet and allow me ssh access.
>>> gcc only recently got support for Android's C library "bionic", I believe post-gcc 4.5.
>>> I'm not sure if that matters much or not.
>>> I'm not sure how much the C library of the target matters to gcc.
>>>
>>>
>>> Anything with pthreads and gcc support is quite easy to port to these days. In the past the biggest thing you had to do was rewrite /usr/include in Modula-3. There was a tendency to rewrite far more of it than necessary. These days, none of it is needed.
>>>
>>>
>>> Now you just have to
>>> - pick a target name
>>> - find the jmpbuf size, word size, endian
>>> - write a much small "config" file
>>> - respond to each error that occurs -- fill in the platform in a few tables sprinkled around the tree
>>>
>>>
>>> Even systems without pthreads or with not very good pthreads (OpenBSD) are easy now, as the user thread support is much more portable. It used to be, for user threads, you had to poke around in the jmpbuf.
>>>
>>>
>>> I would encourage anyone else to try it out.
>>>
>>>
>>> Maybe soon there will be a C generating backend, and we'll just have one distribution format that is a bunch of C, and then gcc support won't even be needed (e.g. IA64_NT).
>>>
>>>
>>> Thanks,
>>> - Jay
>>>
>>> ----------------------------------------
>>>> From: darko at darko.org
>>>> Date: Thu, 17 Jun 2010 18:08:14 -0700
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>
>>>> I've been interested in an ARM port for some time. If you (or anyone else) are interested in doing the port I can send you one of these, which looks like a good platform since it runs Linux and Android, has 512K memory and looks well supported: http://beagleboard.org/hardware
>>>>
>>>>
>>>>
>>>> On 20/05/2010, at 4:47 AM, 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?
>>>>>
>>>>
>>>>
>>>
>>
>>
>
>
 		 	   		  

From darko at darko.org  Sat Jun 19 09:13:53 2010
From: darko at darko.org (Darko)
Date: Sat, 19 Jun 2010 00:13:53 -0700
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <COL101-W5474F17968788325FFA76CE6C10@phx.gbl>
References: <1274350133.8902.0.camel@localhost>, , , ,
	<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>, , , ,
	<2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>, , ,
	<COL101-W580FCB4C956AC658A851ABE6C00@phx.gbl>, , ,
	<44CCDCF6-BACE-4B58-A1F5-EF68A852E2A5@darko.org>, ,
	<COL101-W493D8FFD71EB43948CBE8CE6C10@phx.gbl>, ,
	<B4638299-A29A-454B-9931-4F296F9AD3DB@darko.org>,
	<COL101-W7F2C05F30E9F3525E482DE6C10@phx.gbl>,
	<ED46DCAD-C84A-488C-BF6F-70CA1F24AF3B@darko.org>
	<COL101-W5474F17968788325FFA76CE6C10@phx.gbl>
Message-ID: <5E055C3D-78F6-4C08-86D9-8B8CA86B11A1@darko.org>

I got the first Debian image on http://www.oszoo.org/wiki/index.php/Category:ARM_images to run with a GUI, and it connect to the network. I'm using Q on my 2.4Ghz MacBook 13" and it's surprisingly fast. Note that it's a 10GB image (450MB download).

There are also images for Debian MIPS on that site too.

I agree that the new MacBook trackpad is not perfect and since moving from my previous machine that had a separate button I now get a lot of stray gestures doing odd things. The general solution is not to use the button at all and use taps. The new momentum scrolling with the gesture is neat but needs more "weight". Unfortunately Apple crosses over into form-over-function territory from time to time and this is one of those times.


On 18/06/2010, at 11:18 PM, Jay K wrote:


XP when I can; nothing else comes close for searching and editing text, I've tried many.
  Visual C++ 5.0.
  I recently learned how to copy/paste in vi, which helps, but I'm not sure I remember now.


Darwin/amd64 when I need/want posix/fastfork, which unfortunately is often.
  Cygwin is slow.
  TextWrangler usually there, though it is awful compared to Visual C++ 5.0.
  KomodoEdit is cross platform but also fairly impaired.
ssh access to a variety
Linux=Debian, it has among the best support for a variety of platforms.
Gentoo comes close or better (ppc64) but I've never been able to get it to install -- booting always fails.
Debian/x86 easy to get cross compiler, qemu, etc.


X Windows apps are never very good imho, so just give up and make do with the even worse command line..
 I find things as basic as scrollbars do not work well -- which button do I press when?
 The Modula-3 GUI apps suffer from this problem as well.
  Further damage due to needing three buttons but not having them.


Mouse button clicking is actually broken on modern Macs too -- they removed the mouse button from all the laptops, leaving
just a big pad, prone to accidental clicks at any location.. also prone to accidental multitouch gestures due to resting
a twitchy thumb where the button is supposed to be. Amazing, really, the mouse, one of their key initial advantages,
is now broken. (see also Finder and file open dialogs, two other former strengths that are now not so great.)
Multitouch scroll is nice though.


 - Jay

----------------------------------------
> From: darko at darko.org
> Date: Fri, 18 Jun 2010 22:55:24 -0700
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Linux/ARM? Android?
> 
> Yeah I've got it working on the console but I agree it needs the network.
> 
> Try: http://www.oszoo.org/wiki/index.php/Category:ARM_images
> Also: http://www.armedslack.org/
> 
> What platform are you running on these days?
> 
> 
> 
> 
> On 18/06/2010, at 10:44 PM, Jay K wrote:
> 
> 
> Interesting, thanks.
> But it looks like it needs to use local console for output?
> I need something over the network/X.
> It looks like there's an qemu option for usemode only too.
> 
> - Jay
> 
> ----------------------------------------
>> From: darko at darko.org
>> Date: Fri, 18 Jun 2010 22:13:43 -0700
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Linux/ARM? Android?
>> 
>> If you use qemu, this might be useful: http://free-electrons.com/community/demos/qemu-arm-directfb/
>> 
>> I'm currently looking at some cheap laptops (around $100) which have ethernet plus screen, keyboard, battery, etc which would work well as hosts. Just trying to find one that runs both Linux and Android.
>> 
>> 
>> On 18/06/2010, at 10:04 PM, Jay K wrote:
>> 
>> 
>> Thanks. I'll give qemu a go as well.
>> Hey, maybe we can get mips also. (there's decent modern mips/linux hardware now, Chinese laptops)
>> 
>> - Jay
>> 
>> ----------------------------------------
>>> From: darko at darko.org
>>> Date: Thu, 17 Jun 2010 21:41:59 -0700
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>> 
>>> Ok, the link here is about 20/4Mbs so it shouldn't be too bad and the latency is good. I'm in Mountain View, CA. Unfortunately the board has only 128MB of main memory but I assume that's enough, I think a self hosted compiler has no point.
>>> 
>>> I'll post the details when it's up and running.
>>> 
>>> 
>>> On 17/06/2010, at 9:15 PM, Jay K wrote:
>>> 
>>> 
>>> My preference would be if you can set it up on the internet and allow me ssh access.
>>> gcc only recently got support for Android's C library "bionic", I believe post-gcc 4.5.
>>> I'm not sure if that matters much or not.
>>> I'm not sure how much the C library of the target matters to gcc.
>>> 
>>> 
>>> Anything with pthreads and gcc support is quite easy to port to these days. In the past the biggest thing you had to do was rewrite /usr/include in Modula-3. There was a tendency to rewrite far more of it than necessary. These days, none of it is needed.
>>> 
>>> 
>>> Now you just have to
>>> - pick a target name
>>> - find the jmpbuf size, word size, endian
>>> - write a much small "config" file
>>> - respond to each error that occurs -- fill in the platform in a few tables sprinkled around the tree
>>> 
>>> 
>>> Even systems without pthreads or with not very good pthreads (OpenBSD) are easy now, as the user thread support is much more portable. It used to be, for user threads, you had to poke around in the jmpbuf.
>>> 
>>> 
>>> I would encourage anyone else to try it out.
>>> 
>>> 
>>> Maybe soon there will be a C generating backend, and we'll just have one distribution format that is a bunch of C, and then gcc support won't even be needed (e.g. IA64_NT).
>>> 
>>> 
>>> Thanks,
>>> - Jay
>>> 
>>> ----------------------------------------
>>>> From: darko at darko.org
>>>> Date: Thu, 17 Jun 2010 18:08:14 -0700
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>> 
>>>> I've been interested in an ARM port for some time. If you (or anyone else) are interested in doing the port I can send you one of these, which looks like a good platform since it runs Linux and Android, has 512K memory and looks well supported: http://beagleboard.org/hardware
>>>> 
>>>> 
>>>> 
>>>> On 20/05/2010, at 4:47 AM, 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?
>>>>> 
>>>> 
>>>> 
>>> 
>> 
>> 
> 
> 
		 	   		  



From jay.krell at cornell.edu  Sat Jun 19 10:44:04 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 19 Jun 2010 08:44:04 +0000
Subject: [M3devel] div/mod helpers for pair of negative numbers?
Message-ID: <COL101-W60CEC449B32E4D2297E8F0E6C10@phx.gbl>


Tony, I'm not going to change the release branch, but this is seemingly relevant to ARM on head:


? if ((b == 'P' && a == 'P') || IS_WORD_TYPE(T)) {
??? EXPR_REF (-2) = m3_build2 (FLOOR_MOD_EXPR, t,
??? ??? ??? ?????? m3_cast (t, EXPR_REF (-2)),
??? ??? ??? ?????? m3_cast (t, EXPR_REF (-1)));
??? EXPR_POP ();


is better off as:

? if ((b == a) || IS_WORD_TYPE(T)) {
??? EXPR_REF (-2) = m3_build2 (FLOOR_MOD_EXPR, t,
??? ??? ??? ?????? m3_cast (t, EXPR_REF (-2)),
??? ??? ??? ?????? m3_cast (t, EXPR_REF (-1)));
??? EXPR_POP ();

right?

That, consider..well..the historical modL function is close to that:


int64 __cdecl m3_modL
??? ANSI((????? int64 b, int64 a))
????? KR((b, a) int64 b; int64 a;)
{
? register int64 c;
? if ((a == 0) && (b != 0)) {? c = 0;
? } else if (a> 0)? {? c = (b>= 0) ? a % b : b + 1 + (a-1) % (-b);
? } else /* a < 0 */ {? c = (b>= 0) ? b - 1 - (-1-a) % (b) : - ((-a) % (-b));
? }
? return c;
}


for a < 0 and b < 0, it returns - ((-a) % (-b));.
which isn't exactly a % b as far as I know.

But if you consider my rewritten mod64 function, which I believe I tested thoroughly:

int64
__stdcall
m3_mod64(int64 b, int64 a)
{
? typedef? int64 ST; /* signed type */
? typedef uint64 UT; /* unsigned type */
? int aneg = (a < 0);
? int bneg = (b < 0);
? if (aneg == bneg || a == 0 || b == 0)
??? return (a % b);
? else
? {
??? UT ua = (aneg ? M3_POS(UT, a) : (UT)a);
??? UT ub = (bneg ? M3_POS(UT, b) : (UT)b);
??? a = (ST)(ub - 1 - (ua + ub - 1) % ub);
??? return (bneg ? -a : a);
? }
}



It seems 64bit floor mod doesn't work on ARM, so I'm putting back calling functions, sometimes -- only for 64bit mod on ARM.
div also if I found it is needed.
All other targets will keep using gcc's builtin support, whatever that is.


I guess I'll just have to go back and make sure there is test coverage here and compare release with head.


?- Jay

 		 	   		  

From darko at darko.org  Sat Jun 19 11:15:17 2010
From: darko at darko.org (Darko)
Date: Sat, 19 Jun 2010 02:15:17 -0700
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <5E055C3D-78F6-4C08-86D9-8B8CA86B11A1@darko.org>
References: <1274350133.8902.0.camel@localhost>, , , ,
	<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>, , , ,
	<2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>, , ,
	<COL101-W580FCB4C956AC658A851ABE6C00@phx.gbl>, , ,
	<44CCDCF6-BACE-4B58-A1F5-EF68A852E2A5@darko.org>, ,
	<COL101-W493D8FFD71EB43948CBE8CE6C10@phx.gbl>, ,
	<B4638299-A29A-454B-9931-4F296F9AD3DB@darko.org>,
	<COL101-W7F2C05F30E9F3525E482DE6C10@phx.gbl>,
	<ED46DCAD-C84A-488C-BF6F-70CA1F24AF3B@darko.org>
	<COL101-W5474F17968788325FFA76CE6C10@phx.gbl>
	<5E055C3D-78F6-4C08-86D9-8B8CA86B11A1@darko.org>
Message-ID: <C76EF524-6048-4C61-9744-6797BBA6C552@darko.org>

I should also mention that the Android SDK has a QEMU based emulator for testing applications and the adb (Android Bridge) tool can provide shell access.


On 19/06/2010, at 12:13 AM, Darko wrote:

I got the first Debian image on http://www.oszoo.org/wiki/index.php/Category:ARM_images to run with a GUI, and it connect to the network. I'm using Q on my 2.4Ghz MacBook 13" and it's surprisingly fast. Note that it's a 10GB image (450MB download).

There are also images for Debian MIPS on that site too.

I agree that the new MacBook trackpad is not perfect and since moving from my previous machine that had a separate button I now get a lot of stray gestures doing odd things. The general solution is not to use the button at all and use taps. The new momentum scrolling with the gesture is neat but needs more "weight". Unfortunately Apple crosses over into form-over-function territory from time to time and this is one of those times.


On 18/06/2010, at 11:18 PM, Jay K wrote:


XP when I can; nothing else comes close for searching and editing text, I've tried many.
 Visual C++ 5.0.
 I recently learned how to copy/paste in vi, which helps, but I'm not sure I remember now.


Darwin/amd64 when I need/want posix/fastfork, which unfortunately is often.
 Cygwin is slow.
 TextWrangler usually there, though it is awful compared to Visual C++ 5.0.
 KomodoEdit is cross platform but also fairly impaired.
ssh access to a variety
Linux=Debian, it has among the best support for a variety of platforms.
Gentoo comes close or better (ppc64) but I've never been able to get it to install -- booting always fails.
Debian/x86 easy to get cross compiler, qemu, etc.


X Windows apps are never very good imho, so just give up and make do with the even worse command line..
I find things as basic as scrollbars do not work well -- which button do I press when?
The Modula-3 GUI apps suffer from this problem as well.
 Further damage due to needing three buttons but not having them.


Mouse button clicking is actually broken on modern Macs too -- they removed the mouse button from all the laptops, leaving
just a big pad, prone to accidental clicks at any location.. also prone to accidental multitouch gestures due to resting
a twitchy thumb where the button is supposed to be. Amazing, really, the mouse, one of their key initial advantages,
is now broken. (see also Finder and file open dialogs, two other former strengths that are now not so great.)
Multitouch scroll is nice though.


- Jay

----------------------------------------
> From: darko at darko.org
> Date: Fri, 18 Jun 2010 22:55:24 -0700
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Linux/ARM? Android?
> 
> Yeah I've got it working on the console but I agree it needs the network.
> 
> Try: http://www.oszoo.org/wiki/index.php/Category:ARM_images
> Also: http://www.armedslack.org/
> 
> What platform are you running on these days?
> 
> 
> 
> 
> On 18/06/2010, at 10:44 PM, Jay K wrote:
> 
> 
> Interesting, thanks.
> But it looks like it needs to use local console for output?
> I need something over the network/X.
> It looks like there's an qemu option for usemode only too.
> 
> - Jay
> 
> ----------------------------------------
>> From: darko at darko.org
>> Date: Fri, 18 Jun 2010 22:13:43 -0700
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Linux/ARM? Android?
>> 
>> If you use qemu, this might be useful: http://free-electrons.com/community/demos/qemu-arm-directfb/
>> 
>> I'm currently looking at some cheap laptops (around $100) which have ethernet plus screen, keyboard, battery, etc which would work well as hosts. Just trying to find one that runs both Linux and Android.
>> 
>> 
>> On 18/06/2010, at 10:04 PM, Jay K wrote:
>> 
>> 
>> Thanks. I'll give qemu a go as well.
>> Hey, maybe we can get mips also. (there's decent modern mips/linux hardware now, Chinese laptops)
>> 
>> - Jay
>> 
>> ----------------------------------------
>>> From: darko at darko.org
>>> Date: Thu, 17 Jun 2010 21:41:59 -0700
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>> 
>>> Ok, the link here is about 20/4Mbs so it shouldn't be too bad and the latency is good. I'm in Mountain View, CA. Unfortunately the board has only 128MB of main memory but I assume that's enough, I think a self hosted compiler has no point.
>>> 
>>> I'll post the details when it's up and running.
>>> 
>>> 
>>> On 17/06/2010, at 9:15 PM, Jay K wrote:
>>> 
>>> 
>>> My preference would be if you can set it up on the internet and allow me ssh access.
>>> gcc only recently got support for Android's C library "bionic", I believe post-gcc 4.5.
>>> I'm not sure if that matters much or not.
>>> I'm not sure how much the C library of the target matters to gcc.
>>> 
>>> 
>>> Anything with pthreads and gcc support is quite easy to port to these days. In the past the biggest thing you had to do was rewrite /usr/include in Modula-3. There was a tendency to rewrite far more of it than necessary. These days, none of it is needed.
>>> 
>>> 
>>> Now you just have to
>>> - pick a target name
>>> - find the jmpbuf size, word size, endian
>>> - write a much small "config" file
>>> - respond to each error that occurs -- fill in the platform in a few tables sprinkled around the tree
>>> 
>>> 
>>> Even systems without pthreads or with not very good pthreads (OpenBSD) are easy now, as the user thread support is much more portable. It used to be, for user threads, you had to poke around in the jmpbuf.
>>> 
>>> 
>>> I would encourage anyone else to try it out.
>>> 
>>> 
>>> Maybe soon there will be a C generating backend, and we'll just have one distribution format that is a bunch of C, and then gcc support won't even be needed (e.g. IA64_NT).
>>> 
>>> 
>>> Thanks,
>>> - Jay
>>> 
>>> ----------------------------------------
>>>> From: darko at darko.org
>>>> Date: Thu, 17 Jun 2010 18:08:14 -0700
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>> 
>>>> I've been interested in an ARM port for some time. If you (or anyone else) are interested in doing the port I can send you one of these, which looks like a good platform since it runs Linux and Android, has 512K memory and looks well supported: http://beagleboard.org/hardware
>>>> 
>>>> 
>>>> 
>>>> On 20/05/2010, at 4:47 AM, 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?
>>>>> 
>>>> 
>>>> 
>>> 
>> 
>> 
> 
> 
		 	   		  




From jay.krell at cornell.edu  Sat Jun 19 11:51:50 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 19 Jun 2010 09:51:50 +0000
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <C76EF524-6048-4C61-9744-6797BBA6C552@darko.org>
References: <1274350133.8902.0.camel@localhost>, , ,
	,,<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>, , ,
	,,<2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>, ,
	,,<COL101-W580FCB4C956AC658A851ABE6C00@phx.gbl>, ,
	,,<44CCDCF6-BACE-4B58-A1F5-EF68A852E2A5@darko.org>,
	,,<COL101-W493D8FFD71EB43948CBE8CE6C10@phx.gbl>,
	, , <B4638299-A29A-454B-9931-4F296F9AD3DB@darko.org>, ,
	<COL101-W7F2C05F30E9F3525E482DE6C10@phx.gbl>, ,
	<ED46DCAD-C84A-488C-BF6F-70CA1F24AF3B@darko.org>,
	<COL101-W5474F17968788325FFA76CE6C10@phx.gbl>,
	<5E055C3D-78F6-4C08-86D9-8B8CA86B11A1@darko.org>,
	<C76EF524-6048-4C61-9744-6797BBA6C552@darko.org>
Message-ID: <COL101-W31787A72294920C0484E63E6C10@phx.gbl>


Eh I guess I should try that then. Ok. Thanks. Gotta take a break for a while.
?cd wherever 
?cvs -z3 upd -dAP? 
?cd scripts/python? 
?./boot1.py ARMEL_LINUX? 
? => cm3-boot-ARMEL_LINUX...tgz 
? extract that on a machine with cross tools (e.g. arm-linux-gnueabi-gcc, arm-linux-gnueabi-as), possibly the same machine as already on 
? cd into it? 
? make? 
? => arm cm3 


I got that far.
I can't claim it is right for Android.


Then put that cm3 onto a real (or emulated) ARM system and...
(cvs checkout, put the cm3 in /cm3/bin or such, add that to $PATH, and scripts/python/boot2.sh)


Moving forward to gcc 4.5 will get us atomics for ARM, sort of, at least on Linux, see:
?http://gcc.gnu.org/wiki/Atomic 


?- Jay

----------------------------------------
> From: darko at darko.org
> Date: Sat, 19 Jun 2010 02:15:17 -0700
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Linux/ARM? Android?
>
> I should also mention that the Android SDK has a QEMU based emulator for testing applications and the adb (Android Bridge) tool can provide shell access.
>
>
> On 19/06/2010, at 12:13 AM, Darko wrote:
>
> I got the first Debian image on http://www.oszoo.org/wiki/index.php/Category:ARM_images to run with a GUI, and it connect to the network. I'm using Q on my 2.4Ghz MacBook 13" and it's surprisingly fast. Note that it's a 10GB image (450MB download).
>
> There are also images for Debian MIPS on that site too.
>
> I agree that the new MacBook trackpad is not perfect and since moving from my previous machine that had a separate button I now get a lot of stray gestures doing odd things. The general solution is not to use the button at all and use taps. The new momentum scrolling with the gesture is neat but needs more "weight". Unfortunately Apple crosses over into form-over-function territory from time to time and this is one of those times.
>
>
> On 18/06/2010, at 11:18 PM, Jay K wrote:
>
>
> XP when I can; nothing else comes close for searching and editing text, I've tried many.
> Visual C++ 5.0.
> I recently learned how to copy/paste in vi, which helps, but I'm not sure I remember now.
>
>
> Darwin/amd64 when I need/want posix/fastfork, which unfortunately is often.
> Cygwin is slow.
> TextWrangler usually there, though it is awful compared to Visual C++ 5.0.
> KomodoEdit is cross platform but also fairly impaired.
> ssh access to a variety
> Linux=Debian, it has among the best support for a variety of platforms.
> Gentoo comes close or better (ppc64) but I've never been able to get it to install -- booting always fails.
> Debian/x86 easy to get cross compiler, qemu, etc.
>
>
> X Windows apps are never very good imho, so just give up and make do with the even worse command line..
> I find things as basic as scrollbars do not work well -- which button do I press when?
> The Modula-3 GUI apps suffer from this problem as well.
> Further damage due to needing three buttons but not having them.
>
>
> Mouse button clicking is actually broken on modern Macs too -- they removed the mouse button from all the laptops, leaving
> just a big pad, prone to accidental clicks at any location.. also prone to accidental multitouch gestures due to resting
> a twitchy thumb where the button is supposed to be. Amazing, really, the mouse, one of their key initial advantages,
> is now broken. (see also Finder and file open dialogs, two other former strengths that are now not so great.)
> Multitouch scroll is nice though.
>
>
> - Jay
>
> ----------------------------------------
>> From: darko at darko.org
>> Date: Fri, 18 Jun 2010 22:55:24 -0700
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Linux/ARM? Android?
>>
>> Yeah I've got it working on the console but I agree it needs the network.
>>
>> Try: http://www.oszoo.org/wiki/index.php/Category:ARM_images
>> Also: http://www.armedslack.org/
>>
>> What platform are you running on these days?
>>
>>
>>
>>
>> On 18/06/2010, at 10:44 PM, Jay K wrote:
>>
>>
>> Interesting, thanks.
>> But it looks like it needs to use local console for output?
>> I need something over the network/X.
>> It looks like there's an qemu option for usemode only too.
>>
>> - Jay
>>
>> ----------------------------------------
>>> From: darko at darko.org
>>> Date: Fri, 18 Jun 2010 22:13:43 -0700
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>
>>> If you use qemu, this might be useful: http://free-electrons.com/community/demos/qemu-arm-directfb/
>>>
>>> I'm currently looking at some cheap laptops (around $100) which have ethernet plus screen, keyboard, battery, etc which would work well as hosts. Just trying to find one that runs both Linux and Android.
>>>
>>>
>>> On 18/06/2010, at 10:04 PM, Jay K wrote:
>>>
>>>
>>> Thanks. I'll give qemu a go as well.
>>> Hey, maybe we can get mips also. (there's decent modern mips/linux hardware now, Chinese laptops)
>>>
>>> - Jay
>>>
>>> ----------------------------------------
>>>> From: darko at darko.org
>>>> Date: Thu, 17 Jun 2010 21:41:59 -0700
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>
>>>> Ok, the link here is about 20/4Mbs so it shouldn't be too bad and the latency is good. I'm in Mountain View, CA. Unfortunately the board has only 128MB of main memory but I assume that's enough, I think a self hosted compiler has no point.
>>>>
>>>> I'll post the details when it's up and running.
>>>>
>>>>
>>>> On 17/06/2010, at 9:15 PM, Jay K wrote:
>>>>
>>>>
>>>> My preference would be if you can set it up on the internet and allow me ssh access.
>>>> gcc only recently got support for Android's C library "bionic", I believe post-gcc 4.5.
>>>> I'm not sure if that matters much or not.
>>>> I'm not sure how much the C library of the target matters to gcc.
>>>>
>>>>
>>>> Anything with pthreads and gcc support is quite easy to port to these days. In the past the biggest thing you had to do was rewrite /usr/include in Modula-3. There was a tendency to rewrite far more of it than necessary. These days, none of it is needed.
>>>>
>>>>
>>>> Now you just have to
>>>> - pick a target name
>>>> - find the jmpbuf size, word size, endian
>>>> - write a much small "config" file
>>>> - respond to each error that occurs -- fill in the platform in a few tables sprinkled around the tree
>>>>
>>>>
>>>> Even systems without pthreads or with not very good pthreads (OpenBSD) are easy now, as the user thread support is much more portable. It used to be, for user threads, you had to poke around in the jmpbuf.
>>>>
>>>>
>>>> I would encourage anyone else to try it out.
>>>>
>>>>
>>>> Maybe soon there will be a C generating backend, and we'll just have one distribution format that is a bunch of C, and then gcc support won't even be needed (e.g. IA64_NT).
>>>>
>>>>
>>>> Thanks,
>>>> - Jay
>>>>
>>>> ----------------------------------------
>>>>> From: darko at darko.org
>>>>> Date: Thu, 17 Jun 2010 18:08:14 -0700
>>>>> To: jay.krell at cornell.edu
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>>
>>>>> I've been interested in an ARM port for some time. If you (or anyone else) are interested in doing the port I can send you one of these, which looks like a good platform since it runs Linux and Android, has 512K memory and looks well supported: http://beagleboard.org/hardware
>>>>>
>>>>>
>>>>>
>>>>> On 20/05/2010, at 4:47 AM, 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?
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>
>
>
 		 	   		  

From jay.krell at cornell.edu  Sat Jun 19 12:29:23 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 19 Jun 2010 10:29:23 +0000
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <C76EF524-6048-4C61-9744-6797BBA6C552@darko.org>
References: <1274350133.8902.0.camel@localhost>, ,
	,,,,<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>, ,
	,,,,<2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>,
	,,,,<COL101-W580FCB4C956AC658A851ABE6C00@phx.gbl>,
	, , , , <44CCDCF6-BACE-4B58-A1F5-EF68A852E2A5@darko.org>, , , ,
	<COL101-W493D8FFD71EB43948CBE8CE6C10@phx.gbl>, , , ,
	<B4638299-A29A-454B-9931-4F296F9AD3DB@darko.org>, ,
	<COL101-W7F2C05F30E9F3525E482DE6C10@phx.gbl>, ,
	<ED46DCAD-C84A-488C-BF6F-70CA1F24AF3B@darko.org>,
	<COL101-W5474F17968788325FFA76CE6C10@phx.gbl>,
	<5E055C3D-78F6-4C08-86D9-8B8CA86B11A1@darko.org>,
	<C76EF524-6048-4C61-9744-6797BBA6C552@darko.org>
Message-ID: <COL101-W18EA6CF8E4C3963769265EE6C10@phx.gbl>


Interesting to notice that they have their own pthread library..related to how I suggested we implement Modula-3 threads on top of Linux kernel interfaces instead of pthreads..

?- Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: darko at darko.org
> CC: m3devel at elegosoft.com
> Subject: RE: [M3devel] Linux/ARM? Android?
> Date: Sat, 19 Jun 2010 09:51:50 +0000
>
>
> Eh I guess I should try that then. Ok. Thanks. Gotta take a break for a while.
>  cd wherever
>  cvs -z3 upd -dAP
>  cd scripts/python
>  ./boot1.py ARMEL_LINUX
>   => cm3-boot-ARMEL_LINUX...tgz
>   extract that on a machine with cross tools (e.g. arm-linux-gnueabi-gcc, arm-linux-gnueabi-as), possibly the same machine as already on
>   cd into it
>   make
>   => arm cm3
>
>
> I got that far.
> I can't claim it is right for Android.
>
>
> Then put that cm3 onto a real (or emulated) ARM system and...
> (cvs checkout, put the cm3 in /cm3/bin or such, add that to $PATH, and scripts/python/boot2.sh)
>
>
> Moving forward to gcc 4.5 will get us atomics for ARM, sort of, at least on Linux, see:
>  http://gcc.gnu.org/wiki/Atomic
>
>
>  - Jay
>
> ----------------------------------------
>> From: darko at darko.org
>> Date: Sat, 19 Jun 2010 02:15:17 -0700
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Linux/ARM? Android?
>>
>> I should also mention that the Android SDK has a QEMU based emulator for testing applications and the adb (Android Bridge) tool can provide shell access.
>>
>>
>> On 19/06/2010, at 12:13 AM, Darko wrote:
>>
>> I got the first Debian image on http://www.oszoo.org/wiki/index.php/Category:ARM_images to run with a GUI, and it connect to the network. I'm using Q on my 2.4Ghz MacBook 13" and it's surprisingly fast. Note that it's a 10GB image (450MB download).
>>
>> There are also images for Debian MIPS on that site too.
>>
>> I agree that the new MacBook trackpad is not perfect and since moving from my previous machine that had a separate button I now get a lot of stray gestures doing odd things. The general solution is not to use the button at all and use taps. The new momentum scrolling with the gesture is neat but needs more "weight". Unfortunately Apple crosses over into form-over-function territory from time to time and this is one of those times.
>>
>>
>> On 18/06/2010, at 11:18 PM, Jay K wrote:
>>
>>
>> XP when I can; nothing else comes close for searching and editing text, I've tried many.
>> Visual C++ 5.0.
>> I recently learned how to copy/paste in vi, which helps, but I'm not sure I remember now.
>>
>>
>> Darwin/amd64 when I need/want posix/fastfork, which unfortunately is often.
>> Cygwin is slow.
>> TextWrangler usually there, though it is awful compared to Visual C++ 5.0.
>> KomodoEdit is cross platform but also fairly impaired.
>> ssh access to a variety
>> Linux=Debian, it has among the best support for a variety of platforms.
>> Gentoo comes close or better (ppc64) but I've never been able to get it to install -- booting always fails.
>> Debian/x86 easy to get cross compiler, qemu, etc.
>>
>>
>> X Windows apps are never very good imho, so just give up and make do with the even worse command line..
>> I find things as basic as scrollbars do not work well -- which button do I press when?
>> The Modula-3 GUI apps suffer from this problem as well.
>> Further damage due to needing three buttons but not having them.
>>
>>
>> Mouse button clicking is actually broken on modern Macs too -- they removed the mouse button from all the laptops, leaving
>> just a big pad, prone to accidental clicks at any location.. also prone to accidental multitouch gestures due to resting
>> a twitchy thumb where the button is supposed to be. Amazing, really, the mouse, one of their key initial advantages,
>> is now broken. (see also Finder and file open dialogs, two other former strengths that are now not so great.)
>> Multitouch scroll is nice though.
>>
>>
>> - Jay
>>
>> ----------------------------------------
>>> From: darko at darko.org
>>> Date: Fri, 18 Jun 2010 22:55:24 -0700
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>
>>> Yeah I've got it working on the console but I agree it needs the network.
>>>
>>> Try: http://www.oszoo.org/wiki/index.php/Category:ARM_images
>>> Also: http://www.armedslack.org/
>>>
>>> What platform are you running on these days?
>>>
>>>
>>>
>>>
>>> On 18/06/2010, at 10:44 PM, Jay K wrote:
>>>
>>>
>>> Interesting, thanks.
>>> But it looks like it needs to use local console for output?
>>> I need something over the network/X.
>>> It looks like there's an qemu option for usemode only too.
>>>
>>> - Jay
>>>
>>> ----------------------------------------
>>>> From: darko at darko.org
>>>> Date: Fri, 18 Jun 2010 22:13:43 -0700
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>
>>>> If you use qemu, this might be useful: http://free-electrons.com/community/demos/qemu-arm-directfb/
>>>>
>>>> I'm currently looking at some cheap laptops (around $100) which have ethernet plus screen, keyboard, battery, etc which would work well as hosts. Just trying to find one that runs both Linux and Android.
>>>>
>>>>
>>>> On 18/06/2010, at 10:04 PM, Jay K wrote:
>>>>
>>>>
>>>> Thanks. I'll give qemu a go as well.
>>>> Hey, maybe we can get mips also. (there's decent modern mips/linux hardware now, Chinese laptops)
>>>>
>>>> - Jay
>>>>
>>>> ----------------------------------------
>>>>> From: darko at darko.org
>>>>> Date: Thu, 17 Jun 2010 21:41:59 -0700
>>>>> To: jay.krell at cornell.edu
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>>
>>>>> Ok, the link here is about 20/4Mbs so it shouldn't be too bad and the latency is good. I'm in Mountain View, CA. Unfortunately the board has only 128MB of main memory but I assume that's enough, I think a self hosted compiler has no point.
>>>>>
>>>>> I'll post the details when it's up and running.
>>>>>
>>>>>
>>>>> On 17/06/2010, at 9:15 PM, Jay K wrote:
>>>>>
>>>>>
>>>>> My preference would be if you can set it up on the internet and allow me ssh access.
>>>>> gcc only recently got support for Android's C library "bionic", I believe post-gcc 4.5.
>>>>> I'm not sure if that matters much or not.
>>>>> I'm not sure how much the C library of the target matters to gcc.
>>>>>
>>>>>
>>>>> Anything with pthreads and gcc support is quite easy to port to these days. In the past the biggest thing you had to do was rewrite /usr/include in Modula-3. There was a tendency to rewrite far more of it than necessary. These days, none of it is needed.
>>>>>
>>>>>
>>>>> Now you just have to
>>>>> - pick a target name
>>>>> - find the jmpbuf size, word size, endian
>>>>> - write a much small "config" file
>>>>> - respond to each error that occurs -- fill in the platform in a few tables sprinkled around the tree
>>>>>
>>>>>
>>>>> Even systems without pthreads or with not very good pthreads (OpenBSD) are easy now, as the user thread support is much more portable. It used to be, for user threads, you had to poke around in the jmpbuf.
>>>>>
>>>>>
>>>>> I would encourage anyone else to try it out.
>>>>>
>>>>>
>>>>> Maybe soon there will be a C generating backend, and we'll just have one distribution format that is a bunch of C, and then gcc support won't even be needed (e.g. IA64_NT).
>>>>>
>>>>>
>>>>> Thanks,
>>>>> - Jay
>>>>>
>>>>> ----------------------------------------
>>>>>> From: darko at darko.org
>>>>>> Date: Thu, 17 Jun 2010 18:08:14 -0700
>>>>>> To: jay.krell at cornell.edu
>>>>>> CC: m3devel at elegosoft.com
>>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>>>
>>>>>> I've been interested in an ARM port for some time. If you (or anyone else) are interested in doing the port I can send you one of these, which looks like a good platform since it runs Linux and Android, has 512K memory and looks well supported: http://beagleboard.org/hardware
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 20/05/2010, at 4:47 AM, 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?
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>
 		 	   		  

From darko at darko.org  Sat Jun 19 12:32:33 2010
From: darko at darko.org (Darko)
Date: Sat, 19 Jun 2010 03:32:33 -0700
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <COL101-W18EA6CF8E4C3963769265EE6C10@phx.gbl>
References: <1274350133.8902.0.camel@localhost>, , , , , ,
	<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>, , , , , ,
	<2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>, , , , ,
	<COL101-W580FCB4C956AC658A851ABE6C00@phx.gbl>, , , , ,
	<44CCDCF6-BACE-4B58-A1F5-EF68A852E2A5@darko.org>, , , ,
	<COL101-W493D8FFD71EB43948CBE8CE6C10@phx.gbl>, , , ,
	<B4638299-A29A-454B-9931-4F296F9AD3DB@darko.org>, ,
	<COL101-W7F2C05F30E9F3525E482DE6C10@phx.gbl>, ,
	<ED46DCAD-C84A-488C-BF6F-70CA1F24AF3B@darko.org>,
	<COL101-W5474F17968788325FFA76CE6C10@phx.gbl>,
	<5E055C3D-78F6-4C08-86D9-8B8CA86B11A1@darko.org>,
	<C76EF524-6048-4C61-9744-6797BBA6C552@darko.org>
	<COL101-W18EA6CF8E4C3963769265EE6C10@phx.gbl>
Message-ID: <8F3CF5B8-4F17-4D43-AB51-BF960B05BA80@darko.org>

Has it got something to do with integration with Java?

On 19/06/2010, at 3:29 AM, Jay K wrote:


Interesting to notice that they have their own pthread library..related to how I suggested we implement Modula-3 threads on top of Linux kernel interfaces instead of pthreads..

 - Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: darko at darko.org
> CC: m3devel at elegosoft.com
> Subject: RE: [M3devel] Linux/ARM? Android?
> Date: Sat, 19 Jun 2010 09:51:50 +0000
> 
> 
> Eh I guess I should try that then. Ok. Thanks. Gotta take a break for a while.
> cd wherever
> cvs -z3 upd -dAP
> cd scripts/python
> ./boot1.py ARMEL_LINUX
>  => cm3-boot-ARMEL_LINUX...tgz
>  extract that on a machine with cross tools (e.g. arm-linux-gnueabi-gcc, arm-linux-gnueabi-as), possibly the same machine as already on
>  cd into it
>  make
>  => arm cm3
> 
> 
> I got that far.
> I can't claim it is right for Android.
> 
> 
> Then put that cm3 onto a real (or emulated) ARM system and...
> (cvs checkout, put the cm3 in /cm3/bin or such, add that to $PATH, and scripts/python/boot2.sh)
> 
> 
> Moving forward to gcc 4.5 will get us atomics for ARM, sort of, at least on Linux, see:
> http://gcc.gnu.org/wiki/Atomic
> 
> 
> - Jay
> 
> ----------------------------------------
>> From: darko at darko.org
>> Date: Sat, 19 Jun 2010 02:15:17 -0700
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Linux/ARM? Android?
>> 
>> I should also mention that the Android SDK has a QEMU based emulator for testing applications and the adb (Android Bridge) tool can provide shell access.
>> 
>> 
>> On 19/06/2010, at 12:13 AM, Darko wrote:
>> 
>> I got the first Debian image on http://www.oszoo.org/wiki/index.php/Category:ARM_images to run with a GUI, and it connect to the network. I'm using Q on my 2.4Ghz MacBook 13" and it's surprisingly fast. Note that it's a 10GB image (450MB download).
>> 
>> There are also images for Debian MIPS on that site too.
>> 
>> I agree that the new MacBook trackpad is not perfect and since moving from my previous machine that had a separate button I now get a lot of stray gestures doing odd things. The general solution is not to use the button at all and use taps. The new momentum scrolling with the gesture is neat but needs more "weight". Unfortunately Apple crosses over into form-over-function territory from time to time and this is one of those times.
>> 
>> 
>> On 18/06/2010, at 11:18 PM, Jay K wrote:
>> 
>> 
>> XP when I can; nothing else comes close for searching and editing text, I've tried many.
>> Visual C++ 5.0.
>> I recently learned how to copy/paste in vi, which helps, but I'm not sure I remember now.
>> 
>> 
>> Darwin/amd64 when I need/want posix/fastfork, which unfortunately is often.
>> Cygwin is slow.
>> TextWrangler usually there, though it is awful compared to Visual C++ 5.0.
>> KomodoEdit is cross platform but also fairly impaired.
>> ssh access to a variety
>> Linux=Debian, it has among the best support for a variety of platforms.
>> Gentoo comes close or better (ppc64) but I've never been able to get it to install -- booting always fails.
>> Debian/x86 easy to get cross compiler, qemu, etc.
>> 
>> 
>> X Windows apps are never very good imho, so just give up and make do with the even worse command line..
>> I find things as basic as scrollbars do not work well -- which button do I press when?
>> The Modula-3 GUI apps suffer from this problem as well.
>> Further damage due to needing three buttons but not having them.
>> 
>> 
>> Mouse button clicking is actually broken on modern Macs too -- they removed the mouse button from all the laptops, leaving
>> just a big pad, prone to accidental clicks at any location.. also prone to accidental multitouch gestures due to resting
>> a twitchy thumb where the button is supposed to be. Amazing, really, the mouse, one of their key initial advantages,
>> is now broken. (see also Finder and file open dialogs, two other former strengths that are now not so great.)
>> Multitouch scroll is nice though.
>> 
>> 
>> - Jay
>> 
>> ----------------------------------------
>>> From: darko at darko.org
>>> Date: Fri, 18 Jun 2010 22:55:24 -0700
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>> 
>>> Yeah I've got it working on the console but I agree it needs the network.
>>> 
>>> Try: http://www.oszoo.org/wiki/index.php/Category:ARM_images
>>> Also: http://www.armedslack.org/
>>> 
>>> What platform are you running on these days?
>>> 
>>> 
>>> 
>>> 
>>> On 18/06/2010, at 10:44 PM, Jay K wrote:
>>> 
>>> 
>>> Interesting, thanks.
>>> But it looks like it needs to use local console for output?
>>> I need something over the network/X.
>>> It looks like there's an qemu option for usemode only too.
>>> 
>>> - Jay
>>> 
>>> ----------------------------------------
>>>> From: darko at darko.org
>>>> Date: Fri, 18 Jun 2010 22:13:43 -0700
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>> 
>>>> If you use qemu, this might be useful: http://free-electrons.com/community/demos/qemu-arm-directfb/
>>>> 
>>>> I'm currently looking at some cheap laptops (around $100) which have ethernet plus screen, keyboard, battery, etc which would work well as hosts. Just trying to find one that runs both Linux and Android.
>>>> 
>>>> 
>>>> On 18/06/2010, at 10:04 PM, Jay K wrote:
>>>> 
>>>> 
>>>> Thanks. I'll give qemu a go as well.
>>>> Hey, maybe we can get mips also. (there's decent modern mips/linux hardware now, Chinese laptops)
>>>> 
>>>> - Jay
>>>> 
>>>> ----------------------------------------
>>>>> From: darko at darko.org
>>>>> Date: Thu, 17 Jun 2010 21:41:59 -0700
>>>>> To: jay.krell at cornell.edu
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>> 
>>>>> Ok, the link here is about 20/4Mbs so it shouldn't be too bad and the latency is good. I'm in Mountain View, CA. Unfortunately the board has only 128MB of main memory but I assume that's enough, I think a self hosted compiler has no point.
>>>>> 
>>>>> I'll post the details when it's up and running.
>>>>> 
>>>>> 
>>>>> On 17/06/2010, at 9:15 PM, Jay K wrote:
>>>>> 
>>>>> 
>>>>> My preference would be if you can set it up on the internet and allow me ssh access.
>>>>> gcc only recently got support for Android's C library "bionic", I believe post-gcc 4.5.
>>>>> I'm not sure if that matters much or not.
>>>>> I'm not sure how much the C library of the target matters to gcc.
>>>>> 
>>>>> 
>>>>> Anything with pthreads and gcc support is quite easy to port to these days. In the past the biggest thing you had to do was rewrite /usr/include in Modula-3. There was a tendency to rewrite far more of it than necessary. These days, none of it is needed.
>>>>> 
>>>>> 
>>>>> Now you just have to
>>>>> - pick a target name
>>>>> - find the jmpbuf size, word size, endian
>>>>> - write a much small "config" file
>>>>> - respond to each error that occurs -- fill in the platform in a few tables sprinkled around the tree
>>>>> 
>>>>> 
>>>>> Even systems without pthreads or with not very good pthreads (OpenBSD) are easy now, as the user thread support is much more portable. It used to be, for user threads, you had to poke around in the jmpbuf.
>>>>> 
>>>>> 
>>>>> I would encourage anyone else to try it out.
>>>>> 
>>>>> 
>>>>> Maybe soon there will be a C generating backend, and we'll just have one distribution format that is a bunch of C, and then gcc support won't even be needed (e.g. IA64_NT).
>>>>> 
>>>>> 
>>>>> Thanks,
>>>>> - Jay
>>>>> 
>>>>> ----------------------------------------
>>>>>> From: darko at darko.org
>>>>>> Date: Thu, 17 Jun 2010 18:08:14 -0700
>>>>>> To: jay.krell at cornell.edu
>>>>>> CC: m3devel at elegosoft.com
>>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>>> 
>>>>>> I've been interested in an ARM port for some time. If you (or anyone else) are interested in doing the port I can send you one of these, which looks like a good platform since it runs Linux and Android, has 512K memory and looks well supported: http://beagleboard.org/hardware
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On 20/05/2010, at 4:47 AM, 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?
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
>> 
> 
		 	   		  



From jay.krell at cornell.edu  Sat Jun 19 18:56:54 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 19 Jun 2010 16:56:54 +0000
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <8F3CF5B8-4F17-4D43-AB51-BF960B05BA80@darko.org>
References: <1274350133.8902.0.camel@localhost>, , , , ,
	,,<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>, , , , ,
	,,<2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>, , , ,
	,,<COL101-W580FCB4C956AC658A851ABE6C00@phx.gbl>, , , ,
	,,<44CCDCF6-BACE-4B58-A1F5-EF68A852E2A5@darko.org>, , ,
	,,<COL101-W493D8FFD71EB43948CBE8CE6C10@phx.gbl>, , ,
	,,<B4638299-A29A-454B-9931-4F296F9AD3DB@darko.org>,
	,,<COL101-W7F2C05F30E9F3525E482DE6C10@phx.gbl>,
	, , <ED46DCAD-C84A-488C-BF6F-70CA1F24AF3B@darko.org>, ,
	<COL101-W5474F17968788325FFA76CE6C10@phx.gbl>, ,
	<5E055C3D-78F6-4C08-86D9-8B8CA86B11A1@darko.org>, ,
	<C76EF524-6048-4C61-9744-6797BBA6C552@darko.org>,
	<COL101-W18EA6CF8E4C3963769265EE6C10@phx.gbl>,
	<8F3CF5B8-4F17-4D43-AB51-BF960B05BA80@darko.org>
Message-ID: <COL101-W84E06E7B4D04EE7BE3FC8E6C10@phx.gbl>


I don't think so. Replacing glibc is a popular activity, mostly for efficiency.
See android-ndk-r4/docs/system/libc/overview.txt.

Even Debian no longer uses glibc, sort of.
http://www.osnews.com/story/21441/Debian_Switching_to_EGLIBC
http://www.eglibc.org/home

?- Jay

----------------------------------------
> From: darko at darko.org
> Date: Sat, 19 Jun 2010 03:32:33 -0700
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Linux/ARM? Android?
>
> Has it got something to do with integration with Java?
>
> On 19/06/2010, at 3:29 AM, Jay K wrote:
>
>
> Interesting to notice that they have their own pthread library..related to how I suggested we implement Modula-3 threads on top of Linux kernel interfaces instead of pthreads..
>
> - Jay
>
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: darko at darko.org
>> CC: m3devel at elegosoft.com
>> Subject: RE: [M3devel] Linux/ARM? Android?
>> Date: Sat, 19 Jun 2010 09:51:50 +0000
>>
>>
>> Eh I guess I should try that then. Ok. Thanks. Gotta take a break for a while.
>> cd wherever
>> cvs -z3 upd -dAP
>> cd scripts/python
>> ./boot1.py ARMEL_LINUX
>> => cm3-boot-ARMEL_LINUX...tgz
>> extract that on a machine with cross tools (e.g. arm-linux-gnueabi-gcc, arm-linux-gnueabi-as), possibly the same machine as already on
>> cd into it
>> make
>> => arm cm3
>>
>>
>> I got that far.
>> I can't claim it is right for Android.
>>
>>
>> Then put that cm3 onto a real (or emulated) ARM system and...
>> (cvs checkout, put the cm3 in /cm3/bin or such, add that to $PATH, and scripts/python/boot2.sh)
>>
>>
>> Moving forward to gcc 4.5 will get us atomics for ARM, sort of, at least on Linux, see:
>> http://gcc.gnu.org/wiki/Atomic
>>
>>
>> - Jay
>>
>> ----------------------------------------
>>> From: darko at darko.org
>>> Date: Sat, 19 Jun 2010 02:15:17 -0700
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>
>>> I should also mention that the Android SDK has a QEMU based emulator for testing applications and the adb (Android Bridge) tool can provide shell access.
>>>
>>>
>>> On 19/06/2010, at 12:13 AM, Darko wrote:
>>>
>>> I got the first Debian image on http://www.oszoo.org/wiki/index.php/Category:ARM_images to run with a GUI, and it connect to the network. I'm using Q on my 2.4Ghz MacBook 13" and it's surprisingly fast. Note that it's a 10GB image (450MB download).
>>>
>>> There are also images for Debian MIPS on that site too.
>>>
>>> I agree that the new MacBook trackpad is not perfect and since moving from my previous machine that had a separate button I now get a lot of stray gestures doing odd things. The general solution is not to use the button at all and use taps. The new momentum scrolling with the gesture is neat but needs more "weight". Unfortunately Apple crosses over into form-over-function territory from time to time and this is one of those times.
>>>
>>>
>>> On 18/06/2010, at 11:18 PM, Jay K wrote:
>>>
>>>
>>> XP when I can; nothing else comes close for searching and editing text, I've tried many.
>>> Visual C++ 5.0.
>>> I recently learned how to copy/paste in vi, which helps, but I'm not sure I remember now.
>>>
>>>
>>> Darwin/amd64 when I need/want posix/fastfork, which unfortunately is often.
>>> Cygwin is slow.
>>> TextWrangler usually there, though it is awful compared to Visual C++ 5.0.
>>> KomodoEdit is cross platform but also fairly impaired.
>>> ssh access to a variety
>>> Linux=Debian, it has among the best support for a variety of platforms.
>>> Gentoo comes close or better (ppc64) but I've never been able to get it to install -- booting always fails.
>>> Debian/x86 easy to get cross compiler, qemu, etc.
>>>
>>>
>>> X Windows apps are never very good imho, so just give up and make do with the even worse command line..
>>> I find things as basic as scrollbars do not work well -- which button do I press when?
>>> The Modula-3 GUI apps suffer from this problem as well.
>>> Further damage due to needing three buttons but not having them.
>>>
>>>
>>> Mouse button clicking is actually broken on modern Macs too -- they removed the mouse button from all the laptops, leaving
>>> just a big pad, prone to accidental clicks at any location.. also prone to accidental multitouch gestures due to resting
>>> a twitchy thumb where the button is supposed to be. Amazing, really, the mouse, one of their key initial advantages,
>>> is now broken. (see also Finder and file open dialogs, two other former strengths that are now not so great.)
>>> Multitouch scroll is nice though.
>>>
>>>
>>> - Jay
>>>
>>> ----------------------------------------
>>>> From: darko at darko.org
>>>> Date: Fri, 18 Jun 2010 22:55:24 -0700
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>
>>>> Yeah I've got it working on the console but I agree it needs the network.
>>>>
>>>> Try: http://www.oszoo.org/wiki/index.php/Category:ARM_images
>>>> Also: http://www.armedslack.org/
>>>>
>>>> What platform are you running on these days?
>>>>
>>>>
>>>>
>>>>
>>>> On 18/06/2010, at 10:44 PM, Jay K wrote:
>>>>
>>>>
>>>> Interesting, thanks.
>>>> But it looks like it needs to use local console for output?
>>>> I need something over the network/X.
>>>> It looks like there's an qemu option for usemode only too.
>>>>
>>>> - Jay
>>>>
>>>> ----------------------------------------
>>>>> From: darko at darko.org
>>>>> Date: Fri, 18 Jun 2010 22:13:43 -0700
>>>>> To: jay.krell at cornell.edu
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>>
>>>>> If you use qemu, this might be useful: http://free-electrons.com/community/demos/qemu-arm-directfb/
>>>>>
>>>>> I'm currently looking at some cheap laptops (around $100) which have ethernet plus screen, keyboard, battery, etc which would work well as hosts. Just trying to find one that runs both Linux and Android.
>>>>>
>>>>>
>>>>> On 18/06/2010, at 10:04 PM, Jay K wrote:
>>>>>
>>>>>
>>>>> Thanks. I'll give qemu a go as well.
>>>>> Hey, maybe we can get mips also. (there's decent modern mips/linux hardware now, Chinese laptops)
>>>>>
>>>>> - Jay
>>>>>
>>>>> ----------------------------------------
>>>>>> From: darko at darko.org
>>>>>> Date: Thu, 17 Jun 2010 21:41:59 -0700
>>>>>> To: jay.krell at cornell.edu
>>>>>> CC: m3devel at elegosoft.com
>>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>>>
>>>>>> Ok, the link here is about 20/4Mbs so it shouldn't be too bad and the latency is good. I'm in Mountain View, CA. Unfortunately the board has only 128MB of main memory but I assume that's enough, I think a self hosted compiler has no point.
>>>>>>
>>>>>> I'll post the details when it's up and running.
>>>>>>
>>>>>>
>>>>>> On 17/06/2010, at 9:15 PM, Jay K wrote:
>>>>>>
>>>>>>
>>>>>> My preference would be if you can set it up on the internet and allow me ssh access.
>>>>>> gcc only recently got support for Android's C library "bionic", I believe post-gcc 4.5.
>>>>>> I'm not sure if that matters much or not.
>>>>>> I'm not sure how much the C library of the target matters to gcc.
>>>>>>
>>>>>>
>>>>>> Anything with pthreads and gcc support is quite easy to port to these days. In the past the biggest thing you had to do was rewrite /usr/include in Modula-3. There was a tendency to rewrite far more of it than necessary. These days, none of it is needed.
>>>>>>
>>>>>>
>>>>>> Now you just have to
>>>>>> - pick a target name
>>>>>> - find the jmpbuf size, word size, endian
>>>>>> - write a much small "config" file
>>>>>> - respond to each error that occurs -- fill in the platform in a few tables sprinkled around the tree
>>>>>>
>>>>>>
>>>>>> Even systems without pthreads or with not very good pthreads (OpenBSD) are easy now, as the user thread support is much more portable. It used to be, for user threads, you had to poke around in the jmpbuf.
>>>>>>
>>>>>>
>>>>>> I would encourage anyone else to try it out.
>>>>>>
>>>>>>
>>>>>> Maybe soon there will be a C generating backend, and we'll just have one distribution format that is a bunch of C, and then gcc support won't even be needed (e.g. IA64_NT).
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> - Jay
>>>>>>
>>>>>> ----------------------------------------
>>>>>>> From: darko at darko.org
>>>>>>> Date: Thu, 17 Jun 2010 18:08:14 -0700
>>>>>>> To: jay.krell at cornell.edu
>>>>>>> CC: m3devel at elegosoft.com
>>>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>>>>
>>>>>>> I've been interested in an ARM port for some time. If you (or anyone else) are interested in doing the port I can send you one of these, which looks like a good platform since it runs Linux and Android, has 512K memory and looks well supported: http://beagleboard.org/hardware
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 20/05/2010, at 4:47 AM, 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?
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>
>
 		 	   		  

From darko at darko.org  Sun Jun 20 00:47:24 2010
From: darko at darko.org (Darko)
Date: Sat, 19 Jun 2010 15:47:24 -0700
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <COL101-W31787A72294920C0484E63E6C10@phx.gbl>
References: <1274350133.8902.0.camel@localhost>, , , , ,
	<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>, , , , ,
	<2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>, , , ,
	<COL101-W580FCB4C956AC658A851ABE6C00@phx.gbl>, , , ,
	<44CCDCF6-BACE-4B58-A1F5-EF68A852E2A5@darko.org>, , ,
	<COL101-W493D8FFD71EB43948CBE8CE6C10@phx.gbl>, , ,
	<B4638299-A29A-454B-9931-4F296F9AD3DB@darko.org>, ,
	<COL101-W7F2C05F30E9F3525E482DE6C10@phx.gbl>, ,
	<ED46DCAD-C84A-488C-BF6F-70CA1F24AF3B@darko.org>,
	<COL101-W5474F17968788325FFA76CE6C10@phx.gbl>,
	<5E055C3D-78F6-4C08-86D9-8B8CA86B11A1@darko.org>,
	<C76EF524-6048-4C61-9744-6797BBA6C552@darko.org>
	<COL101-W31787A72294920C0484E63E6C10@phx.gbl>
Message-ID: <C1506F07-DE5E-4712-B15E-CB220A087D1A@darko.org>

Fantasic, thanks. There are some ARM cross tools available under DarwinPorts which I'm going to give this a try with.


On 19/06/2010, at 2:51 AM, Jay K wrote:


Eh I guess I should try that then. Ok. Thanks. Gotta take a break for a while.
 cd wherever 
 cvs -z3 upd -dAP  
 cd scripts/python  
 ./boot1.py ARMEL_LINUX  
  => cm3-boot-ARMEL_LINUX...tgz 
  extract that on a machine with cross tools (e.g. arm-linux-gnueabi-gcc, arm-linux-gnueabi-as), possibly the same machine as already on 
  cd into it  
  make  
  => arm cm3 


I got that far.
I can't claim it is right for Android.


Then put that cm3 onto a real (or emulated) ARM system and...
(cvs checkout, put the cm3 in /cm3/bin or such, add that to $PATH, and scripts/python/boot2.sh)


Moving forward to gcc 4.5 will get us atomics for ARM, sort of, at least on Linux, see:
 http://gcc.gnu.org/wiki/Atomic 


 - Jay

----------------------------------------
> From: darko at darko.org
> Date: Sat, 19 Jun 2010 02:15:17 -0700
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Linux/ARM? Android?
> 
> I should also mention that the Android SDK has a QEMU based emulator for testing applications and the adb (Android Bridge) tool can provide shell access.
> 
> 
> On 19/06/2010, at 12:13 AM, Darko wrote:
> 
> I got the first Debian image on http://www.oszoo.org/wiki/index.php/Category:ARM_images to run with a GUI, and it connect to the network. I'm using Q on my 2.4Ghz MacBook 13" and it's surprisingly fast. Note that it's a 10GB image (450MB download).
> 
> There are also images for Debian MIPS on that site too.
> 
> I agree that the new MacBook trackpad is not perfect and since moving from my previous machine that had a separate button I now get a lot of stray gestures doing odd things. The general solution is not to use the button at all and use taps. The new momentum scrolling with the gesture is neat but needs more "weight". Unfortunately Apple crosses over into form-over-function territory from time to time and this is one of those times.
> 
> 
> On 18/06/2010, at 11:18 PM, Jay K wrote:
> 
> 
> XP when I can; nothing else comes close for searching and editing text, I've tried many.
> Visual C++ 5.0.
> I recently learned how to copy/paste in vi, which helps, but I'm not sure I remember now.
> 
> 
> Darwin/amd64 when I need/want posix/fastfork, which unfortunately is often.
> Cygwin is slow.
> TextWrangler usually there, though it is awful compared to Visual C++ 5.0.
> KomodoEdit is cross platform but also fairly impaired.
> ssh access to a variety
> Linux=Debian, it has among the best support for a variety of platforms.
> Gentoo comes close or better (ppc64) but I've never been able to get it to install -- booting always fails.
> Debian/x86 easy to get cross compiler, qemu, etc.
> 
> 
> X Windows apps are never very good imho, so just give up and make do with the even worse command line..
> I find things as basic as scrollbars do not work well -- which button do I press when?
> The Modula-3 GUI apps suffer from this problem as well.
> Further damage due to needing three buttons but not having them.
> 
> 
> Mouse button clicking is actually broken on modern Macs too -- they removed the mouse button from all the laptops, leaving
> just a big pad, prone to accidental clicks at any location.. also prone to accidental multitouch gestures due to resting
> a twitchy thumb where the button is supposed to be. Amazing, really, the mouse, one of their key initial advantages,
> is now broken. (see also Finder and file open dialogs, two other former strengths that are now not so great.)
> Multitouch scroll is nice though.
> 
> 
> - Jay
> 
> ----------------------------------------
>> From: darko at darko.org
>> Date: Fri, 18 Jun 2010 22:55:24 -0700
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Linux/ARM? Android?
>> 
>> Yeah I've got it working on the console but I agree it needs the network.
>> 
>> Try: http://www.oszoo.org/wiki/index.php/Category:ARM_images
>> Also: http://www.armedslack.org/
>> 
>> What platform are you running on these days?
>> 
>> 
>> 
>> 
>> On 18/06/2010, at 10:44 PM, Jay K wrote:
>> 
>> 
>> Interesting, thanks.
>> But it looks like it needs to use local console for output?
>> I need something over the network/X.
>> It looks like there's an qemu option for usemode only too.
>> 
>> - Jay
>> 
>> ----------------------------------------
>>> From: darko at darko.org
>>> Date: Fri, 18 Jun 2010 22:13:43 -0700
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>> 
>>> If you use qemu, this might be useful: http://free-electrons.com/community/demos/qemu-arm-directfb/
>>> 
>>> I'm currently looking at some cheap laptops (around $100) which have ethernet plus screen, keyboard, battery, etc which would work well as hosts. Just trying to find one that runs both Linux and Android.
>>> 
>>> 
>>> On 18/06/2010, at 10:04 PM, Jay K wrote:
>>> 
>>> 
>>> Thanks. I'll give qemu a go as well.
>>> Hey, maybe we can get mips also. (there's decent modern mips/linux hardware now, Chinese laptops)
>>> 
>>> - Jay
>>> 
>>> ----------------------------------------
>>>> From: darko at darko.org
>>>> Date: Thu, 17 Jun 2010 21:41:59 -0700
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>> 
>>>> Ok, the link here is about 20/4Mbs so it shouldn't be too bad and the latency is good. I'm in Mountain View, CA. Unfortunately the board has only 128MB of main memory but I assume that's enough, I think a self hosted compiler has no point.
>>>> 
>>>> I'll post the details when it's up and running.
>>>> 
>>>> 
>>>> On 17/06/2010, at 9:15 PM, Jay K wrote:
>>>> 
>>>> 
>>>> My preference would be if you can set it up on the internet and allow me ssh access.
>>>> gcc only recently got support for Android's C library "bionic", I believe post-gcc 4.5.
>>>> I'm not sure if that matters much or not.
>>>> I'm not sure how much the C library of the target matters to gcc.
>>>> 
>>>> 
>>>> Anything with pthreads and gcc support is quite easy to port to these days. In the past the biggest thing you had to do was rewrite /usr/include in Modula-3. There was a tendency to rewrite far more of it than necessary. These days, none of it is needed.
>>>> 
>>>> 
>>>> Now you just have to
>>>> - pick a target name
>>>> - find the jmpbuf size, word size, endian
>>>> - write a much small "config" file
>>>> - respond to each error that occurs -- fill in the platform in a few tables sprinkled around the tree
>>>> 
>>>> 
>>>> Even systems without pthreads or with not very good pthreads (OpenBSD) are easy now, as the user thread support is much more portable. It used to be, for user threads, you had to poke around in the jmpbuf.
>>>> 
>>>> 
>>>> I would encourage anyone else to try it out.
>>>> 
>>>> 
>>>> Maybe soon there will be a C generating backend, and we'll just have one distribution format that is a bunch of C, and then gcc support won't even be needed (e.g. IA64_NT).
>>>> 
>>>> 
>>>> Thanks,
>>>> - Jay
>>>> 
>>>> ----------------------------------------
>>>>> From: darko at darko.org
>>>>> Date: Thu, 17 Jun 2010 18:08:14 -0700
>>>>> To: jay.krell at cornell.edu
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>> 
>>>>> I've been interested in an ARM port for some time. If you (or anyone else) are interested in doing the port I can send you one of these, which looks like a good platform since it runs Linux and Android, has 512K memory and looks well supported: http://beagleboard.org/hardware
>>>>> 
>>>>> 
>>>>> 
>>>>> On 20/05/2010, at 4:47 AM, 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?
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
> 
> 
> 
		 	   		  



From jay.krell at cornell.edu  Sun Jun 20 01:42:16 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 19 Jun 2010 23:42:16 +0000
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <C1506F07-DE5E-4712-B15E-CB220A087D1A@darko.org>
References: <1274350133.8902.0.camel@localhost>, , , ,
	,,<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>, , , ,
	,,<2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>, , ,
	,,<COL101-W580FCB4C956AC658A851ABE6C00@phx.gbl>, , ,
	,,<44CCDCF6-BACE-4B58-A1F5-EF68A852E2A5@darko.org>, ,
	,,<COL101-W493D8FFD71EB43948CBE8CE6C10@phx.gbl>, ,
	,,<B4638299-A29A-454B-9931-4F296F9AD3DB@darko.org>,
	,,<COL101-W7F2C05F30E9F3525E482DE6C10@phx.gbl>,
	, , <ED46DCAD-C84A-488C-BF6F-70CA1F24AF3B@darko.org>, ,
	<COL101-W5474F17968788325FFA76CE6C10@phx.gbl>, ,
	<5E055C3D-78F6-4C08-86D9-8B8CA86B11A1@darko.org>, ,
	<C76EF524-6048-4C61-9744-6797BBA6C552@darko.org>,
	<COL101-W31787A72294920C0484E63E6C10@phx.gbl>,
	<C1506F07-DE5E-4712-B15E-CB220A087D1A@darko.org>
Message-ID: <COL101-W29BA9D3680CFB903430A43E6C10@phx.gbl>


I should point out, actually, with cross gcc/as, you should be able to easily enough build the whole system cross.
ie: your apps instead of cm3.
I can try that -- building the whole tree cross, including compiling C and linking.


Notice m3-sys/cminstall/src/config-no-install/ARMEL_LINUX:


SYSTEM_CC = "arm-linux-gnueabi-gcc -gstabs+ -fPIC" % C compiler
SYSTEM_ASM = "arm-linux-gnueabi-as" % Assembler


I get to:
jay at xlin2:~/cm3-boot-ARMEL_LINUX-d5.8.2-20100619$ file cm3
cm3: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.14, not stripped
jay at xlin2:~/cm3-boot-ARMEL_LINUX-d5.8.2-20100619$ qemu-arm ./cm3
/lib/ld-linux.so.3: No such file or directory


My QEmu setup isn't complete..


I got the crosstools from hereabouts:
? http://www.emdebian.org/tools/crosstools.html


crosstool, scratchbox, buildroot may also be good options.


This reminds me though, I have a Western Digital MyBook World Edition.
Haven't powered it on in a while, slightly flaky device.
But it runs Linux/arm (oldabi).
I could/should power it on or get a new one something.


Also note/reminder, Android seems a bit different, at least in terms of finding C headers and libraries, maybe not for generating assembly, than "regular" Linux/arm.
Really "Linux/arm" seems a pretty fractured thing.
Newer architectures have floating point, for one thing.


?- Jay

----------------------------------------
> From: darko at darko.org
> Date: Sat, 19 Jun 2010 15:47:24 -0700
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Linux/ARM? Android?
>
> Fantasic, thanks. There are some ARM cross tools available under DarwinPorts which I'm going to give this a try with.
>
>
> On 19/06/2010, at 2:51 AM, Jay K wrote:
>
>
> Eh I guess I should try that then. Ok. Thanks. Gotta take a break for a while.
> cd wherever
> cvs -z3 upd -dAP
> cd scripts/python
> ./boot1.py ARMEL_LINUX
> => cm3-boot-ARMEL_LINUX...tgz
> extract that on a machine with cross tools (e.g. arm-linux-gnueabi-gcc, arm-linux-gnueabi-as), possibly the same machine as already on
> cd into it
> make
> => arm cm3
>
>
> I got that far.
> I can't claim it is right for Android.
>
>
> Then put that cm3 onto a real (or emulated) ARM system and...
> (cvs checkout, put the cm3 in /cm3/bin or such, add that to $PATH, and scripts/python/boot2.sh)
>
>
> Moving forward to gcc 4.5 will get us atomics for ARM, sort of, at least on Linux, see:
> http://gcc.gnu.org/wiki/Atomic
>
>
> - Jay
>
> ----------------------------------------
>> From: darko at darko.org
>> Date: Sat, 19 Jun 2010 02:15:17 -0700
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Linux/ARM? Android?
>>
>> I should also mention that the Android SDK has a QEMU based emulator for testing applications and the adb (Android Bridge) tool can provide shell access.
>>
>>
>> On 19/06/2010, at 12:13 AM, Darko wrote:
>>
>> I got the first Debian image on http://www.oszoo.org/wiki/index.php/Category:ARM_images to run with a GUI, and it connect to the network. I'm using Q on my 2.4Ghz MacBook 13" and it's surprisingly fast. Note that it's a 10GB image (450MB download).
>>
>> There are also images for Debian MIPS on that site too.
>>
>> I agree that the new MacBook trackpad is not perfect and since moving from my previous machine that had a separate button I now get a lot of stray gestures doing odd things. The general solution is not to use the button at all and use taps. The new momentum scrolling with the gesture is neat but needs more "weight". Unfortunately Apple crosses over into form-over-function territory from time to time and this is one of those times.
>>
>>
>> On 18/06/2010, at 11:18 PM, Jay K wrote:
>>
>>
>> XP when I can; nothing else comes close for searching and editing text, I've tried many.
>> Visual C++ 5.0.
>> I recently learned how to copy/paste in vi, which helps, but I'm not sure I remember now.
>>
>>
>> Darwin/amd64 when I need/want posix/fastfork, which unfortunately is often.
>> Cygwin is slow.
>> TextWrangler usually there, though it is awful compared to Visual C++ 5.0.
>> KomodoEdit is cross platform but also fairly impaired.
>> ssh access to a variety
>> Linux=Debian, it has among the best support for a variety of platforms.
>> Gentoo comes close or better (ppc64) but I've never been able to get it to install -- booting always fails.
>> Debian/x86 easy to get cross compiler, qemu, etc.
>>
>>
>> X Windows apps are never very good imho, so just give up and make do with the even worse command line..
>> I find things as basic as scrollbars do not work well -- which button do I press when?
>> The Modula-3 GUI apps suffer from this problem as well.
>> Further damage due to needing three buttons but not having them.
>>
>>
>> Mouse button clicking is actually broken on modern Macs too -- they removed the mouse button from all the laptops, leaving
>> just a big pad, prone to accidental clicks at any location.. also prone to accidental multitouch gestures due to resting
>> a twitchy thumb where the button is supposed to be. Amazing, really, the mouse, one of their key initial advantages,
>> is now broken. (see also Finder and file open dialogs, two other former strengths that are now not so great.)
>> Multitouch scroll is nice though.
>>
>>
>> - Jay
>>
>> ----------------------------------------
>>> From: darko at darko.org
>>> Date: Fri, 18 Jun 2010 22:55:24 -0700
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>
>>> Yeah I've got it working on the console but I agree it needs the network.
>>>
>>> Try: http://www.oszoo.org/wiki/index.php/Category:ARM_images
>>> Also: http://www.armedslack.org/
>>>
>>> What platform are you running on these days?
>>>
>>>
>>>
>>>
>>> On 18/06/2010, at 10:44 PM, Jay K wrote:
>>>
>>>
>>> Interesting, thanks.
>>> But it looks like it needs to use local console for output?
>>> I need something over the network/X.
>>> It looks like there's an qemu option for usemode only too.
>>>
>>> - Jay
>>>
>>> ----------------------------------------
>>>> From: darko at darko.org
>>>> Date: Fri, 18 Jun 2010 22:13:43 -0700
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>
>>>> If you use qemu, this might be useful: http://free-electrons.com/community/demos/qemu-arm-directfb/
>>>>
>>>> I'm currently looking at some cheap laptops (around $100) which have ethernet plus screen, keyboard, battery, etc which would work well as hosts. Just trying to find one that runs both Linux and Android.
>>>>
>>>>
>>>> On 18/06/2010, at 10:04 PM, Jay K wrote:
>>>>
>>>>
>>>> Thanks. I'll give qemu a go as well.
>>>> Hey, maybe we can get mips also. (there's decent modern mips/linux hardware now, Chinese laptops)
>>>>
>>>> - Jay
>>>>
>>>> ----------------------------------------
>>>>> From: darko at darko.org
>>>>> Date: Thu, 17 Jun 2010 21:41:59 -0700
>>>>> To: jay.krell at cornell.edu
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>>
>>>>> Ok, the link here is about 20/4Mbs so it shouldn't be too bad and the latency is good. I'm in Mountain View, CA. Unfortunately the board has only 128MB of main memory but I assume that's enough, I think a self hosted compiler has no point.
>>>>>
>>>>> I'll post the details when it's up and running.
>>>>>
>>>>>
>>>>> On 17/06/2010, at 9:15 PM, Jay K wrote:
>>>>>
>>>>>
>>>>> My preference would be if you can set it up on the internet and allow me ssh access.
>>>>> gcc only recently got support for Android's C library "bionic", I believe post-gcc 4.5.
>>>>> I'm not sure if that matters much or not.
>>>>> I'm not sure how much the C library of the target matters to gcc.
>>>>>
>>>>>
>>>>> Anything with pthreads and gcc support is quite easy to port to these days. In the past the biggest thing you had to do was rewrite /usr/include in Modula-3. There was a tendency to rewrite far more of it than necessary. These days, none of it is needed.
>>>>>
>>>>>
>>>>> Now you just have to
>>>>> - pick a target name
>>>>> - find the jmpbuf size, word size, endian
>>>>> - write a much small "config" file
>>>>> - respond to each error that occurs -- fill in the platform in a few tables sprinkled around the tree
>>>>>
>>>>>
>>>>> Even systems without pthreads or with not very good pthreads (OpenBSD) are easy now, as the user thread support is much more portable. It used to be, for user threads, you had to poke around in the jmpbuf.
>>>>>
>>>>>
>>>>> I would encourage anyone else to try it out.
>>>>>
>>>>>
>>>>> Maybe soon there will be a C generating backend, and we'll just have one distribution format that is a bunch of C, and then gcc support won't even be needed (e.g. IA64_NT).
>>>>>
>>>>>
>>>>> Thanks,
>>>>> - Jay
>>>>>
>>>>> ----------------------------------------
>>>>>> From: darko at darko.org
>>>>>> Date: Thu, 17 Jun 2010 18:08:14 -0700
>>>>>> To: jay.krell at cornell.edu
>>>>>> CC: m3devel at elegosoft.com
>>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>>>
>>>>>> I've been interested in an ARM port for some time. If you (or anyone else) are interested in doing the port I can send you one of these, which looks like a good platform since it runs Linux and Android, has 512K memory and looks well supported: http://beagleboard.org/hardware
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 20/05/2010, at 4:47 AM, 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?
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>
>
 		 	   		  

From darko at darko.org  Sun Jun 20 02:06:11 2010
From: darko at darko.org (Darko)
Date: Sat, 19 Jun 2010 17:06:11 -0700
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <COL101-W29BA9D3680CFB903430A43E6C10@phx.gbl>
References: <1274350133.8902.0.camel@localhost>, , , , , ,
	<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>, , , , , ,
	<2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>, , , , ,
	<COL101-W580FCB4C956AC658A851ABE6C00@phx.gbl>, , , , ,
	<44CCDCF6-BACE-4B58-A1F5-EF68A852E2A5@darko.org>, , , ,
	<COL101-W493D8FFD71EB43948CBE8CE6C10@phx.gbl>, , , ,
	<B4638299-A29A-454B-9931-4F296F9AD3DB@darko.org>, , ,
	<COL101-W7F2C05F30E9F3525E482DE6C10@phx.gbl>, , ,
	<ED46DCAD-C84A-488C-BF6F-70CA1F24AF3B@darko.org>, ,
	<COL101-W5474F17968788325FFA76CE6C10@phx.gbl>, ,
	<5E055C3D-78F6-4C08-86D9-8B8CA86B11A1@darko.org>, ,
	<C76EF524-6048-4C61-9744-6797BBA6C552@darko.org>,
	<COL101-W31787A72294920C0484E63E6C10@phx.gbl>,
	<C1506F07-DE5E-4712-B15E-CB220A087D1A@darko.org>
	<COL101-W29BA9D3680CFB903430A43E6C10@phx.gbl>
Message-ID: <6DCF6CCC-D3D3-4777-9585-243366375634@darko.org>

A fully crossed system would be the goal since mostly the target devices are ARM are phones, tablets and embedded devices. What distribution are you running on QEmu? Is it the Lenny-lxde one?

Linux/ARM is definitely fractured because of the variety of ARM cores, SoC chips and devices on which it's used. I'm not sure what the best way to approach it is.


On 19/06/2010, at 4:42 PM, Jay K wrote:


I should point out, actually, with cross gcc/as, you should be able to easily enough build the whole system cross.
ie: your apps instead of cm3.
I can try that -- building the whole tree cross, including compiling C and linking.


Notice m3-sys/cminstall/src/config-no-install/ARMEL_LINUX:


SYSTEM_CC = "arm-linux-gnueabi-gcc -gstabs+ -fPIC" % C compiler
SYSTEM_ASM = "arm-linux-gnueabi-as" % Assembler


I get to:
jay at xlin2:~/cm3-boot-ARMEL_LINUX-d5.8.2-20100619$ file cm3
cm3: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.14, not stripped
jay at xlin2:~/cm3-boot-ARMEL_LINUX-d5.8.2-20100619$ qemu-arm ./cm3
/lib/ld-linux.so.3: No such file or directory


My QEmu setup isn't complete..


I got the crosstools from hereabouts:
  http://www.emdebian.org/tools/crosstools.html


crosstool, scratchbox, buildroot may also be good options.


This reminds me though, I have a Western Digital MyBook World Edition.
Haven't powered it on in a while, slightly flaky device.
But it runs Linux/arm (oldabi).
I could/should power it on or get a new one something.


Also note/reminder, Android seems a bit different, at least in terms of finding C headers and libraries, maybe not for generating assembly, than "regular" Linux/arm.
Really "Linux/arm" seems a pretty fractured thing.
Newer architectures have floating point, for one thing.


 - Jay

----------------------------------------
> From: darko at darko.org
> Date: Sat, 19 Jun 2010 15:47:24 -0700
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Linux/ARM? Android?
> 
> Fantasic, thanks. There are some ARM cross tools available under DarwinPorts which I'm going to give this a try with.
> 
> 
> On 19/06/2010, at 2:51 AM, Jay K wrote:
> 
> 
> Eh I guess I should try that then. Ok. Thanks. Gotta take a break for a while.
> cd wherever
> cvs -z3 upd -dAP
> cd scripts/python
> ./boot1.py ARMEL_LINUX
> => cm3-boot-ARMEL_LINUX...tgz
> extract that on a machine with cross tools (e.g. arm-linux-gnueabi-gcc, arm-linux-gnueabi-as), possibly the same machine as already on
> cd into it
> make
> => arm cm3
> 
> 
> I got that far.
> I can't claim it is right for Android.
> 
> 
> Then put that cm3 onto a real (or emulated) ARM system and...
> (cvs checkout, put the cm3 in /cm3/bin or such, add that to $PATH, and scripts/python/boot2.sh)
> 
> 
> Moving forward to gcc 4.5 will get us atomics for ARM, sort of, at least on Linux, see:
> http://gcc.gnu.org/wiki/Atomic
> 
> 
> - Jay
> 
> ----------------------------------------
>> From: darko at darko.org
>> Date: Sat, 19 Jun 2010 02:15:17 -0700
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Linux/ARM? Android?
>> 
>> I should also mention that the Android SDK has a QEMU based emulator for testing applications and the adb (Android Bridge) tool can provide shell access.
>> 
>> 
>> On 19/06/2010, at 12:13 AM, Darko wrote:
>> 
>> I got the first Debian image on http://www.oszoo.org/wiki/index.php/Category:ARM_images to run with a GUI, and it connect to the network. I'm using Q on my 2.4Ghz MacBook 13" and it's surprisingly fast. Note that it's a 10GB image (450MB download).
>> 
>> There are also images for Debian MIPS on that site too.
>> 
>> I agree that the new MacBook trackpad is not perfect and since moving from my previous machine that had a separate button I now get a lot of stray gestures doing odd things. The general solution is not to use the button at all and use taps. The new momentum scrolling with the gesture is neat but needs more "weight". Unfortunately Apple crosses over into form-over-function territory from time to time and this is one of those times.
>> 
>> 
>> On 18/06/2010, at 11:18 PM, Jay K wrote:
>> 
>> 
>> XP when I can; nothing else comes close for searching and editing text, I've tried many.
>> Visual C++ 5.0.
>> I recently learned how to copy/paste in vi, which helps, but I'm not sure I remember now.
>> 
>> 
>> Darwin/amd64 when I need/want posix/fastfork, which unfortunately is often.
>> Cygwin is slow.
>> TextWrangler usually there, though it is awful compared to Visual C++ 5.0.
>> KomodoEdit is cross platform but also fairly impaired.
>> ssh access to a variety
>> Linux=Debian, it has among the best support for a variety of platforms.
>> Gentoo comes close or better (ppc64) but I've never been able to get it to install -- booting always fails.
>> Debian/x86 easy to get cross compiler, qemu, etc.
>> 
>> 
>> X Windows apps are never very good imho, so just give up and make do with the even worse command line..
>> I find things as basic as scrollbars do not work well -- which button do I press when?
>> The Modula-3 GUI apps suffer from this problem as well.
>> Further damage due to needing three buttons but not having them.
>> 
>> 
>> Mouse button clicking is actually broken on modern Macs too -- they removed the mouse button from all the laptops, leaving
>> just a big pad, prone to accidental clicks at any location.. also prone to accidental multitouch gestures due to resting
>> a twitchy thumb where the button is supposed to be. Amazing, really, the mouse, one of their key initial advantages,
>> is now broken. (see also Finder and file open dialogs, two other former strengths that are now not so great.)
>> Multitouch scroll is nice though.
>> 
>> 
>> - Jay
>> 
>> ----------------------------------------
>>> From: darko at darko.org
>>> Date: Fri, 18 Jun 2010 22:55:24 -0700
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>> 
>>> Yeah I've got it working on the console but I agree it needs the network.
>>> 
>>> Try: http://www.oszoo.org/wiki/index.php/Category:ARM_images
>>> Also: http://www.armedslack.org/
>>> 
>>> What platform are you running on these days?
>>> 
>>> 
>>> 
>>> 
>>> On 18/06/2010, at 10:44 PM, Jay K wrote:
>>> 
>>> 
>>> Interesting, thanks.
>>> But it looks like it needs to use local console for output?
>>> I need something over the network/X.
>>> It looks like there's an qemu option for usemode only too.
>>> 
>>> - Jay
>>> 
>>> ----------------------------------------
>>>> From: darko at darko.org
>>>> Date: Fri, 18 Jun 2010 22:13:43 -0700
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>> 
>>>> If you use qemu, this might be useful: http://free-electrons.com/community/demos/qemu-arm-directfb/
>>>> 
>>>> I'm currently looking at some cheap laptops (around $100) which have ethernet plus screen, keyboard, battery, etc which would work well as hosts. Just trying to find one that runs both Linux and Android.
>>>> 
>>>> 
>>>> On 18/06/2010, at 10:04 PM, Jay K wrote:
>>>> 
>>>> 
>>>> Thanks. I'll give qemu a go as well.
>>>> Hey, maybe we can get mips also. (there's decent modern mips/linux hardware now, Chinese laptops)
>>>> 
>>>> - Jay
>>>> 
>>>> ----------------------------------------
>>>>> From: darko at darko.org
>>>>> Date: Thu, 17 Jun 2010 21:41:59 -0700
>>>>> To: jay.krell at cornell.edu
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>> 
>>>>> Ok, the link here is about 20/4Mbs so it shouldn't be too bad and the latency is good. I'm in Mountain View, CA. Unfortunately the board has only 128MB of main memory but I assume that's enough, I think a self hosted compiler has no point.
>>>>> 
>>>>> I'll post the details when it's up and running.
>>>>> 
>>>>> 
>>>>> On 17/06/2010, at 9:15 PM, Jay K wrote:
>>>>> 
>>>>> 
>>>>> My preference would be if you can set it up on the internet and allow me ssh access.
>>>>> gcc only recently got support for Android's C library "bionic", I believe post-gcc 4.5.
>>>>> I'm not sure if that matters much or not.
>>>>> I'm not sure how much the C library of the target matters to gcc.
>>>>> 
>>>>> 
>>>>> Anything with pthreads and gcc support is quite easy to port to these days. In the past the biggest thing you had to do was rewrite /usr/include in Modula-3. There was a tendency to rewrite far more of it than necessary. These days, none of it is needed.
>>>>> 
>>>>> 
>>>>> Now you just have to
>>>>> - pick a target name
>>>>> - find the jmpbuf size, word size, endian
>>>>> - write a much small "config" file
>>>>> - respond to each error that occurs -- fill in the platform in a few tables sprinkled around the tree
>>>>> 
>>>>> 
>>>>> Even systems without pthreads or with not very good pthreads (OpenBSD) are easy now, as the user thread support is much more portable. It used to be, for user threads, you had to poke around in the jmpbuf.
>>>>> 
>>>>> 
>>>>> I would encourage anyone else to try it out.
>>>>> 
>>>>> 
>>>>> Maybe soon there will be a C generating backend, and we'll just have one distribution format that is a bunch of C, and then gcc support won't even be needed (e.g. IA64_NT).
>>>>> 
>>>>> 
>>>>> Thanks,
>>>>> - Jay
>>>>> 
>>>>> ----------------------------------------
>>>>>> From: darko at darko.org
>>>>>> Date: Thu, 17 Jun 2010 18:08:14 -0700
>>>>>> To: jay.krell at cornell.edu
>>>>>> CC: m3devel at elegosoft.com
>>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>>> 
>>>>>> I've been interested in an ARM port for some time. If you (or anyone else) are interested in doing the port I can send you one of these, which looks like a good platform since it runs Linux and Android, has 512K memory and looks well supported: http://beagleboard.org/hardware
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On 20/05/2010, at 4:47 AM, 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?
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
>> 
> 
> 
		 	   		  



From jay.krell at cornell.edu  Sun Jun 20 02:26:04 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 20 Jun 2010 00:26:04 +0000
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <6DCF6CCC-D3D3-4777-9585-243366375634@darko.org>
References: <1274350133.8902.0.camel@localhost>, , , , ,
	,,<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>, , , , ,
	,,<2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>, , , ,
	,,<COL101-W580FCB4C956AC658A851ABE6C00@phx.gbl>, , , ,
	,,<44CCDCF6-BACE-4B58-A1F5-EF68A852E2A5@darko.org>, , ,
	,,<COL101-W493D8FFD71EB43948CBE8CE6C10@phx.gbl>, , ,
	,,<B4638299-A29A-454B-9931-4F296F9AD3DB@darko.org>, ,
	,,<COL101-W7F2C05F30E9F3525E482DE6C10@phx.gbl>, ,
	,,<ED46DCAD-C84A-488C-BF6F-70CA1F24AF3B@darko.org>,
	,,<COL101-W5474F17968788325FFA76CE6C10@phx.gbl>,
	,,<5E055C3D-78F6-4C08-86D9-8B8CA86B11A1@darko.org>,
	, , <C76EF524-6048-4C61-9744-6797BBA6C552@darko.org>, ,
	<COL101-W31787A72294920C0484E63E6C10@phx.gbl>, ,
	<C1506F07-DE5E-4712-B15E-CB220A087D1A@darko.org>,
	<COL101-W29BA9D3680CFB903430A43E6C10@phx.gbl>,
	<6DCF6CCC-D3D3-4777-9585-243366375634@darko.org>
Message-ID: <COL101-W475B32E6802996894EA650E6C20@phx.gbl>


I didn't know what "lxde" is, but Debian 5.0 x86 "Lenny". Minimal install plus apt-get install whatever.

?- Jay

----------------------------------------
> From: darko at darko.org
> Date: Sat, 19 Jun 2010 17:06:11 -0700
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Linux/ARM? Android?
>
> A fully crossed system would be the goal since mostly the target devices are ARM are phones, tablets and embedded devices. What distribution are you running on QEmu? Is it the Lenny-lxde one?
>
> Linux/ARM is definitely fractured because of the variety of ARM cores, SoC chips and devices on which it's used. I'm not sure what the best way to approach it is.
>
>
> On 19/06/2010, at 4:42 PM, Jay K wrote:
>
>
> I should point out, actually, with cross gcc/as, you should be able to easily enough build the whole system cross.
> ie: your apps instead of cm3.
> I can try that -- building the whole tree cross, including compiling C and linking.
>
>
> Notice m3-sys/cminstall/src/config-no-install/ARMEL_LINUX:
>
>
> SYSTEM_CC = "arm-linux-gnueabi-gcc -gstabs+ -fPIC" % C compiler
> SYSTEM_ASM = "arm-linux-gnueabi-as" % Assembler
>
>
> I get to:
> jay at xlin2:~/cm3-boot-ARMEL_LINUX-d5.8.2-20100619$ file cm3
> cm3: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.14, not stripped
> jay at xlin2:~/cm3-boot-ARMEL_LINUX-d5.8.2-20100619$ qemu-arm ./cm3
> /lib/ld-linux.so.3: No such file or directory
>
>
> My QEmu setup isn't complete..
>
>
> I got the crosstools from hereabouts:
> http://www.emdebian.org/tools/crosstools.html
>
>
> crosstool, scratchbox, buildroot may also be good options.
>
>
> This reminds me though, I have a Western Digital MyBook World Edition.
> Haven't powered it on in a while, slightly flaky device.
> But it runs Linux/arm (oldabi).
> I could/should power it on or get a new one something.
>
>
> Also note/reminder, Android seems a bit different, at least in terms of finding C headers and libraries, maybe not for generating assembly, than "regular" Linux/arm.
> Really "Linux/arm" seems a pretty fractured thing.
> Newer architectures have floating point, for one thing.
>
>
> - Jay
>
> ----------------------------------------
>> From: darko at darko.org
>> Date: Sat, 19 Jun 2010 15:47:24 -0700
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Linux/ARM? Android?
>>
>> Fantasic, thanks. There are some ARM cross tools available under DarwinPorts which I'm going to give this a try with.
>>
>>
>> On 19/06/2010, at 2:51 AM, Jay K wrote:
>>
>>
>> Eh I guess I should try that then. Ok. Thanks. Gotta take a break for a while.
>> cd wherever
>> cvs -z3 upd -dAP
>> cd scripts/python
>> ./boot1.py ARMEL_LINUX
>> => cm3-boot-ARMEL_LINUX...tgz
>> extract that on a machine with cross tools (e.g. arm-linux-gnueabi-gcc, arm-linux-gnueabi-as), possibly the same machine as already on
>> cd into it
>> make
>> => arm cm3
>>
>>
>> I got that far.
>> I can't claim it is right for Android.
>>
>>
>> Then put that cm3 onto a real (or emulated) ARM system and...
>> (cvs checkout, put the cm3 in /cm3/bin or such, add that to $PATH, and scripts/python/boot2.sh)
>>
>>
>> Moving forward to gcc 4.5 will get us atomics for ARM, sort of, at least on Linux, see:
>> http://gcc.gnu.org/wiki/Atomic
>>
>>
>> - Jay
>>
>> ----------------------------------------
>>> From: darko at darko.org
>>> Date: Sat, 19 Jun 2010 02:15:17 -0700
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>
>>> I should also mention that the Android SDK has a QEMU based emulator for testing applications and the adb (Android Bridge) tool can provide shell access.
>>>
>>>
>>> On 19/06/2010, at 12:13 AM, Darko wrote:
>>>
>>> I got the first Debian image on http://www.oszoo.org/wiki/index.php/Category:ARM_images to run with a GUI, and it connect to the network. I'm using Q on my 2.4Ghz MacBook 13" and it's surprisingly fast. Note that it's a 10GB image (450MB download).
>>>
>>> There are also images for Debian MIPS on that site too.
>>>
>>> I agree that the new MacBook trackpad is not perfect and since moving from my previous machine that had a separate button I now get a lot of stray gestures doing odd things. The general solution is not to use the button at all and use taps. The new momentum scrolling with the gesture is neat but needs more "weight". Unfortunately Apple crosses over into form-over-function territory from time to time and this is one of those times.
>>>
>>>
>>> On 18/06/2010, at 11:18 PM, Jay K wrote:
>>>
>>>
>>> XP when I can; nothing else comes close for searching and editing text, I've tried many.
>>> Visual C++ 5.0.
>>> I recently learned how to copy/paste in vi, which helps, but I'm not sure I remember now.
>>>
>>>
>>> Darwin/amd64 when I need/want posix/fastfork, which unfortunately is often.
>>> Cygwin is slow.
>>> TextWrangler usually there, though it is awful compared to Visual C++ 5.0.
>>> KomodoEdit is cross platform but also fairly impaired.
>>> ssh access to a variety
>>> Linux=Debian, it has among the best support for a variety of platforms.
>>> Gentoo comes close or better (ppc64) but I've never been able to get it to install -- booting always fails.
>>> Debian/x86 easy to get cross compiler, qemu, etc.
>>>
>>>
>>> X Windows apps are never very good imho, so just give up and make do with the even worse command line..
>>> I find things as basic as scrollbars do not work well -- which button do I press when?
>>> The Modula-3 GUI apps suffer from this problem as well.
>>> Further damage due to needing three buttons but not having them.
>>>
>>>
>>> Mouse button clicking is actually broken on modern Macs too -- they removed the mouse button from all the laptops, leaving
>>> just a big pad, prone to accidental clicks at any location.. also prone to accidental multitouch gestures due to resting
>>> a twitchy thumb where the button is supposed to be. Amazing, really, the mouse, one of their key initial advantages,
>>> is now broken. (see also Finder and file open dialogs, two other former strengths that are now not so great.)
>>> Multitouch scroll is nice though.
>>>
>>>
>>> - Jay
>>>
>>> ----------------------------------------
>>>> From: darko at darko.org
>>>> Date: Fri, 18 Jun 2010 22:55:24 -0700
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>
>>>> Yeah I've got it working on the console but I agree it needs the network.
>>>>
>>>> Try: http://www.oszoo.org/wiki/index.php/Category:ARM_images
>>>> Also: http://www.armedslack.org/
>>>>
>>>> What platform are you running on these days?
>>>>
>>>>
>>>>
>>>>
>>>> On 18/06/2010, at 10:44 PM, Jay K wrote:
>>>>
>>>>
>>>> Interesting, thanks.
>>>> But it looks like it needs to use local console for output?
>>>> I need something over the network/X.
>>>> It looks like there's an qemu option for usemode only too.
>>>>
>>>> - Jay
>>>>
>>>> ----------------------------------------
>>>>> From: darko at darko.org
>>>>> Date: Fri, 18 Jun 2010 22:13:43 -0700
>>>>> To: jay.krell at cornell.edu
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>>
>>>>> If you use qemu, this might be useful: http://free-electrons.com/community/demos/qemu-arm-directfb/
>>>>>
>>>>> I'm currently looking at some cheap laptops (around $100) which have ethernet plus screen, keyboard, battery, etc which would work well as hosts. Just trying to find one that runs both Linux and Android.
>>>>>
>>>>>
>>>>> On 18/06/2010, at 10:04 PM, Jay K wrote:
>>>>>
>>>>>
>>>>> Thanks. I'll give qemu a go as well.
>>>>> Hey, maybe we can get mips also. (there's decent modern mips/linux hardware now, Chinese laptops)
>>>>>
>>>>> - Jay
>>>>>
>>>>> ----------------------------------------
>>>>>> From: darko at darko.org
>>>>>> Date: Thu, 17 Jun 2010 21:41:59 -0700
>>>>>> To: jay.krell at cornell.edu
>>>>>> CC: m3devel at elegosoft.com
>>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>>>
>>>>>> Ok, the link here is about 20/4Mbs so it shouldn't be too bad and the latency is good. I'm in Mountain View, CA. Unfortunately the board has only 128MB of main memory but I assume that's enough, I think a self hosted compiler has no point.
>>>>>>
>>>>>> I'll post the details when it's up and running.
>>>>>>
>>>>>>
>>>>>> On 17/06/2010, at 9:15 PM, Jay K wrote:
>>>>>>
>>>>>>
>>>>>> My preference would be if you can set it up on the internet and allow me ssh access.
>>>>>> gcc only recently got support for Android's C library "bionic", I believe post-gcc 4.5.
>>>>>> I'm not sure if that matters much or not.
>>>>>> I'm not sure how much the C library of the target matters to gcc.
>>>>>>
>>>>>>
>>>>>> Anything with pthreads and gcc support is quite easy to port to these days. In the past the biggest thing you had to do was rewrite /usr/include in Modula-3. There was a tendency to rewrite far more of it than necessary. These days, none of it is needed.
>>>>>>
>>>>>>
>>>>>> Now you just have to
>>>>>> - pick a target name
>>>>>> - find the jmpbuf size, word size, endian
>>>>>> - write a much small "config" file
>>>>>> - respond to each error that occurs -- fill in the platform in a few tables sprinkled around the tree
>>>>>>
>>>>>>
>>>>>> Even systems without pthreads or with not very good pthreads (OpenBSD) are easy now, as the user thread support is much more portable. It used to be, for user threads, you had to poke around in the jmpbuf.
>>>>>>
>>>>>>
>>>>>> I would encourage anyone else to try it out.
>>>>>>
>>>>>>
>>>>>> Maybe soon there will be a C generating backend, and we'll just have one distribution format that is a bunch of C, and then gcc support won't even be needed (e.g. IA64_NT).
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> - Jay
>>>>>>
>>>>>> ----------------------------------------
>>>>>>> From: darko at darko.org
>>>>>>> Date: Thu, 17 Jun 2010 18:08:14 -0700
>>>>>>> To: jay.krell at cornell.edu
>>>>>>> CC: m3devel at elegosoft.com
>>>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>>>>
>>>>>>> I've been interested in an ARM port for some time. If you (or anyone else) are interested in doing the port I can send you one of these, which looks like a good platform since it runs Linux and Android, has 512K memory and looks well supported: http://beagleboard.org/hardware
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 20/05/2010, at 4:47 AM, 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?
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>
 		 	   		  

From darko at darko.org  Sun Jun 20 02:30:12 2010
From: darko at darko.org (Darko)
Date: Sat, 19 Jun 2010 17:30:12 -0700
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <COL101-W475B32E6802996894EA650E6C20@phx.gbl>
References: <1274350133.8902.0.camel@localhost>, , , , , , ,
	<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>, , , , , , ,
	<2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>, , , , , ,
	<COL101-W580FCB4C956AC658A851ABE6C00@phx.gbl>, , , , , ,
	<44CCDCF6-BACE-4B58-A1F5-EF68A852E2A5@darko.org>, , , , ,
	<COL101-W493D8FFD71EB43948CBE8CE6C10@phx.gbl>, , , , ,
	<B4638299-A29A-454B-9931-4F296F9AD3DB@darko.org>, , , ,
	<COL101-W7F2C05F30E9F3525E482DE6C10@phx.gbl>, , , ,
	<ED46DCAD-C84A-488C-BF6F-70CA1F24AF3B@darko.org>, , ,
	<COL101-W5474F17968788325FFA76CE6C10@phx.gbl>, , ,
	<5E055C3D-78F6-4C08-86D9-8B8CA86B11A1@darko.org>, , ,
	<C76EF524-6048-4C61-9744-6797BBA6C552@darko.org>, ,
	<COL101-W31787A72294920C0484E63E6C10@phx.gbl>, ,
	<C1506F07-DE5E-4712-B15E-CB220A087D1A@darko.org>,
	<COL101-W29BA9D3680CFB903430A43E6C10@phx.gbl>,
	<6DCF6CCC-D3D3-4777-9585-243366375634@darko.org>
	<COL101-W475B32E6802996894EA650E6C20@phx.gbl>
Message-ID: <12B75D75-60FC-48DD-9364-2F22E04CA598@darko.org>

I mean as your ARM platform. Which ARM distribution are you running on QEmu?


On 19/06/2010, at 5:26 PM, Jay K wrote:


I didn't know what "lxde" is, but Debian 5.0 x86 "Lenny". Minimal install plus apt-get install whatever.

 - Jay

----------------------------------------
> From: darko at darko.org
> Date: Sat, 19 Jun 2010 17:06:11 -0700
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Linux/ARM? Android?
> 
> A fully crossed system would be the goal since mostly the target devices are ARM are phones, tablets and embedded devices. What distribution are you running on QEmu? Is it the Lenny-lxde one?
> 
> Linux/ARM is definitely fractured because of the variety of ARM cores, SoC chips and devices on which it's used. I'm not sure what the best way to approach it is.
> 
> 
> On 19/06/2010, at 4:42 PM, Jay K wrote:
> 
> 
> I should point out, actually, with cross gcc/as, you should be able to easily enough build the whole system cross.
> ie: your apps instead of cm3.
> I can try that -- building the whole tree cross, including compiling C and linking.
> 
> 
> Notice m3-sys/cminstall/src/config-no-install/ARMEL_LINUX:
> 
> 
> SYSTEM_CC = "arm-linux-gnueabi-gcc -gstabs+ -fPIC" % C compiler
> SYSTEM_ASM = "arm-linux-gnueabi-as" % Assembler
> 
> 
> I get to:
> jay at xlin2:~/cm3-boot-ARMEL_LINUX-d5.8.2-20100619$ file cm3
> cm3: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.14, not stripped
> jay at xlin2:~/cm3-boot-ARMEL_LINUX-d5.8.2-20100619$ qemu-arm ./cm3
> /lib/ld-linux.so.3: No such file or directory
> 
> 
> My QEmu setup isn't complete..
> 
> 
> I got the crosstools from hereabouts:
> http://www.emdebian.org/tools/crosstools.html
> 
> 
> crosstool, scratchbox, buildroot may also be good options.
> 
> 
> This reminds me though, I have a Western Digital MyBook World Edition.
> Haven't powered it on in a while, slightly flaky device.
> But it runs Linux/arm (oldabi).
> I could/should power it on or get a new one something.
> 
> 
> Also note/reminder, Android seems a bit different, at least in terms of finding C headers and libraries, maybe not for generating assembly, than "regular" Linux/arm.
> Really "Linux/arm" seems a pretty fractured thing.
> Newer architectures have floating point, for one thing.
> 
> 
> - Jay
> 
> ----------------------------------------
>> From: darko at darko.org
>> Date: Sat, 19 Jun 2010 15:47:24 -0700
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Linux/ARM? Android?
>> 
>> Fantasic, thanks. There are some ARM cross tools available under DarwinPorts which I'm going to give this a try with.
>> 
>> 
>> On 19/06/2010, at 2:51 AM, Jay K wrote:
>> 
>> 
>> Eh I guess I should try that then. Ok. Thanks. Gotta take a break for a while.
>> cd wherever
>> cvs -z3 upd -dAP
>> cd scripts/python
>> ./boot1.py ARMEL_LINUX
>> => cm3-boot-ARMEL_LINUX...tgz
>> extract that on a machine with cross tools (e.g. arm-linux-gnueabi-gcc, arm-linux-gnueabi-as), possibly the same machine as already on
>> cd into it
>> make
>> => arm cm3
>> 
>> 
>> I got that far.
>> I can't claim it is right for Android.
>> 
>> 
>> Then put that cm3 onto a real (or emulated) ARM system and...
>> (cvs checkout, put the cm3 in /cm3/bin or such, add that to $PATH, and scripts/python/boot2.sh)
>> 
>> 
>> Moving forward to gcc 4.5 will get us atomics for ARM, sort of, at least on Linux, see:
>> http://gcc.gnu.org/wiki/Atomic
>> 
>> 
>> - Jay
>> 
>> ----------------------------------------
>>> From: darko at darko.org
>>> Date: Sat, 19 Jun 2010 02:15:17 -0700
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>> 
>>> I should also mention that the Android SDK has a QEMU based emulator for testing applications and the adb (Android Bridge) tool can provide shell access.
>>> 
>>> 
>>> On 19/06/2010, at 12:13 AM, Darko wrote:
>>> 
>>> I got the first Debian image on http://www.oszoo.org/wiki/index.php/Category:ARM_images to run with a GUI, and it connect to the network. I'm using Q on my 2.4Ghz MacBook 13" and it's surprisingly fast. Note that it's a 10GB image (450MB download).
>>> 
>>> There are also images for Debian MIPS on that site too.
>>> 
>>> I agree that the new MacBook trackpad is not perfect and since moving from my previous machine that had a separate button I now get a lot of stray gestures doing odd things. The general solution is not to use the button at all and use taps. The new momentum scrolling with the gesture is neat but needs more "weight". Unfortunately Apple crosses over into form-over-function territory from time to time and this is one of those times.
>>> 
>>> 
>>> On 18/06/2010, at 11:18 PM, Jay K wrote:
>>> 
>>> 
>>> XP when I can; nothing else comes close for searching and editing text, I've tried many.
>>> Visual C++ 5.0.
>>> I recently learned how to copy/paste in vi, which helps, but I'm not sure I remember now.
>>> 
>>> 
>>> Darwin/amd64 when I need/want posix/fastfork, which unfortunately is often.
>>> Cygwin is slow.
>>> TextWrangler usually there, though it is awful compared to Visual C++ 5.0.
>>> KomodoEdit is cross platform but also fairly impaired.
>>> ssh access to a variety
>>> Linux=Debian, it has among the best support for a variety of platforms.
>>> Gentoo comes close or better (ppc64) but I've never been able to get it to install -- booting always fails.
>>> Debian/x86 easy to get cross compiler, qemu, etc.
>>> 
>>> 
>>> X Windows apps are never very good imho, so just give up and make do with the even worse command line..
>>> I find things as basic as scrollbars do not work well -- which button do I press when?
>>> The Modula-3 GUI apps suffer from this problem as well.
>>> Further damage due to needing three buttons but not having them.
>>> 
>>> 
>>> Mouse button clicking is actually broken on modern Macs too -- they removed the mouse button from all the laptops, leaving
>>> just a big pad, prone to accidental clicks at any location.. also prone to accidental multitouch gestures due to resting
>>> a twitchy thumb where the button is supposed to be. Amazing, really, the mouse, one of their key initial advantages,
>>> is now broken. (see also Finder and file open dialogs, two other former strengths that are now not so great.)
>>> Multitouch scroll is nice though.
>>> 
>>> 
>>> - Jay
>>> 
>>> ----------------------------------------
>>>> From: darko at darko.org
>>>> Date: Fri, 18 Jun 2010 22:55:24 -0700
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>> 
>>>> Yeah I've got it working on the console but I agree it needs the network.
>>>> 
>>>> Try: http://www.oszoo.org/wiki/index.php/Category:ARM_images
>>>> Also: http://www.armedslack.org/
>>>> 
>>>> What platform are you running on these days?
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On 18/06/2010, at 10:44 PM, Jay K wrote:
>>>> 
>>>> 
>>>> Interesting, thanks.
>>>> But it looks like it needs to use local console for output?
>>>> I need something over the network/X.
>>>> It looks like there's an qemu option for usemode only too.
>>>> 
>>>> - Jay
>>>> 
>>>> ----------------------------------------
>>>>> From: darko at darko.org
>>>>> Date: Fri, 18 Jun 2010 22:13:43 -0700
>>>>> To: jay.krell at cornell.edu
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>> 
>>>>> If you use qemu, this might be useful: http://free-electrons.com/community/demos/qemu-arm-directfb/
>>>>> 
>>>>> I'm currently looking at some cheap laptops (around $100) which have ethernet plus screen, keyboard, battery, etc which would work well as hosts. Just trying to find one that runs both Linux and Android.
>>>>> 
>>>>> 
>>>>> On 18/06/2010, at 10:04 PM, Jay K wrote:
>>>>> 
>>>>> 
>>>>> Thanks. I'll give qemu a go as well.
>>>>> Hey, maybe we can get mips also. (there's decent modern mips/linux hardware now, Chinese laptops)
>>>>> 
>>>>> - Jay
>>>>> 
>>>>> ----------------------------------------
>>>>>> From: darko at darko.org
>>>>>> Date: Thu, 17 Jun 2010 21:41:59 -0700
>>>>>> To: jay.krell at cornell.edu
>>>>>> CC: m3devel at elegosoft.com
>>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>>> 
>>>>>> Ok, the link here is about 20/4Mbs so it shouldn't be too bad and the latency is good. I'm in Mountain View, CA. Unfortunately the board has only 128MB of main memory but I assume that's enough, I think a self hosted compiler has no point.
>>>>>> 
>>>>>> I'll post the details when it's up and running.
>>>>>> 
>>>>>> 
>>>>>> On 17/06/2010, at 9:15 PM, Jay K wrote:
>>>>>> 
>>>>>> 
>>>>>> My preference would be if you can set it up on the internet and allow me ssh access.
>>>>>> gcc only recently got support for Android's C library "bionic", I believe post-gcc 4.5.
>>>>>> I'm not sure if that matters much or not.
>>>>>> I'm not sure how much the C library of the target matters to gcc.
>>>>>> 
>>>>>> 
>>>>>> Anything with pthreads and gcc support is quite easy to port to these days. In the past the biggest thing you had to do was rewrite /usr/include in Modula-3. There was a tendency to rewrite far more of it than necessary. These days, none of it is needed.
>>>>>> 
>>>>>> 
>>>>>> Now you just have to
>>>>>> - pick a target name
>>>>>> - find the jmpbuf size, word size, endian
>>>>>> - write a much small "config" file
>>>>>> - respond to each error that occurs -- fill in the platform in a few tables sprinkled around the tree
>>>>>> 
>>>>>> 
>>>>>> Even systems without pthreads or with not very good pthreads (OpenBSD) are easy now, as the user thread support is much more portable. It used to be, for user threads, you had to poke around in the jmpbuf.
>>>>>> 
>>>>>> 
>>>>>> I would encourage anyone else to try it out.
>>>>>> 
>>>>>> 
>>>>>> Maybe soon there will be a C generating backend, and we'll just have one distribution format that is a bunch of C, and then gcc support won't even be needed (e.g. IA64_NT).
>>>>>> 
>>>>>> 
>>>>>> Thanks,
>>>>>> - Jay
>>>>>> 
>>>>>> ----------------------------------------
>>>>>>> From: darko at darko.org
>>>>>>> Date: Thu, 17 Jun 2010 18:08:14 -0700
>>>>>>> To: jay.krell at cornell.edu
>>>>>>> CC: m3devel at elegosoft.com
>>>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>>>> 
>>>>>>> I've been interested in an ARM port for some time. If you (or anyone else) are interested in doing the port I can send you one of these, which looks like a good platform since it runs Linux and Android, has 512K memory and looks well supported: http://beagleboard.org/hardware
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On 20/05/2010, at 4:47 AM, 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?
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> 
>> 
>> 
> 
> 
		 	   		  



From jay.krell at cornell.edu  Sun Jun 20 02:33:17 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 20 Jun 2010 00:33:17 +0000
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <12B75D75-60FC-48DD-9364-2F22E04CA598@darko.org>
References: <1274350133.8902.0.camel@localhost>, , , , , ,
	,,<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>, , , , , ,
	,,<2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>, , , , ,
	,,<COL101-W580FCB4C956AC658A851ABE6C00@phx.gbl>, , , , ,
	,,<44CCDCF6-BACE-4B58-A1F5-EF68A852E2A5@darko.org>, , , ,
	,,<COL101-W493D8FFD71EB43948CBE8CE6C10@phx.gbl>, , , ,
	,,<B4638299-A29A-454B-9931-4F296F9AD3DB@darko.org>, , ,
	,,<COL101-W7F2C05F30E9F3525E482DE6C10@phx.gbl>, , ,
	,,<ED46DCAD-C84A-488C-BF6F-70CA1F24AF3B@darko.org>, ,
	,,<COL101-W5474F17968788325FFA76CE6C10@phx.gbl>, ,
	,,<5E055C3D-78F6-4C08-86D9-8B8CA86B11A1@darko.org>, ,
	,,<C76EF524-6048-4C61-9744-6797BBA6C552@darko.org>,
	,,<COL101-W31787A72294920C0484E63E6C10@phx.gbl>,
	, , <C1506F07-DE5E-4712-B15E-CB220A087D1A@darko.org>, ,
	<COL101-W29BA9D3680CFB903430A43E6C10@phx.gbl>, ,
	<6DCF6CCC-D3D3-4777-9585-243366375634@darko.org>,
	<COL101-W475B32E6802996894EA650E6C20@phx.gbl>,
	<12B75D75-60FC-48DD-9364-2F22E04CA598@darko.org>
Message-ID: <COL101-W197BF4F7E1E4A1A24B1469E6C20@phx.gbl>


None?
None yet?
You are supposed to be able run user mode stuff without installing any kernel or anything.
If I emulate an entire system, can the display be remoted over X?
I never go to the Linux "console", just ssh or X over ssh.

?- Jay

----------------------------------------
> From: darko at darko.org
> Date: Sat, 19 Jun 2010 17:30:12 -0700
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Linux/ARM? Android?
>
> I mean as your ARM platform. Which ARM distribution are you running on QEmu?
>
>
> On 19/06/2010, at 5:26 PM, Jay K wrote:
>
>
> I didn't know what "lxde" is, but Debian 5.0 x86 "Lenny". Minimal install plus apt-get install whatever.
>
> - Jay
>
> ----------------------------------------
>> From: darko at darko.org
>> Date: Sat, 19 Jun 2010 17:06:11 -0700
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Linux/ARM? Android?
>>
>> A fully crossed system would be the goal since mostly the target devices are ARM are phones, tablets and embedded devices. What distribution are you running on QEmu? Is it the Lenny-lxde one?
>>
>> Linux/ARM is definitely fractured because of the variety of ARM cores, SoC chips and devices on which it's used. I'm not sure what the best way to approach it is.
>>
>>
>> On 19/06/2010, at 4:42 PM, Jay K wrote:
>>
>>
>> I should point out, actually, with cross gcc/as, you should be able to easily enough build the whole system cross.
>> ie: your apps instead of cm3.
>> I can try that -- building the whole tree cross, including compiling C and linking.
>>
>>
>> Notice m3-sys/cminstall/src/config-no-install/ARMEL_LINUX:
>>
>>
>> SYSTEM_CC = "arm-linux-gnueabi-gcc -gstabs+ -fPIC" % C compiler
>> SYSTEM_ASM = "arm-linux-gnueabi-as" % Assembler
>>
>>
>> I get to:
>> jay at xlin2:~/cm3-boot-ARMEL_LINUX-d5.8.2-20100619$ file cm3
>> cm3: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.14, not stripped
>> jay at xlin2:~/cm3-boot-ARMEL_LINUX-d5.8.2-20100619$ qemu-arm ./cm3
>> /lib/ld-linux.so.3: No such file or directory
>>
>>
>> My QEmu setup isn't complete..
>>
>>
>> I got the crosstools from hereabouts:
>> http://www.emdebian.org/tools/crosstools.html
>>
>>
>> crosstool, scratchbox, buildroot may also be good options.
>>
>>
>> This reminds me though, I have a Western Digital MyBook World Edition.
>> Haven't powered it on in a while, slightly flaky device.
>> But it runs Linux/arm (oldabi).
>> I could/should power it on or get a new one something.
>>
>>
>> Also note/reminder, Android seems a bit different, at least in terms of finding C headers and libraries, maybe not for generating assembly, than "regular" Linux/arm.
>> Really "Linux/arm" seems a pretty fractured thing.
>> Newer architectures have floating point, for one thing.
>>
>>
>> - Jay
>>
>> ----------------------------------------
>>> From: darko at darko.org
>>> Date: Sat, 19 Jun 2010 15:47:24 -0700
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>
>>> Fantasic, thanks. There are some ARM cross tools available under DarwinPorts which I'm going to give this a try with.
>>>
>>>
>>> On 19/06/2010, at 2:51 AM, Jay K wrote:
>>>
>>>
>>> Eh I guess I should try that then. Ok. Thanks. Gotta take a break for a while.
>>> cd wherever
>>> cvs -z3 upd -dAP
>>> cd scripts/python
>>> ./boot1.py ARMEL_LINUX
>>> => cm3-boot-ARMEL_LINUX...tgz
>>> extract that on a machine with cross tools (e.g. arm-linux-gnueabi-gcc, arm-linux-gnueabi-as), possibly the same machine as already on
>>> cd into it
>>> make
>>> => arm cm3
>>>
>>>
>>> I got that far.
>>> I can't claim it is right for Android.
>>>
>>>
>>> Then put that cm3 onto a real (or emulated) ARM system and...
>>> (cvs checkout, put the cm3 in /cm3/bin or such, add that to $PATH, and scripts/python/boot2.sh)
>>>
>>>
>>> Moving forward to gcc 4.5 will get us atomics for ARM, sort of, at least on Linux, see:
>>> http://gcc.gnu.org/wiki/Atomic
>>>
>>>
>>> - Jay
>>>
>>> ----------------------------------------
>>>> From: darko at darko.org
>>>> Date: Sat, 19 Jun 2010 02:15:17 -0700
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>
>>>> I should also mention that the Android SDK has a QEMU based emulator for testing applications and the adb (Android Bridge) tool can provide shell access.
>>>>
>>>>
>>>> On 19/06/2010, at 12:13 AM, Darko wrote:
>>>>
>>>> I got the first Debian image on http://www.oszoo.org/wiki/index.php/Category:ARM_images to run with a GUI, and it connect to the network. I'm using Q on my 2.4Ghz MacBook 13" and it's surprisingly fast. Note that it's a 10GB image (450MB download).
>>>>
>>>> There are also images for Debian MIPS on that site too.
>>>>
>>>> I agree that the new MacBook trackpad is not perfect and since moving from my previous machine that had a separate button I now get a lot of stray gestures doing odd things. The general solution is not to use the button at all and use taps. The new momentum scrolling with the gesture is neat but needs more "weight". Unfortunately Apple crosses over into form-over-function territory from time to time and this is one of those times.
>>>>
>>>>
>>>> On 18/06/2010, at 11:18 PM, Jay K wrote:
>>>>
>>>>
>>>> XP when I can; nothing else comes close for searching and editing text, I've tried many.
>>>> Visual C++ 5.0.
>>>> I recently learned how to copy/paste in vi, which helps, but I'm not sure I remember now.
>>>>
>>>>
>>>> Darwin/amd64 when I need/want posix/fastfork, which unfortunately is often.
>>>> Cygwin is slow.
>>>> TextWrangler usually there, though it is awful compared to Visual C++ 5.0.
>>>> KomodoEdit is cross platform but also fairly impaired.
>>>> ssh access to a variety
>>>> Linux=Debian, it has among the best support for a variety of platforms.
>>>> Gentoo comes close or better (ppc64) but I've never been able to get it to install -- booting always fails.
>>>> Debian/x86 easy to get cross compiler, qemu, etc.
>>>>
>>>>
>>>> X Windows apps are never very good imho, so just give up and make do with the even worse command line..
>>>> I find things as basic as scrollbars do not work well -- which button do I press when?
>>>> The Modula-3 GUI apps suffer from this problem as well.
>>>> Further damage due to needing three buttons but not having them.
>>>>
>>>>
>>>> Mouse button clicking is actually broken on modern Macs too -- they removed the mouse button from all the laptops, leaving
>>>> just a big pad, prone to accidental clicks at any location.. also prone to accidental multitouch gestures due to resting
>>>> a twitchy thumb where the button is supposed to be. Amazing, really, the mouse, one of their key initial advantages,
>>>> is now broken. (see also Finder and file open dialogs, two other former strengths that are now not so great.)
>>>> Multitouch scroll is nice though.
>>>>
>>>>
>>>> - Jay
>>>>
>>>> ----------------------------------------
>>>>> From: darko at darko.org
>>>>> Date: Fri, 18 Jun 2010 22:55:24 -0700
>>>>> To: jay.krell at cornell.edu
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>>
>>>>> Yeah I've got it working on the console but I agree it needs the network.
>>>>>
>>>>> Try: http://www.oszoo.org/wiki/index.php/Category:ARM_images
>>>>> Also: http://www.armedslack.org/
>>>>>
>>>>> What platform are you running on these days?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 18/06/2010, at 10:44 PM, Jay K wrote:
>>>>>
>>>>>
>>>>> Interesting, thanks.
>>>>> But it looks like it needs to use local console for output?
>>>>> I need something over the network/X.
>>>>> It looks like there's an qemu option for usemode only too.
>>>>>
>>>>> - Jay
>>>>>
>>>>> ----------------------------------------
>>>>>> From: darko at darko.org
>>>>>> Date: Fri, 18 Jun 2010 22:13:43 -0700
>>>>>> To: jay.krell at cornell.edu
>>>>>> CC: m3devel at elegosoft.com
>>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>>>
>>>>>> If you use qemu, this might be useful: http://free-electrons.com/community/demos/qemu-arm-directfb/
>>>>>>
>>>>>> I'm currently looking at some cheap laptops (around $100) which have ethernet plus screen, keyboard, battery, etc which would work well as hosts. Just trying to find one that runs both Linux and Android.
>>>>>>
>>>>>>
>>>>>> On 18/06/2010, at 10:04 PM, Jay K wrote:
>>>>>>
>>>>>>
>>>>>> Thanks. I'll give qemu a go as well.
>>>>>> Hey, maybe we can get mips also. (there's decent modern mips/linux hardware now, Chinese laptops)
>>>>>>
>>>>>> - Jay
>>>>>>
>>>>>> ----------------------------------------
>>>>>>> From: darko at darko.org
>>>>>>> Date: Thu, 17 Jun 2010 21:41:59 -0700
>>>>>>> To: jay.krell at cornell.edu
>>>>>>> CC: m3devel at elegosoft.com
>>>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>>>>
>>>>>>> Ok, the link here is about 20/4Mbs so it shouldn't be too bad and the latency is good. I'm in Mountain View, CA. Unfortunately the board has only 128MB of main memory but I assume that's enough, I think a self hosted compiler has no point.
>>>>>>>
>>>>>>> I'll post the details when it's up and running.
>>>>>>>
>>>>>>>
>>>>>>> On 17/06/2010, at 9:15 PM, Jay K wrote:
>>>>>>>
>>>>>>>
>>>>>>> My preference would be if you can set it up on the internet and allow me ssh access.
>>>>>>> gcc only recently got support for Android's C library "bionic", I believe post-gcc 4.5.
>>>>>>> I'm not sure if that matters much or not.
>>>>>>> I'm not sure how much the C library of the target matters to gcc.
>>>>>>>
>>>>>>>
>>>>>>> Anything with pthreads and gcc support is quite easy to port to these days. In the past the biggest thing you had to do was rewrite /usr/include in Modula-3. There was a tendency to rewrite far more of it than necessary. These days, none of it is needed.
>>>>>>>
>>>>>>>
>>>>>>> Now you just have to
>>>>>>> - pick a target name
>>>>>>> - find the jmpbuf size, word size, endian
>>>>>>> - write a much small "config" file
>>>>>>> - respond to each error that occurs -- fill in the platform in a few tables sprinkled around the tree
>>>>>>>
>>>>>>>
>>>>>>> Even systems without pthreads or with not very good pthreads (OpenBSD) are easy now, as the user thread support is much more portable. It used to be, for user threads, you had to poke around in the jmpbuf.
>>>>>>>
>>>>>>>
>>>>>>> I would encourage anyone else to try it out.
>>>>>>>
>>>>>>>
>>>>>>> Maybe soon there will be a C generating backend, and we'll just have one distribution format that is a bunch of C, and then gcc support won't even be needed (e.g. IA64_NT).
>>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>> - Jay
>>>>>>>
>>>>>>> ----------------------------------------
>>>>>>>> From: darko at darko.org
>>>>>>>> Date: Thu, 17 Jun 2010 18:08:14 -0700
>>>>>>>> To: jay.krell at cornell.edu
>>>>>>>> CC: m3devel at elegosoft.com
>>>>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>>>>>
>>>>>>>> I've been interested in an ARM port for some time. If you (or anyone else) are interested in doing the port I can send you one of these, which looks like a good platform since it runs Linux and Android, has 512K memory and looks well supported: http://beagleboard.org/hardware
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 20/05/2010, at 4:47 AM, 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?
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
 		 	   		  

From darko at darko.org  Sun Jun 20 02:37:50 2010
From: darko at darko.org (Darko)
Date: Sat, 19 Jun 2010 17:37:50 -0700
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <COL101-W197BF4F7E1E4A1A24B1469E6C20@phx.gbl>
References: <1274350133.8902.0.camel@localhost>, , , , , , , ,
	<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>, , , , , , , ,
	<2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>, , , , , , ,
	<COL101-W580FCB4C956AC658A851ABE6C00@phx.gbl>, , , , , , ,
	<44CCDCF6-BACE-4B58-A1F5-EF68A852E2A5@darko.org>, , , , , ,
	<COL101-W493D8FFD71EB43948CBE8CE6C10@phx.gbl>, , , , , ,
	<B4638299-A29A-454B-9931-4F296F9AD3DB@darko.org>, , , , ,
	<COL101-W7F2C05F30E9F3525E482DE6C10@phx.gbl>, , , , ,
	<ED46DCAD-C84A-488C-BF6F-70CA1F24AF3B@darko.org>, , , ,
	<COL101-W5474F17968788325FFA76CE6C10@phx.gbl>, , , ,
	<5E055C3D-78F6-4C08-86D9-8B8CA86B11A1@darko.org>, , , ,
	<C76EF524-6048-4C61-9744-6797BBA6C552@darko.org>, , ,
	<COL101-W31787A72294920C0484E63E6C10@phx.gbl>, , ,
	<C1506F07-DE5E-4712-B15E-CB220A087D1A@darko.org>, ,
	<COL101-W29BA9D3680CFB903430A43E6C10@phx.gbl>, ,
	<6DCF6CCC-D3D3-4777-9585-243366375634@darko.org>,
	<COL101-W475B32E6802996894EA650E6C20@phx.gbl>,
	<12B75D75-60FC-48DD-9364-2F22E04CA598@darko.org>
	<COL101-W197BF4F7E1E4A1A24B1469 E6C20@phx.gbl>
Message-ID: <2DCB0C6D-D4AF-46B0-B24A-2D4F257C0696@darko.org>

This one runs X and sshd straight out of the box, on QEmu: http://www.oszoo.org/wiki/index.php/Debian_Lenny_Arm_%28Armel%29_-_with_lxde


On 19/06/2010, at 5:33 PM, Jay K wrote:


None?
None yet?
You are supposed to be able run user mode stuff without installing any kernel or anything.
If I emulate an entire system, can the display be remoted over X?
I never go to the Linux "console", just ssh or X over ssh.

 - Jay

----------------------------------------
> From: darko at darko.org
> Date: Sat, 19 Jun 2010 17:30:12 -0700
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Linux/ARM? Android?
> 
> I mean as your ARM platform. Which ARM distribution are you running on QEmu?
> 
> 
> On 19/06/2010, at 5:26 PM, Jay K wrote:
> 
> 
> I didn't know what "lxde" is, but Debian 5.0 x86 "Lenny". Minimal install plus apt-get install whatever.
> 
> - Jay
> 
> ----------------------------------------
>> From: darko at darko.org
>> Date: Sat, 19 Jun 2010 17:06:11 -0700
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Linux/ARM? Android?
>> 
>> A fully crossed system would be the goal since mostly the target devices are ARM are phones, tablets and embedded devices. What distribution are you running on QEmu? Is it the Lenny-lxde one?
>> 
>> Linux/ARM is definitely fractured because of the variety of ARM cores, SoC chips and devices on which it's used. I'm not sure what the best way to approach it is.
>> 
>> 
>> On 19/06/2010, at 4:42 PM, Jay K wrote:
>> 
>> 
>> I should point out, actually, with cross gcc/as, you should be able to easily enough build the whole system cross.
>> ie: your apps instead of cm3.
>> I can try that -- building the whole tree cross, including compiling C and linking.
>> 
>> 
>> Notice m3-sys/cminstall/src/config-no-install/ARMEL_LINUX:
>> 
>> 
>> SYSTEM_CC = "arm-linux-gnueabi-gcc -gstabs+ -fPIC" % C compiler
>> SYSTEM_ASM = "arm-linux-gnueabi-as" % Assembler
>> 
>> 
>> I get to:
>> jay at xlin2:~/cm3-boot-ARMEL_LINUX-d5.8.2-20100619$ file cm3
>> cm3: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.14, not stripped
>> jay at xlin2:~/cm3-boot-ARMEL_LINUX-d5.8.2-20100619$ qemu-arm ./cm3
>> /lib/ld-linux.so.3: No such file or directory
>> 
>> 
>> My QEmu setup isn't complete..
>> 
>> 
>> I got the crosstools from hereabouts:
>> http://www.emdebian.org/tools/crosstools.html
>> 
>> 
>> crosstool, scratchbox, buildroot may also be good options.
>> 
>> 
>> This reminds me though, I have a Western Digital MyBook World Edition.
>> Haven't powered it on in a while, slightly flaky device.
>> But it runs Linux/arm (oldabi).
>> I could/should power it on or get a new one something.
>> 
>> 
>> Also note/reminder, Android seems a bit different, at least in terms of finding C headers and libraries, maybe not for generating assembly, than "regular" Linux/arm.
>> Really "Linux/arm" seems a pretty fractured thing.
>> Newer architectures have floating point, for one thing.
>> 
>> 
>> - Jay
>> 
>> ----------------------------------------
>>> From: darko at darko.org
>>> Date: Sat, 19 Jun 2010 15:47:24 -0700
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>> 
>>> Fantasic, thanks. There are some ARM cross tools available under DarwinPorts which I'm going to give this a try with.
>>> 
>>> 
>>> On 19/06/2010, at 2:51 AM, Jay K wrote:
>>> 
>>> 
>>> Eh I guess I should try that then. Ok. Thanks. Gotta take a break for a while.
>>> cd wherever
>>> cvs -z3 upd -dAP
>>> cd scripts/python
>>> ./boot1.py ARMEL_LINUX
>>> => cm3-boot-ARMEL_LINUX...tgz
>>> extract that on a machine with cross tools (e.g. arm-linux-gnueabi-gcc, arm-linux-gnueabi-as), possibly the same machine as already on
>>> cd into it
>>> make
>>> => arm cm3
>>> 
>>> 
>>> I got that far.
>>> I can't claim it is right for Android.
>>> 
>>> 
>>> Then put that cm3 onto a real (or emulated) ARM system and...
>>> (cvs checkout, put the cm3 in /cm3/bin or such, add that to $PATH, and scripts/python/boot2.sh)
>>> 
>>> 
>>> Moving forward to gcc 4.5 will get us atomics for ARM, sort of, at least on Linux, see:
>>> http://gcc.gnu.org/wiki/Atomic
>>> 
>>> 
>>> - Jay
>>> 
>>> ----------------------------------------
>>>> From: darko at darko.org
>>>> Date: Sat, 19 Jun 2010 02:15:17 -0700
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>> 
>>>> I should also mention that the Android SDK has a QEMU based emulator for testing applications and the adb (Android Bridge) tool can provide shell access.
>>>> 
>>>> 
>>>> On 19/06/2010, at 12:13 AM, Darko wrote:
>>>> 
>>>> I got the first Debian image on http://www.oszoo.org/wiki/index.php/Category:ARM_images to run with a GUI, and it connect to the network. I'm using Q on my 2.4Ghz MacBook 13" and it's surprisingly fast. Note that it's a 10GB image (450MB download).
>>>> 
>>>> There are also images for Debian MIPS on that site too.
>>>> 
>>>> I agree that the new MacBook trackpad is not perfect and since moving from my previous machine that had a separate button I now get a lot of stray gestures doing odd things. The general solution is not to use the button at all and use taps. The new momentum scrolling with the gesture is neat but needs more "weight". Unfortunately Apple crosses over into form-over-function territory from time to time and this is one of those times.
>>>> 
>>>> 
>>>> On 18/06/2010, at 11:18 PM, Jay K wrote:
>>>> 
>>>> 
>>>> XP when I can; nothing else comes close for searching and editing text, I've tried many.
>>>> Visual C++ 5.0.
>>>> I recently learned how to copy/paste in vi, which helps, but I'm not sure I remember now.
>>>> 
>>>> 
>>>> Darwin/amd64 when I need/want posix/fastfork, which unfortunately is often.
>>>> Cygwin is slow.
>>>> TextWrangler usually there, though it is awful compared to Visual C++ 5.0.
>>>> KomodoEdit is cross platform but also fairly impaired.
>>>> ssh access to a variety
>>>> Linux=Debian, it has among the best support for a variety of platforms.
>>>> Gentoo comes close or better (ppc64) but I've never been able to get it to install -- booting always fails.
>>>> Debian/x86 easy to get cross compiler, qemu, etc.
>>>> 
>>>> 
>>>> X Windows apps are never very good imho, so just give up and make do with the even worse command line..
>>>> I find things as basic as scrollbars do not work well -- which button do I press when?
>>>> The Modula-3 GUI apps suffer from this problem as well.
>>>> Further damage due to needing three buttons but not having them.
>>>> 
>>>> 
>>>> Mouse button clicking is actually broken on modern Macs too -- they removed the mouse button from all the laptops, leaving
>>>> just a big pad, prone to accidental clicks at any location.. also prone to accidental multitouch gestures due to resting
>>>> a twitchy thumb where the button is supposed to be. Amazing, really, the mouse, one of their key initial advantages,
>>>> is now broken. (see also Finder and file open dialogs, two other former strengths that are now not so great.)
>>>> Multitouch scroll is nice though.
>>>> 
>>>> 
>>>> - Jay
>>>> 
>>>> ----------------------------------------
>>>>> From: darko at darko.org
>>>>> Date: Fri, 18 Jun 2010 22:55:24 -0700
>>>>> To: jay.krell at cornell.edu
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>> 
>>>>> Yeah I've got it working on the console but I agree it needs the network.
>>>>> 
>>>>> Try: http://www.oszoo.org/wiki/index.php/Category:ARM_images
>>>>> Also: http://www.armedslack.org/
>>>>> 
>>>>> What platform are you running on these days?
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On 18/06/2010, at 10:44 PM, Jay K wrote:
>>>>> 
>>>>> 
>>>>> Interesting, thanks.
>>>>> But it looks like it needs to use local console for output?
>>>>> I need something over the network/X.
>>>>> It looks like there's an qemu option for usemode only too.
>>>>> 
>>>>> - Jay
>>>>> 
>>>>> ----------------------------------------
>>>>>> From: darko at darko.org
>>>>>> Date: Fri, 18 Jun 2010 22:13:43 -0700
>>>>>> To: jay.krell at cornell.edu
>>>>>> CC: m3devel at elegosoft.com
>>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>>> 
>>>>>> If you use qemu, this might be useful: http://free-electrons.com/community/demos/qemu-arm-directfb/
>>>>>> 
>>>>>> I'm currently looking at some cheap laptops (around $100) which have ethernet plus screen, keyboard, battery, etc which would work well as hosts. Just trying to find one that runs both Linux and Android.
>>>>>> 
>>>>>> 
>>>>>> On 18/06/2010, at 10:04 PM, Jay K wrote:
>>>>>> 
>>>>>> 
>>>>>> Thanks. I'll give qemu a go as well.
>>>>>> Hey, maybe we can get mips also. (there's decent modern mips/linux hardware now, Chinese laptops)
>>>>>> 
>>>>>> - Jay
>>>>>> 
>>>>>> ----------------------------------------
>>>>>>> From: darko at darko.org
>>>>>>> Date: Thu, 17 Jun 2010 21:41:59 -0700
>>>>>>> To: jay.krell at cornell.edu
>>>>>>> CC: m3devel at elegosoft.com
>>>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>>>> 
>>>>>>> Ok, the link here is about 20/4Mbs so it shouldn't be too bad and the latency is good. I'm in Mountain View, CA. Unfortunately the board has only 128MB of main memory but I assume that's enough, I think a self hosted compiler has no point.
>>>>>>> 
>>>>>>> I'll post the details when it's up and running.
>>>>>>> 
>>>>>>> 
>>>>>>> On 17/06/2010, at 9:15 PM, Jay K wrote:
>>>>>>> 
>>>>>>> 
>>>>>>> My preference would be if you can set it up on the internet and allow me ssh access.
>>>>>>> gcc only recently got support for Android's C library "bionic", I believe post-gcc 4.5.
>>>>>>> I'm not sure if that matters much or not.
>>>>>>> I'm not sure how much the C library of the target matters to gcc.
>>>>>>> 
>>>>>>> 
>>>>>>> Anything with pthreads and gcc support is quite easy to port to these days. In the past the biggest thing you had to do was rewrite /usr/include in Modula-3. There was a tendency to rewrite far more of it than necessary. These days, none of it is needed.
>>>>>>> 
>>>>>>> 
>>>>>>> Now you just have to
>>>>>>> - pick a target name
>>>>>>> - find the jmpbuf size, word size, endian
>>>>>>> - write a much small "config" file
>>>>>>> - respond to each error that occurs -- fill in the platform in a few tables sprinkled around the tree
>>>>>>> 
>>>>>>> 
>>>>>>> Even systems without pthreads or with not very good pthreads (OpenBSD) are easy now, as the user thread support is much more portable. It used to be, for user threads, you had to poke around in the jmpbuf.
>>>>>>> 
>>>>>>> 
>>>>>>> I would encourage anyone else to try it out.
>>>>>>> 
>>>>>>> 
>>>>>>> Maybe soon there will be a C generating backend, and we'll just have one distribution format that is a bunch of C, and then gcc support won't even be needed (e.g. IA64_NT).
>>>>>>> 
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> - Jay
>>>>>>> 
>>>>>>> ----------------------------------------
>>>>>>>> From: darko at darko.org
>>>>>>>> Date: Thu, 17 Jun 2010 18:08:14 -0700
>>>>>>>> To: jay.krell at cornell.edu
>>>>>>>> CC: m3devel at elegosoft.com
>>>>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>>>>> 
>>>>>>>> I've been interested in an ARM port for some time. If you (or anyone else) are interested in doing the port I can send you one of these, which looks like a good platform since it runs Linux and Android, has 512K memory and looks well supported: http://beagleboard.org/hardware
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On 20/05/2010, at 4:47 AM, 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?
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
> 
> 
		 	   		  



From jay.krell at cornell.edu  Sun Jun 20 04:07:21 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 20 Jun 2010 02:07:21 +0000
Subject: [M3devel] div/mod gcc builtin vs. m3core function
Message-ID: <COL101-W19658E57C608B58952727CE6C20@phx.gbl>


So..I'm debugging why 64bit mod on ARM doesn't work..changed the C compiler to use floor instead of trunc, see if it fails..see what it does.
? If it fails, I could report that as a bug.


Now, I'm nervous.
I'm nervous that gcc might sometimes use libgcc functions for div or mod, with the assumption that trunc is needed.
This would clearly be a bug in gcc.
But I'm nervous.

The implementation of div/mod varies a lot -- sometimes a function call in gcc, sometimes not.

I tested some architectures at the time..but I wonder now.

Maybe safest to just always use our functions?

I might try to prove gcc does it wrong, e.g. for ARM, with a modified C front end..but so far I can't run ARM code.

Thoughts?


jbook2:gcc jay$ grep sdiv_optab? */*/*/* 
gcc/config/alpha/alpha.c:????? set_optab_libfunc (sdiv_optab, SImode, 0);
gcc/config/alpha/alpha.c:????? set_optab_libfunc (sdiv_optab, DImode, "$sldiv");
gcc/config/alpha/alpha.c:????? set_optab_libfunc (sdiv_optab, SImode, "OTS$DIV_I");
gcc/config/alpha/alpha.c:????? set_optab_libfunc (sdiv_optab, DImode, "OTS$DIV_L");
gcc/config/alpha/alpha.md:? div = expand_binop (DImode, sdiv_optab, operands[1], operands[2],
gcc/config/arm/arm.c:? set_optab_libfunc (sdiv_optab, DFmode, "__aeabi_ddiv");
gcc/config/arm/arm.c:? set_optab_libfunc (sdiv_optab, SFmode, "__aeabi_fdiv");
gcc/config/arm/arm.c:? set_optab_libfunc (sdiv_optab, DImode, "__aeabi_ldivmod");
gcc/config/arm/arm.c:? set_optab_libfunc (sdiv_optab, SImode, "__aeabi_idiv");
gcc/config/cris/cris.c:? set_optab_libfunc (sdiv_optab, SImode, "__Div");
gcc/config/frv/frv.c:? set_optab_libfunc (sdiv_optab,???? DImode, "__divll");
gcc/config/frv/frv.c:? set_optab_libfunc (sdiv_optab,???? SFmode, "__divf");
gcc/config/frv/frv.c:? set_optab_libfunc (sdiv_optab,???? DFmode, "__divd");
gcc/config/h8300/h8300.c:? set_optab_libfunc (sdiv_optab, HImode, "__divhi3");
gcc/config/ia64/ia64.c:? set_optab_libfunc (sdiv_optab, SImode, "__divsi3");
gcc/config/ia64/ia64.c:? set_optab_libfunc (sdiv_optab, TFmode, "_U_Qfdiv");
gcc/config/ia64/ia64.c:? set_optab_libfunc (sdiv_optab, SImode, 0);
gcc/config/ia64/ia64.c:? set_optab_libfunc (sdiv_optab, DImode, "__milli_divI");
gcc/config/ia64/ia64.c:? set_optab_libfunc (sdiv_optab, SImode, "OTS$DIV_I");
gcc/config/ia64/ia64.c:? set_optab_libfunc (sdiv_optab, DImode, "OTS$DIV_L");
gcc/config/mips/mips.c:????? set_optab_libfunc (sdiv_optab, SImode, "__vr4120_divsi3");
gcc/config/mips/mips.c:????? set_optab_libfunc (sdiv_optab, SFmode, "__mips16_divsf3");
gcc/config/mips/mips.c:??? ? set_optab_libfunc (sdiv_optab, DFmode, "__mips16_divdf3");
gcc/config/pa/pa.c:? set_optab_libfunc (sdiv_optab, TFmode, "_U_Qfdiv");
gcc/config/rs6000/rs6000.c:??? set_optab_libfunc (sdiv_optab, TFmode, "__gcc_qdiv");
gcc/config/rs6000/rs6000.c:??? set_optab_libfunc (sdiv_optab, TFmode, "_xlqdiv");
gcc/config/rs6000/rs6000.c:????? set_optab_libfunc (sdiv_optab, TFmode, "_q_div");
gcc/config/sparc/sparc.c:????? set_optab_libfunc (sdiv_optab, SImode, "*.div");
gcc/config/sparc/sparc.c:????? set_optab_libfunc (sdiv_optab, TFmode, "_Q_div");
gcc/config/sparc/sparc.c:????? set_optab_libfunc (sdiv_optab, SImode, 0);
gcc/config/sparc/sparc.c:??? ? set_optab_libfunc (sdiv_optab, DImode, "__div64");
gcc/config/spu/spu.c:? set_optab_libfunc (sdiv_optab, DImode, "__divdi3");
j



?- Jay




 		 	   		  

From dabenavidesd at yahoo.es  Sun Jun 20 05:17:03 2010
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Sun, 20 Jun 2010 03:17:03 +0000 (GMT)
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <COL101-W197BF4F7E1E4A1A24B1469E6C20@phx.gbl>
Message-ID: <847521.56337.qm@web23602.mail.ird.yahoo.com>

Hi:
yes, you can if you wish, that is, you can redirect the x window session and get access through a host different port (see info below) from a new x client or even forwarding x over a ssh session or separated (ideal if you wish), I haven't  tried to do it (I have old hardware, I guess you should be able to virtualize some very decent and cheap system as see below SuSE article points out) but you should be able to do that. Please see this article for the first (the qemu-system- -redir command option):
http://www.ibm.com/developerworks/opensource/library/l-qemu-development/index.html?ca=drs-
you can select the window manager you wish I remember a friend used to talk about WindowMaker he said it was very cheap in terms of RAM and it allowed to do your work just out of the box (he had a very old i486 laptop with it I guess with < 64 MB RAM just to monitor other servers).
There is a bright idea about clustering with OpenMosix (which used to work years ago now there is http://en.wikipedia.org/wiki/LinuxPMI for that purpose) using QEMU, see this old article http://www.novell.com/coolsolutions/feature/14951.html 
you might get some old machines back into life with a net interface in a cluster and mount your disk too.
Hope it helps.

 

--- El s?b, 19/6/10, Jay K <jay.krell at cornell.edu> escribi?:

> De: Jay K <jay.krell at cornell.edu>
> Asunto: Re: [M3devel] Linux/ARM? Android?
> Para: "Darko (M3)" <darko at darko.org>
> CC: "m3devel" <m3devel at elegosoft.com>
> Fecha: s?bado, 19 de junio, 2010 19:33
> 
> None?
> None yet?
> You are supposed to be able run user mode stuff without
> installing any kernel or anything.
> If I emulate an entire system, can the display be remoted
> over X?
> I never go to the Linux "console", just ssh or X over ssh.
> 
>  - Jay
> 
> ----------------------------------------
> > From: darko at darko.org
> > Date: Sat, 19 Jun 2010 17:30:12 -0700
> > To: jay.krell at cornell.edu
> > CC: m3devel at elegosoft.com
> > Subject: Re: [M3devel] Linux/ARM? Android?
> >
> > I mean as your ARM platform. Which ARM distribution
> are you running on QEmu?
> >
> >
> > On 19/06/2010, at 5:26 PM, Jay K wrote:
> >
> >
> > I didn't know what "lxde" is, but Debian 5.0 x86
> "Lenny". Minimal install plus apt-get install whatever.
> >
> > - Jay
> >
> > ----------------------------------------
> >> From: darko at darko.org
> >> Date: Sat, 19 Jun 2010 17:06:11 -0700
> >> To: jay.krell at cornell.edu
> >> CC: m3devel at elegosoft.com
> >> Subject: Re: [M3devel] Linux/ARM? Android?
> >>
> >> A fully crossed system would be the goal since
> mostly the target devices are ARM are phones, tablets and
> embedded devices. What distribution are you running on QEmu?
> Is it the Lenny-lxde one?
> >>
> >> Linux/ARM is definitely fractured because of the
> variety of ARM cores, SoC chips and devices on which it's
> used. I'm not sure what the best way to approach it is.
> >>
> >>
> >> On 19/06/2010, at 4:42 PM, Jay K wrote:
> >>
> >>
> >> I should point out, actually, with cross gcc/as,
> you should be able to easily enough build the whole system
> cross.
> >> ie: your apps instead of cm3.
> >> I can try that -- building the whole tree cross,
> including compiling C and linking.
> >>
> >>
> >> Notice
> m3-sys/cminstall/src/config-no-install/ARMEL_LINUX:
> >>
> >>
> >> SYSTEM_CC = "arm-linux-gnueabi-gcc -gstabs+ -fPIC"
> % C compiler
> >> SYSTEM_ASM = "arm-linux-gnueabi-as" % Assembler
> >>
> >>
> >> I get to:
> >> jay at xlin2:~/cm3-boot-ARMEL_LINUX-d5.8.2-20100619$
> file cm3
> >> cm3: ELF 32-bit LSB executable, ARM, version 1
> (SYSV), dynamically linked (uses shared libs), for GNU/Linux
> 2.6.14, not stripped
> >> jay at xlin2:~/cm3-boot-ARMEL_LINUX-d5.8.2-20100619$
> qemu-arm ./cm3
> >> /lib/ld-linux.so.3: No such file or directory
> >>
> >>
> >> My QEmu setup isn't complete..
> >>
> >>
> >> I got the crosstools from hereabouts:
> >> http://www.emdebian.org/tools/crosstools.html
> >>
> >>
> >> crosstool, scratchbox, buildroot may also be good
> options.
> >>
> >>
> >> This reminds me though, I have a Western Digital
> MyBook World Edition.
> >> Haven't powered it on in a while, slightly flaky
> device.
> >> But it runs Linux/arm (oldabi).
> >> I could/should power it on or get a new one
> something.
> >>
> >>
> >> Also note/reminder, Android seems a bit different,
> at least in terms of finding C headers and libraries, maybe
> not for generating assembly, than "regular" Linux/arm.
> >> Really "Linux/arm" seems a pretty fractured
> thing.
> >> Newer architectures have floating point, for one
> thing.
> >>
> >>
> >> - Jay
> >>
> >> ----------------------------------------
> >>> From: darko at darko.org
> >>> Date: Sat, 19 Jun 2010 15:47:24 -0700
> >>> To: jay.krell at cornell.edu
> >>> CC: m3devel at elegosoft.com
> >>> Subject: Re: [M3devel] Linux/ARM? Android?
> >>>
> >>> Fantasic, thanks. There are some ARM cross
> tools available under DarwinPorts which I'm going to give
> this a try with.
> >>>
> >>>
> >>> On 19/06/2010, at 2:51 AM, Jay K wrote:
> >>>
> >>>
> >>> Eh I guess I should try that then. Ok. Thanks.
> Gotta take a break for a while.
> >>> cd wherever
> >>> cvs -z3 upd -dAP
> >>> cd scripts/python
> >>> ./boot1.py ARMEL_LINUX
> >>> => cm3-boot-ARMEL_LINUX...tgz
> >>> extract that on a machine with cross tools
> (e.g. arm-linux-gnueabi-gcc, arm-linux-gnueabi-as), possibly
> the same machine as already on
> >>> cd into it
> >>> make
> >>> => arm cm3
> >>>
> >>>
> >>> I got that far.
> >>> I can't claim it is right for Android.
> >>>
> >>>
> >>> Then put that cm3 onto a real (or emulated)
> ARM system and...
> >>> (cvs checkout, put the cm3 in /cm3/bin or
> such, add that to $PATH, and scripts/python/boot2.sh)
> >>>
> >>>
> >>> Moving forward to gcc 4.5 will get us atomics
> for ARM, sort of, at least on Linux, see:
> >>> http://gcc.gnu.org/wiki/Atomic
> >>>
> >>>
> >>> - Jay
> >>>
> >>> ----------------------------------------
> >>>> From: darko at darko.org
> >>>> Date: Sat, 19 Jun 2010 02:15:17 -0700
> >>>> To: jay.krell at cornell.edu
> >>>> CC: m3devel at elegosoft.com
> >>>> Subject: Re: [M3devel] Linux/ARM?
> Android?
> >>>>
> >>>> I should also mention that the Android SDK
> has a QEMU based emulator for testing applications and the
> adb (Android Bridge) tool can provide shell access.
> >>>>
> >>>>
> >>>> On 19/06/2010, at 12:13 AM, Darko wrote:
> >>>>
> >>>> I got the first Debian image on http://www.oszoo.org/wiki/index.php/Category:ARM_images
> to run with a GUI, and it connect to the network. I'm using
> Q on my 2.4Ghz MacBook 13" and it's surprisingly fast. Note
> that it's a 10GB image (450MB download).
> >>>>
> >>>> There are also images for Debian MIPS on
> that site too.
> >>>>
> >>>> I agree that the new MacBook trackpad is
> not perfect and since moving from my previous machine that
> had a separate button I now get a lot of stray gestures
> doing odd things. The general solution is not to use the
> button at all and use taps. The new momentum scrolling with
> the gesture is neat but needs more "weight". Unfortunately
> Apple crosses over into form-over-function territory from
> time to time and this is one of those times.
> >>>>
> >>>>
> >>>> On 18/06/2010, at 11:18 PM, Jay K wrote:
> >>>>
> >>>>
> >>>> XP when I can; nothing else comes close
> for searching and editing text, I've tried many.
> >>>> Visual C++ 5.0.
> >>>> I recently learned how to copy/paste in
> vi, which helps, but I'm not sure I remember now.
> >>>>
> >>>>
> >>>> Darwin/amd64 when I need/want
> posix/fastfork, which unfortunately is often.
> >>>> Cygwin is slow.
> >>>> TextWrangler usually there, though it is
> awful compared to Visual C++ 5.0.
> >>>> KomodoEdit is cross platform but also
> fairly impaired.
> >>>> ssh access to a variety
> >>>> Linux=Debian, it has among the best
> support for a variety of platforms.
> >>>> Gentoo comes close or better (ppc64) but
> I've never been able to get it to install -- booting always
> fails.
> >>>> Debian/x86 easy to get cross compiler,
> qemu, etc.
> >>>>
> >>>>
> >>>> X Windows apps are never very good imho,
> so just give up and make do with the even worse command
> line..
> >>>> I find things as basic as scrollbars do
> not work well -- which button do I press when?
> >>>> The Modula-3 GUI apps suffer from this
> problem as well.
> >>>> Further damage due to needing three
> buttons but not having them.
> >>>>
> >>>>
> >>>> Mouse button clicking is actually broken
> on modern Macs too -- they removed the mouse button from all
> the laptops, leaving
> >>>> just a big pad, prone to accidental clicks
> at any location.. also prone to accidental multitouch
> gestures due to resting
> >>>> a twitchy thumb where the button is
> supposed to be. Amazing, really, the mouse, one of their key
> initial advantages,
> >>>> is now broken. (see also Finder and file
> open dialogs, two other former strengths that are now not so
> great.)
> >>>> Multitouch scroll is nice though.
> >>>>
> >>>>
> >>>> - Jay
> >>>>
> >>>> ----------------------------------------
> >>>>> From: darko at darko.org
> >>>>> Date: Fri, 18 Jun 2010 22:55:24 -0700
> >>>>> To: jay.krell at cornell.edu
> >>>>> CC: m3devel at elegosoft.com
> >>>>> Subject: Re: [M3devel] Linux/ARM?
> Android?
> >>>>>
> >>>>> Yeah I've got it working on the
> console but I agree it needs the network.
> >>>>>
> >>>>> Try: http://www.oszoo.org/wiki/index.php/Category:ARM_images
> >>>>> Also: http://www.armedslack.org/
> >>>>>
> >>>>> What platform are you running on these
> days?
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 18/06/2010, at 10:44 PM, Jay K
> wrote:
> >>>>>
> >>>>>
> >>>>> Interesting, thanks.
> >>>>> But it looks like it needs to use
> local console for output?
> >>>>> I need something over the network/X.
> >>>>> It looks like there's an qemu option
> for usemode only too.
> >>>>>
> >>>>> - Jay
> >>>>>
> >>>>>
> ----------------------------------------
> >>>>>> From: darko at darko.org
> >>>>>> Date: Fri, 18 Jun 2010 22:13:43
> -0700
> >>>>>> To: jay.krell at cornell.edu
> >>>>>> CC: m3devel at elegosoft.com
> >>>>>> Subject: Re: [M3devel] Linux/ARM?
> Android?
> >>>>>>
> >>>>>> If you use qemu, this might be
> useful: http://free-electrons.com/community/demos/qemu-arm-directfb/
> >>>>>>
> >>>>>> I'm currently looking at some
> cheap laptops (around $100) which have ethernet plus screen,
> keyboard, battery, etc which would work well as hosts. Just
> trying to find one that runs both Linux and Android.
> >>>>>>
> >>>>>>
> >>>>>> On 18/06/2010, at 10:04 PM, Jay K
> wrote:
> >>>>>>
> >>>>>>
> >>>>>> Thanks. I'll give qemu a go as
> well.
> >>>>>> Hey, maybe we can get mips also.
> (there's decent modern mips/linux hardware now, Chinese
> laptops)
> >>>>>>
> >>>>>> - Jay
> >>>>>>
> >>>>>>
> ----------------------------------------
> >>>>>>> From: darko at darko.org
> >>>>>>> Date: Thu, 17 Jun 2010
> 21:41:59 -0700
> >>>>>>> To: jay.krell at cornell.edu
> >>>>>>> CC: m3devel at elegosoft.com
> >>>>>>> Subject: Re: [M3devel]
> Linux/ARM? Android?
> >>>>>>>
> >>>>>>> Ok, the link here is about
> 20/4Mbs so it shouldn't be too bad and the latency is good.
> I'm in Mountain View, CA. Unfortunately the board has only
> 128MB of main memory but I assume that's enough, I think a
> self hosted compiler has no point.
> >>>>>>>
> >>>>>>> I'll post the details when
> it's up and running.
> >>>>>>>
> >>>>>>>
> >>>>>>> On 17/06/2010, at 9:15 PM, Jay
> K wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>> My preference would be if you
> can set it up on the internet and allow me ssh access.
> >>>>>>> gcc only recently got support
> for Android's C library "bionic", I believe post-gcc 4.5.
> >>>>>>> I'm not sure if that matters
> much or not.
> >>>>>>> I'm not sure how much the C
> library of the target matters to gcc.
> >>>>>>>
> >>>>>>>
> >>>>>>> Anything with pthreads and gcc
> support is quite easy to port to these days. In the past the
> biggest thing you had to do was rewrite /usr/include in
> Modula-3. There was a tendency to rewrite far more of it
> than necessary. These days, none of it is needed.
> >>>>>>>
> >>>>>>>
> >>>>>>> Now you just have to
> >>>>>>> - pick a target name
> >>>>>>> - find the jmpbuf size, word
> size, endian
> >>>>>>> - write a much small "config"
> file
> >>>>>>> - respond to each error that
> occurs -- fill in the platform in a few tables sprinkled
> around the tree
> >>>>>>>
> >>>>>>>
> >>>>>>> Even systems without pthreads
> or with not very good pthreads (OpenBSD) are easy now, as
> the user thread support is much more portable. It used to
> be, for user threads, you had to poke around in the jmpbuf.
> >>>>>>>
> >>>>>>>
> >>>>>>> I would encourage anyone else
> to try it out.
> >>>>>>>
> >>>>>>>
> >>>>>>> Maybe soon there will be a C
> generating backend, and we'll just have one distribution
> format that is a bunch of C, and then gcc support won't even
> be needed (e.g. IA64_NT).
> >>>>>>>
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> - Jay
> >>>>>>>
> >>>>>>>
> ----------------------------------------
> >>>>>>>> From: darko at darko.org
> >>>>>>>> Date: Thu, 17 Jun 2010
> 18:08:14 -0700
> >>>>>>>> To: jay.krell at cornell.edu
> >>>>>>>> CC: m3devel at elegosoft.com
> >>>>>>>> Subject: Re: [M3devel]
> Linux/ARM? Android?
> >>>>>>>>
> >>>>>>>> I've been interested in an
> ARM port for some time. If you (or anyone else) are
> interested in doing the port I can send you one of these,
> which looks like a good platform since it runs Linux and
> Android, has 512K memory and looks well supported: http://beagleboard.org/hardware
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 20/05/2010, at 4:47 AM,
> 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?
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>
> >>
> >
> >
>     
>         
>           
>   


      


From m3 at sol42.com  Sun Jun 20 11:21:03 2010
From: m3 at sol42.com (m3 at sol42.com)
Date: Sun, 20 Jun 2010 11:21:03 +0200
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <COL101-W493D8FFD71EB43948CBE8CE6C10@phx.gbl>
References: <1274350133.8902.0.camel@localhost>, ,
	<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>, ,
	<2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>,
	<COL101-W580FCB4C956AC658A851ABE6C00@phx.gbl>,
	<44CCDCF6-BACE-4B58-A1F5-EF68A852E2A5@darko.org>
	<COL101-W493D8FFD71EB43948CBE8CE6C10@phx.gbl>
Message-ID: <5CEB90C2-DC07-4D4C-9E90-FCCEA356E065@sol42.com>

On 19 Jun 2010, at 7:04, Jay K wrote:
> Hey, maybe we can get mips also. (there's decent modern mips/linux hardware now, Chinese laptops)
Hmm, I have decent ancient mips/irix hardware I'd love to get m3 running on.  Will have to give it a try when I get some free time.  Is gcc 4 required (I have 3.3)?
Regards.
-Daniel

From dabenavidesd at yahoo.es  Sun Jun 20 20:54:49 2010
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Sun, 20 Jun 2010 18:54:49 +0000 (GMT)
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <5CEB90C2-DC07-4D4C-9E90-FCCEA356E065@sol42.com>
Message-ID: <974011.74052.qm@web23608.mail.ird.yahoo.com>

Hi:
if you mean the c "native" compiler shouldn't be a problem, but one would expect differences between efficiency of both m3cg builds, I believe buildable for gcc 4 and 3 but nonetheless it shouldn't be the same in terms of the generated m3cg but for the M3 code which is what one is interested would be more like the same. If it is necessary to work with it I believe the process of installing a new gcc for c lang only is not too painful and is straight forward after you have a previous version to build a gcc 4 with a bootstrap compiler to build a self hosted c compiler.
I don't know how much of the building process of m3cg is done by the gcc c compiler if it could be done at the same time such a build with current tree (which if there is I think is doable just selecting the proper options in the configure program command parameters, although not sure to build a full self hosted c gcc 4 compiler, but doable if you start with a bootstrap gcc 4 c compiler).
Hope it helps and thanks in adavance
 
--- El dom, 20/6/10, m3 at sol42.com <m3 at sol42.com> escribi?:

> De: m3 at sol42.com <m3 at sol42.com>
> Asunto: Re: [M3devel] Linux/ARM? Android?
> Para: m3devel at elegosoft.com
> Fecha: domingo, 20 de junio, 2010 04:21
> On 19 Jun 2010, at 7:04, Jay K
> wrote:
> > Hey, maybe we can get mips also. (there's decent
> modern mips/linux hardware now, Chinese laptops)
> Hmm, I have decent ancient mips/irix hardware I'd love to
> get m3 running on.  Will have to give it a try when I
> get some free time.  Is gcc 4 required (I have 3.3)?
> Regards.
> -Daniel


      


From jay.krell at cornell.edu  Sun Jun 20 21:16:27 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 20 Jun 2010 19:16:27 +0000
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <5CEB90C2-DC07-4D4C-9E90-FCCEA356E065@sol42.com>
References: <1274350133.8902.0.camel@localhost>,
	,,<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>,
	, , <2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>, ,
	<COL101-W580FCB4C956AC658A851ABE6C00@phx.gbl>, ,
	<44CCDCF6-BACE-4B58-A1F5-EF68A852E2A5@darko.org>,
	<COL101-W493D8FFD71EB43948CBE8CE6C10@phx.gbl>,
	<5CEB90C2-DC07-4D4C-9E90-FCCEA356E065@sol42.com>
Message-ID: <COL101-W70CBF569D6E232E7CAD5BE6C20@phx.gbl>


No gcc 4 is not required.
What is required is that gcc 4.3 support your machine -- since that is currently what m3cg is based on -- but you don't need gcc 4.
You just need some C compiler.
gcc 4.3 does support Irix/mips I believe.
Irix 6.5.

?- Jay

----------------------------------------
> From: m3 at sol42.com
> Date: Sun, 20 Jun 2010 11:21:03 +0200
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] Linux/ARM? Android?
>
> On 19 Jun 2010, at 7:04, Jay K wrote:
>> Hey, maybe we can get mips also. (there's decent modern mips/linux hardware now, Chinese laptops)
> Hmm, I have decent ancient mips/irix hardware I'd love to get m3 running on. Will have to give it a try when I get some free time. Is gcc 4 required (I have 3.3)?
> Regards.
> -Daniel
 		 	   		  

From jay.krell at cornell.edu  Sun Jun 20 21:43:57 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 20 Jun 2010 19:43:57 +0000
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <974011.74052.qm@web23608.mail.ird.yahoo.com>
References: <5CEB90C2-DC07-4D4C-9E90-FCCEA356E065@sol42.com>,
	<974011.74052.qm@web23608.mail.ird.yahoo.com>
Message-ID: <COL101-W190990CE2CFAD02AC0CBC0E6C20@phx.gbl>


True, that m3cg is "most" buildable by gcc itself. That gets the most testing by gcc developers.
Almost any version will do though.
But it is buildable by other C compilers, such as Sun cc and OSF/1's C compiler.
Going forward, like to gcc 4.6, a C++ compiler might be needed.
OpenBSD uses gcc 3.x on most platforms and 2.x on some older ones.
gcc 4.4 and 4.5 actually require a C9x compiler but that is an accidental regression and getting fixed.
I found it using OSF/1 cc on Mika's machine. :)


On Irix I found some wierd old undocumented "O32" compiler and I think was able to use it eventually
to build modern gcc. It required some small patches to some tools, and it seemed to
perhaps even miscompile things, such that they had to later be rebuilt with gcc.


On HP-UX on HPPA the? bundled compiler is K&R. It can be used to build some gcc 3.x, which
can then be used to build gcc 4.x and/or presumably m3cg. I don't remember how far I got.
This "need" to go through gcc 3.x is documented on the gcc web pages.


?- Jay

----------------------------------------
> Date: Sun, 20 Jun 2010 18:54:49 +0000
> From: dabenavidesd at yahoo.es
> To: m3devel at elegosoft.com; m3 at sol42.com
> Subject: Re: [M3devel] Linux/ARM? Android?
>
> Hi:
> if you mean the c "native" compiler shouldn't be a problem, but one would expect differences between efficiency of both m3cg builds, I believe buildable for gcc 4 and 3 but nonetheless it shouldn't be the same in terms of the generated m3cg but for the M3 code which is what one is interested would be more like the same. If it is necessary to work with it I believe the process of installing a new gcc for c lang only is not too painful and is straight forward after you have a previous version to build a gcc 4 with a bootstrap compiler to build a self hosted c compiler.
> I don't know how much of the building process of m3cg is done by the gcc c compiler if it could be done at the same time such a build with current tree (which if there is I think is doable just selecting the proper options in the configure program command parameters, although not sure to build a full self hosted c gcc 4 compiler, but doable if you start with a bootstrap gcc 4 c compiler).
> Hope it helps and thanks in adavance
>
> --- El dom, 20/6/10, m3 at sol42.com  escribi?:
>
>> De: m3 at sol42.com 
>> Asunto: Re: [M3devel] Linux/ARM? Android?
>> Para: m3devel at elegosoft.com
>> Fecha: domingo, 20 de junio, 2010 04:21
>> On 19 Jun 2010, at 7:04, Jay K
>> wrote:
>>> Hey, maybe we can get mips also. (there's decent
>> modern mips/linux hardware now, Chinese laptops)
>> Hmm, I have decent ancient mips/irix hardware I'd love to
>> get m3 running on. Will have to give it a try when I
>> get some free time. Is gcc 4 required (I have 3.3)?
>> Regards.
>> -Daniel
>
>
>
 		 	   		  

From dragisha at m3w.org  Sun Jun 20 22:38:26 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Sun, 20 Jun 2010 22:38:26 +0200
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <COL101-W190990CE2CFAD02AC0CBC0E6C20@phx.gbl>
References: <5CEB90C2-DC07-4D4C-9E90-FCCEA356E065@sol42.com>
	, <974011.74052.qm@web23608.mail.ird.yahoo.com>
	<COL101-W190990CE2CFAD02AC0CBC0E6C20@phx.gbl>
Message-ID: <1277066306.5571.4.camel@localhost>

It's cheaper to support platforms through m3gc (meaning gcc) than
through C. Going native so as to get "broader base than gcc"? Do we
really have that wide userbase? Not to mention developer base...

And why're you looking retro to C? Why not invest yourself on LLVM? JIT
comes to mind....

On Sun, 2010-06-20 at 19:43 +0000, Jay K wrote:
> True, that m3cg is "most" buildable by gcc itself. That gets the most
> testing by gcc developers.
> Almost any version will do though.
> But it is buildable by other C compilers, such as Sun cc and OSF/1's C
> compiler.
> Going forward, like to gcc 4.6, a C++ compiler might be needed.
> OpenBSD uses gcc 3.x on most platforms and 2.x on some older ones.
> gcc 4.4 and 4.5 actually require a C9x compiler but that is an
> accidental regression and getting fixed.
> I found it using OSF/1 cc on Mika's machine. :) 
-- 
Dragi?a Duri? <dragisha at m3w.org>



From jay.krell at cornell.edu  Mon Jun 21 00:40:54 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 20 Jun 2010 22:40:54 +0000
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <1277066306.5571.4.camel@localhost>
References: <5CEB90C2-DC07-4D4C-9E90-FCCEA356E065@sol42.com>,,
	<974011.74052.qm@web23608.mail.ird.yahoo.com>,
	<COL101-W190990CE2CFAD02AC0CBC0E6C20@phx.gbl>,
	<1277066306.5571.4.camel@localhost>
Message-ID: <COL101-W59EAC8AC1D2D1DC0678DA1E6C20@phx.gbl>


If you generate C, you get one very portable distribution format -- a bunch of C in .tar.gz.
Far more portable than what we have today.
You get possibly better optimization.
Possibly better debugging.
A much smaller source tree -- no need for m3cc or m3gdb.
You highly likely get more efficient portable exception handling -- generate C++.
? (On Win32, C suffices. Similarly on OSF/1 and VMS I believe.)
Granted, C++ with exception handling is less portable than C -- there could still be an option to use setjmp/longjmp.
I imagine it'd be wrapped up in some #defines.
Consider all the platforms that aren't well supported by gcc or LLVM.


You might get slower compilation, granted.


You could also use this as a hybrid approach. Consider that we already have two sort of backends.
This would be a third.
Anyone want Alpha, ARM, MIPS, IA64 etc. -- already done, or at least signficantly.


Consider how much work it takes to port "Hello world". None.
This would drive us toward that.
With some benefits and maybe some drawbacks.


?- Jay

----------------------------------------
> From: dragisha at m3w.org
> To: jay.krell at cornell.edu
> Date: Sun, 20 Jun 2010 22:38:26 +0200
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Linux/ARM? Android?
>
> It's cheaper to support platforms through m3gc (meaning gcc) than
> through C. Going native so as to get "broader base than gcc"? Do we
> really have that wide userbase? Not to mention developer base...
>
> And why're you looking retro to C? Why not invest yourself on LLVM? JIT
> comes to mind....
>
> On Sun, 2010-06-20 at 19:43 +0000, Jay K wrote:
>> True, that m3cg is "most" buildable by gcc itself. That gets the most
>> testing by gcc developers.
>> Almost any version will do though.
>> But it is buildable by other C compilers, such as Sun cc and OSF/1's C
>> compiler.
>> Going forward, like to gcc 4.6, a C++ compiler might be needed.
>> OpenBSD uses gcc 3.x on most platforms and 2.x on some older ones.
>> gcc 4.4 and 4.5 actually require a C9x compiler but that is an
>> accidental regression and getting fixed.
>> I found it using OSF/1 cc on Mika's machine. :)
> --
> Dragi?a Duri? 
>
 		 	   		  

From dragisha at m3w.org  Mon Jun 21 08:32:22 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Mon, 21 Jun 2010 08:32:22 +0200
Subject: [M3devel] ***SPAM*** RE:  Linux/ARM? Android?
In-Reply-To: <COL101-W59EAC8AC1D2D1DC0678DA1E6C20@phx.gbl>
References: <5CEB90C2-DC07-4D4C-9E90-FCCEA356E065@sol42.com>
	,, <974011.74052.qm@web23608.mail.ird.yahoo.com>
	,<COL101-W190990CE2CFAD02AC0CBC0E6C20@phx.gbl>
	,<1277066306.5571.4.camel@localhost>
	<COL101-W59EAC8AC1D2D1DC0678DA1E6C20@phx.gbl>
Message-ID: <1277101942.5571.83.camel@localhost>

Is there such thing as overportability ?:) Are we really so desperate to
reach for users and supporters to fight for ones using most obsolete and
obscure hardware/OSes? Outside of what gcc covers?

My mention of LLVM was not "get more platforms" but "get new angle".

On Sun, 2010-06-20 at 22:40 +0000, Jay K wrote:
> 
> If you generate C, you get one very portable distribution format -- a
> bunch of C in .tar.gz.
> Far more portable than what we have today.

  If we all just stick to C, we'll have that, minus all learning and
programming and debugging and packaging and marketing effort for
Modula-3. Don't you think so? And this compares because...

> You get possibly better optimization.
> Possibly better debugging.
> A much smaller source tree -- no need for m3cc or m3gdb.

  And you get to talk C with your program when debugging, instead of
M3... How nice :). We can have Modula-3 developers in teams who don't
even need to know Modula-3? 

  m3gdb we need, that is for sure. As for m3cc... There comes LLVM
also... What we need is coordinated effort with gcc|LLVM people so we
can get recognition and "officiality" of our patches. And once for all
stop running behind in versions used.

> Consider all the platforms that aren't well supported by gcc or LLVM.

  All that hardware people are throwing away....

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



From jay.krell at cornell.edu  Mon Jun 21 09:55:19 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 21 Jun 2010 07:55:19 +0000
Subject: [M3devel] checking function pointers for null?
Message-ID: <COL101-W351A37DF7AC3C7A9A9E1ACE6C30@phx.gbl>


This is code that calls a function pointer:


??????? testq?? %rbx, %rbx ; test function pointer for null
??????? je????? L6
??????? cmpq??? $-1, (%rbx) ; check for closure marker
??????? jne???? L6? ; if not a closure, goto L6
??????? movq??? 16(%rbx), %r13 ; r13=static chain (ought to use r10?) 
??????? movq??? 8(%rbx), %rax ; rax=actual function pointer
??????? jmp???? L8
L6:
??????? movq??? %rbx, %rax ; rax=actual function pointer
L8:
??????? movq??? %r13, %r10 ; r10=static chain (it should have just used r10 in the first place? or is r13 otherwise the previous static chain?)
??????? call??? *%rax


What is the point of the initial testq/je, if we are just going to jump to the address anyway?
Should we do something else if in fact the function pointer is null? Or just let a jump to null fail as it will?
You know -- it seems me we should do either more or less here.
More: report a null deref by calling m3_fault
Less: remove the null check 


?- Jay
 		 	   		  

From hosking at cs.purdue.edu  Mon Jun 21 16:26:31 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 21 Jun 2010 10:26:31 -0400
Subject: [M3devel] checking function pointers for null?
In-Reply-To: <COL101-W351A37DF7AC3C7A9A9E1ACE6C30@phx.gbl>
References: <COL101-W351A37DF7AC3C7A9A9E1ACE6C30@phx.gbl>
Message-ID: <3A74ECDB-2F76-4B7A-B7F3-CAEBA38F129B@cs.purdue.edu>

Is this code from M3CG or the Windows native backend?

If from M3CG perhaps you can show us the M3CG IR code.

On 21 Jun 2010, at 03:55, Jay K wrote:

> 
> This is code that calls a function pointer:
> 
> 
>         testq   %rbx, %rbx ; test function pointer for null
>         je      L6
>         cmpq    $-1, (%rbx) ; check for closure marker
>         jne     L6  ; if not a closure, goto L6
>         movq    16(%rbx), %r13 ; r13=static chain (ought to use r10?) 
>         movq    8(%rbx), %rax ; rax=actual function pointer
>         jmp     L8
> L6:
>         movq    %rbx, %rax ; rax=actual function pointer
> L8:
>         movq    %r13, %r10 ; r10=static chain (it should have just used r10 in the first place? or is r13 otherwise the previous static chain?)
>         call    *%rax
> 
> 
> What is the point of the initial testq/je, if we are just going to jump to the address anyway?
> Should we do something else if in fact the function pointer is null? Or just let a jump to null fail as it will?
> You know -- it seems me we should do either more or less here.
> More: report a null deref by calling m3_fault
> Less: remove the null check 
> 
> 
>  - Jay
> 		 	   		  



From jay.krell at cornell.edu  Mon Jun 21 19:47:48 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 21 Jun 2010 17:47:48 +0000
Subject: [M3devel] checking function pointers for null?
In-Reply-To: <3A74ECDB-2F76-4B7A-B7F3-CAEBA38F129B@cs.purdue.edu>
References: <COL101-W351A37DF7AC3C7A9A9E1ACE6C30@phx.gbl>,
	<3A74ECDB-2F76-4B7A-B7F3-CAEBA38F129B@cs.purdue.edu>
Message-ID: <COL101-W499F828D94ADA12FF53275E6C30@phx.gbl>

Neither backend would add these checks themself, it is m3cg, IR later.

> Subject: Re: [M3devel] checking function pointers for null?
> From: hosking at cs.purdue.edu
> Date: Mon, 21 Jun 2010 10:26:31 -0400
> CC: m3devel at elegosoft.com
> To: jay.krell at cornell.edu
> 
> Is this code from M3CG or the Windows native backend?
> 
> If from M3CG perhaps you can show us the M3CG IR code.
> 
> On 21 Jun 2010, at 03:55, Jay K wrote:
> 
> > 
> > This is code that calls a function pointer:
> > 
> > 
> >         testq   %rbx, %rbx ; test function pointer for null
> >         je      L6
> >         cmpq    $-1, (%rbx) ; check for closure marker
> >         jne     L6  ; if not a closure, goto L6
> >         movq    16(%rbx), %r13 ; r13=static chain (ought to use r10?) 
> >         movq    8(%rbx), %rax ; rax=actual function pointer
> >         jmp     L8
> > L6:
> >         movq    %rbx, %rax ; rax=actual function pointer
> > L8:
> >         movq    %r13, %r10 ; r10=static chain (it should have just used r10 in the first place? or is r13 otherwise the previous static chain?)
> >         call    *%rax
> > 
> > 
> > What is the point of the initial testq/je, if we are just going to jump to the address anyway?
> > Should we do something else if in fact the function pointer is null? Or just let a jump to null fail as it will?
> > You know -- it seems me we should do either more or less here.
> > More: report a null deref by calling m3_fault
> > Less: remove the null check 
> > 
> > 
> >  - Jay
> > 		 	   		  
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100621/13be0de5/attachment-0001.html>

From jay.krell at cornell.edu  Mon Jun 21 22:55:06 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 21 Jun 2010 20:55:06 +0000
Subject: [M3devel] checking function pointers for null?
In-Reply-To: <3A74ECDB-2F76-4B7A-B7F3-CAEBA38F129B@cs.purdue.edu>
References: <COL101-W351A37DF7AC3C7A9A9E1ACE6C30@phx.gbl>,
	<3A74ECDB-2F76-4B7A-B7F3-CAEBA38F129B@cs.purdue.edu>
Message-ID: <COL101-W35300463AE825ED4FE7EB5E6C30@phx.gbl>


The backend is doing what the front/middle end asks.
My original question stands: The check for NULL is worthless, right?
Either it should do more: call m3_fault
Or it should do less: don't bother checking, let the hardware do it at the call or marker check (the marker check, in reality)
?

I can understand the stance that the software does all the checking. That we don't/shouldn't depend on hardware checking.
? Though that isn't true -- the rationale for "Target.first_readable_address" or such is that hardware checks for NULL deref,
?? and even "small deref" -- anything in the first page at least.

But this seems in between -- it avoids the null deref for the marker check but doesn't avoid it for the call.
Perhaps there is an idea that the hardware checking is somehow different for data vs. code??


MODULE Main;

TYPE Function = PROCEDURE ();

PROCEDURE C(a:Function) =
BEGIN
?a();
END C;

BEGIN
END Main.


(23) begin_procedure
? procedure Main__C
?Main__C(24) set_source_line
? source line??? 6
(25) set_source_line
? source line??? 7
(26) load
? type:addr
? type:addr
? m3cg_load (M3_CQL02D_a): offset 0x0, convert addr -> addr
(27) declare_temp
? type:addr
? temp var type:addr size:0x40 alignment:0x40
(28) store
? type:addr
? type:addr
? store (noname) offset:0x0 src_t:addr dst_t:addr
(29) start_call_indirect
? type:void
? start call procedure indirect type:void
(30) load
? type:addr
? type:addr
? m3cg_load (noname): offset 0x0, convert addr -> addr
(31) load_nil??? ***
(32) if_eq???????? ***
? type:addr
? label 1
(33) load
? type:addr
? type:addr
? m3cg_load (noname): offset 0x0, convert addr -> addr
(34) load_indirect
? type:int64
? type:int64
? load address offset:0x0 src_t:int64 dst_t:int64
(35) load_integer
? type:int64
? integer i:0xfe n_bytes:0x1 0x00000000000000001 sign -1
(36) if_ne
? type:int64
? label 1
(37) set_label
? label 2
(38) load
? type:addr
? type:addr
? m3cg_load (noname): offset 0x0, convert addr -> addr
(39) load_indirect
? type:addr
? type:addr
? load address offset:0x80 src_t:addr dst_t:addr
(40) pop_static_link
(41) load
? type:addr
? type:addr
? m3cg_load (noname): offset 0x0, convert addr -> addr
(42) load_indirect
? type:addr
? type:addr
? load address offset:0x40 src_t:addr dst_t:addr
(43) store
? type:addr
? type:addr
? store (noname) offset:0x0 src_t:addr dst_t:addr
(44) set_label
? label 1
(45) load
? type:addr
? type:addr
? m3cg_load (noname): offset 0x0, convert addr -> addr
(46) call_indirect
? type:void
? call procedure indirect type:void
(47) set_source_line
? source line??? 8
(48) exit_proc
? type:void
(49) free_temp
(50) end_procedure
? procedure Main__C

?- Jay


________________________________
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com
> Subject: RE: [M3devel] checking function pointers for null?
> Date: Mon, 21 Jun 2010 17:47:48 +0000
>
>
>
>
>
>
>
> Neither backend would add these checks themself, it is m3cg, IR later.
>
>> Subject: Re: [M3devel] checking function pointers for null?
>> From: hosking at cs.purdue.edu
>> Date: Mon, 21 Jun 2010 10:26:31 -0400
>> CC: m3devel at elegosoft.com
>> To: jay.krell at cornell.edu
>>
>> Is this code from M3CG or the Windows native backend?
>>
>> If from M3CG perhaps you can show us the M3CG IR code.
>>
>> On 21 Jun 2010, at 03:55, Jay K wrote:
>>
>>>
>>> This is code that calls a function pointer:
>>>
>>>
>>> testq %rbx, %rbx ; test function pointer for null
>>> je L6
>>> cmpq $-1, (%rbx) ; check for closure marker
>>> jne L6 ; if not a closure, goto L6
>>> movq 16(%rbx), %r13 ; r13=static chain (ought to use r10?)
>>> movq 8(%rbx), %rax ; rax=actual function pointer
>>> jmp L8
>>> L6:
>>> movq %rbx, %rax ; rax=actual function pointer
>>> L8:
>>> movq %r13, %r10 ; r10=static chain (it should have just used r10 in the first place? or is r13 otherwise the previous static chain?)
>>> call *%rax
>>>
>>>
>>> What is the point of the initial testq/je, if we are just going to jump to the address anyway?
>>> Should we do something else if in fact the function pointer is null? Or just let a jump to null fail as it will?
>>> You know -- it seems me we should do either more or less here.
>>> More: report a null deref by calling m3_fault
>>> Less: remove the null check
>>>
>>>
>>> - Jay
>>>
>>
 		 	   		  

From hosking at cs.purdue.edu  Mon Jun 21 23:09:08 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 21 Jun 2010 17:09:08 -0400
Subject: [M3devel] checking function pointers for null?
In-Reply-To: <COL101-W35300463AE825ED4FE7EB5E6C30@phx.gbl>
References: <COL101-W351A37DF7AC3C7A9A9E1ACE6C30@phx.gbl>,
	<3A74ECDB-2F76-4B7A-B7F3-CAEBA38F129B@cs.purdue.edu>
	<COL101-W35300463AE825ED4FE7EB5E6C30@phx.gbl>
Message-ID: <8A2BCF94-43E9-44F5-9C63-AC71A4563E0B@cs.purdue.edu>

I want to see the IR.


On 21 Jun 2010, at 16:55, Jay K wrote:

> 
> The backend is doing what the front/middle end asks.
> My original question stands: The check for NULL is worthless, right?
> Either it should do more: call m3_fault
> Or it should do less: don't bother checking, let the hardware do it at the call or marker check (the marker check, in reality)
> ?
> 
> I can understand the stance that the software does all the checking. That we don't/shouldn't depend on hardware checking.
>  Though that isn't true -- the rationale for "Target.first_readable_address" or such is that hardware checks for NULL deref,
>   and even "small deref" -- anything in the first page at least.
> 
> But this seems in between -- it avoids the null deref for the marker check but doesn't avoid it for the call.
> Perhaps there is an idea that the hardware checking is somehow different for data vs. code??
> 
> 
> MODULE Main;
> 
> TYPE Function = PROCEDURE ();
> 
> PROCEDURE C(a:Function) =
> BEGIN
> a();
> END C;
> 
> BEGIN
> END Main.
> 
> 
> (23) begin_procedure
>  procedure Main__C
> Main__C(24) set_source_line
>  source line    6
> (25) set_source_line
>  source line    7
> (26) load
>  type:addr
>  type:addr
>  m3cg_load (M3_CQL02D_a): offset 0x0, convert addr -> addr
> (27) declare_temp
>  type:addr
>  temp var type:addr size:0x40 alignment:0x40
> (28) store
>  type:addr
>  type:addr
>  store (noname) offset:0x0 src_t:addr dst_t:addr
> (29) start_call_indirect
>  type:void
>  start call procedure indirect type:void
> (30) load
>  type:addr
>  type:addr
>  m3cg_load (noname): offset 0x0, convert addr -> addr
> (31) load_nil    ***
> (32) if_eq         ***
>  type:addr
>  label 1
> (33) load
>  type:addr
>  type:addr
>  m3cg_load (noname): offset 0x0, convert addr -> addr
> (34) load_indirect
>  type:int64
>  type:int64
>  load address offset:0x0 src_t:int64 dst_t:int64
> (35) load_integer
>  type:int64
>  integer i:0xfe n_bytes:0x1 0x00000000000000001 sign -1
> (36) if_ne
>  type:int64
>  label 1
> (37) set_label
>  label 2
> (38) load
>  type:addr
>  type:addr
>  m3cg_load (noname): offset 0x0, convert addr -> addr
> (39) load_indirect
>  type:addr
>  type:addr
>  load address offset:0x80 src_t:addr dst_t:addr
> (40) pop_static_link
> (41) load
>  type:addr
>  type:addr
>  m3cg_load (noname): offset 0x0, convert addr -> addr
> (42) load_indirect
>  type:addr
>  type:addr
>  load address offset:0x40 src_t:addr dst_t:addr
> (43) store
>  type:addr
>  type:addr
>  store (noname) offset:0x0 src_t:addr dst_t:addr
> (44) set_label
>  label 1
> (45) load
>  type:addr
>  type:addr
>  m3cg_load (noname): offset 0x0, convert addr -> addr
> (46) call_indirect
>  type:void
>  call procedure indirect type:void
> (47) set_source_line
>  source line    8
> (48) exit_proc
>  type:void
> (49) free_temp
> (50) end_procedure
>  procedure Main__C
> 
> - Jay
> 
> 
> ________________________________
>> From: jay.krell at cornell.edu
>> To: hosking at cs.purdue.edu
>> CC: m3devel at elegosoft.com
>> Subject: RE: [M3devel] checking function pointers for null?
>> Date: Mon, 21 Jun 2010 17:47:48 +0000
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> Neither backend would add these checks themself, it is m3cg, IR later.
>> 
>>> Subject: Re: [M3devel] checking function pointers for null?
>>> From: hosking at cs.purdue.edu
>>> Date: Mon, 21 Jun 2010 10:26:31 -0400
>>> CC: m3devel at elegosoft.com
>>> To: jay.krell at cornell.edu
>>> 
>>> Is this code from M3CG or the Windows native backend?
>>> 
>>> If from M3CG perhaps you can show us the M3CG IR code.
>>> 
>>> On 21 Jun 2010, at 03:55, Jay K wrote:
>>> 
>>>> 
>>>> This is code that calls a function pointer:
>>>> 
>>>> 
>>>> testq %rbx, %rbx ; test function pointer for null
>>>> je L6
>>>> cmpq $-1, (%rbx) ; check for closure marker
>>>> jne L6 ; if not a closure, goto L6
>>>> movq 16(%rbx), %r13 ; r13=static chain (ought to use r10?)
>>>> movq 8(%rbx), %rax ; rax=actual function pointer
>>>> jmp L8
>>>> L6:
>>>> movq %rbx, %rax ; rax=actual function pointer
>>>> L8:
>>>> movq %r13, %r10 ; r10=static chain (it should have just used r10 in the first place? or is r13 otherwise the previous static chain?)
>>>> call *%rax
>>>> 
>>>> 
>>>> What is the point of the initial testq/je, if we are just going to jump to the address anyway?
>>>> Should we do something else if in fact the function pointer is null? Or just let a jump to null fail as it will?
>>>> You know -- it seems me we should do either more or less here.
>>>> More: report a null deref by calling m3_fault
>>>> Less: remove the null check
>>>> 
>>>> 
>>>> - Jay
>>>> 
>>> 
> 		 	   		  



From jay.krell at cornell.edu  Tue Jun 22 02:38:37 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 22 Jun 2010 00:38:37 +0000
Subject: [M3devel] checking function pointers for null?
In-Reply-To: <8A2BCF94-43E9-44F5-9C63-AC71A4563E0B@cs.purdue.edu>
References: <COL101-W351A37DF7AC3C7A9A9E1ACE6C30@phx.gbl>, ,
	<3A74ECDB-2F76-4B7A-B7F3-CAEBA38F129B@cs.purdue.edu>,
	<COL101-W35300463AE825ED4FE7EB5E6C30@phx.gbl>,
	<8A2BCF94-43E9-44F5-9C63-AC71A4563E0B@cs.purdue.edu>
Message-ID: <COL101-W28069DAED40F76BDA6CA4FE6C40@phx.gbl>


Isn't that the cm3cg -y output below?
It's all fairly obvious.
 
 
I looked, I might have the names wrong, but there is a function is_closure in the frontend. It is used by more than just call, e.g. it is used for function pointer comparison. So the "silent null check" is sometimes required, but I think it is dubious for call. (And comparing function pointers to other than null is dubious, and often doesn't "work" in the face of dynamic linking.)
 
 
 - Jay


----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Mon, 21 Jun 2010 17:09:08 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] checking function pointers for null?
>
> I want to see the IR.
>
>
> On 21 Jun 2010, at 16:55, Jay K wrote:
>
>>
>> The backend is doing what the front/middle end asks.
>> My original question stands: The check for NULL is worthless, right?
>> Either it should do more: call m3_fault
>> Or it should do less: don't bother checking, let the hardware do it at the call or marker check (the marker check, in reality)
>> ?
>>
>> I can understand the stance that the software does all the checking. That we don't/shouldn't depend on hardware checking.
>> Though that isn't true -- the rationale for "Target.first_readable_address" or such is that hardware checks for NULL deref,
>> and even "small deref" -- anything in the first page at least.
>>
>> But this seems in between -- it avoids the null deref for the marker check but doesn't avoid it for the call.
>> Perhaps there is an idea that the hardware checking is somehow different for data vs. code??
>>
>>
>> MODULE Main;
>>
>> TYPE Function = PROCEDURE ();
>>
>> PROCEDURE C(a:Function) =
>> BEGIN
>> a();
>> END C;
>>
>> BEGIN
>> END Main.
>>
>>
>> (23) begin_procedure
>> procedure Main__C
>> Main__C(24) set_source_line
>> source line 6
>> (25) set_source_line
>> source line 7
>> (26) load
>> type:addr
>> type:addr
>> m3cg_load (M3_CQL02D_a): offset 0x0, convert addr -> addr
>> (27) declare_temp
>> type:addr
>> temp var type:addr size:0x40 alignment:0x40
>> (28) store
>> type:addr
>> type:addr
>> store (noname) offset:0x0 src_t:addr dst_t:addr
>> (29) start_call_indirect
>> type:void
>> start call procedure indirect type:void
>> (30) load
>> type:addr
>> type:addr
>> m3cg_load (noname): offset 0x0, convert addr -> addr
>> (31) load_nil ***
>> (32) if_eq ***
>> type:addr
>> label 1
>> (33) load
>> type:addr
>> type:addr
>> m3cg_load (noname): offset 0x0, convert addr -> addr
>> (34) load_indirect
>> type:int64
>> type:int64
>> load address offset:0x0 src_t:int64 dst_t:int64
>> (35) load_integer
>> type:int64
>> integer i:0xfe n_bytes:0x1 0x00000000000000001 sign -1
>> (36) if_ne
>> type:int64
>> label 1
>> (37) set_label
>> label 2
>> (38) load
>> type:addr
>> type:addr
>> m3cg_load (noname): offset 0x0, convert addr -> addr
>> (39) load_indirect
>> type:addr
>> type:addr
>> load address offset:0x80 src_t:addr dst_t:addr
>> (40) pop_static_link
>> (41) load
>> type:addr
>> type:addr
>> m3cg_load (noname): offset 0x0, convert addr -> addr
>> (42) load_indirect
>> type:addr
>> type:addr
>> load address offset:0x40 src_t:addr dst_t:addr
>> (43) store
>> type:addr
>> type:addr
>> store (noname) offset:0x0 src_t:addr dst_t:addr
>> (44) set_label
>> label 1
>> (45) load
>> type:addr
>> type:addr
>> m3cg_load (noname): offset 0x0, convert addr -> addr
>> (46) call_indirect
>> type:void
>> call procedure indirect type:void
>> (47) set_source_line
>> source line 8
>> (48) exit_proc
>> type:void
>> (49) free_temp
>> (50) end_procedure
>> procedure Main__C
>>
>> - Jay
>>
>>
>> ________________________________
>>> From: jay.krell at cornell.edu
>>> To: hosking at cs.purdue.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: RE: [M3devel] checking function pointers for null?
>>> Date: Mon, 21 Jun 2010 17:47:48 +0000
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Neither backend would add these checks themself, it is m3cg, IR later.
>>>
>>>> Subject: Re: [M3devel] checking function pointers for null?
>>>> From: hosking at cs.purdue.edu
>>>> Date: Mon, 21 Jun 2010 10:26:31 -0400
>>>> CC: m3devel at elegosoft.com
>>>> To: jay.krell at cornell.edu
>>>>
>>>> Is this code from M3CG or the Windows native backend?
>>>>
>>>> If from M3CG perhaps you can show us the M3CG IR code.
>>>>
>>>> On 21 Jun 2010, at 03:55, Jay K wrote:
>>>>
>>>>>
>>>>> This is code that calls a function pointer:
>>>>>
>>>>>
>>>>> testq %rbx, %rbx ; test function pointer for null
>>>>> je L6
>>>>> cmpq $-1, (%rbx) ; check for closure marker
>>>>> jne L6 ; if not a closure, goto L6
>>>>> movq 16(%rbx), %r13 ; r13=static chain (ought to use r10?)
>>>>> movq 8(%rbx), %rax ; rax=actual function pointer
>>>>> jmp L8
>>>>> L6:
>>>>> movq %rbx, %rax ; rax=actual function pointer
>>>>> L8:
>>>>> movq %r13, %r10 ; r10=static chain (it should have just used r10 in the first place? or is r13 otherwise the previous static chain?)
>>>>> call *%rax
>>>>>
>>>>>
>>>>> What is the point of the initial testq/je, if we are just going to jump to the address anyway?
>>>>> Should we do something else if in fact the function pointer is null? Or just let a jump to null fail as it will?
>>>>> You know -- it seems me we should do either more or less here.
>>>>> More: report a null deref by calling m3_fault
>>>>> Less: remove the null check
>>>>>
>>>>>
>>>>> - Jay
>>>>>
>>>>
>>
> 		 	   		  

From jay.krell at cornell.edu  Wed Jun 23 15:40:35 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 23 Jun 2010 13:40:35 +0000
Subject: [M3devel] CHAR vs. Ctypes.char?
Message-ID: <COL101-W44D06778829668CD8100FDE6C50@phx.gbl>


Is it deliberate that CHAR and Ctypes.char don't match?
I'm building the tree with -new_adr.
"Many" of the breaks are due to this mismatch. Not real bugs. I use LOOPHOLE to let it compile.
"Many" are due to socklen_t. Real bugs on 64bit problems, at least in head.
I'm not sure there are any others yet.

?- Jay
 		 	   		  

From hosking at cs.purdue.edu  Wed Jun 23 15:57:04 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 23 Jun 2010 09:57:04 -0400
Subject: [M3devel] CHAR vs. Ctypes.char?
In-Reply-To: <COL101-W44D06778829668CD8100FDE6C50@phx.gbl>
References: <COL101-W44D06778829668CD8100FDE6C50@phx.gbl>
Message-ID: <9FB15BB1-E00A-4AB4-A580-71981F0A65C0@cs.purdue.edu>

CHAR is an enumeration.
Ctypes.char is a subrange.

Never the twain shall meet.

On 23 Jun 2010, at 09:40, Jay K wrote:

> 
> Is it deliberate that CHAR and Ctypes.char don't match?
> I'm building the tree with -new_adr.
> "Many" of the breaks are due to this mismatch. Not real bugs. I use LOOPHOLE to let it compile.
> "Many" are due to socklen_t. Real bugs on 64bit problems, at least in head.
> I'm not sure there are any others yet.
> 
>  - Jay
> 		 	   		  



From jay.krell at cornell.edu  Thu Jun 24 00:52:25 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 23 Jun 2010 22:52:25 +0000
Subject: [M3devel] CHAR vs. Ctypes.char?
In-Reply-To: <9FB15BB1-E00A-4AB4-A580-71981F0A65C0@cs.purdue.edu>
References: <COL101-W44D06778829668CD8100FDE6C50@phx.gbl>,
	<9FB15BB1-E00A-4AB4-A580-71981F0A65C0@cs.purdue.edu>
Message-ID: <COL101-W4372CBD0AF692D3E5990CCE6C50@phx.gbl>


Something should change.
I'm not sure exactly what but I'll make some suggestions.


char_star changed from UNTRACED REF char to UNTRACED REF CHAR
? Probably not this.
? Possibly introduce Utypes.char_star = UNTRACED REF CHAR
? but leave Ctypes.char_star alone. Possibly. This is I think the least
? likely option.
? 

and/or


Utypes.CHAR_star introduced = UNTRACED REF CHAR
many uses of char_star in m3core/src/unix changed to CHAR_star


and/or


Text.i3 already has FromChars that takes array of CHAR
add function FromCChars or somesuch that takes array of Ctypes.char
This I think is most likely.
Even though it adds to a "standard" interface.
It could be TextEx or TextExtras or such if that helps.


In particular, we often have:


Unix.i3: PROCEDURE GetFoo(char_star);


Wrapper.i3:
PROCEDURE GetFoo():TEXT=
VAR buff; ARRAY [0..N] of CHAR;
BEGIN
? Unix.GetFoo(ADR(buff[0]));
? RETURN Text.FromChars(buff);
END GetFoo;


This doesn't work with -new_adr.
? because ADR(CHAR) != ADR(char).
? 

At a minimum you have to:
? Unix.GetFoo(LOOPHOLE(ADR(buff[0]), ADDRESS));


but I'd much rather something more typesafe.


e.g.:
Wrapper.i3:
PROCEDURE GetFoo():TEXT=
VAR buff; ARRAY [0..N] of Ctypes.char;
BEGIN
? Unix.GetFoo(ADR(buff[0]));
? RETURN Text.FromCChars(buff);
END GetFoo;

or

Unix.i3:
PROCEDURE GetFoo(CHAR_star);

Wrapper.i3:
PROCEDURE GetFoo():TEXT=
VAR buff; ARRAY [0..N] of CHAR;
BEGIN
? Unix.GetFoo(ADR(buff[0]));
? RETURN Text.FromChars(buff);
END GetFoo;


or even something fancier like:


Unix.i3:
PROCEDURE GetFoo():TEXT; !



To whatever extent this occurs in sysutils, if at all, probably have to just LOOPHOLE,
since it needs to be compatible with a mix of compilers and m3core.


?- Jay









----------------------------------------
> Subject: Re: [M3devel] CHAR vs. Ctypes.char?
> From: hosking at cs.purdue.edu
> Date: Wed, 23 Jun 2010 09:57:04 -0400
> CC: m3devel at elegosoft.com
> To: jay.krell at cornell.edu
>
> CHAR is an enumeration.
> Ctypes.char is a subrange.
>
> Never the twain shall meet.
>
> On 23 Jun 2010, at 09:40, Jay K wrote:
>
>>
>> Is it deliberate that CHAR and Ctypes.char don't match?
>> I'm building the tree with -new_adr.
>> "Many" of the breaks are due to this mismatch. Not real bugs. I use LOOPHOLE to let it compile.
>> "Many" are due to socklen_t. Real bugs on 64bit problems, at least in head.
>> I'm not sure there are any others yet.
>>
>> - Jay
>>
>
 		 	   		  

From jay.krell at cornell.edu  Thu Jun 24 00:59:10 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 23 Jun 2010 22:59:10 +0000
Subject: [M3devel] -new_adr the default?
Message-ID: <COL101-W54C167232C5F9B2A6C4963E6C50@phx.gbl>


I'd like to make -new_adr the default.
It is more typesafe than the current way and finds bugs.
? Granted, so far I think only bugs that I introduced.


First I will make the tree compile either way.
?Such as by fixing the bugs and resolving somehow the char vs. CHAR breaks.


Changing this does break code, albeit only unsafe code.
? There isn't much of that? Right? :)
Sometimes that code had bugs, sometimes not.


I believe type safety and static checking (and sometimes runtime checking) do have a place in unsafe code.
?Maybe not as much as in safe code, but definitely still something.


The old way is that ADR return ADDRESS, similar to void*, and it is silently convertable to any pointer type. I think.


The new way is that ADR(T) returns UNTRACED REF T is is only silently convertable to ADDRESS? Or nothing at all?
?Esp. not silently convertable to UNTRACED REF U.


So there are buggy places that do:
PROCEDURE Foo(UNTRACED REF T);

PROCEDURE Bar()
VAR u: U;
BEGIN
?Foo(ADR(u));
END Bar;


That compile with old ADR but not with new ADR.
As I changed socklent_t between int and INTEGER, such code silently kept compiling.
? But possibly silently corrupting the stack or producing the wrong data.


This -new_adr feature was already implemented in the compiler unknown long ago.
? I didn't know but Tony pointed it out.
We should probably look at its impementation make sure we aren't switching on some buggy unused code.
So far switching it on I've only seen correct new errors.


?- Jay
 		 	   		  

From hosking at cs.purdue.edu  Thu Jun 24 01:09:35 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 23 Jun 2010 19:09:35 -0400
Subject: [M3devel] CHAR vs. Ctypes.char?
In-Reply-To: <COL101-W4372CBD0AF692D3E5990CCE6C50@phx.gbl>
References: <COL101-W44D06778829668CD8100FDE6C50@phx.gbl>,
	<9FB15BB1-E00A-4AB4-A580-71981F0A65C0@cs.purdue.edu>
	<COL101-W4372CBD0AF692D3E5990CCE6C50@phx.gbl>
Message-ID: <44BE3590-165E-42A2-AB10-4330DBE45205@cs.purdue.edu>

ADR isn't safe so why not just LOOPHOLE?

Sent from my iPhone

On Jun 23, 2010, at 6:52 PM, Jay K <jay.krell at cornell.edu> wrote:

>
> Something should change.
> I'm not sure exactly what but I'll make some suggestions.
>
>
> char_star changed from UNTRACED REF char to UNTRACED REF CHAR
>   Probably not this.
>   Possibly introduce Utypes.char_star = UNTRACED REF CHAR
>   but leave Ctypes.char_star alone. Possibly. This is I think the  
> least
>   likely option.
>
>
> and/or
>
>
> Utypes.CHAR_star introduced = UNTRACED REF CHAR
> many uses of char_star in m3core/src/unix changed to CHAR_star
>
>
> and/or
>
>
> Text.i3 already has FromChars that takes array of CHAR
> add function FromCChars or somesuch that takes array of Ctypes.char
> This I think is most likely.
> Even though it adds to a "standard" interface.
> It could be TextEx or TextExtras or such if that helps.
>
>
> In particular, we often have:
>
>
> Unix.i3: PROCEDURE GetFoo(char_star);
>
>
> Wrapper.i3:
> PROCEDURE GetFoo():TEXT=
> VAR buff; ARRAY [0..N] of CHAR;
> BEGIN
>   Unix.GetFoo(ADR(buff[0]));
>   RETURN Text.FromChars(buff);
> END GetFoo;
>
>
> This doesn't work with -new_adr.
>   because ADR(CHAR) != ADR(char).
>
>
> At a minimum you have to:
>   Unix.GetFoo(LOOPHOLE(ADR(buff[0]), ADDRESS));
>
>
> but I'd much rather something more typesafe.
>
>
> e.g.:
> Wrapper.i3:
> PROCEDURE GetFoo():TEXT=
> VAR buff; ARRAY [0..N] of Ctypes.char;
> BEGIN
>   Unix.GetFoo(ADR(buff[0]));
>   RETURN Text.FromCChars(buff);
> END GetFoo;
>
> or
>
> Unix.i3:
> PROCEDURE GetFoo(CHAR_star);
>
> Wrapper.i3:
> PROCEDURE GetFoo():TEXT=
> VAR buff; ARRAY [0..N] of CHAR;
> BEGIN
>   Unix.GetFoo(ADR(buff[0]));
>   RETURN Text.FromChars(buff);
> END GetFoo;
>
>
> or even something fancier like:
>
>
> Unix.i3:
> PROCEDURE GetFoo():TEXT; !
>
>
>
> To whatever extent this occurs in sysutils, if at all, probably have  
> to just LOOPHOLE,
> since it needs to be compatible with a mix of compilers and m3core.
>
>
>  - Jay
>
>
>
>
>
>
>
>
>
> ----------------------------------------
>> Subject: Re: [M3devel] CHAR vs. Ctypes.char?
>> From: hosking at cs.purdue.edu
>> Date: Wed, 23 Jun 2010 09:57:04 -0400
>> CC: m3devel at elegosoft.com
>> To: jay.krell at cornell.edu
>>
>> CHAR is an enumeration.
>> Ctypes.char is a subrange.
>>
>> Never the twain shall meet.
>>
>> On 23 Jun 2010, at 09:40, Jay K wrote:
>>
>>>
>>> Is it deliberate that CHAR and Ctypes.char don't match?
>>> I'm building the tree with -new_adr.
>>> "Many" of the breaks are due to this mismatch. Not real bugs. I  
>>> use LOOPHOLE to let it compile.
>>> "Many" are due to socklen_t. Real bugs on 64bit problems, at least  
>>> in head.
>>> I'm not sure there are any others yet.
>>>
>>> - Jay
>>>
>>
>


From jay.krell at cornell.edu  Thu Jun 24 04:24:47 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 24 Jun 2010 02:24:47 +0000
Subject: [M3devel] CHAR vs. Ctypes.char?
In-Reply-To: <44BE3590-165E-42A2-AB10-4330DBE45205@cs.purdue.edu>
References: <COL101-W44D06778829668CD8100FDE6C50@phx.gbl>, ,
	<9FB15BB1-E00A-4AB4-A580-71981F0A65C0@cs.purdue.edu>,
	<COL101-W4372CBD0AF692D3E5990CCE6C50@phx.gbl>,
	<44BE3590-165E-42A2-AB10-4330DBE45205@cs.purdue.edu>
Message-ID: <COL101-W53DD740C001143B75A1426E6C60@phx.gbl>


ADR should be "less unsafe".
Perhaps in general Modula-3 "unsafe" can/should be "less unsafe".
e.g. "Only as unsafe as needed to get the 'usual' job done, and no more".
 
 
Imagine if the types involved actually changed in some other way.
LOOPHOLE would likely make almost anything compile.
Whereas my other suggestions add a significant amount of type checking and deliberately fail to compile many incorrect forms.
 
 
There is not, or should be, this "harsh" line where there are no rules or static checking in unsafe code.
There is still a significant amount of checking and a significant confidence that if it compiles, it has a certain amount of correctness and "odds" of working. I've written a lot of C code, even recently. It's not just a lost cause.
 
 
 
 - Jay

----------------------------------------
> From: hosking at cs.purdue.edu
> To: jay.krell at cornell.edu
> Date: Wed, 23 Jun 2010 19:09:35 -0400
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] CHAR vs. Ctypes.char?
>
> ADR isn't safe so why not just LOOPHOLE?
>
> Sent from my iPhone
>
> On Jun 23, 2010, at 6:52 PM, Jay K wrote:
>
>>
>> Something should change.
>> I'm not sure exactly what but I'll make some suggestions.
>>
>>
>> char_star changed from UNTRACED REF char to UNTRACED REF CHAR
>> Probably not this.
>> Possibly introduce Utypes.char_star = UNTRACED REF CHAR
>> but leave Ctypes.char_star alone. Possibly. This is I think the
>> least
>> likely option.
>>
>>
>> and/or
>>
>>
>> Utypes.CHAR_star introduced = UNTRACED REF CHAR
>> many uses of char_star in m3core/src/unix changed to CHAR_star
>>
>>
>> and/or
>>
>>
>> Text.i3 already has FromChars that takes array of CHAR
>> add function FromCChars or somesuch that takes array of Ctypes.char
>> This I think is most likely.
>> Even though it adds to a "standard" interface.
>> It could be TextEx or TextExtras or such if that helps.
>>
>>
>> In particular, we often have:
>>
>>
>> Unix.i3: PROCEDURE GetFoo(char_star);
>>
>>
>> Wrapper.i3:
>> PROCEDURE GetFoo():TEXT=
>> VAR buff; ARRAY [0..N] of CHAR;
>> BEGIN
>> Unix.GetFoo(ADR(buff[0]));
>> RETURN Text.FromChars(buff);
>> END GetFoo;
>>
>>
>> This doesn't work with -new_adr.
>> because ADR(CHAR) != ADR(char).
>>
>>
>> At a minimum you have to:
>> Unix.GetFoo(LOOPHOLE(ADR(buff[0]), ADDRESS));
>>
>>
>> but I'd much rather something more typesafe.
>>
>>
>> e.g.:
>> Wrapper.i3:
>> PROCEDURE GetFoo():TEXT=
>> VAR buff; ARRAY [0..N] of Ctypes.char;
>> BEGIN
>> Unix.GetFoo(ADR(buff[0]));
>> RETURN Text.FromCChars(buff);
>> END GetFoo;
>>
>> or
>>
>> Unix.i3:
>> PROCEDURE GetFoo(CHAR_star);
>>
>> Wrapper.i3:
>> PROCEDURE GetFoo():TEXT=
>> VAR buff; ARRAY [0..N] of CHAR;
>> BEGIN
>> Unix.GetFoo(ADR(buff[0]));
>> RETURN Text.FromChars(buff);
>> END GetFoo;
>>
>>
>> or even something fancier like:
>>
>>
>> Unix.i3:
>> PROCEDURE GetFoo():TEXT; !
>>
>>
>>
>> To whatever extent this occurs in sysutils, if at all, probably have
>> to just LOOPHOLE,
>> since it needs to be compatible with a mix of compilers and m3core.
>>
>>
>> - Jay
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> ----------------------------------------
>>> Subject: Re: [M3devel] CHAR vs. Ctypes.char?
>>> From: hosking at cs.purdue.edu
>>> Date: Wed, 23 Jun 2010 09:57:04 -0400
>>> CC: m3devel at elegosoft.com
>>> To: jay.krell at cornell.edu
>>>
>>> CHAR is an enumeration.
>>> Ctypes.char is a subrange.
>>>
>>> Never the twain shall meet.
>>>
>>> On 23 Jun 2010, at 09:40, Jay K wrote:
>>>
>>>>
>>>> Is it deliberate that CHAR and Ctypes.char don't match?
>>>> I'm building the tree with -new_adr.
>>>> "Many" of the breaks are due to this mismatch. Not real bugs. I
>>>> use LOOPHOLE to let it compile.
>>>> "Many" are due to socklen_t. Real bugs on 64bit problems, at least
>>>> in head.
>>>> I'm not sure there are any others yet.
>>>>
>>>> - Jay
>>>>
>>>
>> 		 	   		  

From jay.krell at cornell.edu  Thu Jun 24 04:27:31 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 24 Jun 2010 02:27:31 +0000
Subject: [M3devel] CHAR vs. Ctypes.char?
In-Reply-To: <COL101-W53DD740C001143B75A1426E6C60@phx.gbl>
References: <COL101-W44D06778829668CD8100FDE6C50@phx.gbl>,
	, , <9FB15BB1-E00A-4AB4-A580-71981F0A65C0@cs.purdue.edu>, ,
	<COL101-W4372CBD0AF692D3E5990CCE6C50@phx.gbl>, ,
	<44BE3590-165E-42A2-AB10-4330DBE45205@cs.purdue.edu>,
	<COL101-W53DD740C001143B75A1426E6C60@phx.gbl>
Message-ID: <COL101-W3D4D5225FE282315363ECE6C60@phx.gbl>


oops...perhaps LOOPHOLE to "CHAR_star" or "char_star" not so bad.
  Program can read locally and decide quickly that basically char==CHAR and casting related to moving between them not so bad. If the types "really" change, it'd be to WCHAR or such and the LOOPHOLE to CHAR/char_star would still fail to compile.
 
LOOPHOLE to ADDRESS is what I'm avoiding.
 
?
 
Still, I like the idea of Text.FromCtypesChars() or such.
 
 
 - Jay


----------------------------------------
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> Date: Thu, 24 Jun 2010 02:24:47 +0000
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] CHAR vs. Ctypes.char?
>
>
> ADR should be "less unsafe".
> Perhaps in general Modula-3 "unsafe" can/should be "less unsafe".
> e.g. "Only as unsafe as needed to get the 'usual' job done, and no more".
>
>
> Imagine if the types involved actually changed in some other way.
> LOOPHOLE would likely make almost anything compile.
> Whereas my other suggestions add a significant amount of type checking and deliberately fail to compile many incorrect forms.
>
>
> There is not, or should be, this "harsh" line where there are no rules or static checking in unsafe code.
> There is still a significant amount of checking and a significant confidence that if it compiles, it has a certain amount of correctness and "odds" of working. I've written a lot of C code, even recently. It's not just a lost cause.
>
>
>
> - Jay
>
> ----------------------------------------
>> From: hosking at cs.purdue.edu
>> To: jay.krell at cornell.edu
>> Date: Wed, 23 Jun 2010 19:09:35 -0400
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] CHAR vs. Ctypes.char?
>>
>> ADR isn't safe so why not just LOOPHOLE?
>>
>> Sent from my iPhone
>>
>> On Jun 23, 2010, at 6:52 PM, Jay K wrote:
>>
>>>
>>> Something should change.
>>> I'm not sure exactly what but I'll make some suggestions.
>>>
>>>
>>> char_star changed from UNTRACED REF char to UNTRACED REF CHAR
>>> Probably not this.
>>> Possibly introduce Utypes.char_star = UNTRACED REF CHAR
>>> but leave Ctypes.char_star alone. Possibly. This is I think the
>>> least
>>> likely option.
>>>
>>>
>>> and/or
>>>
>>>
>>> Utypes.CHAR_star introduced = UNTRACED REF CHAR
>>> many uses of char_star in m3core/src/unix changed to CHAR_star
>>>
>>>
>>> and/or
>>>
>>>
>>> Text.i3 already has FromChars that takes array of CHAR
>>> add function FromCChars or somesuch that takes array of Ctypes.char
>>> This I think is most likely.
>>> Even though it adds to a "standard" interface.
>>> It could be TextEx or TextExtras or such if that helps.
>>>
>>>
>>> In particular, we often have:
>>>
>>>
>>> Unix.i3: PROCEDURE GetFoo(char_star);
>>>
>>>
>>> Wrapper.i3:
>>> PROCEDURE GetFoo():TEXT=
>>> VAR buff; ARRAY [0..N] of CHAR;
>>> BEGIN
>>> Unix.GetFoo(ADR(buff[0]));
>>> RETURN Text.FromChars(buff);
>>> END GetFoo;
>>>
>>>
>>> This doesn't work with -new_adr.
>>> because ADR(CHAR) != ADR(char).
>>>
>>>
>>> At a minimum you have to:
>>> Unix.GetFoo(LOOPHOLE(ADR(buff[0]), ADDRESS));
>>>
>>>
>>> but I'd much rather something more typesafe.
>>>
>>>
>>> e.g.:
>>> Wrapper.i3:
>>> PROCEDURE GetFoo():TEXT=
>>> VAR buff; ARRAY [0..N] of Ctypes.char;
>>> BEGIN
>>> Unix.GetFoo(ADR(buff[0]));
>>> RETURN Text.FromCChars(buff);
>>> END GetFoo;
>>>
>>> or
>>>
>>> Unix.i3:
>>> PROCEDURE GetFoo(CHAR_star);
>>>
>>> Wrapper.i3:
>>> PROCEDURE GetFoo():TEXT=
>>> VAR buff; ARRAY [0..N] of CHAR;
>>> BEGIN
>>> Unix.GetFoo(ADR(buff[0]));
>>> RETURN Text.FromChars(buff);
>>> END GetFoo;
>>>
>>>
>>> or even something fancier like:
>>>
>>>
>>> Unix.i3:
>>> PROCEDURE GetFoo():TEXT; !
>>>
>>>
>>>
>>> To whatever extent this occurs in sysutils, if at all, probably have
>>> to just LOOPHOLE,
>>> since it needs to be compatible with a mix of compilers and m3core.
>>>
>>>
>>> - Jay
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ----------------------------------------
>>>> Subject: Re: [M3devel] CHAR vs. Ctypes.char?
>>>> From: hosking at cs.purdue.edu
>>>> Date: Wed, 23 Jun 2010 09:57:04 -0400
>>>> CC: m3devel at elegosoft.com
>>>> To: jay.krell at cornell.edu
>>>>
>>>> CHAR is an enumeration.
>>>> Ctypes.char is a subrange.
>>>>
>>>> Never the twain shall meet.
>>>>
>>>> On 23 Jun 2010, at 09:40, Jay K wrote:
>>>>
>>>>>
>>>>> Is it deliberate that CHAR and Ctypes.char don't match?
>>>>> I'm building the tree with -new_adr.
>>>>> "Many" of the breaks are due to this mismatch. Not real bugs. I
>>>>> use LOOPHOLE to let it compile.
>>>>> "Many" are due to socklen_t. Real bugs on 64bit problems, at least
>>>>> in head.
>>>>> I'm not sure there are any others yet.
>>>>>
>>>>> - Jay
>>>>>
>>>>
>>> 		 	   		  

From jay.krell at cornell.edu  Thu Jun 24 11:46:27 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 24 Jun 2010 09:46:27 +0000
Subject: [M3devel] alignment in X.i3?
Message-ID: <COL101-W191F4612D5170DE1634C24E6C60@phx.gbl>


I don't suppose anyone else is seeing this?

-- building in AMD64_DARWIN ---

ignoring ../src/m3overrides

new source -> compiling XMachine.i3
new source -> compiling X.i3
"../src/Common/X.i3", line 1376: Could not find a legal alignment for the packed type.
"../src/Common/X.i3", line 1010: Could not find a legal alignment for the packed type.
2 errors encountered
new source -> compiling Xatom.i3
new source -> compiling Xmbuf.i3

I'll keep digging..
?- Jay

 		 	   		  

From jay.krell at cornell.edu  Thu Jun 24 12:01:10 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 24 Jun 2010 10:01:10 +0000
Subject: [M3devel] alignment in X.i3?
In-Reply-To: <COL101-W191F4612D5170DE1634C24E6C60@phx.gbl>
References: <COL101-W191F4612D5170DE1634C24E6C60@phx.gbl>
Message-ID: <COL101-W32744492F5C2FFF711E089E6C60@phx.gbl>


While I did this to myself by accident, there is a "real" question buried here.
I forgot I was experimenting with:

Index: 32BITS/BasicCtypes.i3
===================================================================
RCS file: /usr/cvs/cm3/m3-libs/m3core/src/C/32BITS/BasicCtypes.i3,v
retrieving revision 1.13
diff -u -r1.13 BasicCtypes.i3
--- 32BITS/BasicCtypes.i3??? 11 Feb 2010 12:24:33 -0000??? 1.13
+++ 32BITS/BasicCtypes.i3??? 24 Jun 2010 09:54:01 -0000
@@ -11,15 +11,15 @@
?
?TYPE
?? (* the four signed integer types *)
-? signed_char??????? = [-16_7f-1 .. 16_7f];
-? short_int????????? = [-16_7fff-1 .. 16_7fff];
-? int??????????????? = [-16_7fffffff-1 .. 16_7fffffff];
-? long_int?????????? = [-16_7fffffff-1 .. 16_7fffffff];
-? long_long????????? = [-16_7fffffffffffffffL-1L .. 16_7fffffffffffffffL];
+? signed_char??????? = BITS 8 FOR [-16_7f-1 .. 16_7f];
+? short_int????????? = BITS 16 FOR [-16_7fff-1 .. 16_7fff];
+? int??????????????? = BITS 32 FOR [-16_7fffffff-1 .. 16_7fffffff];
+? long_int?????????? = BITS 32 FOR [-16_7fffffff-1 .. 16_7fffffff];
+? long_long????????? = BITS 64 FOR [-16_7fffffffffffffffL-1L .. 16_7fffffffffffffffL];
?
?? (* the four unsigned integer types *)
-? unsigned_char????? = [16_0 .. 16_ff];
-? unsigned_short_int = [16_0 .. 16_ffff];
+? unsigned_char????? = BITS 8 FOR [16_0 .. 16_ff];
+? unsigned_short_int = BITS 16 FOR [16_0 .. 16_ffff];
?? unsigned_int?????? = Word.T;
?? unsigned_long_int? = Word.T;
?? unsigned_long_long = Long.T;
@@ -33,5 +33,3 @@
?? char?????????????? = signed_char;
?
?END BasicCtypes.
-
-
Index: 64BITS/BasicCtypes.i3
===================================================================
RCS file: /usr/cvs/cm3/m3-libs/m3core/src/C/64BITS/BasicCtypes.i3,v
retrieving revision 1.8
diff -u -r1.8 BasicCtypes.i3
--- 64BITS/BasicCtypes.i3??? 13 Apr 2008 19:44:02 -0000??? 1.8
+++ 64BITS/BasicCtypes.i3??? 24 Jun 2010 09:54:01 -0000
@@ -11,16 +11,16 @@
?
?TYPE
?? (* the four signed integer types *)
-? signed_char??????? = [-16_7f-1 .. 16_7f];
-? short_int????????? = [-16_7fff-1 .. 16_7fff];
-? int??????????????? = [-16_7fffffff-1 .. 16_7fffffff];
-? long_int?????????? = [-16_7fffffffffffffff -1? .. 16_7fffffffffffffff ];
-? long_long????????? = [-16_7fffffffffffffffL-1L .. 16_7fffffffffffffffL];
+? signed_char??????? = BITS 8 FOR [-16_7f-1 .. 16_7f];
+? short_int????????? = BITS 16 FOR [-16_7fff-1 .. 16_7fff];
+? int??????????????? = BITS 32 FOR [-16_7fffffff-1 .. 16_7fffffff];
+? long_int?????????? = BITS 64 FOR [-16_7fffffffffffffff -1? .. 16_7fffffffffffffff ];
+? long_long????????? = BITS 64 FOR [-16_7fffffffffffffffL-1L .. 16_7fffffffffffffffL];
?
?? (* the four unsigned integer types *)
-? unsigned_char????? = [16_0 .. 16_ff];
-? unsigned_short_int = [16_0 .. 16_ffff];
-? unsigned_int?????? = [16_0 .. 16_ffffffff];
+? unsigned_char????? = BITS 8 FOR [16_0 .. 16_ff];
+? unsigned_short_int = BITS 16 FOR [16_0 .. 16_ffff];
+? unsigned_int?????? = BITS 32 FOR [16_0 .. 16_ffffffff];
?? unsigned_long_int? = Word.T;
?? unsigned_long_long = Long.T;
?
@@ -33,5 +33,3 @@
?? char?????????????? = signed_char;
?
?END BasicCtypes.

and then I think there is a "hole" here:

? Int = int; Short = short; Long = long; Char = char;
? Bool????? = Int;

? XMotionEvent = RECORD
???? type: Int;???????????? (* of event *)

(* 32bits padding for alignment here likely *)

???? serial: unsigned_long; (* # of last request processed by server *)
???? send_event: Bool;????? (* true if this came from a SendEvent request *)

(* 32bits padding for alignment here likely also *)


???? display: DisplayStar;? (* Display the event was read from *)
???? window: Window;??????? (* "event" window reported relative to *)
???? root: Window;????????? (* root window that the event occured on *)
???? subwindow: Window;???? (* child window *)
???? time: Time;??????????? (* milliseconds *)
???? x, y: Int;???????????? (* pointer x, y coordinates in event window *)
???? x_root, y_root: Int;?? (* coordinates relative to root *)
???? state: unsigned_int;?? (* key or button mask *)
???? is_hint: Char;???????? (* detail *)
???? same_screen: Bool????? (* same screen flag *)
? END;


Am I write to be concerned with this cloning of header files?
Modula-3 probably inserts the holes/padding just like the C compiler probably inserts the holes/padding,
but it an area that deserves some extra close checking?


Like by passing the size of the record to some C that compares it to the size of the C type?
Or more aggressively the size/offset of each field?


Or maybe introducing a "more portable" C layer, where the "smallest" fields is an INTEGER or a LONGINT?


Or maybe soon someone else will apply some swig-like automation here, and generate the checks?


?- Jay


----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Date: Thu, 24 Jun 2010 09:46:27 +0000
> Subject: [M3devel] alignment in X.i3?
>
>
> I don't suppose anyone else is seeing this?
>
> -- building in AMD64_DARWIN ---
>
> ignoring ../src/m3overrides
>
> new source -> compiling XMachine.i3
> new source -> compiling X.i3
> "../src/Common/X.i3", line 1376: Could not find a legal alignment for the packed type.
> "../src/Common/X.i3", line 1010: Could not find a legal alignment for the packed type.
> 2 errors encountered
> new source -> compiling Xatom.i3
> new source -> compiling Xmbuf.i3
>
> I'll keep digging..
>  - Jay
>
>
 		 	   		  

From rodney_bates at lcwb.coop  Thu Jun 24 23:44:58 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Thu, 24 Jun 2010 16:44:58 -0500
Subject: [M3devel] alignment in X.i3?
In-Reply-To: <COL101-W32744492F5C2FFF711E089E6C60@phx.gbl>
References: <COL101-W191F4612D5170DE1634C24E6C60@phx.gbl>
	<COL101-W32744492F5C2FFF711E089E6C60@phx.gbl>
Message-ID: <4C23D1DA.60407@lcwb.coop>



Jay K wrote:
> While I did this to myself by accident, there is a "real" question buried here.
> I forgot I was experimenting with:
> 
> Index: 32BITS/BasicCtypes.i3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-libs/m3core/src/C/32BITS/BasicCtypes.i3,v
> retrieving revision 1.13
> diff -u -r1.13 BasicCtypes.i3
> --- 32BITS/BasicCtypes.i3    11 Feb 2010 12:24:33 -0000    1.13
> +++ 32BITS/BasicCtypes.i3    24 Jun 2010 09:54:01 -0000
> @@ -11,15 +11,15 @@
>  
>  TYPE
>    (* the four signed integer types *)
> -  signed_char        = [-16_7f-1 .. 16_7f];
> -  short_int          = [-16_7fff-1 .. 16_7fff];
> -  int                = [-16_7fffffff-1 .. 16_7fffffff];
> -  long_int           = [-16_7fffffff-1 .. 16_7fffffff];
> -  long_long          = [-16_7fffffffffffffffL-1L .. 16_7fffffffffffffffL];
> +  signed_char        = BITS 8 FOR [-16_7f-1 .. 16_7f];
> +  short_int          = BITS 16 FOR [-16_7fff-1 .. 16_7fff];
> +  int                = BITS 32 FOR [-16_7fffffff-1 .. 16_7fffffff];
> +  long_int           = BITS 32 FOR [-16_7fffffff-1 .. 16_7fffffff];
> +  long_long          = BITS 64 FOR [-16_7fffffffffffffffL-1L .. 16_7fffffffffffffffL];

This is a block I've been around before.  Packed (BITS) types are not what many
people seem to think.

1) They don't do anything at all for whole variables, parameters, etc. (Except
    create some non-assignabilities).  They *only* apply when used as the type of
    a record field, object field, or array element.

2) When they do apply, they require the compiler not only to use exactly the given
    number of bits, but also, to *add no padding* ahead of the field/element.

If 2) conflicts with normal alignment rules, or any other discretionary rules
the compiler uses (e.g., fields/elements cannot cross native word boundaries),
it may/must refuse.  And this means what you really need will vary from one
record/array to another.  This whole system  is really intended
only for explicit control of bit layouts of records and arrays.

I have finally gotten it that I never want to use BITS in a named type that
could be used in more than one place.  Instead, I always put the BITS in as
an anonymous part of the type of the field or element.  This avoids this
problem.  E.g.:

TYPE T = ...;
...
TYPE R = RECORD
            ...
            F: BITS 8 FOR T;
            ...
          END;

I really think this kind of explicit layout control is, for the most part,
incompatible with writing portable code.  Certainly, the original language
designers seem to have thought so.

It does raise another question.  To use LOOPHOLE, you have to know that the
BITSIZE values of the two types match up.  And what those are is implementation-
dependent.  So if, e.g., BITS 16 FOR [0..16_FF] must occupy 16 bits when a
field of a record, but the compiler might likely give it only 8 when an
autonomous variable (as it does now for [0..16_FF]), what is BITSIZE of
this type?  And I don't just mean what does the current implementation
do here.  I don't believe the language specifies this.

>  
>    (* the four unsigned integer types *)
> -  unsigned_char      = [16_0 .. 16_ff];
> -  unsigned_short_int = [16_0 .. 16_ffff];
> +  unsigned_char      = BITS 8 FOR [16_0 .. 16_ff];
> +  unsigned_short_int = BITS 16 FOR [16_0 .. 16_ffff];
>    unsigned_int       = Word.T;
>    unsigned_long_int  = Word.T;
>    unsigned_long_long = Long.T;
> @@ -33,5 +33,3 @@
>    char               = signed_char;
>  
>  END BasicCtypes.
> -
> -
> Index: 64BITS/BasicCtypes.i3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-libs/m3core/src/C/64BITS/BasicCtypes.i3,v
> retrieving revision 1.8
> diff -u -r1.8 BasicCtypes.i3
> --- 64BITS/BasicCtypes.i3    13 Apr 2008 19:44:02 -0000    1.8
> +++ 64BITS/BasicCtypes.i3    24 Jun 2010 09:54:01 -0000
> @@ -11,16 +11,16 @@
>  
>  TYPE
>    (* the four signed integer types *)
> -  signed_char        = [-16_7f-1 .. 16_7f];
> -  short_int          = [-16_7fff-1 .. 16_7fff];
> -  int                = [-16_7fffffff-1 .. 16_7fffffff];
> -  long_int           = [-16_7fffffffffffffff -1  .. 16_7fffffffffffffff ];
> -  long_long          = [-16_7fffffffffffffffL-1L .. 16_7fffffffffffffffL];
> +  signed_char        = BITS 8 FOR [-16_7f-1 .. 16_7f];
> +  short_int          = BITS 16 FOR [-16_7fff-1 .. 16_7fff];
> +  int                = BITS 32 FOR [-16_7fffffff-1 .. 16_7fffffff];
> +  long_int           = BITS 64 FOR [-16_7fffffffffffffff -1  .. 16_7fffffffffffffff ];
> +  long_long          = BITS 64 FOR [-16_7fffffffffffffffL-1L .. 16_7fffffffffffffffL];
>  
>    (* the four unsigned integer types *)
> -  unsigned_char      = [16_0 .. 16_ff];
> -  unsigned_short_int = [16_0 .. 16_ffff];
> -  unsigned_int       = [16_0 .. 16_ffffffff];
> +  unsigned_char      = BITS 8 FOR [16_0 .. 16_ff];
> +  unsigned_short_int = BITS 16 FOR [16_0 .. 16_ffff];
> +  unsigned_int       = BITS 32 FOR [16_0 .. 16_ffffffff];
>    unsigned_long_int  = Word.T;
>    unsigned_long_long = Long.T;
>  
> @@ -33,5 +33,3 @@
>    char               = signed_char;
>  
>  END BasicCtypes.
> 
> and then I think there is a "hole" here:
> 
>   Int = int; Short = short; Long = long; Char = char;
>   Bool      = Int;
> 
>   XMotionEvent = RECORD
>      type: Int;             (* of event *)
> 
> (* 32bits padding for alignment here likely *)
> 
>      serial: unsigned_long; (* # of last request processed by server *)
>      send_event: Bool;      (* true if this came from a SendEvent request *)
> 
> (* 32bits padding for alignment here likely also *)
> 
> 
>      display: DisplayStar;  (* Display the event was read from *)
>      window: Window;        (* "event" window reported relative to *)
>      root: Window;          (* root window that the event occured on *)
>      subwindow: Window;     (* child window *)
>      time: Time;            (* milliseconds *)
>      x, y: Int;             (* pointer x, y coordinates in event window *)
>      x_root, y_root: Int;   (* coordinates relative to root *)
>      state: unsigned_int;   (* key or button mask *)
>      is_hint: Char;         (* detail *)
>      same_screen: Bool      (* same screen flag *)
>   END;
> 
> 
> Am I write to be concerned with this cloning of header files?
> Modula-3 probably inserts the holes/padding just like the C compiler probably inserts the holes/padding,
> but it an area that deserves some extra close checking?
> 
> 
> Like by passing the size of the record to some C that compares it to the size of the C type?
> Or more aggressively the size/offset of each field?
> 
> 
> Or maybe introducing a "more portable" C layer, where the "smallest" fields is an INTEGER or a LONGINT?
> 
> 
> Or maybe soon someone else will apply some swig-like automation here, and generate the checks?
> 
> 
>  - Jay
> 
> 
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: m3devel at elegosoft.com
>> Date: Thu, 24 Jun 2010 09:46:27 +0000
>> Subject: [M3devel] alignment in X.i3?
>>
>>
>> I don't suppose anyone else is seeing this?
>>
>> -- building in AMD64_DARWIN ---
>>
>> ignoring ../src/m3overrides
>>
>> new source -> compiling XMachine.i3
>> new source -> compiling X.i3
>> "../src/Common/X.i3", line 1376: Could not find a legal alignment for the packed type.
>> "../src/Common/X.i3", line 1010: Could not find a legal alignment for the packed type.
>> 2 errors encountered
>> new source -> compiling Xatom.i3
>> new source -> compiling Xmbuf.i3
>>
>> I'll keep digging..
>>  - Jay
>>
>>
>  		 	   		  


From rodney_bates at lcwb.coop  Fri Jun 25 00:03:55 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Thu, 24 Jun 2010 17:03:55 -0500
Subject: [M3devel] LOOPHOLE and open array types
Message-ID: <4C23D64B.6050600@lcwb.coop>

The language definition says:
-------------------------------------------------------------------
An unchecked type transfer operation has the form:

     LOOPHOLE(e, T)

where e is an expression whose type is not an open array type and
T is a type.  It denotes e's bit pattern interpreted as a
variable or value of type T.  It is a designator if e is, and is
writable if e is.  An unchecked runtime error can occur if e's
bit pattern is not a legal T, or if e is a designator and some
legal bit pattern for T is not legal for e.

If T is not an open array type, BITSIZE(e) must equal
BITSIZE(T).  If T is an open array type, its element type must
not be an open array type, and e's bit pattern is interpreted as an
array whose length is BITSIZE(e) divided by BITSIZE(the element
type of T).  The division must come out even.
-------------------------------------------------------------------

Is there any reason not to allow e to have an open array type
*if* T is an open array type?  Element size of T would have to
evenly divide element size of e, to avoid runtime checks.

Other rules being the same, this would allow, e.g.:

PROCEDURE FromCtypes_chars (F: ARRAY OF Ctypes.char): TEXT

= BEGIN
     RETURN Text.FromChars(LOOPHOLE(F, ARRAY OF CHAR))
   END FromCtypes_chars

It would take a bit more implementation to handle the RT size of
e, but there is already the capability to produce a result value
of open array type.  The only difference would be the element
count would be element count of e times a constant instead of
just a constant.


From rodney_bates at lcwb.coop  Fri Jun 25 00:25:02 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Thu, 24 Jun 2010 17:25:02 -0500
Subject: [M3devel] -new_adr the default?
In-Reply-To: <COL101-W54C167232C5F9B2A6C4963E6C50@phx.gbl>
References: <COL101-W54C167232C5F9B2A6C4963E6C50@phx.gbl>
Message-ID: <4C23DB3E.7010603@lcwb.coop>



Jay K wrote:
> I'd like to make -new_adr the default.
> It is more typesafe than the current way and finds bugs.
>   Granted, so far I think only bugs that I introduced.
> 
> 
> First I will make the tree compile either way.
>  Such as by fixing the bugs and resolving somehow the char vs. CHAR breaks.
> 
> 
> Changing this does break code, albeit only unsafe code.
>   There isn't much of that? Right? :)
> Sometimes that code had bugs, sometimes not.
> 
> 
> I believe type safety and static checking (and sometimes runtime checking) do have a place in unsafe code.
>  Maybe not as much as in safe code, but definitely still something.
> 
> 
> The old way is that ADR return ADDRESS, similar to void*, and it is silently convertable to any pointer type. I think.
                                                                 ^
Yes, but only in UNSAFE code.  OtherPointerType <: ADDRESS.
> 
> 
> The new way is that ADR(T) returns UNTRACED REF T is is only silently convertable to ADDRESS? 
                                                        ^
Yes, even in safe code, because of the same subtype relation.

Or nothing at all?
>  Esp. not silently convertable to UNTRACED REF U.
Yes, this would require an explicit LOOPHOLE.  Or, you could convert in two steps,
to a variable of ADDRESS first, then to UNTRACED REF U.  Both require UNSAFE.

> 
> 
> So there are buggy places that do:
> PROCEDURE Foo(UNTRACED REF T);
> 
> PROCEDURE Bar()
> VAR u: U;

Not sure what this is doing, but it seems like just changing to VAR u: T; ought
to work too.  It would compile with either semantics of ADR.

> BEGIN
>  Foo(ADR(u));
> END Bar;
> 
> 
> That compile with old ADR but not with new ADR.
> As I changed socklent_t between int and INTEGER, such code silently kept compiling.
>   But possibly silently corrupting the stack or producing the wrong data.
> 
> 
> This -new_adr feature was already implemented in the compiler unknown long ago.
>   I didn't know but Tony pointed it out.
> We should probably look at its impementation make sure we aren't switching on some buggy unused code.
> So far switching it on I've only seen correct new errors.
> 
> 
>  - Jay
>  		 	   		  


From jay.krell at cornell.edu  Fri Jun 25 11:48:48 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 25 Jun 2010 09:48:48 +0000
Subject: [M3devel] gcc 4.5 static chain
Message-ID: <COL101-W4975CA91E3B1ED2707FA48E6C70@phx.gbl>


Here's some background as to why it is taking me so long to
get gcc 4.5 working.


Two of gcc's internal data structures are "tree" and "gimple".


"tree" is a somewhat intuitive structure that roughly
corresponds to a C AST ("abstract syntax tree").
It has stuff like plus, and call.
I believe it is meant to support any gcc frontend: Ada, Java, etc.


"tree" is produced by the C frontend and our "parse.c"
?(The Modula-3 gcc backend is structured as a gcc frontend,
?producing similar in-memory data as the C frontend. "backend"
?and "frontend" get confused.)


I believe "tree" has been there "forever", for as long
as DEC SRC Modula-3 has had a gcc backend.
(2.x presumably)


"gimple" is very much like tree, but it is less general.
it is more amenable to optimization.
Things like loops are deconstructed into goto.
I think.


"gimple" is newer, like dating to gcc 4.x.
Previously optimization operated on tree and/or rtx and neither was great.
rtx is too low level. tree is too high level.


Gimple I think was originally just exactly tree but with
some of the node types not used. Confusing. Faster to write it,
reused the tree code, but confusing. Gives "tree" multiple meanings.
In 4.4 or 4.5 they made it its own type.
I think, for one thing, it now is made up of nodes with small arrays
instead of nodes with node pointers.



Or something like this.
I'm mostly just repeating what you can read online elsewhere from
?more authoritative and clearer sources.
?

So, at some point, "tree" is converted to "gimple".
? Though, this is a very confusing point to me.
? It appears that really the compiler deals with a significant
? mix of "tree" and "gimple". Perhaps that is inevitable. Perhaps
? tree can only be gradually converted to gimple.
? 

Anyway, among the "tree codes" such as plus, call, etc., we add one.
We add to load a static link.
For the current function?
For a specific function to be called?
I find this point not obvious.


So then, given that we have introduced a tree code, we must teach
other parts of gcc about it.


Tangent.


tree-nested.c converts nested functions into non-nested functions.
As needed, it moves locals into structs, adds "display" parameters
to nested functions, changes references to outer locals into
accesses through the "display", etc.


Again, this is a transformation we probably could/should make ourselves in m3front.


Only the locals that are actually accessed are moved into a local struct.
Presumably only nested functions that reference outer locals get the extra parameter.
And so on.


In gcc-4.3/tree-nested.c we deal with our tree code.
We appear to do two things:
?
?- we ensure that the function we are getting a static link for has one
??? I don't understand that actually. gcc is already doing similar.
??? Why do we need to do more? 
? 
? - it replaces the load of the static link with, uh, the load of the
??? static link -- it replaces the tree node with our custom tree code
??? with the tree node representing actually computing/getting the value we want
??? It is a little fishy to me btw how this is done.
??? Is overwriting *tp really the way?
??? In 4.5 there are functions to insert/after/replace within the gimple
??? iterator. I wonder if there is similar in 4.3.


Now, the difference in 4.5 is that "gimplification" happens earlier.
The code in 4.3 that we change to deal with tree and our custom tree code,
is now dealing with gimple instead.


Therefore, I believe part of the 4.5 change is a simple translation
of the tree code to a new gimple code.


And then some corresponding change in 4.5.


Btw, it appears gimplify_expr is also a "lang hook", which means
more of our code can move out of line to parse.c.


I haven't figured it all out yet.


I should further note that gcc's notion of a nested function is almost
identical to Modula-3's.


You know, this movement of locals into a local struct, the accepting
an extra parameter pointing to that struct in nested functions, gcc
and Modula-3 are the same.


Therefore tree-nested.c does a lot of work and it is almost all useful/relevant
to us.


The difference is only what happens when you take the address of a nested function.
Or perhaps when you call them.


gcc generates a little bit of code at runtime to add the static link parameter
?(e.g. on x86/AMD64 to load into a designated register: r10 for AMD64, ecx for x86,
?see the function ix86_static_chain).
Modula-3 generates a little bit of data: marker, function pointer, static chain,
and the caller does extra work.


There are significant tradeoffs either way and there is, I'm convinced,
absolutely no good way to do this.
gcc generates code at runtime, generally on the stack.
? These days the stack is not by default executable, in order to
? protect against viruses etc. overflowing buffers on the stack
? and writing code to the stack.
Modula-3 has to check function pointers before calling them.


As I said, neither is good, there's no good solution.
? Better perhaps to do the transform yourself. Then you have
? the option of putting the context on the stack or heap as well.
? Better perhaps to expose programmer to the cost. Perhaps.


Perhaps the C ABIs could have reserved a register for this, but I'm not sure
that makes sense. Would you load it up and it remains preserved until changed?


But I digressed.


?- Jay 		 	   		  

From ttmrichter at gmail.com  Fri Jun 25 17:07:21 2010
From: ttmrichter at gmail.com (Michael Richter)
Date: Fri, 25 Jun 2010 23:07:21 +0800
Subject: [M3devel] gcc vs. clang as back-end
Message-ID: <AANLkTik63tUQqujL3yUi5MH8rOApxcqj8hMl5LuXTpqu@mail.gmail.com>

I've just read Jay K's long message about problems integrating with gcc 4.5.
 The LLVM project has clang out now which is ready for prime time as a C or
Objective-C compiler (not yet there for C++, but that's out of scope for CM3
I'd guess).  Since clang was specifically designed, as one of its goals, to
be easy to use as a form of library, would it not perhaps be better to start
using clang as a back-end instead of any version of gcc (which is
notoriously difficult to write front-ends, back-ends or tools for)?

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

From hosking at cs.purdue.edu  Fri Jun 25 17:46:39 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 25 Jun 2010 11:46:39 -0400
Subject: [M3devel] gcc vs. clang as back-end
In-Reply-To: <AANLkTik63tUQqujL3yUi5MH8rOApxcqj8hMl5LuXTpqu@mail.gmail.com>
References: <AANLkTik63tUQqujL3yUi5MH8rOApxcqj8hMl5LuXTpqu@mail.gmail.com>
Message-ID: <FDE20D78-F7CA-40B3-B2D4-66A0AA8CF274@cs.purdue.edu>

Hi Michael,

CM3 has a front-end compiler written in Modula-3 that targets an M3-specific IR.  Currently, that M3 IR is parsed and compiled by a simple front-end to gcc to generate assembler.  It's not clear that Clang itself is the way to go.  Rather, I think it would be better to build a translator from M3 IR to LLVM IR.

It would be much more effort to build a whole new M3 front-end around Clang.  Or do I misunderstand your suggestion?

-- Tony

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 25 Jun 2010, at 11:07, Michael Richter wrote:

> I've just read Jay K's long message about problems integrating with gcc 4.5.  The LLVM project has clang out now which is ready for prime time as a C or Objective-C compiler (not yet there for C++, but that's out of scope for CM3 I'd guess).  Since clang was specifically designed, as one of its goals, to be easy to use as a form of library, would it not perhaps be better to start using clang as a back-end instead of any version of gcc (which is notoriously difficult to write front-ends, back-ends or tools for)?
> 
> -- 
> "Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot."
> --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra.

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

From jay.krell at cornell.edu  Sat Jun 26 03:53:45 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 26 Jun 2010 01:53:45 +0000
Subject: [M3devel] gcc vs. clang as back-end
In-Reply-To: <FDE20D78-F7CA-40B3-B2D4-66A0AA8CF274@cs.purdue.edu>
References: <AANLkTik63tUQqujL3yUi5MH8rOApxcqj8hMl5LuXTpqu@mail.gmail.com>,
	<FDE20D78-F7CA-40B3-B2D4-66A0AA8CF274@cs.purdue.edu>
Message-ID: <COL101-W22F8C5289770196CD70115E6C80@phx.gbl>


gcc probably isn't as bad as people say.
?Most people are talking about C or C++ compilation, which is architecturally very problematic due the lack of a well designed module system. The same content gets parsed countless times.

? Any speed up you can make, apparently clang has made a few, will be multiplied by a very large amount.


clang doesn't make sense, for a Modula-3 backend.
LLVM does.
Anyone, yes, please feel free to contribute an LLVM backend.


I'll keep poking at the static chain stuff for now.


Thanks,
?- Jay

________________________________
> From: hosking at cs.purdue.edu
> Date: Fri, 25 Jun 2010 11:46:39 -0400
> To: ttmrichter at gmail.com
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] gcc vs. clang as back-end
>
>
>
> Hi Michael,
>
> CM3 has a front-end compiler written in Modula-3 that targets an M3-specific IR. Currently, that M3 IR is parsed and compiled by a simple front-end to gcc to generate assembler. It's not clear that Clang itself is the way to go. Rather, I think it would be better to build a translator from M3 IR to LLVM IR.
>
> It would be much more effort to build a whole new M3 front-end around Clang. Or do I misunderstand your suggestion?
>
> -- Tony
>
>
>
> 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 25 Jun 2010, at 11:07, Michael Richter wrote:
>
> I've just read Jay K's long message about problems integrating with gcc 4.5. The LLVM project has clang out now which is ready for prime time as a C or Objective-C compiler (not yet there for C++, but that's out of scope for CM3 I'd guess). Since clang was specifically designed, as one of its goals, to be easy to use as a form of library, would it not perhaps be better to start using clang as a back-end instead of any version of gcc (which is notoriously difficult to write front-ends, back-ends or tools for)?
>
>
> --
> "Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot."
>
>
> --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra.
>
>
 		 	   		  

From jay.krell at cornell.edu  Sat Jun 26 14:51:47 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 26 Jun 2010 12:51:47 +0000
Subject: [M3devel] gcc 4.5 and how to pass the static link
Message-ID: <COL101-W17562D51BBB958218397FFE6C80@phx.gbl>


ok, I got "man vs. boy" to work.


Now I'm going back and revisiting some diffs I have, try to reduce them.
There isn't much.


I'm going to commit something that will seem odd,
and isn't easy to explain, and that I might not fully understand.


Here is what I suspect though.


In gcc 4.3, how to pass a static chain is always the same for each architecture.
?I think.
?
?
In 4.5, it depends on the function being called. At least for some architectures.
See the function ix86_static_chain.
x86 functions can have varying calling conventions, so how to pass
the static chain can vary from function to function.


This doesn't make complete sense for Modula-3 though.
We pass the static chain for function pointers as well.
?And gcc never does, because function pointers are "flattened" via "trampolines".
?That is, the caller of a function pointer doesn't have to pass a static link.
?A trampoline is built to pass it.
?Err. It does make partial sense. Function pointers still have calling conventions.


calls.c:prepare_call_address:
? if (static_chain_value != 0)
??? {
????? rtx chain;

????? gcc_assert (fndecl);
????? chain = targetm.calls.static_chain (fndecl, false);
????? static_chain_value = convert_memory_address (Pmode, static_chain_value);

????? emit_move_insn (chain, static_chain_value);
????? if (REG_P (chain))
??? use_reg (call_fusage, chain);
??? }


the assertion fails here:

m3-sys/m3link:

PROCEDURE ForEachUnit (VAR s: State;? p: UnitProc) =
? VAR x: MxMap.Contents;? u: Mx.Unit;
? BEGIN
??? x := MxMap.GetData (s.base.interfaces);
??? FOR i := 0 TO LAST (x^) DO
????? u := x[i].value;
????? IF (u # NIL) THEN p (s, u) END;??? *** here ***
??? END;
??? x := MxMap.GetData (s.base.modules);
??? FOR i := 0 TO LAST (x^) DO
????? u := x[i].value;
????? IF (u # NIL) THEN p (s, u) END;
??? END;
??? x := MxMap.GetData (s.base.virtuals);
??? FOR i := 0 TO LAST (x^) DO
????? u := x[i].value;
????? IF (u # NIL) THEN p (s, u) END;
??? END;
? END ForEachUnit;
? 
? 
So I'm going to quite alter that code to allow null and in such case
use the register 4.3 would have (ECX).


Arguably even for non-null we should do that.
We only support __cdecl and __stdcall, and ECX is correct for either.
gcc supports __fastcall and it appears possibly custom calling conventions.


?- Jay
 		 	   		  

From rcolebur at SCIRES.COM  Sat Jun 26 18:00:57 2010
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Sat, 26 Jun 2010 12:00:57 -0400
Subject: [M3devel] syntax errs in hand.c
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E605DBF557@ATLEX02-SRV.SCIRES.LOCAL>

Jay:

I'm getting compile errors in hand.c on Windows from the HEAD branch.

Regards,
Randy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100626/e067ca9f/attachment-0001.html>

From jay.krell at cornell.edu  Sun Jun 27 03:05:37 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 27 Jun 2010 01:05:37 +0000
Subject: [M3devel] syntax errs in hand.c
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E605DBF557@ATLEX02-SRV.SCIRES.LOCAL>
References: <D67F02DDC62F7545A6B84C285F88F3E605DBF557@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <COL101-W368E851606052D84250E89E6C90@phx.gbl>


Randy, can you please fix them?

Thanks,
?- Jay

________________________________
> From: rcolebur at SCIRES.COM
> To: m3devel at elegosoft.com
> Date: Sat, 26 Jun 2010 12:00:57 -0400
> Subject: [M3devel] syntax errs in hand.c
>
> Jay:
>
> I?m getting compile errors in hand.c on Windows from
> the HEAD branch.
>
> Regards,
>> Randy
 		 	   		  

From jay.krell at cornell.edu  Sun Jun 27 10:12:54 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 27 Jun 2010 08:12:54 +0000
Subject: [M3devel] m3cg 4.5 problem
Message-ID: <COL101-W728051433DA06972261F1E6C90@phx.gbl>


This tiny bit of code, which is cut down from m3front, causes an assertion failure in a 4.5 m3cg:
MODULE TypeCaseStmt;
IMPORT M3ID, CG, Expr, Stmt, StmtRep, Type, Variable, Scope;
PROCEDURE GetOutcomex (): Stmt.Outcomes =  VAR oc := Stmt.Outcomes {};  line 6  BEGIN    RETURN oc;  END GetOutcomex;
BEGINEND TypeCaseStmt.
../src/stmts/TypeCaseStmt.m3:6:0: internal compiler error: in gimplify_expr, at gimplify.c:7315Please submit a full bug report,

(1) begin_unit(2) set_source_file(3) set_source_line  source line    1(4) comment  comment: `module global constants'(5) declare_segment  segment L_1 typeid 0xffffffff(6) comment  comment: `module global data'(7) declare_segment  segment MM_TypeCaseStmt typeid 0xffffffff(8) set_source_line  source line   11(9) declare_procedure  type:addr  procedure:TypeCaseStmt_M3 nparams:0x1 rettype:addr lev:0 exported:1(10) declare_param  type:int64  param M3_AcxOUs_mode type:int64 typeid:0x195c2a74 bytesize:0x40 alignment:0x40 in_memory:0x0 up_level:0x0  mode 0x11 (DImode)(11) import_procedure  type:addr  procedure:TypeCaseStmt_I3 nparams:0x0 rettype:addr(12) export_unit(13) import_procedure  type:addr  procedure:Scope_I3 nparams:0x0 rettype:addr(14) import_unit(15) import_procedure  type:addr  procedure:Variable_I3 nparams:0x0 rettype:addr(16) import_unit(17) import_procedure  type:addr  procedure:Type_I3 nparams:0x0 rettype:addr(18) import_unit(19) import_procedure  type:addr  procedure:StmtRep_I3 nparams:0x0 rettype:addr(20) import_unit(21) import_procedure  type:addr  procedure:Stmt_I3 nparams:0x0 rettype:addr(22) import_unit(23) import_procedure  type:addr  procedure:Expr_I3 nparams:0x0 rettype:addr(24) import_unit(25) import_procedure  type:addr  procedure:CG_I3 nparams:0x0 rettype:addr(26) import_unit(27) import_procedure  type:addr  procedure:M3ID_I3 nparams:0x0 rettype:addr(28) import_unit(29) import_procedure  type:addr  procedure:RTHooks_I3 nparams:0x0 rettype:addr(30) import_unit(31) declare_procedure  type:word64  procedure:TypeCaseStmt__GetOutcomex nparams:0x0 rettype:word64 lev:0 exported:0(32) declare_local  type:word64  local var M3_EXQtd6_oc type:word64 size:0x40 alignment:0x40(33) declare_local  type:word64  local var M3_EXQtd6__result type:word64 size:0x40 alignment:0x40(34) comment  comment: `GetOutcomex'(35) set_source_line  source line    5(36) begin_procedure  procedure TypeCaseStmt__GetOutcomex TypeCaseStmt__GetOutcomex(37) set_source_line  source line    6(38) load_integer  type:int64  integer:0x0(39) store  type:int64  type:int64  store (M3_EXQtd6_oc) offset:0x0 src_t:int64 dst_t:int64(40) set_source_line  source line    8(41) load  type:word64  type:int64  m3cg_load (M3_EXQtd6_oc): offset 0x0, convert word64 -> int64(42) exit_proc  type:word64(43) end_procedure  procedure TypeCaseStmt__GetOutcomex

Breakpoint 1, fancy_abort (file=0x1009f0c6f "../../gcc-4.5/gcc/gimplify.c", line=7315, function=0x1009f1242 "gimplify_expr") at ../../gcc-4.5/gcc/diagnostic.c:763763	  internal_error ("in %s, at %s:%d", function, trim_filename (file), line);(gdb) bt#0  fancy_abort (file=0x1009f0c6f "../../gcc-4.5/gcc/gimplify.c", line=7315, function=0x1009f1242 "gimplify_expr") at ../../gcc-4.5/gcc/diagnostic.c:763#1  0x00000001004cc4d6 in gimplify_expr (expr_p=0x1410e2060, pre_p=0x7fff5fbff420, post_p=0x7fff5fbfeff8, gimple_test_f=0x1004aac7f <is_gimple_lvalue>, fallback=2) at ../../gcc-4.5/gcc/gimplify.c:7315#2  0x00000001004c5ad3 in gimplify_modify_expr (expr_p=0x1416a5f28, pre_p=0x7fff5fbff420, post_p=0x7fff5fbfeff8, want_value=0 '\0') at ../../gcc-4.5/gcc/gimplify.c:4444#3  0x00000001004caafc in gimplify_expr (expr_p=0x1416a5f28, pre_p=0x7fff5fbff420, post_p=0x7fff5fbfeff8, gimple_test_f=0x1004ab1a6 <is_gimple_stmt>, fallback=0) at ../../gcc-4.5/gcc/gimplify.c:6619#4  0x00000001004c7800 in gimplify_stmt (stmt_p=0x1416a5f28, seq_p=0x7fff5fbff420) at ../../gcc-4.5/gcc/gimplify.c:5264#5  0x00000001004be376 in gimplify_statement_list (expr_p=0x1416c4030, pre_p=0x7fff5fbff420) at ../../gcc-4.5/gcc/gimplify.c:1382#6  0x00000001004cb6f5 in gimplify_expr (expr_p=0x1416c4030, pre_p=0x7fff5fbff420, post_p=0x7fff5fbff2e8, gimple_test_f=0x1004ab1a6 <is_gimple_stmt>, fallback=0) at ../../gcc-4.5/gcc/gimplify.c:6935#7  0x00000001004c7800 in gimplify_stmt (stmt_p=0x1416c4030, seq_p=0x7fff5fbff420) at ../../gcc-4.5/gcc/gimplify.c:5264#8  0x00000001004bdb6c in gimplify_bind_expr (expr_p=0x1416c2298, pre_p=0x7fff5fbff778) at ../../gcc-4.5/gcc/gimplify.c:1127#9  0x00000001004cae2b in gimplify_expr (expr_p=0x1416c2298, pre_p=0x7fff5fbff778, post_p=0x7fff5fbff618, gimple_test_f=0x1004ab1a6 <is_gimple_stmt>, fallback=0) at ../../gcc-4.5/gcc/gimplify.c:6719#10 0x00000001004c7800 in gimplify_stmt (stmt_p=0x1416c2298, seq_p=0x7fff5fbff778) at ../../gcc-4.5/gcc/gimplify.c:5264#11 0x00000001004ccbe6 in gimplify_body (body_p=0x1416c2298, fndecl=0x1416c2200, do_parms=1 '\001') at ../../gcc-4.5/gcc/gimplify.c:7528#12 0x00000001004cceae in gimplify_function_tree (fndecl=0x1416c2200) at ../../gcc-4.5/gcc/gimplify.c:7624#13 0x00000001000069c7 in m3_gimplify_function (fndecl=0x1416c2200) at ../../gcc-4.5/gcc/m3cg/parse.c:2370#14 0x0000000100009cb4 in m3cg_end_procedure () at ../../gcc-4.5/gcc/m3cg/parse.c:3642#15 0x000000010000feb5 in m3_parse_file (xx=0) at ../../gcc-4.5/gcc/m3cg/parse.c:5550#16 0x00000001006be6a2 in compile_file () at ../../gcc-4.5/gcc/toplev.c:1053#17 0x00000001006c0e19 in do_compile () at ../../gcc-4.5/gcc/toplev.c:2415#18 0x00000001006c0ee0 in toplev_main (argc=3, argv=0x7fff5fbff930) at ../../gcc-4.5/gcc/toplev.c:2457#19 0x000000010001743b in main (argc=3, argv=0x7fff5fbff930) at ../../gcc-4.5/gcc/main.c:35(

Wierd, huh?
The only thing I can think of an int/word mismatch.I did change one instance of Integer to Word, after finding this.Stmt.Outcomes is an enumeration.So presumably Stmt.Outcomes { } is 0.Enumerations should work equally well as Integer or Word, right?Clearly above there is still a mix. I can try changing them all to Word.

I'll keep digging.

Maybe dump the entire function generic tree for this and similar C.

 - Jay 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100627/1814fee7/attachment-0001.html>

From jay.krell at cornell.edu  Sun Jun 27 11:23:13 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 27 Jun 2010 09:23:13 +0000
Subject: [M3devel] m3cg 4.5 problem
In-Reply-To: <COL101-W728051433DA06972261F1E6C90@phx.gbl>
References: <COL101-W728051433DA06972261F1E6C90@phx.gbl>
Message-ID: <COL101-W2519C65D63208BF55620CE6C90@phx.gbl>


I was a bit off. It is actually set of enum. Like this:
MODULE TypeCaseStmt;
TYPE T1 = {A,B};TYPE T2 = SET OF T1; PROCEDURE GetOutcomex (): T2 =  VAR oc := T2 {};  BEGIN    RETURN oc;  END GetOutcomex;
BEGINEND TypeCaseStmt.
 - Jay
From: jay.krell at cornell.edu
To: m3devel at elegosoft.com; hosking at cs.purdue.edu
Date: Sun, 27 Jun 2010 08:12:54 +0000
Subject: [M3devel] m3cg 4.5 problem








This tiny bit of code, which is cut down from m3front, causes an assertion failure in a 4.5 m3cg:
MODULE TypeCaseStmt;
IMPORT M3ID, CG, Expr, Stmt, StmtRep, Type, Variable, Scope;
PROCEDURE GetOutcomex (): Stmt.Outcomes =  VAR oc := Stmt.Outcomes {};  line 6  BEGIN    RETURN oc;  END GetOutcomex;
BEGINEND TypeCaseStmt.
../src/stmts/TypeCaseStmt.m3:6:0: internal compiler error: in gimplify_expr, at gimplify.c:7315Please submit a full bug report,

(1) begin_unit(2) set_source_file(3) set_source_line  source line    1(4) comment  comment: `module global constants'(5) declare_segment  segment L_1 typeid 0xffffffff(6) comment  comment: `module global data'(7) declare_segment  segment MM_TypeCaseStmt typeid 0xffffffff(8) set_source_line  source line   11(9) declare_procedure  type:addr  procedure:TypeCaseStmt_M3 nparams:0x1 rettype:addr lev:0 exported:1(10) declare_param  type:int64  param M3_AcxOUs_mode type:int64 typeid:0x195c2a74 bytesize:0x40 alignment:0x40 in_memory:0x0 up_level:0x0  mode 0x11 (DImode)(11) import_procedure  type:addr  procedure:TypeCaseStmt_I3 nparams:0x0 rettype:addr(12) export_unit(13) import_procedure  type:addr  procedure:Scope_I3 nparams:0x0 rettype:addr(14) import_unit(15) import_procedure  type:addr  procedure:Variable_I3 nparams:0x0 rettype:addr(16) import_unit(17) import_procedure  type:addr  procedure:Type_I3 nparams:0x0 rettype:addr(18) import_unit(19) import_procedure  type:addr  procedure:StmtRep_I3 nparams:0x0 rettype:addr(20) import_unit(21) import_procedure  type:addr  procedure:Stmt_I3 nparams:0x0 rettype:addr(22) import_unit(23) import_procedure  type:addr  procedure:Expr_I3 nparams:0x0 rettype:addr(24) import_unit(25) import_procedure  type:addr  procedure:CG_I3 nparams:0x0 rettype:addr(26) import_unit(27) import_procedure  type:addr  procedure:M3ID_I3 nparams:0x0 rettype:addr(28) import_unit(29) import_procedure  type:addr  procedure:RTHooks_I3 nparams:0x0 rettype:addr(30) import_unit(31) declare_procedure  type:word64  procedure:TypeCaseStmt__GetOutcomex nparams:0x0 rettype:word64 lev:0 exported:0(32) declare_local  type:word64  local var M3_EXQtd6_oc type:word64 size:0x40 alignment:0x40(33) declare_local  type:word64  local var M3_EXQtd6__result type:word64 size:0x40 alignment:0x40(34) comment  comment: `GetOutcomex'(35) set_source_line  source line    5(36) begin_procedure  procedure TypeCaseStmt__GetOutcomex TypeCaseStmt__GetOutcomex(37) set_source_line  source line    6(38) load_integer  type:int64  integer:0x0(39) store  type:int64  type:int64  store (M3_EXQtd6_oc) offset:0x0 src_t:int64 dst_t:int64(40) set_source_line  source line    8(41) load  type:word64  type:int64  m3cg_load (M3_EXQtd6_oc): offset 0x0, convert word64 -> int64(42) exit_proc  type:word64(43) end_procedure  procedure TypeCaseStmt__GetOutcomex

Breakpoint 1, fancy_abort (file=0x1009f0c6f "../../gcc-4.5/gcc/gimplify.c", line=7315, function=0x1009f1242 "gimplify_expr") at ../../gcc-4.5/gcc/diagnostic.c:763763	  internal_error ("in %s, at %s:%d", function, trim_filename (file), line);(gdb) bt#0  fancy_abort (file=0x1009f0c6f "../../gcc-4.5/gcc/gimplify.c", line=7315, function=0x1009f1242 "gimplify_expr") at ../../gcc-4.5/gcc/diagnostic.c:763#1  0x00000001004cc4d6 in gimplify_expr (expr_p=0x1410e2060, pre_p=0x7fff5fbff420, post_p=0x7fff5fbfeff8, gimple_test_f=0x1004aac7f <is_gimple_lvalue>, fallback=2) at ../../gcc-4.5/gcc/gimplify.c:7315#2  0x00000001004c5ad3 in gimplify_modify_expr (expr_p=0x1416a5f28, pre_p=0x7fff5fbff420, post_p=0x7fff5fbfeff8, want_value=0 '\0') at ../../gcc-4.5/gcc/gimplify.c:4444#3  0x00000001004caafc in gimplify_expr (expr_p=0x1416a5f28, pre_p=0x7fff5fbff420, post_p=0x7fff5fbfeff8, gimple_test_f=0x1004ab1a6 <is_gimple_stmt>, fallback=0) at ../../gcc-4.5/gcc/gimplify.c:6619#4  0x00000001004c7800 in gimplify_stmt (stmt_p=0x1416a5f28, seq_p=0x7fff5fbff420) at ../../gcc-4.5/gcc/gimplify.c:5264#5  0x00000001004be376 in gimplify_statement_list (expr_p=0x1416c4030, pre_p=0x7fff5fbff420) at ../../gcc-4.5/gcc/gimplify.c:1382#6  0x00000001004cb6f5 in gimplify_expr (expr_p=0x1416c4030, pre_p=0x7fff5fbff420, post_p=0x7fff5fbff2e8, gimple_test_f=0x1004ab1a6 <is_gimple_stmt>, fallback=0) at ../../gcc-4.5/gcc/gimplify.c:6935#7  0x00000001004c7800 in gimplify_stmt (stmt_p=0x1416c4030, seq_p=0x7fff5fbff420) at ../../gcc-4.5/gcc/gimplify.c:5264#8  0x00000001004bdb6c in gimplify_bind_expr (expr_p=0x1416c2298, pre_p=0x7fff5fbff778) at ../../gcc-4.5/gcc/gimplify.c:1127#9  0x00000001004cae2b in gimplify_expr (expr_p=0x1416c2298, pre_p=0x7fff5fbff778, post_p=0x7fff5fbff618, gimple_test_f=0x1004ab1a6 <is_gimple_stmt>, fallback=0) at ../../gcc-4.5/gcc/gimplify.c:6719#10 0x00000001004c7800 in gimplify_stmt (stmt_p=0x1416c2298, seq_p=0x7fff5fbff778) at ../../gcc-4.5/gcc/gimplify.c:5264#11 0x00000001004ccbe6 in gimplify_body (body_p=0x1416c2298, fndecl=0x1416c2200, do_parms=1 '\001') at ../../gcc-4.5/gcc/gimplify.c:7528#12 0x00000001004cceae in gimplify_function_tree (fndecl=0x1416c2200) at ../../gcc-4.5/gcc/gimplify.c:7624#13 0x00000001000069c7 in m3_gimplify_function (fndecl=0x1416c2200) at ../../gcc-4.5/gcc/m3cg/parse.c:2370#14 0x0000000100009cb4 in m3cg_end_procedure () at ../../gcc-4.5/gcc/m3cg/parse.c:3642#15 0x000000010000feb5 in m3_parse_file (xx=0) at ../../gcc-4.5/gcc/m3cg/parse.c:5550#16 0x00000001006be6a2 in compile_file () at ../../gcc-4.5/gcc/toplev.c:1053#17 0x00000001006c0e19 in do_compile () at ../../gcc-4.5/gcc/toplev.c:2415#18 0x00000001006c0ee0 in toplev_main (argc=3, argv=0x7fff5fbff930) at ../../gcc-4.5/gcc/toplev.c:2457#19 0x000000010001743b in main (argc=3, argv=0x7fff5fbff930) at ../../gcc-4.5/gcc/main.c:35(

Wierd, huh?
The only thing I can think of an int/word mismatch.I did change one instance of Integer to Word, after finding this.Stmt.Outcomes is an enumeration.So presumably Stmt.Outcomes { } is 0.Enumerations should work equally well as Integer or Word, right?Clearly above there is still a mix. I can try changing them all to Word.

I'll keep digging.

Maybe dump the entire function generic tree for this and similar C.

 - Jay 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100627/2ee35f81/attachment-0001.html>

From ttmrichter at gmail.com  Sun Jun 27 12:54:30 2010
From: ttmrichter at gmail.com (Michael Richter)
Date: Sun, 27 Jun 2010 18:54:30 +0800
Subject: [M3devel] cm3ide and Chrome
Message-ID: <AANLkTim77ivruVuNT21PtStijrhMlRD-bNc9VOIH669d@mail.gmail.com>

Is there a trick to making cm3ide work with Google Chrome?  The problem
seems to be that Google Chrome returns *immediately* upon invocation where
the default, Firefox, does not.  Cm3ide waits for the browser to exit to
decide that it's time to end, so what winds up happening for me when
specifying Chrome as the browser is that cm3ide starts, Chrome starts,
cm3ide starts serving up some content, Chrome's launcher returns
immediately, cm3ide dies.  The result is a partial opening page and nothing
else.

Also, when specifying the browser (any browser), it doesn't like me giving
options to the browser command line: it rejects "/usr/bin/google-chrome
--new-window" as an option when asking for the browser if I delete the
configuration file.  I have to go /usr/bin/google-chrome and then manually
edit the configuration file to include any command line switches I want to
use.

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

From jay.krell at cornell.edu  Sun Jun 27 13:07:06 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 27 Jun 2010 11:07:06 +0000
Subject: [M3devel] extra temporaries?
Message-ID: <COL101-W63DC70E1561934607F902CE6C90@phx.gbl>


Why all these extra temporaries?

static voidm3cg_max (void){  MTYPE (t);
  tree t1 = declare_temp (t);  tree t2 = declare_temp (t);
  add_stmt (m3_build2 (MODIFY_EXPR, t, t1, EXPR_REF (-1)));  add_stmt (m3_build2 (MODIFY_EXPR, t, t2, EXPR_REF (-2)));
  EXPR_REF (-2) = m3_build3 (COND_EXPR, t,                             m3_build2 (LE_EXPR, boolean_type_node, t2, t1),                             t1, t2);  EXPR_POP ();}

static voidm3cg_min (void){  MTYPE (t);
  tree t1 = declare_temp (t);  tree t2 = declare_temp (t);
  add_stmt (m3_build2 (MODIFY_EXPR, t, t1, EXPR_REF (-1)));  add_stmt (m3_build2 (MODIFY_EXPR, t, t2, EXPR_REF (-2)));
  EXPR_REF (-2) = m3_build3 (COND_EXPR, t,                             m3_build2 (LE_EXPR, boolean_type_node, t1, t2),                             t1, t2);  EXPR_POP ();}


static voidm3cg_check_nil (void){  INTEGER (code);
  tree temp1 = declare_temp (t_addr);
  m3_store (temp1, 0, t_addr, T_addr, t_addr, T_addr);  EXPR_PUSH (temp1);  add_stmt (build3 (COND_EXPR, t_void,                    m3_build2 (EQ_EXPR, boolean_type_node, temp1, v_null),                    generate_fault (code),                    NULL_TREE));}


static voidm3cg_check_lo (void){  MTYPE2         (t, T);  TARGET_INTEGER (a);  INTEGER        (code);
  tree temp1 = declare_temp (t);
  a = convert (t, a);
  if (option_exprs_trace)    fprintf (stderr, "  check low type:%s code:0x%lx\n", m3cg_typename(T), code);
  if (TREE_TYPE (EXPR_REF (-1)) != t)    EXPR_REF (-1) = m3_build1 (CONVERT_EXPR, t, EXPR_REF (-1));
  m3_store (temp1, 0, t, T, t, T);  EXPR_PUSH (temp1);  add_stmt (build3 (COND_EXPR, t_void,                    m3_build2 (LT_EXPR, boolean_type_node, temp1, a),                    generate_fault (code),                    NULL_TREE));}

static voidm3cg_check_hi (void){  MTYPE2         (t, T);  TARGET_INTEGER (a);  INTEGER        (code);
  tree temp1 = declare_temp (t);
  a = convert (t, a);
  if (option_exprs_trace)    fprintf (stderr, "  check high type:%s code:0x%lx\n", m3cg_typename(T), code);
  if (TREE_TYPE (EXPR_REF (-1)) != t)    EXPR_REF (-1) = m3_build1 (CONVERT_EXPR, t, EXPR_REF (-1));
  m3_store (temp1, 0, t, T, t, T);  EXPR_PUSH (temp1);  add_stmt (build3 (COND_EXPR, t_void,                    m3_build2 (GT_EXPR, boolean_type_node, temp1, a),                    generate_fault (code),                    NULL_TREE));}

static voidm3cg_check_range (void){  MTYPE2         (t, T);  TARGET_INTEGER (a);  TARGET_INTEGER (b);  INTEGER        (code);
  tree temp1 = declare_temp (t);
  a = convert (t, a);  b = convert (t, b);
  if (option_exprs_trace)    fprintf (stderr, "  check range type:%s code:0x%lx\n", m3cg_typename(T), code);
  if (TREE_TYPE (EXPR_REF (-1)) != t)    EXPR_REF (-1) = m3_build1 (CONVERT_EXPR, t, EXPR_REF (-1));
  m3_store (temp1, 0, t, T, t, T);  EXPR_PUSH (temp1);  add_stmt (build3 (COND_EXPR, t_void,                    m3_build2 (TRUTH_ORIF_EXPR, boolean_type_node,                               m3_build2 (LT_EXPR,                                          boolean_type_node, temp1, a),                               m3_build2 (GT_EXPR,                                          boolean_type_node, temp1, b)),                    generate_fault (code),                    NULL_TREE));}

static voidm3cg_check_eq (void){  MTYPE2  (t, T);  INTEGER (code);
  tree temp1 = declare_temp (t);  tree temp2 = declare_temp (t);
  m3_store (temp1, 0, t, T, t, T);  m3_store (temp2, 0, t, T, t, T);  add_stmt (build3 (COND_EXPR, t_void,                    m3_build2 (NE_EXPR, boolean_type_node, temp1, temp2),                    generate_fault (code),                    NULL_TREE));}

seem kind of wasteful.

 - Jay

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

From jay.krell at cornell.edu  Sun Jun 27 13:15:13 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 27 Jun 2010 11:15:13 +0000
Subject: [M3devel] cm3ide and Chrome
In-Reply-To: <AANLkTim77ivruVuNT21PtStijrhMlRD-bNc9VOIH669d@mail.gmail.com>
References: <AANLkTim77ivruVuNT21PtStijrhMlRD-bNc9VOIH669d@mail.gmail.com>
Message-ID: <COL101-W43C485848DE91DF690DFF3E6C90@phx.gbl>


Similar? stuff has been discussed. Like, Internet Explorer returning or continuing to run depends on if there is already an instance."start /wait" prefixed to the command line might help.
"When specifying the browser.." you mean cminstall?  You might try manually editing c:\cm3\bin\cm3.cfg or c:\cm3\bin\config\NT386* after running it.  cminstall is just making small edits to them.
 - Jay

Date: Sun, 27 Jun 2010 18:54:30 +0800
From: ttmrichter at gmail.com
To: m3devel at elegosoft.com
Subject: [M3devel] cm3ide and Chrome

Is there a trick to making cm3ide work with Google Chrome?  The problem seems to be that Google Chrome returns immediately upon invocation where the default, Firefox, does not.  Cm3ide waits for the browser to exit to decide that it's time to end, so what winds up happening for me when specifying Chrome as the browser is that cm3ide starts, Chrome starts, cm3ide starts serving up some content, Chrome's launcher returns immediately, cm3ide dies.  The result is a partial opening page and nothing else.

Also, when specifying the browser (any browser), it doesn't like me giving options to the browser command line: it rejects "/usr/bin/google-chrome --new-window" as an option when asking for the browser if I delete the configuration file.  I have to go /usr/bin/google-chrome and then manually edit the configuration file to include any command line switches I want to use.

-- 
"Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot."

--Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra.

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

From rcolebur at SCIRES.COM  Sun Jun 27 13:25:55 2010
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Sun, 27 Jun 2010 07:25:55 -0400
Subject: [M3devel] cm3ide and Chrome
In-Reply-To: <AANLkTim77ivruVuNT21PtStijrhMlRD-bNc9VOIH669d@mail.gmail.com>
References: <AANLkTim77ivruVuNT21PtStijrhMlRD-bNc9VOIH669d@mail.gmail.com>
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E605DBF572@ATLEX02-SRV.SCIRES.LOCAL>

Michael:

You can edit the cm3ide configuration file to change the behavior.  This file is usually located in ..\Documents\CM3_IDE_Home\CM3_IDE.cfg0 or CM3_IDE.cfg1

Find the ?start_browser? proc.  Change the return value to be FALSE.

FALSE means CM3_IDE should stay running when the browser terminates, whereas TRUE causes it to terminate when the browser terminates.

If you want to give command line options to the browser, you can specify them in the start_browser proc as well.

Regards,
Randy Coleburn

From: Michael Richter [mailto:ttmrichter at gmail.com]
Sent: Sunday, June 27, 2010 6:55 AM
To: m3devel
Subject: [M3devel] cm3ide and Chrome

Is there a trick to making cm3ide work with Google Chrome?  The problem seems to be that Google Chrome returns immediately upon invocation where the default, Firefox, does not.  Cm3ide waits for the browser to exit to decide that it's time to end, so what winds up happening for me when specifying Chrome as the browser is that cm3ide starts, Chrome starts, cm3ide starts serving up some content, Chrome's launcher returns immediately, cm3ide dies.  The result is a partial opening page and nothing else.

Also, when specifying the browser (any browser), it doesn't like me giving options to the browser command line: it rejects "/usr/bin/google-chrome --new-window" as an option when asking for the browser if I delete the configuration file.  I have to go /usr/bin/google-chrome and then manually edit the configuration file to include any command line switches I want to use.

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

From rcolebur at SCIRES.COM  Sun Jun 27 13:27:41 2010
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Sun, 27 Jun 2010 07:27:41 -0400
Subject: [M3devel] cm3ide and Chrome
In-Reply-To: <COL101-W43C485848DE91DF690DFF3E6C90@phx.gbl>
References: <AANLkTim77ivruVuNT21PtStijrhMlRD-bNc9VOIH669d@mail.gmail.com>
	<COL101-W43C485848DE91DF690DFF3E6C90@phx.gbl>
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E605DBF573@ATLEX02-SRV.SCIRES.LOCAL>

See my prior post instead.
--Randy

From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Sunday, June 27, 2010 7:15 AM
To: ttmrichter at gmail.com; m3devel
Subject: Re: [M3devel] cm3ide and Chrome

Similar? stuff has been discussed.
 Like, Internet Explorer returning or continuing to run depends on if there is already an instance.
"start /wait" prefixed to the command line might help.

"When specifying the browser.." you mean cminstall?
  You might try manually editing c:\cm3\bin\cm3.cfg or c:\cm3\bin\config\NT386* after running it.
  cminstall is just making small edits to them.

 - Jay

________________________________
Date: Sun, 27 Jun 2010 18:54:30 +0800
From: ttmrichter at gmail.com
To: m3devel at elegosoft.com
Subject: [M3devel] cm3ide and Chrome

Is there a trick to making cm3ide work with Google Chrome?  The problem seems to be that Google Chrome returns immediately upon invocation where the default, Firefox, does not.  Cm3ide waits for the browser to exit to decide that it's time to end, so what winds up happening for me when specifying Chrome as the browser is that cm3ide starts, Chrome starts, cm3ide starts serving up some content, Chrome's launcher returns immediately, cm3ide dies.  The result is a partial opening page and nothing else.

Also, when specifying the browser (any browser), it doesn't like me giving options to the browser command line: it rejects "/usr/bin/google-chrome --new-window" as an option when asking for the browser if I delete the configuration file.  I have to go /usr/bin/google-chrome and then manually edit the configuration file to include any command line switches I want to use.

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

From jay.krell at cornell.edu  Sun Jun 27 14:39:45 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 27 Jun 2010 12:39:45 +0000
Subject: [M3devel] div/mod?
Message-ID: <COL101-W52D2A18F8772E0667B8746E6C90@phx.gbl>


implementing div/mod?
The historical implementation is "ok". advantages:   stable   doesn't do any div/mod of negative numbers disadvantages:   I believe it gets a few cases wrong, e.g. involving minimal inputs   relies on silent overflow of signed math     There are gcc flags that warn about this,     and I think also optimizations that break it.

"new" C implementation:  advantages:    avoids silent overflow overflow of signed numbers (no warnings from gcc)    I believe it fixes the incorrect cases in the historical implementation.  disadvantages:    one nagging part of it is how it deals with two negative    inputs; it assumes C matches Modula-3

INTEGER__stdcallm3_div(INTEGER b, INTEGER a){  int aneg = (a < 0);  int bneg = (b < 0);  if (aneg == bneg || a == 0 || b == 0)    return (a / b);...
INTEGER__stdcallm3_mod(INTEGER b, INTEGER a){  int aneg = (a < 0);  int bneg = (b < 0);  if (aneg == bneg || a == 0 || b == 0)    return (a % b);...

This makes me a bit nervous regarding the case of aneg && bneg.Generally, as was said, everyone defines div/mod the same for positive inputs,but once either (or both?) inputs are negative, there are several options.But it seems to test out ok. At least on AMD64_DARWIN. I could test more platforms.

gcc "opcodes" (tree codes, there are different ones for   trunc/round/floor/ceil div/mod)  presumably fastest option    and maybe smallest though probably not  presumably not much used  64bit path doesn't work for ARM, for a mostly understood reason,     compiler goes down path of wanting 128bit integers ("TImode"), though     I suspect it doesn't really need them, either it ends     up doing something else, or they are a way of     moving around a pair of int64

Could go back to the hybrid I had briefly: always use gcc "opcodes", except 64bit operations on ARM or could even fix 64bit on ARM?   ?

Notice that m3back has always implemented 32bit div/mod inline.  But always calls the C for 64bit.Also my confidence in gcc "opcodes" was briefly shakenby noticing it still uses the "normal" helper functions, butupon closer inspection, it does "wrap" them in various formsof rounding, depending on the exact operation requested.
 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100627/22b0ff30/attachment-0001.html>

From ttmrichter at gmail.com  Sun Jun 27 14:47:12 2010
From: ttmrichter at gmail.com (Michael Richter)
Date: Sun, 27 Jun 2010 20:47:12 +0800
Subject: [M3devel] cm3ide and Chrome
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E605DBF572@ATLEX02-SRV.SCIRES.LOCAL>
References: <AANLkTim77ivruVuNT21PtStijrhMlRD-bNc9VOIH669d@mail.gmail.com>
	<D67F02DDC62F7545A6B84C285F88F3E605DBF572@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <AANLkTilNwMZJUnptlIJXPhbc7TJxw5PL4T0IotuE0VHD@mail.gmail.com>

On 27 June 2010 19:25, Coleburn, Randy <rcolebur at scires.com> wrote:

>  You can edit the cm3ide configuration file to change the behavior.  This
> file is usually located in ..\Documents\CM3_IDE_Home\*CM3_IDE.cfg0* or *
> CM3_IDE.cfg1*
>
> Find the ?*start_browser*? proc.  Change the return value to be *FALSE*.
>
I found the .cfg* file but I didn't catch that TRUE/FALSE return value
thing.  That makes a huge difference!  Thanks a lot.

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

From jay.krell at cornell.edu  Sun Jun 27 15:44:06 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 27 Jun 2010 13:44:06 +0000
Subject: [M3devel] m3cg 4.5 problem
In-Reply-To: <COL101-W2519C65D63208BF55620CE6C90@phx.gbl>
References: <COL101-W728051433DA06972261F1E6C90@phx.gbl>,
	<COL101-W2519C65D63208BF55620CE6C90@phx.gbl>
Message-ID: <COL101-W24F2979E24DCCB1CDD09B3E6C90@phx.gbl>


I almost have this figured out.

4.5:
(gdb) break is_gimple_lvalue(gdb) runBreakpoint 2, is_gimple_lvalue (t=0x414653b8) at ../../gcc-4.5/gcc/gimple.c:24562456	  return (is_gimple_addressable (t)(gdb) call debug_tree(t) <nop_expr 0x414653b8    type <integer_type 0x41417360 int_64 public DI        size <integer_cst 0x41405340 constant 64>        unit size <integer_cst 0x41405360 constant 8>        align 64 symtab 0 alias set -1 canonical type 0x41417360 precision 64 min <integer_cst 0x414052e0 -9223372036854775808> max <integer_cst 0x41405300 9223372036854775807>>       arg 0 <var_decl 0x414680b8 M3_DxNB17_oc        type <integer_type 0x414173c0 word_64 sizes-gimplified public unsigned DI size <integer_cst 0x41405340 64> unit size <integer_cst 0x41405360 8>            align 64 symtab 0 alias set -1 canonical type 0x414173c0 precision 64 min <integer_cst 0x41405380 0> max <integer_cst 0x41405320 18446744073709551615>>        unsigned DI file ../src/stmts/TypeCaseStmt.m3 line 12 col 0 size <integer_cst 0x41405340 64> unit size <integer_cst 0x41405360 8>        align 64 context <function_decl 0x41466400 TypeCaseStmt__GetOutcomex>>>


(gdb) finishRun till exit from #0  is_gimple_lvalue (t=0x414653b8) at ../../gcc-4.5/gcc/gimple.c:24560x004ea8bc in gimplify_expr (expr_p=0x41456218, pre_p=0xbffff510, post_p=0xbffff230, gimple_test_f=0x4c9bd5 <is_gimple_lvalue>, fallback=2) at ../../gcc-4.5/gcc/gimplify.c:72627262	gimple_test_f) (*expr_p))Value returned is $13 = 0 '\0'

4.3:(gdb) break is_gimple_lvalueBreakpoint 1 at 0x5708e3: file ../../gcc/gcc/tree-gimple.c, line 147.(gdb) runStarting program: /Users/jay/dev2/cm3/m3-sys/m3cc/I386_DARWIN-I386_DARWIN-4.3/gcc/m3cgc1 -m64 TypeCaseStmt.mcReading symbols for shared libraries ++. done TypeCaseStmt__GetOutcomexBreakpoint 1, is_gimple_lvalue (t=0x41141060) at ../../gcc/gcc/tree-gimple.c:147147	  return (is_gimple_addressable (t)(gdb) call debug_tree(t) <var_decl 0x41141060 M3_DxNB17_oc    type <integer_type 0x41111460 word_64 sizes-gimplified public unsigned DI        size <integer_cst 0x40b2d6f0 constant invariant 64>        unit size <integer_cst 0x40b2d720 constant invariant 8>        align 64 symtab 0 alias set -1 canonical type 0x41111460 precision 64 min <integer_cst 0x40b2d750 0> max <integer_cst 0x40b2d6c0 18446744073709551615>>    unsigned DI file ../src/stmts/TypeCaseStmt.m3 line 12 col 0 size <integer_cst 0x40b2d6f0 64> unit size <integer_cst 0x40b2d720 8>    align 64 context <function_decl 0x4113e100 TypeCaseStmt__GetOutcomex>>(gdb) finishRun till exit from #0  is_gimple_lvalue (t=0x41141060) at ../../gcc/gcc/tree-gimple.c:1470x003d7541 in gimplify_expr (expr_p=0x4113d16c, pre_p=0xbffff350, post_p=0xbffff34c, gimple_test_f=0x5708dd <is_gimple_lvalue>, fallback=fb_either) at ../../gcc/gcc/gimplify.c:6240warning: Source file is more recent than executable.6240	  if (!internal_post && (*gimple_test_f) (*expr_p))Value returned is $1 = 1 '\001'

nop_expr is what we use for casting.We are casting int64 to word64.The result of a cast is not an lvalue.I suspect 4.3 has removed this as a "useless conversion"...
In 4.5 we have: gdb: call debug_tree(*expr_p)
        stmt <modify_expr 0x41456200 type <integer_type 0x41417360 int_64>            side-effects used            arg 0 <nop_expr 0x414653b8 type <integer_type 0x41417360 int_64>                arg 0 <var_decl 0x414680b8 M3_DxNB17_oc>>            arg 1 <integer_cst 0x414057e0 constant 0>            ../src/stmts/TypeCaseStmt.m3:7:0>

in 4.3 we have:
        stmt <modify_expr 0x4113d180 type <integer_type 0x411113f0 int_64>            side-effects used            arg 0 <bit_field_ref 0x4113d150 type <integer_type 0x411113f0 int_64>                arg 0 <var_decl 0x41141060 M3_DxNB17_oc>                arg 1 <integer_cst 0x40b2d6f0 64>                arg 2 <integer_cst 0x40b2da20 constant invariant 0>>            arg 1 <integer_cst 0x40b2dde0 constant invariant 0>            ../src/stmts/TypeCaseStmt.m3:7:0> Again, 4.5 reads: (int64)oc = 0;
4.3 reads:  (bit field ref)oc = 0;
int64 cast is not an lvalue, bit field ref is. Something like that.
Either one of the #if GCC45 I have or gcc has done a transform in the meantime..
I'll keep digging.
I don't believe we need the cast -- we should just get the type right in the first place.But fixing that isn't necessarily what I'm going to do.I have to see where 4.3 vs. 4.5 difference comes from first..

 - Jay


From: jay.krell at cornell.edu
To: m3devel at elegosoft.com; hosking at cs.purdue.edu
Date: Sun, 27 Jun 2010 09:23:13 +0000
Subject: Re: [M3devel] m3cg 4.5 problem








I was a bit off. It is actually set of enum. Like this:
MODULE TypeCaseStmt;
TYPE T1 = {A,B};TYPE T2 = SET OF T1; PROCEDURE GetOutcomex (): T2 =  VAR oc := T2 {};  BEGIN    RETURN oc;  END GetOutcomex;
BEGINEND TypeCaseStmt.
 - Jay
From: jay.krell at cornell.edu
To: m3devel at elegosoft.com; hosking at cs.purdue.edu
Date: Sun, 27 Jun 2010 08:12:54 +0000
Subject: [M3devel] m3cg 4.5 problem








This tiny bit of code, which is cut down from m3front, causes an assertion failure in a 4.5 m3cg:
MODULE TypeCaseStmt;
IMPORT M3ID, CG, Expr, Stmt, StmtRep, Type, Variable, Scope;
PROCEDURE GetOutcomex (): Stmt.Outcomes =  VAR oc := Stmt.Outcomes {};  line 6  BEGIN    RETURN oc;  END GetOutcomex;
BEGINEND TypeCaseStmt.
../src/stmts/TypeCaseStmt.m3:6:0: internal compiler error: in gimplify_expr, at gimplify.c:7315Please submit a full bug report,

(1) begin_unit(2) set_source_file(3) set_source_line  source line    1(4) comment  comment: `module global constants'(5) declare_segment  segment L_1 typeid 0xffffffff(6) comment  comment: `module global data'(7) declare_segment  segment MM_TypeCaseStmt typeid 0xffffffff(8) set_source_line  source line   11(9) declare_procedure  type:addr  procedure:TypeCaseStmt_M3 nparams:0x1 rettype:addr lev:0 exported:1(10) declare_param  type:int64  param M3_AcxOUs_mode type:int64 typeid:0x195c2a74 bytesize:0x40 alignment:0x40 in_memory:0x0 up_level:0x0  mode 0x11 (DImode)(11) import_procedure  type:addr  procedure:TypeCaseStmt_I3 nparams:0x0 rettype:addr(12) export_unit(13) import_procedure  type:addr  procedure:Scope_I3 nparams:0x0 rettype:addr(14) import_unit(15) import_procedure  type:addr  procedure:Variable_I3 nparams:0x0 rettype:addr(16) import_unit(17) import_procedure  type:addr  procedure:Type_I3 nparams:0x0 rettype:addr(18) import_unit(19) import_procedure  type:addr  procedure:StmtRep_I3 nparams:0x0 rettype:addr(20) import_unit(21) import_procedure  type:addr  procedure:Stmt_I3 nparams:0x0 rettype:addr(22) import_unit(23) import_procedure  type:addr  procedure:Expr_I3 nparams:0x0 rettype:addr(24) import_unit(25) import_procedure  type:addr  procedure:CG_I3 nparams:0x0 rettype:addr(26) import_unit(27) import_procedure  type:addr  procedure:M3ID_I3 nparams:0x0 rettype:addr(28) import_unit(29) import_procedure  type:addr  procedure:RTHooks_I3 nparams:0x0 rettype:addr(30) import_unit(31) declare_procedure  type:word64  procedure:TypeCaseStmt__GetOutcomex nparams:0x0 rettype:word64 lev:0 exported:0(32) declare_local  type:word64  local var M3_EXQtd6_oc type:word64 size:0x40 alignment:0x40(33) declare_local  type:word64  local var M3_EXQtd6__result type:word64 size:0x40 alignment:0x40(34) comment  comment: `GetOutcomex'(35) set_source_line  source line    5(36) begin_procedure  procedure TypeCaseStmt__GetOutcomex TypeCaseStmt__GetOutcomex(37) set_source_line  source line    6(38) load_integer  type:int64  integer:0x0(39) store  type:int64  type:int64  store (M3_EXQtd6_oc) offset:0x0 src_t:int64 dst_t:int64(40) set_source_line  source line    8(41) load  type:word64  type:int64  m3cg_load (M3_EXQtd6_oc): offset 0x0, convert word64 -> int64(42) exit_proc  type:word64(43) end_procedure  procedure TypeCaseStmt__GetOutcomex

Breakpoint 1, fancy_abort (file=0x1009f0c6f "../../gcc-4.5/gcc/gimplify.c", line=7315, function=0x1009f1242 "gimplify_expr") at ../../gcc-4.5/gcc/diagnostic.c:763763	  internal_error ("in %s, at %s:%d", function, trim_filename (file), line);(gdb) bt#0  fancy_abort (file=0x1009f0c6f "../../gcc-4.5/gcc/gimplify.c", line=7315, function=0x1009f1242 "gimplify_expr") at ../../gcc-4.5/gcc/diagnostic.c:763#1  0x00000001004cc4d6 in gimplify_expr (expr_p=0x1410e2060, pre_p=0x7fff5fbff420, post_p=0x7fff5fbfeff8, gimple_test_f=0x1004aac7f <is_gimple_lvalue>, fallback=2) at ../../gcc-4.5/gcc/gimplify.c:7315#2  0x00000001004c5ad3 in gimplify_modify_expr (expr_p=0x1416a5f28, pre_p=0x7fff5fbff420, post_p=0x7fff5fbfeff8, want_value=0 '\0') at ../../gcc-4.5/gcc/gimplify.c:4444#3  0x00000001004caafc in gimplify_expr (expr_p=0x1416a5f28, pre_p=0x7fff5fbff420, post_p=0x7fff5fbfeff8, gimple_test_f=0x1004ab1a6 <is_gimple_stmt>, fallback=0) at ../../gcc-4.5/gcc/gimplify.c:6619#4  0x00000001004c7800 in gimplify_stmt (stmt_p=0x1416a5f28, seq_p=0x7fff5fbff420) at ../../gcc-4.5/gcc/gimplify.c:5264#5  0x00000001004be376 in gimplify_statement_list (expr_p=0x1416c4030, pre_p=0x7fff5fbff420) at ../../gcc-4.5/gcc/gimplify.c:1382#6  0x00000001004cb6f5 in gimplify_expr (expr_p=0x1416c4030, pre_p=0x7fff5fbff420, post_p=0x7fff5fbff2e8, gimple_test_f=0x1004ab1a6 <is_gimple_stmt>, fallback=0) at ../../gcc-4.5/gcc/gimplify.c:6935#7  0x00000001004c7800 in gimplify_stmt (stmt_p=0x1416c4030, seq_p=0x7fff5fbff420) at ../../gcc-4.5/gcc/gimplify.c:5264#8  0x00000001004bdb6c in gimplify_bind_expr (expr_p=0x1416c2298, pre_p=0x7fff5fbff778) at ../../gcc-4.5/gcc/gimplify.c:1127#9  0x00000001004cae2b in gimplify_expr (expr_p=0x1416c2298, pre_p=0x7fff5fbff778, post_p=0x7fff5fbff618, gimple_test_f=0x1004ab1a6 <is_gimple_stmt>, fallback=0) at ../../gcc-4.5/gcc/gimplify.c:6719#10 0x00000001004c7800 in gimplify_stmt (stmt_p=0x1416c2298, seq_p=0x7fff5fbff778) at ../../gcc-4.5/gcc/gimplify.c:5264#11 0x00000001004ccbe6 in gimplify_body (body_p=0x1416c2298, fndecl=0x1416c2200, do_parms=1 '\001') at ../../gcc-4.5/gcc/gimplify.c:7528#12 0x00000001004cceae in gimplify_function_tree (fndecl=0x1416c2200) at ../../gcc-4.5/gcc/gimplify.c:7624#13 0x00000001000069c7 in m3_gimplify_function (fndecl=0x1416c2200) at ../../gcc-4.5/gcc/m3cg/parse.c:2370#14 0x0000000100009cb4 in m3cg_end_procedure () at ../../gcc-4.5/gcc/m3cg/parse.c:3642#15 0x000000010000feb5 in m3_parse_file (xx=0) at ../../gcc-4.5/gcc/m3cg/parse.c:5550#16 0x00000001006be6a2 in compile_file () at ../../gcc-4.5/gcc/toplev.c:1053#17 0x00000001006c0e19 in do_compile () at ../../gcc-4.5/gcc/toplev.c:2415#18 0x00000001006c0ee0 in toplev_main (argc=3, argv=0x7fff5fbff930) at ../../gcc-4.5/gcc/toplev.c:2457#19 0x000000010001743b in main (argc=3, argv=0x7fff5fbff930) at ../../gcc-4.5/gcc/main.c:35(

Wierd, huh?
The only thing I can think of an int/word mismatch.I did change one instance of Integer to Word, after finding this.Stmt.Outcomes is an enumeration.So presumably Stmt.Outcomes { } is 0.Enumerations should work equally well as Integer or Word, right?Clearly above there is still a mix. I can try changing them all to Word.

I'll keep digging.

Maybe dump the entire function generic tree for this and similar C.

 - Jay 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100627/47649ec6/attachment-0001.html>

From jay.krell at cornell.edu  Sun Jun 27 17:04:59 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 27 Jun 2010 15:04:59 +0000
Subject: [M3devel] m3cg 4.5 problem
In-Reply-To: <COL101-W24F2979E24DCCB1CDD09B3E6C90@phx.gbl>
References: <COL101-W728051433DA06972261F1E6C90@phx.gbl>, ,
	<COL101-W2519C65D63208BF55620CE6C90@phx.gbl>,
	<COL101-W24F2979E24DCCB1CDD09B3E6C90@phx.gbl>
Message-ID: <COL101-W327A4E4C62AF02A66F7138E6C90@phx.gbl>


Problem seems to be here:

fold-const.c:fold_ternary_loc
...  switch (code)...    case BIT_FIELD_REF:...      /* A bit-field-ref that referenced the full argument can be stripped.  */      if (INTEGRAL_TYPE_P (TREE_TYPE (arg0))	  && TYPE_PRECISION (TREE_TYPE (arg0)) == tree_low_cst (arg1, 1)	  && integer_zerop (op2))	return fold_convert_loc (loc, type, arg0);

Turning our bit field refs which are lvalues into casts (nop_expr) which are not.For now I'll #if this out.Further investigation: see how it compares to trunk; see if we can get the types right.
 - Jay
From: jay.krell at cornell.edu
To: m3devel at elegosoft.com; hosking at cs.purdue.edu
Date: Sun, 27 Jun 2010 13:44:06 +0000
Subject: Re: [M3devel] m3cg 4.5 problem








I almost have this figured out.

4.5:
(gdb) break is_gimple_lvalue(gdb) runBreakpoint 2, is_gimple_lvalue (t=0x414653b8) at ../../gcc-4.5/gcc/gimple.c:24562456	  return (is_gimple_addressable (t)(gdb) call debug_tree(t) <nop_expr 0x414653b8    type <integer_type 0x41417360 int_64 public DI        size <integer_cst 0x41405340 constant 64>        unit size <integer_cst 0x41405360 constant 8>        align 64 symtab 0 alias set -1 canonical type 0x41417360 precision 64 min <integer_cst 0x414052e0 -9223372036854775808> max <integer_cst 0x41405300 9223372036854775807>>       arg 0 <var_decl 0x414680b8 M3_DxNB17_oc        type <integer_type 0x414173c0 word_64 sizes-gimplified public unsigned DI size <integer_cst 0x41405340 64> unit size <integer_cst 0x41405360 8>            align 64 symtab 0 alias set -1 canonical type 0x414173c0 precision 64 min <integer_cst 0x41405380 0> max <integer_cst 0x41405320 18446744073709551615>>        unsigned DI file ../src/stmts/TypeCaseStmt.m3 line 12 col 0 size <integer_cst 0x41405340 64> unit size <integer_cst 0x41405360 8>        align 64 context <function_decl 0x41466400 TypeCaseStmt__GetOutcomex>>>


(gdb) finishRun till exit from #0  is_gimple_lvalue (t=0x414653b8) at ../../gcc-4.5/gcc/gimple.c:24560x004ea8bc in gimplify_expr (expr_p=0x41456218, pre_p=0xbffff510, post_p=0xbffff230, gimple_test_f=0x4c9bd5 <is_gimple_lvalue>, fallback=2) at ../../gcc-4.5/gcc/gimplify.c:72627262	gimple_test_f) (*expr_p))Value returned is $13 = 0 '\0'

4.3:(gdb) break is_gimple_lvalueBreakpoint 1 at 0x5708e3: file ../../gcc/gcc/tree-gimple.c, line 147.(gdb) runStarting program: /Users/jay/dev2/cm3/m3-sys/m3cc/I386_DARWIN-I386_DARWIN-4.3/gcc/m3cgc1 -m64 TypeCaseStmt.mcReading symbols for shared libraries ++. done TypeCaseStmt__GetOutcomexBreakpoint 1, is_gimple_lvalue (t=0x41141060) at ../../gcc/gcc/tree-gimple.c:147147	  return (is_gimple_addressable (t)(gdb) call debug_tree(t) <var_decl 0x41141060 M3_DxNB17_oc    type <integer_type 0x41111460 word_64 sizes-gimplified public unsigned DI        size <integer_cst 0x40b2d6f0 constant invariant 64>        unit size <integer_cst 0x40b2d720 constant invariant 8>        align 64 symtab 0 alias set -1 canonical type 0x41111460 precision 64 min <integer_cst 0x40b2d750 0> max <integer_cst 0x40b2d6c0 18446744073709551615>>    unsigned DI file ../src/stmts/TypeCaseStmt.m3 line 12 col 0 size <integer_cst 0x40b2d6f0 64> unit size <integer_cst 0x40b2d720 8>    align 64 context <function_decl 0x4113e100 TypeCaseStmt__GetOutcomex>>(gdb) finishRun till exit from #0  is_gimple_lvalue (t=0x41141060) at ../../gcc/gcc/tree-gimple.c:1470x003d7541 in gimplify_expr (expr_p=0x4113d16c, pre_p=0xbffff350, post_p=0xbffff34c, gimple_test_f=0x5708dd <is_gimple_lvalue>, fallback=fb_either) at ../../gcc/gcc/gimplify.c:6240warning: Source file is more recent than executable.6240	  if (!internal_post && (*gimple_test_f) (*expr_p))Value returned is $1 = 1 '\001'

nop_expr is what we use for casting.We are casting int64 to word64.The result of a cast is not an lvalue.I suspect 4.3 has removed this as a "useless conversion"...
In 4.5 we have: gdb: call debug_tree(*expr_p)
        stmt <modify_expr 0x41456200 type <integer_type 0x41417360 int_64>            side-effects used            arg 0 <nop_expr 0x414653b8 type <integer_type 0x41417360 int_64>                arg 0 <var_decl 0x414680b8 M3_DxNB17_oc>>            arg 1 <integer_cst 0x414057e0 constant 0>            ../src/stmts/TypeCaseStmt.m3:7:0>

in 4.3 we have:
        stmt <modify_expr 0x4113d180 type <integer_type 0x411113f0 int_64>            side-effects used            arg 0 <bit_field_ref 0x4113d150 type <integer_type 0x411113f0 int_64>                arg 0 <var_decl 0x41141060 M3_DxNB17_oc>                arg 1 <integer_cst 0x40b2d6f0 64>                arg 2 <integer_cst 0x40b2da20 constant invariant 0>>            arg 1 <integer_cst 0x40b2dde0 constant invariant 0>            ../src/stmts/TypeCaseStmt.m3:7:0> Again, 4.5 reads: (int64)oc = 0;
4.3 reads:  (bit field ref)oc = 0;
int64 cast is not an lvalue, bit field ref is. Something like that.
Either one of the #if GCC45 I have or gcc has done a transform in the meantime..
I'll keep digging.
I don't believe we need the cast -- we should just get the type right in the first place.But fixing that isn't necessarily what I'm going to do.I have to see where 4.3 vs. 4.5 difference comes from first..

 - Jay


From: jay.krell at cornell.edu
To: m3devel at elegosoft.com; hosking at cs.purdue.edu
Date: Sun, 27 Jun 2010 09:23:13 +0000
Subject: Re: [M3devel] m3cg 4.5 problem








I was a bit off. It is actually set of enum. Like this:
MODULE TypeCaseStmt;
TYPE T1 = {A,B};TYPE T2 = SET OF T1; PROCEDURE GetOutcomex (): T2 =  VAR oc := T2 {};  BEGIN    RETURN oc;  END GetOutcomex;
BEGINEND TypeCaseStmt.
 - Jay
From: jay.krell at cornell.edu
To: m3devel at elegosoft.com; hosking at cs.purdue.edu
Date: Sun, 27 Jun 2010 08:12:54 +0000
Subject: [M3devel] m3cg 4.5 problem








This tiny bit of code, which is cut down from m3front, causes an assertion failure in a 4.5 m3cg:
MODULE TypeCaseStmt;
IMPORT M3ID, CG, Expr, Stmt, StmtRep, Type, Variable, Scope;
PROCEDURE GetOutcomex (): Stmt.Outcomes =  VAR oc := Stmt.Outcomes {};  line 6  BEGIN    RETURN oc;  END GetOutcomex;
BEGINEND TypeCaseStmt.
../src/stmts/TypeCaseStmt.m3:6:0: internal compiler error: in gimplify_expr, at gimplify.c:7315Please submit a full bug report,

(1) begin_unit(2) set_source_file(3) set_source_line  source line    1(4) comment  comment: `module global constants'(5) declare_segment  segment L_1 typeid 0xffffffff(6) comment  comment: `module global data'(7) declare_segment  segment MM_TypeCaseStmt typeid 0xffffffff(8) set_source_line  source line   11(9) declare_procedure  type:addr  procedure:TypeCaseStmt_M3 nparams:0x1 rettype:addr lev:0 exported:1(10) declare_param  type:int64  param M3_AcxOUs_mode type:int64 typeid:0x195c2a74 bytesize:0x40 alignment:0x40 in_memory:0x0 up_level:0x0  mode 0x11 (DImode)(11) import_procedure  type:addr  procedure:TypeCaseStmt_I3 nparams:0x0 rettype:addr(12) export_unit(13) import_procedure  type:addr  procedure:Scope_I3 nparams:0x0 rettype:addr(14) import_unit(15) import_procedure  type:addr  procedure:Variable_I3 nparams:0x0 rettype:addr(16) import_unit(17) import_procedure  type:addr  procedure:Type_I3 nparams:0x0 rettype:addr(18) import_unit(19) import_procedure  type:addr  procedure:StmtRep_I3 nparams:0x0 rettype:addr(20) import_unit(21) import_procedure  type:addr  procedure:Stmt_I3 nparams:0x0 rettype:addr(22) import_unit(23) import_procedure  type:addr  procedure:Expr_I3 nparams:0x0 rettype:addr(24) import_unit(25) import_procedure  type:addr  procedure:CG_I3 nparams:0x0 rettype:addr(26) import_unit(27) import_procedure  type:addr  procedure:M3ID_I3 nparams:0x0 rettype:addr(28) import_unit(29) import_procedure  type:addr  procedure:RTHooks_I3 nparams:0x0 rettype:addr(30) import_unit(31) declare_procedure  type:word64  procedure:TypeCaseStmt__GetOutcomex nparams:0x0 rettype:word64 lev:0 exported:0(32) declare_local  type:word64  local var M3_EXQtd6_oc type:word64 size:0x40 alignment:0x40(33) declare_local  type:word64  local var M3_EXQtd6__result type:word64 size:0x40 alignment:0x40(34) comment  comment: `GetOutcomex'(35) set_source_line  source line    5(36) begin_procedure  procedure TypeCaseStmt__GetOutcomex TypeCaseStmt__GetOutcomex(37) set_source_line  source line    6(38) load_integer  type:int64  integer:0x0(39) store  type:int64  type:int64  store (M3_EXQtd6_oc) offset:0x0 src_t:int64 dst_t:int64(40) set_source_line  source line    8(41) load  type:word64  type:int64  m3cg_load (M3_EXQtd6_oc): offset 0x0, convert word64 -> int64(42) exit_proc  type:word64(43) end_procedure  procedure TypeCaseStmt__GetOutcomex

Breakpoint 1, fancy_abort (file=0x1009f0c6f "../../gcc-4.5/gcc/gimplify.c", line=7315, function=0x1009f1242 "gimplify_expr") at ../../gcc-4.5/gcc/diagnostic.c:763763	  internal_error ("in %s, at %s:%d", function, trim_filename (file), line);(gdb) bt#0  fancy_abort (file=0x1009f0c6f "../../gcc-4.5/gcc/gimplify.c", line=7315, function=0x1009f1242 "gimplify_expr") at ../../gcc-4.5/gcc/diagnostic.c:763#1  0x00000001004cc4d6 in gimplify_expr (expr_p=0x1410e2060, pre_p=0x7fff5fbff420, post_p=0x7fff5fbfeff8, gimple_test_f=0x1004aac7f <is_gimple_lvalue>, fallback=2) at ../../gcc-4.5/gcc/gimplify.c:7315#2  0x00000001004c5ad3 in gimplify_modify_expr (expr_p=0x1416a5f28, pre_p=0x7fff5fbff420, post_p=0x7fff5fbfeff8, want_value=0 '\0') at ../../gcc-4.5/gcc/gimplify.c:4444#3  0x00000001004caafc in gimplify_expr (expr_p=0x1416a5f28, pre_p=0x7fff5fbff420, post_p=0x7fff5fbfeff8, gimple_test_f=0x1004ab1a6 <is_gimple_stmt>, fallback=0) at ../../gcc-4.5/gcc/gimplify.c:6619#4  0x00000001004c7800 in gimplify_stmt (stmt_p=0x1416a5f28, seq_p=0x7fff5fbff420) at ../../gcc-4.5/gcc/gimplify.c:5264#5  0x00000001004be376 in gimplify_statement_list (expr_p=0x1416c4030, pre_p=0x7fff5fbff420) at ../../gcc-4.5/gcc/gimplify.c:1382#6  0x00000001004cb6f5 in gimplify_expr (expr_p=0x1416c4030, pre_p=0x7fff5fbff420, post_p=0x7fff5fbff2e8, gimple_test_f=0x1004ab1a6 <is_gimple_stmt>, fallback=0) at ../../gcc-4.5/gcc/gimplify.c:6935#7  0x00000001004c7800 in gimplify_stmt (stmt_p=0x1416c4030, seq_p=0x7fff5fbff420) at ../../gcc-4.5/gcc/gimplify.c:5264#8  0x00000001004bdb6c in gimplify_bind_expr (expr_p=0x1416c2298, pre_p=0x7fff5fbff778) at ../../gcc-4.5/gcc/gimplify.c:1127#9  0x00000001004cae2b in gimplify_expr (expr_p=0x1416c2298, pre_p=0x7fff5fbff778, post_p=0x7fff5fbff618, gimple_test_f=0x1004ab1a6 <is_gimple_stmt>, fallback=0) at ../../gcc-4.5/gcc/gimplify.c:6719#10 0x00000001004c7800 in gimplify_stmt (stmt_p=0x1416c2298, seq_p=0x7fff5fbff778) at ../../gcc-4.5/gcc/gimplify.c:5264#11 0x00000001004ccbe6 in gimplify_body (body_p=0x1416c2298, fndecl=0x1416c2200, do_parms=1 '\001') at ../../gcc-4.5/gcc/gimplify.c:7528#12 0x00000001004cceae in gimplify_function_tree (fndecl=0x1416c2200) at ../../gcc-4.5/gcc/gimplify.c:7624#13 0x00000001000069c7 in m3_gimplify_function (fndecl=0x1416c2200) at ../../gcc-4.5/gcc/m3cg/parse.c:2370#14 0x0000000100009cb4 in m3cg_end_procedure () at ../../gcc-4.5/gcc/m3cg/parse.c:3642#15 0x000000010000feb5 in m3_parse_file (xx=0) at ../../gcc-4.5/gcc/m3cg/parse.c:5550#16 0x00000001006be6a2 in compile_file () at ../../gcc-4.5/gcc/toplev.c:1053#17 0x00000001006c0e19 in do_compile () at ../../gcc-4.5/gcc/toplev.c:2415#18 0x00000001006c0ee0 in toplev_main (argc=3, argv=0x7fff5fbff930) at ../../gcc-4.5/gcc/toplev.c:2457#19 0x000000010001743b in main (argc=3, argv=0x7fff5fbff930) at ../../gcc-4.5/gcc/main.c:35(

Wierd, huh?
The only thing I can think of an int/word mismatch.I did change one instance of Integer to Word, after finding this.Stmt.Outcomes is an enumeration.So presumably Stmt.Outcomes { } is 0.Enumerations should work equally well as Integer or Word, right?Clearly above there is still a mix. I can try changing them all to Word.

I'll keep digging.

Maybe dump the entire function generic tree for this and similar C.

 - Jay 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100627/0a29baa9/attachment-0001.html>

From jay.krell at cornell.edu  Mon Jun 28 03:39:35 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 28 Jun 2010 01:39:35 +0000
Subject: [M3devel] gcc 4.5 status
Message-ID: <COL101-W56446A25BC09D1C25A5AD9E6CA0@phx.gbl>


Gcc 4.5 complains about a few similar aspects of our trees.
These would all be errors but I hacked the gcc source to make them warnings.


Running cm3 build with gcc 4.5 crashes early in sysutils => PathReprCommon => Text.Length.


I think I'll try to fix up these type issues first.
You can see they aren't all that interesting, either widening an unsigned integer or
changing the signedness but not the width of an integer.

It's likely this checking isn't on by default, but that I enabled it, and that the errors/warnings are true,
?even though my enabling might have been by hacking the #idefs instead of the configure command.


I assume upgrading to gcc 4.5 is considered fairly unilaterly uncontroversially good.
I chose working on it for that reason.


D.1401 = TextClass__GetChar (M3_Bd56fi_t.11, M3_Cwb5VA_i.10);

cm3cg: warning: type mismatch in indirect reference
word_64

<unnamed type>

D.1408 = *D.1407;

cm3cg: warning: verify_gimple failed
../src/cm3/TextUtils.m3: In function 'TextUtils__SkipRight':
cm3cg: warning: invalid conversion in gimple call
word_8

word_64

D.1481 = TextClass__GetChar (M3_Bd56fi_t.36, D.1479);

cm3cg: warning: type mismatch in indirect reference
word_64

<unnamed type>

D.1488 = *D.1487;

cm3cg: warning: verify_gimple failed
../src/cm3/TextUtils.m3: In function 'TextUtils__Compress':
cm3cg: warning: invalid conversion in gimple call
word_8

word_64

D.1553 = TextClass__GetChar (M3_Bd56fi_t.59, M3_Cwb5VA_i.58);

cm3cg: warning: type mismatch in indirect reference
word_64

<unnamed type>

D.1560 = *D.1559;

cm3cg: warning: invalid conversion in gimple call
word_8

word_64

D.1591 = TextClass__GetChar (M3_Bd56fi_t.67, D.1589);

cm3cg: warning: type mismatch in indirect reference
word_64

<unnamed type>

D.1598 = *D.1597;

cm3cg: warning: verify_gimple failed
../src/cm3/TextUtils.m3: In function 'TextUtils__SubstChar':
cm3cg: warning: invalid conversion in gimple call
word_8

word_64

D.1683 = TextClass__GetChar (M3_Bd56fi_t.99, D.1681);

cm3cg: warning: type mismatch in binary expression
word_64

int_64

int_64

D.1701 = D.1700 & 1;

cm3cg: warning: type mismatch in binary expression
word_64

int_64

int_64






 		 	   		  

From dabenavidesd at yahoo.es  Mon Jun 28 04:37:11 2010
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Mon, 28 Jun 2010 02:37:11 +0000 (GMT)
Subject: [M3devel] gcc 4.5 status
In-Reply-To: <COL101-W56446A25BC09D1C25A5AD9E6CA0@phx.gbl>
Message-ID: <619968.30896.qm@web23605.mail.ird.yahoo.com>

Hi all:
please let me investigate before you make the simple changes you are trying because as I understand the type of the ADR operator might be of an unsafe module but that doesn't mean you can hack it to do your program better compile (that would be like use an ill behaved program to make "well" behaved ones). I mean is good to discard that the type system (the set of sound type rules that make a program compile run and if safely guarded do its work flawlessly, that is, the set of safe and well behaved programs without ill behaved in there) is not "hacked" hard coded to expect the type of ADR to be ADDRESS instead of the UNTRACED REF T.
I would like to be pointed out the way you are trying to solve the initial problem, I mean it is easy to see that ADR operator might return ADDRESS but probably not in all cases (programs) to be UNTRACED REF T though your programs show yes, changes reveal there is a problem indeed with current tree.
Anyway this needs to confirm there is a change in the type rules a check of original m3tk as before had happened with the new types or type introductions rules.
I might need explanations about your rationale behind the new ADR type so if you don't mind just tell me what are the reasons to do the mentioned changes if you don't mind. I know there are this emails:
https://mail.elegosoft.com/pipermail/m3devel/2010-June/007241.html
and
https://mail.elegosoft.com/pipermail/m3devel/2010-June/007249.html
BTW are the m3-sys/cm3/m3test shipped to the source browser in Elego web pages, I might need to check this test cases before the actual code, see:
http://opencm3.net/doc/help/gen_html/INDEX.html
If not we better make some ones testing UNSAFE features if they aren't shipped and/or already done (just to proof well behaved programs properties in UNSAFE modules to see if they actually work and if not why do they fail, I know there might be less panic with them but is better to have them than nothing, we might make some directory of them if somebody can point out where I can put then I have Elego ssh keys so I can see what I can do about it).

Thanks for your attention


--- El dom, 27/6/10, Jay K <jay.krell at cornell.edu> escribi?:

> De: Jay K <jay.krell at cornell.edu>
> Asunto: [M3devel] gcc 4.5 status
> Para: "m3devel" <m3devel at elegosoft.com>
> Fecha: domingo, 27 de junio, 2010 20:39
> 
> Gcc 4.5 complains about a few similar aspects of our
> trees.
> These would all be errors but I hacked the gcc source to
> make them warnings.
> 
> 
> Running cm3 build with gcc 4.5 crashes early in sysutils
> => PathReprCommon => Text.Length.
> 
> 
> I think I'll try to fix up these type issues first.
> You can see they aren't all that interesting, either
> widening an unsigned integer or
> changing the signedness but not the width of an integer.
> 
> It's likely this checking isn't on by default, but that I
> enabled it, and that the errors/warnings are true,
>  even though my enabling might have been by hacking the
> #idefs instead of the configure command.
> 
> 
> I assume upgrading to gcc 4.5 is considered fairly
> unilaterly uncontroversially good.
> I chose working on it for that reason.
> 
> 
> D.1401 = TextClass__GetChar (M3_Bd56fi_t.11,
> M3_Cwb5VA_i.10);
> 
> cm3cg: warning: type mismatch in indirect reference
> word_64
> 
> <unnamed type>
> 
> D.1408 = *D.1407;
> 
> cm3cg: warning: verify_gimple failed
> ../src/cm3/TextUtils.m3: In function
> 'TextUtils__SkipRight':
> cm3cg: warning: invalid conversion in gimple call
> word_8
> 
> word_64
> 
> D.1481 = TextClass__GetChar (M3_Bd56fi_t.36, D.1479);
> 
> cm3cg: warning: type mismatch in indirect reference
> word_64
> 
> <unnamed type>
> 
> D.1488 = *D.1487;
> 
> cm3cg: warning: verify_gimple failed
> ../src/cm3/TextUtils.m3: In function
> 'TextUtils__Compress':
> cm3cg: warning: invalid conversion in gimple call
> word_8
> 
> word_64
> 
> D.1553 = TextClass__GetChar (M3_Bd56fi_t.59,
> M3_Cwb5VA_i.58);
> 
> cm3cg: warning: type mismatch in indirect reference
> word_64
> 
> <unnamed type>
> 
> D.1560 = *D.1559;
> 
> cm3cg: warning: invalid conversion in gimple call
> word_8
> 
> word_64
> 
> D.1591 = TextClass__GetChar (M3_Bd56fi_t.67, D.1589);
> 
> cm3cg: warning: type mismatch in indirect reference
> word_64
> 
> <unnamed type>
> 
> D.1598 = *D.1597;
> 
> cm3cg: warning: verify_gimple failed
> ../src/cm3/TextUtils.m3: In function
> 'TextUtils__SubstChar':
> cm3cg: warning: invalid conversion in gimple call
> word_8
> 
> word_64
> 
> D.1683 = TextClass__GetChar (M3_Bd56fi_t.99, D.1681);
> 
> cm3cg: warning: type mismatch in binary expression
> word_64
> 
> int_64
> 
> int_64
> 
> D.1701 = D.1700 & 1;
> 
> cm3cg: warning: type mismatch in binary expression
> word_64
> 
> int_64
> 
> int_64
> 
> 
> 
> 
> 
> 
>     
>         
>           
>   


      


From jay.krell at cornell.edu  Mon Jun 28 10:08:13 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 28 Jun 2010 08:08:13 +0000
Subject: [M3devel] gcc 4.5 status
In-Reply-To: <619968.30896.qm@web23605.mail.ird.yahoo.com>
References: <COL101-W56446A25BC09D1C25A5AD9E6CA0@phx.gbl>,
	<619968.30896.qm@web23605.mail.ird.yahoo.com>
Message-ID: <COL101-W395F243446FE921432E2E3E6CA0@phx.gbl>


Daniel, I'm afraid I generally don't understand much that you say.
True, m3tools/m3tk should ideally follow the compiler's definition of ADR.
Moving to gcc 4.5 has nothing to do with changing the meaning of ADR. Granted, I jump around a bit.

current/old ADR return ADDRESS, which is silently assignable to any UNTRACED REF type.
new ADR(t) returns UNTRACED REF t.

Consider C.
In C, void* is assignable to any pointer type. (not so in C++)
In C, &T returns T*, not void*.
So &T is NOT assignable to any pointer type, only T* and void*.

The idea here would be elevate unsafe Modula-3 to C's level of safety.
Instead of being even less safe.

Despite the lack of safety, a certain amount of static checking is a good idea.


?- Jay

----------------------------------------
> Date: Mon, 28 Jun 2010 02:37:11 +0000
> From: dabenavidesd at yahoo.es
> To: m3devel at elegosoft.com; jay.krell at cornell.edu
> Subject: Re: [M3devel] gcc 4.5 status
>
> Hi all:
> please let me investigate before you make the simple changes you are trying because as I understand the type of the ADR operator might be of an unsafe module but that doesn't mean you can hack it to do your program better compile (that would be like use an ill behaved program to make "well" behaved ones). I mean is good to discard that the type system (the set of sound type rules that make a program compile run and if safely guarded do its work flawlessly, that is, the set of safe and well behaved programs without ill behaved in there) is not "hacked" hard coded to expect the type of ADR to be ADDRESS instead of the UNTRACED REF T.
> I would like to be pointed out the way you are trying to solve the initial problem, I mean it is easy to see that ADR operator might return ADDRESS but probably not in all cases (programs) to be UNTRACED REF T though your programs show yes, changes reveal there is a problem indeed with current tree.
> Anyway this needs to confirm there is a change in the type rules a check of original m3tk as before had happened with the new types or type introductions rules.
> I might need explanations about your rationale behind the new ADR type so if you don't mind just tell me what are the reasons to do the mentioned changes if you don't mind. I know there are this emails:
> https://mail.elegosoft.com/pipermail/m3devel/2010-June/007241.html
> and
> https://mail.elegosoft.com/pipermail/m3devel/2010-June/007249.html
> BTW are the m3-sys/cm3/m3test shipped to the source browser in Elego web pages, I might need to check this test cases before the actual code, see:
> http://opencm3.net/doc/help/gen_html/INDEX.html
> If not we better make some ones testing UNSAFE features if they aren't shipped and/or already done (just to proof well behaved programs properties in UNSAFE modules to see if they actually work and if not why do they fail, I know there might be less panic with them but is better to have them than nothing, we might make some directory of them if somebody can point out where I can put then I have Elego ssh keys so I can see what I can do about it).
>
> Thanks for your attention
>
>
> --- El dom, 27/6/10, Jay K  escribi?:
>
>> De: Jay K 
>> Asunto: [M3devel] gcc 4.5 status
>> Para: "m3devel" 
>> Fecha: domingo, 27 de junio, 2010 20:39
>>
>> Gcc 4.5 complains about a few similar aspects of our
>> trees.
>> These would all be errors but I hacked the gcc source to
>> make them warnings.
>>
>>
>> Running cm3 build with gcc 4.5 crashes early in sysutils
>> => PathReprCommon => Text.Length.
>>
>>
>> I think I'll try to fix up these type issues first.
>> You can see they aren't all that interesting, either
>> widening an unsigned integer or
>> changing the signedness but not the width of an integer.
>>
>> It's likely this checking isn't on by default, but that I
>> enabled it, and that the errors/warnings are true,
>> even though my enabling might have been by hacking the
>> #idefs instead of the configure command.
>>
>>
>> I assume upgrading to gcc 4.5 is considered fairly
>> unilaterly uncontroversially good.
>> I chose working on it for that reason.
>>
>>
>> D.1401 = TextClass__GetChar (M3_Bd56fi_t.11,
>> M3_Cwb5VA_i.10);
>>
>> cm3cg: warning: type mismatch in indirect reference
>> word_64
>>
>> 
>>
>> D.1408 = *D.1407;
>>
>> cm3cg: warning: verify_gimple failed
>> ../src/cm3/TextUtils.m3: In function
>> 'TextUtils__SkipRight':
>> cm3cg: warning: invalid conversion in gimple call
>> word_8
>>
>> word_64
>>
>> D.1481 = TextClass__GetChar (M3_Bd56fi_t.36, D.1479);
>>
>> cm3cg: warning: type mismatch in indirect reference
>> word_64
>>
>> 
>>
>> D.1488 = *D.1487;
>>
>> cm3cg: warning: verify_gimple failed
>> ../src/cm3/TextUtils.m3: In function
>> 'TextUtils__Compress':
>> cm3cg: warning: invalid conversion in gimple call
>> word_8
>>
>> word_64
>>
>> D.1553 = TextClass__GetChar (M3_Bd56fi_t.59,
>> M3_Cwb5VA_i.58);
>>
>> cm3cg: warning: type mismatch in indirect reference
>> word_64
>>
>> 
>>
>> D.1560 = *D.1559;
>>
>> cm3cg: warning: invalid conversion in gimple call
>> word_8
>>
>> word_64
>>
>> D.1591 = TextClass__GetChar (M3_Bd56fi_t.67, D.1589);
>>
>> cm3cg: warning: type mismatch in indirect reference
>> word_64
>>
>> 
>>
>> D.1598 = *D.1597;
>>
>> cm3cg: warning: verify_gimple failed
>> ../src/cm3/TextUtils.m3: In function
>> 'TextUtils__SubstChar':
>> cm3cg: warning: invalid conversion in gimple call
>> word_8
>>
>> word_64
>>
>> D.1683 = TextClass__GetChar (M3_Bd56fi_t.99, D.1681);
>>
>> cm3cg: warning: type mismatch in binary expression
>> word_64
>>
>> int_64
>>
>> int_64
>>
>> D.1701 = D.1700 & 1;
>>
>> cm3cg: warning: type mismatch in binary expression
>> word_64
>>
>> int_64
>>
>> int_64
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
 		 	   		  

From dabenavidesd at yahoo.es  Mon Jun 28 13:31:36 2010
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Mon, 28 Jun 2010 11:31:36 +0000 (GMT)
Subject: [M3devel] gcc 4.5 status
In-Reply-To: <COL101-W395F243446FE921432E2E3E6CA0@phx.gbl>
Message-ID: <760071.93937.qm@web23605.mail.ird.yahoo.com>

Hi:
ok, here is a good reference of type systems by Luca Cardelli, it is sort of familiar language with better conceptualization
http://lucacardelli.name/Papers/TypeSystems.pdf
Hope it helps and thanks for the answer let me know if the above paper is a proper clarification (I think it is, specially pages 1-4).
Thanks for the info, hope it helps 

--- El lun, 28/6/10, Jay K <jay.krell at cornell.edu> escribi?:

> De: Jay K <jay.krell at cornell.edu>
> Asunto: RE: [M3devel] gcc 4.5 status
> Para: "Daniel (M3)" <dabenavidesd at yahoo.es>, "m3devel" <m3devel at elegosoft.com>
> Fecha: lunes, 28 de junio, 2010 03:08
> 
> Daniel, I'm afraid I generally don't understand much that
> you say.
> True, m3tools/m3tk should ideally follow the compiler's
> definition of ADR.
> Moving to gcc 4.5 has nothing to do with changing the
> meaning of ADR. Granted, I jump around a bit.
> 
> current/old ADR return ADDRESS, which is silently
> assignable to any UNTRACED REF type.
> new ADR(t) returns UNTRACED REF t.
> 
> Consider C.
> In C, void* is assignable to any pointer type. (not so in
> C++)
> In C, &T returns T*, not void*.
> So &T is NOT assignable to any pointer type, only T*
> and void*.
> 
> The idea here would be elevate unsafe Modula-3 to C's level
> of safety.
> Instead of being even less safe.
> 
> Despite the lack of safety, a certain amount of static
> checking is a good idea.
> 
> 
>  - Jay
> 
> ----------------------------------------
> > Date: Mon, 28 Jun 2010 02:37:11 +0000
> > From: dabenavidesd at yahoo.es
> > To: m3devel at elegosoft.com;
> jay.krell at cornell.edu
> > Subject: Re: [M3devel] gcc 4.5 status
> >
> > Hi all:
> > please let me investigate before you make the simple
> changes you are trying because as I understand the type of
> the ADR operator might be of an unsafe module but that
> doesn't mean you can hack it to do your program better
> compile (that would be like use an ill behaved program to
> make "well" behaved ones). I mean is good to discard that
> the type system (the set of sound type rules that make a
> program compile run and if safely guarded do its work
> flawlessly, that is, the set of safe and well behaved
> programs without ill behaved in there) is not "hacked" hard
> coded to expect the type of ADR to be ADDRESS instead of the
> UNTRACED REF T.
> > I would like to be pointed out the way you are trying
> to solve the initial problem, I mean it is easy to see that
> ADR operator might return ADDRESS but probably not in all
> cases (programs) to be UNTRACED REF T though your programs
> show yes, changes reveal there is a problem indeed with
> current tree.
> > Anyway this needs to confirm there is a change in the
> type rules a check of original m3tk as before had happened
> with the new types or type introductions rules.
> > I might need explanations about your rationale behind
> the new ADR type so if you don't mind just tell me what are
> the reasons to do the mentioned changes if you don't mind. I
> know there are this emails:
> > https://mail.elegosoft.com/pipermail/m3devel/2010-June/007241.html
> > and
> > https://mail.elegosoft.com/pipermail/m3devel/2010-June/007249.html
> > BTW are the m3-sys/cm3/m3test shipped to the source
> browser in Elego web pages, I might need to check this test
> cases before the actual code, see:
> > http://opencm3.net/doc/help/gen_html/INDEX.html
> > If not we better make some ones testing UNSAFE
> features if they aren't shipped and/or already done (just to
> proof well behaved programs properties in UNSAFE modules to
> see if they actually work and if not why do they fail, I
> know there might be less panic with them but is better to
> have them than nothing, we might make some directory of them
> if somebody can point out where I can put then I have Elego
> ssh keys so I can see what I can do about it).
> >
> > Thanks for your attention
> >
> >
> > --- El dom, 27/6/10, Jay K  escribi?:
> >
> >> De: Jay K 
> >> Asunto: [M3devel] gcc 4.5 status
> >> Para: "m3devel" 
> >> Fecha: domingo, 27 de junio, 2010 20:39
> >>
> >> Gcc 4.5 complains about a few similar aspects of
> our
> >> trees.
> >> These would all be errors but I hacked the gcc
> source to
> >> make them warnings.
> >>
> >>
> >> Running cm3 build with gcc 4.5 crashes early in
> sysutils
> >> => PathReprCommon => Text.Length.
> >>
> >>
> >> I think I'll try to fix up these type issues
> first.
> >> You can see they aren't all that interesting,
> either
> >> widening an unsigned integer or
> >> changing the signedness but not the width of an
> integer.
> >>
> >> It's likely this checking isn't on by default, but
> that I
> >> enabled it, and that the errors/warnings are
> true,
> >> even though my enabling might have been by hacking
> the
> >> #idefs instead of the configure command.
> >>
> >>
> >> I assume upgrading to gcc 4.5 is considered
> fairly
> >> unilaterly uncontroversially good.
> >> I chose working on it for that reason.
> >>
> >>
> >> D.1401 = TextClass__GetChar (M3_Bd56fi_t.11,
> >> M3_Cwb5VA_i.10);
> >>
> >> cm3cg: warning: type mismatch in indirect
> reference
> >> word_64
> >>
> >> 
> >>
> >> D.1408 = *D.1407;
> >>
> >> cm3cg: warning: verify_gimple failed
> >> ../src/cm3/TextUtils.m3: In function
> >> 'TextUtils__SkipRight':
> >> cm3cg: warning: invalid conversion in gimple call
> >> word_8
> >>
> >> word_64
> >>
> >> D.1481 = TextClass__GetChar (M3_Bd56fi_t.36,
> D.1479);
> >>
> >> cm3cg: warning: type mismatch in indirect
> reference
> >> word_64
> >>
> >> 
> >>
> >> D.1488 = *D.1487;
> >>
> >> cm3cg: warning: verify_gimple failed
> >> ../src/cm3/TextUtils.m3: In function
> >> 'TextUtils__Compress':
> >> cm3cg: warning: invalid conversion in gimple call
> >> word_8
> >>
> >> word_64
> >>
> >> D.1553 = TextClass__GetChar (M3_Bd56fi_t.59,
> >> M3_Cwb5VA_i.58);
> >>
> >> cm3cg: warning: type mismatch in indirect
> reference
> >> word_64
> >>
> >> 
> >>
> >> D.1560 = *D.1559;
> >>
> >> cm3cg: warning: invalid conversion in gimple call
> >> word_8
> >>
> >> word_64
> >>
> >> D.1591 = TextClass__GetChar (M3_Bd56fi_t.67,
> D.1589);
> >>
> >> cm3cg: warning: type mismatch in indirect
> reference
> >> word_64
> >>
> >> 
> >>
> >> D.1598 = *D.1597;
> >>
> >> cm3cg: warning: verify_gimple failed
> >> ../src/cm3/TextUtils.m3: In function
> >> 'TextUtils__SubstChar':
> >> cm3cg: warning: invalid conversion in gimple call
> >> word_8
> >>
> >> word_64
> >>
> >> D.1683 = TextClass__GetChar (M3_Bd56fi_t.99,
> D.1681);
> >>
> >> cm3cg: warning: type mismatch in binary
> expression
> >> word_64
> >>
> >> int_64
> >>
> >> int_64
> >>
> >> D.1701 = D.1700 & 1;
> >>
> >> cm3cg: warning: type mismatch in binary
> expression
> >> word_64
> >>
> >> int_64
> >>
> >> int_64
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
>     
>         
>           
>   


      


From jay.krell at cornell.edu  Mon Jun 28 14:08:47 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 28 Jun 2010 12:08:47 +0000
Subject: [M3devel] "the tree problems"
Message-ID: <COL101-W50F7EF3F8B51097C14CDF9E6CA0@phx.gbl>


The "tree problems" exist with gcc 4.3 also.
I'd like to clear these up ahead of most other work.
? Enable configure -enable-checking=something unconditionally.

There a few. Some are more trivial than others.

Here is a start that I'm testing:
It can be broken into two parts, "bit operations (and/or/xor/not)" and index_address.

Index: parse.c
===================================================================
RCS file: /usr/cvs/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c,v
retrieving revision 1.201
diff -u -5 -r1.201 parse.c
--- parse.c??? 27 Jun 2010 14:09:32 -0000??? 1.201
+++ parse.c??? 28 Jun 2010 12:04:49 -0000
@@ -4404,41 +4404,43 @@
?static void
?m3cg_not (void)
?{
?? MTYPE (t);
?
-? EXPR_REF (-1) = m3_build1 (BIT_NOT_EXPR, m3_unsigned_type (t),
-???????????????????????????? EXPR_REF (-1));
+? EXPR_REF (-1) = m3_build1 (BIT_NOT_EXPR, t, m3_cast (t, EXPR_REF (-1)));
?}
?
?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_REF (-2) = m3_build2 (BIT_AND_EXPR, t,
+???????????????????????????? m3_cast (t, EXPR_REF (-2)),
+???????????????????????????? m3_cast (t, EXPR_REF (-1)));
?? EXPR_POP ();
?}
?
?static void
?m3cg_or (void)
?{
?? MTYPE (t);
?
-? EXPR_REF (-2) = m3_build2 (BIT_IOR_EXPR, m3_unsigned_type (t),
-???????????????????????????? EXPR_REF (-2), EXPR_REF (-1));
+? EXPR_REF (-2) = m3_build2 (BIT_IOR_EXPR, t,
+???????????????????????????? m3_cast (t, EXPR_REF (-2)),
+???????????????????????????? m3_cast (t, EXPR_REF (-1)));
?? EXPR_POP ();
?}
?
?static void
?m3cg_xor (void)
?{
?? MTYPE (t);
?
-? EXPR_REF (-2) = m3_build2 (BIT_XOR_EXPR, m3_unsigned_type (t),
-???????????????????????????? EXPR_REF (-2), EXPR_REF (-1));
+? EXPR_REF (-2) = m3_build2 (BIT_XOR_EXPR, t,
+???????????????????????????? m3_cast (t, EXPR_REF (-2)),
+???????????????????????????? m3_cast (t, EXPR_REF (-1)));
?? EXPR_POP ();
?}
?
?static void
?m3cg_shift (void)
@@ -4972,28 +4974,29 @@
?}
?
?static void
?m3cg_index_address (void)
?{
-? enum tree_code plus = (GCC45 ? POINTER_PLUS_EXPR : PLUS_EXPR);
-? tree a = { 0 };
?? MTYPE2?? (t, T);
-? BYTESIZE (n);
+? BYTESIZE (bits);
+? long bytes = bits / BITS_PER_UNIT;
+? bool signd = IS_INTEGER_TYPE_TREE(t);? 
+? tree a = (signd ? ssize_int (bytes) : ssize_int (bytes));
?
?? if (option_vars_trace)
-??? fprintf(stderr, "? index address n:0x%lx n_bytes:0x%lx type:%s\n",
-??????????? n, n / BITS_PER_UNIT, m3cg_typename(T));
+??? fprintf(stderr, "? index address n_bytes:0x%lx type:%s\n",
+??????????? bytes, m3cg_typename(T));
?
-? a = m3_build2 (MULT_EXPR, t, EXPR_REF (-1), size_int (n / BITS_PER_UNIT));
-? if (GCC45)
-? {
-??? gcc_assert(IS_INTEGER_TYPE_TREE(t) || IS_WORD_TYPE_TREE(t));
-??? if (IS_INTEGER_TYPE_TREE(t))
-????? a = m3_cast(ssizetype, a);
-??? a = m3_cast(sizetype, a);
-? }
-? EXPR_REF (-2) = m3_build2 (plus, t_addr, m3_cast (t_addr, EXPR_REF (-2)), a);
+? gcc_assert(signd || IS_WORD_TYPE_TREE(t));
+? gcc_assert(bits>= 0);
+? gcc_assert(bytes>= 0);
+? 
+? a = m3_build2 (MULT_EXPR, t, m3_cast(t, EXPR_REF (-1)), a);
+? if (signd)
+??? a = m3_cast(ssizetype, a);
+? a = m3_cast(sizetype, a);
+? EXPR_REF (-2) = m3_build2 (POINTER_PLUS_EXPR, t_addr, m3_cast (t_addr, EXPR_REF (-2)), a);
?? EXPR_POP ();
?}
?

alternatively we could try like:


+? EXPR_REF (-2) = m3_build2 (BIT_AND_EXPR, t,

+???????????????????????????? EXPR_REF (-2),

+???????????????????????????? EXPR_REF (-1));



which is nicer, if it works.


Though I believe the more "forceful" (cast-ful) interpretation is what Tony described a while ago, in describing what the NT/x86 backend does wrong.
These "bit" are fairly uniquely uninteresting, since they don't vary for signed vs. unsigned.


There are more problems in shifting, where I'm treading more carefully, since right shift's and "extract" are affected by signed vs. unsigned.


? - Jay
 		 	   		  

From rcolebur at SCIRES.COM  Mon Jun 28 21:26:18 2010
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Mon, 28 Jun 2010 15:26:18 -0400
Subject: [M3devel] m3core compilation errors on HEAD branch
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E62F8D76D1@ATLEX02-SRV.SCIRES.LOCAL>

Jay:

I'm getting a bunch of compile errors on m3core package.

These are all from various "C" files, not modula-3.

Regards,
Randy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100628/b04b23d6/attachment-0001.html>

From jay.krell at cornell.edu  Mon Jun 28 22:04:41 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 28 Jun 2010 20:04:41 +0000
Subject: [M3devel] m3core compilation errors on HEAD branch
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E62F8D76D1@ATLEX02-SRV.SCIRES.LOCAL>
References: <D67F02DDC62F7545A6B84C285F88F3E62F8D76D1@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <COL101-W482011876B9BE028B81FB4E6CA0@phx.gbl>


I fixed hand.c.
I'll look at the rest later.

?- Jay


________________________________
> From: rcolebur at SCIRES.COM
> To: m3devel at elegosoft.com
> Date: Mon, 28 Jun 2010 15:26:18 -0400
> Subject: [M3devel] m3core compilation errors on HEAD branch
>
> Jay:
>
> I?m getting a bunch of compile errors on m3core
> package.
>
> These are all from various ?C? files, not
> modula-3.
>
> Regards,

> Randy
>
>
 		 	   		  

From jay.krell at cornell.edu  Mon Jun 28 22:49:53 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 28 Jun 2010 20:49:53 +0000
Subject: [M3devel] windows msi, file ownership
Message-ID: <COL101-W4607C2990464A09FC2013DE6CA0@phx.gbl>


I'm using the msi and I noticed the files are owned by nt authority\system.
Kind of annoying. A little harder to replace than "normal".
Probably should be changed to administrator.

?- Jay




 		 	   		  

From jay.krell at cornell.edu  Tue Jun 29 11:25:37 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 29 Jun 2010 09:25:37 +0000
Subject: [M3devel] gcc tree checking
Message-ID: <COL101-W5454413A2730ED2963AFD1E6CB0@phx.gbl>


One of the (series of) tree type mismatches is like:


m3cgc1: warning: verify_gimple failed
?TextUtils__TextExtras_FindCharSet
../src/cm3/TextUtils.m3: In function 'TextUtils__TextExtras_FindCharSet':
m3cgc1: warning: invalid conversion in gimple call
word_8
word_64
D.3538 = Text__GetChar (M3_Bd56fi_t, M3_Cwb5VA_i.322);

GetChar returns word_8 but the call is asserted to return word_64.

I believe this comes from:

PROCEDURE EmitCall (t: T) =
? VAR result := ProcType.CGResult (t.signature);
? BEGIN
??? IF (t.impl_peer # NIL) THEN t := t.impl_peer; END;
??? CG.Call_direct (t.cg_proc, result);
??? EVAL Marker.EmitExceptionTest (t.signature, need_value := FALSE);
? END EmitCall;

PROCEDURE CGResult (t: Type.T): CG.Type =
? VAR p := Reduce (t);
? BEGIN
??? IF (p = NIL) OR (p.result = NIL) THEN
????? RETURN CG.Type.Void;
??? ELSIF NOT LargeResult (p.result) THEN
????? RETURN Type.CGType (p.result, in_memory := TRUE);
????? (*** 2/27/96 WKK:? in_memory = TRUE => so that Win32 code generator
?????????? can convert register return values to their full 32-bit width! ***)
??? ELSIF p.callConv.standard_structs THEN
????? RETURN CG.Type.Void;
??? ELSE
????? RETURN CG.Type.Struct;
??? END;
? END CGResult;

PROCEDURE CGType (t: T;? in_memory: BOOLEAN): CG.Type =
? BEGIN
??? t := Check (t);
??? IF (in_memory)
????? THEN RETURN t.info.mem_type;
????? ELSE RETURN t.info.stk_type;
??? END;
? END CGType;


I think in_memory needs to be FALSE, and the Win32 codegen should
I believe act the same, but I can check/fix that either way.

I'm thinking maybe I should make a test case that thoroughly exercise
each m3cg opcode and verifies that the output assembly is unchanged,
for a few architectures.

I believe this area really should be fixed, but almost must be very careful.. (like in everything..).

?- Jay

 		 	   		  

From jay.krell at cornell.edu  Tue Jun 29 14:17:27 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 29 Jun 2010 12:17:27 +0000
Subject: [M3devel] gcc tree checking
In-Reply-To: <COL101-W5454413A2730ED2963AFD1E6CB0@phx.gbl>
References: <COL101-W5454413A2730ED2963AFD1E6CB0@phx.gbl>
Message-ID: <COL101-W3C343C13C41DE503EDAE8E6CB0@phx.gbl>


Changing in_memory breaks cm3.
The fix is therefore probably in parse.c to cast or convert, similar to what m3back does.

?- Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Subject: gcc tree checking
> Date: Tue, 29 Jun 2010 09:25:37 +0000
>
>
> One of the (series of) tree type mismatches is like:
>
>
> m3cgc1: warning: verify_gimple failed
>  TextUtils__TextExtras_FindCharSet
> ../src/cm3/TextUtils.m3: In function 'TextUtils__TextExtras_FindCharSet':
> m3cgc1: warning: invalid conversion in gimple call
> word_8
> word_64
> D.3538 = Text__GetChar (M3_Bd56fi_t, M3_Cwb5VA_i.322);
>
> GetChar returns word_8 but the call is asserted to return word_64.
>
> I believe this comes from:
>
> PROCEDURE EmitCall (t: T) =
>   VAR result := ProcType.CGResult (t.signature);
>   BEGIN
>     IF (t.impl_peer # NIL) THEN t := t.impl_peer; END;
>     CG.Call_direct (t.cg_proc, result);
>     EVAL Marker.EmitExceptionTest (t.signature, need_value := FALSE);
>   END EmitCall;
>
> PROCEDURE CGResult (t: Type.T): CG.Type =
>   VAR p := Reduce (t);
>   BEGIN
>     IF (p = NIL) OR (p.result = NIL) THEN
>       RETURN CG.Type.Void;
>     ELSIF NOT LargeResult (p.result) THEN
>       RETURN Type.CGType (p.result, in_memory := TRUE);
>       (*** 2/27/96 WKK:  in_memory = TRUE => so that Win32 code generator
>            can convert register return values to their full 32-bit width! ***)
>     ELSIF p.callConv.standard_structs THEN
>       RETURN CG.Type.Void;
>     ELSE
>       RETURN CG.Type.Struct;
>     END;
>   END CGResult;
>
> PROCEDURE CGType (t: T;  in_memory: BOOLEAN): CG.Type =
>   BEGIN
>     t := Check (t);
>     IF (in_memory)
>       THEN RETURN t.info.mem_type;
>       ELSE RETURN t.info.stk_type;
>     END;
>   END CGType;
>
>
> I think in_memory needs to be FALSE, and the Win32 codegen should
> I believe act the same, but I can check/fix that either way.
>
> I'm thinking maybe I should make a test case that thoroughly exercise
> each m3cg opcode and verifies that the output assembly is unchanged,
> for a few architectures.
>
> I believe this area really should be fixed, but almost must be very careful.. (like in everything..).
>
>  - Jay
>
>
 		 	   		  

From rodney_bates at lcwb.coop  Tue Jun 29 19:59:01 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Tue, 29 Jun 2010 12:59:01 -0500
Subject: [M3devel] gcc tree checking
In-Reply-To: <COL101-W5454413A2730ED2963AFD1E6CB0@phx.gbl>
References: <COL101-W5454413A2730ED2963AFD1E6CB0@phx.gbl>
Message-ID: <4C2A3465.1080308@lcwb.coop>



Jay K wrote:
> One of the (series of) tree type mismatches is like:
> 
> 
> m3cgc1: warning: verify_gimple failed
>  TextUtils__TextExtras_FindCharSet
> ../src/cm3/TextUtils.m3: In function 'TextUtils__TextExtras_FindCharSet':
> m3cgc1: warning: invalid conversion in gimple call
> word_8
> word_64
> D.3538 = Text__GetChar (M3_Bd56fi_t, M3_Cwb5VA_i.322);
> 
> GetChar returns word_8 but the call is asserted to return word_64.
> 
> I believe this comes from:
> 
> PROCEDURE EmitCall (t: T) =
>   VAR result := ProcType.CGResult (t.signature);
>   BEGIN
>     IF (t.impl_peer # NIL) THEN t := t.impl_peer; END;
>     CG.Call_direct (t.cg_proc, result);
>     EVAL Marker.EmitExceptionTest (t.signature, need_value := FALSE);
>   END EmitCall;
> 
> PROCEDURE CGResult (t: Type.T): CG.Type =
>   VAR p := Reduce (t);
>   BEGIN
>     IF (p = NIL) OR (p.result = NIL) THEN
>       RETURN CG.Type.Void;
>     ELSIF NOT LargeResult (p.result) THEN
>       RETURN Type.CGType (p.result, in_memory := TRUE);
>       (*** 2/27/96 WKK:  in_memory = TRUE => so that Win32 code generator
>            can convert register return values to their full 32-bit width! ***)
>     ELSIF p.callConv.standard_structs THEN
>       RETURN CG.Type.Void;
>     ELSE
>       RETURN CG.Type.Struct;
>     END;
>   END CGResult;
> 
> PROCEDURE CGType (t: T;  in_memory: BOOLEAN): CG.Type =
>   BEGIN
>     t := Check (t);
>     IF (in_memory)
>       THEN RETURN t.info.mem_type;
>       ELSE RETURN t.info.stk_type;
>     END;
>   END CGType;
> 
> 
> I think in_memory needs to be FALSE, and the Win32 codegen should
> I believe act the same, but I can check/fix that either way.
> 
> I'm thinking maybe I should make a test case that thoroughly exercise
> each m3cg opcode and verifies that the output assembly is unchanged,
> for a few architectures.

This is a very good idea.  It may be a lot of work, but I have found
many times over that regression testing tools of this kind pay for
themselves in the (not so) long run.  Some of the changes found will
be legitimate, but that's a lot easier to verify than to chase obscure
bugs from end symptoms.

> 
> I believe this area really should be fixed, but almost must be very careful.. (like in everything..).
> 
>  - Jay
> 
>  		 	   		  


From jay.krell at cornell.edu  Tue Jun 29 22:28:53 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 29 Jun 2010 20:28:53 +0000
Subject: [M3devel] gcc tree checking
In-Reply-To: <4C2A3465.1080308@lcwb.coop>
References: <COL101-W5454413A2730ED2963AFD1E6CB0@phx.gbl>,
	<4C2A3465.1080308@lcwb.coop>
Message-ID: <COL101-W622BF57F65B4D5A9A22DF2E6CB0@phx.gbl>


I staked a claim, put in the start of something and made it work.
But then got lazy. I've been using m3core as my test.
Compiling all of it with cm3 -keep.
mv AMD64_DARWIN AMD64_DARWIN.1
make a compiler change
cm3 -keep again
diff -u AMD64_DARWIN.1 AMD64_DARWIN

And then often recompiling compiler with itself to push the change further.
?Hoping the compiler itself gets pretty good coverage, which has proven
? right and wrong through the years.

The test I put in can still be developed further.

?- Jay


----------------------------------------
> Date: Tue, 29 Jun 2010 12:59:01 -0500
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] gcc tree checking
>
>
>
> Jay K wrote:
>> One of the (series of) tree type mismatches is like:
>>
>>
>> m3cgc1: warning: verify_gimple failed
>> TextUtils__TextExtras_FindCharSet
>> ../src/cm3/TextUtils.m3: In function 'TextUtils__TextExtras_FindCharSet':
>> m3cgc1: warning: invalid conversion in gimple call
>> word_8
>> word_64
>> D.3538 = Text__GetChar (M3_Bd56fi_t, M3_Cwb5VA_i.322);
>>
>> GetChar returns word_8 but the call is asserted to return word_64.
>>
>> I believe this comes from:
>>
>> PROCEDURE EmitCall (t: T) =
>> VAR result := ProcType.CGResult (t.signature);
>> BEGIN
>> IF (t.impl_peer # NIL) THEN t := t.impl_peer; END;
>> CG.Call_direct (t.cg_proc, result);
>> EVAL Marker.EmitExceptionTest (t.signature, need_value := FALSE);
>> END EmitCall;
>>
>> PROCEDURE CGResult (t: Type.T): CG.Type =
>> VAR p := Reduce (t);
>> BEGIN
>> IF (p = NIL) OR (p.result = NIL) THEN
>> RETURN CG.Type.Void;
>> ELSIF NOT LargeResult (p.result) THEN
>> RETURN Type.CGType (p.result, in_memory := TRUE);
>> (*** 2/27/96 WKK: in_memory = TRUE => so that Win32 code generator
>> can convert register return values to their full 32-bit width! ***)
>> ELSIF p.callConv.standard_structs THEN
>> RETURN CG.Type.Void;
>> ELSE
>> RETURN CG.Type.Struct;
>> END;
>> END CGResult;
>>
>> PROCEDURE CGType (t: T; in_memory: BOOLEAN): CG.Type =
>> BEGIN
>> t := Check (t);
>> IF (in_memory)
>> THEN RETURN t.info.mem_type;
>> ELSE RETURN t.info.stk_type;
>> END;
>> END CGType;
>>
>>
>> I think in_memory needs to be FALSE, and the Win32 codegen should
>> I believe act the same, but I can check/fix that either way.
>>
>> I'm thinking maybe I should make a test case that thoroughly exercise
>> each m3cg opcode and verifies that the output assembly is unchanged,
>> for a few architectures.
>
> This is a very good idea. It may be a lot of work, but I have found
> many times over that regression testing tools of this kind pay for
> themselves in the (not so) long run. Some of the changes found will
> be legitimate, but that's a lot easier to verify than to chase obscure
> bugs from end symptoms.
>
>>
>> I believe this area really should be fixed, but almost must be very careful.. (like in everything..).
>>
>> - Jay
>>
>>
 		 	   		  

From wagner at elegosoft.com  Wed Jun 30 09:06:31 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Wed, 30 Jun 2010 09:06:31 +0200
Subject: [M3devel] gcc tree checking
In-Reply-To: <4C2A3465.1080308@lcwb.coop>
References: <COL101-W5454413A2730ED2963AFD1E6CB0@phx.gbl>
	<4C2A3465.1080308@lcwb.coop>
Message-ID: <20100630090631.10m2uzg52cs40sc8@mail.elegosoft.com>

Quoting "Rodney M. Bates" <rodney_bates at lcwb.coop>:

> Jay K wrote:
[...]
>> I'm thinking maybe I should make a test case that thoroughly exercise
>> each m3cg opcode and verifies that the output assembly is unchanged,
>> for a few architectures.
>
> This is a very good idea.  It may be a lot of work, but I have found
> many times over that regression testing tools of this kind pay for
> themselves in the (not so) long run.  Some of the changes found will
> be legitimate, but that's a lot easier to verify than to chase obscure
> bugs from end symptoms.

I second that. Regression testing for the generated code would be
great and give us much more safefy when changing the compiler.

So anybody who'd like to work in this area is greatly encouraged.

Of course a general easily extensible framework would be nice :-)
Preferrably written in quake and M3.

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  Tue Jun  1 11:03:01 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Tue, 01 Jun 2010 11:03:01 +0200
Subject: [M3devel] OS for CM3
In-Reply-To: <20100522215317.E428D1A2096@async.async.caltech.edu>
References: <20100522215317.E428D1A2096@async.async.caltech.edu>
Message-ID: <20100601110301.g7805qomqskk4wws@mail.elegosoft.com>

Quoting Mika Nystrom <mika at 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?

Do you have simple test programs we could use to regularly measure
the performance of multithreading on different target platforms?

FreeBSD should support scaling via threads, but I've no idea about
actual performance yet.

I've been using FreeBSD/amd64 for about half a year now at home
(due to sudden death of my old hardware) and it's running OK,
except for the occasional suprise after a source upgrade ;-)

I second your feeling of dismay about loss of traditional system
administration conventions... no time to keep up-to-date with
everything.

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  Tue Jun  1 13:16:16 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 1 Jun 2010 11:16:16 +0000
Subject: [M3devel] m3cg_pop checks for side effects on the wrong thing
Message-ID: <COL101-W3186CD99E2045404ED5924E6EF0@phx.gbl>


Tony, I started looking at the effect of fixing the m3cg_pop "bug", where it checks for tree_side_effects on the wrong thing.
? You know -- is it significant? Should it be fixed in release?
In every case I looked at, optimized and not, all the fix did was add unnecessary code.
So I took another step: I tried removing the add_stmt there all together.
I built m3core before and after that, optimized and not.
Again, the code appears to be equivalent either way, just that add_stmt adds unnecessary code.


I'm going to try building the compiler and the rest of the system with this change.
If that works, I think this is an ok change.
? And we can rest easy about release.


?- Jay




 		 	   		  

From jay.krell at cornell.edu  Tue Jun  1 18:00:41 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 1 Jun 2010 16:00:41 +0000
Subject: [M3devel] uninitialized + insert_mn
Message-ID: <COL101-W235ED30E74DF1BC021F7CBE6EF0@phx.gbl>


../src/runtime/common/RTCollector.m3: In function 'RTCollector__CleanOlderRefSanityCheck':
../src/runtime/common/RTCollector.m3:1724: warning: 'M3_EB9wjE_tc' is used uninitialized in this function
../src/runtime/common/RTCollector.m3: In function 'RTCollector__RefSanityCheck':
../src/runtime/common/RTCollector.m3:1702: warning: 'M3_EB9wjE_tc' is used uninitialized in this function


PROCEDURE RefSanityCheck (<*UNUSED*>v: RTHeapMap.Visitor;? cp? : ADDRESS) =
? VAR ref := LOOPHOLE(cp, UNTRACED REF RefReferent)^;
? BEGIN
??? IF ref # NIL THEN
????? VAR
??????? h? := HeaderOf(ref);
??????? tc := h.typecode;
????? BEGIN


It is actually *kind of* true.
The store to tc uses load tc, insert_mn, store tc.


Any idea what to do?
offset=0
count=20


I'm willing to just go without -Wuninitialized, or look into turning it off for any function that uses insert.
Maybe look into what gcc uses -- hey, maybe bitfield refs? Yeah yeah, I'm half serious.
Of course I remember they caused a problem.
Perhaps we can use them, just be sure to twiddle the bit offsets depending on endian?


What I'm really doing is looking into removing the heavy use of volatile.


?- Jay

 		 	   		  

From jay.krell at cornell.edu  Tue Jun  1 18:10:11 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 1 Jun 2010 16:10:11 +0000
Subject: [M3devel] uninitialized + insert_mn
In-Reply-To: <COL101-W235ED30E74DF1BC021F7CBE6EF0@phx.gbl>
References: <COL101-W235ED30E74DF1BC021F7CBE6EF0@phx.gbl>
Message-ID: <COL101-W336E3972DCE285DA3850A7E6EF0@phx.gbl>


I found the lame hack that volatizing whatever store follows an insert_mn works.
If it suffices for the entire tree I'll go with it for now.

?- Jay


----------------------------------------
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu; m3devel at elegosoft.com
> Date: Tue, 1 Jun 2010 16:00:41 +0000
> Subject: [M3devel] uninitialized + insert_mn
>
>
> ../src/runtime/common/RTCollector.m3: In function 'RTCollector__CleanOlderRefSanityCheck':
> ../src/runtime/common/RTCollector.m3:1724: warning: 'M3_EB9wjE_tc' is used uninitialized in this function
> ../src/runtime/common/RTCollector.m3: In function 'RTCollector__RefSanityCheck':
> ../src/runtime/common/RTCollector.m3:1702: warning: 'M3_EB9wjE_tc' is used uninitialized in this function
>
>
> PROCEDURE RefSanityCheck (<*UNUSED*>v: RTHeapMap.Visitor;  cp  : ADDRESS) =
>   VAR ref := LOOPHOLE(cp, UNTRACED REF RefReferent)^;
>   BEGIN
>     IF ref # NIL THEN
>       VAR
>         h  := HeaderOf(ref);
>         tc := h.typecode;
>       BEGIN
>
>
> It is actually *kind of* true.
> The store to tc uses load tc, insert_mn, store tc.
>
>
> Any idea what to do?
> offset=0
> count=20
>
>
> I'm willing to just go without -Wuninitialized, or look into turning it off for any function that uses insert.
> Maybe look into what gcc uses -- hey, maybe bitfield refs? Yeah yeah, I'm half serious.
> Of course I remember they caused a problem.
> Perhaps we can use them, just be sure to twiddle the bit offsets depending on endian?
>
>
> What I'm really doing is looking into removing the heavy use of volatile.
>
>
>  - Jay
>
>
 		 	   		  

From jay.krell at cornell.edu  Tue Jun  1 19:16:46 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 1 Jun 2010 17:16:46 +0000
Subject: [M3devel] reducing use of volatile in backend?
Message-ID: <COL101-W17AA739AA2DE2050C6CCD0E6EF0@phx.gbl>


Tony, would we maybe be better off not using volatile everywhere but
selectively turning off optimizations in m3_post_options?
You know, using volatile probably disables more than necessary?
I'm experimenting with this.

?- Jay




 		 	   		  

From jay.krell at cornell.edu  Tue Jun  1 19:58:50 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 1 Jun 2010 17:58:50 +0000
Subject: [M3devel] optimizer doesn't do much?
Message-ID: <COL101-W32EFB0D6FFF6C0D451CC7FE6EF0@phx.gbl>


Here's a version from cm3cg with lots of optimizations turned on, a few turned off, *and* volatile generally removed:

??? xorl??? %eax, %eax
??? testq??? %rdi, %rdi
??? movq??? %rsi, %rdx
??? je??? L3
??? cmpq??? $-1, (%rdi)
??? movq??? %rdi, %rax
??? jne??? L3
??? movq??? 16(%rdi), %rax
??? movq??? %rax, -16(%rsp)
??? movq??? 8(%rdi), %rax
L3:
??? movq??? -16(%rsp), %r10
??? movq??? %rdx, %rdi
??? movq??? %rax, %r11
??? jmp??? *%r11

Much better!

?- Jay


----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Subject: optimizer doesn't do much?
> Date: Sun, 30 May 2010 18:11:26 +0000
>
>
> 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  Tue Jun  1 21:21:47 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 1 Jun 2010 19:21:47 +0000
Subject: [M3devel] unreachable code
Message-ID: <COL101-W43E6ACB5FD4C86FB00CA6FE6EF0@phx.gbl>


Here's nice stuff the compiler reports:

"../src/misc/stochastic/RandomImprovedMcGill.m3", line 63: warning: unreachable statement
"../src/misc/stochastic/RandomSubtractiveFibo2.m3", line 51: warning: unreachable statement

??? <* ASSERT Word.Size = 32 *>

Probably they just need to use Cstdint.uint32_t and mask sometimes..

?..Jay
 		 	   		  

From hosking at cs.purdue.edu  Tue Jun  1 23:05:30 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Tue, 1 Jun 2010 16:05:30 -0500
Subject: [M3devel] reducing use of volatile in backend?
In-Reply-To: <COL101-W17AA739AA2DE2050C6CCD0E6EF0@phx.gbl>
References: <COL101-W17AA739AA2DE2050C6CCD0E6EF0@phx.gbl>
Message-ID: <AA1F4490-A9C7-4F94-8E03-65A5E9031424@cs.purdue.edu>

We don't want to disable optimisations for types where it makes sense  
to have them. Better to smarten up typebased alias analysis instead so  
we can get rid of volatile properly.

Sent from my iPhone

On Jun 1, 2010, at 12:16 PM, Jay K <jay.krell at cornell.edu> wrote:

>
> Tony, would we maybe be better off not using volatile everywhere but
> selectively turning off optimizations in m3_post_options?
> You know, using volatile probably disables more than necessary?
> I'm experimenting with this.
>
>  - Jay
>
>
>
>
>


From jay.krell at cornell.edu  Tue Jun  1 23:55:31 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 1 Jun 2010 21:55:31 +0000
Subject: [M3devel] reducing use of volatile in backend?
In-Reply-To: <AA1F4490-A9C7-4F94-8E03-65A5E9031424@cs.purdue.edu>
References: <COL101-W17AA739AA2DE2050C6CCD0E6EF0@phx.gbl>,
	<AA1F4490-A9C7-4F94-8E03-65A5E9031424@cs.purdue.edu>
Message-ID: <COL101-W405F0F081CEA577B80A523E6EF0@phx.gbl>


I've had *a lot* of success here the past few hours.
 
 
There is an assert starting up mentor I need to look at, possibly out of data binaries.
  The one in socket.c assert(lossless_socklen || socklen == null || socklen < 1<<30.
 
 
Compiler seems to work.
  Lots of things do break it, so that is something.
 
 
Various gui apps startup.
  Some of the gui apps don't work, but nor did older copies I had -- fours, badbricks, and I think columns, wouldn't take any mouse clicks. I have to test older versions. Could be unrelated.
 
 
 
Here is what I have:
 
  The vast vast majority of optimizations can be enabled.
 
  Nearly all uses of volatile can be removed.
 
  Just a few optimizations "need" to be disabled.
 
In particular:
 I only have volatile remaining:
    on store after insert_mn (special case)
 
    floating point (huh? wierd)
     compile errors without this 
 
    in functions that call setjmp or vfork
      This is very reasonable, but we should try to limit it to not all the variables, only what are accessed after the second return (I'm not sure how that computes for vfork, but for setjmp it makes sense to me.
 
 
    on the load/store in loophole
      compile errors without this; perhaps redundant with the floating point check
 
 
    on load link, else it gets uninitialized warning 
 
 
 
Also I found a likely bug.
In functions that call setjmp/vfork, we volatize already seen parameters and locals, but we don't volatize not yet seen locals (in nested blocks) and temporaries. I fixed that.
 
  
 
 
 The optimizations I disabled, from memory:
 
 
  pre - partial redundancy elimination 
 
 
  fre - full redundancy elimination (these are related) 
    One or both of these causes the compiler to access violate in the optimizer, compiling libm3/Formatter.mc, but otherwise I think they compile m3core and libm3 entirely
 
 
  loop im (induction motion) - caused a compile error in Trestle 
 
  vrp - value range propagation
     This seems to be the biggest problem, no compile errors but "random" runtime malfunction, usually starting up cm3.
 
 
  insn_sched - wierd, caused a compile break
    but insn_sched_after_reload ok
 
 
 That's about it. All the ones with "alias" in them, only like two, I enabled, seemed ok.
  salias and strict_alias. I left strict alias till late in experimentation but really it seems ok.
 
 
I can compile the entire system, though I get lots of warnings about uninitialized variables.
I pass the backend the -Wuninitialized flag.
 
 
I test it out more -- the gui non-interaction, the mentor assert, and test other platforms.
But I think we'll have volatile mostly gone and just a small number of optimizations turned off fairly soon.
We can iterate more on the remaining optimizations.
 
 
Getting good typeinfo would be good so that gdb can debug.
And maybe so that other than stabs works.
 
 
 - Jay




----------------------------------------
> From: hosking at cs.purdue.edu
> To: jay.krell at cornell.edu
> Date: Tue, 1 Jun 2010 16:05:30 -0500
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] reducing use of volatile in backend?
>
> We don't want to disable optimisations for types where it makes sense
> to have them. Better to smarten up typebased alias analysis instead so
> we can get rid of volatile properly.
>
> Sent from my iPhone
>
> On Jun 1, 2010, at 12:16 PM, Jay K wrote:
>
>>
>> Tony, would we maybe be better off not using volatile everywhere but
>> selectively turning off optimizations in m3_post_options?
>> You know, using volatile probably disables more than necessary?
>> I'm experimenting with this.
>>
>> - Jay
>>
>>
>>
>>
>> 		 	   		  

From mika at async.async.caltech.edu  Wed Jun  2 05:52:26 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Tue, 01 Jun 2010 20:52:26 -0700
Subject: [M3devel] [M3commit] CVS Update: cm3
In-Reply-To: <COL101-W3678C92B3A9FA07AD57BF2E6D00@phx.gbl> 
References: <20100601124200.8E42B2474003@birch.elegosoft.com>,
	<E86D485E-C5D5-4B7A-8142-5E0BE31280DD@cs.purdue.edu>
	<COL101-W58EC381F7DE75AC44CFB57E6EF0@phx.gbl>,
	<5458A114-F000-4A90-9998-FD7DF63E06C0@cs.purdue.edu>
	<COL101-W3678C92B3A9FA07AD57BF2E6D00@phx.gbl>
Message-ID: <20100602035226.43C1F1A208F@async.async.caltech.edu>


Safety is important in that it allows you to limit the possible effects
of bugs.  Getting programs bug-free is of course a very difficult problem
no matter what you do.

But no I don't think warnings for uninitialized use of variables is 
something one should do in general in Modula-3.  The safety guarantees
lead to different idioms from in C---not so many compiler warnings
are required to get your code right.  And if you do screw up 
an uninitialized variable, the effect is going to be limited.
Unlike what happens in C, where if you screw up the initialization
of a pointer, for instance, all hell breaks loose.

Your example is contrived.  Usually the code looks like this

VAR
  x : T;
BEGIN
  IF cond1 THEN x := ... END; 
  ...
  IF cond2 THEN (* use x *) END
END

where the programmer knows that cond2 logically implies cond1.

I think the presence of VAR parameter passing makes these sorts of
warnings also less useful in Modula-3.   Is the following OK?

PROCEDURE InitializeIt(VAR a : T);
PROCEUDRE UseIt(VALUE a : T);

VAR x : T;
BEGIN
  InitializeIt(x);
  UseIt(x)
END

I would think your compiler can't prove that x is initialized.  Warning
or not?  I say no: this is actually very reasonable Modula-3 code.
But then do you want a warning for the IF?  It's logically the same.

There's a chapter in 
EWD's Discipline of Programming that deals with the problem in 
detail.  I think he winds up with six different "modes" for variables.

     Mika

Jay K writes:
>
>ok=2C so in C:
>=20
>int F()
>{
>  int i=3B
>  return i=3B
>}
>=20
>should warn or not?
>Prevailing wisdom is definitely.
>Main known exception is code to generate random numbers.
>  I believe this is how Debian broke key generation.
>=20
>=20
>Modula-3:
>=20
>=20
>PROCEDURE F(): INTEGER =3D=20
> VAR i: INTEGER=3B
>BEGIN
>  RETURN i=3B
>END F=3B
>=20
>=20
>Should warn or not?
>Since this identical to the C=2C prevailing wisdom is definitely.
>=20
>=20
>They are=2C I guess=2C "safe"=2C but most likely=2C incorrect.
>=20
>=20
>The compiler may have made "safety" guarantees=2C and they are significant=
>=2C
>but safe is far from correct=2C and however smart the compiler can be to lo=
>ok for correctness issues=2C is also nice.
>=20
>=20
>=20
>(Friend of mine conjectured something like: Safety guarantees have people d=
>eluded. Software will still have plenty of bugs and be plenty difficult to =
>get correct and require plenty of testing. Safety guarantees help=2C but th=
>ey are only a small step toward actual correctness.)
>=20
>=20
>=20
> - Jay
>
>
>----------------------------------------
>> Subject: Re: [M3commit] CVS Update: cm3
>> From: hosking at cs.purdue.edu
>> Date: Tue=2C 1 Jun 2010 20:04:00 -0400
>> CC: jkrell at elego.de=3B m3commit at elegosoft.com
>> To: jay.krell at cornell.edu
>>
>> Sure=2C an INTEGER is a valid value whatever the bits.
>>
>>
>> On 1 Jun 2010=2C at 17:44=2C Jay K wrote:
>>
>>>
>>> Start removing the rampant use of volatile in the backend and these warn=
>ings show up.
>>>
>>> Volatile quashes the uninitialized checks in the backend.
>>>
>>> Is it really ok for an INTEGER to be uninitialized? I realize it contain=
>s an "integer" value=2C as all bit patterns are.
>>>
>>> Some of these really do seem like bugs. Some do not.
>>> I'll try making fault_proc noreturn=2C which should remove some of them.
>>>
>>>
>>> - Jay
>>>
>>>
>>>
>>>
>>> ----------------------------------------
>>>> From: hosking at cs.purdue.edu
>>>> To: jkrell at elego.de
>>>> Date: Tue=2C 1 Jun 2010 16:29:20 -0500
>>>> CC: m3commit at elegosoft.com
>>>> Subject: Re: [M3commit] CVS Update: cm3
>>>>
>>>> This is bogus. The M3 compiler guarantees all variables are initialized=
>.
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On Jun 1=2C 2010=2C at 2:42 PM=2C jkrell at elego.de (Jay Krell) wrote:
>>>>
>>>>> CVSROOT: /usr/cvs
>>>>> Changes by: jkrell at birch. 10/06/01 14:42:00
>>>>>
>>>>> Modified files:
>>>>> cm3/m3-libs/m3core/src/convert/: Convert.m3
>>>>>
>>>>> Log message:
>>>>> initialize locals=3B I get warnings that some not quite all=2C are
>>>>> used uninitialized if I remove the volatile/sideeffects on every
>>>>> load/store in parse.c
>> 		 	   		  =


From jay.krell at cornell.edu  Wed Jun  2 06:50:28 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 2 Jun 2010 04:50:28 +0000
Subject: [M3devel] warning for uninitialized variables?
In-Reply-To: <20100602035226.43C1F1A208F@async.async.caltech.edu>
References: <20100601124200.8E42B2474003@birch.elegosoft.com>, ,
	<E86D485E-C5D5-4B7A-8142-5E0BE31280DD@cs.purdue.edu>,
	<COL101-W58EC381F7DE75AC44CFB57E6EF0@phx.gbl>, ,
	<5458A114-F000-4A90-9998-FD7DF63E06C0@cs.purdue.edu>,
	<COL101-W3678C92B3A9FA07AD57BF2E6D00@phx.gbl>,
	<20100602035226.43C1F1A208F@async.async.caltech.edu>
Message-ID: <COL101-W59770EAA64E52A966D79F3E6D00@phx.gbl>


Wow. You really surprise me Mika.


To warn on this kind of thing, to me, there is no question.


Limting the affects by virtue of being safe isn't much consolation.
The program can easily go down a "safe" but very incorrect path.


There are several forms.
In fact, sometimes the compiler says something "is" used uninitialized.
Sometimes it says "maybe".


In your example, generally, once the address is taken of a variable,
the compiler gives up. Esp. if that address is passed to a function it doesn't "see".


However compilers are getting better.
Windows headers are now annotated with "in" and "out", etc. with
a calculus behind them, not just informal human definitions.


So if you pass something by pointer to "in" you should a warning/error.
If it is "out", ok.


The annotations can even be checked, if you write to something that is "in"
you should get a warning/error.


There are many more warnings in the tree than I have yet looked at.
I've seen a few forms.
Some are because the compiler doesn't know that some functions don't return.
I'll see about improving that. Though I think there's a limit to how good I can manage,
unless we add a <* noreturn *> pragma.


One form is:
a: INTEGER
if cond
? a := 1;
...
if cond
? use a
?

When the compiler is really unsure, it doesn't bother saying anything.


If code is lucky, it gets one smart human to study it carefully when it is first written.
However all code is lucky to have a smart and generally getting smarter compiler
look at it repeatedly.
We shouldn't throw away this tool so rapidly, the gcc optimizer and its data flow analysis.


I grant that by initializing to 0, I haven't necessarily made the code correct either.
But at least it is now consistent.


Even better would be runtime checks that stop if a variable is read before written.


See also the rules in Java and C# that require the compiler to be able to prove
a variable is written before read. Possibly even verifiable at load time.


Other forms look related to going "through" a switch statement with no arms handling the value.
I think I can address that by marking fault_proc as noreturn.


One form apparently in cm3ide would use uninitialized data if presented with a malformed file.
Good software doesn't depend on the well formedness of its input.

There are many more warnings like this in the tree.


My inclination is at least to temporarily hardcode the gcc backend to always optimize,
and always produce these warnings. People can look over them maybe and decide.
Or they can look over my "fixes".


Or I guess if people really really really really prefer, we can always turn off the warnings
and let the code lie. I really think that is the wrong answer.


I have been burned too much by uninitialized locals in C.
I put " = { 0 }" after everything.
Again, that isn't necessarily "correct", but at least the incorrect paths are consistent.
If they don't work and I happen down them, they will guaranteeably not work.


Uninitialized values can be different run to run.
Repeatability and consistency are important.


I'm also nervous about us not taking a hard line on integer overflow.
Overflown math doesn't necessarily lead to array out of bounds soon or ever.
It too can lead to incorrect but safe behavior.


?- Jay


----------------------------------------
> To: jay.krell at cornell.edu
> Date: Tue, 1 Jun 2010 20:52:26 -0700
> From: mika at async.async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] [M3commit] CVS Update: cm3
>
>
> Safety is important in that it allows you to limit the possible effects
> of bugs. Getting programs bug-free is of course a very difficult problem
> no matter what you do.
>
> But no I don't think warnings for uninitialized use of variables is
> something one should do in general in Modula-3. The safety guarantees
> lead to different idioms from in C---not so many compiler warnings
> are required to get your code right. And if you do screw up
> an uninitialized variable, the effect is going to be limited.
> Unlike what happens in C, where if you screw up the initialization
> of a pointer, for instance, all hell breaks loose.
>
> Your example is contrived. Usually the code looks like this
>
> VAR
> x : T;
> BEGIN
> IF cond1 THEN x := ... END;
> ...
> IF cond2 THEN (* use x *) END
> END
>
> where the programmer knows that cond2 logically implies cond1.
>
> I think the presence of VAR parameter passing makes these sorts of
> warnings also less useful in Modula-3. Is the following OK?
>
> PROCEDURE InitializeIt(VAR a : T);
> PROCEUDRE UseIt(VALUE a : T);
>
> VAR x : T;
> BEGIN
> InitializeIt(x);
> UseIt(x)
> END
>
> I would think your compiler can't prove that x is initialized. Warning
> or not? I say no: this is actually very reasonable Modula-3 code.
> But then do you want a warning for the IF? It's logically the same.
>
> There's a chapter in
> EWD's Discipline of Programming that deals with the problem in
> detail. I think he winds up with six different "modes" for variables.
>
> Mika
>
> Jay K writes:
>>
>>ok=2C so in C:
>>=20
>>int F()
>>{
>> int i=3B
>> return i=3B
>>}
>>=20
>>should warn or not?
>>Prevailing wisdom is definitely.
>>Main known exception is code to generate random numbers.
>> I believe this is how Debian broke key generation.
>>=20
>>=20
>>Modula-3:
>>=20
>>=20
>>PROCEDURE F(): INTEGER =3D=20
>> VAR i: INTEGER=3B
>>BEGIN
>> RETURN i=3B
>>END F=3B
>>=20
>>=20
>>Should warn or not?
>>Since this identical to the C=2C prevailing wisdom is definitely.
>>=20
>>=20
>>They are=2C I guess=2C "safe"=2C but most likely=2C incorrect.
>>=20
>>=20
>>The compiler may have made "safety" guarantees=2C and they are significant=
>>=2C
>>but safe is far from correct=2C and however smart the compiler can be to lo=
>>ok for correctness issues=2C is also nice.
>>=20
>>=20
>>=20
>>(Friend of mine conjectured something like: Safety guarantees have people d=
>>eluded. Software will still have plenty of bugs and be plenty difficult to =
>>get correct and require plenty of testing. Safety guarantees help=2C but th=
>>ey are only a small step toward actual correctness.)
>>=20
>>=20
>>=20
>> - Jay
>>
>>
>>----------------------------------------
>>> Subject: Re: [M3commit] CVS Update: cm3
>>> From: hosking at cs.purdue.edu
>>> Date: Tue=2C 1 Jun 2010 20:04:00 -0400
>>> CC: jkrell at elego.de=3B m3commit at elegosoft.com
>>> To: jay.krell at cornell.edu
>>>
>>> Sure=2C an INTEGER is a valid value whatever the bits.
>>>
>>>
>>> On 1 Jun 2010=2C at 17:44=2C Jay K wrote:
>>>
>>>>
>>>> Start removing the rampant use of volatile in the backend and these warn=
>>ings show up.
>>>>
>>>> Volatile quashes the uninitialized checks in the backend.
>>>>
>>>> Is it really ok for an INTEGER to be uninitialized? I realize it contain=
>>s an "integer" value=2C as all bit patterns are.
>>>>
>>>> Some of these really do seem like bugs. Some do not.
>>>> I'll try making fault_proc noreturn=2C which should remove some of them.
>>>>
>>>>
>>>> - Jay
>>>>
>>>>
>>>>
>>>>
>>>> ----------------------------------------
>>>>> From: hosking at cs.purdue.edu
>>>>> To: jkrell at elego.de
>>>>> Date: Tue=2C 1 Jun 2010 16:29:20 -0500
>>>>> CC: m3commit at elegosoft.com
>>>>> Subject: Re: [M3commit] CVS Update: cm3
>>>>>
>>>>> This is bogus. The M3 compiler guarantees all variables are initialized=
>>.
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>> On Jun 1=2C 2010=2C at 2:42 PM=2C jkrell at elego.de (Jay Krell) wrote:
>>>>>
>>>>>> CVSROOT: /usr/cvs
>>>>>> Changes by: jkrell at birch. 10/06/01 14:42:00
>>>>>>
>>>>>> Modified files:
>>>>>> cm3/m3-libs/m3core/src/convert/: Convert.m3
>>>>>>
>>>>>> Log message:
>>>>>> initialize locals=3B I get warnings that some not quite all=2C are
>>>>>> used uninitialized if I remove the volatile/sideeffects on every
>>>>>> load/store in parse.c
>>> =
 		 	   		  

From jay.krell at cornell.edu  Wed Jun  2 09:41:33 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 2 Jun 2010 07:41:33 +0000
Subject: [M3devel] ADR is *too* unsafe..
Message-ID: <COL101-W617B9602E6CAA0BBE5BE25E6D00@phx.gbl>


(*
Wow, ADR generates a plain ADDRESS, not an untraced ref to a specific type?
Doesn't this seem wrong? Doesn't unsafe code deserve a little better, say,
? to be at least as typesafe as C?
http://www.cs.purdue.edu/homes/hosking/m3/reference/unsafe.html

This is why 64bit m3-comm/tcp/src/TCP.m3 breaks randomly
on some platforms on an assertion failure in C. And the
compiler isn't going to help me find these type mismatches? Ugh.

This seems wrong. :(

I guess I should really really use VAR then.
*)


UNSAFE MODULE Main;
IMPORT Ctypes, Cstddef;


PROCEDURE F1(a:UNTRACED REF Ctypes.int) =
BEGIN
? F2(a); (* error, expected *)
END F1;


PROCEDURE F2(a:UNTRACED REF Cstddef.size_t) =
BEGIN
? F1(a); (* error, expected *)
END F2;


VAR c:Ctypes.int;
??? d:Cstddef.size_t;

??? 
BEGIN
? F1(ADR(c)); (* ok *)
? F1(ADR(d)); (* error expected but no *)
? F2(ADR(c)); (* error expected but no *)
? F2(ADR(d)); (* ok *)
END Main.



?- Jay
 		 	   		  

From mika at async.async.caltech.edu  Wed Jun  2 14:44:22 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Wed, 02 Jun 2010 05:44:22 -0700
Subject: [M3devel] warning for uninitialized variables?
In-Reply-To: <COL101-W59770EAA64E52A966D79F3E6D00@phx.gbl> 
References: <20100601124200.8E42B2474003@birch.elegosoft.com>, ,
	<E86D485E-C5D5-4B7A-8142-5E0BE31280DD@cs.purdue.edu>,
	<COL101-W58EC381F7DE75AC44CFB57E6EF0@phx.gbl>, ,
	<5458A114-F000-4A90-9998-FD7DF63E06C0@cs.purdue.edu>,
	<COL101-W3678C92B3A9FA07AD57BF2E6D00@phx.gbl>,
	<20100602035226.43C1F1A208F@async.async.caltech.edu>
	<COL101-W59770EAA64E52A966D79F3E6D00@phx.gbl>
Message-ID: <20100602124422.11C6D1A209A@async.async.caltech.edu>

Jay K writes:
>
>Wow. You really surprise me Mika.
>
>
>To warn on this kind of thing=2C to me=2C there is no question.
>
>
>Limting the affects by virtue of being safe isn't much consolation.
>The program can easily go down a "safe" but very incorrect path.

It is, though!  Do you always know what value to initialize the
variables to?  If not, you're just picking some value to shut up
the compiler, and now your code no longer expresses---to a human
reader---that x is uninitialized.

Remember, code is mainly written for humans!  Computers don't care
about fancy structuring, declarations, etc.  When you write a program,
you write it to be read by a human.  The fact that a variable is
uninitialized is a part of the design of the program.

It's an unfortunate fact that our languages don't have all the 
mechanisms necessary to deal properly with uninitialized variables.
Retrofitting mechanisms to something that just isn't expressive
enough to solve the problem I really don't think is the way to go.

EWD's book chapter... read it.  "An essay on the scope of variables"
I think it is called.


>
>
>There are several forms.
>In fact=2C sometimes the compiler says something "is" used uninitialized.
>Sometimes it says "maybe".
>
>
>In your example=2C generally=2C once the address is taken of a variable=2C
>the compiler gives up. Esp. if that address is passed to a function it does=
>n't "see".

As long as this doesn't raise warnings I can live with your warnings...

...
>
>
>There are many more warnings in the tree than I have yet looked at.
>I've seen a few forms.
>Some are because the compiler doesn't know that some functions don't return=
>.
>I'll see about improving that. Though I think there's a limit to how good I=
> can manage=2C
>unless we add a <* noreturn *> pragma.

adding <*ASSERT FALSE*> in the right places might fix these warnings.

...
>
>
>I grant that by initializing to 0=2C I haven't necessarily made the code co=
>rrect either.
>But at least it is now consistent.
>
>
>Even better would be runtime checks that stop if a variable is read before =
>written.

Which you have just defeated with your initialization!

I know that my Modula code will outlive its current compiler.  Probably
by a long time.  Once you add the initialization you're talking about,
you can't go back.  It no longer expresses the useful property you're
trying to check.  When the new compiler comes along with its runtime
check, it will miss that my variables are actually uninitialized.

>
>
>See also the rules in Java and C# that require the compiler to be able to p=
>rove
>a variable is written before read. Possibly even verifiable at load time.

I *hate* this.  See above.  

What's next?  The compiler refuses to compile loops that it can't
prove will terminate???  Hogwash!

>
>
>Other forms look related to going "through" a switch statement with no arms=
> handling the value.
>I think I can address that by marking fault_proc as noreturn.
>
>
>One form apparently in cm3ide would use uninitialized data if presented wit=
>h a malformed file.
>Good software doesn't depend on the well formedness of its input.
>
>There are many more warnings like this in the tree.
>
>
>My inclination is at least to temporarily hardcode the gcc backend to alway=
>s optimize=2C
>and always produce these warnings. People can look over them maybe and deci=
>de.
>Or they can look over my "fixes".
>
>
>Or I guess if people really really really really prefer=2C we can always tu=
>rn off the warnings
>and let the code lie. I really think that is the wrong answer.
>
>
>I have been burned too much by uninitialized locals in C.
>I put " =3D { 0 }" after everything.
>Again=2C that isn't necessarily "correct"=2C but at least the incorrect pat=
>hs are consistent.
>If they don't work and I happen down them=2C they will guaranteeably not wo=
>rk.

No they will just consistently not work.  Not "guaranteeably".  You have
to initialize them to some specific value for that to be the case.
Using "0" often will just give you the wrong answer!  

>
>
>Uninitialized values can be different run to run.
>Repeatability and consistency are important.

Not forcing the programmer to obscure the meaning of the code I think
is more important.

>
>
>I'm also nervous about us not taking a hard line on integer overflow.
>Overflown math doesn't necessarily lead to array out of bounds soon or ever=
>.
>It too can lead to incorrect but safe behavior.

Similar situation is it not?  You don't generate a compiler warning
for math that "might overflow".  

I think we can all agree that error on integer overflow, error on
use of uninitialized variable, at runtime, would both be good things?

     Mika

>
>
>=A0- Jay
>
>
>----------------------------------------
>> To: jay.krell at cornell.edu
>> Date: Tue=2C 1 Jun 2010 20:52:26 -0700
>> From: mika at async.async.caltech.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] [M3commit] CVS Update: cm3
>>
>>
>> Safety is important in that it allows you to limit the possible effects
>> of bugs. Getting programs bug-free is of course a very difficult problem
>> no matter what you do.
>>
>> But no I don't think warnings for uninitialized use of variables is
>> something one should do in general in Modula-3. The safety guarantees
>> lead to different idioms from in C---not so many compiler warnings
>> are required to get your code right. And if you do screw up
>> an uninitialized variable=2C the effect is going to be limited.
>> Unlike what happens in C=2C where if you screw up the initialization
>> of a pointer=2C for instance=2C all hell breaks loose.
>>
>> Your example is contrived. Usually the code looks like this
>>
>> VAR
>> x : T=3B
>> BEGIN
>> IF cond1 THEN x :=3D ... END=3B
>> ...
>> IF cond2 THEN (* use x *) END
>> END
>>
>> where the programmer knows that cond2 logically implies cond1.
>>
>> I think the presence of VAR parameter passing makes these sorts of
>> warnings also less useful in Modula-3. Is the following OK?
>>
>> PROCEDURE InitializeIt(VAR a : T)=3B
>> PROCEUDRE UseIt(VALUE a : T)=3B
>>
>> VAR x : T=3B
>> BEGIN
>> InitializeIt(x)=3B
>> UseIt(x)
>> END
>>
>> I would think your compiler can't prove that x is initialized. Warning
>> or not? I say no: this is actually very reasonable Modula-3 code.
>> But then do you want a warning for the IF? It's logically the same.
>>
>> There's a chapter in
>> EWD's Discipline of Programming that deals with the problem in
>> detail. I think he winds up with six different "modes" for variables.
>>
>> Mika
>>
>> Jay K writes:
>>>
>>>ok=3D2C so in C:
>>>=3D20
>>>int F()
>>>{
>>> int i=3D3B
>>> return i=3D3B
>>>}
>>>=3D20
>>>should warn or not?
>>>Prevailing wisdom is definitely.
>>>Main known exception is code to generate random numbers.
>>> I believe this is how Debian broke key generation.
>>>=3D20
>>>=3D20
>>>Modula-3:
>>>=3D20
>>>=3D20
>>>PROCEDURE F(): INTEGER =3D3D=3D20
>>> VAR i: INTEGER=3D3B
>>>BEGIN
>>> RETURN i=3D3B
>>>END F=3D3B
>>>=3D20
>>>=3D20
>>>Should warn or not?
>>>Since this identical to the C=3D2C prevailing wisdom is definitely.
>>>=3D20
>>>=3D20
>>>They are=3D2C I guess=3D2C "safe"=3D2C but most likely=3D2C incorrect.
>>>=3D20
>>>=3D20
>>>The compiler may have made "safety" guarantees=3D2C and they are signific=
>ant=3D
>>>=3D2C
>>>but safe is far from correct=3D2C and however smart the compiler can be t=
>o lo=3D
>>>ok for correctness issues=3D2C is also nice.
>>>=3D20
>>>=3D20
>>>=3D20
>>>(Friend of mine conjectured something like: Safety guarantees have people=
> d=3D
>>>eluded. Software will still have plenty of bugs and be plenty difficult t=
>o =3D
>>>get correct and require plenty of testing. Safety guarantees help=3D2C bu=
>t th=3D
>>>ey are only a small step toward actual correctness.)
>>>=3D20
>>>=3D20
>>>=3D20
>>> - Jay
>>>
>>>
>>>----------------------------------------
>>>> Subject: Re: [M3commit] CVS Update: cm3
>>>> From: hosking at cs.purdue.edu
>>>> Date: Tue=3D2C 1 Jun 2010 20:04:00 -0400
>>>> CC: jkrell at elego.de=3D3B m3commit at elegosoft.com
>>>> To: jay.krell at cornell.edu
>>>>
>>>> Sure=3D2C an INTEGER is a valid value whatever the bits.
>>>>
>>>>
>>>> On 1 Jun 2010=3D2C at 17:44=3D2C Jay K wrote:
>>>>
>>>>>
>>>>> Start removing the rampant use of volatile in the backend and these wa=
>rn=3D
>>>ings show up.
>>>>>
>>>>> Volatile quashes the uninitialized checks in the backend.
>>>>>
>>>>> Is it really ok for an INTEGER to be uninitialized? I realize it conta=
>in=3D
>>>s an "integer" value=3D2C as all bit patterns are.
>>>>>
>>>>> Some of these really do seem like bugs. Some do not.
>>>>> I'll try making fault_proc noreturn=3D2C which should remove some of t=
>hem.
>>>>>
>>>>>
>>>>> - Jay
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ----------------------------------------
>>>>>> From: hosking at cs.purdue.edu
>>>>>> To: jkrell at elego.de
>>>>>> Date: Tue=3D2C 1 Jun 2010 16:29:20 -0500
>>>>>> CC: m3commit at elegosoft.com
>>>>>> Subject: Re: [M3commit] CVS Update: cm3
>>>>>>
>>>>>> This is bogus. The M3 compiler guarantees all variables are initializ=
>ed=3D
>>>.
>>>>>>
>>>>>> Sent from my iPhone
>>>>>>
>>>>>> On Jun 1=3D2C 2010=3D2C at 2:42 PM=3D2C jkrell at elego.de (Jay Krell) w=
>rote:
>>>>>>
>>>>>>> CVSROOT: /usr/cvs
>>>>>>> Changes by: jkrell at birch. 10/06/01 14:42:00
>>>>>>>
>>>>>>> Modified files:
>>>>>>> cm3/m3-libs/m3core/src/convert/: Convert.m3
>>>>>>>
>>>>>>> Log message:
>>>>>>> initialize locals=3D3B I get warnings that some not quite all=3D2C a=
>re
>>>>>>> used uninitialized if I remove the volatile/sideeffects on every
>>>>>>> load/store in parse.c
>>>> =3D
> 		 	   		  =



From jay.krell at cornell.edu  Wed Jun  2 15:01:38 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 2 Jun 2010 13:01:38 +0000
Subject: [M3devel] SOLgnu/SOLsun -O1/-O2/-O3
Message-ID: <COL101-W26B2AF5D865D1A694793DAE6D00@phx.gbl>


Anyone recall if SOLgnu/sun work with any optimization?
? You know -- the platforms that have a stack walker and don't use setjmp.
I tried leaving them having all loads/stores be volatile, except handling still doesn't work -- cm3 gets an unhandled exception instead of saying cm3.cfg not found.
I'll have to test with an old clean version.
Could be I'm missing something, or maybe the m3cg_pop change broke them.


?- Jay

 		 	   		  

From jay.krell at cornell.edu  Wed Jun  2 14:59:45 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 2 Jun 2010 12:59:45 +0000
Subject: [M3devel] warning for uninitialized variables?
In-Reply-To: <20100602124422.11C6D1A209A@async.async.caltech.edu>
References: <20100601124200.8E42B2474003@birch.elegosoft.com>, ,
	<E86D485E-C5D5-4B7A-8142-5E0BE31280DD@cs.purdue.edu>,
	<COL101-W58EC381F7DE75AC44CFB57E6EF0@phx.gbl>, ,
	<5458A114-F000-4A90-9998-FD7DF63E06C0@cs.purdue.edu>,
	<COL101-W3678C92B3A9FA07AD57BF2E6D00@phx.gbl>,
	<20100602035226.43C1F1A208F@async.async.caltech.edu>
	<COL101-W59770EAA64E52A966D79F3E6D00@phx.gbl>,
	<20100602124422.11C6D1A209A@async.async.caltech.edu>
Message-ID: <COL101-W5343011FD0FA7BCC8C42AEE6D00@phx.gbl>


I grant that an immediate runtime error upon reading an unwritten value is ideal.
But absent that possibility, I want something consistent.
Heck, here's a crazy idea: reserve the current FIRST(INTEGER) as "invalid", initialize locals to it, any read (or generation/write) of that value trigger a runtime error.
CARDINAL could work this way more easily since it has many values to spare.


?- Jay

----------------------------------------
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] warning for uninitialized variables?
> Date: Wed, 2 Jun 2010 05:44:22 -0700
> From: mika at async.async.caltech.edu
>
> Jay K writes:
>>
>>Wow. You really surprise me Mika.
>>
>>
>>To warn on this kind of thing=2C to me=2C there is no question.
>>
>>
>>Limting the affects by virtue of being safe isn't much consolation.
>>The program can easily go down a "safe" but very incorrect path.
>
> It is, though! Do you always know what value to initialize the
> variables to? If not, you're just picking some value to shut up
> the compiler, and now your code no longer expresses---to a human
> reader---that x is uninitialized.
>
> Remember, code is mainly written for humans! Computers don't care
> about fancy structuring, declarations, etc. When you write a program,
> you write it to be read by a human. The fact that a variable is
> uninitialized is a part of the design of the program.
>
> It's an unfortunate fact that our languages don't have all the
> mechanisms necessary to deal properly with uninitialized variables.
> Retrofitting mechanisms to something that just isn't expressive
> enough to solve the problem I really don't think is the way to go.
>
> EWD's book chapter... read it. "An essay on the scope of variables"
> I think it is called.
>
>
>>
>>
>>There are several forms.
>>In fact=2C sometimes the compiler says something "is" used uninitialized.
>>Sometimes it says "maybe".
>>
>>
>>In your example=2C generally=2C once the address is taken of a variable=2C
>>the compiler gives up. Esp. if that address is passed to a function it does=
>>n't "see".
>
> As long as this doesn't raise warnings I can live with your warnings...
>
> ...
>>
>>
>>There are many more warnings in the tree than I have yet looked at.
>>I've seen a few forms.
>>Some are because the compiler doesn't know that some functions don't return=
>>.
>>I'll see about improving that. Though I think there's a limit to how good I=
>> can manage=2C
>>unless we add a <* noreturn *> pragma.
>
> adding <*ASSERT FALSE*> in the right places might fix these warnings.
>
> ...
>>
>>
>>I grant that by initializing to 0=2C I haven't necessarily made the code co=
>>rrect either.
>>But at least it is now consistent.
>>
>>
>>Even better would be runtime checks that stop if a variable is read before =
>>written.
>
> Which you have just defeated with your initialization!
>
> I know that my Modula code will outlive its current compiler. Probably
> by a long time. Once you add the initialization you're talking about,
> you can't go back. It no longer expresses the useful property you're
> trying to check. When the new compiler comes along with its runtime
> check, it will miss that my variables are actually uninitialized.
>
>>
>>
>>See also the rules in Java and C# that require the compiler to be able to p=
>>rove
>>a variable is written before read. Possibly even verifiable at load time.
>
> I *hate* this. See above.
>
> What's next? The compiler refuses to compile loops that it can't
> prove will terminate??? Hogwash!
>
>>
>>
>>Other forms look related to going "through" a switch statement with no arms=
>> handling the value.
>>I think I can address that by marking fault_proc as noreturn.
>>
>>
>>One form apparently in cm3ide would use uninitialized data if presented wit=
>>h a malformed file.
>>Good software doesn't depend on the well formedness of its input.
>>
>>There are many more warnings like this in the tree.
>>
>>
>>My inclination is at least to temporarily hardcode the gcc backend to alway=
>>s optimize=2C
>>and always produce these warnings. People can look over them maybe and deci=
>>de.
>>Or they can look over my "fixes".
>>
>>
>>Or I guess if people really really really really prefer=2C we can always tu=
>>rn off the warnings
>>and let the code lie. I really think that is the wrong answer.
>>
>>
>>I have been burned too much by uninitialized locals in C.
>>I put " =3D { 0 }" after everything.
>>Again=2C that isn't necessarily "correct"=2C but at least the incorrect pat=
>>hs are consistent.
>>If they don't work and I happen down them=2C they will guaranteeably not wo=
>>rk.
>
> No they will just consistently not work. Not "guaranteeably". You have
> to initialize them to some specific value for that to be the case.
> Using "0" often will just give you the wrong answer!
>
>>
>>
>>Uninitialized values can be different run to run.
>>Repeatability and consistency are important.
>
> Not forcing the programmer to obscure the meaning of the code I think
> is more important.
>
>>
>>
>>I'm also nervous about us not taking a hard line on integer overflow.
>>Overflown math doesn't necessarily lead to array out of bounds soon or ever=
>>.
>>It too can lead to incorrect but safe behavior.
>
> Similar situation is it not? You don't generate a compiler warning
> for math that "might overflow".
>
> I think we can all agree that error on integer overflow, error on
> use of uninitialized variable, at runtime, would both be good things?
>
> Mika
>
>>
>>
>>=A0- Jay
>>
>>
>>----------------------------------------
>>> To: jay.krell at cornell.edu
>>> Date: Tue=2C 1 Jun 2010 20:52:26 -0700
>>> From: mika at async.async.caltech.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] [M3commit] CVS Update: cm3
>>>
>>>
>>> Safety is important in that it allows you to limit the possible effects
>>> of bugs. Getting programs bug-free is of course a very difficult problem
>>> no matter what you do.
>>>
>>> But no I don't think warnings for uninitialized use of variables is
>>> something one should do in general in Modula-3. The safety guarantees
>>> lead to different idioms from in C---not so many compiler warnings
>>> are required to get your code right. And if you do screw up
>>> an uninitialized variable=2C the effect is going to be limited.
>>> Unlike what happens in C=2C where if you screw up the initialization
>>> of a pointer=2C for instance=2C all hell breaks loose.
>>>
>>> Your example is contrived. Usually the code looks like this
>>>
>>> VAR
>>> x : T=3B
>>> BEGIN
>>> IF cond1 THEN x :=3D ... END=3B
>>> ...
>>> IF cond2 THEN (* use x *) END
>>> END
>>>
>>> where the programmer knows that cond2 logically implies cond1.
>>>
>>> I think the presence of VAR parameter passing makes these sorts of
>>> warnings also less useful in Modula-3. Is the following OK?
>>>
>>> PROCEDURE InitializeIt(VAR a : T)=3B
>>> PROCEUDRE UseIt(VALUE a : T)=3B
>>>
>>> VAR x : T=3B
>>> BEGIN
>>> InitializeIt(x)=3B
>>> UseIt(x)
>>> END
>>>
>>> I would think your compiler can't prove that x is initialized. Warning
>>> or not? I say no: this is actually very reasonable Modula-3 code.
>>> But then do you want a warning for the IF? It's logically the same.
>>>
>>> There's a chapter in
>>> EWD's Discipline of Programming that deals with the problem in
>>> detail. I think he winds up with six different "modes" for variables.
>>>
>>> Mika
>>>
>>> Jay K writes:
>>>>
>>>>ok=3D2C so in C:
>>>>=3D20
>>>>int F()
>>>>{
>>>> int i=3D3B
>>>> return i=3D3B
>>>>}
>>>>=3D20
>>>>should warn or not?
>>>>Prevailing wisdom is definitely.
>>>>Main known exception is code to generate random numbers.
>>>> I believe this is how Debian broke key generation.
>>>>=3D20
>>>>=3D20
>>>>Modula-3:
>>>>=3D20
>>>>=3D20
>>>>PROCEDURE F(): INTEGER =3D3D=3D20
>>>> VAR i: INTEGER=3D3B
>>>>BEGIN
>>>> RETURN i=3D3B
>>>>END F=3D3B
>>>>=3D20
>>>>=3D20
>>>>Should warn or not?
>>>>Since this identical to the C=3D2C prevailing wisdom is definitely.
>>>>=3D20
>>>>=3D20
>>>>They are=3D2C I guess=3D2C "safe"=3D2C but most likely=3D2C incorrect.
>>>>=3D20
>>>>=3D20
>>>>The compiler may have made "safety" guarantees=3D2C and they are signific=
>>ant=3D
>>>>=3D2C
>>>>but safe is far from correct=3D2C and however smart the compiler can be t=
>>o lo=3D
>>>>ok for correctness issues=3D2C is also nice.
>>>>=3D20
>>>>=3D20
>>>>=3D20
>>>>(Friend of mine conjectured something like: Safety guarantees have people=
>> d=3D
>>>>eluded. Software will still have plenty of bugs and be plenty difficult t=
>>o =3D
>>>>get correct and require plenty of testing. Safety guarantees help=3D2C bu=
>>t th=3D
>>>>ey are only a small step toward actual correctness.)
>>>>=3D20
>>>>=3D20
>>>>=3D20
>>>> - Jay
>>>>
>>>>
>>>>----------------------------------------
>>>>> Subject: Re: [M3commit] CVS Update: cm3
>>>>> From: hosking at cs.purdue.edu
>>>>> Date: Tue=3D2C 1 Jun 2010 20:04:00 -0400
>>>>> CC: jkrell at elego.de=3D3B m3commit at elegosoft.com
>>>>> To: jay.krell at cornell.edu
>>>>>
>>>>> Sure=3D2C an INTEGER is a valid value whatever the bits.
>>>>>
>>>>>
>>>>> On 1 Jun 2010=3D2C at 17:44=3D2C Jay K wrote:
>>>>>
>>>>>>
>>>>>> Start removing the rampant use of volatile in the backend and these wa=
>>rn=3D
>>>>ings show up.
>>>>>>
>>>>>> Volatile quashes the uninitialized checks in the backend.
>>>>>>
>>>>>> Is it really ok for an INTEGER to be uninitialized? I realize it conta=
>>in=3D
>>>>s an "integer" value=3D2C as all bit patterns are.
>>>>>>
>>>>>> Some of these really do seem like bugs. Some do not.
>>>>>> I'll try making fault_proc noreturn=3D2C which should remove some of t=
>>hem.
>>>>>>
>>>>>>
>>>>>> - Jay
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ----------------------------------------
>>>>>>> From: hosking at cs.purdue.edu
>>>>>>> To: jkrell at elego.de
>>>>>>> Date: Tue=3D2C 1 Jun 2010 16:29:20 -0500
>>>>>>> CC: m3commit at elegosoft.com
>>>>>>> Subject: Re: [M3commit] CVS Update: cm3
>>>>>>>
>>>>>>> This is bogus. The M3 compiler guarantees all variables are initializ=
>>ed=3D
>>>>.
>>>>>>>
>>>>>>> Sent from my iPhone
>>>>>>>
>>>>>>> On Jun 1=3D2C 2010=3D2C at 2:42 PM=3D2C jkrell at elego.de (Jay Krell) w=
>>rote:
>>>>>>>
>>>>>>>> CVSROOT: /usr/cvs
>>>>>>>> Changes by: jkrell at birch. 10/06/01 14:42:00
>>>>>>>>
>>>>>>>> Modified files:
>>>>>>>> cm3/m3-libs/m3core/src/convert/: Convert.m3
>>>>>>>>
>>>>>>>> Log message:
>>>>>>>> initialize locals=3D3B I get warnings that some not quite all=3D2C a=
>>re
>>>>>>>> used uninitialized if I remove the volatile/sideeffects on every
>>>>>>>> load/store in parse.c
>>>>> =3D
>> =
>
 		 	   		  

From hosking at cs.purdue.edu  Wed Jun  2 16:01:09 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 2 Jun 2010 10:01:09 -0400
Subject: [M3devel] ADR is *too* unsafe..
In-Reply-To: <COL101-W617B9602E6CAA0BBE5BE25E6D00@phx.gbl>
References: <COL101-W617B9602E6CAA0BBE5BE25E6D00@phx.gbl>
Message-ID: <A8CEEB02-D279-4C90-B8D3-5D163619C748@cs.purdue.edu>

Why does the compiler break?
Yes, VAR is *much* safer.

On 2 Jun 2010, at 03:41, Jay K wrote:

> 
> (*
> Wow, ADR generates a plain ADDRESS, not an untraced ref to a specific type?
> Doesn't this seem wrong? Doesn't unsafe code deserve a little better, say,
>   to be at least as typesafe as C?
> http://www.cs.purdue.edu/homes/hosking/m3/reference/unsafe.html
> 
> This is why 64bit m3-comm/tcp/src/TCP.m3 breaks randomly
> on some platforms on an assertion failure in C. And the
> compiler isn't going to help me find these type mismatches? Ugh.
> 
> This seems wrong. :(
> 
> I guess I should really really use VAR then.
> *)
> 
> 
> UNSAFE MODULE Main;
> IMPORT Ctypes, Cstddef;
> 
> 
> PROCEDURE F1(a:UNTRACED REF Ctypes.int) =
> BEGIN
>   F2(a); (* error, expected *)
> END F1;
> 
> 
> PROCEDURE F2(a:UNTRACED REF Cstddef.size_t) =
> BEGIN
>   F1(a); (* error, expected *)
> END F2;
> 
> 
> VAR c:Ctypes.int;
>     d:Cstddef.size_t;
> 
>     
> BEGIN
>   F1(ADR(c)); (* ok *)
>   F1(ADR(d)); (* error expected but no *)
>   F2(ADR(c)); (* error expected but no *)
>   F2(ADR(d)); (* ok *)
> END Main.
> 
> 
> 
>  - Jay
> 		 	   		  



From jay.krell at cornell.edu  Wed Jun  2 16:07:02 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 2 Jun 2010 14:07:02 +0000
Subject: [M3devel] ADR is *too* unsafe..
In-Reply-To: <A8CEEB02-D279-4C90-B8D3-5D163619C748@cs.purdue.edu>
References: <COL101-W617B9602E6CAA0BBE5BE25E6D00@phx.gbl>,
	<A8CEEB02-D279-4C90-B8D3-5D163619C748@cs.purdue.edu>
Message-ID: <COL101-W444318DF7FE046C2AE542AE6D00@phx.gbl>


The compiler doesn't break. Mentor does, networking stuff. I fixed it. But I would have
expected the compiler to have told me about it.
It is unfortunate. ADR should be *slightly* safer.
Maybe we can get a warning for this? passing ADR(foo) to untraced ref bar?
It seems...quite unfortunate that the language is defined this way..

?- Jay


----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Wed, 2 Jun 2010 10:01:09 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] ADR is *too* unsafe..
>
> Why does the compiler break?
> Yes, VAR is *much* safer.
>
> On 2 Jun 2010, at 03:41, Jay K wrote:
>
>>
>> (*
>> Wow, ADR generates a plain ADDRESS, not an untraced ref to a specific type?
>> Doesn't this seem wrong? Doesn't unsafe code deserve a little better, say,
>> to be at least as typesafe as C?
>> http://www.cs.purdue.edu/homes/hosking/m3/reference/unsafe.html
>>
>> This is why 64bit m3-comm/tcp/src/TCP.m3 breaks randomly
>> on some platforms on an assertion failure in C. And the
>> compiler isn't going to help me find these type mismatches? Ugh.
>>
>> This seems wrong. :(
>>
>> I guess I should really really use VAR then.
>> *)
>>
>>
>> UNSAFE MODULE Main;
>> IMPORT Ctypes, Cstddef;
>>
>>
>> PROCEDURE F1(a:UNTRACED REF Ctypes.int) =
>> BEGIN
>> F2(a); (* error, expected *)
>> END F1;
>>
>>
>> PROCEDURE F2(a:UNTRACED REF Cstddef.size_t) =
>> BEGIN
>> F1(a); (* error, expected *)
>> END F2;
>>
>>
>> VAR c:Ctypes.int;
>> d:Cstddef.size_t;
>>
>>
>> BEGIN
>> F1(ADR(c)); (* ok *)
>> F1(ADR(d)); (* error expected but no *)
>> F2(ADR(c)); (* error expected but no *)
>> F2(ADR(d)); (* ok *)
>> END Main.
>>
>>
>>
>> - Jay
>>
>
 		 	   		  

From jay.krell at cornell.edu  Wed Jun  2 16:07:35 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 2 Jun 2010 14:07:35 +0000
Subject: [M3devel] SOLgnu/SOLsun -O1/-O2/-O3
Message-ID: <COL101-W16BB57F49DB4CD5964A0A1E6D00@phx.gbl>


It looks like -O2 does work.
I need to keep digging.

?- Jay


----------------------------------------
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu; m3devel at elegosoft.com
> Subject: SOLgnu/SOLsun -O1/-O2/-O3
> Date: Wed, 2 Jun 2010 13:01:38 +0000
>
>
> Anyone recall if SOLgnu/sun work with any optimization?
>   You know -- the platforms that have a stack walker and don't use setjmp.
> I tried leaving them having all loads/stores be volatile, except handling still doesn't work -- cm3 gets an unhandled exception instead of saying cm3.cfg not found.
> I'll have to test with an old clean version.
> Could be I'm missing something, or maybe the m3cg_pop change broke them.
>
>
>  - Jay
>
>
 		 	   		  

From jay.krell at cornell.edu  Wed Jun  2 16:30:05 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 2 Jun 2010 14:30:05 +0000
Subject: [M3devel] reducing use of volatile in backend?
In-Reply-To: <AA1F4490-A9C7-4F94-8E03-65A5E9031424@cs.purdue.edu>
References: <COL101-W17AA739AA2DE2050C6CCD0E6EF0@phx.gbl>,
	<AA1F4490-A9C7-4F94-8E03-65A5E9031424@cs.purdue.edu>
Message-ID: <COL101-W35361E5B4C86598DB49C90E6D00@phx.gbl>


attached is the diff I'm working on.


It works well on a few platforms.
I've been using it on AMD64_DARWIN.
Cross I386_LINUX, PPC_DARWIN cm3 startup and give
? the correct message, which requires exception handling to work.


SOLgnu exception handling doesn't work.
MIPS64_OPENBSD internal errors a bunch in the compiler.
? Probably don't care. Don't know if it was working before.


Still to do:
? figure out what is up with SOLgnu/SOLsun


Not ideal but I think ok for now:
? volatizing all floating point
??? We already were, though granted possibly with more optimizations.
? flag_unit_at_a_time = 0

? 
flag_unit_at_a_time isn't "tricky" or subtle,
but it does remove a function we want to take the address of.
I couldn't find a way to get it to keep the function.


What I think is fine for a while:
? flag_tree_vrp = 0;
? flag_tree_pre = 0;
? flag_tree_fre = 0;

? 
Maybe it doesn't take much to let them work?
Maybe wait until 4.5 is working and try again there?
? In particular pre/fre only fail in one file among m3core/libm3, Formater.m3.
? vrp is what silently produces non-working code.
? It is either the only one, or one of pre/fre also do.
? At least one of pre/fre crash, accessing null pointer.

?
and probably also ok for a "while":
?flag_tree_loop_im = 0
?flag_schedule_insns = 0

?
though for flag_schedule_insns = 0 to fail seems odd,
and flag_tree_loop_im only broke in a little code, should
probably look at that code.


Oh and I still need to see about fours/badbricks recieving mouse clicks.
Mine aren't.


The TREE_ADDRESSABLE change in m3_write_globals was needed to get SOLgnu
to compiler. The assert failed.


We might want to have the frontend tell the backend if the
target has a stack walker, instead of the logic I have here.


While it is not ideal, I think this will let -O1/2/3 generate code much more like people expect, without
constantly reloading registers from the stack.


?- Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com
> Subject: RE: [M3devel] reducing use of volatile in backend?
> Date: Tue, 1 Jun 2010 21:55:31 +0000
>
>
> I've had *a lot* of success here the past few hours.
>
>
> There is an assert starting up mentor I need to look at, possibly out of data binaries.
> The one in socket.c assert(lossless_socklen || socklen == null || socklen < 1<<30.
>
>
> Compiler seems to work.
> Lots of things do break it, so that is something.
>
>
> Various gui apps startup.
> Some of the gui apps don't work, but nor did older copies I had -- fours, badbricks, and I think columns, wouldn't take any mouse clicks. I have to test older versions. Could be unrelated.
>
>
>
> Here is what I have:
>
> The vast vast majority of optimizations can be enabled.
>
> Nearly all uses of volatile can be removed.
>
> Just a few optimizations "need" to be disabled.
>
> In particular:
> I only have volatile remaining:
> on store after insert_mn (special case)
>
> floating point (huh? wierd)
> compile errors without this
>
> in functions that call setjmp or vfork
> This is very reasonable, but we should try to limit it to not all the variables, only what are accessed after the second return (I'm not sure how that computes for vfork, but for setjmp it makes sense to me.
>
>
> on the load/store in loophole
> compile errors without this; perhaps redundant with the floating point check
>
>
> on load link, else it gets uninitialized warning
>
>
>
> Also I found a likely bug.
> In functions that call setjmp/vfork, we volatize already seen parameters and locals, but we don't volatize not yet seen locals (in nested blocks) and temporaries. I fixed that.
>
>
>
>
> The optimizations I disabled, from memory:
>
>
> pre - partial redundancy elimination
>
>
> fre - full redundancy elimination (these are related)
> One or both of these causes the compiler to access violate in the optimizer, compiling libm3/Formatter.mc, but otherwise I think they compile m3core and libm3 entirely
>
>
> loop im (induction motion) - caused a compile error in Trestle
>
> vrp - value range propagation
> This seems to be the biggest problem, no compile errors but "random" runtime malfunction, usually starting up cm3.
>
>
> insn_sched - wierd, caused a compile break
> but insn_sched_after_reload ok
>
>
> That's about it. All the ones with "alias" in them, only like two, I enabled, seemed ok.
> salias and strict_alias. I left strict alias till late in experimentation but really it seems ok.
>
>
> I can compile the entire system, though I get lots of warnings about uninitialized variables.
> I pass the backend the -Wuninitialized flag.
>
>
> I test it out more -- the gui non-interaction, the mentor assert, and test other platforms.
> But I think we'll have volatile mostly gone and just a small number of optimizations turned off fairly soon.
> We can iterate more on the remaining optimizations.
>
>
> Getting good typeinfo would be good so that gdb can debug.
> And maybe so that other than stabs works.
>
>
> - Jay
>
>
>
>
> ----------------------------------------
>> From: hosking at cs.purdue.edu
>> To: jay.krell at cornell.edu
>> Date: Tue, 1 Jun 2010 16:05:30 -0500
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] reducing use of volatile in backend?
>>
>> We don't want to disable optimisations for types where it makes sense
>> to have them. Better to smarten up typebased alias analysis instead so
>> we can get rid of volatile properly.
>>
>> Sent from my iPhone
>>
>> On Jun 1, 2010, at 12:16 PM, Jay K wrote:
>>
>>>
>>> Tony, would we maybe be better off not using volatile everywhere but
>>> selectively turning off optimizations in m3_post_options?
>>> You know, using volatile probably disables more than necessary?
>>> I'm experimenting with this.
>>>
>>> - Jay
>>>
>>>
>>>
>>>
>>>
 		 	   		  
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: less-volatile.txt
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100602/59c4b762/attachment-0002.txt>

From hosking at cs.purdue.edu  Wed Jun  2 16:41:47 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 2 Jun 2010 10:41:47 -0400
Subject: [M3devel] warning for uninitialized variables?
In-Reply-To: <20100602124422.11C6D1A209A@async.async.caltech.edu>
References: <20100601124200.8E42B2474003@birch.elegosoft.com>, ,
	<E86D485E-C5D5-4B7A-8142-5E0BE31280DD@cs.purdue.edu>,
	<COL101-W58EC381F7DE75AC44CFB57E6EF0@phx.gbl>, ,
	<5458A114-F000-4A90-9998-FD7DF63E06C0@cs.purdue.edu>,
	<COL101-W3678C92B3A9FA07AD57BF2E6D00@phx.gbl>,
	<20100602035226.43C1F1A208F@async.async.caltech.edu>
	<COL101-W59770EAA64E52A966D79F3E6D00@phx.gbl>
	<20100602124422.11C6D1A209A@async.async.caltech.edu>
Message-ID: <16413179-F84C-42BF-AB09-2D8294EB4782@cs.purdue.edu>

Hear, hear!

On 2 Jun 2010, at 08:44, Mika Nystrom wrote:

> Jay K writes:
>> 
>> Wow. You really surprise me Mika.
>> 
>> 
>> To warn on this kind of thing=2C to me=2C there is no question.
>> 
>> 
>> Limting the affects by virtue of being safe isn't much consolation.
>> The program can easily go down a "safe" but very incorrect path.
> 
> It is, though!  Do you always know what value to initialize the
> variables to?  If not, you're just picking some value to shut up
> the compiler, and now your code no longer expresses---to a human
> reader---that x is uninitialized.
> 
> Remember, code is mainly written for humans!  Computers don't care
> about fancy structuring, declarations, etc.  When you write a program,
> you write it to be read by a human.  The fact that a variable is
> uninitialized is a part of the design of the program.
> 
> It's an unfortunate fact that our languages don't have all the 
> mechanisms necessary to deal properly with uninitialized variables.
> Retrofitting mechanisms to something that just isn't expressive
> enough to solve the problem I really don't think is the way to go.
> 
> EWD's book chapter... read it.  "An essay on the scope of variables"
> I think it is called.
> 
> 
>> 
>> 
>> There are several forms.
>> In fact=2C sometimes the compiler says something "is" used uninitialized.
>> Sometimes it says "maybe".
>> 
>> 
>> In your example=2C generally=2C once the address is taken of a variable=2C
>> the compiler gives up. Esp. if that address is passed to a function it does=
>> n't "see".
> 
> As long as this doesn't raise warnings I can live with your warnings...
> 
> ...
>> 
>> 
>> There are many more warnings in the tree than I have yet looked at.
>> I've seen a few forms.
>> Some are because the compiler doesn't know that some functions don't return=
>> .
>> I'll see about improving that. Though I think there's a limit to how good I=
>> can manage=2C
>> unless we add a <* noreturn *> pragma.
> 
> adding <*ASSERT FALSE*> in the right places might fix these warnings.
> 
> ...
>> 
>> 
>> I grant that by initializing to 0=2C I haven't necessarily made the code co=
>> rrect either.
>> But at least it is now consistent.
>> 
>> 
>> Even better would be runtime checks that stop if a variable is read before =
>> written.
> 
> Which you have just defeated with your initialization!
> 
> I know that my Modula code will outlive its current compiler.  Probably
> by a long time.  Once you add the initialization you're talking about,
> you can't go back.  It no longer expresses the useful property you're
> trying to check.  When the new compiler comes along with its runtime
> check, it will miss that my variables are actually uninitialized.
> 
>> 
>> 
>> See also the rules in Java and C# that require the compiler to be able to p=
>> rove
>> a variable is written before read. Possibly even verifiable at load time.
> 
> I *hate* this.  See above.  
> 
> What's next?  The compiler refuses to compile loops that it can't
> prove will terminate???  Hogwash!
> 
>> 
>> 
>> Other forms look related to going "through" a switch statement with no arms=
>> handling the value.
>> I think I can address that by marking fault_proc as noreturn.
>> 
>> 
>> One form apparently in cm3ide would use uninitialized data if presented wit=
>> h a malformed file.
>> Good software doesn't depend on the well formedness of its input.
>> 
>> There are many more warnings like this in the tree.
>> 
>> 
>> My inclination is at least to temporarily hardcode the gcc backend to alway=
>> s optimize=2C
>> and always produce these warnings. People can look over them maybe and deci=
>> de.
>> Or they can look over my "fixes".
>> 
>> 
>> Or I guess if people really really really really prefer=2C we can always tu=
>> rn off the warnings
>> and let the code lie. I really think that is the wrong answer.
>> 
>> 
>> I have been burned too much by uninitialized locals in C.
>> I put " =3D { 0 }" after everything.
>> Again=2C that isn't necessarily "correct"=2C but at least the incorrect pat=
>> hs are consistent.
>> If they don't work and I happen down them=2C they will guaranteeably not wo=
>> rk.
> 
> No they will just consistently not work.  Not "guaranteeably".  You have
> to initialize them to some specific value for that to be the case.
> Using "0" often will just give you the wrong answer!  
> 
>> 
>> 
>> Uninitialized values can be different run to run.
>> Repeatability and consistency are important.
> 
> Not forcing the programmer to obscure the meaning of the code I think
> is more important.
> 
>> 
>> 
>> I'm also nervous about us not taking a hard line on integer overflow.
>> Overflown math doesn't necessarily lead to array out of bounds soon or ever=
>> .
>> It too can lead to incorrect but safe behavior.
> 
> Similar situation is it not?  You don't generate a compiler warning
> for math that "might overflow".  
> 
> I think we can all agree that error on integer overflow, error on
> use of uninitialized variable, at runtime, would both be good things?
> 
>     Mika
> 
>> 
>> 
>> =A0- Jay
>> 
>> 
>> ----------------------------------------
>>> To: jay.krell at cornell.edu
>>> Date: Tue=2C 1 Jun 2010 20:52:26 -0700
>>> From: mika at async.async.caltech.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] [M3commit] CVS Update: cm3
>>> 
>>> 
>>> Safety is important in that it allows you to limit the possible effects
>>> of bugs. Getting programs bug-free is of course a very difficult problem
>>> no matter what you do.
>>> 
>>> But no I don't think warnings for uninitialized use of variables is
>>> something one should do in general in Modula-3. The safety guarantees
>>> lead to different idioms from in C---not so many compiler warnings
>>> are required to get your code right. And if you do screw up
>>> an uninitialized variable=2C the effect is going to be limited.
>>> Unlike what happens in C=2C where if you screw up the initialization
>>> of a pointer=2C for instance=2C all hell breaks loose.
>>> 
>>> Your example is contrived. Usually the code looks like this
>>> 
>>> VAR
>>> x : T=3B
>>> BEGIN
>>> IF cond1 THEN x :=3D ... END=3B
>>> ...
>>> IF cond2 THEN (* use x *) END
>>> END
>>> 
>>> where the programmer knows that cond2 logically implies cond1.
>>> 
>>> I think the presence of VAR parameter passing makes these sorts of
>>> warnings also less useful in Modula-3. Is the following OK?
>>> 
>>> PROCEDURE InitializeIt(VAR a : T)=3B
>>> PROCEUDRE UseIt(VALUE a : T)=3B
>>> 
>>> VAR x : T=3B
>>> BEGIN
>>> InitializeIt(x)=3B
>>> UseIt(x)
>>> END
>>> 
>>> I would think your compiler can't prove that x is initialized. Warning
>>> or not? I say no: this is actually very reasonable Modula-3 code.
>>> But then do you want a warning for the IF? It's logically the same.
>>> 
>>> There's a chapter in
>>> EWD's Discipline of Programming that deals with the problem in
>>> detail. I think he winds up with six different "modes" for variables.
>>> 
>>> Mika
>>> 
>>> Jay K writes:
>>>> 
>>>> ok=3D2C so in C:
>>>> =3D20
>>>> int F()
>>>> {
>>>> int i=3D3B
>>>> return i=3D3B
>>>> }
>>>> =3D20
>>>> should warn or not?
>>>> Prevailing wisdom is definitely.
>>>> Main known exception is code to generate random numbers.
>>>> I believe this is how Debian broke key generation.
>>>> =3D20
>>>> =3D20
>>>> Modula-3:
>>>> =3D20
>>>> =3D20
>>>> PROCEDURE F(): INTEGER =3D3D=3D20
>>>> VAR i: INTEGER=3D3B
>>>> BEGIN
>>>> RETURN i=3D3B
>>>> END F=3D3B
>>>> =3D20
>>>> =3D20
>>>> Should warn or not?
>>>> Since this identical to the C=3D2C prevailing wisdom is definitely.
>>>> =3D20
>>>> =3D20
>>>> They are=3D2C I guess=3D2C "safe"=3D2C but most likely=3D2C incorrect.
>>>> =3D20
>>>> =3D20
>>>> The compiler may have made "safety" guarantees=3D2C and they are signific=
>> ant=3D
>>>> =3D2C
>>>> but safe is far from correct=3D2C and however smart the compiler can be t=
>> o lo=3D
>>>> ok for correctness issues=3D2C is also nice.
>>>> =3D20
>>>> =3D20
>>>> =3D20
>>>> (Friend of mine conjectured something like: Safety guarantees have people=
>> d=3D
>>>> eluded. Software will still have plenty of bugs and be plenty difficult t=
>> o =3D
>>>> get correct and require plenty of testing. Safety guarantees help=3D2C bu=
>> t th=3D
>>>> ey are only a small step toward actual correctness.)
>>>> =3D20
>>>> =3D20
>>>> =3D20
>>>> - Jay
>>>> 
>>>> 
>>>> ----------------------------------------
>>>>> Subject: Re: [M3commit] CVS Update: cm3
>>>>> From: hosking at cs.purdue.edu
>>>>> Date: Tue=3D2C 1 Jun 2010 20:04:00 -0400
>>>>> CC: jkrell at elego.de=3D3B m3commit at elegosoft.com
>>>>> To: jay.krell at cornell.edu
>>>>> 
>>>>> Sure=3D2C an INTEGER is a valid value whatever the bits.
>>>>> 
>>>>> 
>>>>> On 1 Jun 2010=3D2C at 17:44=3D2C Jay K wrote:
>>>>> 
>>>>>> 
>>>>>> Start removing the rampant use of volatile in the backend and these wa=
>> rn=3D
>>>> ings show up.
>>>>>> 
>>>>>> Volatile quashes the uninitialized checks in the backend.
>>>>>> 
>>>>>> Is it really ok for an INTEGER to be uninitialized? I realize it conta=
>> in=3D
>>>> s an "integer" value=3D2C as all bit patterns are.
>>>>>> 
>>>>>> Some of these really do seem like bugs. Some do not.
>>>>>> I'll try making fault_proc noreturn=3D2C which should remove some of t=
>> hem.
>>>>>> 
>>>>>> 
>>>>>> - Jay
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> ----------------------------------------
>>>>>>> From: hosking at cs.purdue.edu
>>>>>>> To: jkrell at elego.de
>>>>>>> Date: Tue=3D2C 1 Jun 2010 16:29:20 -0500
>>>>>>> CC: m3commit at elegosoft.com
>>>>>>> Subject: Re: [M3commit] CVS Update: cm3
>>>>>>> 
>>>>>>> This is bogus. The M3 compiler guarantees all variables are initializ=
>> ed=3D
>>>> .
>>>>>>> 
>>>>>>> Sent from my iPhone
>>>>>>> 
>>>>>>> On Jun 1=3D2C 2010=3D2C at 2:42 PM=3D2C jkrell at elego.de (Jay Krell) w=
>> rote:
>>>>>>> 
>>>>>>>> CVSROOT: /usr/cvs
>>>>>>>> Changes by: jkrell at birch. 10/06/01 14:42:00
>>>>>>>> 
>>>>>>>> Modified files:
>>>>>>>> cm3/m3-libs/m3core/src/convert/: Convert.m3
>>>>>>>> 
>>>>>>>> Log message:
>>>>>>>> initialize locals=3D3B I get warnings that some not quite all=3D2C a=
>> re
>>>>>>>> used uninitialized if I remove the volatile/sideeffects on every
>>>>>>>> load/store in parse.c
>>>>> =3D
>> 		 	   		  =



From jay.krell at cornell.edu  Wed Jun  2 16:52:55 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 2 Jun 2010 14:52:55 +0000
Subject: [M3devel] warning for uninitialized variables?
In-Reply-To: <16413179-F84C-42BF-AB09-2D8294EB4782@cs.purdue.edu>
References: <20100601124200.8E42B2474003@birch.elegosoft.com>,
	, , <E86D485E-C5D5-4B7A-8142-5E0BE31280DD@cs.purdue.edu>, ,
	<COL101-W58EC381F7DE75AC44CFB57E6EF0@phx.gbl>, 
	, , <5458A114-F000-4A90-9998-FD7DF63E06C0@cs.purdue.edu>, ,
	<COL101-W3678C92B3A9FA07AD57BF2E6D00@phx.gbl>, ,
	<20100602035226.43C1F1A208F@async.async.caltech.edu>,
	<COL101-W59770EAA64E52A966D79F3E6D00@phx.gbl>,
	<20100602124422.11C6D1A209A@async.async.caltech.edu>,
	<16413179-F84C-42BF-AB09-2D8294EB4782@cs.purdue.edu>
Message-ID: <COL101-W44444F6A175254747767CFE6D00@phx.gbl>


Running with a consistent initialized/uninitialized 0 is better than running with a "random" value that you get from no initialization.
?They are both "bad".
?The 0 is agreed misleading, because it might look initialized.
? But it still better than a value that can change from run to run.


C int (or ptrdiff_t) and Modula-3 INTEGER are equivalent. They both are "valid" for any bit pattern.
C programmers always consider it a bug to use uninitialized values, except, the case I pointed out, looking for entropy to generate random numbers.

?>> The fact that a variable is uninitialized is a part of the design of the program.

Not if it can be used uninitialized.
Some of the warnings from gcc are definitive -- the values *are* used uninitialized.
Sometimes it says "is used uninitialized", sometimes it says "might be used initialized", and usually it is quiet, either because it knows it isn't used uninitialized or because it is too uncertain.


Programs are written for humans to read, true, but programs that read programs are much more diligent, energetic, and often smarter (and slowly getting smarter with age, often the opposite of humans).
Compilers really do have a big "leg" up on humans, since they can harness fast digital processor with big storage.
Granted, neither is always better than the other. But compilers/computers have far more capacity for code reading than humans and I know from experience that most code is never read by a human, not even once, until I get to it :), because the bugs I readily see wouldn't survive even a glance...
?(and the compilers often fail too, granted).


Again I'm quite surprised we want to leave uninitialized variables that get used uninitialized.
The one in cm3ide for example, if the input is malformed, I believe it uses uninitialized data.
I don't see how this can be deemed anything other than a bug to be fixed, and that we should be glad the compiler (finally) found it..now that I'm working on removing the rampant volatile...


If we can invest in runtime checks to immediately catch reads of unwritten data, then I'd favor that instead.


?- Jay

----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Wed, 2 Jun 2010 10:41:47 -0400
> To: mika at async.async.caltech.edu
> CC: m3devel at elegosoft.com; jay.krell at cornell.edu
> Subject: Re: [M3devel] warning for uninitialized variables?
>
> Hear, hear!
>
> On 2 Jun 2010, at 08:44, Mika Nystrom wrote:
>
>> Jay K writes:
>>>
>>> Wow. You really surprise me Mika.
>>>
>>>
>>> To warn on this kind of thing=2C to me=2C there is no question.
>>>
>>>
>>> Limting the affects by virtue of being safe isn't much consolation.
>>> The program can easily go down a "safe" but very incorrect path.
>>
>> It is, though! Do you always know what value to initialize the
>> variables to? If not, you're just picking some value to shut up
>> the compiler, and now your code no longer expresses---to a human
>> reader---that x is uninitialized.
>>
>> Remember, code is mainly written for humans! Computers don't care
>> about fancy structuring, declarations, etc. When you write a program,
>> you write it to be read by a human. The fact that a variable is
>> uninitialized is a part of the design of the program.
>>
>> It's an unfortunate fact that our languages don't have all the
>> mechanisms necessary to deal properly with uninitialized variables.
>> Retrofitting mechanisms to something that just isn't expressive
>> enough to solve the problem I really don't think is the way to go.
>>
>> EWD's book chapter... read it. "An essay on the scope of variables"
>> I think it is called.
>>
>>
>>>
>>>
>>> There are several forms.
>>> In fact=2C sometimes the compiler says something "is" used uninitialized.
>>> Sometimes it says "maybe".
>>>
>>>
>>> In your example=2C generally=2C once the address is taken of a variable=2C
>>> the compiler gives up. Esp. if that address is passed to a function it does=
>>> n't "see".
>>
>> As long as this doesn't raise warnings I can live with your warnings...
>>
>> ...
>>>
>>>
>>> There are many more warnings in the tree than I have yet looked at.
>>> I've seen a few forms.
>>> Some are because the compiler doesn't know that some functions don't return=
>>> .
>>> I'll see about improving that. Though I think there's a limit to how good I=
>>> can manage=2C
>>> unless we add a <* noreturn *> pragma.
>>
>> adding <*ASSERT FALSE*> in the right places might fix these warnings.
>>
>> ...
>>>
>>>
>>> I grant that by initializing to 0=2C I haven't necessarily made the code co=
>>> rrect either.
>>> But at least it is now consistent.
>>>
>>>
>>> Even better would be runtime checks that stop if a variable is read before =
>>> written.
>>
>> Which you have just defeated with your initialization!
>>
>> I know that my Modula code will outlive its current compiler. Probably
>> by a long time. Once you add the initialization you're talking about,
>> you can't go back. It no longer expresses the useful property you're
>> trying to check. When the new compiler comes along with its runtime
>> check, it will miss that my variables are actually uninitialized.
>>
>>>
>>>
>>> See also the rules in Java and C# that require the compiler to be able to p=
>>> rove
>>> a variable is written before read. Possibly even verifiable at load time.
>>
>> I *hate* this. See above.
>>
>> What's next? The compiler refuses to compile loops that it can't
>> prove will terminate??? Hogwash!
>>
>>>
>>>
>>> Other forms look related to going "through" a switch statement with no arms=
>>> handling the value.
>>> I think I can address that by marking fault_proc as noreturn.
>>>
>>>
>>> One form apparently in cm3ide would use uninitialized data if presented wit=
>>> h a malformed file.
>>> Good software doesn't depend on the well formedness of its input.
>>>
>>> There are many more warnings like this in the tree.
>>>
>>>
>>> My inclination is at least to temporarily hardcode the gcc backend to alway=
>>> s optimize=2C
>>> and always produce these warnings. People can look over them maybe and deci=
>>> de.
>>> Or they can look over my "fixes".
>>>
>>>
>>> Or I guess if people really really really really prefer=2C we can always tu=
>>> rn off the warnings
>>> and let the code lie. I really think that is the wrong answer.
>>>
>>>
>>> I have been burned too much by uninitialized locals in C.
>>> I put " =3D { 0 }" after everything.
>>> Again=2C that isn't necessarily "correct"=2C but at least the incorrect pat=
>>> hs are consistent.
>>> If they don't work and I happen down them=2C they will guaranteeably not wo=
>>> rk.
>>
>> No they will just consistently not work. Not "guaranteeably". You have
>> to initialize them to some specific value for that to be the case.
>> Using "0" often will just give you the wrong answer!
>>
>>>
>>>
>>> Uninitialized values can be different run to run.
>>> Repeatability and consistency are important.
>>
>> Not forcing the programmer to obscure the meaning of the code I think
>> is more important.
>>
>>>
>>>
>>> I'm also nervous about us not taking a hard line on integer overflow.
>>> Overflown math doesn't necessarily lead to array out of bounds soon or ever=
>>> .
>>> It too can lead to incorrect but safe behavior.
>>
>> Similar situation is it not? You don't generate a compiler warning
>> for math that "might overflow".
>>
>> I think we can all agree that error on integer overflow, error on
>> use of uninitialized variable, at runtime, would both be good things?
>>
>> Mika
>>
>>>
>>>
>>> =A0- Jay
>>>
>>>
>>> ----------------------------------------
>>>> To: jay.krell at cornell.edu
>>>> Date: Tue=2C 1 Jun 2010 20:52:26 -0700
>>>> From: mika at async.async.caltech.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] [M3commit] CVS Update: cm3
>>>>
>>>>
>>>> Safety is important in that it allows you to limit the possible effects
>>>> of bugs. Getting programs bug-free is of course a very difficult problem
>>>> no matter what you do.
>>>>
>>>> But no I don't think warnings for uninitialized use of variables is
>>>> something one should do in general in Modula-3. The safety guarantees
>>>> lead to different idioms from in C---not so many compiler warnings
>>>> are required to get your code right. And if you do screw up
>>>> an uninitialized variable=2C the effect is going to be limited.
>>>> Unlike what happens in C=2C where if you screw up the initialization
>>>> of a pointer=2C for instance=2C all hell breaks loose.
>>>>
>>>> Your example is contrived. Usually the code looks like this
>>>>
>>>> VAR
>>>> x : T=3B
>>>> BEGIN
>>>> IF cond1 THEN x :=3D ... END=3B
>>>> ...
>>>> IF cond2 THEN (* use x *) END
>>>> END
>>>>
>>>> where the programmer knows that cond2 logically implies cond1.
>>>>
>>>> I think the presence of VAR parameter passing makes these sorts of
>>>> warnings also less useful in Modula-3. Is the following OK?
>>>>
>>>> PROCEDURE InitializeIt(VAR a : T)=3B
>>>> PROCEUDRE UseIt(VALUE a : T)=3B
>>>>
>>>> VAR x : T=3B
>>>> BEGIN
>>>> InitializeIt(x)=3B
>>>> UseIt(x)
>>>> END
>>>>
>>>> I would think your compiler can't prove that x is initialized. Warning
>>>> or not? I say no: this is actually very reasonable Modula-3 code.
>>>> But then do you want a warning for the IF? It's logically the same.
>>>>
>>>> There's a chapter in
>>>> EWD's Discipline of Programming that deals with the problem in
>>>> detail. I think he winds up with six different "modes" for variables.
>>>>
>>>> Mika
>>>>
>>>> Jay K writes:
>>>>>
>>>>> ok=3D2C so in C:
>>>>> =3D20
>>>>> int F()
>>>>> {
>>>>> int i=3D3B
>>>>> return i=3D3B
>>>>> }
>>>>> =3D20
>>>>> should warn or not?
>>>>> Prevailing wisdom is definitely.
>>>>> Main known exception is code to generate random numbers.
>>>>> I believe this is how Debian broke key generation.
>>>>> =3D20
>>>>> =3D20
>>>>> Modula-3:
>>>>> =3D20
>>>>> =3D20
>>>>> PROCEDURE F(): INTEGER =3D3D=3D20
>>>>> VAR i: INTEGER=3D3B
>>>>> BEGIN
>>>>> RETURN i=3D3B
>>>>> END F=3D3B
>>>>> =3D20
>>>>> =3D20
>>>>> Should warn or not?
>>>>> Since this identical to the C=3D2C prevailing wisdom is definitely.
>>>>> =3D20
>>>>> =3D20
>>>>> They are=3D2C I guess=3D2C "safe"=3D2C but most likely=3D2C incorrect.
>>>>> =3D20
>>>>> =3D20
>>>>> The compiler may have made "safety" guarantees=3D2C and they are signific=
>>> ant=3D
>>>>> =3D2C
>>>>> but safe is far from correct=3D2C and however smart the compiler can be t=
>>> o lo=3D
>>>>> ok for correctness issues=3D2C is also nice.
>>>>> =3D20
>>>>> =3D20
>>>>> =3D20
>>>>> (Friend of mine conjectured something like: Safety guarantees have people=
>>> d=3D
>>>>> eluded. Software will still have plenty of bugs and be plenty difficult t=
>>> o =3D
>>>>> get correct and require plenty of testing. Safety guarantees help=3D2C bu=
>>> t th=3D
>>>>> ey are only a small step toward actual correctness.)
>>>>> =3D20
>>>>> =3D20
>>>>> =3D20
>>>>> - Jay
>>>>>
>>>>>
>>>>> ----------------------------------------
>>>>>> Subject: Re: [M3commit] CVS Update: cm3
>>>>>> From: hosking at cs.purdue.edu
>>>>>> Date: Tue=3D2C 1 Jun 2010 20:04:00 -0400
>>>>>> CC: jkrell at elego.de=3D3B m3commit at elegosoft.com
>>>>>> To: jay.krell at cornell.edu
>>>>>>
>>>>>> Sure=3D2C an INTEGER is a valid value whatever the bits.
>>>>>>
>>>>>>
>>>>>> On 1 Jun 2010=3D2C at 17:44=3D2C Jay K wrote:
>>>>>>
>>>>>>>
>>>>>>> Start removing the rampant use of volatile in the backend and these wa=
>>> rn=3D
>>>>> ings show up.
>>>>>>>
>>>>>>> Volatile quashes the uninitialized checks in the backend.
>>>>>>>
>>>>>>> Is it really ok for an INTEGER to be uninitialized? I realize it conta=
>>> in=3D
>>>>> s an "integer" value=3D2C as all bit patterns are.
>>>>>>>
>>>>>>> Some of these really do seem like bugs. Some do not.
>>>>>>> I'll try making fault_proc noreturn=3D2C which should remove some of t=
>>> hem.
>>>>>>>
>>>>>>>
>>>>>>> - Jay
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ----------------------------------------
>>>>>>>> From: hosking at cs.purdue.edu
>>>>>>>> To: jkrell at elego.de
>>>>>>>> Date: Tue=3D2C 1 Jun 2010 16:29:20 -0500
>>>>>>>> CC: m3commit at elegosoft.com
>>>>>>>> Subject: Re: [M3commit] CVS Update: cm3
>>>>>>>>
>>>>>>>> This is bogus. The M3 compiler guarantees all variables are initializ=
>>> ed=3D
>>>>> .
>>>>>>>>
>>>>>>>> Sent from my iPhone
>>>>>>>>
>>>>>>>> On Jun 1=3D2C 2010=3D2C at 2:42 PM=3D2C jkrell at elego.de (Jay Krell) w=
>>> rote:
>>>>>>>>
>>>>>>>>> CVSROOT: /usr/cvs
>>>>>>>>> Changes by: jkrell at birch. 10/06/01 14:42:00
>>>>>>>>>
>>>>>>>>> Modified files:
>>>>>>>>> cm3/m3-libs/m3core/src/convert/: Convert.m3
>>>>>>>>>
>>>>>>>>> Log message:
>>>>>>>>> initialize locals=3D3B I get warnings that some not quite all=3D2C a=
>>> re
>>>>>>>>> used uninitialized if I remove the volatile/sideeffects on every
>>>>>>>>> load/store in parse.c
>>>>>> =3D
>>> =
>
 		 	   		  

From hosking at cs.purdue.edu  Wed Jun  2 17:02:15 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 2 Jun 2010 11:02:15 -0400
Subject: [M3devel] ADR is *too* unsafe..
In-Reply-To: <COL101-W444318DF7FE046C2AE542AE6D00@phx.gbl>
References: <COL101-W617B9602E6CAA0BBE5BE25E6D00@phx.gbl>,
	<A8CEEB02-D279-4C90-B8D3-5D163619C748@cs.purdue.edu>
	<COL101-W444318DF7FE046C2AE542AE6D00@phx.gbl>
Message-ID: <67147BA0-0307-45FB-B646-588B55EDACC3@cs.purdue.edu>

Actually, the compiler already has support to do exactly what you want.  Take a look at the flag Host.new_adr.  This implements:

ADR (t: T): UNTRACED REF T



On 2 Jun 2010, at 10:07, Jay K wrote:

> 
> The compiler doesn't break. Mentor does, networking stuff. I fixed it. But I would have
> expected the compiler to have told me about it.
> It is unfortunate. ADR should be *slightly* safer.
> Maybe we can get a warning for this? passing ADR(foo) to untraced ref bar?
> It seems...quite unfortunate that the language is defined this way..
> 
>  - Jay
> 
> 
> ----------------------------------------
>> From: hosking at cs.purdue.edu
>> Date: Wed, 2 Jun 2010 10:01:09 -0400
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] ADR is *too* unsafe..
>> 
>> Why does the compiler break?
>> Yes, VAR is *much* safer.
>> 
>> On 2 Jun 2010, at 03:41, Jay K wrote:
>> 
>>> 
>>> (*
>>> Wow, ADR generates a plain ADDRESS, not an untraced ref to a specific type?
>>> Doesn't this seem wrong? Doesn't unsafe code deserve a little better, say,
>>> to be at least as typesafe as C?
>>> http://www.cs.purdue.edu/homes/hosking/m3/reference/unsafe.html
>>> 
>>> This is why 64bit m3-comm/tcp/src/TCP.m3 breaks randomly
>>> on some platforms on an assertion failure in C. And the
>>> compiler isn't going to help me find these type mismatches? Ugh.
>>> 
>>> This seems wrong. :(
>>> 
>>> I guess I should really really use VAR then.
>>> *)
>>> 
>>> 
>>> UNSAFE MODULE Main;
>>> IMPORT Ctypes, Cstddef;
>>> 
>>> 
>>> PROCEDURE F1(a:UNTRACED REF Ctypes.int) =
>>> BEGIN
>>> F2(a); (* error, expected *)
>>> END F1;
>>> 
>>> 
>>> PROCEDURE F2(a:UNTRACED REF Cstddef.size_t) =
>>> BEGIN
>>> F1(a); (* error, expected *)
>>> END F2;
>>> 
>>> 
>>> VAR c:Ctypes.int;
>>> d:Cstddef.size_t;
>>> 
>>> 
>>> BEGIN
>>> F1(ADR(c)); (* ok *)
>>> F1(ADR(d)); (* error expected but no *)
>>> F2(ADR(c)); (* error expected but no *)
>>> F2(ADR(d)); (* ok *)
>>> END Main.
>>> 
>>> 
>>> 
>>> - Jay
>>> 
>> 
> 		 	   		  



From hosking at cs.purdue.edu  Wed Jun  2 17:02:54 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 2 Jun 2010 11:02:54 -0400
Subject: [M3devel] SOLgnu/SOLsun -O1/-O2/-O3
In-Reply-To: <COL101-W26B2AF5D865D1A694793DAE6D00@phx.gbl>
References: <COL101-W26B2AF5D865D1A694793DAE6D00@phx.gbl>
Message-ID: <C793D9CD-5C57-49D8-927D-26EBDEAFE0AB@cs.purdue.edu>

Yes, worked for me using -O3.


On 2 Jun 2010, at 09:01, Jay K wrote:

> 
> Anyone recall if SOLgnu/sun work with any optimization?
>   You know -- the platforms that have a stack walker and don't use setjmp.
> I tried leaving them having all loads/stores be volatile, except handling still doesn't work -- cm3 gets an unhandled exception instead of saying cm3.cfg not found.
> I'll have to test with an old clean version.
> Could be I'm missing something, or maybe the m3cg_pop change broke them.
> 
> 
>  - Jay
> 
> 		 	   		  



From hosking at cs.purdue.edu  Wed Jun  2 17:04:09 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 2 Jun 2010 11:04:09 -0400
Subject: [M3devel] reducing use of volatile in backend?
In-Reply-To: <COL101-W35361E5B4C86598DB49C90E6D00@phx.gbl>
References: <COL101-W17AA739AA2DE2050C6CCD0E6EF0@phx.gbl>,
	<AA1F4490-A9C7-4F94-8E03-65A5E9031424@cs.purdue.edu>
	<COL101-W35361E5B4C86598DB49C90E6D00@phx.gbl>
Message-ID: <B09FDA2E-FBC9-473F-B311-283F9D573568@cs.purdue.edu>



On 2 Jun 2010, at 10:30, Jay K wrote:

> 
> attached is the diff I'm working on.
> 
> 
> It works well on a few platforms.
> I've been using it on AMD64_DARWIN.
> Cross I386_LINUX, PPC_DARWIN cm3 startup and give
>   the correct message, which requires exception handling to work.
> 
> 
> SOLgnu exception handling doesn't work.

Possibly needs a register window flush?  I'm only speculating here.

> MIPS64_OPENBSD internal errors a bunch in the compiler.
>   Probably don't care. Don't know if it was working before.
> 
> Still to do:
>   figure out what is up with SOLgnu/SOLsun
> 
> 
> Not ideal but I think ok for now:
>   volatizing all floating point
>     We already were, though granted possibly with more optimizations.
>   flag_unit_at_a_time = 0
> 
>   
> flag_unit_at_a_time isn't "tricky" or subtle,
> but it does remove a function we want to take the address of.
> I couldn't find a way to get it to keep the function.
> 
> 
> What I think is fine for a while:
>   flag_tree_vrp = 0;
>   flag_tree_pre = 0;
>   flag_tree_fre = 0;
> 
>   
> Maybe it doesn't take much to let them work?
> Maybe wait until 4.5 is working and try again there?
>   In particular pre/fre only fail in one file among m3core/libm3, Formater.m3.
>   vrp is what silently produces non-working code.
>   It is either the only one, or one of pre/fre also do.
>   At least one of pre/fre crash, accessing null pointer.
> 
>  
> and probably also ok for a "while":
>  flag_tree_loop_im = 0
>  flag_schedule_insns = 0
> 
>  
> though for flag_schedule_insns = 0 to fail seems odd,
> and flag_tree_loop_im only broke in a little code, should
> probably look at that code.
> 
> 
> Oh and I still need to see about fours/badbricks recieving mouse clicks.
> Mine aren't.
> 
> 
> The TREE_ADDRESSABLE change in m3_write_globals was needed to get SOLgnu
> to compiler. The assert failed.
> 
> 
> We might want to have the frontend tell the backend if the
> target has a stack walker, instead of the logic I have here.
> 
> 
> While it is not ideal, I think this will let -O1/2/3 generate code much more like people expect, without
> constantly reloading registers from the stack.
> 
> 
>  - Jay
> 
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: hosking at cs.purdue.edu
>> CC: m3devel at elegosoft.com
>> Subject: RE: [M3devel] reducing use of volatile in backend?
>> Date: Tue, 1 Jun 2010 21:55:31 +0000
>> 
>> 
>> I've had *a lot* of success here the past few hours.
>> 
>> 
>> There is an assert starting up mentor I need to look at, possibly out of data binaries.
>> The one in socket.c assert(lossless_socklen || socklen == null || socklen < 1<<30.
>> 
>> 
>> Compiler seems to work.
>> Lots of things do break it, so that is something.
>> 
>> 
>> Various gui apps startup.
>> Some of the gui apps don't work, but nor did older copies I had -- fours, badbricks, and I think columns, wouldn't take any mouse clicks. I have to test older versions. Could be unrelated.
>> 
>> 
>> 
>> Here is what I have:
>> 
>> The vast vast majority of optimizations can be enabled.
>> 
>> Nearly all uses of volatile can be removed.
>> 
>> Just a few optimizations "need" to be disabled.
>> 
>> In particular:
>> I only have volatile remaining:
>> on store after insert_mn (special case)
>> 
>> floating point (huh? wierd)
>> compile errors without this
>> 
>> in functions that call setjmp or vfork
>> This is very reasonable, but we should try to limit it to not all the variables, only what are accessed after the second return (I'm not sure how that computes for vfork, but for setjmp it makes sense to me.
>> 
>> 
>> on the load/store in loophole
>> compile errors without this; perhaps redundant with the floating point check
>> 
>> 
>> on load link, else it gets uninitialized warning
>> 
>> 
>> 
>> Also I found a likely bug.
>> In functions that call setjmp/vfork, we volatize already seen parameters and locals, but we don't volatize not yet seen locals (in nested blocks) and temporaries. I fixed that.
>> 
>> 
>> 
>> 
>> The optimizations I disabled, from memory:
>> 
>> 
>> pre - partial redundancy elimination
>> 
>> 
>> fre - full redundancy elimination (these are related)
>> One or both of these causes the compiler to access violate in the optimizer, compiling libm3/Formatter.mc, but otherwise I think they compile m3core and libm3 entirely
>> 
>> 
>> loop im (induction motion) - caused a compile error in Trestle
>> 
>> vrp - value range propagation
>> This seems to be the biggest problem, no compile errors but "random" runtime malfunction, usually starting up cm3.
>> 
>> 
>> insn_sched - wierd, caused a compile break
>> but insn_sched_after_reload ok
>> 
>> 
>> That's about it. All the ones with "alias" in them, only like two, I enabled, seemed ok.
>> salias and strict_alias. I left strict alias till late in experimentation but really it seems ok.
>> 
>> 
>> I can compile the entire system, though I get lots of warnings about uninitialized variables.
>> I pass the backend the -Wuninitialized flag.
>> 
>> 
>> I test it out more -- the gui non-interaction, the mentor assert, and test other platforms.
>> But I think we'll have volatile mostly gone and just a small number of optimizations turned off fairly soon.
>> We can iterate more on the remaining optimizations.
>> 
>> 
>> Getting good typeinfo would be good so that gdb can debug.
>> And maybe so that other than stabs works.
>> 
>> 
>> - Jay
>> 
>> 
>> 
>> 
>> ----------------------------------------
>>> From: hosking at cs.purdue.edu
>>> To: jay.krell at cornell.edu
>>> Date: Tue, 1 Jun 2010 16:05:30 -0500
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] reducing use of volatile in backend?
>>> 
>>> We don't want to disable optimisations for types where it makes sense
>>> to have them. Better to smarten up typebased alias analysis instead so
>>> we can get rid of volatile properly.
>>> 
>>> Sent from my iPhone
>>> 
>>> On Jun 1, 2010, at 12:16 PM, Jay K wrote:
>>> 
>>>> 
>>>> Tony, would we maybe be better off not using volatile everywhere but
>>>> selectively turning off optimizations in m3_post_options?
>>>> You know, using volatile probably disables more than necessary?
>>>> I'm experimenting with this.
>>>> 
>>>> - Jay
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
> 		 	   		  <less-volatile.txt>

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

From hosking at cs.purdue.edu  Wed Jun  2 17:06:23 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 2 Jun 2010 11:06:23 -0400
Subject: [M3devel] warning for uninitialized variables?
In-Reply-To: <COL101-W44444F6A175254747767CFE6D00@phx.gbl>
References: <20100601124200.8E42B2474003@birch.elegosoft.com>, , ,
	<E86D485E-C5D5-4B7A-8142-5E0BE31280DD@cs.purdue.edu>, ,
	<COL101-W58EC381F7DE75AC44CFB57E6EF0@phx.gbl>, , ,
	<5458A114-F000-4A90-9998-FD7DF63E06C0@cs.purdue.edu>, ,
	<COL101-W3678C92B3A9FA07AD57BF2E6D00@phx.gbl>, ,
	<20100602035226.43C1F1A208F@async.async.caltech.edu>,
	<COL101-W59770EAA64E52A966D79F3E6D00@phx.gbl>,
	<20100602124422.11C6D1A209A@async.async.caltech.edu>,
	<16413179-F84C-42BF-AB09-2D8294EB4782@cs.purdue.edu>
	<COL101-W44444F6A175254747767CFE6D00@phx.gbl>
Message-ID: <5EDDD7E5-C33E-4BD1-A036-2D3561F08277@cs.purdue.edu>

On 2 Jun 2010, at 10:52, Jay K wrote:

> If we can invest in runtime checks to immediately catch reads of unwritten data, then I'd favor that instead.

YUCK!



From hosking at cs.purdue.edu  Wed Jun  2 17:08:55 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 2 Jun 2010 11:08:55 -0400
Subject: [M3devel] ADR is *too* unsafe..
In-Reply-To: <67147BA0-0307-45FB-B646-588B55EDACC3@cs.purdue.edu>
References: <COL101-W617B9602E6CAA0BBE5BE25E6D00@phx.gbl>,
	<A8CEEB02-D279-4C90-B8D3-5D163619C748@cs.purdue.edu>
	<COL101-W444318DF7FE046C2AE542AE6D00@phx.gbl>
	<67147BA0-0307-45FB-B646-588B55EDACC3@cs.purdue.edu>
Message-ID: <833AEC0D-7CAD-4E2E-A99D-C12F5C0DD870@cs.purdue.edu>

Also, I meant to point to:

http://www.modula3.org/threads/3/#advancedTopic

On 2 Jun 2010, at 11:02, Tony Hosking wrote:

> Actually, the compiler already has support to do exactly what you want.  Take a look at the flag Host.new_adr.  This implements:
> 
> ADR (t: T): UNTRACED REF T
> 
> 
> 
> On 2 Jun 2010, at 10:07, Jay K wrote:
> 
>> 
>> The compiler doesn't break. Mentor does, networking stuff. I fixed it. But I would have
>> expected the compiler to have told me about it.
>> It is unfortunate. ADR should be *slightly* safer.
>> Maybe we can get a warning for this? passing ADR(foo) to untraced ref bar?
>> It seems...quite unfortunate that the language is defined this way..
>> 
>> - Jay
>> 
>> 
>> ----------------------------------------
>>> From: hosking at cs.purdue.edu
>>> Date: Wed, 2 Jun 2010 10:01:09 -0400
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] ADR is *too* unsafe..
>>> 
>>> Why does the compiler break?
>>> Yes, VAR is *much* safer.
>>> 
>>> On 2 Jun 2010, at 03:41, Jay K wrote:
>>> 
>>>> 
>>>> (*
>>>> Wow, ADR generates a plain ADDRESS, not an untraced ref to a specific type?
>>>> Doesn't this seem wrong? Doesn't unsafe code deserve a little better, say,
>>>> to be at least as typesafe as C?
>>>> http://www.cs.purdue.edu/homes/hosking/m3/reference/unsafe.html
>>>> 
>>>> This is why 64bit m3-comm/tcp/src/TCP.m3 breaks randomly
>>>> on some platforms on an assertion failure in C. And the
>>>> compiler isn't going to help me find these type mismatches? Ugh.
>>>> 
>>>> This seems wrong. :(
>>>> 
>>>> I guess I should really really use VAR then.
>>>> *)
>>>> 
>>>> 
>>>> UNSAFE MODULE Main;
>>>> IMPORT Ctypes, Cstddef;
>>>> 
>>>> 
>>>> PROCEDURE F1(a:UNTRACED REF Ctypes.int) =
>>>> BEGIN
>>>> F2(a); (* error, expected *)
>>>> END F1;
>>>> 
>>>> 
>>>> PROCEDURE F2(a:UNTRACED REF Cstddef.size_t) =
>>>> BEGIN
>>>> F1(a); (* error, expected *)
>>>> END F2;
>>>> 
>>>> 
>>>> VAR c:Ctypes.int;
>>>> d:Cstddef.size_t;
>>>> 
>>>> 
>>>> BEGIN
>>>> F1(ADR(c)); (* ok *)
>>>> F1(ADR(d)); (* error expected but no *)
>>>> F2(ADR(c)); (* error expected but no *)
>>>> F2(ADR(d)); (* ok *)
>>>> END Main.
>>>> 
>>>> 
>>>> 
>>>> - Jay
>>>> 
>>> 
>> 		 	   		  
> 



From jay.krell at cornell.edu  Wed Jun  2 17:13:55 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 2 Jun 2010 15:13:55 +0000
Subject: [M3devel] warning for uninitialized variables?
In-Reply-To: <5EDDD7E5-C33E-4BD1-A036-2D3561F08277@cs.purdue.edu>
References: <20100601124200.8E42B2474003@birch.elegosoft.com>, ,
	,,<E86D485E-C5D5-4B7A-8142-5E0BE31280DD@cs.purdue.edu>,
	,,<COL101-W58EC381F7DE75AC44CFB57E6EF0@phx.gbl>, ,
	,,<5458A114-F000-4A90-9998-FD7DF63E06C0@cs.purdue.edu>,
	,,<COL101-W3678C92B3A9FA07AD57BF2E6D00@phx.gbl>,
	, , <20100602035226.43C1F1A208F@async.async.caltech.edu>, ,
	<COL101-W59770EAA64E52A966D79F3E6D00@phx.gbl>, ,
	<20100602124422.11C6D1A209A@async.async.caltech.edu>, ,
	<16413179-F84C-42BF-AB09-2D8294EB4782@cs.purdue.edu>,
	<COL101-W44444F6A175254747767CFE6D00@phx.gbl>,
	<5EDDD7E5-C33E-4BD1-A036-2D3561F08277@cs.purdue.edu>
Message-ID: <COL101-W40BE08A256108863A44C5FE6D00@phx.gbl>


Well, I'm certainly not lobbying hard for that, presumably there is no efficient implementation, esp. for full range integers.

Wikipedia has a nice article. "nice" means "agrees with me".


http://en.wikipedia.org/wiki/Uninitialized_variable
"it is a programming error and a common source of bugs in software."


And then they point out how Java requires mechanically verified initialization of locals.

The code:
void F(bool a)
?int i;
?if (a)
?? i = 0;
if (a)
? print(i)


is I believe illegal.


?- Jay


----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Wed, 2 Jun 2010 11:06:23 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] warning for uninitialized variables?
>
> On 2 Jun 2010, at 10:52, Jay K wrote:
>
>> If we can invest in runtime checks to immediately catch reads of unwritten data, then I'd favor that instead.
>
> YUCK!
>
 		 	   		  

From jay.krell at cornell.edu  Wed Jun  2 17:18:22 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 2 Jun 2010 15:18:22 +0000
Subject: [M3devel] ADR is *too* unsafe..
In-Reply-To: <833AEC0D-7CAD-4E2E-A99D-C12F5C0DD870@cs.purdue.edu>
References: <COL101-W617B9602E6CAA0BBE5BE25E6D00@phx.gbl>, ,
	<A8CEEB02-D279-4C90-B8D3-5D163619C748@cs.purdue.edu>,
	<COL101-W444318DF7FE046C2AE542AE6D00@phx.gbl>,
	<67147BA0-0307-45FB-B646-588B55EDACC3@cs.purdue.edu>,
	<833AEC0D-7CAD-4E2E-A99D-C12F5C0DD870@cs.purdue.edu>
Message-ID: <COL101-W259EC30CD3362F448A983DE6D00@phx.gbl>


Cool.

?> but also modified the front-end of the compiler to generate C
header files for Modula-3 interface files.
?> This way, procedures exported via a
Modula-3 interface can be called directly from C using "module dot method"
syntax


I've been wanting that. :)

?> "CVAR"

Sounds like a good small change?

?- Jay


----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Wed, 2 Jun 2010 11:08:55 -0400
> To: hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com; jay.krell at cornell.edu
> Subject: Re: [M3devel] ADR is *too* unsafe..
>
> Also, I meant to point to:
>
> http://www.modula3.org/threads/3/#advancedTopic
>
> On 2 Jun 2010, at 11:02, Tony Hosking wrote:
>
>> Actually, the compiler already has support to do exactly what you want. Take a look at the flag Host.new_adr. This implements:
>>
>> ADR (t: T): UNTRACED REF T
>>
>>
>>
>> On 2 Jun 2010, at 10:07, Jay K wrote:
>>
>>>
>>> The compiler doesn't break. Mentor does, networking stuff. I fixed it. But I would have
>>> expected the compiler to have told me about it.
>>> It is unfortunate. ADR should be *slightly* safer.
>>> Maybe we can get a warning for this? passing ADR(foo) to untraced ref bar?
>>> It seems...quite unfortunate that the language is defined this way..
>>>
>>> - Jay
>>>
>>>
>>> ----------------------------------------
>>>> From: hosking at cs.purdue.edu
>>>> Date: Wed, 2 Jun 2010 10:01:09 -0400
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] ADR is *too* unsafe..
>>>>
>>>> Why does the compiler break?
>>>> Yes, VAR is *much* safer.
>>>>
>>>> On 2 Jun 2010, at 03:41, Jay K wrote:
>>>>
>>>>>
>>>>> (*
>>>>> Wow, ADR generates a plain ADDRESS, not an untraced ref to a specific type?
>>>>> Doesn't this seem wrong? Doesn't unsafe code deserve a little better, say,
>>>>> to be at least as typesafe as C?
>>>>> http://www.cs.purdue.edu/homes/hosking/m3/reference/unsafe.html
>>>>>
>>>>> This is why 64bit m3-comm/tcp/src/TCP.m3 breaks randomly
>>>>> on some platforms on an assertion failure in C. And the
>>>>> compiler isn't going to help me find these type mismatches? Ugh.
>>>>>
>>>>> This seems wrong. :(
>>>>>
>>>>> I guess I should really really use VAR then.
>>>>> *)
>>>>>
>>>>>
>>>>> UNSAFE MODULE Main;
>>>>> IMPORT Ctypes, Cstddef;
>>>>>
>>>>>
>>>>> PROCEDURE F1(a:UNTRACED REF Ctypes.int) =
>>>>> BEGIN
>>>>> F2(a); (* error, expected *)
>>>>> END F1;
>>>>>
>>>>>
>>>>> PROCEDURE F2(a:UNTRACED REF Cstddef.size_t) =
>>>>> BEGIN
>>>>> F1(a); (* error, expected *)
>>>>> END F2;
>>>>>
>>>>>
>>>>> VAR c:Ctypes.int;
>>>>> d:Cstddef.size_t;
>>>>>
>>>>>
>>>>> BEGIN
>>>>> F1(ADR(c)); (* ok *)
>>>>> F1(ADR(d)); (* error expected but no *)
>>>>> F2(ADR(c)); (* error expected but no *)
>>>>> F2(ADR(d)); (* ok *)
>>>>> END Main.
>>>>>
>>>>>
>>>>>
>>>>> - Jay
>>>>>
>>>>
>>>
>>
>
 		 	   		  

From mika at async.async.caltech.edu  Wed Jun  2 17:32:20 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Wed, 02 Jun 2010 08:32:20 -0700
Subject: [M3devel] warning for uninitialized variables?
In-Reply-To: <COL101-W40BE08A256108863A44C5FE6D00@phx.gbl> 
Message-ID: <20100602153220.A4A041A209D@async.async.caltech.edu>

Jay K writes:
>
>Well=2C I'm certainly not lobbying hard for that=2C presumably there is no =
>efficient implementation=2C esp. for full range integers.
>
>Wikipedia has a nice article. "nice" means "agrees with me".
>
>
>http://en.wikipedia.org/wiki/Uninitialized_variable
>"it is a programming error and a common source of bugs in software."

I don't think anyone disagrees too strongly with that, Jay, but
the question is what can be done about it.  I think the sad answer
is, "not much."

>
>
>And then they point out how Java requires mechanically verified initializat=
>ion of locals.

One might equally well say that an infinite loop is a programming error
and a common source of bugs in software.

Some good people, accordingly, insist that every loop be accompanied by
a proof of termination.

The difference is, of course, that it is obvious that there are
useful loops that we cannot ever expect a compiler to be able to prove
termination of (on its own), whereas "some people feel" that there are
no useful ways of initializing variables that could not be verified
correct by a particular implementation of the Java compiler.

I think that if you take a step back from the problems you will see
they are in fact the same problem: they both breach the "undecidability
barrier".  This is because we haven't put enough information in the
variable declarations themselves to deduce what is wanted.  EWD's chapter
is a start on that---how to do this statically.  (That's the last time
I'm going to plug that chapter, I promise.) 

Modula-3 actually has some very nice mechanisms for avoiding uninitialized
variables.  The ability to declare/initialize a variable from an
expression without providing an explicit type is one.  WITH is another.
I almost never have problems with uninitialized variables in my Modula-3
programs.  Almost...

    Mika


From mika at async.async.caltech.edu  Wed Jun  2 17:37:04 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Wed, 02 Jun 2010 08:37:04 -0700
Subject: [M3devel] ADR is *too* unsafe..
In-Reply-To: <COL101-W259EC30CD3362F448A983DE6D00@phx.gbl> 
References: <COL101-W617B9602E6CAA0BBE5BE25E6D00@phx.gbl>, ,
	<A8CEEB02-D279-4C90-B8D3-5D163619C748@cs.purdue.edu>,
	<COL101-W444318DF7FE046C2AE542AE6D00@phx.gbl>,
	<67147BA0-0307-45FB-B646-588B55EDACC3@cs.purdue.edu>,
	<833AEC0D-7CAD-4E2E-A99D-C12F5C0DD870@cs.purdue.edu>
	<COL101-W259EC30CD3362F448A983DE6D00@phx.gbl>
Message-ID: <20100602153704.7645A1A209F@async.async.caltech.edu>

Jay K writes:
>
>Cool.
>
>=A0> but also modified the front-end of the compiler to generate C
>header files for Modula-3 interface files.
>=A0> This way=2C procedures exported via a
>Modula-3 interface can be called directly from C using "module dot method"
>syntax
>
>
>I've been wanting that. :)

What do you want it to do?

My Modula-Scheme system does this for Scheme already.. in fact it's
probably doing something even more complicated than what you want... hmm.
I've been meaning to check it in somewhere for a long time.

     Mika

>
>=A0> "CVAR"
>
>Sounds like a good small change?
>
>=A0- Jay
>
>
...


From jay.krell at cornell.edu  Wed Jun  2 17:42:41 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 2 Jun 2010 15:42:41 +0000
Subject: [M3devel] warning for uninitialized variables?
In-Reply-To: <20100602153220.A4A041A209D@async.async.caltech.edu>
References: <COL101-W40BE08A256108863A44C5FE6D00@phx.gbl>
	,<20100602153220.A4A041A209D@async.async.caltech.edu>
Message-ID: <COL101-W5218B47FE71F77410C9668E6D00@phx.gbl>


I've looked but can't quite find the paper. I found its "number".
Modula-3 ... I think beats C, because I can specify initializers for records, and subranges and enums are initialized.
C++ is more general and nice though since I can specificy initialization functions for types. Not as unenforced convention as in Modula-3, but enforced because the compiler makes the calls. Though Modula-3 does at least have the compiler generally do some initialization.


"what to do about it", well, compilers these days can tell us.
I/we have to go through the warnings that my upcoming change generate. A fair number.
But I/we should wait until I also have fault_proc marked as "noreturn", since that should help reduce them.
And maybe maybe even add <* noreturn *> pragma or such, since I know there cases like:
? (possibly the front end figures it out by seeing what you call, but still need to communicate it down)


if x = 0
? i = 0
else if x = 1
? i = 2
else if x = 2
? i = 4
else
? error(); (* probably noreturn *)
print i (* compiler complains it might be uninitialized, from the error case *)


?- Jay


----------------------------------------
> To: jay.krell at cornell.edu
> Date: Wed, 2 Jun 2010 08:32:20 -0700
> From: mika at async.async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] warning for uninitialized variables?
>
> Jay K writes:
>>
>>Well=2C I'm certainly not lobbying hard for that=2C presumably there is no =
>>efficient implementation=2C esp. for full range integers.
>>
>>Wikipedia has a nice article. "nice" means "agrees with me".
>>
>>
>>http://en.wikipedia.org/wiki/Uninitialized_variable
>>"it is a programming error and a common source of bugs in software."
>
> I don't think anyone disagrees too strongly with that, Jay, but
> the question is what can be done about it. I think the sad answer
> is, "not much."
>
>>
>>
>>And then they point out how Java requires mechanically verified initializat=
>>ion of locals.
>
> One might equally well say that an infinite loop is a programming error
> and a common source of bugs in software.
>
> Some good people, accordingly, insist that every loop be accompanied by
> a proof of termination.
>
> The difference is, of course, that it is obvious that there are
> useful loops that we cannot ever expect a compiler to be able to prove
> termination of (on its own), whereas "some people feel" that there are
> no useful ways of initializing variables that could not be verified
> correct by a particular implementation of the Java compiler.
>
> I think that if you take a step back from the problems you will see
> they are in fact the same problem: they both breach the "undecidability
> barrier". This is because we haven't put enough information in the
> variable declarations themselves to deduce what is wanted. EWD's chapter
> is a start on that---how to do this statically. (That's the last time
> I'm going to plug that chapter, I promise.)
>
> Modula-3 actually has some very nice mechanisms for avoiding uninitialized
> variables. The ability to declare/initialize a variable from an
> expression without providing an explicit type is one. WITH is another.
> I almost never have problems with uninitialized variables in my Modula-3
> programs. Almost...
>
> Mika
 		 	   		  

From jay.krell at cornell.edu  Wed Jun  2 17:48:56 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 2 Jun 2010 15:48:56 +0000
Subject: [M3devel] ADR is *too* unsafe..
In-Reply-To: <20100602153704.7645A1A209F@async.async.caltech.edu>
References: <COL101-W617B9602E6CAA0BBE5BE25E6D00@phx.gbl>, ,
	<A8CEEB02-D279-4C90-B8D3-5D163619C748@cs.purdue.edu>,
	<COL101-W444318DF7FE046C2AE542AE6D00@phx.gbl>,
	<67147BA0-0307-45FB-B646-588B55EDACC3@cs.purdue.edu>,
	<833AEC0D-7CAD-4E2E-A99D-C12F5C0DD870@cs.purdue.edu>
	<COL101-W259EC30CD3362F448A983DE6D00@phx.gbl>,
	<20100602153704.7645A1A209F@async.async.caltech.edu>
Message-ID: <COL101-W3271AE47A4F3E15973FAB3E6D00@phx.gbl>


for example:

/dev2/cm3/m3-libs/m3core/src/unix/Common/Ustat.i3

TYPE
? struct_stat = RECORD
(*
This MUST match UstatC.c.

Sorted by size, then by name; make everything LONGINT if possible, else INTEGER;
Limit on LONGINT is compatibility with existing Modula-3 code. Blowing up the sizes
larger than necessary is a slight deoptimization for the sake of simplicity and
commonality. *)
??? st_dev?? : LONGINT; (* Utypes.dev_t?? *)
??? st_ino?? : LONGINT; (* Utypes.ino_t?? *)
??? st_mtime : LONGINT; (* not time_t???? *)
??? st_nlink : LONGINT; (* Utypes.nlink_t *)
??? st_rdev? : LONGINT; (* Utypes.dev_t?? *)
??? st_size? : LONGINT; (* Utypes.off_t?? *)
??? st_flags : INTEGER; (* only on some platforms: Darwin, FreeBSD, OpenBSD, NetBSD, else 0 *)
??? st_gid?? : INTEGER; (* Utypes.gid_t?? *)
??? st_mode? : INTEGER; (* Utypes.mode_t? *)
??? st_uid?? : INTEGER; (* Utypes.uid_t?? *)
? END;
? struct_stat_star = UNTRACED REF struct_stat;


/dev2/cm3/m3-libs/m3core/src/unix/Common/UstatC.c 

struct _m3_stat_t
{
/*
This MUST match Ustat.i3.

Sorted by size, then by name; make everything LONGINT if possible, else INTEGER;
Limit on LONGINT is compatibility with existing Modula-3 code. Blowing up the sizes
larger than necessary is a slight deoptimization for the sake of simplicity and
commonality.
??? 
"st_" prefix is omitted from the names in case they are macros, which does happen */

??? LONGINT dev;
??? LONGINT ino;
??? LONGINT mtime;
??? LONGINT nlink;
??? LONGINT rdev;
??? LONGINT size;
??? INTEGER flags;
??? INTEGER gid;
??? INTEGER mode;
??? INTEGER uid;
};


We used to clone headers through careful reading of multiple platform-specified #ifdefed-to-heck headers.
Now we clone them through easier reading of simple platform-independent #ifdef-free headers.
This is progress, it is easier for programmer to get it right and eyeball it and believe it is right.


But what should actually happen is compiler should generate Ustat.h from Ustat.i3.
The only mechanical duplicate that should occur, should be done by programs.
Comments that say "must match" are the signature of a compromise, that I made.


Similarly but less obviously how, Uconstants.c should be generated.
Given a list of symbols, the C code should just #ifdef foo const bar__foo = foo #endif tc.


Such generation should happen every time one builds.
?Not just once and check them in and hope they stay current (as many folks are prone to, not necessarily present company)


?- Jay

----------------------------------------
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] ADR is *too* unsafe..
> Date: Wed, 2 Jun 2010 08:37:04 -0700
> From: mika at async.async.caltech.edu
>
> Jay K writes:
>>
>>Cool.
>>
>>=A0> but also modified the front-end of the compiler to generate C
>>header files for Modula-3 interface files.
>>=A0> This way=2C procedures exported via a
>>Modula-3 interface can be called directly from C using "module dot method"
>>syntax
>>
>>
>>I've been wanting that. :)
>
> What do you want it to do?
>
> My Modula-Scheme system does this for Scheme already.. in fact it's
> probably doing something even more complicated than what you want... hmm.
> I've been meaning to check it in somewhere for a long time.
>
> Mika
>
>>
>>=A0> "CVAR"
>>
>>Sounds like a good small change?
>>
>>=A0- Jay
>>
>>
> ...
 		 	   		  

From mika at async.async.caltech.edu  Wed Jun  2 18:08:11 2010
From: mika at async.async.caltech.edu (Mika Nystrom)
Date: Wed, 02 Jun 2010 09:08:11 -0700
Subject: [M3devel] ADR is *too* unsafe..
In-Reply-To: <COL101-W3271AE47A4F3E15973FAB3E6D00@phx.gbl> 
References: <COL101-W617B9602E6CAA0BBE5BE25E6D00@phx.gbl>, ,
	<A8CEEB02-D279-4C90-B8D3-5D163619C748@cs.purdue.edu>,
	<COL101-W444318DF7FE046C2AE542AE6D00@phx.gbl>,
	<67147BA0-0307-45FB-B646-588B55EDACC3@cs.purdue.edu>,
	<833AEC0D-7CAD-4E2E-A99D-C12F5C0DD870@cs.purdue.edu>
	<COL101-W259EC30CD3362F448A983DE6D00@phx.gbl>,
	<20100602153704.7645A1A209F@async.async.caltech.edu>
	<COL101-W3271AE47A4F3E15973FAB3E6D00@phx.gbl>
Message-ID: <20100602160811.9FCE71A209C@async.async.caltech.edu>


That shouldn't be hard, provided you're willing to write some
Scheme code :-)

     Mika

Jay K writes:
>
>for example:
>
>/dev2/cm3/m3-libs/m3core/src/unix/Common/Ustat.i3
>
>TYPE
>=A0 struct_stat =3D RECORD
>(*
>This MUST match UstatC.c.
>
>Sorted by size=2C then by name=3B make everything LONGINT if possible=2C el=
>se INTEGER=3B
>Limit on LONGINT is compatibility with existing Modula-3 code. Blowing up t=
>he sizes
>larger than necessary is a slight deoptimization for the sake of simplicity=
> and
>commonality. *)
>=A0=A0=A0 st_dev=A0=A0 : LONGINT=3B (* Utypes.dev_t=A0=A0 *)
>=A0=A0=A0 st_ino=A0=A0 : LONGINT=3B (* Utypes.ino_t=A0=A0 *)
>=A0=A0=A0 st_mtime : LONGINT=3B (* not time_t=A0=A0=A0=A0 *)
>=A0=A0=A0 st_nlink : LONGINT=3B (* Utypes.nlink_t *)
>=A0=A0=A0 st_rdev=A0 : LONGINT=3B (* Utypes.dev_t=A0=A0 *)
>=A0=A0=A0 st_size=A0 : LONGINT=3B (* Utypes.off_t=A0=A0 *)
>=A0=A0=A0 st_flags : INTEGER=3B (* only on some platforms: Darwin=2C FreeBS=
>D=2C OpenBSD=2C NetBSD=2C else 0 *)
>=A0=A0=A0 st_gid=A0=A0 : INTEGER=3B (* Utypes.gid_t=A0=A0 *)
>=A0=A0=A0 st_mode=A0 : INTEGER=3B (* Utypes.mode_t=A0 *)
>=A0=A0=A0 st_uid=A0=A0 : INTEGER=3B (* Utypes.uid_t=A0=A0 *)
>=A0 END=3B
>=A0 struct_stat_star =3D UNTRACED REF struct_stat=3B
>
>
>/dev2/cm3/m3-libs/m3core/src/unix/Common/UstatC.c=20
>
>struct _m3_stat_t
>{
>/*
>This MUST match Ustat.i3.
>
>Sorted by size=2C then by name=3B make everything LONGINT if possible=2C el=
>se INTEGER=3B
>Limit on LONGINT is compatibility with existing Modula-3 code. Blowing up t=
>he sizes
>larger than necessary is a slight deoptimization for the sake of simplicity=
> and
>commonality.
>=A0=A0=A0=20
>"st_" prefix is omitted from the names in case they are macros=2C which doe=
>s happen */
>
>=A0=A0=A0 LONGINT dev=3B
>=A0=A0=A0 LONGINT ino=3B
>=A0=A0=A0 LONGINT mtime=3B
>=A0=A0=A0 LONGINT nlink=3B
>=A0=A0=A0 LONGINT rdev=3B
>=A0=A0=A0 LONGINT size=3B
>=A0=A0=A0 INTEGER flags=3B
>=A0=A0=A0 INTEGER gid=3B
>=A0=A0=A0 INTEGER mode=3B
>=A0=A0=A0 INTEGER uid=3B
>}=3B
>
>
>We used to clone headers through careful reading of multiple platform-speci=
>fied #ifdefed-to-heck headers.
>Now we clone them through easier reading of simple platform-independent #if=
>def-free headers.
>This is progress=2C it is easier for programmer to get it right and eyeball=
> it and believe it is right.
>
>
>But what should actually happen is compiler should generate Ustat.h from Us=
>tat.i3.
>The only mechanical duplicate that should occur=2C should be done by progra=
>ms.
>Comments that say "must match" are the signature of a compromise=2C that I =
>made.
>
>
>Similarly but less obviously how=2C Uconstants.c should be generated.
>Given a list of symbols=2C the C code should just #ifdef foo const bar__foo=
> =3D foo #endif tc.
>
>
>Such generation should happen every time one builds.
>=A0Not just once and check them in and hope they stay current (as many folk=
>s are prone to=2C not necessarily present company)
>
>
>=A0- Jay
>
>----------------------------------------
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] ADR is *too* unsafe..
>> Date: Wed=2C 2 Jun 2010 08:37:04 -0700
>> From: mika at async.async.caltech.edu
>>
>> Jay K writes:
>>>
>>>Cool.
>>>
>>>=3DA0> but also modified the front-end of the compiler to generate C
>>>header files for Modula-3 interface files.
>>>=3DA0> This way=3D2C procedures exported via a
>>>Modula-3 interface can be called directly from C using "module dot method=
>"
>>>syntax
>>>
>>>
>>>I've been wanting that. :)
>>
>> What do you want it to do?
>>
>> My Modula-Scheme system does this for Scheme already.. in fact it's
>> probably doing something even more complicated than what you want... hmm.
>> I've been meaning to check it in somewhere for a long time.
>>
>> Mika
>>
>>>
>>>=3DA0> "CVAR"
>>>
>>>Sounds like a good small change?
>>>
>>>=3DA0- Jay
>>>
>>>
>> ...
> 		 	   		  =


From jay.krell at cornell.edu  Wed Jun  2 18:54:45 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 2 Jun 2010 16:54:45 +0000
Subject: [M3devel] ADR is *too* unsafe..
In-Reply-To: <20100602160811.9FCE71A209C@async.async.caltech.edu>
References: <COL101-W617B9602E6CAA0BBE5BE25E6D00@phx.gbl>, ,
	<A8CEEB02-D279-4C90-B8D3-5D163619C748@cs.purdue.edu>,
	<COL101-W444318DF7FE046C2AE542AE6D00@phx.gbl>,
	<67147BA0-0307-45FB-B646-588B55EDACC3@cs.purdue.edu>,
	<833AEC0D-7CAD-4E2E-A99D-C12F5C0DD870@cs.purdue.edu>
	<COL101-W259EC30CD3362F448A983DE6D00@phx.gbl>,
	<20100602153704.7645A1A209F@async.async.caltech.edu>
	<COL101-W3271AE47A4F3E15973FAB3E6D00@phx.gbl>,
	<20100602160811.9FCE71A209C@async.async.caltech.edu>
Message-ID: <COL101-W2141AC09F05E54A393E48BE6D00@phx.gbl>


As long as I describe the interface just once, and you then spit out both .i3 and .h, and
they are pretty much "guaranteed to match", ok.
(Or maybe it can interface with the Modula-3 compiler at a lower level in-memory, instead
of out to text and then parsed back into something else; I have no similar hope for C..)

?- Jay


----------------------------------------
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] ADR is *too* unsafe..
> Date: Wed, 2 Jun 2010 09:08:11 -0700
> From: mika at async.async.caltech.edu
>
>
> That shouldn't be hard, provided you're willing to write some
> Scheme code :-)
>
> Mika
>
> Jay K writes:
>>
>>for example:
>>
>>/dev2/cm3/m3-libs/m3core/src/unix/Common/Ustat.i3
>>
>>TYPE
>>=A0 struct_stat =3D RECORD
>>(*
>>This MUST match UstatC.c.
>>
>>Sorted by size=2C then by name=3B make everything LONGINT if possible=2C el=
>>se INTEGER=3B
>>Limit on LONGINT is compatibility with existing Modula-3 code. Blowing up t=
>>he sizes
>>larger than necessary is a slight deoptimization for the sake of simplicity=
>> and
>>commonality. *)
>>=A0=A0=A0 st_dev=A0=A0 : LONGINT=3B (* Utypes.dev_t=A0=A0 *)
>>=A0=A0=A0 st_ino=A0=A0 : LONGINT=3B (* Utypes.ino_t=A0=A0 *)
>>=A0=A0=A0 st_mtime : LONGINT=3B (* not time_t=A0=A0=A0=A0 *)
>>=A0=A0=A0 st_nlink : LONGINT=3B (* Utypes.nlink_t *)
>>=A0=A0=A0 st_rdev=A0 : LONGINT=3B (* Utypes.dev_t=A0=A0 *)
>>=A0=A0=A0 st_size=A0 : LONGINT=3B (* Utypes.off_t=A0=A0 *)
>>=A0=A0=A0 st_flags : INTEGER=3B (* only on some platforms: Darwin=2C FreeBS=
>>D=2C OpenBSD=2C NetBSD=2C else 0 *)
>>=A0=A0=A0 st_gid=A0=A0 : INTEGER=3B (* Utypes.gid_t=A0=A0 *)
>>=A0=A0=A0 st_mode=A0 : INTEGER=3B (* Utypes.mode_t=A0 *)
>>=A0=A0=A0 st_uid=A0=A0 : INTEGER=3B (* Utypes.uid_t=A0=A0 *)
>>=A0 END=3B
>>=A0 struct_stat_star =3D UNTRACED REF struct_stat=3B
>>
>>
>>/dev2/cm3/m3-libs/m3core/src/unix/Common/UstatC.c=20
>>
>>struct _m3_stat_t
>>{
>>/*
>>This MUST match Ustat.i3.
>>
>>Sorted by size=2C then by name=3B make everything LONGINT if possible=2C el=
>>se INTEGER=3B
>>Limit on LONGINT is compatibility with existing Modula-3 code. Blowing up t=
>>he sizes
>>larger than necessary is a slight deoptimization for the sake of simplicity=
>> and
>>commonality.
>>=A0=A0=A0=20
>>"st_" prefix is omitted from the names in case they are macros=2C which doe=
>>s happen */
>>
>>=A0=A0=A0 LONGINT dev=3B
>>=A0=A0=A0 LONGINT ino=3B
>>=A0=A0=A0 LONGINT mtime=3B
>>=A0=A0=A0 LONGINT nlink=3B
>>=A0=A0=A0 LONGINT rdev=3B
>>=A0=A0=A0 LONGINT size=3B
>>=A0=A0=A0 INTEGER flags=3B
>>=A0=A0=A0 INTEGER gid=3B
>>=A0=A0=A0 INTEGER mode=3B
>>=A0=A0=A0 INTEGER uid=3B
>>}=3B
>>
>>
>>We used to clone headers through careful reading of multiple platform-speci=
>>fied #ifdefed-to-heck headers.
>>Now we clone them through easier reading of simple platform-independent #if=
>>def-free headers.
>>This is progress=2C it is easier for programmer to get it right and eyeball=
>> it and believe it is right.
>>
>>
>>But what should actually happen is compiler should generate Ustat.h from Us=
>>tat.i3.
>>The only mechanical duplicate that should occur=2C should be done by progra=
>>ms.
>>Comments that say "must match" are the signature of a compromise=2C that I =
>>made.
>>
>>
>>Similarly but less obviously how=2C Uconstants.c should be generated.
>>Given a list of symbols=2C the C code should just #ifdef foo const bar__foo=
>> =3D foo #endif tc.
>>
>>
>>Such generation should happen every time one builds.
>>=A0Not just once and check them in and hope they stay current (as many folk=
>>s are prone to=2C not necessarily present company)
>>
>>
>>=A0- Jay
>>
>>----------------------------------------
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] ADR is *too* unsafe..
>>> Date: Wed=2C 2 Jun 2010 08:37:04 -0700
>>> From: mika at async.async.caltech.edu
>>>
>>> Jay K writes:
>>>>
>>>>Cool.
>>>>
>>>>=3DA0> but also modified the front-end of the compiler to generate C
>>>>header files for Modula-3 interface files.
>>>>=3DA0> This way=3D2C procedures exported via a
>>>>Modula-3 interface can be called directly from C using "module dot method=
>>"
>>>>syntax
>>>>
>>>>
>>>>I've been wanting that. :)
>>>
>>> What do you want it to do?
>>>
>>> My Modula-Scheme system does this for Scheme already.. in fact it's
>>> probably doing something even more complicated than what you want... hmm.
>>> I've been meaning to check it in somewhere for a long time.
>>>
>>> Mika
>>>
>>>>
>>>>=3DA0> "CVAR"
>>>>
>>>>Sounds like a good small change?
>>>>
>>>>=3DA0- Jay
>>>>
>>>>
>>> ...
>> =
 		 	   		  

From hendrik at topoi.pooq.com  Fri Jun  4 01:30:22 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Thu, 3 Jun 2010 19:30:22 -0400
Subject: [M3devel] warning for uninitialized variables?
In-Reply-To: <COL101-W59770EAA64E52A966D79F3E6D00@phx.gbl>
References: <20100602035226.43C1F1A208F@async.async.caltech.edu>
	<COL101-W59770EAA64E52A966D79F3E6D00@phx.gbl>
Message-ID: <20100603233021.GA11727@topoi.pooq.com>

On Wed, Jun 02, 2010 at 04:50:28AM +0000, Jay K wrote:
> 
> Wow. You really surprise me Mika.
> 
> 
> To warn on this kind of thing, to me, there is no question.
> 
> 
> Limting the affects by virtue of being safe isn't much consolation.
> The program can easily go down a "safe" but very incorrect path.
> 
> 
> There are several forms.
> In fact, sometimes the compiler says something "is" used uninitialized.
> Sometimes it says "maybe".
> 
> 
> In your example, generally, once the address is taken of a variable,
> the compiler gives up. Esp. if that address is passed to a function it doesn't "see".
> 
> 
> However compilers are getting better.
> Windows headers are now annotated with "in" and "out", etc. with
> a calculus behind them, not just informal human definitions.
> 
> 
> So if you pass something by pointer to "in" you should a warning/error.
> If it is "out", ok.
> 
> 
> The annotations can even be checked, if you write to something that is "in"
> you should get a warning/error.
> 
> 
> There are many more warnings in the tree than I have yet looked at.
> I've seen a few forms.
> Some are because the compiler doesn't know that some functions don't return.
> I'll see about improving that. Though I think there's a limit to how good I can manage,
> unless we add a <* noreturn *> pragma.

Or a new type that has *no* values at all, and therefore can never be 
returned by anything.  If it'e the type of an expression, that 
expression can never return a value.

Notice, that if you were to let statements have a type (Algol 68 does, 
calling it the VOID type) that type would *not* be the type with no 
values at all.  The VOID type has one value, and needs log(1) = 0 bits 
to store it.

The NORETURN type would have no values, is never stored.  log(0) doesn't 
give a meaningful numper of bits, which is right.

> 
> I grant that by initializing to 0, I haven't necessarily made the code correct either.
> But at least it is now consistent.

It's very useful for code execution to ne repeatable.

> 
> 
> Even better would be runtime checks that stop if a variable is read 
> before written.

Takes extra storage, unless there are bit patterns that are known to fit 
in the available space *and* be invalid values for the type.

> 
> 
> Uninitialized values can be different run to run.
> Repeatability and consistency are important.

*VERY*

> I'm also nervous about us not taking a hard line on integer overflow.
> Overflown math doesn't necessarily lead to array out of bounds soon or ever.
> It too can lead to incorrect but safe behavior.

I agree.  But I do need a way to turn it off for specific operations so 
I get modulo results.  Perhaps also a specific type for wrap-around 
arithmetic?

-- hendrik



From hendrik at topoi.pooq.com  Fri Jun  4 01:36:14 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Thu, 3 Jun 2010 19:36:14 -0400
Subject: [M3devel] warning for uninitialized variables?
In-Reply-To: <20100602124422.11C6D1A209A@async.async.caltech.edu>
References: <20100602035226.43C1F1A208F@async.async.caltech.edu>
	<COL101-W59770EAA64E52A966D79F3E6D00@phx.gbl>
	<20100602124422.11C6D1A209A@async.async.caltech.edu>
Message-ID: <20100603233614.GB11727@topoi.pooq.com>

On Wed, Jun 02, 2010 at 05:44:22AM -0700, Mika Nystrom wrote:
> Jay K writes:
> >
> >Limting the affects by virtue of being safe isn't much consolation.
> >The program can easily go down a "safe" but very incorrect path.
> 
> It is, though!  Do you always know what value to initialize the
> variables to?  If not, you're just picking some value to shut up
> the compiler, and now your code no longer expresses---to a human
> reader---that x is uninitialized.

Not initializing it because thats your intent is OK in the cource code.
But letting the compiler initialize it to some or other value in a 
consistent manner gives the consistency that makes your code more 
rerunnable therefore more debuggable. 

> 
> Remember, code is mainly written for humans!  Computers don't care
> about fancy structuring, declarations, etc.  When you write a program,
> you write it to be read by a human.  The fact that a variable is
> uninitialized is a part of the design of the program.
> 
> It's an unfortunate fact that our languages don't have all the 
> mechanisms necessary to deal properly with uninitialized variables.
> Retrofitting mechanisms to something that just isn't expressive
> enough to solve the problem I really don't think is the way to go.

That's why I like to declare variables at the very point they are 
initialized.  If they are in scope, they are OK.  (Actually, there are 
still a very few cases where you want to declare a variable other than 
where it's initialized.  But that's quite rare).

But Modula 3 has chosen a different path, and I don't think this is 
really retrofittable.

-- hendrik


From hendrik at topoi.pooq.com  Fri Jun  4 01:41:02 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Thu, 3 Jun 2010 19:41:02 -0400
Subject: [M3devel] warning for uninitialized variables?
In-Reply-To: <COL101-W5343011FD0FA7BCC8C42AEE6D00@phx.gbl>
References: <20100602035226.43C1F1A208F@async.async.caltech.edu>
	<20100602124422.11C6D1A209A@async.async.caltech.edu>
	<COL101-W5343011FD0FA7BCC8C42AEE6D00@phx.gbl>
Message-ID: <20100603234102.GC11727@topoi.pooq.com>

On Wed, Jun 02, 2010 at 12:59:45PM +0000, Jay K wrote:
> 
> I grant that an immediate runtime error upon reading an unwritten value is ideal.

One of the variables in a cryptographic-quality random number generator 
was uninitialized.  Someone in Debian "fixed" that.  The random number 
generator was n longer of cryptographic quality.  It turns out is was 
relying on the variable being garbage.

So we still need to be able to use uninitialized stuff..  But not by 
accident.

> But absent that possibility, I want something consistent.
> Heck, here's a crazy idea: reserve the current FIRST(INTEGER) as 
> "invalid", initialize locals to it, any read (or generation/write) of 
> that value trigger a runtime error.
> CARDINAL could work this way more easily since it has many values to spare.

And if instead of a load, your machine had a load absolute value, a 
hardware overflow trap could catch the error at no additional run time.
That's a hack I planned to use for a NULL check on an IBM 360 long long 
ago.

-- hendrik


From hendrik at topoi.pooq.com  Fri Jun  4 01:51:03 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Thu, 3 Jun 2010 19:51:03 -0400
Subject: [M3devel] warning for uninitialized variables?
In-Reply-To: <COL101-W44444F6A175254747767CFE6D00@phx.gbl>
References: <16413179-F84C-42BF-AB09-2D8294EB4782@cs.purdue.edu>
	<COL101-W44444F6A175254747767CFE6D00@phx.gbl>
Message-ID: <20100603235102.GD11727@topoi.pooq.com>

On Wed, Jun 02, 2010 at 02:52:55PM +0000, Jay K wrote:
> 
> Running with a consistent initialized/uninitialized 0 is better than running with a "random" value that you get from no initialization.
> ?They are both "bad".
> ?The 0 is agreed misleading, because it might look initialized.
> ? But it still better than a value that can change from run to run.

Initializing it to cosistent gibberish won't look as initialized.  The 
University of Waterloo WATFOR compiler initialized all of memory to a 
consistent bit pattern that was *not* a printable character in the 
character set, and was *not* a valid exponent for a floating-point 
number.  It was a valid integer, though.  That much was OK, and would 
provide consistency with a high probability of misbehaviour on error.

But they went further and regularly checked for that value on reads.  It 
took time, it found errors, and it was a rare day that anyone needed 
that value.  But it did happen, and I consider the test a mistake for 
types that an validly assume all bit patterns.
> 
> Programs are written for humans to read, true, but programs that read programs are much more diligent, energetic, and often smarter (and slowly getting smarter with age, often the opposite of humans).
> Compilers really do have a big "leg" up on humans, since they can harness fast digital processor with big storage.
> Granted, neither is always better than the other. But compilers/computers have far more capacity for code reading than humans and I know from experience that most code is never read by a human, not even once, until I get to it :), because the bugs I readily see wouldn't survive even a glance...
> ?(and the compilers often fail too, granted).
> 
> 
> Again I'm quite surprised we want to leave uninitialized variables 
> that get used uninitialized.  The one in cm3ide for example, if the 
> input is malformed, I believe it uses uninitialized data.
> I don't see how this can be deemed anything other than a bug to be 
> fixed, and that we should be glad the compiler (finally) found it..now 
> that I'm working on removing the rampant volatile...
> 
> 
> If we can invest in runtime checks to immediately catch reads of 
> unwritten data, then I'd favor that instead.

The hard part is distinguishing the truly uninitialized variable from a 
variable that pappens to validly get assigned a computed bit pattern 
that just happens to be the marker for "uninitialized".

But being able to turn on such a run-time check during debugging might 
make it wasier to find a *lot* of uninitialized variables, with only anb 
occasional false positive.

-- hendrik


From jay.krell at cornell.edu  Fri Jun  4 01:47:00 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 3 Jun 2010 23:47:00 +0000
Subject: [M3devel] warning for uninitialized variables?
In-Reply-To: <20100603233614.GB11727@topoi.pooq.com>
References: <20100602035226.43C1F1A208F@async.async.caltech.edu>,
	<COL101-W59770EAA64E52A966D79F3E6D00@phx.gbl>,
	<20100602124422.11C6D1A209A@async.async.caltech.edu>,
	<20100603233614.GB11727@topoi.pooq.com>
Message-ID: <COL101-W2394F109BD07DCB14C61EBE6D10@phx.gbl>


Declare at initialization is good.
  Exactly what C++ supports and it is considered completely uncontroversial and maybe C9x even supports it.
 
 
Modula-3 supports it, both with "WITH..DO" and "VAR..BEGIN" but at too high a syntactic cost -- having to indent for each new block of variables, or to use begin/end without indenting.
 
 
Heck, C supports the same thing -- you can introduce braces anywhere, and then variables after any left brace.
 
 
I would rather move all my variables to the top of the function and initialize them with 0 than to indent every time I want a new variable. Really. I have learned to accept much about Modula-3's syntax, but not this.
 
 
 
 - Jay


----------------------------------------
> Date: Thu, 3 Jun 2010 19:36:14 -0400
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] warning for uninitialized variables?
>
> On Wed, Jun 02, 2010 at 05:44:22AM -0700, Mika Nystrom wrote:
>> Jay K writes:
>>>
>>>Limting the affects by virtue of being safe isn't much consolation.
>>>The program can easily go down a "safe" but very incorrect path.
>>
>> It is, though! Do you always know what value to initialize the
>> variables to? If not, you're just picking some value to shut up
>> the compiler, and now your code no longer expresses---to a human
>> reader---that x is uninitialized.
>
> Not initializing it because thats your intent is OK in the cource code.
> But letting the compiler initialize it to some or other value in a
> consistent manner gives the consistency that makes your code more
> rerunnable therefore more debuggable.
>
>>
>> Remember, code is mainly written for humans! Computers don't care
>> about fancy structuring, declarations, etc. When you write a program,
>> you write it to be read by a human. The fact that a variable is
>> uninitialized is a part of the design of the program.
>>
>> It's an unfortunate fact that our languages don't have all the
>> mechanisms necessary to deal properly with uninitialized variables.
>> Retrofitting mechanisms to something that just isn't expressive
>> enough to solve the problem I really don't think is the way to go.
>
> That's why I like to declare variables at the very point they are
> initialized. If they are in scope, they are OK. (Actually, there are
> still a very few cases where you want to declare a variable other than
> where it's initialized. But that's quite rare).
>
> But Modula 3 has chosen a different path, and I don't think this is
> really retrofittable.
>
> -- hendrik 		 	   		  

From hendrik at topoi.pooq.com  Fri Jun  4 01:54:55 2010
From: hendrik at topoi.pooq.com (hendrik at topoi.pooq.com)
Date: Thu, 3 Jun 2010 19:54:55 -0400
Subject: [M3devel] warning for uninitialized variables?
In-Reply-To: <COL101-W40BE08A256108863A44C5FE6D00@phx.gbl>
References: <5EDDD7E5-C33E-4BD1-A036-2D3561F08277@cs.purdue.edu>
	<COL101-W40BE08A256108863A44C5FE6D00@phx.gbl>
Message-ID: <20100603235455.GE11727@topoi.pooq.com>

On Wed, Jun 02, 2010 at 03:13:55PM +0000, Jay K wrote:
> 
> Well, I'm certainly not lobbying hard for that, presumably there is no efficient implementation, esp. for full range integers.
> 
> Wikipedia has a nice article. "nice" means "agrees with me".
> 
> 
> http://en.wikipedia.org/wiki/Uninitialized_variable
> "it is a programming error and a common source of bugs in software."
> 
> 
> And then they point out how Java requires mechanically verified initialization of locals.
> 
> The code:
> void F(bool a)
> ?int i;
> ?if (a)
> ?? i = 0;
> if (a)
> ? print(i)
> 
> 
> is I believe illegal.

But it's *not* illegal in Modula 3.  You can't prohibit it without 
making a serious language change. However much we might desire to.

-- hendrik


From jay.krell at cornell.edu  Fri Jun  4 01:59:01 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 3 Jun 2010 23:59:01 +0000
Subject: [M3devel] warning for uninitialized variables?
In-Reply-To: <20100603233021.GA11727@topoi.pooq.com>
References: <20100602035226.43C1F1A208F@async.async.caltech.edu>,
	<COL101-W59770EAA64E52A966D79F3E6D00@phx.gbl>,
	<20100603233021.GA11727@topoi.pooq.com>
Message-ID: <COL101-W62E2D97D9F353F3DACDC1AE6D10@phx.gbl>


> The NORETURN type would have no values 
 
 
Everyone else seems to do with pragma-ish things.
I don't know what is best.
Visual C++ has __declspec(noreturn).
gcc has __attribute__((noreturn)) or somesuch. Maybe it is named something else.
Visual C++ puts a breakpoint instruction after any call to a noreturn function.
abort() for example is noreturn.
 
 
 
>> I'm also nervous about us not taking a hard line on integer overflow. 
> I agree. But I do need a way to turn it off for specific operations so 
> Perhaps also a specific type for wrap-around arithmetic? 
 
 
Yes. Or a new module.
And I believe a bunch more is needed in general.
  Signed and unsigned.
  And overflow should do one:
    return an "error" code (boolean? true for success? or true for overflow? Booleans can be so ambiguous..) 
    raise an exception 
    silently wraparound 
 
 
 
I have to look into Modula-3 generics.
Ideally this can be implemented with generics and not actually writing all N combinations.
And without any "runtime switching".
 
 
For example, the generic parameters would be
  "Word"
  "Error"
 
 
 
Word would look like Word.
Except all the functions would probably return BOOLEAN to indicate overflow.
  Even if that isn't the actual "error code".
 
 
Error would expose type T that the actual implementation would return.
Oh, wait, no, Modula-3 can't do that -- there is no "VOID" type.
 
 
So..instead.. decide what the "error code" form is -- probably returning FALSE.
The Error module would expose one function, OnError.
 
 
The main code when it recieves false from "Word" would call Error.OnError.
There'd be two Error's versions. In one, OnError would do nothing. In the other, it would raise an exception.
 
 
Hm.
If Modula-3 didn't have this pesky "eval" thing, you'd be done.
Silent wraparound would be calling the "OnError donothing" form, but you'd just ignore the error.
 
 
This is unfortunate I think.
 
 
Btw, C++ folks eventually realized you need to be able to write code like this:
 
PROCEDURE F1();
 
PROCEDURE F2() = 
BEGIN
  RETURN F1();
END F1;
 
 
for reasons related to templates/generics.
You need to be able to return the result of a function you call, without knowing the return type, and the return type possibly being void. The need for this feature is obvious once you spend a few days using templates/generics.
 
 
Anyway, for silent overflow you'd have to layer over the bool version, just prepending eval.
Something like that.
 
 
The lowest level implementation probably returns bool.
 
 
The Error module could also expose a type ErrorType and some constants like OverflowError and NoError.
 
 
Maybe I'll code this up soon in pure Modula-3.
 
 
Where/who/when are the interface police?
We can add stuff to m3core or libm3 at will? As long as don't extend or change stuff in the green book?
 
 
 - Jay


----------------------------------------
> Date: Thu, 3 Jun 2010 19:30:22 -0400
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] warning for uninitialized variables?
>
> On Wed, Jun 02, 2010 at 04:50:28AM +0000, Jay K wrote:
>>
>> Wow. You really surprise me Mika.
>>
>>
>> To warn on this kind of thing, to me, there is no question.
>>
>>
>> Limting the affects by virtue of being safe isn't much consolation.
>> The program can easily go down a "safe" but very incorrect path.
>>
>>
>> There are several forms.
>> In fact, sometimes the compiler says something "is" used uninitialized.
>> Sometimes it says "maybe".
>>
>>
>> In your example, generally, once the address is taken of a variable,
>> the compiler gives up. Esp. if that address is passed to a function it doesn't "see".
>>
>>
>> However compilers are getting better.
>> Windows headers are now annotated with "in" and "out", etc. with
>> a calculus behind them, not just informal human definitions.
>>
>>
>> So if you pass something by pointer to "in" you should a warning/error.
>> If it is "out", ok.
>>
>>
>> The annotations can even be checked, if you write to something that is "in"
>> you should get a warning/error.
>>
>>
>> There are many more warnings in the tree than I have yet looked at.
>> I've seen a few forms.
>> Some are because the compiler doesn't know that some functions don't return.
>> I'll see about improving that. Though I think there's a limit to how good I can manage,
>> unless we add a <* noreturn *> pragma.
>
> Or a new type that has *no* values at all, and therefore can never be
> returned by anything. If it'e the type of an expression, that
> expression can never return a value.
>
> Notice, that if you were to let statements have a type (Algol 68 does,
> calling it the VOID type) that type would *not* be the type with no
> values at all. The VOID type has one value, and needs log(1) = 0 bits
> to store it.
>
> The NORETURN type would have no values, is never stored. log(0) doesn't
> give a meaningful numper of bits, which is right.
>
>>
>> I grant that by initializing to 0, I haven't necessarily made the code correct either.
>> But at least it is now consistent.
>
> It's very useful for code execution to ne repeatable.
>
>>
>>
>> Even better would be runtime checks that stop if a variable is read
>> before written.
>
> Takes extra storage, unless there are bit patterns that are known to fit
> in the available space *and* be invalid values for the type.
>
>>
>>
>> Uninitialized values can be different run to run.
>> Repeatability and consistency are important.
>
> *VERY*
>
>> I'm also nervous about us not taking a hard line on integer overflow.
>> Overflown math doesn't necessarily lead to array out of bounds soon or ever.
>> It too can lead to incorrect but safe behavior.
>
> I agree. But I do need a way to turn it off for specific operations so
> I get modulo results. Perhaps also a specific type for wrap-around
> arithmetic?
>
> -- hendrik
> 		 	   		  

From jay.krell at cornell.edu  Fri Jun  4 02:14:14 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 4 Jun 2010 00:14:14 +0000
Subject: [M3devel] warning for uninitialized variables?
In-Reply-To: <20100603235102.GD11727@topoi.pooq.com>
References: <16413179-F84C-42BF-AB09-2D8294EB4782@cs.purdue.edu>,
	<COL101-W44444F6A175254747767CFE6D00@phx.gbl>,
	<20100603235102.GD11727@topoi.pooq.com>
Message-ID: <COL101-W58390B33633452C34384DDE6D20@phx.gbl>


Search the web for "visual C++ /rtc".
 
You'll find that Visual C++ has the ideal feature here, not enabled by default. Not efficient.
 
If you compile with /RTCu:
  an extra byte local is created for each local variable 
  It is initialized to zero.
  Writes to the variable write 1 to the extra. (taking the address does to, the documentation spends a lot of space explaining) 
  Reads of the variable check if the extra is 0 or not and if it 0 a function is called to report the error.
 
 
It's pretty cool imho.
 
 
And it appears if the compiler can prove the variable isn't initialized, the checking is omitted.
Given decent code, that should make it very affordable to always be enabled.
 
 
 - Jay


----------------------------------------
> Date: Thu, 3 Jun 2010 19:51:03 -0400
> From: hendrik at topoi.pooq.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] warning for uninitialized variables?
>
> On Wed, Jun 02, 2010 at 02:52:55PM +0000, Jay K wrote:
>>
>> Running with a consistent initialized/uninitialized 0 is better than running with a "random" value that you get from no initialization.
>> They are both "bad".
>> The 0 is agreed misleading, because it might look initialized.
>> But it still better than a value that can change from run to run.
>
> Initializing it to cosistent gibberish won't look as initialized. The
> University of Waterloo WATFOR compiler initialized all of memory to a
> consistent bit pattern that was *not* a printable character in the
> character set, and was *not* a valid exponent for a floating-point
> number. It was a valid integer, though. That much was OK, and would
> provide consistency with a high probability of misbehaviour on error.
>
> But they went further and regularly checked for that value on reads. It
> took time, it found errors, and it was a rare day that anyone needed
> that value. But it did happen, and I consider the test a mistake for
> types that an validly assume all bit patterns.
>>
>> Programs are written for humans to read, true, but programs that read programs are much more diligent, energetic, and often smarter (and slowly getting smarter with age, often the opposite of humans).
>> Compilers really do have a big "leg" up on humans, since they can harness fast digital processor with big storage.
>> Granted, neither is always better than the other. But compilers/computers have far more capacity for code reading than humans and I know from experience that most code is never read by a human, not even once, until I get to it :), because the bugs I readily see wouldn't survive even a glance...
>> (and the compilers often fail too, granted).
>>
>>
>> Again I'm quite surprised we want to leave uninitialized variables
>> that get used uninitialized. The one in cm3ide for example, if the
>> input is malformed, I believe it uses uninitialized data.
>> I don't see how this can be deemed anything other than a bug to be
>> fixed, and that we should be glad the compiler (finally) found it..now
>> that I'm working on removing the rampant volatile...
>>
>>
>> If we can invest in runtime checks to immediately catch reads of
>> unwritten data, then I'd favor that instead.
>
> The hard part is distinguishing the truly uninitialized variable from a
> variable that pappens to validly get assigned a computed bit pattern
> that just happens to be the marker for "uninitialized".
>
> But being able to turn on such a run-time check during debugging might
> make it wasier to find a *lot* of uninitialized variables, with only anb
> occasional false positive.
>
> -- hendrik 		 	   		  

From jay.krell at cornell.edu  Fri Jun  4 18:29:34 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 4 Jun 2010 16:29:34 +0000
Subject: [M3devel] optimizer problems
Message-ID: <COL101-W915873EEE558B40A8F280E6D20@phx.gbl>


Just a note that I have found at least two pieces of code that fail to compile with optimization enabled, even in the release branch.

One is a simple case involving unused nested functions.
One is a complicated not really understood case.


To fix these I have pessimized the optimizer in the release branch but turning off two optimizations.


It would be nice to find a better fix for the first.
Even something sleazy like having the front end report up front to the backend if there are any nested functions in the unit, and only pessimizing such units.
There is probably also a fix to gcc around preserving nested functions. I thought code in varasm.c was suspicious but couldn't get it to work quickly.


The other fix seems to always involve exception handling, so something sleazy might be appropriate there -- only turn off the optimization in units that use exception handling. Longer term, we should use the gcc exception handling support if possible, even if that involves configure -enable-sjlj-exceptions (presumably not on all targets).

?- Jay


 		 	   		  

From hosking at cs.purdue.edu  Fri Jun  4 18:37:45 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 4 Jun 2010 12:37:45 -0400
Subject: [M3devel] optimizer problems
In-Reply-To: <COL101-W915873EEE558B40A8F280E6D20@phx.gbl>
References: <COL101-W915873EEE558B40A8F280E6D20@phx.gbl>
Message-ID: <282D3F06-9C5A-4525-B1D0-77E59B12D833@cs.purdue.edu>

You should be able to mark it as used.

On 4 Jun 2010, at 12:29, Jay K wrote:

> 
> Just a note that I have found at least two pieces of code that fail to compile with optimization enabled, even in the release branch.
> 
> One is a simple case involving unused nested functions.
> One is a complicated not really understood case.
> 
> 
> To fix these I have pessimized the optimizer in the release branch but turning off two optimizations.
> 
> 
> It would be nice to find a better fix for the first.
> Even something sleazy like having the front end report up front to the backend if there are any nested functions in the unit, and only pessimizing such units.
> There is probably also a fix to gcc around preserving nested functions. I thought code in varasm.c was suspicious but couldn't get it to work quickly.



From jay.krell at cornell.edu  Fri Jun  4 19:06:25 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 4 Jun 2010 17:06:25 +0000
Subject: [M3devel] optimizer problems
In-Reply-To: <282D3F06-9C5A-4525-B1D0-77E59B12D833@cs.purdue.edu>
References: <COL101-W915873EEE558B40A8F280E6D20@phx.gbl>,
	<282D3F06-9C5A-4525-B1D0-77E59B12D833@cs.purdue.edu>
Message-ID: <COL101-W5966EA54CF4DA49BC6D74E6D20@phx.gbl>


I already tried that.. :(
 
 
 - Jay


----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Fri, 4 Jun 2010 12:37:45 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] optimizer problems
>
> You should be able to mark it as used.
>
> On 4 Jun 2010, at 12:29, Jay K wrote:
>
>>
>> Just a note that I have found at least two pieces of code that fail to compile with optimization enabled, even in the release branch.
>>
>> One is a simple case involving unused nested functions.
>> One is a complicated not really understood case.
>>
>>
>> To fix these I have pessimized the optimizer in the release branch but turning off two optimizations.
>>
>>
>> It would be nice to find a better fix for the first.
>> Even something sleazy like having the front end report up front to the backend if there are any nested functions in the unit, and only pessimizing such units.
>> There is probably also a fix to gcc around preserving nested functions. I thought code in varasm.c was suspicious but couldn't get it to work quickly.
> 		 	   		  

From hosking at cs.purdue.edu  Fri Jun  4 19:56:44 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 4 Jun 2010 13:56:44 -0400
Subject: [M3devel] optimizer problems
In-Reply-To: <COL101-W5966EA54CF4DA49BC6D74E6D20@phx.gbl>
References: <COL101-W915873EEE558B40A8F280E6D20@phx.gbl>,
	<282D3F06-9C5A-4525-B1D0-77E59B12D833@cs.purdue.edu>
	<COL101-W5966EA54CF4DA49BC6D74E6D20@phx.gbl>
Message-ID: <1B0AB99B-837F-464E-9BE7-140DAEB59E5E@cs.purdue.edu>

Or "external".  I assume it is getting dead code eliminated.

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




On 4 Jun 2010, at 13:06, Jay K wrote:

> 
> I already tried that.. :(
> 
> 
> - Jay
> 
> 
> ----------------------------------------
>> From: hosking at cs.purdue.edu
>> Date: Fri, 4 Jun 2010 12:37:45 -0400
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] optimizer problems
>> 
>> You should be able to mark it as used.
>> 
>> On 4 Jun 2010, at 12:29, Jay K wrote:
>> 
>>> 
>>> Just a note that I have found at least two pieces of code that fail to compile with optimization enabled, even in the release branch.
>>> 
>>> One is a simple case involving unused nested functions.
>>> One is a complicated not really understood case.
>>> 
>>> 
>>> To fix these I have pessimized the optimizer in the release branch but turning off two optimizations.
>>> 
>>> 
>>> It would be nice to find a better fix for the first.
>>> Even something sleazy like having the front end report up front to the backend if there are any nested functions in the unit, and only pessimizing such units.
>>> There is probably also a fix to gcc around preserving nested functions. I thought code in varasm.c was suspicious but couldn't get it to work quickly.
>> 		 	   		  

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

From jay.krell at cornell.edu  Fri Jun  4 21:55:30 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 4 Jun 2010 19:55:30 +0000
Subject: [M3devel] optimizer problems
In-Reply-To: <1B0AB99B-837F-464E-9BE7-140DAEB59E5E@cs.purdue.edu>
References: <COL101-W915873EEE558B40A8F280E6D20@phx.gbl>, ,
	<282D3F06-9C5A-4525-B1D0-77E59B12D833@cs.purdue.edu>,
	<COL101-W5966EA54CF4DA49BC6D74E6D20@phx.gbl>,
	<1B0AB99B-837F-464E-9BE7-140DAEB59E5E@cs.purdue.edu>
Message-ID: <COL101-W57AFCFC65554B7DD84A092E6D20@phx.gbl>


I will experiment more.
I don't remember if I tried as much as "exported", which is clearly wrong, but it'd be interesting to see if *some* way can preserve it. Should also be easy to find the code that removes it.
 
 
 
I have more questions..not well formed..not having researched a lot..so have held off..but..like..what is it about our trees? What is it you refer to as the missing type information and the problems with alias analysis? I understand to some extent. But we do actually mostly seem to build reasonable and reasonably typed trees.
Granted, I haven't compared to C trees.
I guess using the various dump option for C trees and our trees would be good.
 
 
 
I think one place we fail is access globals, and indeed accessing structs.
We just offset from them I think, instead of accessing fields.
Is that what you mean??
 
 
For "scalar" locals and globals, our trees seem ok, right?
 
 
 
As I aid, I should just use more of the gcc dump options and compare.
 
 
TYPE T1 = RECORD a,b:INTEGER END;
 
global:T1{3,4};
 
PROCEDURE F1() =
VAR local:T1{1,2};
BEGIN
  local.a := global.b;
  globa.a := local.b;
END;
 
 
typedef struct {ptrdiff_t a,b;}T1;
T1 global = {3,4};
 
void F1()
{
  T1 local = {1,2};
  local.a = global.b;
  global.a = local.b;
}
 
 
I should probably compile each of these and dump their "generic" trees and compare?
And strive to have them match?
 
 
More importantly though is loophole and float.
 
 
TYPE T1 = RECORD a,b:int END;
TYPE T2 = RECORD a,b:float END;
 
 
global:T1{3,4};
 
 
PROCEDURE F1() =
VAR local:T2{0.0,0.0;
BEGIN
  LOOPHOLE(local, T1).a := global.b;
  LOOPHOLE(global, T2).a := local.b;
END;
 
 
typedef struct {int a,b;}T1;
typedef struct {float a,b;}T2;
T1 global = {3,4};
 
 
void F1()
{
  T2 local = {0,0};
  ((T1*)&local)->a = global.b;
  ((T2*)&global)->a = local.b;
}
 
 
stuff like that?
Get those C and Modula-3 trees to match?
 
 
I assume as part of this, if it seems "necessary" to add volatile store/load to all loophole uses,
in order to remove volatile from floats, that is probably an ok compromise.
Even when loophole is acting on non-floats.
Maybe the problem is loophole and structs though. That seems likely.
Ideally loopholing between integers and pointers doesn't require store/load, as it currently doesn't.
 
 
Again, really, though I've removed a lot of volatile, I'm still quite bothered, since I still put it on every floating point use.
 
 
The vrp/fre/pre stuff I think will be more difficult, but maybe I can figure those out.
vrp I just know results in a broken compiler. I haven't looked at it beyond that.
I guess the thing to do is compile some chunk of code, e.g. m3core, with vrp being the only variable, and see what varies, and go from there.
 
 
Given how much optimization does work now, I doubt the effort is very worthwhile on the lingering view I disabled, except, again, for unit at a time and volatile float. We'll see..
 
 
I was doing kind of dumb slow unscientific work before. There are many optimization flags and I wanted to narrow them down more than one at a time, so I'd guess, switch a few on, upgrade, if it worked proceed, if it failed, alter the guess some.
 
 
And there's still Solaris/sparc32 to do similar with..
Should be more automated but my current methods are quite tedious.. :(
 
 
 
 - Jay











________________________________
> From: hosking at cs.purdue.edu
> Date: Fri, 4 Jun 2010 13:56:44 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] optimizer problems
>
>
>
> Or "external". I assume it is getting dead code eliminated.
>
>
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Office +1 765 494 6001 | Mobile +1 765 427 5484
>
>
>
>
>
>
> On 4 Jun 2010, at 13:06, Jay K wrote:
>
>
> I already tried that.. :(
>
>
> - Jay
>
>
> ----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Fri, 4 Jun 2010 12:37:45 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] optimizer problems
>
> You should be able to mark it as used.
>
> On 4 Jun 2010, at 12:29, Jay K wrote:
>
>
> Just a note that I have found at least two pieces of code that fail to compile with optimization enabled, even in the release branch.
>
> One is a simple case involving unused nested functions.
> One is a complicated not really understood case.
>
>
> To fix these I have pessimized the optimizer in the release branch but turning off two optimizations.
>
>
> It would be nice to find a better fix for the first.
> Even something sleazy like having the front end report up front to the backend if there are any nested functions in the unit, and only pessimizing such units.
> There is probably also a fix to gcc around preserving nested functions. I thought code in varasm.c was suspicious but couldn't get it to work quickly.
>
> 		 	   		  

From jay.krell at cornell.edu  Sat Jun  5 21:23:24 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 5 Jun 2010 19:23:24 +0000
Subject: [M3devel] cvs down?
Message-ID: <COL101-W60FFAA82EE18F721A82159E6D30@phx.gbl>


My last commit didn't send mail.
cvs diff and update aren't working.

?- Jay




 		 	   		  

From jay.krell at cornell.edu  Sat Jun  5 22:52:34 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 5 Jun 2010 20:52:34 +0000
Subject: [M3devel] further removal of volatile
Message-ID: <COL101-W4299A2A8F51F83263BDF87E6D30@phx.gbl>


Tony, Currently we still put volatile on all floating point loads and/or stores.
I removed it from all the other types.
The main problem I was having is that CopySign in m3core would fail to compile.
?It is loophoing a float as a struct with bitfields I believe.
? I didn't look at what the equivalent C tree would be, though that is probably a good idea.


With this it seems I don't need the volatile:


static void
m3_load_1 (tree v, int o, tree src_t, m3_type src_T, tree dst_t, m3_type dst_T,
?????????? bool volatil)
{
? if (o != 0 || TREE_TYPE (v) != src_t)
? {
??? if (GCC42 || (src_T != dst_T))?? <<< 
??? {
????? /* failsafe, but inefficient */
????? v = m3_build1 (ADDR_EXPR, t_addr, v);
????? v = m3_build2 (PLUS_EXPR, t_addr, v, size_int (o / BITS_PER_UNIT));
????? v = m3_build1 (INDIRECT_REF, src_t,
????? m3_cast (m3_build_pointer_type (src_t), v));
??? }
??? else
??? {
????? v = m3_build3 (BIT_FIELD_REF, src_t, v, TYPE_SIZE (src_t),
???????????????????? bitsize_int (o));
??? }
? }
?...



static void
m3_store_1 (tree v, int o, tree src_t, m3_type src_T, tree dst_t, m3_type dst_T,
??????????? bool volatil)
{
? tree val;
? if (o != 0 || TREE_TYPE (v) != dst_t)
? {
??? if (GCC42 || (src_T != dst_T))?? <<<< 
??? {
????? /* failsafe, but inefficient */
????? v = m3_build1 (ADDR_EXPR, t_addr, v);
????? v = m3_build2 (PLUS_EXPR, t_addr, v, size_int (o / BITS_PER_UNIT));
????? v = m3_build1 (INDIRECT_REF, dst_t,
???????????????????? m3_cast (m3_build_pointer_type (dst_t), v));
??? }
??? else
??? {
????? v = m3_build3 (BIT_FIELD_REF, dst_t, v, TYPE_SIZE (dst_t),
???????????????????? bitsize_int (o));
??? }
? }..

Previously, the code was the equivalent of saying if GCC42 there.


Good enough?


You know, this bitfield stuff has been a recurring problem.

I could probably narrow it down more.
? Like maybe if the types are the same size or both integers, still go down the old faster path.
??? Though I thought I had tried if they were either float going slow and that didn't work.
???? It might relate to structs as well.


However inefficient the non-bitfield ref path is, I can hope/assume it isn't as bad now without volatile.
But I could look a bit at the code.


?- Jay
 		 	   		  

From hosking at cs.purdue.edu  Sat Jun  5 23:46:00 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Sat, 5 Jun 2010 17:46:00 -0400
Subject: [M3devel] further removal of volatile
In-Reply-To: <COL101-W4299A2A8F51F83263BDF87E6D30@phx.gbl>
References: <COL101-W4299A2A8F51F83263BDF87E6D30@phx.gbl>
Message-ID: <37F7DB2D-2415-425D-BD64-3811174969C4@cs.purdue.edu>

But what sort of code do you get not using the BIT_FIELD_REF?


On 5 Jun 2010, at 16:52, Jay K wrote:

> 
> Tony, Currently we still put volatile on all floating point loads and/or stores.
> I removed it from all the other types.
> The main problem I was having is that CopySign in m3core would fail to compile.
>  It is loophoing a float as a struct with bitfields I believe.
>   I didn't look at what the equivalent C tree would be, though that is probably a good idea.
> 
> 
> With this it seems I don't need the volatile:
> 
> 
> static void
> m3_load_1 (tree v, int o, tree src_t, m3_type src_T, tree dst_t, m3_type dst_T,
>            bool volatil)
> {
>   if (o != 0 || TREE_TYPE (v) != src_t)
>   {
>     if (GCC42 || (src_T != dst_T))   <<< 
>     {
>       /* failsafe, but inefficient */
>       v = m3_build1 (ADDR_EXPR, t_addr, v);
>       v = m3_build2 (PLUS_EXPR, t_addr, v, size_int (o / BITS_PER_UNIT));
>       v = m3_build1 (INDIRECT_REF, src_t,
>       m3_cast (m3_build_pointer_type (src_t), v));
>     }
>     else
>     {
>       v = m3_build3 (BIT_FIELD_REF, src_t, v, TYPE_SIZE (src_t),
>                      bitsize_int (o));
>     }
>   }
>  ...
> 
> 
> 
> static void
> m3_store_1 (tree v, int o, tree src_t, m3_type src_T, tree dst_t, m3_type dst_T,
>             bool volatil)
> {
>   tree val;
>   if (o != 0 || TREE_TYPE (v) != dst_t)
>   {
>     if (GCC42 || (src_T != dst_T))   <<<< 
>     {
>       /* failsafe, but inefficient */
>       v = m3_build1 (ADDR_EXPR, t_addr, v);
>       v = m3_build2 (PLUS_EXPR, t_addr, v, size_int (o / BITS_PER_UNIT));
>       v = m3_build1 (INDIRECT_REF, dst_t,
>                      m3_cast (m3_build_pointer_type (dst_t), v));
>     }
>     else
>     {
>       v = m3_build3 (BIT_FIELD_REF, dst_t, v, TYPE_SIZE (dst_t),
>                      bitsize_int (o));
>     }
>   }..
> 
> Previously, the code was the equivalent of saying if GCC42 there.
> 
> 
> Good enough?
> 
> 
> You know, this bitfield stuff has been a recurring problem.
> 
> I could probably narrow it down more.
>   Like maybe if the types are the same size or both integers, still go down the old faster path.
>     Though I thought I had tried if they were either float going slow and that didn't work.
>      It might relate to structs as well.
> 
> 
> However inefficient the non-bitfield ref path is, I can hope/assume it isn't as bad now without volatile.
> But I could look a bit at the code.
> 
> 
>  - Jay
> 		 	   		  



From jay.krell at cornell.edu  Sun Jun  6 00:16:49 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 5 Jun 2010 22:16:49 +0000
Subject: [M3devel] further removal of volatile
In-Reply-To: <37F7DB2D-2415-425D-BD64-3811174969C4@cs.purdue.edu>
References: <COL101-W4299A2A8F51F83263BDF87E6D30@phx.gbl>,
	<37F7DB2D-2415-425D-BD64-3811174969C4@cs.purdue.edu>
Message-ID: <COL101-W49F94907D04D32B1EF7421E6D30@phx.gbl>


I didn't look...but darn..one problem seemingly present here:

/Users/jay/dev2/cm3/caltech-parser/parserlib/klex/AMD64_DARWIN/klex ../src/Calc.l -o CalcLex.i3 -t ../src/Calc.t -ti3 CalcTok.i3


***
*** runtime error:
***??? Segmentation violation - possible attempt to dereference NIL
***??? pc = 0x100012fa7 = Output + 0x17 in ../src/NFA.m3
***

"/cm3.amd64/pkg/cit_util/src/generics.tmpl", line 38: quake runtime error: exit 1536: /Users/jay/dev2/cm3/caltech-parser/parserlib/klex/AMD64_DARWIN/klex ../src/Calc.l -o CalcLex.i3 -t ../src/Calc.t -ti3 CalcTok.i3

ugh.

Later..
?- Jay


----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Sat, 5 Jun 2010 17:46:00 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] further removal of volatile
>
> But what sort of code do you get not using the BIT_FIELD_REF?
>
>
> On 5 Jun 2010, at 16:52, Jay K wrote:
>
>>
>> Tony, Currently we still put volatile on all floating point loads and/or stores.
>> I removed it from all the other types.
>> The main problem I was having is that CopySign in m3core would fail to compile.
>> It is loophoing a float as a struct with bitfields I believe.
>> I didn't look at what the equivalent C tree would be, though that is probably a good idea.
>>
>>
>> With this it seems I don't need the volatile:
>>
>>
>> static void
>> m3_load_1 (tree v, int o, tree src_t, m3_type src_T, tree dst_t, m3_type dst_T,
>> bool volatil)
>> {
>> if (o != 0 || TREE_TYPE (v) != src_t)
>> {
>> if (GCC42 || (src_T != dst_T)) <<<
>> {
>> /* failsafe, but inefficient */
>> v = m3_build1 (ADDR_EXPR, t_addr, v);
>> v = m3_build2 (PLUS_EXPR, t_addr, v, size_int (o / BITS_PER_UNIT));
>> v = m3_build1 (INDIRECT_REF, src_t,
>> m3_cast (m3_build_pointer_type (src_t), v));
>> }
>> else
>> {
>> v = m3_build3 (BIT_FIELD_REF, src_t, v, TYPE_SIZE (src_t),
>> bitsize_int (o));
>> }
>> }
>> ...
>>
>>
>>
>> static void
>> m3_store_1 (tree v, int o, tree src_t, m3_type src_T, tree dst_t, m3_type dst_T,
>> bool volatil)
>> {
>> tree val;
>> if (o != 0 || TREE_TYPE (v) != dst_t)
>> {
>> if (GCC42 || (src_T != dst_T)) <<<<
>> {
>> /* failsafe, but inefficient */
>> v = m3_build1 (ADDR_EXPR, t_addr, v);
>> v = m3_build2 (PLUS_EXPR, t_addr, v, size_int (o / BITS_PER_UNIT));
>> v = m3_build1 (INDIRECT_REF, dst_t,
>> m3_cast (m3_build_pointer_type (dst_t), v));
>> }
>> else
>> {
>> v = m3_build3 (BIT_FIELD_REF, dst_t, v, TYPE_SIZE (dst_t),
>> bitsize_int (o));
>> }
>> }..
>>
>> Previously, the code was the equivalent of saying if GCC42 there.
>>
>>
>> Good enough?
>>
>>
>> You know, this bitfield stuff has been a recurring problem.
>>
>> I could probably narrow it down more.
>> Like maybe if the types are the same size or both integers, still go down the old faster path.
>> Though I thought I had tried if they were either float going slow and that didn't work.
>> It might relate to structs as well.
>>
>>
>> However inefficient the non-bitfield ref path is, I can hope/assume it isn't as bad now without volatile.
>> But I could look a bit at the code.
>>
>>
>> - Jay
>>
>
 		 	   		  

From jay.krell at cornell.edu  Sun Jun  6 02:53:52 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 6 Jun 2010 00:53:52 +0000
Subject: [M3devel] cvs down?
Message-ID: <COL101-W4496C59304ACFEC817DC7BE6D40@phx.gbl>


It is back.

----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Subject: cvs down?
> Date: Sat, 5 Jun 2010 19:23:24 +0000
>
>
> My last commit didn't send mail.
> cvs diff and update aren't working.
>
>  - Jay
 		 	   		  

From jay.krell at cornell.edu  Wed Jun  9 09:07:18 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 9 Jun 2010 07:07:18 +0000
Subject: [M3devel] maybe volatile is "good"?
Message-ID: <COL101-W117095721973381CF1CEA6E6D70@phx.gbl>


A friend was asking about the portability of the system, and the "ptrdiff_t problem" -- where the optimizer might generate code whereby pointers exist but aren't evident in any registers or on the stack, because instead some pointer difference is being applied. I can't describe this well, but I know what he was referring to. A posting by David Chase mentions it. The result is that the garbage collector doesn't realize something is live and prematurely frees it, or moves it and doesn't update references...ok here is the link:

http://compilers.iecc.com/comparch/article/90-08-046

"...Worse things can happen; in some situations, it

may profit to use &a[-100] to reference elements of a, or to use

&b[0]-&a[0] to generate references to b"

So, this makes me nervous about my recent removal of making all loads and stores volatile.

Maybe best to put them back?

I know the optimized codegen was terrible, but..

?- Jay




 		 	   		  

From hosking at cs.purdue.edu  Wed Jun  9 14:13:21 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 9 Jun 2010 08:13:21 -0400
Subject: [M3devel] maybe volatile is "good"?
In-Reply-To: <COL101-W117095721973381CF1CEA6E6D70@phx.gbl>
References: <COL101-W117095721973381CF1CEA6E6D70@phx.gbl>
Message-ID: <FF22799E-E5D2-4C69-82E9-2EA35EEF3954@cs.purdue.edu>

This is not a problem.   gcc doesn't perform these optimisations, as far as I know.

On 9 Jun 2010, at 03:07, Jay K wrote:

> 
> A friend was asking about the portability of the system, and the "ptrdiff_t problem" -- where the optimizer might generate code whereby pointers exist but aren't evident in any registers or on the stack, because instead some pointer difference is being applied. I can't describe this well, but I know what he was referring to. A posting by David Chase mentions it. The result is that the garbage collector doesn't realize something is live and prematurely frees it, or moves it and doesn't update references...ok here is the link:
> 
> http://compilers.iecc.com/comparch/article/90-08-046
> 
> "...Worse things can happen; in some situations, it
> 
> may profit to use &a[-100] to reference elements of a, or to use
> 
> &b[0]-&a[0] to generate references to b"
> 
> So, this makes me nervous about my recent removal of making all loads and stores volatile.
> 
> Maybe best to put them back?
> 
> I know the optimized codegen was terrible, but..
> 
>  - Jay
> 
> 
> 
> 
> 		 	   		  



From jay.krell at cornell.edu  Sat Jun 12 17:11:42 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 12 Jun 2010 15:11:42 +0000
Subject: [M3devel] size vs. speed set_member / set_singleton serialized on
	NT386
Message-ID: <COL101-W447DCAFDF282BFB9A659D7E6DA0@phx.gbl>


We used to have (still in release branch):

m3-libs/m3core/src/Csupport/Common/parse.c:

void __cdecl set_singleton
??? ANSI((????? long a, ulong* s))
????? KR((a, s) long a; ulong* s;)
{
? long a_word = a / SET_GRAIN;
? long a_bit? = a % SET_GRAIN;
? s[a_word] |= (1UL << a_bit);
}


long __cdecl set_member
??? ANSI((????????? long elt, ulong* set))
????? KR((elt, set) long elt; ulong* set;)
{
? register long word = elt / SET_GRAIN;
? register long bit? = elt % SET_GRAIN;
? return (set[word] & (1UL << bit)) != 0;
}

Both backends generate calls to these functions.


In the gcc backend we now inline the equivalent.
In the NT backend, I use the bt and bts instructions.
?The resulting code is very size optimized.
? bt and bts do the shift, the index, the and/or. All in one.

I don't think I knew it at the time, but bt/bts are interlocked/seralized/atomic -- slow.

Maybe the wrong choice here?
Should instead inline the equivalent mask/index/and/or like the gcc backend does?


?- Jay
 		 	   		  

From jay.krell at cornell.edu  Sat Jun 12 22:24:57 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 12 Jun 2010 20:24:57 +0000
Subject: [M3devel] Modula-3 on Alpha/osf
Message-ID: <COL101-W6299CB615484EB3A70C44CE6DA0@phx.gbl>


It can compile itself. No stack walker currently.
User threads were used accidentally and worked. pthreads now.
No gui apps tested.

Compiling m3-libs/arithmetic:

Program received signal SIGFPE, Arithmetic exception.
0x00000001203c8c80 in TFloat__Multiply ()
(gdb) bt
#0? 0x00000001203c8c80 in TFloat__Multiply ()
#1? 0x000000012034a334 in ReelExpr__Multiply ()
#2? 0x0000000120373e10 in MultiplyExpr__Fold ()
#3? 0x00000001201ff810 in Expr__ConstValue ()
#4? 0x0000000120203744 in Constant__Check ()
#5? 0x0000000120163100 in Value__TypeCheck ()
#6? 0x00000001201853b4 in Scope__TypeCheck ()
#7? 0x000000012017cfdc in Module__TypeCheck ()
#8? 0x0000000120159b14 in M3Front__DoCompile ()
#9? 0x00000001201589f8 in M3Front__Compile ()
#10 0x0000000120059418 in Builder__RunM3 ()


Really, not all that interesting, the system has proven very portable.


Untested min distribution (with above bug):
http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-ALPHA_OSF-d5.8.2-20100612.tar.gz

Thanks to Mika for running the hardware/OS.


more later,
?- Jay
 		 	   		  

From jay.krell at cornell.edu  Sun Jun 13 00:39:18 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 12 Jun 2010 22:39:18 +0000
Subject: [M3devel] integer overflow
Message-ID: <COL101-W35BD9898C6B5DE9BC5A498E6DA0@phx.gbl>


Been reading about Alpha:


Alpha and Programming Languages 
Alpha is an attractive architecture for compiling a large variety of programming languages. 
Alpha has been carefull y desi gned to avoi d bi as t oward one or two progra mmi ng languages. 
For example: 
? Alpha does not contain a subroutine call instruction that moves a register window by a 
fixed amount. Thus, Alpha is a good match for programming languages with many 
parameters and programming languages with no parameters. 
? Alpha does not contain a global integer overflow enable bit. Such a bit would need to 
be changed at every subroutine boundary when a FORTRAN program calls a C pro- 
gram. 







...


Integer Operate Instructions 
...Integer overfl ow tr ap enable is encoded in t he functi on fie ld of ea ch instruct ion, ra ther t han 
kept in a global state bit. Thus, for example, both ADDQ/V and ADDQ opcodes exist for spec- 
ifying 64-bi t ADD with and without overflow checking. That makes it easier to pipe line 
implementations. 



?- Jay
 		 	   		  

From jay.krell at cornell.edu  Sun Jun 13 07:44:17 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 13 Jun 2010 05:44:17 +0000
Subject: [M3devel] Modula-3 on Alpha/osf
Message-ID: <COL101-W49D9DFBDF25B81EC171D18E6DB0@phx.gbl>


Ok, the floating point problem is fixed well enough now. Mika reports several X apps work.


http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-all-ALPHA_OSF-d5.8.2-20100612.tar.gz
http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-all-ALPHA_OSF-d5.8.2-20100612.tar.xz
http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-ALPHA_OSF-d5.8.2-20100612.tar.gz
http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-ALPHA_OSF-d5.8.2-20100612.tar.xz

I admit I forgot to remove $HOME/bin from $PATH when building these and it likely mattered.
Though "stock" install should suffice to use it.


These builds maybe lack most symbols.

?- Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com; mika at async.async.caltech.edu
> Subject: Modula-3 on Alpha/osf
> Date: Sat, 12 Jun 2010 20:24:57 +0000
>
>
> It can compile itself. No stack walker currently.
> User threads were used accidentally and worked. pthreads now.
> No gui apps tested.
>
> Compiling m3-libs/arithmetic:
>
> Program received signal SIGFPE, Arithmetic exception.
> 0x00000001203c8c80 in TFloat__Multiply ()
> (gdb) bt
> #0  0x00000001203c8c80 in TFloat__Multiply ()
> #1  0x000000012034a334 in ReelExpr__Multiply ()
> #2  0x0000000120373e10 in MultiplyExpr__Fold ()
> #3  0x00000001201ff810 in Expr__ConstValue ()
> #4  0x0000000120203744 in Constant__Check ()
> #5  0x0000000120163100 in Value__TypeCheck ()
> #6  0x00000001201853b4 in Scope__TypeCheck ()
> #7  0x000000012017cfdc in Module__TypeCheck ()
> #8  0x0000000120159b14 in M3Front__DoCompile ()
> #9  0x00000001201589f8 in M3Front__Compile ()
> #10 0x0000000120059418 in Builder__RunM3 ()
>
>
> Really, not all that interesting, the system has proven very portable.
>
>
> Untested min distribution (with above bug):
> http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-ALPHA_OSF-d5.8.2-20100612.tar.gz
>
> Thanks to Mika for running the hardware/OS.
>
>
> more later,
>  - Jay
>
 		 	   		  

From jay.krell at cornell.edu  Sun Jun 13 07:46:14 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 13 Jun 2010 05:46:14 +0000
Subject: [M3devel] interesting osf cc option for uninitialized variables
Message-ID: <COL101-W7E2AF461FEDBCE3741EE6E6DB0@phx.gbl>


? -trapuv
????? Forces all uninitialized stack variables to be initialized with
????? 0xfff58005fff58005. When this value is used as a floating-point vari-
????? able, it is treated as a floating-point NaN and causes a floating-point
????? trap.? When it is used as a pointer, an address or segmentation viola-
????? tion usually occurs.


Relates to recent discussion.
This should probably be how longreals are initialize for this target.
Though in reality I'm not very motivated to make this target esp. better than any others.
It is interesting to see though what features people have put into C compilers.


?- Jay





 		 	   		  

From rodney_bates at lcwb.coop  Sun Jun 13 17:08:15 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Sun, 13 Jun 2010 10:08:15 -0500
Subject: [M3devel] interesting osf cc option for uninitialized variables
In-Reply-To: <COL101-W7E2AF461FEDBCE3741EE6E6DB0@phx.gbl>
References: <COL101-W7E2AF461FEDBCE3741EE6E6DB0@phx.gbl>
Message-ID: <4C14F45F.2090709@lcwb.coop>



Jay K wrote:
>   -trapuv
>       Forces all uninitialized stack variables to be initialized with
>       0xfff58005fff58005. When this value is used as a floating-point vari-
>       able, it is treated as a floating-point NaN and causes a floating-point
>       trap.  When it is used as a pointer, an address or segmentation viola-
>       tion usually occurs.

In the case of a pointer, doing this would violate the Modula-3 language rule
that all variables are initialized to a bit pattern that represents a valid
member of the variable's type.  For a pointer, this would have to be either
the address of an allocated heap object or NIL.  Only the NIL makes any sense.

I like the idea for floats, though, and I consider a NaN to be a valid member
of the type.

> 
> 
> Relates to recent discussion.
> This should probably be how longreals are initialize for this target.
> Though in reality I'm not very motivated to make this target esp. better than any others.
> It is interesting to see though what features people have put into C compilers.
> 
> 
>  - Jay
> 
> 
> 
> 
> 
>  		 	   		  


From rodney_bates at lcwb.coop  Sun Jun 13 17:12:54 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Sun, 13 Jun 2010 10:12:54 -0500
Subject: [M3devel] integer overflow
In-Reply-To: <COL101-W35BD9898C6B5DE9BC5A498E6DA0@phx.gbl>
References: <COL101-W35BD9898C6B5DE9BC5A498E6DA0@phx.gbl>
Message-ID: <4C14F576.5000104@lcwb.coop>



Jay K wrote:
> Been reading about Alpha:
> 
> 
> Alpha and Programming Languages 
> Alpha is an attractive architecture for compiling a large variety of programming languages. 
> Alpha has been carefull y desi gned to avoi d bi as t oward one or two progra mmi ng languages. 
> For example: 
> ? Alpha does not contain a subroutine call instruction that moves a register window by a 
> fixed amount. Thus, Alpha is a good match for programming languages with many 
> parameters and programming languages with no parameters. 
> ? Alpha does not contain a global integer overflow enable bit. Such a bit would need to 
> be changed at every subroutine boundary when a FORTRAN program calls a C pro- 
> gram. 
> 
> 
> 
> 
> 
> 
> 
> ...
> 
> 
> Integer Operate Instructions 
> ...Integer overfl ow tr ap enable is encoded in t he functi on fie ld of ea ch instruct ion, ra ther t han 
> kept in a global state bit. Thus, for example, both ADDQ/V and ADDQ opcodes exist for spec- 
> ifying 64-bi t ADD with and without overflow checking. That makes it easier to pipe line 
> implementations. 
> 
> 

I'm all for trapping integer overflows, if the performance penalty isn't just horrible.  I doubt
that in more than a tiny minority of cases, integer overflows that silently wrap around (or
silently do anything else) are cases the original programmer knew were correct or even thought
about the possibility they might happen.

> 
>  - Jay
>  		 	   		  


From jay.krell at cornell.edu  Sun Jun 13 22:43:22 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 13 Jun 2010 20:43:22 +0000
Subject: [M3devel] -rpath/origin/CM3_INSTALL on osf
Message-ID: <COL101-W3A566B3FC93FA0C3C7817E6DB0@phx.gbl>


OSF, at least the older version that Mika is running, supports -rpath /foo/bar and -rpath ${arbitrary_environment_variable}, but not -rpath $origin.


Therefore I believe we should pick an arbitrary_environment_variable.


I'd like CM3_ROOT, but that is already somewhat/optionally in use for the root of the source tree.
CM3_INSTALL is somewhat/optionally in use to mean what we want here.
So CM3_INSTALL should probably be it.


Alternatively we could pick something really new, OSF_CM3_RPATH or such, and drop in wrapper scripts that set it to their location.


As well, OSF still has the "old" structure where all the .so files are strewn around pkg instead of flattened into lib.
I'll fix that shortly.


You know, the distributions I uploaded have /home/jayk presumably all around them.


We could also "stage" installs to somewhere unique/arbitrary and require user to set LD_LIBRARY_PATH.
But CM3_INSTALL seems adequate, maybe better.


Possibly CM3_INSTALL_5_8, CM3_INSTALL_5_9, etc.
? Though really, better than that is probably wrapper scripts that set CM3_INSTALL.
And wrapper scripts could be executables, put the real executables in lib or such.


?- Jay
 		 	   		  

From jay.krell at cornell.edu  Mon Jun 14 09:05:26 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 14 Jun 2010 07:05:26 +0000
Subject: [M3devel] -rpath/origin/CM3_INSTALL on osf
Message-ID: <COL101-W67A6DC7F1AAB8224C9C67E6DC0@phx.gbl>


It looks like you can't use $FOO/t, just $FOO.
So I'll probably use CM3_RPATH.

?- Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Subject: -rpath/origin/CM3_INSTALL on osf
> Date: Sun, 13 Jun 2010 20:43:22 +0000
>
>
> OSF, at least the older version that Mika is running, supports -rpath /foo/bar and -rpath ${arbitrary_environment_variable}, but not -rpath $origin.
>
>
> Therefore I believe we should pick an arbitrary_environment_variable.
>
>
> I'd like CM3_ROOT, but that is already somewhat/optionally in use for the root of the source tree.
> CM3_INSTALL is somewhat/optionally in use to mean what we want here.
> So CM3_INSTALL should probably be it.
>
>
> Alternatively we could pick something really new, OSF_CM3_RPATH or such, and drop in wrapper scripts that set it to their location.
>
>
> As well, OSF still has the "old" structure where all the .so files are strewn around pkg instead of flattened into lib.
> I'll fix that shortly.
>
>
> You know, the distributions I uploaded have /home/jayk presumably all around them.
>
>
> We could also "stage" installs to somewhere unique/arbitrary and require user to set LD_LIBRARY_PATH.
> But CM3_INSTALL seems adequate, maybe better.
>
>
> Possibly CM3_INSTALL_5_8, CM3_INSTALL_5_9, etc.
>   Though really, better than that is probably wrapper scripts that set CM3_INSTALL.
> And wrapper scripts could be executables, put the real executables in lib or such.
>
>
>  - Jay
>
 		 	   		  

From jay.krell at cornell.edu  Mon Jun 14 23:04:35 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 14 Jun 2010 21:04:35 +0000
Subject: [M3devel] -rpath/origin/CM3_INSTALL on osf
Message-ID: <COL101-W1739F3FDC24AB9E1B858FAE6DC0@phx.gbl>


I'm strongly considering dropping in bin stubs that calculate and set CM3_RPATH and then exec the actual files, in cm3/lib.
Thoughts?
It'd only be for OSF.
And only for shared executables -- wouldn't break cm3 finding config files.
Whether or not argv[0] "lies" and remains as bin, or is "truth" and set to lib, unsure.


Alternatively, relink on upon ship/install?
? That I believe is not unusual practise. It'd also fix NetBSD 4.0..
??? And it is in some ways better than the current use of $ORIGIN on all other systems.
? Augment "boot1.py" to build the entire system, and build a makefile that rebuilds and ships all libraries/executables?
? Well, what that probably looks like is augmenting it with Olaf's packaging.
?? Use that layout, and the method of using cd+cm3, but include all the .c and .s files and have cm3 run assemble/make_lib/ship.
?? We likely want that anyway, as a more complete form of cross build. Where I define "cross build" in an odd way -- compiling
?? all the Modula-3 to assembly, but not compiling any of the C or running the assembler or linking.
?? 
There are possible other options, like have the stub determine all the files to load and put them in _RLD_LIST.

Or just don't support shared libraries on OSF?

Or just distribute existing "boot" for OSF, and require people (Mika) to run scripts/python/boot2.sh?
?This is maybe the best short term choice. Doesn't require any work, supports shared libraries.
?I think I'll "try" that. Upload a current boot and if Mika can get it to work from there and doesn't mind it, good enough.

?- Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Subject: RE: -rpath/origin/CM3_INSTALL on osf
> Date: Mon, 14 Jun 2010 07:05:26 +0000
>
>
> It looks like you can't use $FOO/t, just $FOO.
> So I'll probably use CM3_RPATH.
>
>  - Jay
>
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: m3devel at elegosoft.com
>> Subject: -rpath/origin/CM3_INSTALL on osf
>> Date: Sun, 13 Jun 2010 20:43:22 +0000
>>
>>
>> OSF, at least the older version that Mika is running, supports -rpath /foo/bar and -rpath ${arbitrary_environment_variable}, but not -rpath $origin.
>>
>>
>> Therefore I believe we should pick an arbitrary_environment_variable.
>>
>>
>> I'd like CM3_ROOT, but that is already somewhat/optionally in use for the root of the source tree.
>> CM3_INSTALL is somewhat/optionally in use to mean what we want here.
>> So CM3_INSTALL should probably be it.
>>
>>
>> Alternatively we could pick something really new, OSF_CM3_RPATH or such, and drop in wrapper scripts that set it to their location.
>>
>>
>> As well, OSF still has the "old" structure where all the .so files are strewn around pkg instead of flattened into lib.
>> I'll fix that shortly.
>>
>>
>> You know, the distributions I uploaded have /home/jayk presumably all around them.
>>
>>
>> We could also "stage" installs to somewhere unique/arbitrary and require user to set LD_LIBRARY_PATH.
>> But CM3_INSTALL seems adequate, maybe better.
>>
>>
>> Possibly CM3_INSTALL_5_8, CM3_INSTALL_5_9, etc.
>> Though really, better than that is probably wrapper scripts that set CM3_INSTALL.
>> And wrapper scripts could be executables, put the real executables in lib or such.
>>
>>
>> - Jay
>>
>
 		 	   		  

From wagner at elegosoft.com  Tue Jun 15 11:04:21 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Tue, 15 Jun 2010 11:04:21 +0200
Subject: [M3devel] -rpath/origin/CM3_INSTALL on osf
In-Reply-To: <COL101-W1739F3FDC24AB9E1B858FAE6DC0@phx.gbl>
References: <COL101-W1739F3FDC24AB9E1B858FAE6DC0@phx.gbl>
Message-ID: <20100615110421.7sika6yr4sskso4g@mail.elegosoft.com>

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

> I'm strongly considering dropping in bin stubs that calculate and   
> set CM3_RPATH and then exec the actual files, in cm3/lib.
> Thoughts?
> It'd only be for OSF.
> And only for shared executables -- wouldn't break cm3 finding config files.
> Whether or not argv[0] "lies" and remains as bin, or is "truth" and   
> set to lib, unsure.
>
>
> Alternatively, relink on upon ship/install?
> ? That I believe is not unusual practise. It'd also fix NetBSD 4.0..
> ??? And it is in some ways better than the current use of $ORIGIN on  
>  all other systems.
> ? Augment "boot1.py" to build the entire system, and build a   
> makefile that rebuilds and ships all libraries/executables?
> ? Well, what that probably looks like is augmenting it with Olaf's packaging.
> ?? Use that layout, and the method of using cd+cm3, but include all   
> the .c and .s files and have cm3 run assemble/make_lib/ship.
> ?? We likely want that anyway, as a more complete form of cross   
> build. Where I define "cross build" in an odd way -- compiling
> ?? all the Modula-3 to assembly, but not compiling any of the C or   
> running the assembler or linking.

I think `relink upon ship' would be interesting as an experimental
option. I'm still not sure if we should really do that or not,
but if it can be done with little effort, we may play with it.
  ??
> There are possible other options, like have the stub determine all   
> the files to load and put them in _RLD_LIST.
>
> Or just don't support shared libraries on OSF?

Sounds lame :-)

> Or just distribute existing "boot" for OSF, and require people   
> (Mika) to run scripts/python/boot2.sh?
> ?This is maybe the best short term choice. Doesn't require any work,  
>  supports shared libraries.
> ?I think I'll "try" that. Upload a current boot and if Mika can get   
> it to work from there and doesn't mind it, good enough.

OK with me, too, for now, if all users are satisfied with that.
We're only talking about ALPHA_OSF, aren't we?

Olaf

> ?- Jay
>
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: m3devel at elegosoft.com
>> Subject: RE: -rpath/origin/CM3_INSTALL on osf
>> Date: Mon, 14 Jun 2010 07:05:26 +0000
>>
>>
>> It looks like you can't use $FOO/t, just $FOO.
>> So I'll probably use CM3_RPATH.
>>
>>  - Jay
>>
>> ----------------------------------------
>>> From: jay.krell at cornell.edu
>>> To: m3devel at elegosoft.com
>>> Subject: -rpath/origin/CM3_INSTALL on osf
>>> Date: Sun, 13 Jun 2010 20:43:22 +0000
>>>
>>>
>>> OSF, at least the older version that Mika is running, supports   
>>> -rpath /foo/bar and -rpath ${arbitrary_environment_variable}, but   
>>> not -rpath $origin.
>>>
>>>
>>> Therefore I believe we should pick an arbitrary_environment_variable.
>>>
>>>
>>> I'd like CM3_ROOT, but that is already somewhat/optionally in use   
>>> for the root of the source tree.
>>> CM3_INSTALL is somewhat/optionally in use to mean what we want here.
>>> So CM3_INSTALL should probably be it.
>>>
>>>
>>> Alternatively we could pick something really new, OSF_CM3_RPATH or  
>>>  such, and drop in wrapper scripts that set it to their location.
>>>
>>>
>>> As well, OSF still has the "old" structure where all the .so files  
>>>  are strewn around pkg instead of flattened into lib.
>>> I'll fix that shortly.
>>>
>>>
>>> You know, the distributions I uploaded have /home/jayk presumably   
>>> all around them.
>>>
>>>
>>> We could also "stage" installs to somewhere unique/arbitrary and   
>>> require user to set LD_LIBRARY_PATH.
>>> But CM3_INSTALL seems adequate, maybe better.
>>>
>>>
>>> Possibly CM3_INSTALL_5_8, CM3_INSTALL_5_9, etc.
>>> Though really, better than that is probably wrapper scripts that   
>>> set CM3_INSTALL.
>>> And wrapper scripts could be executables, put the real executables  
>>>  in lib or such.
>>>
>>>
>>> - 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 jay.krell at cornell.edu  Wed Jun 16 09:01:28 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 16 Jun 2010 07:01:28 +0000
Subject: [M3devel] -rpath/origin/CM3_INSTALL on osf
In-Reply-To: <20100615110421.7sika6yr4sskso4g@mail.elegosoft.com>
References: <COL101-W1739F3FDC24AB9E1B858FAE6DC0@phx.gbl>,
	<20100615110421.7sika6yr4sskso4g@mail.elegosoft.com>
Message-ID: <COL101-W4A6E5C8BBFA0272B893F7E6DE0@phx.gbl>


Yes it is mainly about OSF.
Though it is also about running unshipped binaries on all systems -- dynamically linked ones.
For now I'll probably do nothing. Except put this in a todo.txt file I'm going to checkin, I think.
Other stuff first I think.

?- Jay

----------------------------------------
> Date: Tue, 15 Jun 2010 11:04:21 +0200
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] -rpath/origin/CM3_INSTALL on osf
>
> Quoting Jay K :
>
>> I'm strongly considering dropping in bin stubs that calculate and
>> set CM3_RPATH and then exec the actual files, in cm3/lib.
>> Thoughts?
>> It'd only be for OSF.
>> And only for shared executables -- wouldn't break cm3 finding config files.
>> Whether or not argv[0] "lies" and remains as bin, or is "truth" and
>> set to lib, unsure.
>>
>>
>> Alternatively, relink on upon ship/install?
>>   That I believe is not unusual practise. It'd also fix NetBSD 4.0..
>>     And it is in some ways better than the current use of $ORIGIN on
>> all other systems.
>>   Augment "boot1.py" to build the entire system, and build a
>> makefile that rebuilds and ships all libraries/executables?
>>   Well, what that probably looks like is augmenting it with Olaf's packaging.
>>    Use that layout, and the method of using cd+cm3, but include all
>> the .c and .s files and have cm3 run assemble/make_lib/ship.
>>    We likely want that anyway, as a more complete form of cross
>> build. Where I define "cross build" in an odd way -- compiling
>>    all the Modula-3 to assembly, but not compiling any of the C or
>> running the assembler or linking.
>
> I think `relink upon ship' would be interesting as an experimental
> option. I'm still not sure if we should really do that or not,
> but if it can be done with little effort, we may play with it.
>
>> There are possible other options, like have the stub determine all
>> the files to load and put them in _RLD_LIST.
>>
>> Or just don't support shared libraries on OSF?
>
> Sounds lame :-)
>
>> Or just distribute existing "boot" for OSF, and require people
>> (Mika) to run scripts/python/boot2.sh?
>>  This is maybe the best short term choice. Doesn't require any work,
>> supports shared libraries.
>>  I think I'll "try" that. Upload a current boot and if Mika can get
>> it to work from there and doesn't mind it, good enough.
>
> OK with me, too, for now, if all users are satisfied with that.
> We're only talking about ALPHA_OSF, aren't we?
>
> Olaf
>
>>  - Jay
>>
>> ----------------------------------------
>>> From: jay.krell at cornell.edu
>>> To: m3devel at elegosoft.com
>>> Subject: RE: -rpath/origin/CM3_INSTALL on osf
>>> Date: Mon, 14 Jun 2010 07:05:26 +0000
>>>
>>>
>>> It looks like you can't use $FOO/t, just $FOO.
>>> So I'll probably use CM3_RPATH.
>>>
>>> - Jay
>>>
>>> ----------------------------------------
>>>> From: jay.krell at cornell.edu
>>>> To: m3devel at elegosoft.com
>>>> Subject: -rpath/origin/CM3_INSTALL on osf
>>>> Date: Sun, 13 Jun 2010 20:43:22 +0000
>>>>
>>>>
>>>> OSF, at least the older version that Mika is running, supports
>>>> -rpath /foo/bar and -rpath ${arbitrary_environment_variable}, but
>>>> not -rpath $origin.
>>>>
>>>>
>>>> Therefore I believe we should pick an arbitrary_environment_variable.
>>>>
>>>>
>>>> I'd like CM3_ROOT, but that is already somewhat/optionally in use
>>>> for the root of the source tree.
>>>> CM3_INSTALL is somewhat/optionally in use to mean what we want here.
>>>> So CM3_INSTALL should probably be it.
>>>>
>>>>
>>>> Alternatively we could pick something really new, OSF_CM3_RPATH or
>>>> such, and drop in wrapper scripts that set it to their location.
>>>>
>>>>
>>>> As well, OSF still has the "old" structure where all the .so files
>>>> are strewn around pkg instead of flattened into lib.
>>>> I'll fix that shortly.
>>>>
>>>>
>>>> You know, the distributions I uploaded have /home/jayk presumably
>>>> all around them.
>>>>
>>>>
>>>> We could also "stage" installs to somewhere unique/arbitrary and
>>>> require user to set LD_LIBRARY_PATH.
>>>> But CM3_INSTALL seems adequate, maybe better.
>>>>
>>>>
>>>> Possibly CM3_INSTALL_5_8, CM3_INSTALL_5_9, etc.
>>>> Though really, better than that is probably wrapper scripts that
>>>> set CM3_INSTALL.
>>>> And wrapper scripts could be executables, put the real executables
>>>> in lib or such.
>>>>
>>>>
>>>> - 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 darko at darko.org  Fri Jun 18 03:08:14 2010
From: darko at darko.org (Darko)
Date: Thu, 17 Jun 2010 18:08:14 -0700
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>
References: <1274350133.8902.0.camel@localhost>
	<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>
Message-ID: <2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>

I've been interested in an ARM port for some time. If you (or anyone else) are interested  in doing the port I can send you one of these, which looks like a good platform since it runs Linux and Android, has 512K memory and looks well supported: http://beagleboard.org/hardware



On 20/05/2010, at 4:47 AM, 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? 
> 
		 	   		  



From jay.krell at cornell.edu  Fri Jun 18 06:15:05 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 18 Jun 2010 04:15:05 +0000
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>
References: <1274350133.8902.0.camel@localhost>,
	<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>,
	<2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>
Message-ID: <COL101-W580FCB4C956AC658A851ABE6C00@phx.gbl>


My preference would be if you can set it up on the internet and allow me ssh access.
gcc only recently got support for Android's C library "bionic", I believe post-gcc 4.5.
I'm not sure if that matters much or not.
I'm not sure how much the C library of the target matters to gcc.
 
 
Anything with pthreads and gcc support is quite easy to port to these days. In the past the biggest thing you had to do was rewrite /usr/include in Modula-3. There was a tendency to rewrite far more of it than necessary. These days, none of it is needed.
 
 
Now you just have to
  - pick a target name 
  - find the jmpbuf size, word size, endian 
  - write a much small "config" file
  - respond to each error that occurs -- fill in the platform in a few tables sprinkled around the tree 
 
 
Even systems without pthreads or with not very good pthreads (OpenBSD) are easy now, as the user thread support is much more portable. It used to be, for user threads, you had to poke around in the jmpbuf.
 
 
I would encourage anyone else to try it out.
 
 
Maybe soon there will be a C generating backend, and we'll just have one distribution format that is a bunch of C, and then gcc support won't even be needed (e.g. IA64_NT).
 
 
Thanks,
 - Jay

----------------------------------------
> From: darko at darko.org
> Date: Thu, 17 Jun 2010 18:08:14 -0700
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Linux/ARM? Android?
>
> I've been interested in an ARM port for some time. If you (or anyone else) are interested in doing the port I can send you one of these, which looks like a good platform since it runs Linux and Android, has 512K memory and looks well supported: http://beagleboard.org/hardware
>
>
>
> On 20/05/2010, at 4:47 AM, 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?
>>
>
> 		 	   		  

From darko at darko.org  Fri Jun 18 06:41:59 2010
From: darko at darko.org (Darko)
Date: Thu, 17 Jun 2010 21:41:59 -0700
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <COL101-W580FCB4C956AC658A851ABE6C00@phx.gbl>
References: <1274350133.8902.0.camel@localhost>,
	<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>,
	<2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>
	<COL101-W580FCB4C956AC658A851ABE6C00@phx.gbl>
Message-ID: <44CCDCF6-BACE-4B58-A1F5-EF68A852E2A5@darko.org>

Ok, the link here is about 20/4Mbs so it shouldn't be too bad and the latency is good. I'm in Mountain View, CA. Unfortunately the board has only 128MB of main memory but I assume that's enough, I think a self hosted compiler has no point.

I'll post the details when it's up and running.


On 17/06/2010, at 9:15 PM, Jay K wrote:


My preference would be if you can set it up on the internet and allow me ssh access.
gcc only recently got support for Android's C library "bionic", I believe post-gcc 4.5.
I'm not sure if that matters much or not.
I'm not sure how much the C library of the target matters to gcc.


Anything with pthreads and gcc support is quite easy to port to these days. In the past the biggest thing you had to do was rewrite /usr/include in Modula-3. There was a tendency to rewrite far more of it than necessary. These days, none of it is needed.


Now you just have to
 - pick a target name 
 - find the jmpbuf size, word size, endian 
 - write a much small "config" file
 - respond to each error that occurs -- fill in the platform in a few tables sprinkled around the tree 


Even systems without pthreads or with not very good pthreads (OpenBSD) are easy now, as the user thread support is much more portable. It used to be, for user threads, you had to poke around in the jmpbuf.


I would encourage anyone else to try it out.


Maybe soon there will be a C generating backend, and we'll just have one distribution format that is a bunch of C, and then gcc support won't even be needed (e.g. IA64_NT).


Thanks,
- Jay

----------------------------------------
> From: darko at darko.org
> Date: Thu, 17 Jun 2010 18:08:14 -0700
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Linux/ARM? Android?
> 
> I've been interested in an ARM port for some time. If you (or anyone else) are interested in doing the port I can send you one of these, which looks like a good platform since it runs Linux and Android, has 512K memory and looks well supported: http://beagleboard.org/hardware
> 
> 
> 
> On 20/05/2010, at 4:47 AM, 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?
>> 
> 
> 		 	   		  



From jay.krell at cornell.edu  Sat Jun 19 07:04:28 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 19 Jun 2010 05:04:28 +0000
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <44CCDCF6-BACE-4B58-A1F5-EF68A852E2A5@darko.org>
References: <1274350133.8902.0.camel@localhost>, ,
	<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>, ,
	<2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>,
	<COL101-W580FCB4C956AC658A851ABE6C00@phx.gbl>,
	<44CCDCF6-BACE-4B58-A1F5-EF68A852E2A5@darko.org>
Message-ID: <COL101-W493D8FFD71EB43948CBE8CE6C10@phx.gbl>


Thanks. I'll give qemu a go as well.
Hey, maybe we can get mips also. (there's decent modern mips/linux hardware now, Chinese laptops)

?- Jay

----------------------------------------
> From: darko at darko.org
> Date: Thu, 17 Jun 2010 21:41:59 -0700
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Linux/ARM? Android?
>
> Ok, the link here is about 20/4Mbs so it shouldn't be too bad and the latency is good. I'm in Mountain View, CA. Unfortunately the board has only 128MB of main memory but I assume that's enough, I think a self hosted compiler has no point.
>
> I'll post the details when it's up and running.
>
>
> On 17/06/2010, at 9:15 PM, Jay K wrote:
>
>
> My preference would be if you can set it up on the internet and allow me ssh access.
> gcc only recently got support for Android's C library "bionic", I believe post-gcc 4.5.
> I'm not sure if that matters much or not.
> I'm not sure how much the C library of the target matters to gcc.
>
>
> Anything with pthreads and gcc support is quite easy to port to these days. In the past the biggest thing you had to do was rewrite /usr/include in Modula-3. There was a tendency to rewrite far more of it than necessary. These days, none of it is needed.
>
>
> Now you just have to
> - pick a target name
> - find the jmpbuf size, word size, endian
> - write a much small "config" file
> - respond to each error that occurs -- fill in the platform in a few tables sprinkled around the tree
>
>
> Even systems without pthreads or with not very good pthreads (OpenBSD) are easy now, as the user thread support is much more portable. It used to be, for user threads, you had to poke around in the jmpbuf.
>
>
> I would encourage anyone else to try it out.
>
>
> Maybe soon there will be a C generating backend, and we'll just have one distribution format that is a bunch of C, and then gcc support won't even be needed (e.g. IA64_NT).
>
>
> Thanks,
> - Jay
>
> ----------------------------------------
>> From: darko at darko.org
>> Date: Thu, 17 Jun 2010 18:08:14 -0700
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Linux/ARM? Android?
>>
>> I've been interested in an ARM port for some time. If you (or anyone else) are interested in doing the port I can send you one of these, which looks like a good platform since it runs Linux and Android, has 512K memory and looks well supported: http://beagleboard.org/hardware
>>
>>
>>
>> On 20/05/2010, at 4:47 AM, 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?
>>>
>>
>>
>
 		 	   		  

From darko at darko.org  Sat Jun 19 07:13:43 2010
From: darko at darko.org (Darko)
Date: Fri, 18 Jun 2010 22:13:43 -0700
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <COL101-W493D8FFD71EB43948CBE8CE6C10@phx.gbl>
References: <1274350133.8902.0.camel@localhost>, ,
	<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>, ,
	<2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>,
	<COL101-W580FCB4C956AC658A851ABE6C00@phx.gbl>,
	<44CCDCF6-BACE-4B58-A1F5-EF68A852E2A5@darko.org>
	<COL101-W493D8FFD71EB43948CBE8CE6C10@phx.gbl>
Message-ID: <B4638299-A29A-454B-9931-4F296F9AD3DB@darko.org>

If you use qemu, this might be useful: http://free-electrons.com/community/demos/qemu-arm-directfb/

I'm currently looking at some cheap laptops (around $100) which have ethernet plus screen, keyboard, battery, etc which would work well as hosts. Just trying to find one that runs both Linux and Android.


On 18/06/2010, at 10:04 PM, Jay K wrote:


Thanks. I'll give qemu a go as well.
Hey, maybe we can get mips also. (there's decent modern mips/linux hardware now, Chinese laptops)

 - Jay

----------------------------------------
> From: darko at darko.org
> Date: Thu, 17 Jun 2010 21:41:59 -0700
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Linux/ARM? Android?
> 
> Ok, the link here is about 20/4Mbs so it shouldn't be too bad and the latency is good. I'm in Mountain View, CA. Unfortunately the board has only 128MB of main memory but I assume that's enough, I think a self hosted compiler has no point.
> 
> I'll post the details when it's up and running.
> 
> 
> On 17/06/2010, at 9:15 PM, Jay K wrote:
> 
> 
> My preference would be if you can set it up on the internet and allow me ssh access.
> gcc only recently got support for Android's C library "bionic", I believe post-gcc 4.5.
> I'm not sure if that matters much or not.
> I'm not sure how much the C library of the target matters to gcc.
> 
> 
> Anything with pthreads and gcc support is quite easy to port to these days. In the past the biggest thing you had to do was rewrite /usr/include in Modula-3. There was a tendency to rewrite far more of it than necessary. These days, none of it is needed.
> 
> 
> Now you just have to
> - pick a target name
> - find the jmpbuf size, word size, endian
> - write a much small "config" file
> - respond to each error that occurs -- fill in the platform in a few tables sprinkled around the tree
> 
> 
> Even systems without pthreads or with not very good pthreads (OpenBSD) are easy now, as the user thread support is much more portable. It used to be, for user threads, you had to poke around in the jmpbuf.
> 
> 
> I would encourage anyone else to try it out.
> 
> 
> Maybe soon there will be a C generating backend, and we'll just have one distribution format that is a bunch of C, and then gcc support won't even be needed (e.g. IA64_NT).
> 
> 
> Thanks,
> - Jay
> 
> ----------------------------------------
>> From: darko at darko.org
>> Date: Thu, 17 Jun 2010 18:08:14 -0700
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Linux/ARM? Android?
>> 
>> I've been interested in an ARM port for some time. If you (or anyone else) are interested in doing the port I can send you one of these, which looks like a good platform since it runs Linux and Android, has 512K memory and looks well supported: http://beagleboard.org/hardware
>> 
>> 
>> 
>> On 20/05/2010, at 4:47 AM, 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?
>>> 
>> 
>> 
> 
		 	   		  



From jay.krell at cornell.edu  Sat Jun 19 07:44:55 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 19 Jun 2010 05:44:55 +0000
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <B4638299-A29A-454B-9931-4F296F9AD3DB@darko.org>
References: <1274350133.8902.0.camel@localhost>,
	,,<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>,
	, , <2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>, ,
	<COL101-W580FCB4C956AC658A851ABE6C00@phx.gbl>, ,
	<44CCDCF6-BACE-4B58-A1F5-EF68A852E2A5@darko.org>,
	<COL101-W493D8FFD71EB43948CBE8CE6C10@phx.gbl>,
	<B4638299-A29A-454B-9931-4F296F9AD3DB@darko.org>
Message-ID: <COL101-W7F2C05F30E9F3525E482DE6C10@phx.gbl>


Interesting, thanks.
But it looks like it needs to use local console for output?
I need something over the network/X.
It looks like there's an qemu option for usemode only too.

?- Jay

----------------------------------------
> From: darko at darko.org
> Date: Fri, 18 Jun 2010 22:13:43 -0700
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Linux/ARM? Android?
>
> If you use qemu, this might be useful: http://free-electrons.com/community/demos/qemu-arm-directfb/
>
> I'm currently looking at some cheap laptops (around $100) which have ethernet plus screen, keyboard, battery, etc which would work well as hosts. Just trying to find one that runs both Linux and Android.
>
>
> On 18/06/2010, at 10:04 PM, Jay K wrote:
>
>
> Thanks. I'll give qemu a go as well.
> Hey, maybe we can get mips also. (there's decent modern mips/linux hardware now, Chinese laptops)
>
> - Jay
>
> ----------------------------------------
>> From: darko at darko.org
>> Date: Thu, 17 Jun 2010 21:41:59 -0700
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Linux/ARM? Android?
>>
>> Ok, the link here is about 20/4Mbs so it shouldn't be too bad and the latency is good. I'm in Mountain View, CA. Unfortunately the board has only 128MB of main memory but I assume that's enough, I think a self hosted compiler has no point.
>>
>> I'll post the details when it's up and running.
>>
>>
>> On 17/06/2010, at 9:15 PM, Jay K wrote:
>>
>>
>> My preference would be if you can set it up on the internet and allow me ssh access.
>> gcc only recently got support for Android's C library "bionic", I believe post-gcc 4.5.
>> I'm not sure if that matters much or not.
>> I'm not sure how much the C library of the target matters to gcc.
>>
>>
>> Anything with pthreads and gcc support is quite easy to port to these days. In the past the biggest thing you had to do was rewrite /usr/include in Modula-3. There was a tendency to rewrite far more of it than necessary. These days, none of it is needed.
>>
>>
>> Now you just have to
>> - pick a target name
>> - find the jmpbuf size, word size, endian
>> - write a much small "config" file
>> - respond to each error that occurs -- fill in the platform in a few tables sprinkled around the tree
>>
>>
>> Even systems without pthreads or with not very good pthreads (OpenBSD) are easy now, as the user thread support is much more portable. It used to be, for user threads, you had to poke around in the jmpbuf.
>>
>>
>> I would encourage anyone else to try it out.
>>
>>
>> Maybe soon there will be a C generating backend, and we'll just have one distribution format that is a bunch of C, and then gcc support won't even be needed (e.g. IA64_NT).
>>
>>
>> Thanks,
>> - Jay
>>
>> ----------------------------------------
>>> From: darko at darko.org
>>> Date: Thu, 17 Jun 2010 18:08:14 -0700
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>
>>> I've been interested in an ARM port for some time. If you (or anyone else) are interested in doing the port I can send you one of these, which looks like a good platform since it runs Linux and Android, has 512K memory and looks well supported: http://beagleboard.org/hardware
>>>
>>>
>>>
>>> On 20/05/2010, at 4:47 AM, 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?
>>>>
>>>
>>>
>>
>
>
 		 	   		  

From darko at darko.org  Sat Jun 19 07:55:24 2010
From: darko at darko.org (Darko)
Date: Fri, 18 Jun 2010 22:55:24 -0700
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <COL101-W7F2C05F30E9F3525E482DE6C10@phx.gbl>
References: <1274350133.8902.0.camel@localhost>, , ,
	<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>, , ,
	<2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>, ,
	<COL101-W580FCB4C956AC658A851ABE6C00@phx.gbl>, ,
	<44CCDCF6-BACE-4B58-A1F5-EF68A852E2A5@darko.org>,
	<COL101-W493D8FFD71EB43948CBE8CE6C10@phx.gbl>,
	<B4638299-A29A-454B-9931-4F296F9AD3DB@darko.org>
	<COL101-W7F2C05F30E9F3525E482DE6C10@phx.gbl>
Message-ID: <ED46DCAD-C84A-488C-BF6F-70CA1F24AF3B@darko.org>

Yeah I've got it working on the console but I agree it needs the network.

Try: http://www.oszoo.org/wiki/index.php/Category:ARM_images
Also: http://www.armedslack.org/ 

What platform are you running on these days?




On 18/06/2010, at 10:44 PM, Jay K wrote:


Interesting, thanks.
But it looks like it needs to use local console for output?
I need something over the network/X.
It looks like there's an qemu option for usemode only too.

 - Jay

----------------------------------------
> From: darko at darko.org
> Date: Fri, 18 Jun 2010 22:13:43 -0700
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Linux/ARM? Android?
> 
> If you use qemu, this might be useful: http://free-electrons.com/community/demos/qemu-arm-directfb/
> 
> I'm currently looking at some cheap laptops (around $100) which have ethernet plus screen, keyboard, battery, etc which would work well as hosts. Just trying to find one that runs both Linux and Android.
> 
> 
> On 18/06/2010, at 10:04 PM, Jay K wrote:
> 
> 
> Thanks. I'll give qemu a go as well.
> Hey, maybe we can get mips also. (there's decent modern mips/linux hardware now, Chinese laptops)
> 
> - Jay
> 
> ----------------------------------------
>> From: darko at darko.org
>> Date: Thu, 17 Jun 2010 21:41:59 -0700
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Linux/ARM? Android?
>> 
>> Ok, the link here is about 20/4Mbs so it shouldn't be too bad and the latency is good. I'm in Mountain View, CA. Unfortunately the board has only 128MB of main memory but I assume that's enough, I think a self hosted compiler has no point.
>> 
>> I'll post the details when it's up and running.
>> 
>> 
>> On 17/06/2010, at 9:15 PM, Jay K wrote:
>> 
>> 
>> My preference would be if you can set it up on the internet and allow me ssh access.
>> gcc only recently got support for Android's C library "bionic", I believe post-gcc 4.5.
>> I'm not sure if that matters much or not.
>> I'm not sure how much the C library of the target matters to gcc.
>> 
>> 
>> Anything with pthreads and gcc support is quite easy to port to these days. In the past the biggest thing you had to do was rewrite /usr/include in Modula-3. There was a tendency to rewrite far more of it than necessary. These days, none of it is needed.
>> 
>> 
>> Now you just have to
>> - pick a target name
>> - find the jmpbuf size, word size, endian
>> - write a much small "config" file
>> - respond to each error that occurs -- fill in the platform in a few tables sprinkled around the tree
>> 
>> 
>> Even systems without pthreads or with not very good pthreads (OpenBSD) are easy now, as the user thread support is much more portable. It used to be, for user threads, you had to poke around in the jmpbuf.
>> 
>> 
>> I would encourage anyone else to try it out.
>> 
>> 
>> Maybe soon there will be a C generating backend, and we'll just have one distribution format that is a bunch of C, and then gcc support won't even be needed (e.g. IA64_NT).
>> 
>> 
>> Thanks,
>> - Jay
>> 
>> ----------------------------------------
>>> From: darko at darko.org
>>> Date: Thu, 17 Jun 2010 18:08:14 -0700
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>> 
>>> I've been interested in an ARM port for some time. If you (or anyone else) are interested in doing the port I can send you one of these, which looks like a good platform since it runs Linux and Android, has 512K memory and looks well supported: http://beagleboard.org/hardware
>>> 
>>> 
>>> 
>>> On 20/05/2010, at 4:47 AM, 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?
>>>> 
>>> 
>>> 
>> 
> 
> 
		 	   		  



From jay.krell at cornell.edu  Sat Jun 19 08:18:50 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 19 Jun 2010 06:18:50 +0000
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <ED46DCAD-C84A-488C-BF6F-70CA1F24AF3B@darko.org>
References: <1274350133.8902.0.camel@localhost>, ,
	,,<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>, ,
	,,<2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>,
	,,<COL101-W580FCB4C956AC658A851ABE6C00@phx.gbl>,
	, , <44CCDCF6-BACE-4B58-A1F5-EF68A852E2A5@darko.org>, ,
	<COL101-W493D8FFD71EB43948CBE8CE6C10@phx.gbl>, ,
	<B4638299-A29A-454B-9931-4F296F9AD3DB@darko.org>,
	<COL101-W7F2C05F30E9F3525E482DE6C10@phx.gbl>,
	<ED46DCAD-C84A-488C-BF6F-70CA1F24AF3B@darko.org>
Message-ID: <COL101-W5474F17968788325FFA76CE6C10@phx.gbl>


XP when I can; nothing else comes close for searching and editing text, I've tried many.
? Visual C++ 5.0.
? I recently learned how to copy/paste in vi, which helps, but I'm not sure I remember now.


Darwin/amd64 when I need/want posix/fastfork, which unfortunately is often.
? Cygwin is slow.
? TextWrangler usually there, though it is awful compared to Visual C++ 5.0.
? KomodoEdit is cross platform but also fairly impaired.
ssh access to a variety
Linux=Debian, it has among the best support for a variety of platforms.
Gentoo comes close or better (ppc64) but I've never been able to get it to install -- booting always fails.
Debian/x86 easy to get cross compiler, qemu, etc.


X Windows apps are never very good imho, so just give up and make do with the even worse command line..
?I find things as basic as scrollbars do not work well -- which button do I press when?
?The Modula-3 GUI apps suffer from this problem as well.
? Further damage due to needing three buttons but not having them.


Mouse button clicking is actually broken on modern Macs too -- they removed the mouse button from all the laptops, leaving
just a big pad, prone to accidental clicks at any location.. also prone to accidental multitouch gestures due to resting
a twitchy thumb where the button is supposed to be. Amazing, really, the mouse, one of their key initial advantages,
is now broken. (see also Finder and file open dialogs, two other former strengths that are now not so great.)
Multitouch scroll is nice though.


?- Jay

----------------------------------------
> From: darko at darko.org
> Date: Fri, 18 Jun 2010 22:55:24 -0700
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Linux/ARM? Android?
>
> Yeah I've got it working on the console but I agree it needs the network.
>
> Try: http://www.oszoo.org/wiki/index.php/Category:ARM_images
> Also: http://www.armedslack.org/
>
> What platform are you running on these days?
>
>
>
>
> On 18/06/2010, at 10:44 PM, Jay K wrote:
>
>
> Interesting, thanks.
> But it looks like it needs to use local console for output?
> I need something over the network/X.
> It looks like there's an qemu option for usemode only too.
>
> - Jay
>
> ----------------------------------------
>> From: darko at darko.org
>> Date: Fri, 18 Jun 2010 22:13:43 -0700
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Linux/ARM? Android?
>>
>> If you use qemu, this might be useful: http://free-electrons.com/community/demos/qemu-arm-directfb/
>>
>> I'm currently looking at some cheap laptops (around $100) which have ethernet plus screen, keyboard, battery, etc which would work well as hosts. Just trying to find one that runs both Linux and Android.
>>
>>
>> On 18/06/2010, at 10:04 PM, Jay K wrote:
>>
>>
>> Thanks. I'll give qemu a go as well.
>> Hey, maybe we can get mips also. (there's decent modern mips/linux hardware now, Chinese laptops)
>>
>> - Jay
>>
>> ----------------------------------------
>>> From: darko at darko.org
>>> Date: Thu, 17 Jun 2010 21:41:59 -0700
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>
>>> Ok, the link here is about 20/4Mbs so it shouldn't be too bad and the latency is good. I'm in Mountain View, CA. Unfortunately the board has only 128MB of main memory but I assume that's enough, I think a self hosted compiler has no point.
>>>
>>> I'll post the details when it's up and running.
>>>
>>>
>>> On 17/06/2010, at 9:15 PM, Jay K wrote:
>>>
>>>
>>> My preference would be if you can set it up on the internet and allow me ssh access.
>>> gcc only recently got support for Android's C library "bionic", I believe post-gcc 4.5.
>>> I'm not sure if that matters much or not.
>>> I'm not sure how much the C library of the target matters to gcc.
>>>
>>>
>>> Anything with pthreads and gcc support is quite easy to port to these days. In the past the biggest thing you had to do was rewrite /usr/include in Modula-3. There was a tendency to rewrite far more of it than necessary. These days, none of it is needed.
>>>
>>>
>>> Now you just have to
>>> - pick a target name
>>> - find the jmpbuf size, word size, endian
>>> - write a much small "config" file
>>> - respond to each error that occurs -- fill in the platform in a few tables sprinkled around the tree
>>>
>>>
>>> Even systems without pthreads or with not very good pthreads (OpenBSD) are easy now, as the user thread support is much more portable. It used to be, for user threads, you had to poke around in the jmpbuf.
>>>
>>>
>>> I would encourage anyone else to try it out.
>>>
>>>
>>> Maybe soon there will be a C generating backend, and we'll just have one distribution format that is a bunch of C, and then gcc support won't even be needed (e.g. IA64_NT).
>>>
>>>
>>> Thanks,
>>> - Jay
>>>
>>> ----------------------------------------
>>>> From: darko at darko.org
>>>> Date: Thu, 17 Jun 2010 18:08:14 -0700
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>
>>>> I've been interested in an ARM port for some time. If you (or anyone else) are interested in doing the port I can send you one of these, which looks like a good platform since it runs Linux and Android, has 512K memory and looks well supported: http://beagleboard.org/hardware
>>>>
>>>>
>>>>
>>>> On 20/05/2010, at 4:47 AM, 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?
>>>>>
>>>>
>>>>
>>>
>>
>>
>
>
 		 	   		  

From darko at darko.org  Sat Jun 19 09:13:53 2010
From: darko at darko.org (Darko)
Date: Sat, 19 Jun 2010 00:13:53 -0700
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <COL101-W5474F17968788325FFA76CE6C10@phx.gbl>
References: <1274350133.8902.0.camel@localhost>, , , ,
	<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>, , , ,
	<2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>, , ,
	<COL101-W580FCB4C956AC658A851ABE6C00@phx.gbl>, , ,
	<44CCDCF6-BACE-4B58-A1F5-EF68A852E2A5@darko.org>, ,
	<COL101-W493D8FFD71EB43948CBE8CE6C10@phx.gbl>, ,
	<B4638299-A29A-454B-9931-4F296F9AD3DB@darko.org>,
	<COL101-W7F2C05F30E9F3525E482DE6C10@phx.gbl>,
	<ED46DCAD-C84A-488C-BF6F-70CA1F24AF3B@darko.org>
	<COL101-W5474F17968788325FFA76CE6C10@phx.gbl>
Message-ID: <5E055C3D-78F6-4C08-86D9-8B8CA86B11A1@darko.org>

I got the first Debian image on http://www.oszoo.org/wiki/index.php/Category:ARM_images to run with a GUI, and it connect to the network. I'm using Q on my 2.4Ghz MacBook 13" and it's surprisingly fast. Note that it's a 10GB image (450MB download).

There are also images for Debian MIPS on that site too.

I agree that the new MacBook trackpad is not perfect and since moving from my previous machine that had a separate button I now get a lot of stray gestures doing odd things. The general solution is not to use the button at all and use taps. The new momentum scrolling with the gesture is neat but needs more "weight". Unfortunately Apple crosses over into form-over-function territory from time to time and this is one of those times.


On 18/06/2010, at 11:18 PM, Jay K wrote:


XP when I can; nothing else comes close for searching and editing text, I've tried many.
  Visual C++ 5.0.
  I recently learned how to copy/paste in vi, which helps, but I'm not sure I remember now.


Darwin/amd64 when I need/want posix/fastfork, which unfortunately is often.
  Cygwin is slow.
  TextWrangler usually there, though it is awful compared to Visual C++ 5.0.
  KomodoEdit is cross platform but also fairly impaired.
ssh access to a variety
Linux=Debian, it has among the best support for a variety of platforms.
Gentoo comes close or better (ppc64) but I've never been able to get it to install -- booting always fails.
Debian/x86 easy to get cross compiler, qemu, etc.


X Windows apps are never very good imho, so just give up and make do with the even worse command line..
 I find things as basic as scrollbars do not work well -- which button do I press when?
 The Modula-3 GUI apps suffer from this problem as well.
  Further damage due to needing three buttons but not having them.


Mouse button clicking is actually broken on modern Macs too -- they removed the mouse button from all the laptops, leaving
just a big pad, prone to accidental clicks at any location.. also prone to accidental multitouch gestures due to resting
a twitchy thumb where the button is supposed to be. Amazing, really, the mouse, one of their key initial advantages,
is now broken. (see also Finder and file open dialogs, two other former strengths that are now not so great.)
Multitouch scroll is nice though.


 - Jay

----------------------------------------
> From: darko at darko.org
> Date: Fri, 18 Jun 2010 22:55:24 -0700
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Linux/ARM? Android?
> 
> Yeah I've got it working on the console but I agree it needs the network.
> 
> Try: http://www.oszoo.org/wiki/index.php/Category:ARM_images
> Also: http://www.armedslack.org/
> 
> What platform are you running on these days?
> 
> 
> 
> 
> On 18/06/2010, at 10:44 PM, Jay K wrote:
> 
> 
> Interesting, thanks.
> But it looks like it needs to use local console for output?
> I need something over the network/X.
> It looks like there's an qemu option for usemode only too.
> 
> - Jay
> 
> ----------------------------------------
>> From: darko at darko.org
>> Date: Fri, 18 Jun 2010 22:13:43 -0700
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Linux/ARM? Android?
>> 
>> If you use qemu, this might be useful: http://free-electrons.com/community/demos/qemu-arm-directfb/
>> 
>> I'm currently looking at some cheap laptops (around $100) which have ethernet plus screen, keyboard, battery, etc which would work well as hosts. Just trying to find one that runs both Linux and Android.
>> 
>> 
>> On 18/06/2010, at 10:04 PM, Jay K wrote:
>> 
>> 
>> Thanks. I'll give qemu a go as well.
>> Hey, maybe we can get mips also. (there's decent modern mips/linux hardware now, Chinese laptops)
>> 
>> - Jay
>> 
>> ----------------------------------------
>>> From: darko at darko.org
>>> Date: Thu, 17 Jun 2010 21:41:59 -0700
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>> 
>>> Ok, the link here is about 20/4Mbs so it shouldn't be too bad and the latency is good. I'm in Mountain View, CA. Unfortunately the board has only 128MB of main memory but I assume that's enough, I think a self hosted compiler has no point.
>>> 
>>> I'll post the details when it's up and running.
>>> 
>>> 
>>> On 17/06/2010, at 9:15 PM, Jay K wrote:
>>> 
>>> 
>>> My preference would be if you can set it up on the internet and allow me ssh access.
>>> gcc only recently got support for Android's C library "bionic", I believe post-gcc 4.5.
>>> I'm not sure if that matters much or not.
>>> I'm not sure how much the C library of the target matters to gcc.
>>> 
>>> 
>>> Anything with pthreads and gcc support is quite easy to port to these days. In the past the biggest thing you had to do was rewrite /usr/include in Modula-3. There was a tendency to rewrite far more of it than necessary. These days, none of it is needed.
>>> 
>>> 
>>> Now you just have to
>>> - pick a target name
>>> - find the jmpbuf size, word size, endian
>>> - write a much small "config" file
>>> - respond to each error that occurs -- fill in the platform in a few tables sprinkled around the tree
>>> 
>>> 
>>> Even systems without pthreads or with not very good pthreads (OpenBSD) are easy now, as the user thread support is much more portable. It used to be, for user threads, you had to poke around in the jmpbuf.
>>> 
>>> 
>>> I would encourage anyone else to try it out.
>>> 
>>> 
>>> Maybe soon there will be a C generating backend, and we'll just have one distribution format that is a bunch of C, and then gcc support won't even be needed (e.g. IA64_NT).
>>> 
>>> 
>>> Thanks,
>>> - Jay
>>> 
>>> ----------------------------------------
>>>> From: darko at darko.org
>>>> Date: Thu, 17 Jun 2010 18:08:14 -0700
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>> 
>>>> I've been interested in an ARM port for some time. If you (or anyone else) are interested in doing the port I can send you one of these, which looks like a good platform since it runs Linux and Android, has 512K memory and looks well supported: http://beagleboard.org/hardware
>>>> 
>>>> 
>>>> 
>>>> On 20/05/2010, at 4:47 AM, 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?
>>>>> 
>>>> 
>>>> 
>>> 
>> 
>> 
> 
> 
		 	   		  



From jay.krell at cornell.edu  Sat Jun 19 10:44:04 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 19 Jun 2010 08:44:04 +0000
Subject: [M3devel] div/mod helpers for pair of negative numbers?
Message-ID: <COL101-W60CEC449B32E4D2297E8F0E6C10@phx.gbl>


Tony, I'm not going to change the release branch, but this is seemingly relevant to ARM on head:


? if ((b == 'P' && a == 'P') || IS_WORD_TYPE(T)) {
??? EXPR_REF (-2) = m3_build2 (FLOOR_MOD_EXPR, t,
??? ??? ??? ?????? m3_cast (t, EXPR_REF (-2)),
??? ??? ??? ?????? m3_cast (t, EXPR_REF (-1)));
??? EXPR_POP ();


is better off as:

? if ((b == a) || IS_WORD_TYPE(T)) {
??? EXPR_REF (-2) = m3_build2 (FLOOR_MOD_EXPR, t,
??? ??? ??? ?????? m3_cast (t, EXPR_REF (-2)),
??? ??? ??? ?????? m3_cast (t, EXPR_REF (-1)));
??? EXPR_POP ();

right?

That, consider..well..the historical modL function is close to that:


int64 __cdecl m3_modL
??? ANSI((????? int64 b, int64 a))
????? KR((b, a) int64 b; int64 a;)
{
? register int64 c;
? if ((a == 0) && (b != 0)) {? c = 0;
? } else if (a> 0)? {? c = (b>= 0) ? a % b : b + 1 + (a-1) % (-b);
? } else /* a < 0 */ {? c = (b>= 0) ? b - 1 - (-1-a) % (b) : - ((-a) % (-b));
? }
? return c;
}


for a < 0 and b < 0, it returns - ((-a) % (-b));.
which isn't exactly a % b as far as I know.

But if you consider my rewritten mod64 function, which I believe I tested thoroughly:

int64
__stdcall
m3_mod64(int64 b, int64 a)
{
? typedef? int64 ST; /* signed type */
? typedef uint64 UT; /* unsigned type */
? int aneg = (a < 0);
? int bneg = (b < 0);
? if (aneg == bneg || a == 0 || b == 0)
??? return (a % b);
? else
? {
??? UT ua = (aneg ? M3_POS(UT, a) : (UT)a);
??? UT ub = (bneg ? M3_POS(UT, b) : (UT)b);
??? a = (ST)(ub - 1 - (ua + ub - 1) % ub);
??? return (bneg ? -a : a);
? }
}



It seems 64bit floor mod doesn't work on ARM, so I'm putting back calling functions, sometimes -- only for 64bit mod on ARM.
div also if I found it is needed.
All other targets will keep using gcc's builtin support, whatever that is.


I guess I'll just have to go back and make sure there is test coverage here and compare release with head.


?- Jay

 		 	   		  

From darko at darko.org  Sat Jun 19 11:15:17 2010
From: darko at darko.org (Darko)
Date: Sat, 19 Jun 2010 02:15:17 -0700
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <5E055C3D-78F6-4C08-86D9-8B8CA86B11A1@darko.org>
References: <1274350133.8902.0.camel@localhost>, , , ,
	<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>, , , ,
	<2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>, , ,
	<COL101-W580FCB4C956AC658A851ABE6C00@phx.gbl>, , ,
	<44CCDCF6-BACE-4B58-A1F5-EF68A852E2A5@darko.org>, ,
	<COL101-W493D8FFD71EB43948CBE8CE6C10@phx.gbl>, ,
	<B4638299-A29A-454B-9931-4F296F9AD3DB@darko.org>,
	<COL101-W7F2C05F30E9F3525E482DE6C10@phx.gbl>,
	<ED46DCAD-C84A-488C-BF6F-70CA1F24AF3B@darko.org>
	<COL101-W5474F17968788325FFA76CE6C10@phx.gbl>
	<5E055C3D-78F6-4C08-86D9-8B8CA86B11A1@darko.org>
Message-ID: <C76EF524-6048-4C61-9744-6797BBA6C552@darko.org>

I should also mention that the Android SDK has a QEMU based emulator for testing applications and the adb (Android Bridge) tool can provide shell access.


On 19/06/2010, at 12:13 AM, Darko wrote:

I got the first Debian image on http://www.oszoo.org/wiki/index.php/Category:ARM_images to run with a GUI, and it connect to the network. I'm using Q on my 2.4Ghz MacBook 13" and it's surprisingly fast. Note that it's a 10GB image (450MB download).

There are also images for Debian MIPS on that site too.

I agree that the new MacBook trackpad is not perfect and since moving from my previous machine that had a separate button I now get a lot of stray gestures doing odd things. The general solution is not to use the button at all and use taps. The new momentum scrolling with the gesture is neat but needs more "weight". Unfortunately Apple crosses over into form-over-function territory from time to time and this is one of those times.


On 18/06/2010, at 11:18 PM, Jay K wrote:


XP when I can; nothing else comes close for searching and editing text, I've tried many.
 Visual C++ 5.0.
 I recently learned how to copy/paste in vi, which helps, but I'm not sure I remember now.


Darwin/amd64 when I need/want posix/fastfork, which unfortunately is often.
 Cygwin is slow.
 TextWrangler usually there, though it is awful compared to Visual C++ 5.0.
 KomodoEdit is cross platform but also fairly impaired.
ssh access to a variety
Linux=Debian, it has among the best support for a variety of platforms.
Gentoo comes close or better (ppc64) but I've never been able to get it to install -- booting always fails.
Debian/x86 easy to get cross compiler, qemu, etc.


X Windows apps are never very good imho, so just give up and make do with the even worse command line..
I find things as basic as scrollbars do not work well -- which button do I press when?
The Modula-3 GUI apps suffer from this problem as well.
 Further damage due to needing three buttons but not having them.


Mouse button clicking is actually broken on modern Macs too -- they removed the mouse button from all the laptops, leaving
just a big pad, prone to accidental clicks at any location.. also prone to accidental multitouch gestures due to resting
a twitchy thumb where the button is supposed to be. Amazing, really, the mouse, one of their key initial advantages,
is now broken. (see also Finder and file open dialogs, two other former strengths that are now not so great.)
Multitouch scroll is nice though.


- Jay

----------------------------------------
> From: darko at darko.org
> Date: Fri, 18 Jun 2010 22:55:24 -0700
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Linux/ARM? Android?
> 
> Yeah I've got it working on the console but I agree it needs the network.
> 
> Try: http://www.oszoo.org/wiki/index.php/Category:ARM_images
> Also: http://www.armedslack.org/
> 
> What platform are you running on these days?
> 
> 
> 
> 
> On 18/06/2010, at 10:44 PM, Jay K wrote:
> 
> 
> Interesting, thanks.
> But it looks like it needs to use local console for output?
> I need something over the network/X.
> It looks like there's an qemu option for usemode only too.
> 
> - Jay
> 
> ----------------------------------------
>> From: darko at darko.org
>> Date: Fri, 18 Jun 2010 22:13:43 -0700
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Linux/ARM? Android?
>> 
>> If you use qemu, this might be useful: http://free-electrons.com/community/demos/qemu-arm-directfb/
>> 
>> I'm currently looking at some cheap laptops (around $100) which have ethernet plus screen, keyboard, battery, etc which would work well as hosts. Just trying to find one that runs both Linux and Android.
>> 
>> 
>> On 18/06/2010, at 10:04 PM, Jay K wrote:
>> 
>> 
>> Thanks. I'll give qemu a go as well.
>> Hey, maybe we can get mips also. (there's decent modern mips/linux hardware now, Chinese laptops)
>> 
>> - Jay
>> 
>> ----------------------------------------
>>> From: darko at darko.org
>>> Date: Thu, 17 Jun 2010 21:41:59 -0700
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>> 
>>> Ok, the link here is about 20/4Mbs so it shouldn't be too bad and the latency is good. I'm in Mountain View, CA. Unfortunately the board has only 128MB of main memory but I assume that's enough, I think a self hosted compiler has no point.
>>> 
>>> I'll post the details when it's up and running.
>>> 
>>> 
>>> On 17/06/2010, at 9:15 PM, Jay K wrote:
>>> 
>>> 
>>> My preference would be if you can set it up on the internet and allow me ssh access.
>>> gcc only recently got support for Android's C library "bionic", I believe post-gcc 4.5.
>>> I'm not sure if that matters much or not.
>>> I'm not sure how much the C library of the target matters to gcc.
>>> 
>>> 
>>> Anything with pthreads and gcc support is quite easy to port to these days. In the past the biggest thing you had to do was rewrite /usr/include in Modula-3. There was a tendency to rewrite far more of it than necessary. These days, none of it is needed.
>>> 
>>> 
>>> Now you just have to
>>> - pick a target name
>>> - find the jmpbuf size, word size, endian
>>> - write a much small "config" file
>>> - respond to each error that occurs -- fill in the platform in a few tables sprinkled around the tree
>>> 
>>> 
>>> Even systems without pthreads or with not very good pthreads (OpenBSD) are easy now, as the user thread support is much more portable. It used to be, for user threads, you had to poke around in the jmpbuf.
>>> 
>>> 
>>> I would encourage anyone else to try it out.
>>> 
>>> 
>>> Maybe soon there will be a C generating backend, and we'll just have one distribution format that is a bunch of C, and then gcc support won't even be needed (e.g. IA64_NT).
>>> 
>>> 
>>> Thanks,
>>> - Jay
>>> 
>>> ----------------------------------------
>>>> From: darko at darko.org
>>>> Date: Thu, 17 Jun 2010 18:08:14 -0700
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>> 
>>>> I've been interested in an ARM port for some time. If you (or anyone else) are interested in doing the port I can send you one of these, which looks like a good platform since it runs Linux and Android, has 512K memory and looks well supported: http://beagleboard.org/hardware
>>>> 
>>>> 
>>>> 
>>>> On 20/05/2010, at 4:47 AM, 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?
>>>>> 
>>>> 
>>>> 
>>> 
>> 
>> 
> 
> 
		 	   		  




From jay.krell at cornell.edu  Sat Jun 19 11:51:50 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 19 Jun 2010 09:51:50 +0000
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <C76EF524-6048-4C61-9744-6797BBA6C552@darko.org>
References: <1274350133.8902.0.camel@localhost>, , ,
	,,<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>, , ,
	,,<2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>, ,
	,,<COL101-W580FCB4C956AC658A851ABE6C00@phx.gbl>, ,
	,,<44CCDCF6-BACE-4B58-A1F5-EF68A852E2A5@darko.org>,
	,,<COL101-W493D8FFD71EB43948CBE8CE6C10@phx.gbl>,
	, , <B4638299-A29A-454B-9931-4F296F9AD3DB@darko.org>, ,
	<COL101-W7F2C05F30E9F3525E482DE6C10@phx.gbl>, ,
	<ED46DCAD-C84A-488C-BF6F-70CA1F24AF3B@darko.org>,
	<COL101-W5474F17968788325FFA76CE6C10@phx.gbl>,
	<5E055C3D-78F6-4C08-86D9-8B8CA86B11A1@darko.org>,
	<C76EF524-6048-4C61-9744-6797BBA6C552@darko.org>
Message-ID: <COL101-W31787A72294920C0484E63E6C10@phx.gbl>


Eh I guess I should try that then. Ok. Thanks. Gotta take a break for a while.
?cd wherever 
?cvs -z3 upd -dAP? 
?cd scripts/python? 
?./boot1.py ARMEL_LINUX? 
? => cm3-boot-ARMEL_LINUX...tgz 
? extract that on a machine with cross tools (e.g. arm-linux-gnueabi-gcc, arm-linux-gnueabi-as), possibly the same machine as already on 
? cd into it? 
? make? 
? => arm cm3 


I got that far.
I can't claim it is right for Android.


Then put that cm3 onto a real (or emulated) ARM system and...
(cvs checkout, put the cm3 in /cm3/bin or such, add that to $PATH, and scripts/python/boot2.sh)


Moving forward to gcc 4.5 will get us atomics for ARM, sort of, at least on Linux, see:
?http://gcc.gnu.org/wiki/Atomic 


?- Jay

----------------------------------------
> From: darko at darko.org
> Date: Sat, 19 Jun 2010 02:15:17 -0700
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Linux/ARM? Android?
>
> I should also mention that the Android SDK has a QEMU based emulator for testing applications and the adb (Android Bridge) tool can provide shell access.
>
>
> On 19/06/2010, at 12:13 AM, Darko wrote:
>
> I got the first Debian image on http://www.oszoo.org/wiki/index.php/Category:ARM_images to run with a GUI, and it connect to the network. I'm using Q on my 2.4Ghz MacBook 13" and it's surprisingly fast. Note that it's a 10GB image (450MB download).
>
> There are also images for Debian MIPS on that site too.
>
> I agree that the new MacBook trackpad is not perfect and since moving from my previous machine that had a separate button I now get a lot of stray gestures doing odd things. The general solution is not to use the button at all and use taps. The new momentum scrolling with the gesture is neat but needs more "weight". Unfortunately Apple crosses over into form-over-function territory from time to time and this is one of those times.
>
>
> On 18/06/2010, at 11:18 PM, Jay K wrote:
>
>
> XP when I can; nothing else comes close for searching and editing text, I've tried many.
> Visual C++ 5.0.
> I recently learned how to copy/paste in vi, which helps, but I'm not sure I remember now.
>
>
> Darwin/amd64 when I need/want posix/fastfork, which unfortunately is often.
> Cygwin is slow.
> TextWrangler usually there, though it is awful compared to Visual C++ 5.0.
> KomodoEdit is cross platform but also fairly impaired.
> ssh access to a variety
> Linux=Debian, it has among the best support for a variety of platforms.
> Gentoo comes close or better (ppc64) but I've never been able to get it to install -- booting always fails.
> Debian/x86 easy to get cross compiler, qemu, etc.
>
>
> X Windows apps are never very good imho, so just give up and make do with the even worse command line..
> I find things as basic as scrollbars do not work well -- which button do I press when?
> The Modula-3 GUI apps suffer from this problem as well.
> Further damage due to needing three buttons but not having them.
>
>
> Mouse button clicking is actually broken on modern Macs too -- they removed the mouse button from all the laptops, leaving
> just a big pad, prone to accidental clicks at any location.. also prone to accidental multitouch gestures due to resting
> a twitchy thumb where the button is supposed to be. Amazing, really, the mouse, one of their key initial advantages,
> is now broken. (see also Finder and file open dialogs, two other former strengths that are now not so great.)
> Multitouch scroll is nice though.
>
>
> - Jay
>
> ----------------------------------------
>> From: darko at darko.org
>> Date: Fri, 18 Jun 2010 22:55:24 -0700
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Linux/ARM? Android?
>>
>> Yeah I've got it working on the console but I agree it needs the network.
>>
>> Try: http://www.oszoo.org/wiki/index.php/Category:ARM_images
>> Also: http://www.armedslack.org/
>>
>> What platform are you running on these days?
>>
>>
>>
>>
>> On 18/06/2010, at 10:44 PM, Jay K wrote:
>>
>>
>> Interesting, thanks.
>> But it looks like it needs to use local console for output?
>> I need something over the network/X.
>> It looks like there's an qemu option for usemode only too.
>>
>> - Jay
>>
>> ----------------------------------------
>>> From: darko at darko.org
>>> Date: Fri, 18 Jun 2010 22:13:43 -0700
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>
>>> If you use qemu, this might be useful: http://free-electrons.com/community/demos/qemu-arm-directfb/
>>>
>>> I'm currently looking at some cheap laptops (around $100) which have ethernet plus screen, keyboard, battery, etc which would work well as hosts. Just trying to find one that runs both Linux and Android.
>>>
>>>
>>> On 18/06/2010, at 10:04 PM, Jay K wrote:
>>>
>>>
>>> Thanks. I'll give qemu a go as well.
>>> Hey, maybe we can get mips also. (there's decent modern mips/linux hardware now, Chinese laptops)
>>>
>>> - Jay
>>>
>>> ----------------------------------------
>>>> From: darko at darko.org
>>>> Date: Thu, 17 Jun 2010 21:41:59 -0700
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>
>>>> Ok, the link here is about 20/4Mbs so it shouldn't be too bad and the latency is good. I'm in Mountain View, CA. Unfortunately the board has only 128MB of main memory but I assume that's enough, I think a self hosted compiler has no point.
>>>>
>>>> I'll post the details when it's up and running.
>>>>
>>>>
>>>> On 17/06/2010, at 9:15 PM, Jay K wrote:
>>>>
>>>>
>>>> My preference would be if you can set it up on the internet and allow me ssh access.
>>>> gcc only recently got support for Android's C library "bionic", I believe post-gcc 4.5.
>>>> I'm not sure if that matters much or not.
>>>> I'm not sure how much the C library of the target matters to gcc.
>>>>
>>>>
>>>> Anything with pthreads and gcc support is quite easy to port to these days. In the past the biggest thing you had to do was rewrite /usr/include in Modula-3. There was a tendency to rewrite far more of it than necessary. These days, none of it is needed.
>>>>
>>>>
>>>> Now you just have to
>>>> - pick a target name
>>>> - find the jmpbuf size, word size, endian
>>>> - write a much small "config" file
>>>> - respond to each error that occurs -- fill in the platform in a few tables sprinkled around the tree
>>>>
>>>>
>>>> Even systems without pthreads or with not very good pthreads (OpenBSD) are easy now, as the user thread support is much more portable. It used to be, for user threads, you had to poke around in the jmpbuf.
>>>>
>>>>
>>>> I would encourage anyone else to try it out.
>>>>
>>>>
>>>> Maybe soon there will be a C generating backend, and we'll just have one distribution format that is a bunch of C, and then gcc support won't even be needed (e.g. IA64_NT).
>>>>
>>>>
>>>> Thanks,
>>>> - Jay
>>>>
>>>> ----------------------------------------
>>>>> From: darko at darko.org
>>>>> Date: Thu, 17 Jun 2010 18:08:14 -0700
>>>>> To: jay.krell at cornell.edu
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>>
>>>>> I've been interested in an ARM port for some time. If you (or anyone else) are interested in doing the port I can send you one of these, which looks like a good platform since it runs Linux and Android, has 512K memory and looks well supported: http://beagleboard.org/hardware
>>>>>
>>>>>
>>>>>
>>>>> On 20/05/2010, at 4:47 AM, 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?
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>
>
>
 		 	   		  

From jay.krell at cornell.edu  Sat Jun 19 12:29:23 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 19 Jun 2010 10:29:23 +0000
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <C76EF524-6048-4C61-9744-6797BBA6C552@darko.org>
References: <1274350133.8902.0.camel@localhost>, ,
	,,,,<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>, ,
	,,,,<2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>,
	,,,,<COL101-W580FCB4C956AC658A851ABE6C00@phx.gbl>,
	, , , , <44CCDCF6-BACE-4B58-A1F5-EF68A852E2A5@darko.org>, , , ,
	<COL101-W493D8FFD71EB43948CBE8CE6C10@phx.gbl>, , , ,
	<B4638299-A29A-454B-9931-4F296F9AD3DB@darko.org>, ,
	<COL101-W7F2C05F30E9F3525E482DE6C10@phx.gbl>, ,
	<ED46DCAD-C84A-488C-BF6F-70CA1F24AF3B@darko.org>,
	<COL101-W5474F17968788325FFA76CE6C10@phx.gbl>,
	<5E055C3D-78F6-4C08-86D9-8B8CA86B11A1@darko.org>,
	<C76EF524-6048-4C61-9744-6797BBA6C552@darko.org>
Message-ID: <COL101-W18EA6CF8E4C3963769265EE6C10@phx.gbl>


Interesting to notice that they have their own pthread library..related to how I suggested we implement Modula-3 threads on top of Linux kernel interfaces instead of pthreads..

?- Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: darko at darko.org
> CC: m3devel at elegosoft.com
> Subject: RE: [M3devel] Linux/ARM? Android?
> Date: Sat, 19 Jun 2010 09:51:50 +0000
>
>
> Eh I guess I should try that then. Ok. Thanks. Gotta take a break for a while.
>  cd wherever
>  cvs -z3 upd -dAP
>  cd scripts/python
>  ./boot1.py ARMEL_LINUX
>   => cm3-boot-ARMEL_LINUX...tgz
>   extract that on a machine with cross tools (e.g. arm-linux-gnueabi-gcc, arm-linux-gnueabi-as), possibly the same machine as already on
>   cd into it
>   make
>   => arm cm3
>
>
> I got that far.
> I can't claim it is right for Android.
>
>
> Then put that cm3 onto a real (or emulated) ARM system and...
> (cvs checkout, put the cm3 in /cm3/bin or such, add that to $PATH, and scripts/python/boot2.sh)
>
>
> Moving forward to gcc 4.5 will get us atomics for ARM, sort of, at least on Linux, see:
>  http://gcc.gnu.org/wiki/Atomic
>
>
>  - Jay
>
> ----------------------------------------
>> From: darko at darko.org
>> Date: Sat, 19 Jun 2010 02:15:17 -0700
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Linux/ARM? Android?
>>
>> I should also mention that the Android SDK has a QEMU based emulator for testing applications and the adb (Android Bridge) tool can provide shell access.
>>
>>
>> On 19/06/2010, at 12:13 AM, Darko wrote:
>>
>> I got the first Debian image on http://www.oszoo.org/wiki/index.php/Category:ARM_images to run with a GUI, and it connect to the network. I'm using Q on my 2.4Ghz MacBook 13" and it's surprisingly fast. Note that it's a 10GB image (450MB download).
>>
>> There are also images for Debian MIPS on that site too.
>>
>> I agree that the new MacBook trackpad is not perfect and since moving from my previous machine that had a separate button I now get a lot of stray gestures doing odd things. The general solution is not to use the button at all and use taps. The new momentum scrolling with the gesture is neat but needs more "weight". Unfortunately Apple crosses over into form-over-function territory from time to time and this is one of those times.
>>
>>
>> On 18/06/2010, at 11:18 PM, Jay K wrote:
>>
>>
>> XP when I can; nothing else comes close for searching and editing text, I've tried many.
>> Visual C++ 5.0.
>> I recently learned how to copy/paste in vi, which helps, but I'm not sure I remember now.
>>
>>
>> Darwin/amd64 when I need/want posix/fastfork, which unfortunately is often.
>> Cygwin is slow.
>> TextWrangler usually there, though it is awful compared to Visual C++ 5.0.
>> KomodoEdit is cross platform but also fairly impaired.
>> ssh access to a variety
>> Linux=Debian, it has among the best support for a variety of platforms.
>> Gentoo comes close or better (ppc64) but I've never been able to get it to install -- booting always fails.
>> Debian/x86 easy to get cross compiler, qemu, etc.
>>
>>
>> X Windows apps are never very good imho, so just give up and make do with the even worse command line..
>> I find things as basic as scrollbars do not work well -- which button do I press when?
>> The Modula-3 GUI apps suffer from this problem as well.
>> Further damage due to needing three buttons but not having them.
>>
>>
>> Mouse button clicking is actually broken on modern Macs too -- they removed the mouse button from all the laptops, leaving
>> just a big pad, prone to accidental clicks at any location.. also prone to accidental multitouch gestures due to resting
>> a twitchy thumb where the button is supposed to be. Amazing, really, the mouse, one of their key initial advantages,
>> is now broken. (see also Finder and file open dialogs, two other former strengths that are now not so great.)
>> Multitouch scroll is nice though.
>>
>>
>> - Jay
>>
>> ----------------------------------------
>>> From: darko at darko.org
>>> Date: Fri, 18 Jun 2010 22:55:24 -0700
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>
>>> Yeah I've got it working on the console but I agree it needs the network.
>>>
>>> Try: http://www.oszoo.org/wiki/index.php/Category:ARM_images
>>> Also: http://www.armedslack.org/
>>>
>>> What platform are you running on these days?
>>>
>>>
>>>
>>>
>>> On 18/06/2010, at 10:44 PM, Jay K wrote:
>>>
>>>
>>> Interesting, thanks.
>>> But it looks like it needs to use local console for output?
>>> I need something over the network/X.
>>> It looks like there's an qemu option for usemode only too.
>>>
>>> - Jay
>>>
>>> ----------------------------------------
>>>> From: darko at darko.org
>>>> Date: Fri, 18 Jun 2010 22:13:43 -0700
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>
>>>> If you use qemu, this might be useful: http://free-electrons.com/community/demos/qemu-arm-directfb/
>>>>
>>>> I'm currently looking at some cheap laptops (around $100) which have ethernet plus screen, keyboard, battery, etc which would work well as hosts. Just trying to find one that runs both Linux and Android.
>>>>
>>>>
>>>> On 18/06/2010, at 10:04 PM, Jay K wrote:
>>>>
>>>>
>>>> Thanks. I'll give qemu a go as well.
>>>> Hey, maybe we can get mips also. (there's decent modern mips/linux hardware now, Chinese laptops)
>>>>
>>>> - Jay
>>>>
>>>> ----------------------------------------
>>>>> From: darko at darko.org
>>>>> Date: Thu, 17 Jun 2010 21:41:59 -0700
>>>>> To: jay.krell at cornell.edu
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>>
>>>>> Ok, the link here is about 20/4Mbs so it shouldn't be too bad and the latency is good. I'm in Mountain View, CA. Unfortunately the board has only 128MB of main memory but I assume that's enough, I think a self hosted compiler has no point.
>>>>>
>>>>> I'll post the details when it's up and running.
>>>>>
>>>>>
>>>>> On 17/06/2010, at 9:15 PM, Jay K wrote:
>>>>>
>>>>>
>>>>> My preference would be if you can set it up on the internet and allow me ssh access.
>>>>> gcc only recently got support for Android's C library "bionic", I believe post-gcc 4.5.
>>>>> I'm not sure if that matters much or not.
>>>>> I'm not sure how much the C library of the target matters to gcc.
>>>>>
>>>>>
>>>>> Anything with pthreads and gcc support is quite easy to port to these days. In the past the biggest thing you had to do was rewrite /usr/include in Modula-3. There was a tendency to rewrite far more of it than necessary. These days, none of it is needed.
>>>>>
>>>>>
>>>>> Now you just have to
>>>>> - pick a target name
>>>>> - find the jmpbuf size, word size, endian
>>>>> - write a much small "config" file
>>>>> - respond to each error that occurs -- fill in the platform in a few tables sprinkled around the tree
>>>>>
>>>>>
>>>>> Even systems without pthreads or with not very good pthreads (OpenBSD) are easy now, as the user thread support is much more portable. It used to be, for user threads, you had to poke around in the jmpbuf.
>>>>>
>>>>>
>>>>> I would encourage anyone else to try it out.
>>>>>
>>>>>
>>>>> Maybe soon there will be a C generating backend, and we'll just have one distribution format that is a bunch of C, and then gcc support won't even be needed (e.g. IA64_NT).
>>>>>
>>>>>
>>>>> Thanks,
>>>>> - Jay
>>>>>
>>>>> ----------------------------------------
>>>>>> From: darko at darko.org
>>>>>> Date: Thu, 17 Jun 2010 18:08:14 -0700
>>>>>> To: jay.krell at cornell.edu
>>>>>> CC: m3devel at elegosoft.com
>>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>>>
>>>>>> I've been interested in an ARM port for some time. If you (or anyone else) are interested in doing the port I can send you one of these, which looks like a good platform since it runs Linux and Android, has 512K memory and looks well supported: http://beagleboard.org/hardware
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 20/05/2010, at 4:47 AM, 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?
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>
 		 	   		  

From darko at darko.org  Sat Jun 19 12:32:33 2010
From: darko at darko.org (Darko)
Date: Sat, 19 Jun 2010 03:32:33 -0700
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <COL101-W18EA6CF8E4C3963769265EE6C10@phx.gbl>
References: <1274350133.8902.0.camel@localhost>, , , , , ,
	<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>, , , , , ,
	<2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>, , , , ,
	<COL101-W580FCB4C956AC658A851ABE6C00@phx.gbl>, , , , ,
	<44CCDCF6-BACE-4B58-A1F5-EF68A852E2A5@darko.org>, , , ,
	<COL101-W493D8FFD71EB43948CBE8CE6C10@phx.gbl>, , , ,
	<B4638299-A29A-454B-9931-4F296F9AD3DB@darko.org>, ,
	<COL101-W7F2C05F30E9F3525E482DE6C10@phx.gbl>, ,
	<ED46DCAD-C84A-488C-BF6F-70CA1F24AF3B@darko.org>,
	<COL101-W5474F17968788325FFA76CE6C10@phx.gbl>,
	<5E055C3D-78F6-4C08-86D9-8B8CA86B11A1@darko.org>,
	<C76EF524-6048-4C61-9744-6797BBA6C552@darko.org>
	<COL101-W18EA6CF8E4C3963769265EE6C10@phx.gbl>
Message-ID: <8F3CF5B8-4F17-4D43-AB51-BF960B05BA80@darko.org>

Has it got something to do with integration with Java?

On 19/06/2010, at 3:29 AM, Jay K wrote:


Interesting to notice that they have their own pthread library..related to how I suggested we implement Modula-3 threads on top of Linux kernel interfaces instead of pthreads..

 - Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: darko at darko.org
> CC: m3devel at elegosoft.com
> Subject: RE: [M3devel] Linux/ARM? Android?
> Date: Sat, 19 Jun 2010 09:51:50 +0000
> 
> 
> Eh I guess I should try that then. Ok. Thanks. Gotta take a break for a while.
> cd wherever
> cvs -z3 upd -dAP
> cd scripts/python
> ./boot1.py ARMEL_LINUX
>  => cm3-boot-ARMEL_LINUX...tgz
>  extract that on a machine with cross tools (e.g. arm-linux-gnueabi-gcc, arm-linux-gnueabi-as), possibly the same machine as already on
>  cd into it
>  make
>  => arm cm3
> 
> 
> I got that far.
> I can't claim it is right for Android.
> 
> 
> Then put that cm3 onto a real (or emulated) ARM system and...
> (cvs checkout, put the cm3 in /cm3/bin or such, add that to $PATH, and scripts/python/boot2.sh)
> 
> 
> Moving forward to gcc 4.5 will get us atomics for ARM, sort of, at least on Linux, see:
> http://gcc.gnu.org/wiki/Atomic
> 
> 
> - Jay
> 
> ----------------------------------------
>> From: darko at darko.org
>> Date: Sat, 19 Jun 2010 02:15:17 -0700
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Linux/ARM? Android?
>> 
>> I should also mention that the Android SDK has a QEMU based emulator for testing applications and the adb (Android Bridge) tool can provide shell access.
>> 
>> 
>> On 19/06/2010, at 12:13 AM, Darko wrote:
>> 
>> I got the first Debian image on http://www.oszoo.org/wiki/index.php/Category:ARM_images to run with a GUI, and it connect to the network. I'm using Q on my 2.4Ghz MacBook 13" and it's surprisingly fast. Note that it's a 10GB image (450MB download).
>> 
>> There are also images for Debian MIPS on that site too.
>> 
>> I agree that the new MacBook trackpad is not perfect and since moving from my previous machine that had a separate button I now get a lot of stray gestures doing odd things. The general solution is not to use the button at all and use taps. The new momentum scrolling with the gesture is neat but needs more "weight". Unfortunately Apple crosses over into form-over-function territory from time to time and this is one of those times.
>> 
>> 
>> On 18/06/2010, at 11:18 PM, Jay K wrote:
>> 
>> 
>> XP when I can; nothing else comes close for searching and editing text, I've tried many.
>> Visual C++ 5.0.
>> I recently learned how to copy/paste in vi, which helps, but I'm not sure I remember now.
>> 
>> 
>> Darwin/amd64 when I need/want posix/fastfork, which unfortunately is often.
>> Cygwin is slow.
>> TextWrangler usually there, though it is awful compared to Visual C++ 5.0.
>> KomodoEdit is cross platform but also fairly impaired.
>> ssh access to a variety
>> Linux=Debian, it has among the best support for a variety of platforms.
>> Gentoo comes close or better (ppc64) but I've never been able to get it to install -- booting always fails.
>> Debian/x86 easy to get cross compiler, qemu, etc.
>> 
>> 
>> X Windows apps are never very good imho, so just give up and make do with the even worse command line..
>> I find things as basic as scrollbars do not work well -- which button do I press when?
>> The Modula-3 GUI apps suffer from this problem as well.
>> Further damage due to needing three buttons but not having them.
>> 
>> 
>> Mouse button clicking is actually broken on modern Macs too -- they removed the mouse button from all the laptops, leaving
>> just a big pad, prone to accidental clicks at any location.. also prone to accidental multitouch gestures due to resting
>> a twitchy thumb where the button is supposed to be. Amazing, really, the mouse, one of their key initial advantages,
>> is now broken. (see also Finder and file open dialogs, two other former strengths that are now not so great.)
>> Multitouch scroll is nice though.
>> 
>> 
>> - Jay
>> 
>> ----------------------------------------
>>> From: darko at darko.org
>>> Date: Fri, 18 Jun 2010 22:55:24 -0700
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>> 
>>> Yeah I've got it working on the console but I agree it needs the network.
>>> 
>>> Try: http://www.oszoo.org/wiki/index.php/Category:ARM_images
>>> Also: http://www.armedslack.org/
>>> 
>>> What platform are you running on these days?
>>> 
>>> 
>>> 
>>> 
>>> On 18/06/2010, at 10:44 PM, Jay K wrote:
>>> 
>>> 
>>> Interesting, thanks.
>>> But it looks like it needs to use local console for output?
>>> I need something over the network/X.
>>> It looks like there's an qemu option for usemode only too.
>>> 
>>> - Jay
>>> 
>>> ----------------------------------------
>>>> From: darko at darko.org
>>>> Date: Fri, 18 Jun 2010 22:13:43 -0700
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>> 
>>>> If you use qemu, this might be useful: http://free-electrons.com/community/demos/qemu-arm-directfb/
>>>> 
>>>> I'm currently looking at some cheap laptops (around $100) which have ethernet plus screen, keyboard, battery, etc which would work well as hosts. Just trying to find one that runs both Linux and Android.
>>>> 
>>>> 
>>>> On 18/06/2010, at 10:04 PM, Jay K wrote:
>>>> 
>>>> 
>>>> Thanks. I'll give qemu a go as well.
>>>> Hey, maybe we can get mips also. (there's decent modern mips/linux hardware now, Chinese laptops)
>>>> 
>>>> - Jay
>>>> 
>>>> ----------------------------------------
>>>>> From: darko at darko.org
>>>>> Date: Thu, 17 Jun 2010 21:41:59 -0700
>>>>> To: jay.krell at cornell.edu
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>> 
>>>>> Ok, the link here is about 20/4Mbs so it shouldn't be too bad and the latency is good. I'm in Mountain View, CA. Unfortunately the board has only 128MB of main memory but I assume that's enough, I think a self hosted compiler has no point.
>>>>> 
>>>>> I'll post the details when it's up and running.
>>>>> 
>>>>> 
>>>>> On 17/06/2010, at 9:15 PM, Jay K wrote:
>>>>> 
>>>>> 
>>>>> My preference would be if you can set it up on the internet and allow me ssh access.
>>>>> gcc only recently got support for Android's C library "bionic", I believe post-gcc 4.5.
>>>>> I'm not sure if that matters much or not.
>>>>> I'm not sure how much the C library of the target matters to gcc.
>>>>> 
>>>>> 
>>>>> Anything with pthreads and gcc support is quite easy to port to these days. In the past the biggest thing you had to do was rewrite /usr/include in Modula-3. There was a tendency to rewrite far more of it than necessary. These days, none of it is needed.
>>>>> 
>>>>> 
>>>>> Now you just have to
>>>>> - pick a target name
>>>>> - find the jmpbuf size, word size, endian
>>>>> - write a much small "config" file
>>>>> - respond to each error that occurs -- fill in the platform in a few tables sprinkled around the tree
>>>>> 
>>>>> 
>>>>> Even systems without pthreads or with not very good pthreads (OpenBSD) are easy now, as the user thread support is much more portable. It used to be, for user threads, you had to poke around in the jmpbuf.
>>>>> 
>>>>> 
>>>>> I would encourage anyone else to try it out.
>>>>> 
>>>>> 
>>>>> Maybe soon there will be a C generating backend, and we'll just have one distribution format that is a bunch of C, and then gcc support won't even be needed (e.g. IA64_NT).
>>>>> 
>>>>> 
>>>>> Thanks,
>>>>> - Jay
>>>>> 
>>>>> ----------------------------------------
>>>>>> From: darko at darko.org
>>>>>> Date: Thu, 17 Jun 2010 18:08:14 -0700
>>>>>> To: jay.krell at cornell.edu
>>>>>> CC: m3devel at elegosoft.com
>>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>>> 
>>>>>> I've been interested in an ARM port for some time. If you (or anyone else) are interested in doing the port I can send you one of these, which looks like a good platform since it runs Linux and Android, has 512K memory and looks well supported: http://beagleboard.org/hardware
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On 20/05/2010, at 4:47 AM, 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?
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
>> 
> 
		 	   		  



From jay.krell at cornell.edu  Sat Jun 19 18:56:54 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 19 Jun 2010 16:56:54 +0000
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <8F3CF5B8-4F17-4D43-AB51-BF960B05BA80@darko.org>
References: <1274350133.8902.0.camel@localhost>, , , , ,
	,,<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>, , , , ,
	,,<2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>, , , ,
	,,<COL101-W580FCB4C956AC658A851ABE6C00@phx.gbl>, , , ,
	,,<44CCDCF6-BACE-4B58-A1F5-EF68A852E2A5@darko.org>, , ,
	,,<COL101-W493D8FFD71EB43948CBE8CE6C10@phx.gbl>, , ,
	,,<B4638299-A29A-454B-9931-4F296F9AD3DB@darko.org>,
	,,<COL101-W7F2C05F30E9F3525E482DE6C10@phx.gbl>,
	, , <ED46DCAD-C84A-488C-BF6F-70CA1F24AF3B@darko.org>, ,
	<COL101-W5474F17968788325FFA76CE6C10@phx.gbl>, ,
	<5E055C3D-78F6-4C08-86D9-8B8CA86B11A1@darko.org>, ,
	<C76EF524-6048-4C61-9744-6797BBA6C552@darko.org>,
	<COL101-W18EA6CF8E4C3963769265EE6C10@phx.gbl>,
	<8F3CF5B8-4F17-4D43-AB51-BF960B05BA80@darko.org>
Message-ID: <COL101-W84E06E7B4D04EE7BE3FC8E6C10@phx.gbl>


I don't think so. Replacing glibc is a popular activity, mostly for efficiency.
See android-ndk-r4/docs/system/libc/overview.txt.

Even Debian no longer uses glibc, sort of.
http://www.osnews.com/story/21441/Debian_Switching_to_EGLIBC
http://www.eglibc.org/home

?- Jay

----------------------------------------
> From: darko at darko.org
> Date: Sat, 19 Jun 2010 03:32:33 -0700
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Linux/ARM? Android?
>
> Has it got something to do with integration with Java?
>
> On 19/06/2010, at 3:29 AM, Jay K wrote:
>
>
> Interesting to notice that they have their own pthread library..related to how I suggested we implement Modula-3 threads on top of Linux kernel interfaces instead of pthreads..
>
> - Jay
>
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: darko at darko.org
>> CC: m3devel at elegosoft.com
>> Subject: RE: [M3devel] Linux/ARM? Android?
>> Date: Sat, 19 Jun 2010 09:51:50 +0000
>>
>>
>> Eh I guess I should try that then. Ok. Thanks. Gotta take a break for a while.
>> cd wherever
>> cvs -z3 upd -dAP
>> cd scripts/python
>> ./boot1.py ARMEL_LINUX
>> => cm3-boot-ARMEL_LINUX...tgz
>> extract that on a machine with cross tools (e.g. arm-linux-gnueabi-gcc, arm-linux-gnueabi-as), possibly the same machine as already on
>> cd into it
>> make
>> => arm cm3
>>
>>
>> I got that far.
>> I can't claim it is right for Android.
>>
>>
>> Then put that cm3 onto a real (or emulated) ARM system and...
>> (cvs checkout, put the cm3 in /cm3/bin or such, add that to $PATH, and scripts/python/boot2.sh)
>>
>>
>> Moving forward to gcc 4.5 will get us atomics for ARM, sort of, at least on Linux, see:
>> http://gcc.gnu.org/wiki/Atomic
>>
>>
>> - Jay
>>
>> ----------------------------------------
>>> From: darko at darko.org
>>> Date: Sat, 19 Jun 2010 02:15:17 -0700
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>
>>> I should also mention that the Android SDK has a QEMU based emulator for testing applications and the adb (Android Bridge) tool can provide shell access.
>>>
>>>
>>> On 19/06/2010, at 12:13 AM, Darko wrote:
>>>
>>> I got the first Debian image on http://www.oszoo.org/wiki/index.php/Category:ARM_images to run with a GUI, and it connect to the network. I'm using Q on my 2.4Ghz MacBook 13" and it's surprisingly fast. Note that it's a 10GB image (450MB download).
>>>
>>> There are also images for Debian MIPS on that site too.
>>>
>>> I agree that the new MacBook trackpad is not perfect and since moving from my previous machine that had a separate button I now get a lot of stray gestures doing odd things. The general solution is not to use the button at all and use taps. The new momentum scrolling with the gesture is neat but needs more "weight". Unfortunately Apple crosses over into form-over-function territory from time to time and this is one of those times.
>>>
>>>
>>> On 18/06/2010, at 11:18 PM, Jay K wrote:
>>>
>>>
>>> XP when I can; nothing else comes close for searching and editing text, I've tried many.
>>> Visual C++ 5.0.
>>> I recently learned how to copy/paste in vi, which helps, but I'm not sure I remember now.
>>>
>>>
>>> Darwin/amd64 when I need/want posix/fastfork, which unfortunately is often.
>>> Cygwin is slow.
>>> TextWrangler usually there, though it is awful compared to Visual C++ 5.0.
>>> KomodoEdit is cross platform but also fairly impaired.
>>> ssh access to a variety
>>> Linux=Debian, it has among the best support for a variety of platforms.
>>> Gentoo comes close or better (ppc64) but I've never been able to get it to install -- booting always fails.
>>> Debian/x86 easy to get cross compiler, qemu, etc.
>>>
>>>
>>> X Windows apps are never very good imho, so just give up and make do with the even worse command line..
>>> I find things as basic as scrollbars do not work well -- which button do I press when?
>>> The Modula-3 GUI apps suffer from this problem as well.
>>> Further damage due to needing three buttons but not having them.
>>>
>>>
>>> Mouse button clicking is actually broken on modern Macs too -- they removed the mouse button from all the laptops, leaving
>>> just a big pad, prone to accidental clicks at any location.. also prone to accidental multitouch gestures due to resting
>>> a twitchy thumb where the button is supposed to be. Amazing, really, the mouse, one of their key initial advantages,
>>> is now broken. (see also Finder and file open dialogs, two other former strengths that are now not so great.)
>>> Multitouch scroll is nice though.
>>>
>>>
>>> - Jay
>>>
>>> ----------------------------------------
>>>> From: darko at darko.org
>>>> Date: Fri, 18 Jun 2010 22:55:24 -0700
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>
>>>> Yeah I've got it working on the console but I agree it needs the network.
>>>>
>>>> Try: http://www.oszoo.org/wiki/index.php/Category:ARM_images
>>>> Also: http://www.armedslack.org/
>>>>
>>>> What platform are you running on these days?
>>>>
>>>>
>>>>
>>>>
>>>> On 18/06/2010, at 10:44 PM, Jay K wrote:
>>>>
>>>>
>>>> Interesting, thanks.
>>>> But it looks like it needs to use local console for output?
>>>> I need something over the network/X.
>>>> It looks like there's an qemu option for usemode only too.
>>>>
>>>> - Jay
>>>>
>>>> ----------------------------------------
>>>>> From: darko at darko.org
>>>>> Date: Fri, 18 Jun 2010 22:13:43 -0700
>>>>> To: jay.krell at cornell.edu
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>>
>>>>> If you use qemu, this might be useful: http://free-electrons.com/community/demos/qemu-arm-directfb/
>>>>>
>>>>> I'm currently looking at some cheap laptops (around $100) which have ethernet plus screen, keyboard, battery, etc which would work well as hosts. Just trying to find one that runs both Linux and Android.
>>>>>
>>>>>
>>>>> On 18/06/2010, at 10:04 PM, Jay K wrote:
>>>>>
>>>>>
>>>>> Thanks. I'll give qemu a go as well.
>>>>> Hey, maybe we can get mips also. (there's decent modern mips/linux hardware now, Chinese laptops)
>>>>>
>>>>> - Jay
>>>>>
>>>>> ----------------------------------------
>>>>>> From: darko at darko.org
>>>>>> Date: Thu, 17 Jun 2010 21:41:59 -0700
>>>>>> To: jay.krell at cornell.edu
>>>>>> CC: m3devel at elegosoft.com
>>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>>>
>>>>>> Ok, the link here is about 20/4Mbs so it shouldn't be too bad and the latency is good. I'm in Mountain View, CA. Unfortunately the board has only 128MB of main memory but I assume that's enough, I think a self hosted compiler has no point.
>>>>>>
>>>>>> I'll post the details when it's up and running.
>>>>>>
>>>>>>
>>>>>> On 17/06/2010, at 9:15 PM, Jay K wrote:
>>>>>>
>>>>>>
>>>>>> My preference would be if you can set it up on the internet and allow me ssh access.
>>>>>> gcc only recently got support for Android's C library "bionic", I believe post-gcc 4.5.
>>>>>> I'm not sure if that matters much or not.
>>>>>> I'm not sure how much the C library of the target matters to gcc.
>>>>>>
>>>>>>
>>>>>> Anything with pthreads and gcc support is quite easy to port to these days. In the past the biggest thing you had to do was rewrite /usr/include in Modula-3. There was a tendency to rewrite far more of it than necessary. These days, none of it is needed.
>>>>>>
>>>>>>
>>>>>> Now you just have to
>>>>>> - pick a target name
>>>>>> - find the jmpbuf size, word size, endian
>>>>>> - write a much small "config" file
>>>>>> - respond to each error that occurs -- fill in the platform in a few tables sprinkled around the tree
>>>>>>
>>>>>>
>>>>>> Even systems without pthreads or with not very good pthreads (OpenBSD) are easy now, as the user thread support is much more portable. It used to be, for user threads, you had to poke around in the jmpbuf.
>>>>>>
>>>>>>
>>>>>> I would encourage anyone else to try it out.
>>>>>>
>>>>>>
>>>>>> Maybe soon there will be a C generating backend, and we'll just have one distribution format that is a bunch of C, and then gcc support won't even be needed (e.g. IA64_NT).
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> - Jay
>>>>>>
>>>>>> ----------------------------------------
>>>>>>> From: darko at darko.org
>>>>>>> Date: Thu, 17 Jun 2010 18:08:14 -0700
>>>>>>> To: jay.krell at cornell.edu
>>>>>>> CC: m3devel at elegosoft.com
>>>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>>>>
>>>>>>> I've been interested in an ARM port for some time. If you (or anyone else) are interested in doing the port I can send you one of these, which looks like a good platform since it runs Linux and Android, has 512K memory and looks well supported: http://beagleboard.org/hardware
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 20/05/2010, at 4:47 AM, 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?
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>
>
 		 	   		  

From darko at darko.org  Sun Jun 20 00:47:24 2010
From: darko at darko.org (Darko)
Date: Sat, 19 Jun 2010 15:47:24 -0700
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <COL101-W31787A72294920C0484E63E6C10@phx.gbl>
References: <1274350133.8902.0.camel@localhost>, , , , ,
	<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>, , , , ,
	<2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>, , , ,
	<COL101-W580FCB4C956AC658A851ABE6C00@phx.gbl>, , , ,
	<44CCDCF6-BACE-4B58-A1F5-EF68A852E2A5@darko.org>, , ,
	<COL101-W493D8FFD71EB43948CBE8CE6C10@phx.gbl>, , ,
	<B4638299-A29A-454B-9931-4F296F9AD3DB@darko.org>, ,
	<COL101-W7F2C05F30E9F3525E482DE6C10@phx.gbl>, ,
	<ED46DCAD-C84A-488C-BF6F-70CA1F24AF3B@darko.org>,
	<COL101-W5474F17968788325FFA76CE6C10@phx.gbl>,
	<5E055C3D-78F6-4C08-86D9-8B8CA86B11A1@darko.org>,
	<C76EF524-6048-4C61-9744-6797BBA6C552@darko.org>
	<COL101-W31787A72294920C0484E63E6C10@phx.gbl>
Message-ID: <C1506F07-DE5E-4712-B15E-CB220A087D1A@darko.org>

Fantasic, thanks. There are some ARM cross tools available under DarwinPorts which I'm going to give this a try with.


On 19/06/2010, at 2:51 AM, Jay K wrote:


Eh I guess I should try that then. Ok. Thanks. Gotta take a break for a while.
 cd wherever 
 cvs -z3 upd -dAP  
 cd scripts/python  
 ./boot1.py ARMEL_LINUX  
  => cm3-boot-ARMEL_LINUX...tgz 
  extract that on a machine with cross tools (e.g. arm-linux-gnueabi-gcc, arm-linux-gnueabi-as), possibly the same machine as already on 
  cd into it  
  make  
  => arm cm3 


I got that far.
I can't claim it is right for Android.


Then put that cm3 onto a real (or emulated) ARM system and...
(cvs checkout, put the cm3 in /cm3/bin or such, add that to $PATH, and scripts/python/boot2.sh)


Moving forward to gcc 4.5 will get us atomics for ARM, sort of, at least on Linux, see:
 http://gcc.gnu.org/wiki/Atomic 


 - Jay

----------------------------------------
> From: darko at darko.org
> Date: Sat, 19 Jun 2010 02:15:17 -0700
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Linux/ARM? Android?
> 
> I should also mention that the Android SDK has a QEMU based emulator for testing applications and the adb (Android Bridge) tool can provide shell access.
> 
> 
> On 19/06/2010, at 12:13 AM, Darko wrote:
> 
> I got the first Debian image on http://www.oszoo.org/wiki/index.php/Category:ARM_images to run with a GUI, and it connect to the network. I'm using Q on my 2.4Ghz MacBook 13" and it's surprisingly fast. Note that it's a 10GB image (450MB download).
> 
> There are also images for Debian MIPS on that site too.
> 
> I agree that the new MacBook trackpad is not perfect and since moving from my previous machine that had a separate button I now get a lot of stray gestures doing odd things. The general solution is not to use the button at all and use taps. The new momentum scrolling with the gesture is neat but needs more "weight". Unfortunately Apple crosses over into form-over-function territory from time to time and this is one of those times.
> 
> 
> On 18/06/2010, at 11:18 PM, Jay K wrote:
> 
> 
> XP when I can; nothing else comes close for searching and editing text, I've tried many.
> Visual C++ 5.0.
> I recently learned how to copy/paste in vi, which helps, but I'm not sure I remember now.
> 
> 
> Darwin/amd64 when I need/want posix/fastfork, which unfortunately is often.
> Cygwin is slow.
> TextWrangler usually there, though it is awful compared to Visual C++ 5.0.
> KomodoEdit is cross platform but also fairly impaired.
> ssh access to a variety
> Linux=Debian, it has among the best support for a variety of platforms.
> Gentoo comes close or better (ppc64) but I've never been able to get it to install -- booting always fails.
> Debian/x86 easy to get cross compiler, qemu, etc.
> 
> 
> X Windows apps are never very good imho, so just give up and make do with the even worse command line..
> I find things as basic as scrollbars do not work well -- which button do I press when?
> The Modula-3 GUI apps suffer from this problem as well.
> Further damage due to needing three buttons but not having them.
> 
> 
> Mouse button clicking is actually broken on modern Macs too -- they removed the mouse button from all the laptops, leaving
> just a big pad, prone to accidental clicks at any location.. also prone to accidental multitouch gestures due to resting
> a twitchy thumb where the button is supposed to be. Amazing, really, the mouse, one of their key initial advantages,
> is now broken. (see also Finder and file open dialogs, two other former strengths that are now not so great.)
> Multitouch scroll is nice though.
> 
> 
> - Jay
> 
> ----------------------------------------
>> From: darko at darko.org
>> Date: Fri, 18 Jun 2010 22:55:24 -0700
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Linux/ARM? Android?
>> 
>> Yeah I've got it working on the console but I agree it needs the network.
>> 
>> Try: http://www.oszoo.org/wiki/index.php/Category:ARM_images
>> Also: http://www.armedslack.org/
>> 
>> What platform are you running on these days?
>> 
>> 
>> 
>> 
>> On 18/06/2010, at 10:44 PM, Jay K wrote:
>> 
>> 
>> Interesting, thanks.
>> But it looks like it needs to use local console for output?
>> I need something over the network/X.
>> It looks like there's an qemu option for usemode only too.
>> 
>> - Jay
>> 
>> ----------------------------------------
>>> From: darko at darko.org
>>> Date: Fri, 18 Jun 2010 22:13:43 -0700
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>> 
>>> If you use qemu, this might be useful: http://free-electrons.com/community/demos/qemu-arm-directfb/
>>> 
>>> I'm currently looking at some cheap laptops (around $100) which have ethernet plus screen, keyboard, battery, etc which would work well as hosts. Just trying to find one that runs both Linux and Android.
>>> 
>>> 
>>> On 18/06/2010, at 10:04 PM, Jay K wrote:
>>> 
>>> 
>>> Thanks. I'll give qemu a go as well.
>>> Hey, maybe we can get mips also. (there's decent modern mips/linux hardware now, Chinese laptops)
>>> 
>>> - Jay
>>> 
>>> ----------------------------------------
>>>> From: darko at darko.org
>>>> Date: Thu, 17 Jun 2010 21:41:59 -0700
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>> 
>>>> Ok, the link here is about 20/4Mbs so it shouldn't be too bad and the latency is good. I'm in Mountain View, CA. Unfortunately the board has only 128MB of main memory but I assume that's enough, I think a self hosted compiler has no point.
>>>> 
>>>> I'll post the details when it's up and running.
>>>> 
>>>> 
>>>> On 17/06/2010, at 9:15 PM, Jay K wrote:
>>>> 
>>>> 
>>>> My preference would be if you can set it up on the internet and allow me ssh access.
>>>> gcc only recently got support for Android's C library "bionic", I believe post-gcc 4.5.
>>>> I'm not sure if that matters much or not.
>>>> I'm not sure how much the C library of the target matters to gcc.
>>>> 
>>>> 
>>>> Anything with pthreads and gcc support is quite easy to port to these days. In the past the biggest thing you had to do was rewrite /usr/include in Modula-3. There was a tendency to rewrite far more of it than necessary. These days, none of it is needed.
>>>> 
>>>> 
>>>> Now you just have to
>>>> - pick a target name
>>>> - find the jmpbuf size, word size, endian
>>>> - write a much small "config" file
>>>> - respond to each error that occurs -- fill in the platform in a few tables sprinkled around the tree
>>>> 
>>>> 
>>>> Even systems without pthreads or with not very good pthreads (OpenBSD) are easy now, as the user thread support is much more portable. It used to be, for user threads, you had to poke around in the jmpbuf.
>>>> 
>>>> 
>>>> I would encourage anyone else to try it out.
>>>> 
>>>> 
>>>> Maybe soon there will be a C generating backend, and we'll just have one distribution format that is a bunch of C, and then gcc support won't even be needed (e.g. IA64_NT).
>>>> 
>>>> 
>>>> Thanks,
>>>> - Jay
>>>> 
>>>> ----------------------------------------
>>>>> From: darko at darko.org
>>>>> Date: Thu, 17 Jun 2010 18:08:14 -0700
>>>>> To: jay.krell at cornell.edu
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>> 
>>>>> I've been interested in an ARM port for some time. If you (or anyone else) are interested in doing the port I can send you one of these, which looks like a good platform since it runs Linux and Android, has 512K memory and looks well supported: http://beagleboard.org/hardware
>>>>> 
>>>>> 
>>>>> 
>>>>> On 20/05/2010, at 4:47 AM, 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?
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
> 
> 
> 
		 	   		  



From jay.krell at cornell.edu  Sun Jun 20 01:42:16 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 19 Jun 2010 23:42:16 +0000
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <C1506F07-DE5E-4712-B15E-CB220A087D1A@darko.org>
References: <1274350133.8902.0.camel@localhost>, , , ,
	,,<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>, , , ,
	,,<2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>, , ,
	,,<COL101-W580FCB4C956AC658A851ABE6C00@phx.gbl>, , ,
	,,<44CCDCF6-BACE-4B58-A1F5-EF68A852E2A5@darko.org>, ,
	,,<COL101-W493D8FFD71EB43948CBE8CE6C10@phx.gbl>, ,
	,,<B4638299-A29A-454B-9931-4F296F9AD3DB@darko.org>,
	,,<COL101-W7F2C05F30E9F3525E482DE6C10@phx.gbl>,
	, , <ED46DCAD-C84A-488C-BF6F-70CA1F24AF3B@darko.org>, ,
	<COL101-W5474F17968788325FFA76CE6C10@phx.gbl>, ,
	<5E055C3D-78F6-4C08-86D9-8B8CA86B11A1@darko.org>, ,
	<C76EF524-6048-4C61-9744-6797BBA6C552@darko.org>,
	<COL101-W31787A72294920C0484E63E6C10@phx.gbl>,
	<C1506F07-DE5E-4712-B15E-CB220A087D1A@darko.org>
Message-ID: <COL101-W29BA9D3680CFB903430A43E6C10@phx.gbl>


I should point out, actually, with cross gcc/as, you should be able to easily enough build the whole system cross.
ie: your apps instead of cm3.
I can try that -- building the whole tree cross, including compiling C and linking.


Notice m3-sys/cminstall/src/config-no-install/ARMEL_LINUX:


SYSTEM_CC = "arm-linux-gnueabi-gcc -gstabs+ -fPIC" % C compiler
SYSTEM_ASM = "arm-linux-gnueabi-as" % Assembler


I get to:
jay at xlin2:~/cm3-boot-ARMEL_LINUX-d5.8.2-20100619$ file cm3
cm3: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.14, not stripped
jay at xlin2:~/cm3-boot-ARMEL_LINUX-d5.8.2-20100619$ qemu-arm ./cm3
/lib/ld-linux.so.3: No such file or directory


My QEmu setup isn't complete..


I got the crosstools from hereabouts:
? http://www.emdebian.org/tools/crosstools.html


crosstool, scratchbox, buildroot may also be good options.


This reminds me though, I have a Western Digital MyBook World Edition.
Haven't powered it on in a while, slightly flaky device.
But it runs Linux/arm (oldabi).
I could/should power it on or get a new one something.


Also note/reminder, Android seems a bit different, at least in terms of finding C headers and libraries, maybe not for generating assembly, than "regular" Linux/arm.
Really "Linux/arm" seems a pretty fractured thing.
Newer architectures have floating point, for one thing.


?- Jay

----------------------------------------
> From: darko at darko.org
> Date: Sat, 19 Jun 2010 15:47:24 -0700
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Linux/ARM? Android?
>
> Fantasic, thanks. There are some ARM cross tools available under DarwinPorts which I'm going to give this a try with.
>
>
> On 19/06/2010, at 2:51 AM, Jay K wrote:
>
>
> Eh I guess I should try that then. Ok. Thanks. Gotta take a break for a while.
> cd wherever
> cvs -z3 upd -dAP
> cd scripts/python
> ./boot1.py ARMEL_LINUX
> => cm3-boot-ARMEL_LINUX...tgz
> extract that on a machine with cross tools (e.g. arm-linux-gnueabi-gcc, arm-linux-gnueabi-as), possibly the same machine as already on
> cd into it
> make
> => arm cm3
>
>
> I got that far.
> I can't claim it is right for Android.
>
>
> Then put that cm3 onto a real (or emulated) ARM system and...
> (cvs checkout, put the cm3 in /cm3/bin or such, add that to $PATH, and scripts/python/boot2.sh)
>
>
> Moving forward to gcc 4.5 will get us atomics for ARM, sort of, at least on Linux, see:
> http://gcc.gnu.org/wiki/Atomic
>
>
> - Jay
>
> ----------------------------------------
>> From: darko at darko.org
>> Date: Sat, 19 Jun 2010 02:15:17 -0700
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Linux/ARM? Android?
>>
>> I should also mention that the Android SDK has a QEMU based emulator for testing applications and the adb (Android Bridge) tool can provide shell access.
>>
>>
>> On 19/06/2010, at 12:13 AM, Darko wrote:
>>
>> I got the first Debian image on http://www.oszoo.org/wiki/index.php/Category:ARM_images to run with a GUI, and it connect to the network. I'm using Q on my 2.4Ghz MacBook 13" and it's surprisingly fast. Note that it's a 10GB image (450MB download).
>>
>> There are also images for Debian MIPS on that site too.
>>
>> I agree that the new MacBook trackpad is not perfect and since moving from my previous machine that had a separate button I now get a lot of stray gestures doing odd things. The general solution is not to use the button at all and use taps. The new momentum scrolling with the gesture is neat but needs more "weight". Unfortunately Apple crosses over into form-over-function territory from time to time and this is one of those times.
>>
>>
>> On 18/06/2010, at 11:18 PM, Jay K wrote:
>>
>>
>> XP when I can; nothing else comes close for searching and editing text, I've tried many.
>> Visual C++ 5.0.
>> I recently learned how to copy/paste in vi, which helps, but I'm not sure I remember now.
>>
>>
>> Darwin/amd64 when I need/want posix/fastfork, which unfortunately is often.
>> Cygwin is slow.
>> TextWrangler usually there, though it is awful compared to Visual C++ 5.0.
>> KomodoEdit is cross platform but also fairly impaired.
>> ssh access to a variety
>> Linux=Debian, it has among the best support for a variety of platforms.
>> Gentoo comes close or better (ppc64) but I've never been able to get it to install -- booting always fails.
>> Debian/x86 easy to get cross compiler, qemu, etc.
>>
>>
>> X Windows apps are never very good imho, so just give up and make do with the even worse command line..
>> I find things as basic as scrollbars do not work well -- which button do I press when?
>> The Modula-3 GUI apps suffer from this problem as well.
>> Further damage due to needing three buttons but not having them.
>>
>>
>> Mouse button clicking is actually broken on modern Macs too -- they removed the mouse button from all the laptops, leaving
>> just a big pad, prone to accidental clicks at any location.. also prone to accidental multitouch gestures due to resting
>> a twitchy thumb where the button is supposed to be. Amazing, really, the mouse, one of their key initial advantages,
>> is now broken. (see also Finder and file open dialogs, two other former strengths that are now not so great.)
>> Multitouch scroll is nice though.
>>
>>
>> - Jay
>>
>> ----------------------------------------
>>> From: darko at darko.org
>>> Date: Fri, 18 Jun 2010 22:55:24 -0700
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>
>>> Yeah I've got it working on the console but I agree it needs the network.
>>>
>>> Try: http://www.oszoo.org/wiki/index.php/Category:ARM_images
>>> Also: http://www.armedslack.org/
>>>
>>> What platform are you running on these days?
>>>
>>>
>>>
>>>
>>> On 18/06/2010, at 10:44 PM, Jay K wrote:
>>>
>>>
>>> Interesting, thanks.
>>> But it looks like it needs to use local console for output?
>>> I need something over the network/X.
>>> It looks like there's an qemu option for usemode only too.
>>>
>>> - Jay
>>>
>>> ----------------------------------------
>>>> From: darko at darko.org
>>>> Date: Fri, 18 Jun 2010 22:13:43 -0700
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>
>>>> If you use qemu, this might be useful: http://free-electrons.com/community/demos/qemu-arm-directfb/
>>>>
>>>> I'm currently looking at some cheap laptops (around $100) which have ethernet plus screen, keyboard, battery, etc which would work well as hosts. Just trying to find one that runs both Linux and Android.
>>>>
>>>>
>>>> On 18/06/2010, at 10:04 PM, Jay K wrote:
>>>>
>>>>
>>>> Thanks. I'll give qemu a go as well.
>>>> Hey, maybe we can get mips also. (there's decent modern mips/linux hardware now, Chinese laptops)
>>>>
>>>> - Jay
>>>>
>>>> ----------------------------------------
>>>>> From: darko at darko.org
>>>>> Date: Thu, 17 Jun 2010 21:41:59 -0700
>>>>> To: jay.krell at cornell.edu
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>>
>>>>> Ok, the link here is about 20/4Mbs so it shouldn't be too bad and the latency is good. I'm in Mountain View, CA. Unfortunately the board has only 128MB of main memory but I assume that's enough, I think a self hosted compiler has no point.
>>>>>
>>>>> I'll post the details when it's up and running.
>>>>>
>>>>>
>>>>> On 17/06/2010, at 9:15 PM, Jay K wrote:
>>>>>
>>>>>
>>>>> My preference would be if you can set it up on the internet and allow me ssh access.
>>>>> gcc only recently got support for Android's C library "bionic", I believe post-gcc 4.5.
>>>>> I'm not sure if that matters much or not.
>>>>> I'm not sure how much the C library of the target matters to gcc.
>>>>>
>>>>>
>>>>> Anything with pthreads and gcc support is quite easy to port to these days. In the past the biggest thing you had to do was rewrite /usr/include in Modula-3. There was a tendency to rewrite far more of it than necessary. These days, none of it is needed.
>>>>>
>>>>>
>>>>> Now you just have to
>>>>> - pick a target name
>>>>> - find the jmpbuf size, word size, endian
>>>>> - write a much small "config" file
>>>>> - respond to each error that occurs -- fill in the platform in a few tables sprinkled around the tree
>>>>>
>>>>>
>>>>> Even systems without pthreads or with not very good pthreads (OpenBSD) are easy now, as the user thread support is much more portable. It used to be, for user threads, you had to poke around in the jmpbuf.
>>>>>
>>>>>
>>>>> I would encourage anyone else to try it out.
>>>>>
>>>>>
>>>>> Maybe soon there will be a C generating backend, and we'll just have one distribution format that is a bunch of C, and then gcc support won't even be needed (e.g. IA64_NT).
>>>>>
>>>>>
>>>>> Thanks,
>>>>> - Jay
>>>>>
>>>>> ----------------------------------------
>>>>>> From: darko at darko.org
>>>>>> Date: Thu, 17 Jun 2010 18:08:14 -0700
>>>>>> To: jay.krell at cornell.edu
>>>>>> CC: m3devel at elegosoft.com
>>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>>>
>>>>>> I've been interested in an ARM port for some time. If you (or anyone else) are interested in doing the port I can send you one of these, which looks like a good platform since it runs Linux and Android, has 512K memory and looks well supported: http://beagleboard.org/hardware
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 20/05/2010, at 4:47 AM, 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?
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>
>
 		 	   		  

From darko at darko.org  Sun Jun 20 02:06:11 2010
From: darko at darko.org (Darko)
Date: Sat, 19 Jun 2010 17:06:11 -0700
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <COL101-W29BA9D3680CFB903430A43E6C10@phx.gbl>
References: <1274350133.8902.0.camel@localhost>, , , , , ,
	<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>, , , , , ,
	<2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>, , , , ,
	<COL101-W580FCB4C956AC658A851ABE6C00@phx.gbl>, , , , ,
	<44CCDCF6-BACE-4B58-A1F5-EF68A852E2A5@darko.org>, , , ,
	<COL101-W493D8FFD71EB43948CBE8CE6C10@phx.gbl>, , , ,
	<B4638299-A29A-454B-9931-4F296F9AD3DB@darko.org>, , ,
	<COL101-W7F2C05F30E9F3525E482DE6C10@phx.gbl>, , ,
	<ED46DCAD-C84A-488C-BF6F-70CA1F24AF3B@darko.org>, ,
	<COL101-W5474F17968788325FFA76CE6C10@phx.gbl>, ,
	<5E055C3D-78F6-4C08-86D9-8B8CA86B11A1@darko.org>, ,
	<C76EF524-6048-4C61-9744-6797BBA6C552@darko.org>,
	<COL101-W31787A72294920C0484E63E6C10@phx.gbl>,
	<C1506F07-DE5E-4712-B15E-CB220A087D1A@darko.org>
	<COL101-W29BA9D3680CFB903430A43E6C10@phx.gbl>
Message-ID: <6DCF6CCC-D3D3-4777-9585-243366375634@darko.org>

A fully crossed system would be the goal since mostly the target devices are ARM are phones, tablets and embedded devices. What distribution are you running on QEmu? Is it the Lenny-lxde one?

Linux/ARM is definitely fractured because of the variety of ARM cores, SoC chips and devices on which it's used. I'm not sure what the best way to approach it is.


On 19/06/2010, at 4:42 PM, Jay K wrote:


I should point out, actually, with cross gcc/as, you should be able to easily enough build the whole system cross.
ie: your apps instead of cm3.
I can try that -- building the whole tree cross, including compiling C and linking.


Notice m3-sys/cminstall/src/config-no-install/ARMEL_LINUX:


SYSTEM_CC = "arm-linux-gnueabi-gcc -gstabs+ -fPIC" % C compiler
SYSTEM_ASM = "arm-linux-gnueabi-as" % Assembler


I get to:
jay at xlin2:~/cm3-boot-ARMEL_LINUX-d5.8.2-20100619$ file cm3
cm3: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.14, not stripped
jay at xlin2:~/cm3-boot-ARMEL_LINUX-d5.8.2-20100619$ qemu-arm ./cm3
/lib/ld-linux.so.3: No such file or directory


My QEmu setup isn't complete..


I got the crosstools from hereabouts:
  http://www.emdebian.org/tools/crosstools.html


crosstool, scratchbox, buildroot may also be good options.


This reminds me though, I have a Western Digital MyBook World Edition.
Haven't powered it on in a while, slightly flaky device.
But it runs Linux/arm (oldabi).
I could/should power it on or get a new one something.


Also note/reminder, Android seems a bit different, at least in terms of finding C headers and libraries, maybe not for generating assembly, than "regular" Linux/arm.
Really "Linux/arm" seems a pretty fractured thing.
Newer architectures have floating point, for one thing.


 - Jay

----------------------------------------
> From: darko at darko.org
> Date: Sat, 19 Jun 2010 15:47:24 -0700
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Linux/ARM? Android?
> 
> Fantasic, thanks. There are some ARM cross tools available under DarwinPorts which I'm going to give this a try with.
> 
> 
> On 19/06/2010, at 2:51 AM, Jay K wrote:
> 
> 
> Eh I guess I should try that then. Ok. Thanks. Gotta take a break for a while.
> cd wherever
> cvs -z3 upd -dAP
> cd scripts/python
> ./boot1.py ARMEL_LINUX
> => cm3-boot-ARMEL_LINUX...tgz
> extract that on a machine with cross tools (e.g. arm-linux-gnueabi-gcc, arm-linux-gnueabi-as), possibly the same machine as already on
> cd into it
> make
> => arm cm3
> 
> 
> I got that far.
> I can't claim it is right for Android.
> 
> 
> Then put that cm3 onto a real (or emulated) ARM system and...
> (cvs checkout, put the cm3 in /cm3/bin or such, add that to $PATH, and scripts/python/boot2.sh)
> 
> 
> Moving forward to gcc 4.5 will get us atomics for ARM, sort of, at least on Linux, see:
> http://gcc.gnu.org/wiki/Atomic
> 
> 
> - Jay
> 
> ----------------------------------------
>> From: darko at darko.org
>> Date: Sat, 19 Jun 2010 02:15:17 -0700
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Linux/ARM? Android?
>> 
>> I should also mention that the Android SDK has a QEMU based emulator for testing applications and the adb (Android Bridge) tool can provide shell access.
>> 
>> 
>> On 19/06/2010, at 12:13 AM, Darko wrote:
>> 
>> I got the first Debian image on http://www.oszoo.org/wiki/index.php/Category:ARM_images to run with a GUI, and it connect to the network. I'm using Q on my 2.4Ghz MacBook 13" and it's surprisingly fast. Note that it's a 10GB image (450MB download).
>> 
>> There are also images for Debian MIPS on that site too.
>> 
>> I agree that the new MacBook trackpad is not perfect and since moving from my previous machine that had a separate button I now get a lot of stray gestures doing odd things. The general solution is not to use the button at all and use taps. The new momentum scrolling with the gesture is neat but needs more "weight". Unfortunately Apple crosses over into form-over-function territory from time to time and this is one of those times.
>> 
>> 
>> On 18/06/2010, at 11:18 PM, Jay K wrote:
>> 
>> 
>> XP when I can; nothing else comes close for searching and editing text, I've tried many.
>> Visual C++ 5.0.
>> I recently learned how to copy/paste in vi, which helps, but I'm not sure I remember now.
>> 
>> 
>> Darwin/amd64 when I need/want posix/fastfork, which unfortunately is often.
>> Cygwin is slow.
>> TextWrangler usually there, though it is awful compared to Visual C++ 5.0.
>> KomodoEdit is cross platform but also fairly impaired.
>> ssh access to a variety
>> Linux=Debian, it has among the best support for a variety of platforms.
>> Gentoo comes close or better (ppc64) but I've never been able to get it to install -- booting always fails.
>> Debian/x86 easy to get cross compiler, qemu, etc.
>> 
>> 
>> X Windows apps are never very good imho, so just give up and make do with the even worse command line..
>> I find things as basic as scrollbars do not work well -- which button do I press when?
>> The Modula-3 GUI apps suffer from this problem as well.
>> Further damage due to needing three buttons but not having them.
>> 
>> 
>> Mouse button clicking is actually broken on modern Macs too -- they removed the mouse button from all the laptops, leaving
>> just a big pad, prone to accidental clicks at any location.. also prone to accidental multitouch gestures due to resting
>> a twitchy thumb where the button is supposed to be. Amazing, really, the mouse, one of their key initial advantages,
>> is now broken. (see also Finder and file open dialogs, two other former strengths that are now not so great.)
>> Multitouch scroll is nice though.
>> 
>> 
>> - Jay
>> 
>> ----------------------------------------
>>> From: darko at darko.org
>>> Date: Fri, 18 Jun 2010 22:55:24 -0700
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>> 
>>> Yeah I've got it working on the console but I agree it needs the network.
>>> 
>>> Try: http://www.oszoo.org/wiki/index.php/Category:ARM_images
>>> Also: http://www.armedslack.org/
>>> 
>>> What platform are you running on these days?
>>> 
>>> 
>>> 
>>> 
>>> On 18/06/2010, at 10:44 PM, Jay K wrote:
>>> 
>>> 
>>> Interesting, thanks.
>>> But it looks like it needs to use local console for output?
>>> I need something over the network/X.
>>> It looks like there's an qemu option for usemode only too.
>>> 
>>> - Jay
>>> 
>>> ----------------------------------------
>>>> From: darko at darko.org
>>>> Date: Fri, 18 Jun 2010 22:13:43 -0700
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>> 
>>>> If you use qemu, this might be useful: http://free-electrons.com/community/demos/qemu-arm-directfb/
>>>> 
>>>> I'm currently looking at some cheap laptops (around $100) which have ethernet plus screen, keyboard, battery, etc which would work well as hosts. Just trying to find one that runs both Linux and Android.
>>>> 
>>>> 
>>>> On 18/06/2010, at 10:04 PM, Jay K wrote:
>>>> 
>>>> 
>>>> Thanks. I'll give qemu a go as well.
>>>> Hey, maybe we can get mips also. (there's decent modern mips/linux hardware now, Chinese laptops)
>>>> 
>>>> - Jay
>>>> 
>>>> ----------------------------------------
>>>>> From: darko at darko.org
>>>>> Date: Thu, 17 Jun 2010 21:41:59 -0700
>>>>> To: jay.krell at cornell.edu
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>> 
>>>>> Ok, the link here is about 20/4Mbs so it shouldn't be too bad and the latency is good. I'm in Mountain View, CA. Unfortunately the board has only 128MB of main memory but I assume that's enough, I think a self hosted compiler has no point.
>>>>> 
>>>>> I'll post the details when it's up and running.
>>>>> 
>>>>> 
>>>>> On 17/06/2010, at 9:15 PM, Jay K wrote:
>>>>> 
>>>>> 
>>>>> My preference would be if you can set it up on the internet and allow me ssh access.
>>>>> gcc only recently got support for Android's C library "bionic", I believe post-gcc 4.5.
>>>>> I'm not sure if that matters much or not.
>>>>> I'm not sure how much the C library of the target matters to gcc.
>>>>> 
>>>>> 
>>>>> Anything with pthreads and gcc support is quite easy to port to these days. In the past the biggest thing you had to do was rewrite /usr/include in Modula-3. There was a tendency to rewrite far more of it than necessary. These days, none of it is needed.
>>>>> 
>>>>> 
>>>>> Now you just have to
>>>>> - pick a target name
>>>>> - find the jmpbuf size, word size, endian
>>>>> - write a much small "config" file
>>>>> - respond to each error that occurs -- fill in the platform in a few tables sprinkled around the tree
>>>>> 
>>>>> 
>>>>> Even systems without pthreads or with not very good pthreads (OpenBSD) are easy now, as the user thread support is much more portable. It used to be, for user threads, you had to poke around in the jmpbuf.
>>>>> 
>>>>> 
>>>>> I would encourage anyone else to try it out.
>>>>> 
>>>>> 
>>>>> Maybe soon there will be a C generating backend, and we'll just have one distribution format that is a bunch of C, and then gcc support won't even be needed (e.g. IA64_NT).
>>>>> 
>>>>> 
>>>>> Thanks,
>>>>> - Jay
>>>>> 
>>>>> ----------------------------------------
>>>>>> From: darko at darko.org
>>>>>> Date: Thu, 17 Jun 2010 18:08:14 -0700
>>>>>> To: jay.krell at cornell.edu
>>>>>> CC: m3devel at elegosoft.com
>>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>>> 
>>>>>> I've been interested in an ARM port for some time. If you (or anyone else) are interested in doing the port I can send you one of these, which looks like a good platform since it runs Linux and Android, has 512K memory and looks well supported: http://beagleboard.org/hardware
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On 20/05/2010, at 4:47 AM, 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?
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
>> 
> 
> 
		 	   		  



From jay.krell at cornell.edu  Sun Jun 20 02:26:04 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 20 Jun 2010 00:26:04 +0000
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <6DCF6CCC-D3D3-4777-9585-243366375634@darko.org>
References: <1274350133.8902.0.camel@localhost>, , , , ,
	,,<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>, , , , ,
	,,<2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>, , , ,
	,,<COL101-W580FCB4C956AC658A851ABE6C00@phx.gbl>, , , ,
	,,<44CCDCF6-BACE-4B58-A1F5-EF68A852E2A5@darko.org>, , ,
	,,<COL101-W493D8FFD71EB43948CBE8CE6C10@phx.gbl>, , ,
	,,<B4638299-A29A-454B-9931-4F296F9AD3DB@darko.org>, ,
	,,<COL101-W7F2C05F30E9F3525E482DE6C10@phx.gbl>, ,
	,,<ED46DCAD-C84A-488C-BF6F-70CA1F24AF3B@darko.org>,
	,,<COL101-W5474F17968788325FFA76CE6C10@phx.gbl>,
	,,<5E055C3D-78F6-4C08-86D9-8B8CA86B11A1@darko.org>,
	, , <C76EF524-6048-4C61-9744-6797BBA6C552@darko.org>, ,
	<COL101-W31787A72294920C0484E63E6C10@phx.gbl>, ,
	<C1506F07-DE5E-4712-B15E-CB220A087D1A@darko.org>,
	<COL101-W29BA9D3680CFB903430A43E6C10@phx.gbl>,
	<6DCF6CCC-D3D3-4777-9585-243366375634@darko.org>
Message-ID: <COL101-W475B32E6802996894EA650E6C20@phx.gbl>


I didn't know what "lxde" is, but Debian 5.0 x86 "Lenny". Minimal install plus apt-get install whatever.

?- Jay

----------------------------------------
> From: darko at darko.org
> Date: Sat, 19 Jun 2010 17:06:11 -0700
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Linux/ARM? Android?
>
> A fully crossed system would be the goal since mostly the target devices are ARM are phones, tablets and embedded devices. What distribution are you running on QEmu? Is it the Lenny-lxde one?
>
> Linux/ARM is definitely fractured because of the variety of ARM cores, SoC chips and devices on which it's used. I'm not sure what the best way to approach it is.
>
>
> On 19/06/2010, at 4:42 PM, Jay K wrote:
>
>
> I should point out, actually, with cross gcc/as, you should be able to easily enough build the whole system cross.
> ie: your apps instead of cm3.
> I can try that -- building the whole tree cross, including compiling C and linking.
>
>
> Notice m3-sys/cminstall/src/config-no-install/ARMEL_LINUX:
>
>
> SYSTEM_CC = "arm-linux-gnueabi-gcc -gstabs+ -fPIC" % C compiler
> SYSTEM_ASM = "arm-linux-gnueabi-as" % Assembler
>
>
> I get to:
> jay at xlin2:~/cm3-boot-ARMEL_LINUX-d5.8.2-20100619$ file cm3
> cm3: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.14, not stripped
> jay at xlin2:~/cm3-boot-ARMEL_LINUX-d5.8.2-20100619$ qemu-arm ./cm3
> /lib/ld-linux.so.3: No such file or directory
>
>
> My QEmu setup isn't complete..
>
>
> I got the crosstools from hereabouts:
> http://www.emdebian.org/tools/crosstools.html
>
>
> crosstool, scratchbox, buildroot may also be good options.
>
>
> This reminds me though, I have a Western Digital MyBook World Edition.
> Haven't powered it on in a while, slightly flaky device.
> But it runs Linux/arm (oldabi).
> I could/should power it on or get a new one something.
>
>
> Also note/reminder, Android seems a bit different, at least in terms of finding C headers and libraries, maybe not for generating assembly, than "regular" Linux/arm.
> Really "Linux/arm" seems a pretty fractured thing.
> Newer architectures have floating point, for one thing.
>
>
> - Jay
>
> ----------------------------------------
>> From: darko at darko.org
>> Date: Sat, 19 Jun 2010 15:47:24 -0700
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Linux/ARM? Android?
>>
>> Fantasic, thanks. There are some ARM cross tools available under DarwinPorts which I'm going to give this a try with.
>>
>>
>> On 19/06/2010, at 2:51 AM, Jay K wrote:
>>
>>
>> Eh I guess I should try that then. Ok. Thanks. Gotta take a break for a while.
>> cd wherever
>> cvs -z3 upd -dAP
>> cd scripts/python
>> ./boot1.py ARMEL_LINUX
>> => cm3-boot-ARMEL_LINUX...tgz
>> extract that on a machine with cross tools (e.g. arm-linux-gnueabi-gcc, arm-linux-gnueabi-as), possibly the same machine as already on
>> cd into it
>> make
>> => arm cm3
>>
>>
>> I got that far.
>> I can't claim it is right for Android.
>>
>>
>> Then put that cm3 onto a real (or emulated) ARM system and...
>> (cvs checkout, put the cm3 in /cm3/bin or such, add that to $PATH, and scripts/python/boot2.sh)
>>
>>
>> Moving forward to gcc 4.5 will get us atomics for ARM, sort of, at least on Linux, see:
>> http://gcc.gnu.org/wiki/Atomic
>>
>>
>> - Jay
>>
>> ----------------------------------------
>>> From: darko at darko.org
>>> Date: Sat, 19 Jun 2010 02:15:17 -0700
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>
>>> I should also mention that the Android SDK has a QEMU based emulator for testing applications and the adb (Android Bridge) tool can provide shell access.
>>>
>>>
>>> On 19/06/2010, at 12:13 AM, Darko wrote:
>>>
>>> I got the first Debian image on http://www.oszoo.org/wiki/index.php/Category:ARM_images to run with a GUI, and it connect to the network. I'm using Q on my 2.4Ghz MacBook 13" and it's surprisingly fast. Note that it's a 10GB image (450MB download).
>>>
>>> There are also images for Debian MIPS on that site too.
>>>
>>> I agree that the new MacBook trackpad is not perfect and since moving from my previous machine that had a separate button I now get a lot of stray gestures doing odd things. The general solution is not to use the button at all and use taps. The new momentum scrolling with the gesture is neat but needs more "weight". Unfortunately Apple crosses over into form-over-function territory from time to time and this is one of those times.
>>>
>>>
>>> On 18/06/2010, at 11:18 PM, Jay K wrote:
>>>
>>>
>>> XP when I can; nothing else comes close for searching and editing text, I've tried many.
>>> Visual C++ 5.0.
>>> I recently learned how to copy/paste in vi, which helps, but I'm not sure I remember now.
>>>
>>>
>>> Darwin/amd64 when I need/want posix/fastfork, which unfortunately is often.
>>> Cygwin is slow.
>>> TextWrangler usually there, though it is awful compared to Visual C++ 5.0.
>>> KomodoEdit is cross platform but also fairly impaired.
>>> ssh access to a variety
>>> Linux=Debian, it has among the best support for a variety of platforms.
>>> Gentoo comes close or better (ppc64) but I've never been able to get it to install -- booting always fails.
>>> Debian/x86 easy to get cross compiler, qemu, etc.
>>>
>>>
>>> X Windows apps are never very good imho, so just give up and make do with the even worse command line..
>>> I find things as basic as scrollbars do not work well -- which button do I press when?
>>> The Modula-3 GUI apps suffer from this problem as well.
>>> Further damage due to needing three buttons but not having them.
>>>
>>>
>>> Mouse button clicking is actually broken on modern Macs too -- they removed the mouse button from all the laptops, leaving
>>> just a big pad, prone to accidental clicks at any location.. also prone to accidental multitouch gestures due to resting
>>> a twitchy thumb where the button is supposed to be. Amazing, really, the mouse, one of their key initial advantages,
>>> is now broken. (see also Finder and file open dialogs, two other former strengths that are now not so great.)
>>> Multitouch scroll is nice though.
>>>
>>>
>>> - Jay
>>>
>>> ----------------------------------------
>>>> From: darko at darko.org
>>>> Date: Fri, 18 Jun 2010 22:55:24 -0700
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>
>>>> Yeah I've got it working on the console but I agree it needs the network.
>>>>
>>>> Try: http://www.oszoo.org/wiki/index.php/Category:ARM_images
>>>> Also: http://www.armedslack.org/
>>>>
>>>> What platform are you running on these days?
>>>>
>>>>
>>>>
>>>>
>>>> On 18/06/2010, at 10:44 PM, Jay K wrote:
>>>>
>>>>
>>>> Interesting, thanks.
>>>> But it looks like it needs to use local console for output?
>>>> I need something over the network/X.
>>>> It looks like there's an qemu option for usemode only too.
>>>>
>>>> - Jay
>>>>
>>>> ----------------------------------------
>>>>> From: darko at darko.org
>>>>> Date: Fri, 18 Jun 2010 22:13:43 -0700
>>>>> To: jay.krell at cornell.edu
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>>
>>>>> If you use qemu, this might be useful: http://free-electrons.com/community/demos/qemu-arm-directfb/
>>>>>
>>>>> I'm currently looking at some cheap laptops (around $100) which have ethernet plus screen, keyboard, battery, etc which would work well as hosts. Just trying to find one that runs both Linux and Android.
>>>>>
>>>>>
>>>>> On 18/06/2010, at 10:04 PM, Jay K wrote:
>>>>>
>>>>>
>>>>> Thanks. I'll give qemu a go as well.
>>>>> Hey, maybe we can get mips also. (there's decent modern mips/linux hardware now, Chinese laptops)
>>>>>
>>>>> - Jay
>>>>>
>>>>> ----------------------------------------
>>>>>> From: darko at darko.org
>>>>>> Date: Thu, 17 Jun 2010 21:41:59 -0700
>>>>>> To: jay.krell at cornell.edu
>>>>>> CC: m3devel at elegosoft.com
>>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>>>
>>>>>> Ok, the link here is about 20/4Mbs so it shouldn't be too bad and the latency is good. I'm in Mountain View, CA. Unfortunately the board has only 128MB of main memory but I assume that's enough, I think a self hosted compiler has no point.
>>>>>>
>>>>>> I'll post the details when it's up and running.
>>>>>>
>>>>>>
>>>>>> On 17/06/2010, at 9:15 PM, Jay K wrote:
>>>>>>
>>>>>>
>>>>>> My preference would be if you can set it up on the internet and allow me ssh access.
>>>>>> gcc only recently got support for Android's C library "bionic", I believe post-gcc 4.5.
>>>>>> I'm not sure if that matters much or not.
>>>>>> I'm not sure how much the C library of the target matters to gcc.
>>>>>>
>>>>>>
>>>>>> Anything with pthreads and gcc support is quite easy to port to these days. In the past the biggest thing you had to do was rewrite /usr/include in Modula-3. There was a tendency to rewrite far more of it than necessary. These days, none of it is needed.
>>>>>>
>>>>>>
>>>>>> Now you just have to
>>>>>> - pick a target name
>>>>>> - find the jmpbuf size, word size, endian
>>>>>> - write a much small "config" file
>>>>>> - respond to each error that occurs -- fill in the platform in a few tables sprinkled around the tree
>>>>>>
>>>>>>
>>>>>> Even systems without pthreads or with not very good pthreads (OpenBSD) are easy now, as the user thread support is much more portable. It used to be, for user threads, you had to poke around in the jmpbuf.
>>>>>>
>>>>>>
>>>>>> I would encourage anyone else to try it out.
>>>>>>
>>>>>>
>>>>>> Maybe soon there will be a C generating backend, and we'll just have one distribution format that is a bunch of C, and then gcc support won't even be needed (e.g. IA64_NT).
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> - Jay
>>>>>>
>>>>>> ----------------------------------------
>>>>>>> From: darko at darko.org
>>>>>>> Date: Thu, 17 Jun 2010 18:08:14 -0700
>>>>>>> To: jay.krell at cornell.edu
>>>>>>> CC: m3devel at elegosoft.com
>>>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>>>>
>>>>>>> I've been interested in an ARM port for some time. If you (or anyone else) are interested in doing the port I can send you one of these, which looks like a good platform since it runs Linux and Android, has 512K memory and looks well supported: http://beagleboard.org/hardware
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 20/05/2010, at 4:47 AM, 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?
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>
 		 	   		  

From darko at darko.org  Sun Jun 20 02:30:12 2010
From: darko at darko.org (Darko)
Date: Sat, 19 Jun 2010 17:30:12 -0700
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <COL101-W475B32E6802996894EA650E6C20@phx.gbl>
References: <1274350133.8902.0.camel@localhost>, , , , , , ,
	<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>, , , , , , ,
	<2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>, , , , , ,
	<COL101-W580FCB4C956AC658A851ABE6C00@phx.gbl>, , , , , ,
	<44CCDCF6-BACE-4B58-A1F5-EF68A852E2A5@darko.org>, , , , ,
	<COL101-W493D8FFD71EB43948CBE8CE6C10@phx.gbl>, , , , ,
	<B4638299-A29A-454B-9931-4F296F9AD3DB@darko.org>, , , ,
	<COL101-W7F2C05F30E9F3525E482DE6C10@phx.gbl>, , , ,
	<ED46DCAD-C84A-488C-BF6F-70CA1F24AF3B@darko.org>, , ,
	<COL101-W5474F17968788325FFA76CE6C10@phx.gbl>, , ,
	<5E055C3D-78F6-4C08-86D9-8B8CA86B11A1@darko.org>, , ,
	<C76EF524-6048-4C61-9744-6797BBA6C552@darko.org>, ,
	<COL101-W31787A72294920C0484E63E6C10@phx.gbl>, ,
	<C1506F07-DE5E-4712-B15E-CB220A087D1A@darko.org>,
	<COL101-W29BA9D3680CFB903430A43E6C10@phx.gbl>,
	<6DCF6CCC-D3D3-4777-9585-243366375634@darko.org>
	<COL101-W475B32E6802996894EA650E6C20@phx.gbl>
Message-ID: <12B75D75-60FC-48DD-9364-2F22E04CA598@darko.org>

I mean as your ARM platform. Which ARM distribution are you running on QEmu?


On 19/06/2010, at 5:26 PM, Jay K wrote:


I didn't know what "lxde" is, but Debian 5.0 x86 "Lenny". Minimal install plus apt-get install whatever.

 - Jay

----------------------------------------
> From: darko at darko.org
> Date: Sat, 19 Jun 2010 17:06:11 -0700
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Linux/ARM? Android?
> 
> A fully crossed system would be the goal since mostly the target devices are ARM are phones, tablets and embedded devices. What distribution are you running on QEmu? Is it the Lenny-lxde one?
> 
> Linux/ARM is definitely fractured because of the variety of ARM cores, SoC chips and devices on which it's used. I'm not sure what the best way to approach it is.
> 
> 
> On 19/06/2010, at 4:42 PM, Jay K wrote:
> 
> 
> I should point out, actually, with cross gcc/as, you should be able to easily enough build the whole system cross.
> ie: your apps instead of cm3.
> I can try that -- building the whole tree cross, including compiling C and linking.
> 
> 
> Notice m3-sys/cminstall/src/config-no-install/ARMEL_LINUX:
> 
> 
> SYSTEM_CC = "arm-linux-gnueabi-gcc -gstabs+ -fPIC" % C compiler
> SYSTEM_ASM = "arm-linux-gnueabi-as" % Assembler
> 
> 
> I get to:
> jay at xlin2:~/cm3-boot-ARMEL_LINUX-d5.8.2-20100619$ file cm3
> cm3: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.14, not stripped
> jay at xlin2:~/cm3-boot-ARMEL_LINUX-d5.8.2-20100619$ qemu-arm ./cm3
> /lib/ld-linux.so.3: No such file or directory
> 
> 
> My QEmu setup isn't complete..
> 
> 
> I got the crosstools from hereabouts:
> http://www.emdebian.org/tools/crosstools.html
> 
> 
> crosstool, scratchbox, buildroot may also be good options.
> 
> 
> This reminds me though, I have a Western Digital MyBook World Edition.
> Haven't powered it on in a while, slightly flaky device.
> But it runs Linux/arm (oldabi).
> I could/should power it on or get a new one something.
> 
> 
> Also note/reminder, Android seems a bit different, at least in terms of finding C headers and libraries, maybe not for generating assembly, than "regular" Linux/arm.
> Really "Linux/arm" seems a pretty fractured thing.
> Newer architectures have floating point, for one thing.
> 
> 
> - Jay
> 
> ----------------------------------------
>> From: darko at darko.org
>> Date: Sat, 19 Jun 2010 15:47:24 -0700
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Linux/ARM? Android?
>> 
>> Fantasic, thanks. There are some ARM cross tools available under DarwinPorts which I'm going to give this a try with.
>> 
>> 
>> On 19/06/2010, at 2:51 AM, Jay K wrote:
>> 
>> 
>> Eh I guess I should try that then. Ok. Thanks. Gotta take a break for a while.
>> cd wherever
>> cvs -z3 upd -dAP
>> cd scripts/python
>> ./boot1.py ARMEL_LINUX
>> => cm3-boot-ARMEL_LINUX...tgz
>> extract that on a machine with cross tools (e.g. arm-linux-gnueabi-gcc, arm-linux-gnueabi-as), possibly the same machine as already on
>> cd into it
>> make
>> => arm cm3
>> 
>> 
>> I got that far.
>> I can't claim it is right for Android.
>> 
>> 
>> Then put that cm3 onto a real (or emulated) ARM system and...
>> (cvs checkout, put the cm3 in /cm3/bin or such, add that to $PATH, and scripts/python/boot2.sh)
>> 
>> 
>> Moving forward to gcc 4.5 will get us atomics for ARM, sort of, at least on Linux, see:
>> http://gcc.gnu.org/wiki/Atomic
>> 
>> 
>> - Jay
>> 
>> ----------------------------------------
>>> From: darko at darko.org
>>> Date: Sat, 19 Jun 2010 02:15:17 -0700
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>> 
>>> I should also mention that the Android SDK has a QEMU based emulator for testing applications and the adb (Android Bridge) tool can provide shell access.
>>> 
>>> 
>>> On 19/06/2010, at 12:13 AM, Darko wrote:
>>> 
>>> I got the first Debian image on http://www.oszoo.org/wiki/index.php/Category:ARM_images to run with a GUI, and it connect to the network. I'm using Q on my 2.4Ghz MacBook 13" and it's surprisingly fast. Note that it's a 10GB image (450MB download).
>>> 
>>> There are also images for Debian MIPS on that site too.
>>> 
>>> I agree that the new MacBook trackpad is not perfect and since moving from my previous machine that had a separate button I now get a lot of stray gestures doing odd things. The general solution is not to use the button at all and use taps. The new momentum scrolling with the gesture is neat but needs more "weight". Unfortunately Apple crosses over into form-over-function territory from time to time and this is one of those times.
>>> 
>>> 
>>> On 18/06/2010, at 11:18 PM, Jay K wrote:
>>> 
>>> 
>>> XP when I can; nothing else comes close for searching and editing text, I've tried many.
>>> Visual C++ 5.0.
>>> I recently learned how to copy/paste in vi, which helps, but I'm not sure I remember now.
>>> 
>>> 
>>> Darwin/amd64 when I need/want posix/fastfork, which unfortunately is often.
>>> Cygwin is slow.
>>> TextWrangler usually there, though it is awful compared to Visual C++ 5.0.
>>> KomodoEdit is cross platform but also fairly impaired.
>>> ssh access to a variety
>>> Linux=Debian, it has among the best support for a variety of platforms.
>>> Gentoo comes close or better (ppc64) but I've never been able to get it to install -- booting always fails.
>>> Debian/x86 easy to get cross compiler, qemu, etc.
>>> 
>>> 
>>> X Windows apps are never very good imho, so just give up and make do with the even worse command line..
>>> I find things as basic as scrollbars do not work well -- which button do I press when?
>>> The Modula-3 GUI apps suffer from this problem as well.
>>> Further damage due to needing three buttons but not having them.
>>> 
>>> 
>>> Mouse button clicking is actually broken on modern Macs too -- they removed the mouse button from all the laptops, leaving
>>> just a big pad, prone to accidental clicks at any location.. also prone to accidental multitouch gestures due to resting
>>> a twitchy thumb where the button is supposed to be. Amazing, really, the mouse, one of their key initial advantages,
>>> is now broken. (see also Finder and file open dialogs, two other former strengths that are now not so great.)
>>> Multitouch scroll is nice though.
>>> 
>>> 
>>> - Jay
>>> 
>>> ----------------------------------------
>>>> From: darko at darko.org
>>>> Date: Fri, 18 Jun 2010 22:55:24 -0700
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>> 
>>>> Yeah I've got it working on the console but I agree it needs the network.
>>>> 
>>>> Try: http://www.oszoo.org/wiki/index.php/Category:ARM_images
>>>> Also: http://www.armedslack.org/
>>>> 
>>>> What platform are you running on these days?
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On 18/06/2010, at 10:44 PM, Jay K wrote:
>>>> 
>>>> 
>>>> Interesting, thanks.
>>>> But it looks like it needs to use local console for output?
>>>> I need something over the network/X.
>>>> It looks like there's an qemu option for usemode only too.
>>>> 
>>>> - Jay
>>>> 
>>>> ----------------------------------------
>>>>> From: darko at darko.org
>>>>> Date: Fri, 18 Jun 2010 22:13:43 -0700
>>>>> To: jay.krell at cornell.edu
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>> 
>>>>> If you use qemu, this might be useful: http://free-electrons.com/community/demos/qemu-arm-directfb/
>>>>> 
>>>>> I'm currently looking at some cheap laptops (around $100) which have ethernet plus screen, keyboard, battery, etc which would work well as hosts. Just trying to find one that runs both Linux and Android.
>>>>> 
>>>>> 
>>>>> On 18/06/2010, at 10:04 PM, Jay K wrote:
>>>>> 
>>>>> 
>>>>> Thanks. I'll give qemu a go as well.
>>>>> Hey, maybe we can get mips also. (there's decent modern mips/linux hardware now, Chinese laptops)
>>>>> 
>>>>> - Jay
>>>>> 
>>>>> ----------------------------------------
>>>>>> From: darko at darko.org
>>>>>> Date: Thu, 17 Jun 2010 21:41:59 -0700
>>>>>> To: jay.krell at cornell.edu
>>>>>> CC: m3devel at elegosoft.com
>>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>>> 
>>>>>> Ok, the link here is about 20/4Mbs so it shouldn't be too bad and the latency is good. I'm in Mountain View, CA. Unfortunately the board has only 128MB of main memory but I assume that's enough, I think a self hosted compiler has no point.
>>>>>> 
>>>>>> I'll post the details when it's up and running.
>>>>>> 
>>>>>> 
>>>>>> On 17/06/2010, at 9:15 PM, Jay K wrote:
>>>>>> 
>>>>>> 
>>>>>> My preference would be if you can set it up on the internet and allow me ssh access.
>>>>>> gcc only recently got support for Android's C library "bionic", I believe post-gcc 4.5.
>>>>>> I'm not sure if that matters much or not.
>>>>>> I'm not sure how much the C library of the target matters to gcc.
>>>>>> 
>>>>>> 
>>>>>> Anything with pthreads and gcc support is quite easy to port to these days. In the past the biggest thing you had to do was rewrite /usr/include in Modula-3. There was a tendency to rewrite far more of it than necessary. These days, none of it is needed.
>>>>>> 
>>>>>> 
>>>>>> Now you just have to
>>>>>> - pick a target name
>>>>>> - find the jmpbuf size, word size, endian
>>>>>> - write a much small "config" file
>>>>>> - respond to each error that occurs -- fill in the platform in a few tables sprinkled around the tree
>>>>>> 
>>>>>> 
>>>>>> Even systems without pthreads or with not very good pthreads (OpenBSD) are easy now, as the user thread support is much more portable. It used to be, for user threads, you had to poke around in the jmpbuf.
>>>>>> 
>>>>>> 
>>>>>> I would encourage anyone else to try it out.
>>>>>> 
>>>>>> 
>>>>>> Maybe soon there will be a C generating backend, and we'll just have one distribution format that is a bunch of C, and then gcc support won't even be needed (e.g. IA64_NT).
>>>>>> 
>>>>>> 
>>>>>> Thanks,
>>>>>> - Jay
>>>>>> 
>>>>>> ----------------------------------------
>>>>>>> From: darko at darko.org
>>>>>>> Date: Thu, 17 Jun 2010 18:08:14 -0700
>>>>>>> To: jay.krell at cornell.edu
>>>>>>> CC: m3devel at elegosoft.com
>>>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>>>> 
>>>>>>> I've been interested in an ARM port for some time. If you (or anyone else) are interested in doing the port I can send you one of these, which looks like a good platform since it runs Linux and Android, has 512K memory and looks well supported: http://beagleboard.org/hardware
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On 20/05/2010, at 4:47 AM, 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?
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> 
>> 
>> 
> 
> 
		 	   		  



From jay.krell at cornell.edu  Sun Jun 20 02:33:17 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 20 Jun 2010 00:33:17 +0000
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <12B75D75-60FC-48DD-9364-2F22E04CA598@darko.org>
References: <1274350133.8902.0.camel@localhost>, , , , , ,
	,,<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>, , , , , ,
	,,<2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>, , , , ,
	,,<COL101-W580FCB4C956AC658A851ABE6C00@phx.gbl>, , , , ,
	,,<44CCDCF6-BACE-4B58-A1F5-EF68A852E2A5@darko.org>, , , ,
	,,<COL101-W493D8FFD71EB43948CBE8CE6C10@phx.gbl>, , , ,
	,,<B4638299-A29A-454B-9931-4F296F9AD3DB@darko.org>, , ,
	,,<COL101-W7F2C05F30E9F3525E482DE6C10@phx.gbl>, , ,
	,,<ED46DCAD-C84A-488C-BF6F-70CA1F24AF3B@darko.org>, ,
	,,<COL101-W5474F17968788325FFA76CE6C10@phx.gbl>, ,
	,,<5E055C3D-78F6-4C08-86D9-8B8CA86B11A1@darko.org>, ,
	,,<C76EF524-6048-4C61-9744-6797BBA6C552@darko.org>,
	,,<COL101-W31787A72294920C0484E63E6C10@phx.gbl>,
	, , <C1506F07-DE5E-4712-B15E-CB220A087D1A@darko.org>, ,
	<COL101-W29BA9D3680CFB903430A43E6C10@phx.gbl>, ,
	<6DCF6CCC-D3D3-4777-9585-243366375634@darko.org>,
	<COL101-W475B32E6802996894EA650E6C20@phx.gbl>,
	<12B75D75-60FC-48DD-9364-2F22E04CA598@darko.org>
Message-ID: <COL101-W197BF4F7E1E4A1A24B1469E6C20@phx.gbl>


None?
None yet?
You are supposed to be able run user mode stuff without installing any kernel or anything.
If I emulate an entire system, can the display be remoted over X?
I never go to the Linux "console", just ssh or X over ssh.

?- Jay

----------------------------------------
> From: darko at darko.org
> Date: Sat, 19 Jun 2010 17:30:12 -0700
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Linux/ARM? Android?
>
> I mean as your ARM platform. Which ARM distribution are you running on QEmu?
>
>
> On 19/06/2010, at 5:26 PM, Jay K wrote:
>
>
> I didn't know what "lxde" is, but Debian 5.0 x86 "Lenny". Minimal install plus apt-get install whatever.
>
> - Jay
>
> ----------------------------------------
>> From: darko at darko.org
>> Date: Sat, 19 Jun 2010 17:06:11 -0700
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Linux/ARM? Android?
>>
>> A fully crossed system would be the goal since mostly the target devices are ARM are phones, tablets and embedded devices. What distribution are you running on QEmu? Is it the Lenny-lxde one?
>>
>> Linux/ARM is definitely fractured because of the variety of ARM cores, SoC chips and devices on which it's used. I'm not sure what the best way to approach it is.
>>
>>
>> On 19/06/2010, at 4:42 PM, Jay K wrote:
>>
>>
>> I should point out, actually, with cross gcc/as, you should be able to easily enough build the whole system cross.
>> ie: your apps instead of cm3.
>> I can try that -- building the whole tree cross, including compiling C and linking.
>>
>>
>> Notice m3-sys/cminstall/src/config-no-install/ARMEL_LINUX:
>>
>>
>> SYSTEM_CC = "arm-linux-gnueabi-gcc -gstabs+ -fPIC" % C compiler
>> SYSTEM_ASM = "arm-linux-gnueabi-as" % Assembler
>>
>>
>> I get to:
>> jay at xlin2:~/cm3-boot-ARMEL_LINUX-d5.8.2-20100619$ file cm3
>> cm3: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.14, not stripped
>> jay at xlin2:~/cm3-boot-ARMEL_LINUX-d5.8.2-20100619$ qemu-arm ./cm3
>> /lib/ld-linux.so.3: No such file or directory
>>
>>
>> My QEmu setup isn't complete..
>>
>>
>> I got the crosstools from hereabouts:
>> http://www.emdebian.org/tools/crosstools.html
>>
>>
>> crosstool, scratchbox, buildroot may also be good options.
>>
>>
>> This reminds me though, I have a Western Digital MyBook World Edition.
>> Haven't powered it on in a while, slightly flaky device.
>> But it runs Linux/arm (oldabi).
>> I could/should power it on or get a new one something.
>>
>>
>> Also note/reminder, Android seems a bit different, at least in terms of finding C headers and libraries, maybe not for generating assembly, than "regular" Linux/arm.
>> Really "Linux/arm" seems a pretty fractured thing.
>> Newer architectures have floating point, for one thing.
>>
>>
>> - Jay
>>
>> ----------------------------------------
>>> From: darko at darko.org
>>> Date: Sat, 19 Jun 2010 15:47:24 -0700
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>
>>> Fantasic, thanks. There are some ARM cross tools available under DarwinPorts which I'm going to give this a try with.
>>>
>>>
>>> On 19/06/2010, at 2:51 AM, Jay K wrote:
>>>
>>>
>>> Eh I guess I should try that then. Ok. Thanks. Gotta take a break for a while.
>>> cd wherever
>>> cvs -z3 upd -dAP
>>> cd scripts/python
>>> ./boot1.py ARMEL_LINUX
>>> => cm3-boot-ARMEL_LINUX...tgz
>>> extract that on a machine with cross tools (e.g. arm-linux-gnueabi-gcc, arm-linux-gnueabi-as), possibly the same machine as already on
>>> cd into it
>>> make
>>> => arm cm3
>>>
>>>
>>> I got that far.
>>> I can't claim it is right for Android.
>>>
>>>
>>> Then put that cm3 onto a real (or emulated) ARM system and...
>>> (cvs checkout, put the cm3 in /cm3/bin or such, add that to $PATH, and scripts/python/boot2.sh)
>>>
>>>
>>> Moving forward to gcc 4.5 will get us atomics for ARM, sort of, at least on Linux, see:
>>> http://gcc.gnu.org/wiki/Atomic
>>>
>>>
>>> - Jay
>>>
>>> ----------------------------------------
>>>> From: darko at darko.org
>>>> Date: Sat, 19 Jun 2010 02:15:17 -0700
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>
>>>> I should also mention that the Android SDK has a QEMU based emulator for testing applications and the adb (Android Bridge) tool can provide shell access.
>>>>
>>>>
>>>> On 19/06/2010, at 12:13 AM, Darko wrote:
>>>>
>>>> I got the first Debian image on http://www.oszoo.org/wiki/index.php/Category:ARM_images to run with a GUI, and it connect to the network. I'm using Q on my 2.4Ghz MacBook 13" and it's surprisingly fast. Note that it's a 10GB image (450MB download).
>>>>
>>>> There are also images for Debian MIPS on that site too.
>>>>
>>>> I agree that the new MacBook trackpad is not perfect and since moving from my previous machine that had a separate button I now get a lot of stray gestures doing odd things. The general solution is not to use the button at all and use taps. The new momentum scrolling with the gesture is neat but needs more "weight". Unfortunately Apple crosses over into form-over-function territory from time to time and this is one of those times.
>>>>
>>>>
>>>> On 18/06/2010, at 11:18 PM, Jay K wrote:
>>>>
>>>>
>>>> XP when I can; nothing else comes close for searching and editing text, I've tried many.
>>>> Visual C++ 5.0.
>>>> I recently learned how to copy/paste in vi, which helps, but I'm not sure I remember now.
>>>>
>>>>
>>>> Darwin/amd64 when I need/want posix/fastfork, which unfortunately is often.
>>>> Cygwin is slow.
>>>> TextWrangler usually there, though it is awful compared to Visual C++ 5.0.
>>>> KomodoEdit is cross platform but also fairly impaired.
>>>> ssh access to a variety
>>>> Linux=Debian, it has among the best support for a variety of platforms.
>>>> Gentoo comes close or better (ppc64) but I've never been able to get it to install -- booting always fails.
>>>> Debian/x86 easy to get cross compiler, qemu, etc.
>>>>
>>>>
>>>> X Windows apps are never very good imho, so just give up and make do with the even worse command line..
>>>> I find things as basic as scrollbars do not work well -- which button do I press when?
>>>> The Modula-3 GUI apps suffer from this problem as well.
>>>> Further damage due to needing three buttons but not having them.
>>>>
>>>>
>>>> Mouse button clicking is actually broken on modern Macs too -- they removed the mouse button from all the laptops, leaving
>>>> just a big pad, prone to accidental clicks at any location.. also prone to accidental multitouch gestures due to resting
>>>> a twitchy thumb where the button is supposed to be. Amazing, really, the mouse, one of their key initial advantages,
>>>> is now broken. (see also Finder and file open dialogs, two other former strengths that are now not so great.)
>>>> Multitouch scroll is nice though.
>>>>
>>>>
>>>> - Jay
>>>>
>>>> ----------------------------------------
>>>>> From: darko at darko.org
>>>>> Date: Fri, 18 Jun 2010 22:55:24 -0700
>>>>> To: jay.krell at cornell.edu
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>>
>>>>> Yeah I've got it working on the console but I agree it needs the network.
>>>>>
>>>>> Try: http://www.oszoo.org/wiki/index.php/Category:ARM_images
>>>>> Also: http://www.armedslack.org/
>>>>>
>>>>> What platform are you running on these days?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 18/06/2010, at 10:44 PM, Jay K wrote:
>>>>>
>>>>>
>>>>> Interesting, thanks.
>>>>> But it looks like it needs to use local console for output?
>>>>> I need something over the network/X.
>>>>> It looks like there's an qemu option for usemode only too.
>>>>>
>>>>> - Jay
>>>>>
>>>>> ----------------------------------------
>>>>>> From: darko at darko.org
>>>>>> Date: Fri, 18 Jun 2010 22:13:43 -0700
>>>>>> To: jay.krell at cornell.edu
>>>>>> CC: m3devel at elegosoft.com
>>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>>>
>>>>>> If you use qemu, this might be useful: http://free-electrons.com/community/demos/qemu-arm-directfb/
>>>>>>
>>>>>> I'm currently looking at some cheap laptops (around $100) which have ethernet plus screen, keyboard, battery, etc which would work well as hosts. Just trying to find one that runs both Linux and Android.
>>>>>>
>>>>>>
>>>>>> On 18/06/2010, at 10:04 PM, Jay K wrote:
>>>>>>
>>>>>>
>>>>>> Thanks. I'll give qemu a go as well.
>>>>>> Hey, maybe we can get mips also. (there's decent modern mips/linux hardware now, Chinese laptops)
>>>>>>
>>>>>> - Jay
>>>>>>
>>>>>> ----------------------------------------
>>>>>>> From: darko at darko.org
>>>>>>> Date: Thu, 17 Jun 2010 21:41:59 -0700
>>>>>>> To: jay.krell at cornell.edu
>>>>>>> CC: m3devel at elegosoft.com
>>>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>>>>
>>>>>>> Ok, the link here is about 20/4Mbs so it shouldn't be too bad and the latency is good. I'm in Mountain View, CA. Unfortunately the board has only 128MB of main memory but I assume that's enough, I think a self hosted compiler has no point.
>>>>>>>
>>>>>>> I'll post the details when it's up and running.
>>>>>>>
>>>>>>>
>>>>>>> On 17/06/2010, at 9:15 PM, Jay K wrote:
>>>>>>>
>>>>>>>
>>>>>>> My preference would be if you can set it up on the internet and allow me ssh access.
>>>>>>> gcc only recently got support for Android's C library "bionic", I believe post-gcc 4.5.
>>>>>>> I'm not sure if that matters much or not.
>>>>>>> I'm not sure how much the C library of the target matters to gcc.
>>>>>>>
>>>>>>>
>>>>>>> Anything with pthreads and gcc support is quite easy to port to these days. In the past the biggest thing you had to do was rewrite /usr/include in Modula-3. There was a tendency to rewrite far more of it than necessary. These days, none of it is needed.
>>>>>>>
>>>>>>>
>>>>>>> Now you just have to
>>>>>>> - pick a target name
>>>>>>> - find the jmpbuf size, word size, endian
>>>>>>> - write a much small "config" file
>>>>>>> - respond to each error that occurs -- fill in the platform in a few tables sprinkled around the tree
>>>>>>>
>>>>>>>
>>>>>>> Even systems without pthreads or with not very good pthreads (OpenBSD) are easy now, as the user thread support is much more portable. It used to be, for user threads, you had to poke around in the jmpbuf.
>>>>>>>
>>>>>>>
>>>>>>> I would encourage anyone else to try it out.
>>>>>>>
>>>>>>>
>>>>>>> Maybe soon there will be a C generating backend, and we'll just have one distribution format that is a bunch of C, and then gcc support won't even be needed (e.g. IA64_NT).
>>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>> - Jay
>>>>>>>
>>>>>>> ----------------------------------------
>>>>>>>> From: darko at darko.org
>>>>>>>> Date: Thu, 17 Jun 2010 18:08:14 -0700
>>>>>>>> To: jay.krell at cornell.edu
>>>>>>>> CC: m3devel at elegosoft.com
>>>>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>>>>>
>>>>>>>> I've been interested in an ARM port for some time. If you (or anyone else) are interested in doing the port I can send you one of these, which looks like a good platform since it runs Linux and Android, has 512K memory and looks well supported: http://beagleboard.org/hardware
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 20/05/2010, at 4:47 AM, 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?
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
 		 	   		  

From darko at darko.org  Sun Jun 20 02:37:50 2010
From: darko at darko.org (Darko)
Date: Sat, 19 Jun 2010 17:37:50 -0700
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <COL101-W197BF4F7E1E4A1A24B1469E6C20@phx.gbl>
References: <1274350133.8902.0.camel@localhost>, , , , , , , ,
	<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>, , , , , , , ,
	<2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>, , , , , , ,
	<COL101-W580FCB4C956AC658A851ABE6C00@phx.gbl>, , , , , , ,
	<44CCDCF6-BACE-4B58-A1F5-EF68A852E2A5@darko.org>, , , , , ,
	<COL101-W493D8FFD71EB43948CBE8CE6C10@phx.gbl>, , , , , ,
	<B4638299-A29A-454B-9931-4F296F9AD3DB@darko.org>, , , , ,
	<COL101-W7F2C05F30E9F3525E482DE6C10@phx.gbl>, , , , ,
	<ED46DCAD-C84A-488C-BF6F-70CA1F24AF3B@darko.org>, , , ,
	<COL101-W5474F17968788325FFA76CE6C10@phx.gbl>, , , ,
	<5E055C3D-78F6-4C08-86D9-8B8CA86B11A1@darko.org>, , , ,
	<C76EF524-6048-4C61-9744-6797BBA6C552@darko.org>, , ,
	<COL101-W31787A72294920C0484E63E6C10@phx.gbl>, , ,
	<C1506F07-DE5E-4712-B15E-CB220A087D1A@darko.org>, ,
	<COL101-W29BA9D3680CFB903430A43E6C10@phx.gbl>, ,
	<6DCF6CCC-D3D3-4777-9585-243366375634@darko.org>,
	<COL101-W475B32E6802996894EA650E6C20@phx.gbl>,
	<12B75D75-60FC-48DD-9364-2F22E04CA598@darko.org>
	<COL101-W197BF4F7E1E4A1A24B1469 E6C20@phx.gbl>
Message-ID: <2DCB0C6D-D4AF-46B0-B24A-2D4F257C0696@darko.org>

This one runs X and sshd straight out of the box, on QEmu: http://www.oszoo.org/wiki/index.php/Debian_Lenny_Arm_%28Armel%29_-_with_lxde


On 19/06/2010, at 5:33 PM, Jay K wrote:


None?
None yet?
You are supposed to be able run user mode stuff without installing any kernel or anything.
If I emulate an entire system, can the display be remoted over X?
I never go to the Linux "console", just ssh or X over ssh.

 - Jay

----------------------------------------
> From: darko at darko.org
> Date: Sat, 19 Jun 2010 17:30:12 -0700
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Linux/ARM? Android?
> 
> I mean as your ARM platform. Which ARM distribution are you running on QEmu?
> 
> 
> On 19/06/2010, at 5:26 PM, Jay K wrote:
> 
> 
> I didn't know what "lxde" is, but Debian 5.0 x86 "Lenny". Minimal install plus apt-get install whatever.
> 
> - Jay
> 
> ----------------------------------------
>> From: darko at darko.org
>> Date: Sat, 19 Jun 2010 17:06:11 -0700
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] Linux/ARM? Android?
>> 
>> A fully crossed system would be the goal since mostly the target devices are ARM are phones, tablets and embedded devices. What distribution are you running on QEmu? Is it the Lenny-lxde one?
>> 
>> Linux/ARM is definitely fractured because of the variety of ARM cores, SoC chips and devices on which it's used. I'm not sure what the best way to approach it is.
>> 
>> 
>> On 19/06/2010, at 4:42 PM, Jay K wrote:
>> 
>> 
>> I should point out, actually, with cross gcc/as, you should be able to easily enough build the whole system cross.
>> ie: your apps instead of cm3.
>> I can try that -- building the whole tree cross, including compiling C and linking.
>> 
>> 
>> Notice m3-sys/cminstall/src/config-no-install/ARMEL_LINUX:
>> 
>> 
>> SYSTEM_CC = "arm-linux-gnueabi-gcc -gstabs+ -fPIC" % C compiler
>> SYSTEM_ASM = "arm-linux-gnueabi-as" % Assembler
>> 
>> 
>> I get to:
>> jay at xlin2:~/cm3-boot-ARMEL_LINUX-d5.8.2-20100619$ file cm3
>> cm3: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.14, not stripped
>> jay at xlin2:~/cm3-boot-ARMEL_LINUX-d5.8.2-20100619$ qemu-arm ./cm3
>> /lib/ld-linux.so.3: No such file or directory
>> 
>> 
>> My QEmu setup isn't complete..
>> 
>> 
>> I got the crosstools from hereabouts:
>> http://www.emdebian.org/tools/crosstools.html
>> 
>> 
>> crosstool, scratchbox, buildroot may also be good options.
>> 
>> 
>> This reminds me though, I have a Western Digital MyBook World Edition.
>> Haven't powered it on in a while, slightly flaky device.
>> But it runs Linux/arm (oldabi).
>> I could/should power it on or get a new one something.
>> 
>> 
>> Also note/reminder, Android seems a bit different, at least in terms of finding C headers and libraries, maybe not for generating assembly, than "regular" Linux/arm.
>> Really "Linux/arm" seems a pretty fractured thing.
>> Newer architectures have floating point, for one thing.
>> 
>> 
>> - Jay
>> 
>> ----------------------------------------
>>> From: darko at darko.org
>>> Date: Sat, 19 Jun 2010 15:47:24 -0700
>>> To: jay.krell at cornell.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>> 
>>> Fantasic, thanks. There are some ARM cross tools available under DarwinPorts which I'm going to give this a try with.
>>> 
>>> 
>>> On 19/06/2010, at 2:51 AM, Jay K wrote:
>>> 
>>> 
>>> Eh I guess I should try that then. Ok. Thanks. Gotta take a break for a while.
>>> cd wherever
>>> cvs -z3 upd -dAP
>>> cd scripts/python
>>> ./boot1.py ARMEL_LINUX
>>> => cm3-boot-ARMEL_LINUX...tgz
>>> extract that on a machine with cross tools (e.g. arm-linux-gnueabi-gcc, arm-linux-gnueabi-as), possibly the same machine as already on
>>> cd into it
>>> make
>>> => arm cm3
>>> 
>>> 
>>> I got that far.
>>> I can't claim it is right for Android.
>>> 
>>> 
>>> Then put that cm3 onto a real (or emulated) ARM system and...
>>> (cvs checkout, put the cm3 in /cm3/bin or such, add that to $PATH, and scripts/python/boot2.sh)
>>> 
>>> 
>>> Moving forward to gcc 4.5 will get us atomics for ARM, sort of, at least on Linux, see:
>>> http://gcc.gnu.org/wiki/Atomic
>>> 
>>> 
>>> - Jay
>>> 
>>> ----------------------------------------
>>>> From: darko at darko.org
>>>> Date: Sat, 19 Jun 2010 02:15:17 -0700
>>>> To: jay.krell at cornell.edu
>>>> CC: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>> 
>>>> I should also mention that the Android SDK has a QEMU based emulator for testing applications and the adb (Android Bridge) tool can provide shell access.
>>>> 
>>>> 
>>>> On 19/06/2010, at 12:13 AM, Darko wrote:
>>>> 
>>>> I got the first Debian image on http://www.oszoo.org/wiki/index.php/Category:ARM_images to run with a GUI, and it connect to the network. I'm using Q on my 2.4Ghz MacBook 13" and it's surprisingly fast. Note that it's a 10GB image (450MB download).
>>>> 
>>>> There are also images for Debian MIPS on that site too.
>>>> 
>>>> I agree that the new MacBook trackpad is not perfect and since moving from my previous machine that had a separate button I now get a lot of stray gestures doing odd things. The general solution is not to use the button at all and use taps. The new momentum scrolling with the gesture is neat but needs more "weight". Unfortunately Apple crosses over into form-over-function territory from time to time and this is one of those times.
>>>> 
>>>> 
>>>> On 18/06/2010, at 11:18 PM, Jay K wrote:
>>>> 
>>>> 
>>>> XP when I can; nothing else comes close for searching and editing text, I've tried many.
>>>> Visual C++ 5.0.
>>>> I recently learned how to copy/paste in vi, which helps, but I'm not sure I remember now.
>>>> 
>>>> 
>>>> Darwin/amd64 when I need/want posix/fastfork, which unfortunately is often.
>>>> Cygwin is slow.
>>>> TextWrangler usually there, though it is awful compared to Visual C++ 5.0.
>>>> KomodoEdit is cross platform but also fairly impaired.
>>>> ssh access to a variety
>>>> Linux=Debian, it has among the best support for a variety of platforms.
>>>> Gentoo comes close or better (ppc64) but I've never been able to get it to install -- booting always fails.
>>>> Debian/x86 easy to get cross compiler, qemu, etc.
>>>> 
>>>> 
>>>> X Windows apps are never very good imho, so just give up and make do with the even worse command line..
>>>> I find things as basic as scrollbars do not work well -- which button do I press when?
>>>> The Modula-3 GUI apps suffer from this problem as well.
>>>> Further damage due to needing three buttons but not having them.
>>>> 
>>>> 
>>>> Mouse button clicking is actually broken on modern Macs too -- they removed the mouse button from all the laptops, leaving
>>>> just a big pad, prone to accidental clicks at any location.. also prone to accidental multitouch gestures due to resting
>>>> a twitchy thumb where the button is supposed to be. Amazing, really, the mouse, one of their key initial advantages,
>>>> is now broken. (see also Finder and file open dialogs, two other former strengths that are now not so great.)
>>>> Multitouch scroll is nice though.
>>>> 
>>>> 
>>>> - Jay
>>>> 
>>>> ----------------------------------------
>>>>> From: darko at darko.org
>>>>> Date: Fri, 18 Jun 2010 22:55:24 -0700
>>>>> To: jay.krell at cornell.edu
>>>>> CC: m3devel at elegosoft.com
>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>> 
>>>>> Yeah I've got it working on the console but I agree it needs the network.
>>>>> 
>>>>> Try: http://www.oszoo.org/wiki/index.php/Category:ARM_images
>>>>> Also: http://www.armedslack.org/
>>>>> 
>>>>> What platform are you running on these days?
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On 18/06/2010, at 10:44 PM, Jay K wrote:
>>>>> 
>>>>> 
>>>>> Interesting, thanks.
>>>>> But it looks like it needs to use local console for output?
>>>>> I need something over the network/X.
>>>>> It looks like there's an qemu option for usemode only too.
>>>>> 
>>>>> - Jay
>>>>> 
>>>>> ----------------------------------------
>>>>>> From: darko at darko.org
>>>>>> Date: Fri, 18 Jun 2010 22:13:43 -0700
>>>>>> To: jay.krell at cornell.edu
>>>>>> CC: m3devel at elegosoft.com
>>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>>> 
>>>>>> If you use qemu, this might be useful: http://free-electrons.com/community/demos/qemu-arm-directfb/
>>>>>> 
>>>>>> I'm currently looking at some cheap laptops (around $100) which have ethernet plus screen, keyboard, battery, etc which would work well as hosts. Just trying to find one that runs both Linux and Android.
>>>>>> 
>>>>>> 
>>>>>> On 18/06/2010, at 10:04 PM, Jay K wrote:
>>>>>> 
>>>>>> 
>>>>>> Thanks. I'll give qemu a go as well.
>>>>>> Hey, maybe we can get mips also. (there's decent modern mips/linux hardware now, Chinese laptops)
>>>>>> 
>>>>>> - Jay
>>>>>> 
>>>>>> ----------------------------------------
>>>>>>> From: darko at darko.org
>>>>>>> Date: Thu, 17 Jun 2010 21:41:59 -0700
>>>>>>> To: jay.krell at cornell.edu
>>>>>>> CC: m3devel at elegosoft.com
>>>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>>>> 
>>>>>>> Ok, the link here is about 20/4Mbs so it shouldn't be too bad and the latency is good. I'm in Mountain View, CA. Unfortunately the board has only 128MB of main memory but I assume that's enough, I think a self hosted compiler has no point.
>>>>>>> 
>>>>>>> I'll post the details when it's up and running.
>>>>>>> 
>>>>>>> 
>>>>>>> On 17/06/2010, at 9:15 PM, Jay K wrote:
>>>>>>> 
>>>>>>> 
>>>>>>> My preference would be if you can set it up on the internet and allow me ssh access.
>>>>>>> gcc only recently got support for Android's C library "bionic", I believe post-gcc 4.5.
>>>>>>> I'm not sure if that matters much or not.
>>>>>>> I'm not sure how much the C library of the target matters to gcc.
>>>>>>> 
>>>>>>> 
>>>>>>> Anything with pthreads and gcc support is quite easy to port to these days. In the past the biggest thing you had to do was rewrite /usr/include in Modula-3. There was a tendency to rewrite far more of it than necessary. These days, none of it is needed.
>>>>>>> 
>>>>>>> 
>>>>>>> Now you just have to
>>>>>>> - pick a target name
>>>>>>> - find the jmpbuf size, word size, endian
>>>>>>> - write a much small "config" file
>>>>>>> - respond to each error that occurs -- fill in the platform in a few tables sprinkled around the tree
>>>>>>> 
>>>>>>> 
>>>>>>> Even systems without pthreads or with not very good pthreads (OpenBSD) are easy now, as the user thread support is much more portable. It used to be, for user threads, you had to poke around in the jmpbuf.
>>>>>>> 
>>>>>>> 
>>>>>>> I would encourage anyone else to try it out.
>>>>>>> 
>>>>>>> 
>>>>>>> Maybe soon there will be a C generating backend, and we'll just have one distribution format that is a bunch of C, and then gcc support won't even be needed (e.g. IA64_NT).
>>>>>>> 
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> - Jay
>>>>>>> 
>>>>>>> ----------------------------------------
>>>>>>>> From: darko at darko.org
>>>>>>>> Date: Thu, 17 Jun 2010 18:08:14 -0700
>>>>>>>> To: jay.krell at cornell.edu
>>>>>>>> CC: m3devel at elegosoft.com
>>>>>>>> Subject: Re: [M3devel] Linux/ARM? Android?
>>>>>>>> 
>>>>>>>> I've been interested in an ARM port for some time. If you (or anyone else) are interested in doing the port I can send you one of these, which looks like a good platform since it runs Linux and Android, has 512K memory and looks well supported: http://beagleboard.org/hardware
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On 20/05/2010, at 4:47 AM, 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?
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
> 
> 
		 	   		  



From jay.krell at cornell.edu  Sun Jun 20 04:07:21 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 20 Jun 2010 02:07:21 +0000
Subject: [M3devel] div/mod gcc builtin vs. m3core function
Message-ID: <COL101-W19658E57C608B58952727CE6C20@phx.gbl>


So..I'm debugging why 64bit mod on ARM doesn't work..changed the C compiler to use floor instead of trunc, see if it fails..see what it does.
? If it fails, I could report that as a bug.


Now, I'm nervous.
I'm nervous that gcc might sometimes use libgcc functions for div or mod, with the assumption that trunc is needed.
This would clearly be a bug in gcc.
But I'm nervous.

The implementation of div/mod varies a lot -- sometimes a function call in gcc, sometimes not.

I tested some architectures at the time..but I wonder now.

Maybe safest to just always use our functions?

I might try to prove gcc does it wrong, e.g. for ARM, with a modified C front end..but so far I can't run ARM code.

Thoughts?


jbook2:gcc jay$ grep sdiv_optab? */*/*/* 
gcc/config/alpha/alpha.c:????? set_optab_libfunc (sdiv_optab, SImode, 0);
gcc/config/alpha/alpha.c:????? set_optab_libfunc (sdiv_optab, DImode, "$sldiv");
gcc/config/alpha/alpha.c:????? set_optab_libfunc (sdiv_optab, SImode, "OTS$DIV_I");
gcc/config/alpha/alpha.c:????? set_optab_libfunc (sdiv_optab, DImode, "OTS$DIV_L");
gcc/config/alpha/alpha.md:? div = expand_binop (DImode, sdiv_optab, operands[1], operands[2],
gcc/config/arm/arm.c:? set_optab_libfunc (sdiv_optab, DFmode, "__aeabi_ddiv");
gcc/config/arm/arm.c:? set_optab_libfunc (sdiv_optab, SFmode, "__aeabi_fdiv");
gcc/config/arm/arm.c:? set_optab_libfunc (sdiv_optab, DImode, "__aeabi_ldivmod");
gcc/config/arm/arm.c:? set_optab_libfunc (sdiv_optab, SImode, "__aeabi_idiv");
gcc/config/cris/cris.c:? set_optab_libfunc (sdiv_optab, SImode, "__Div");
gcc/config/frv/frv.c:? set_optab_libfunc (sdiv_optab,???? DImode, "__divll");
gcc/config/frv/frv.c:? set_optab_libfunc (sdiv_optab,???? SFmode, "__divf");
gcc/config/frv/frv.c:? set_optab_libfunc (sdiv_optab,???? DFmode, "__divd");
gcc/config/h8300/h8300.c:? set_optab_libfunc (sdiv_optab, HImode, "__divhi3");
gcc/config/ia64/ia64.c:? set_optab_libfunc (sdiv_optab, SImode, "__divsi3");
gcc/config/ia64/ia64.c:? set_optab_libfunc (sdiv_optab, TFmode, "_U_Qfdiv");
gcc/config/ia64/ia64.c:? set_optab_libfunc (sdiv_optab, SImode, 0);
gcc/config/ia64/ia64.c:? set_optab_libfunc (sdiv_optab, DImode, "__milli_divI");
gcc/config/ia64/ia64.c:? set_optab_libfunc (sdiv_optab, SImode, "OTS$DIV_I");
gcc/config/ia64/ia64.c:? set_optab_libfunc (sdiv_optab, DImode, "OTS$DIV_L");
gcc/config/mips/mips.c:????? set_optab_libfunc (sdiv_optab, SImode, "__vr4120_divsi3");
gcc/config/mips/mips.c:????? set_optab_libfunc (sdiv_optab, SFmode, "__mips16_divsf3");
gcc/config/mips/mips.c:??? ? set_optab_libfunc (sdiv_optab, DFmode, "__mips16_divdf3");
gcc/config/pa/pa.c:? set_optab_libfunc (sdiv_optab, TFmode, "_U_Qfdiv");
gcc/config/rs6000/rs6000.c:??? set_optab_libfunc (sdiv_optab, TFmode, "__gcc_qdiv");
gcc/config/rs6000/rs6000.c:??? set_optab_libfunc (sdiv_optab, TFmode, "_xlqdiv");
gcc/config/rs6000/rs6000.c:????? set_optab_libfunc (sdiv_optab, TFmode, "_q_div");
gcc/config/sparc/sparc.c:????? set_optab_libfunc (sdiv_optab, SImode, "*.div");
gcc/config/sparc/sparc.c:????? set_optab_libfunc (sdiv_optab, TFmode, "_Q_div");
gcc/config/sparc/sparc.c:????? set_optab_libfunc (sdiv_optab, SImode, 0);
gcc/config/sparc/sparc.c:??? ? set_optab_libfunc (sdiv_optab, DImode, "__div64");
gcc/config/spu/spu.c:? set_optab_libfunc (sdiv_optab, DImode, "__divdi3");
j



?- Jay




 		 	   		  

From dabenavidesd at yahoo.es  Sun Jun 20 05:17:03 2010
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Sun, 20 Jun 2010 03:17:03 +0000 (GMT)
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <COL101-W197BF4F7E1E4A1A24B1469E6C20@phx.gbl>
Message-ID: <847521.56337.qm@web23602.mail.ird.yahoo.com>

Hi:
yes, you can if you wish, that is, you can redirect the x window session and get access through a host different port (see info below) from a new x client or even forwarding x over a ssh session or separated (ideal if you wish), I haven't  tried to do it (I have old hardware, I guess you should be able to virtualize some very decent and cheap system as see below SuSE article points out) but you should be able to do that. Please see this article for the first (the qemu-system- -redir command option):
http://www.ibm.com/developerworks/opensource/library/l-qemu-development/index.html?ca=drs-
you can select the window manager you wish I remember a friend used to talk about WindowMaker he said it was very cheap in terms of RAM and it allowed to do your work just out of the box (he had a very old i486 laptop with it I guess with < 64 MB RAM just to monitor other servers).
There is a bright idea about clustering with OpenMosix (which used to work years ago now there is http://en.wikipedia.org/wiki/LinuxPMI for that purpose) using QEMU, see this old article http://www.novell.com/coolsolutions/feature/14951.html 
you might get some old machines back into life with a net interface in a cluster and mount your disk too.
Hope it helps.

 

--- El s?b, 19/6/10, Jay K <jay.krell at cornell.edu> escribi?:

> De: Jay K <jay.krell at cornell.edu>
> Asunto: Re: [M3devel] Linux/ARM? Android?
> Para: "Darko (M3)" <darko at darko.org>
> CC: "m3devel" <m3devel at elegosoft.com>
> Fecha: s?bado, 19 de junio, 2010 19:33
> 
> None?
> None yet?
> You are supposed to be able run user mode stuff without
> installing any kernel or anything.
> If I emulate an entire system, can the display be remoted
> over X?
> I never go to the Linux "console", just ssh or X over ssh.
> 
>  - Jay
> 
> ----------------------------------------
> > From: darko at darko.org
> > Date: Sat, 19 Jun 2010 17:30:12 -0700
> > To: jay.krell at cornell.edu
> > CC: m3devel at elegosoft.com
> > Subject: Re: [M3devel] Linux/ARM? Android?
> >
> > I mean as your ARM platform. Which ARM distribution
> are you running on QEmu?
> >
> >
> > On 19/06/2010, at 5:26 PM, Jay K wrote:
> >
> >
> > I didn't know what "lxde" is, but Debian 5.0 x86
> "Lenny". Minimal install plus apt-get install whatever.
> >
> > - Jay
> >
> > ----------------------------------------
> >> From: darko at darko.org
> >> Date: Sat, 19 Jun 2010 17:06:11 -0700
> >> To: jay.krell at cornell.edu
> >> CC: m3devel at elegosoft.com
> >> Subject: Re: [M3devel] Linux/ARM? Android?
> >>
> >> A fully crossed system would be the goal since
> mostly the target devices are ARM are phones, tablets and
> embedded devices. What distribution are you running on QEmu?
> Is it the Lenny-lxde one?
> >>
> >> Linux/ARM is definitely fractured because of the
> variety of ARM cores, SoC chips and devices on which it's
> used. I'm not sure what the best way to approach it is.
> >>
> >>
> >> On 19/06/2010, at 4:42 PM, Jay K wrote:
> >>
> >>
> >> I should point out, actually, with cross gcc/as,
> you should be able to easily enough build the whole system
> cross.
> >> ie: your apps instead of cm3.
> >> I can try that -- building the whole tree cross,
> including compiling C and linking.
> >>
> >>
> >> Notice
> m3-sys/cminstall/src/config-no-install/ARMEL_LINUX:
> >>
> >>
> >> SYSTEM_CC = "arm-linux-gnueabi-gcc -gstabs+ -fPIC"
> % C compiler
> >> SYSTEM_ASM = "arm-linux-gnueabi-as" % Assembler
> >>
> >>
> >> I get to:
> >> jay at xlin2:~/cm3-boot-ARMEL_LINUX-d5.8.2-20100619$
> file cm3
> >> cm3: ELF 32-bit LSB executable, ARM, version 1
> (SYSV), dynamically linked (uses shared libs), for GNU/Linux
> 2.6.14, not stripped
> >> jay at xlin2:~/cm3-boot-ARMEL_LINUX-d5.8.2-20100619$
> qemu-arm ./cm3
> >> /lib/ld-linux.so.3: No such file or directory
> >>
> >>
> >> My QEmu setup isn't complete..
> >>
> >>
> >> I got the crosstools from hereabouts:
> >> http://www.emdebian.org/tools/crosstools.html
> >>
> >>
> >> crosstool, scratchbox, buildroot may also be good
> options.
> >>
> >>
> >> This reminds me though, I have a Western Digital
> MyBook World Edition.
> >> Haven't powered it on in a while, slightly flaky
> device.
> >> But it runs Linux/arm (oldabi).
> >> I could/should power it on or get a new one
> something.
> >>
> >>
> >> Also note/reminder, Android seems a bit different,
> at least in terms of finding C headers and libraries, maybe
> not for generating assembly, than "regular" Linux/arm.
> >> Really "Linux/arm" seems a pretty fractured
> thing.
> >> Newer architectures have floating point, for one
> thing.
> >>
> >>
> >> - Jay
> >>
> >> ----------------------------------------
> >>> From: darko at darko.org
> >>> Date: Sat, 19 Jun 2010 15:47:24 -0700
> >>> To: jay.krell at cornell.edu
> >>> CC: m3devel at elegosoft.com
> >>> Subject: Re: [M3devel] Linux/ARM? Android?
> >>>
> >>> Fantasic, thanks. There are some ARM cross
> tools available under DarwinPorts which I'm going to give
> this a try with.
> >>>
> >>>
> >>> On 19/06/2010, at 2:51 AM, Jay K wrote:
> >>>
> >>>
> >>> Eh I guess I should try that then. Ok. Thanks.
> Gotta take a break for a while.
> >>> cd wherever
> >>> cvs -z3 upd -dAP
> >>> cd scripts/python
> >>> ./boot1.py ARMEL_LINUX
> >>> => cm3-boot-ARMEL_LINUX...tgz
> >>> extract that on a machine with cross tools
> (e.g. arm-linux-gnueabi-gcc, arm-linux-gnueabi-as), possibly
> the same machine as already on
> >>> cd into it
> >>> make
> >>> => arm cm3
> >>>
> >>>
> >>> I got that far.
> >>> I can't claim it is right for Android.
> >>>
> >>>
> >>> Then put that cm3 onto a real (or emulated)
> ARM system and...
> >>> (cvs checkout, put the cm3 in /cm3/bin or
> such, add that to $PATH, and scripts/python/boot2.sh)
> >>>
> >>>
> >>> Moving forward to gcc 4.5 will get us atomics
> for ARM, sort of, at least on Linux, see:
> >>> http://gcc.gnu.org/wiki/Atomic
> >>>
> >>>
> >>> - Jay
> >>>
> >>> ----------------------------------------
> >>>> From: darko at darko.org
> >>>> Date: Sat, 19 Jun 2010 02:15:17 -0700
> >>>> To: jay.krell at cornell.edu
> >>>> CC: m3devel at elegosoft.com
> >>>> Subject: Re: [M3devel] Linux/ARM?
> Android?
> >>>>
> >>>> I should also mention that the Android SDK
> has a QEMU based emulator for testing applications and the
> adb (Android Bridge) tool can provide shell access.
> >>>>
> >>>>
> >>>> On 19/06/2010, at 12:13 AM, Darko wrote:
> >>>>
> >>>> I got the first Debian image on http://www.oszoo.org/wiki/index.php/Category:ARM_images
> to run with a GUI, and it connect to the network. I'm using
> Q on my 2.4Ghz MacBook 13" and it's surprisingly fast. Note
> that it's a 10GB image (450MB download).
> >>>>
> >>>> There are also images for Debian MIPS on
> that site too.
> >>>>
> >>>> I agree that the new MacBook trackpad is
> not perfect and since moving from my previous machine that
> had a separate button I now get a lot of stray gestures
> doing odd things. The general solution is not to use the
> button at all and use taps. The new momentum scrolling with
> the gesture is neat but needs more "weight". Unfortunately
> Apple crosses over into form-over-function territory from
> time to time and this is one of those times.
> >>>>
> >>>>
> >>>> On 18/06/2010, at 11:18 PM, Jay K wrote:
> >>>>
> >>>>
> >>>> XP when I can; nothing else comes close
> for searching and editing text, I've tried many.
> >>>> Visual C++ 5.0.
> >>>> I recently learned how to copy/paste in
> vi, which helps, but I'm not sure I remember now.
> >>>>
> >>>>
> >>>> Darwin/amd64 when I need/want
> posix/fastfork, which unfortunately is often.
> >>>> Cygwin is slow.
> >>>> TextWrangler usually there, though it is
> awful compared to Visual C++ 5.0.
> >>>> KomodoEdit is cross platform but also
> fairly impaired.
> >>>> ssh access to a variety
> >>>> Linux=Debian, it has among the best
> support for a variety of platforms.
> >>>> Gentoo comes close or better (ppc64) but
> I've never been able to get it to install -- booting always
> fails.
> >>>> Debian/x86 easy to get cross compiler,
> qemu, etc.
> >>>>
> >>>>
> >>>> X Windows apps are never very good imho,
> so just give up and make do with the even worse command
> line..
> >>>> I find things as basic as scrollbars do
> not work well -- which button do I press when?
> >>>> The Modula-3 GUI apps suffer from this
> problem as well.
> >>>> Further damage due to needing three
> buttons but not having them.
> >>>>
> >>>>
> >>>> Mouse button clicking is actually broken
> on modern Macs too -- they removed the mouse button from all
> the laptops, leaving
> >>>> just a big pad, prone to accidental clicks
> at any location.. also prone to accidental multitouch
> gestures due to resting
> >>>> a twitchy thumb where the button is
> supposed to be. Amazing, really, the mouse, one of their key
> initial advantages,
> >>>> is now broken. (see also Finder and file
> open dialogs, two other former strengths that are now not so
> great.)
> >>>> Multitouch scroll is nice though.
> >>>>
> >>>>
> >>>> - Jay
> >>>>
> >>>> ----------------------------------------
> >>>>> From: darko at darko.org
> >>>>> Date: Fri, 18 Jun 2010 22:55:24 -0700
> >>>>> To: jay.krell at cornell.edu
> >>>>> CC: m3devel at elegosoft.com
> >>>>> Subject: Re: [M3devel] Linux/ARM?
> Android?
> >>>>>
> >>>>> Yeah I've got it working on the
> console but I agree it needs the network.
> >>>>>
> >>>>> Try: http://www.oszoo.org/wiki/index.php/Category:ARM_images
> >>>>> Also: http://www.armedslack.org/
> >>>>>
> >>>>> What platform are you running on these
> days?
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 18/06/2010, at 10:44 PM, Jay K
> wrote:
> >>>>>
> >>>>>
> >>>>> Interesting, thanks.
> >>>>> But it looks like it needs to use
> local console for output?
> >>>>> I need something over the network/X.
> >>>>> It looks like there's an qemu option
> for usemode only too.
> >>>>>
> >>>>> - Jay
> >>>>>
> >>>>>
> ----------------------------------------
> >>>>>> From: darko at darko.org
> >>>>>> Date: Fri, 18 Jun 2010 22:13:43
> -0700
> >>>>>> To: jay.krell at cornell.edu
> >>>>>> CC: m3devel at elegosoft.com
> >>>>>> Subject: Re: [M3devel] Linux/ARM?
> Android?
> >>>>>>
> >>>>>> If you use qemu, this might be
> useful: http://free-electrons.com/community/demos/qemu-arm-directfb/
> >>>>>>
> >>>>>> I'm currently looking at some
> cheap laptops (around $100) which have ethernet plus screen,
> keyboard, battery, etc which would work well as hosts. Just
> trying to find one that runs both Linux and Android.
> >>>>>>
> >>>>>>
> >>>>>> On 18/06/2010, at 10:04 PM, Jay K
> wrote:
> >>>>>>
> >>>>>>
> >>>>>> Thanks. I'll give qemu a go as
> well.
> >>>>>> Hey, maybe we can get mips also.
> (there's decent modern mips/linux hardware now, Chinese
> laptops)
> >>>>>>
> >>>>>> - Jay
> >>>>>>
> >>>>>>
> ----------------------------------------
> >>>>>>> From: darko at darko.org
> >>>>>>> Date: Thu, 17 Jun 2010
> 21:41:59 -0700
> >>>>>>> To: jay.krell at cornell.edu
> >>>>>>> CC: m3devel at elegosoft.com
> >>>>>>> Subject: Re: [M3devel]
> Linux/ARM? Android?
> >>>>>>>
> >>>>>>> Ok, the link here is about
> 20/4Mbs so it shouldn't be too bad and the latency is good.
> I'm in Mountain View, CA. Unfortunately the board has only
> 128MB of main memory but I assume that's enough, I think a
> self hosted compiler has no point.
> >>>>>>>
> >>>>>>> I'll post the details when
> it's up and running.
> >>>>>>>
> >>>>>>>
> >>>>>>> On 17/06/2010, at 9:15 PM, Jay
> K wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>> My preference would be if you
> can set it up on the internet and allow me ssh access.
> >>>>>>> gcc only recently got support
> for Android's C library "bionic", I believe post-gcc 4.5.
> >>>>>>> I'm not sure if that matters
> much or not.
> >>>>>>> I'm not sure how much the C
> library of the target matters to gcc.
> >>>>>>>
> >>>>>>>
> >>>>>>> Anything with pthreads and gcc
> support is quite easy to port to these days. In the past the
> biggest thing you had to do was rewrite /usr/include in
> Modula-3. There was a tendency to rewrite far more of it
> than necessary. These days, none of it is needed.
> >>>>>>>
> >>>>>>>
> >>>>>>> Now you just have to
> >>>>>>> - pick a target name
> >>>>>>> - find the jmpbuf size, word
> size, endian
> >>>>>>> - write a much small "config"
> file
> >>>>>>> - respond to each error that
> occurs -- fill in the platform in a few tables sprinkled
> around the tree
> >>>>>>>
> >>>>>>>
> >>>>>>> Even systems without pthreads
> or with not very good pthreads (OpenBSD) are easy now, as
> the user thread support is much more portable. It used to
> be, for user threads, you had to poke around in the jmpbuf.
> >>>>>>>
> >>>>>>>
> >>>>>>> I would encourage anyone else
> to try it out.
> >>>>>>>
> >>>>>>>
> >>>>>>> Maybe soon there will be a C
> generating backend, and we'll just have one distribution
> format that is a bunch of C, and then gcc support won't even
> be needed (e.g. IA64_NT).
> >>>>>>>
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> - Jay
> >>>>>>>
> >>>>>>>
> ----------------------------------------
> >>>>>>>> From: darko at darko.org
> >>>>>>>> Date: Thu, 17 Jun 2010
> 18:08:14 -0700
> >>>>>>>> To: jay.krell at cornell.edu
> >>>>>>>> CC: m3devel at elegosoft.com
> >>>>>>>> Subject: Re: [M3devel]
> Linux/ARM? Android?
> >>>>>>>>
> >>>>>>>> I've been interested in an
> ARM port for some time. If you (or anyone else) are
> interested in doing the port I can send you one of these,
> which looks like a good platform since it runs Linux and
> Android, has 512K memory and looks well supported: http://beagleboard.org/hardware
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 20/05/2010, at 4:47 AM,
> 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?
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>
> >>
> >
> >
>     
>         
>           
>   


      


From m3 at sol42.com  Sun Jun 20 11:21:03 2010
From: m3 at sol42.com (m3 at sol42.com)
Date: Sun, 20 Jun 2010 11:21:03 +0200
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <COL101-W493D8FFD71EB43948CBE8CE6C10@phx.gbl>
References: <1274350133.8902.0.camel@localhost>, ,
	<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>, ,
	<2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>,
	<COL101-W580FCB4C956AC658A851ABE6C00@phx.gbl>,
	<44CCDCF6-BACE-4B58-A1F5-EF68A852E2A5@darko.org>
	<COL101-W493D8FFD71EB43948CBE8CE6C10@phx.gbl>
Message-ID: <5CEB90C2-DC07-4D4C-9E90-FCCEA356E065@sol42.com>

On 19 Jun 2010, at 7:04, Jay K wrote:
> Hey, maybe we can get mips also. (there's decent modern mips/linux hardware now, Chinese laptops)
Hmm, I have decent ancient mips/irix hardware I'd love to get m3 running on.  Will have to give it a try when I get some free time.  Is gcc 4 required (I have 3.3)?
Regards.
-Daniel

From dabenavidesd at yahoo.es  Sun Jun 20 20:54:49 2010
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Sun, 20 Jun 2010 18:54:49 +0000 (GMT)
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <5CEB90C2-DC07-4D4C-9E90-FCCEA356E065@sol42.com>
Message-ID: <974011.74052.qm@web23608.mail.ird.yahoo.com>

Hi:
if you mean the c "native" compiler shouldn't be a problem, but one would expect differences between efficiency of both m3cg builds, I believe buildable for gcc 4 and 3 but nonetheless it shouldn't be the same in terms of the generated m3cg but for the M3 code which is what one is interested would be more like the same. If it is necessary to work with it I believe the process of installing a new gcc for c lang only is not too painful and is straight forward after you have a previous version to build a gcc 4 with a bootstrap compiler to build a self hosted c compiler.
I don't know how much of the building process of m3cg is done by the gcc c compiler if it could be done at the same time such a build with current tree (which if there is I think is doable just selecting the proper options in the configure program command parameters, although not sure to build a full self hosted c gcc 4 compiler, but doable if you start with a bootstrap gcc 4 c compiler).
Hope it helps and thanks in adavance
 
--- El dom, 20/6/10, m3 at sol42.com <m3 at sol42.com> escribi?:

> De: m3 at sol42.com <m3 at sol42.com>
> Asunto: Re: [M3devel] Linux/ARM? Android?
> Para: m3devel at elegosoft.com
> Fecha: domingo, 20 de junio, 2010 04:21
> On 19 Jun 2010, at 7:04, Jay K
> wrote:
> > Hey, maybe we can get mips also. (there's decent
> modern mips/linux hardware now, Chinese laptops)
> Hmm, I have decent ancient mips/irix hardware I'd love to
> get m3 running on.  Will have to give it a try when I
> get some free time.  Is gcc 4 required (I have 3.3)?
> Regards.
> -Daniel


      


From jay.krell at cornell.edu  Sun Jun 20 21:16:27 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 20 Jun 2010 19:16:27 +0000
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <5CEB90C2-DC07-4D4C-9E90-FCCEA356E065@sol42.com>
References: <1274350133.8902.0.camel@localhost>,
	,,<COL101-W19884F70A1ADA472886C4CE6E30@phx.gbl>,
	, , <2742A528-7AEC-4F7C-BDF8-760130C5A4EA@darko.org>, ,
	<COL101-W580FCB4C956AC658A851ABE6C00@phx.gbl>, ,
	<44CCDCF6-BACE-4B58-A1F5-EF68A852E2A5@darko.org>,
	<COL101-W493D8FFD71EB43948CBE8CE6C10@phx.gbl>,
	<5CEB90C2-DC07-4D4C-9E90-FCCEA356E065@sol42.com>
Message-ID: <COL101-W70CBF569D6E232E7CAD5BE6C20@phx.gbl>


No gcc 4 is not required.
What is required is that gcc 4.3 support your machine -- since that is currently what m3cg is based on -- but you don't need gcc 4.
You just need some C compiler.
gcc 4.3 does support Irix/mips I believe.
Irix 6.5.

?- Jay

----------------------------------------
> From: m3 at sol42.com
> Date: Sun, 20 Jun 2010 11:21:03 +0200
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] Linux/ARM? Android?
>
> On 19 Jun 2010, at 7:04, Jay K wrote:
>> Hey, maybe we can get mips also. (there's decent modern mips/linux hardware now, Chinese laptops)
> Hmm, I have decent ancient mips/irix hardware I'd love to get m3 running on. Will have to give it a try when I get some free time. Is gcc 4 required (I have 3.3)?
> Regards.
> -Daniel
 		 	   		  

From jay.krell at cornell.edu  Sun Jun 20 21:43:57 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 20 Jun 2010 19:43:57 +0000
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <974011.74052.qm@web23608.mail.ird.yahoo.com>
References: <5CEB90C2-DC07-4D4C-9E90-FCCEA356E065@sol42.com>,
	<974011.74052.qm@web23608.mail.ird.yahoo.com>
Message-ID: <COL101-W190990CE2CFAD02AC0CBC0E6C20@phx.gbl>


True, that m3cg is "most" buildable by gcc itself. That gets the most testing by gcc developers.
Almost any version will do though.
But it is buildable by other C compilers, such as Sun cc and OSF/1's C compiler.
Going forward, like to gcc 4.6, a C++ compiler might be needed.
OpenBSD uses gcc 3.x on most platforms and 2.x on some older ones.
gcc 4.4 and 4.5 actually require a C9x compiler but that is an accidental regression and getting fixed.
I found it using OSF/1 cc on Mika's machine. :)


On Irix I found some wierd old undocumented "O32" compiler and I think was able to use it eventually
to build modern gcc. It required some small patches to some tools, and it seemed to
perhaps even miscompile things, such that they had to later be rebuilt with gcc.


On HP-UX on HPPA the? bundled compiler is K&R. It can be used to build some gcc 3.x, which
can then be used to build gcc 4.x and/or presumably m3cg. I don't remember how far I got.
This "need" to go through gcc 3.x is documented on the gcc web pages.


?- Jay

----------------------------------------
> Date: Sun, 20 Jun 2010 18:54:49 +0000
> From: dabenavidesd at yahoo.es
> To: m3devel at elegosoft.com; m3 at sol42.com
> Subject: Re: [M3devel] Linux/ARM? Android?
>
> Hi:
> if you mean the c "native" compiler shouldn't be a problem, but one would expect differences between efficiency of both m3cg builds, I believe buildable for gcc 4 and 3 but nonetheless it shouldn't be the same in terms of the generated m3cg but for the M3 code which is what one is interested would be more like the same. If it is necessary to work with it I believe the process of installing a new gcc for c lang only is not too painful and is straight forward after you have a previous version to build a gcc 4 with a bootstrap compiler to build a self hosted c compiler.
> I don't know how much of the building process of m3cg is done by the gcc c compiler if it could be done at the same time such a build with current tree (which if there is I think is doable just selecting the proper options in the configure program command parameters, although not sure to build a full self hosted c gcc 4 compiler, but doable if you start with a bootstrap gcc 4 c compiler).
> Hope it helps and thanks in adavance
>
> --- El dom, 20/6/10, m3 at sol42.com  escribi?:
>
>> De: m3 at sol42.com 
>> Asunto: Re: [M3devel] Linux/ARM? Android?
>> Para: m3devel at elegosoft.com
>> Fecha: domingo, 20 de junio, 2010 04:21
>> On 19 Jun 2010, at 7:04, Jay K
>> wrote:
>>> Hey, maybe we can get mips also. (there's decent
>> modern mips/linux hardware now, Chinese laptops)
>> Hmm, I have decent ancient mips/irix hardware I'd love to
>> get m3 running on. Will have to give it a try when I
>> get some free time. Is gcc 4 required (I have 3.3)?
>> Regards.
>> -Daniel
>
>
>
 		 	   		  

From dragisha at m3w.org  Sun Jun 20 22:38:26 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Sun, 20 Jun 2010 22:38:26 +0200
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <COL101-W190990CE2CFAD02AC0CBC0E6C20@phx.gbl>
References: <5CEB90C2-DC07-4D4C-9E90-FCCEA356E065@sol42.com>
	, <974011.74052.qm@web23608.mail.ird.yahoo.com>
	<COL101-W190990CE2CFAD02AC0CBC0E6C20@phx.gbl>
Message-ID: <1277066306.5571.4.camel@localhost>

It's cheaper to support platforms through m3gc (meaning gcc) than
through C. Going native so as to get "broader base than gcc"? Do we
really have that wide userbase? Not to mention developer base...

And why're you looking retro to C? Why not invest yourself on LLVM? JIT
comes to mind....

On Sun, 2010-06-20 at 19:43 +0000, Jay K wrote:
> True, that m3cg is "most" buildable by gcc itself. That gets the most
> testing by gcc developers.
> Almost any version will do though.
> But it is buildable by other C compilers, such as Sun cc and OSF/1's C
> compiler.
> Going forward, like to gcc 4.6, a C++ compiler might be needed.
> OpenBSD uses gcc 3.x on most platforms and 2.x on some older ones.
> gcc 4.4 and 4.5 actually require a C9x compiler but that is an
> accidental regression and getting fixed.
> I found it using OSF/1 cc on Mika's machine. :) 
-- 
Dragi?a Duri? <dragisha at m3w.org>



From jay.krell at cornell.edu  Mon Jun 21 00:40:54 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 20 Jun 2010 22:40:54 +0000
Subject: [M3devel] Linux/ARM? Android?
In-Reply-To: <1277066306.5571.4.camel@localhost>
References: <5CEB90C2-DC07-4D4C-9E90-FCCEA356E065@sol42.com>,,
	<974011.74052.qm@web23608.mail.ird.yahoo.com>,
	<COL101-W190990CE2CFAD02AC0CBC0E6C20@phx.gbl>,
	<1277066306.5571.4.camel@localhost>
Message-ID: <COL101-W59EAC8AC1D2D1DC0678DA1E6C20@phx.gbl>


If you generate C, you get one very portable distribution format -- a bunch of C in .tar.gz.
Far more portable than what we have today.
You get possibly better optimization.
Possibly better debugging.
A much smaller source tree -- no need for m3cc or m3gdb.
You highly likely get more efficient portable exception handling -- generate C++.
? (On Win32, C suffices. Similarly on OSF/1 and VMS I believe.)
Granted, C++ with exception handling is less portable than C -- there could still be an option to use setjmp/longjmp.
I imagine it'd be wrapped up in some #defines.
Consider all the platforms that aren't well supported by gcc or LLVM.


You might get slower compilation, granted.


You could also use this as a hybrid approach. Consider that we already have two sort of backends.
This would be a third.
Anyone want Alpha, ARM, MIPS, IA64 etc. -- already done, or at least signficantly.


Consider how much work it takes to port "Hello world". None.
This would drive us toward that.
With some benefits and maybe some drawbacks.


?- Jay

----------------------------------------
> From: dragisha at m3w.org
> To: jay.krell at cornell.edu
> Date: Sun, 20 Jun 2010 22:38:26 +0200
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Linux/ARM? Android?
>
> It's cheaper to support platforms through m3gc (meaning gcc) than
> through C. Going native so as to get "broader base than gcc"? Do we
> really have that wide userbase? Not to mention developer base...
>
> And why're you looking retro to C? Why not invest yourself on LLVM? JIT
> comes to mind....
>
> On Sun, 2010-06-20 at 19:43 +0000, Jay K wrote:
>> True, that m3cg is "most" buildable by gcc itself. That gets the most
>> testing by gcc developers.
>> Almost any version will do though.
>> But it is buildable by other C compilers, such as Sun cc and OSF/1's C
>> compiler.
>> Going forward, like to gcc 4.6, a C++ compiler might be needed.
>> OpenBSD uses gcc 3.x on most platforms and 2.x on some older ones.
>> gcc 4.4 and 4.5 actually require a C9x compiler but that is an
>> accidental regression and getting fixed.
>> I found it using OSF/1 cc on Mika's machine. :)
> --
> Dragi?a Duri? 
>
 		 	   		  

From dragisha at m3w.org  Mon Jun 21 08:32:22 2010
From: dragisha at m3w.org (=?UTF-8?Q?Dragi=C5=A1a_Duri=C4=87?=)
Date: Mon, 21 Jun 2010 08:32:22 +0200
Subject: [M3devel] ***SPAM*** RE:  Linux/ARM? Android?
In-Reply-To: <COL101-W59EAC8AC1D2D1DC0678DA1E6C20@phx.gbl>
References: <5CEB90C2-DC07-4D4C-9E90-FCCEA356E065@sol42.com>
	,, <974011.74052.qm@web23608.mail.ird.yahoo.com>
	,<COL101-W190990CE2CFAD02AC0CBC0E6C20@phx.gbl>
	,<1277066306.5571.4.camel@localhost>
	<COL101-W59EAC8AC1D2D1DC0678DA1E6C20@phx.gbl>
Message-ID: <1277101942.5571.83.camel@localhost>

Is there such thing as overportability ?:) Are we really so desperate to
reach for users and supporters to fight for ones using most obsolete and
obscure hardware/OSes? Outside of what gcc covers?

My mention of LLVM was not "get more platforms" but "get new angle".

On Sun, 2010-06-20 at 22:40 +0000, Jay K wrote:
> 
> If you generate C, you get one very portable distribution format -- a
> bunch of C in .tar.gz.
> Far more portable than what we have today.

  If we all just stick to C, we'll have that, minus all learning and
programming and debugging and packaging and marketing effort for
Modula-3. Don't you think so? And this compares because...

> You get possibly better optimization.
> Possibly better debugging.
> A much smaller source tree -- no need for m3cc or m3gdb.

  And you get to talk C with your program when debugging, instead of
M3... How nice :). We can have Modula-3 developers in teams who don't
even need to know Modula-3? 

  m3gdb we need, that is for sure. As for m3cc... There comes LLVM
also... What we need is coordinated effort with gcc|LLVM people so we
can get recognition and "officiality" of our patches. And once for all
stop running behind in versions used.

> Consider all the platforms that aren't well supported by gcc or LLVM.

  All that hardware people are throwing away....

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



From jay.krell at cornell.edu  Mon Jun 21 09:55:19 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 21 Jun 2010 07:55:19 +0000
Subject: [M3devel] checking function pointers for null?
Message-ID: <COL101-W351A37DF7AC3C7A9A9E1ACE6C30@phx.gbl>


This is code that calls a function pointer:


??????? testq?? %rbx, %rbx ; test function pointer for null
??????? je????? L6
??????? cmpq??? $-1, (%rbx) ; check for closure marker
??????? jne???? L6? ; if not a closure, goto L6
??????? movq??? 16(%rbx), %r13 ; r13=static chain (ought to use r10?) 
??????? movq??? 8(%rbx), %rax ; rax=actual function pointer
??????? jmp???? L8
L6:
??????? movq??? %rbx, %rax ; rax=actual function pointer
L8:
??????? movq??? %r13, %r10 ; r10=static chain (it should have just used r10 in the first place? or is r13 otherwise the previous static chain?)
??????? call??? *%rax


What is the point of the initial testq/je, if we are just going to jump to the address anyway?
Should we do something else if in fact the function pointer is null? Or just let a jump to null fail as it will?
You know -- it seems me we should do either more or less here.
More: report a null deref by calling m3_fault
Less: remove the null check 


?- Jay
 		 	   		  

From hosking at cs.purdue.edu  Mon Jun 21 16:26:31 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 21 Jun 2010 10:26:31 -0400
Subject: [M3devel] checking function pointers for null?
In-Reply-To: <COL101-W351A37DF7AC3C7A9A9E1ACE6C30@phx.gbl>
References: <COL101-W351A37DF7AC3C7A9A9E1ACE6C30@phx.gbl>
Message-ID: <3A74ECDB-2F76-4B7A-B7F3-CAEBA38F129B@cs.purdue.edu>

Is this code from M3CG or the Windows native backend?

If from M3CG perhaps you can show us the M3CG IR code.

On 21 Jun 2010, at 03:55, Jay K wrote:

> 
> This is code that calls a function pointer:
> 
> 
>         testq   %rbx, %rbx ; test function pointer for null
>         je      L6
>         cmpq    $-1, (%rbx) ; check for closure marker
>         jne     L6  ; if not a closure, goto L6
>         movq    16(%rbx), %r13 ; r13=static chain (ought to use r10?) 
>         movq    8(%rbx), %rax ; rax=actual function pointer
>         jmp     L8
> L6:
>         movq    %rbx, %rax ; rax=actual function pointer
> L8:
>         movq    %r13, %r10 ; r10=static chain (it should have just used r10 in the first place? or is r13 otherwise the previous static chain?)
>         call    *%rax
> 
> 
> What is the point of the initial testq/je, if we are just going to jump to the address anyway?
> Should we do something else if in fact the function pointer is null? Or just let a jump to null fail as it will?
> You know -- it seems me we should do either more or less here.
> More: report a null deref by calling m3_fault
> Less: remove the null check 
> 
> 
>  - Jay
> 		 	   		  



From jay.krell at cornell.edu  Mon Jun 21 19:47:48 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 21 Jun 2010 17:47:48 +0000
Subject: [M3devel] checking function pointers for null?
In-Reply-To: <3A74ECDB-2F76-4B7A-B7F3-CAEBA38F129B@cs.purdue.edu>
References: <COL101-W351A37DF7AC3C7A9A9E1ACE6C30@phx.gbl>,
	<3A74ECDB-2F76-4B7A-B7F3-CAEBA38F129B@cs.purdue.edu>
Message-ID: <COL101-W499F828D94ADA12FF53275E6C30@phx.gbl>

Neither backend would add these checks themself, it is m3cg, IR later.

> Subject: Re: [M3devel] checking function pointers for null?
> From: hosking at cs.purdue.edu
> Date: Mon, 21 Jun 2010 10:26:31 -0400
> CC: m3devel at elegosoft.com
> To: jay.krell at cornell.edu
> 
> Is this code from M3CG or the Windows native backend?
> 
> If from M3CG perhaps you can show us the M3CG IR code.
> 
> On 21 Jun 2010, at 03:55, Jay K wrote:
> 
> > 
> > This is code that calls a function pointer:
> > 
> > 
> >         testq   %rbx, %rbx ; test function pointer for null
> >         je      L6
> >         cmpq    $-1, (%rbx) ; check for closure marker
> >         jne     L6  ; if not a closure, goto L6
> >         movq    16(%rbx), %r13 ; r13=static chain (ought to use r10?) 
> >         movq    8(%rbx), %rax ; rax=actual function pointer
> >         jmp     L8
> > L6:
> >         movq    %rbx, %rax ; rax=actual function pointer
> > L8:
> >         movq    %r13, %r10 ; r10=static chain (it should have just used r10 in the first place? or is r13 otherwise the previous static chain?)
> >         call    *%rax
> > 
> > 
> > What is the point of the initial testq/je, if we are just going to jump to the address anyway?
> > Should we do something else if in fact the function pointer is null? Or just let a jump to null fail as it will?
> > You know -- it seems me we should do either more or less here.
> > More: report a null deref by calling m3_fault
> > Less: remove the null check 
> > 
> > 
> >  - Jay
> > 		 	   		  
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100621/13be0de5/attachment-0002.html>

From jay.krell at cornell.edu  Mon Jun 21 22:55:06 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 21 Jun 2010 20:55:06 +0000
Subject: [M3devel] checking function pointers for null?
In-Reply-To: <3A74ECDB-2F76-4B7A-B7F3-CAEBA38F129B@cs.purdue.edu>
References: <COL101-W351A37DF7AC3C7A9A9E1ACE6C30@phx.gbl>,
	<3A74ECDB-2F76-4B7A-B7F3-CAEBA38F129B@cs.purdue.edu>
Message-ID: <COL101-W35300463AE825ED4FE7EB5E6C30@phx.gbl>


The backend is doing what the front/middle end asks.
My original question stands: The check for NULL is worthless, right?
Either it should do more: call m3_fault
Or it should do less: don't bother checking, let the hardware do it at the call or marker check (the marker check, in reality)
?

I can understand the stance that the software does all the checking. That we don't/shouldn't depend on hardware checking.
? Though that isn't true -- the rationale for "Target.first_readable_address" or such is that hardware checks for NULL deref,
?? and even "small deref" -- anything in the first page at least.

But this seems in between -- it avoids the null deref for the marker check but doesn't avoid it for the call.
Perhaps there is an idea that the hardware checking is somehow different for data vs. code??


MODULE Main;

TYPE Function = PROCEDURE ();

PROCEDURE C(a:Function) =
BEGIN
?a();
END C;

BEGIN
END Main.


(23) begin_procedure
? procedure Main__C
?Main__C(24) set_source_line
? source line??? 6
(25) set_source_line
? source line??? 7
(26) load
? type:addr
? type:addr
? m3cg_load (M3_CQL02D_a): offset 0x0, convert addr -> addr
(27) declare_temp
? type:addr
? temp var type:addr size:0x40 alignment:0x40
(28) store
? type:addr
? type:addr
? store (noname) offset:0x0 src_t:addr dst_t:addr
(29) start_call_indirect
? type:void
? start call procedure indirect type:void
(30) load
? type:addr
? type:addr
? m3cg_load (noname): offset 0x0, convert addr -> addr
(31) load_nil??? ***
(32) if_eq???????? ***
? type:addr
? label 1
(33) load
? type:addr
? type:addr
? m3cg_load (noname): offset 0x0, convert addr -> addr
(34) load_indirect
? type:int64
? type:int64
? load address offset:0x0 src_t:int64 dst_t:int64
(35) load_integer
? type:int64
? integer i:0xfe n_bytes:0x1 0x00000000000000001 sign -1
(36) if_ne
? type:int64
? label 1
(37) set_label
? label 2
(38) load
? type:addr
? type:addr
? m3cg_load (noname): offset 0x0, convert addr -> addr
(39) load_indirect
? type:addr
? type:addr
? load address offset:0x80 src_t:addr dst_t:addr
(40) pop_static_link
(41) load
? type:addr
? type:addr
? m3cg_load (noname): offset 0x0, convert addr -> addr
(42) load_indirect
? type:addr
? type:addr
? load address offset:0x40 src_t:addr dst_t:addr
(43) store
? type:addr
? type:addr
? store (noname) offset:0x0 src_t:addr dst_t:addr
(44) set_label
? label 1
(45) load
? type:addr
? type:addr
? m3cg_load (noname): offset 0x0, convert addr -> addr
(46) call_indirect
? type:void
? call procedure indirect type:void
(47) set_source_line
? source line??? 8
(48) exit_proc
? type:void
(49) free_temp
(50) end_procedure
? procedure Main__C

?- Jay


________________________________
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com
> Subject: RE: [M3devel] checking function pointers for null?
> Date: Mon, 21 Jun 2010 17:47:48 +0000
>
>
>
>
>
>
>
> Neither backend would add these checks themself, it is m3cg, IR later.
>
>> Subject: Re: [M3devel] checking function pointers for null?
>> From: hosking at cs.purdue.edu
>> Date: Mon, 21 Jun 2010 10:26:31 -0400
>> CC: m3devel at elegosoft.com
>> To: jay.krell at cornell.edu
>>
>> Is this code from M3CG or the Windows native backend?
>>
>> If from M3CG perhaps you can show us the M3CG IR code.
>>
>> On 21 Jun 2010, at 03:55, Jay K wrote:
>>
>>>
>>> This is code that calls a function pointer:
>>>
>>>
>>> testq %rbx, %rbx ; test function pointer for null
>>> je L6
>>> cmpq $-1, (%rbx) ; check for closure marker
>>> jne L6 ; if not a closure, goto L6
>>> movq 16(%rbx), %r13 ; r13=static chain (ought to use r10?)
>>> movq 8(%rbx), %rax ; rax=actual function pointer
>>> jmp L8
>>> L6:
>>> movq %rbx, %rax ; rax=actual function pointer
>>> L8:
>>> movq %r13, %r10 ; r10=static chain (it should have just used r10 in the first place? or is r13 otherwise the previous static chain?)
>>> call *%rax
>>>
>>>
>>> What is the point of the initial testq/je, if we are just going to jump to the address anyway?
>>> Should we do something else if in fact the function pointer is null? Or just let a jump to null fail as it will?
>>> You know -- it seems me we should do either more or less here.
>>> More: report a null deref by calling m3_fault
>>> Less: remove the null check
>>>
>>>
>>> - Jay
>>>
>>
 		 	   		  

From hosking at cs.purdue.edu  Mon Jun 21 23:09:08 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Mon, 21 Jun 2010 17:09:08 -0400
Subject: [M3devel] checking function pointers for null?
In-Reply-To: <COL101-W35300463AE825ED4FE7EB5E6C30@phx.gbl>
References: <COL101-W351A37DF7AC3C7A9A9E1ACE6C30@phx.gbl>,
	<3A74ECDB-2F76-4B7A-B7F3-CAEBA38F129B@cs.purdue.edu>
	<COL101-W35300463AE825ED4FE7EB5E6C30@phx.gbl>
Message-ID: <8A2BCF94-43E9-44F5-9C63-AC71A4563E0B@cs.purdue.edu>

I want to see the IR.


On 21 Jun 2010, at 16:55, Jay K wrote:

> 
> The backend is doing what the front/middle end asks.
> My original question stands: The check for NULL is worthless, right?
> Either it should do more: call m3_fault
> Or it should do less: don't bother checking, let the hardware do it at the call or marker check (the marker check, in reality)
> ?
> 
> I can understand the stance that the software does all the checking. That we don't/shouldn't depend on hardware checking.
>  Though that isn't true -- the rationale for "Target.first_readable_address" or such is that hardware checks for NULL deref,
>   and even "small deref" -- anything in the first page at least.
> 
> But this seems in between -- it avoids the null deref for the marker check but doesn't avoid it for the call.
> Perhaps there is an idea that the hardware checking is somehow different for data vs. code??
> 
> 
> MODULE Main;
> 
> TYPE Function = PROCEDURE ();
> 
> PROCEDURE C(a:Function) =
> BEGIN
> a();
> END C;
> 
> BEGIN
> END Main.
> 
> 
> (23) begin_procedure
>  procedure Main__C
> Main__C(24) set_source_line
>  source line    6
> (25) set_source_line
>  source line    7
> (26) load
>  type:addr
>  type:addr
>  m3cg_load (M3_CQL02D_a): offset 0x0, convert addr -> addr
> (27) declare_temp
>  type:addr
>  temp var type:addr size:0x40 alignment:0x40
> (28) store
>  type:addr
>  type:addr
>  store (noname) offset:0x0 src_t:addr dst_t:addr
> (29) start_call_indirect
>  type:void
>  start call procedure indirect type:void
> (30) load
>  type:addr
>  type:addr
>  m3cg_load (noname): offset 0x0, convert addr -> addr
> (31) load_nil    ***
> (32) if_eq         ***
>  type:addr
>  label 1
> (33) load
>  type:addr
>  type:addr
>  m3cg_load (noname): offset 0x0, convert addr -> addr
> (34) load_indirect
>  type:int64
>  type:int64
>  load address offset:0x0 src_t:int64 dst_t:int64
> (35) load_integer
>  type:int64
>  integer i:0xfe n_bytes:0x1 0x00000000000000001 sign -1
> (36) if_ne
>  type:int64
>  label 1
> (37) set_label
>  label 2
> (38) load
>  type:addr
>  type:addr
>  m3cg_load (noname): offset 0x0, convert addr -> addr
> (39) load_indirect
>  type:addr
>  type:addr
>  load address offset:0x80 src_t:addr dst_t:addr
> (40) pop_static_link
> (41) load
>  type:addr
>  type:addr
>  m3cg_load (noname): offset 0x0, convert addr -> addr
> (42) load_indirect
>  type:addr
>  type:addr
>  load address offset:0x40 src_t:addr dst_t:addr
> (43) store
>  type:addr
>  type:addr
>  store (noname) offset:0x0 src_t:addr dst_t:addr
> (44) set_label
>  label 1
> (45) load
>  type:addr
>  type:addr
>  m3cg_load (noname): offset 0x0, convert addr -> addr
> (46) call_indirect
>  type:void
>  call procedure indirect type:void
> (47) set_source_line
>  source line    8
> (48) exit_proc
>  type:void
> (49) free_temp
> (50) end_procedure
>  procedure Main__C
> 
> - Jay
> 
> 
> ________________________________
>> From: jay.krell at cornell.edu
>> To: hosking at cs.purdue.edu
>> CC: m3devel at elegosoft.com
>> Subject: RE: [M3devel] checking function pointers for null?
>> Date: Mon, 21 Jun 2010 17:47:48 +0000
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> Neither backend would add these checks themself, it is m3cg, IR later.
>> 
>>> Subject: Re: [M3devel] checking function pointers for null?
>>> From: hosking at cs.purdue.edu
>>> Date: Mon, 21 Jun 2010 10:26:31 -0400
>>> CC: m3devel at elegosoft.com
>>> To: jay.krell at cornell.edu
>>> 
>>> Is this code from M3CG or the Windows native backend?
>>> 
>>> If from M3CG perhaps you can show us the M3CG IR code.
>>> 
>>> On 21 Jun 2010, at 03:55, Jay K wrote:
>>> 
>>>> 
>>>> This is code that calls a function pointer:
>>>> 
>>>> 
>>>> testq %rbx, %rbx ; test function pointer for null
>>>> je L6
>>>> cmpq $-1, (%rbx) ; check for closure marker
>>>> jne L6 ; if not a closure, goto L6
>>>> movq 16(%rbx), %r13 ; r13=static chain (ought to use r10?)
>>>> movq 8(%rbx), %rax ; rax=actual function pointer
>>>> jmp L8
>>>> L6:
>>>> movq %rbx, %rax ; rax=actual function pointer
>>>> L8:
>>>> movq %r13, %r10 ; r10=static chain (it should have just used r10 in the first place? or is r13 otherwise the previous static chain?)
>>>> call *%rax
>>>> 
>>>> 
>>>> What is the point of the initial testq/je, if we are just going to jump to the address anyway?
>>>> Should we do something else if in fact the function pointer is null? Or just let a jump to null fail as it will?
>>>> You know -- it seems me we should do either more or less here.
>>>> More: report a null deref by calling m3_fault
>>>> Less: remove the null check
>>>> 
>>>> 
>>>> - Jay
>>>> 
>>> 
> 		 	   		  



From jay.krell at cornell.edu  Tue Jun 22 02:38:37 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 22 Jun 2010 00:38:37 +0000
Subject: [M3devel] checking function pointers for null?
In-Reply-To: <8A2BCF94-43E9-44F5-9C63-AC71A4563E0B@cs.purdue.edu>
References: <COL101-W351A37DF7AC3C7A9A9E1ACE6C30@phx.gbl>, ,
	<3A74ECDB-2F76-4B7A-B7F3-CAEBA38F129B@cs.purdue.edu>,
	<COL101-W35300463AE825ED4FE7EB5E6C30@phx.gbl>,
	<8A2BCF94-43E9-44F5-9C63-AC71A4563E0B@cs.purdue.edu>
Message-ID: <COL101-W28069DAED40F76BDA6CA4FE6C40@phx.gbl>


Isn't that the cm3cg -y output below?
It's all fairly obvious.
 
 
I looked, I might have the names wrong, but there is a function is_closure in the frontend. It is used by more than just call, e.g. it is used for function pointer comparison. So the "silent null check" is sometimes required, but I think it is dubious for call. (And comparing function pointers to other than null is dubious, and often doesn't "work" in the face of dynamic linking.)
 
 
 - Jay


----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Mon, 21 Jun 2010 17:09:08 -0400
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] checking function pointers for null?
>
> I want to see the IR.
>
>
> On 21 Jun 2010, at 16:55, Jay K wrote:
>
>>
>> The backend is doing what the front/middle end asks.
>> My original question stands: The check for NULL is worthless, right?
>> Either it should do more: call m3_fault
>> Or it should do less: don't bother checking, let the hardware do it at the call or marker check (the marker check, in reality)
>> ?
>>
>> I can understand the stance that the software does all the checking. That we don't/shouldn't depend on hardware checking.
>> Though that isn't true -- the rationale for "Target.first_readable_address" or such is that hardware checks for NULL deref,
>> and even "small deref" -- anything in the first page at least.
>>
>> But this seems in between -- it avoids the null deref for the marker check but doesn't avoid it for the call.
>> Perhaps there is an idea that the hardware checking is somehow different for data vs. code??
>>
>>
>> MODULE Main;
>>
>> TYPE Function = PROCEDURE ();
>>
>> PROCEDURE C(a:Function) =
>> BEGIN
>> a();
>> END C;
>>
>> BEGIN
>> END Main.
>>
>>
>> (23) begin_procedure
>> procedure Main__C
>> Main__C(24) set_source_line
>> source line 6
>> (25) set_source_line
>> source line 7
>> (26) load
>> type:addr
>> type:addr
>> m3cg_load (M3_CQL02D_a): offset 0x0, convert addr -> addr
>> (27) declare_temp
>> type:addr
>> temp var type:addr size:0x40 alignment:0x40
>> (28) store
>> type:addr
>> type:addr
>> store (noname) offset:0x0 src_t:addr dst_t:addr
>> (29) start_call_indirect
>> type:void
>> start call procedure indirect type:void
>> (30) load
>> type:addr
>> type:addr
>> m3cg_load (noname): offset 0x0, convert addr -> addr
>> (31) load_nil ***
>> (32) if_eq ***
>> type:addr
>> label 1
>> (33) load
>> type:addr
>> type:addr
>> m3cg_load (noname): offset 0x0, convert addr -> addr
>> (34) load_indirect
>> type:int64
>> type:int64
>> load address offset:0x0 src_t:int64 dst_t:int64
>> (35) load_integer
>> type:int64
>> integer i:0xfe n_bytes:0x1 0x00000000000000001 sign -1
>> (36) if_ne
>> type:int64
>> label 1
>> (37) set_label
>> label 2
>> (38) load
>> type:addr
>> type:addr
>> m3cg_load (noname): offset 0x0, convert addr -> addr
>> (39) load_indirect
>> type:addr
>> type:addr
>> load address offset:0x80 src_t:addr dst_t:addr
>> (40) pop_static_link
>> (41) load
>> type:addr
>> type:addr
>> m3cg_load (noname): offset 0x0, convert addr -> addr
>> (42) load_indirect
>> type:addr
>> type:addr
>> load address offset:0x40 src_t:addr dst_t:addr
>> (43) store
>> type:addr
>> type:addr
>> store (noname) offset:0x0 src_t:addr dst_t:addr
>> (44) set_label
>> label 1
>> (45) load
>> type:addr
>> type:addr
>> m3cg_load (noname): offset 0x0, convert addr -> addr
>> (46) call_indirect
>> type:void
>> call procedure indirect type:void
>> (47) set_source_line
>> source line 8
>> (48) exit_proc
>> type:void
>> (49) free_temp
>> (50) end_procedure
>> procedure Main__C
>>
>> - Jay
>>
>>
>> ________________________________
>>> From: jay.krell at cornell.edu
>>> To: hosking at cs.purdue.edu
>>> CC: m3devel at elegosoft.com
>>> Subject: RE: [M3devel] checking function pointers for null?
>>> Date: Mon, 21 Jun 2010 17:47:48 +0000
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Neither backend would add these checks themself, it is m3cg, IR later.
>>>
>>>> Subject: Re: [M3devel] checking function pointers for null?
>>>> From: hosking at cs.purdue.edu
>>>> Date: Mon, 21 Jun 2010 10:26:31 -0400
>>>> CC: m3devel at elegosoft.com
>>>> To: jay.krell at cornell.edu
>>>>
>>>> Is this code from M3CG or the Windows native backend?
>>>>
>>>> If from M3CG perhaps you can show us the M3CG IR code.
>>>>
>>>> On 21 Jun 2010, at 03:55, Jay K wrote:
>>>>
>>>>>
>>>>> This is code that calls a function pointer:
>>>>>
>>>>>
>>>>> testq %rbx, %rbx ; test function pointer for null
>>>>> je L6
>>>>> cmpq $-1, (%rbx) ; check for closure marker
>>>>> jne L6 ; if not a closure, goto L6
>>>>> movq 16(%rbx), %r13 ; r13=static chain (ought to use r10?)
>>>>> movq 8(%rbx), %rax ; rax=actual function pointer
>>>>> jmp L8
>>>>> L6:
>>>>> movq %rbx, %rax ; rax=actual function pointer
>>>>> L8:
>>>>> movq %r13, %r10 ; r10=static chain (it should have just used r10 in the first place? or is r13 otherwise the previous static chain?)
>>>>> call *%rax
>>>>>
>>>>>
>>>>> What is the point of the initial testq/je, if we are just going to jump to the address anyway?
>>>>> Should we do something else if in fact the function pointer is null? Or just let a jump to null fail as it will?
>>>>> You know -- it seems me we should do either more or less here.
>>>>> More: report a null deref by calling m3_fault
>>>>> Less: remove the null check
>>>>>
>>>>>
>>>>> - Jay
>>>>>
>>>>
>>
> 		 	   		  

From jay.krell at cornell.edu  Wed Jun 23 15:40:35 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 23 Jun 2010 13:40:35 +0000
Subject: [M3devel] CHAR vs. Ctypes.char?
Message-ID: <COL101-W44D06778829668CD8100FDE6C50@phx.gbl>


Is it deliberate that CHAR and Ctypes.char don't match?
I'm building the tree with -new_adr.
"Many" of the breaks are due to this mismatch. Not real bugs. I use LOOPHOLE to let it compile.
"Many" are due to socklen_t. Real bugs on 64bit problems, at least in head.
I'm not sure there are any others yet.

?- Jay
 		 	   		  

From hosking at cs.purdue.edu  Wed Jun 23 15:57:04 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 23 Jun 2010 09:57:04 -0400
Subject: [M3devel] CHAR vs. Ctypes.char?
In-Reply-To: <COL101-W44D06778829668CD8100FDE6C50@phx.gbl>
References: <COL101-W44D06778829668CD8100FDE6C50@phx.gbl>
Message-ID: <9FB15BB1-E00A-4AB4-A580-71981F0A65C0@cs.purdue.edu>

CHAR is an enumeration.
Ctypes.char is a subrange.

Never the twain shall meet.

On 23 Jun 2010, at 09:40, Jay K wrote:

> 
> Is it deliberate that CHAR and Ctypes.char don't match?
> I'm building the tree with -new_adr.
> "Many" of the breaks are due to this mismatch. Not real bugs. I use LOOPHOLE to let it compile.
> "Many" are due to socklen_t. Real bugs on 64bit problems, at least in head.
> I'm not sure there are any others yet.
> 
>  - Jay
> 		 	   		  



From jay.krell at cornell.edu  Thu Jun 24 00:52:25 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 23 Jun 2010 22:52:25 +0000
Subject: [M3devel] CHAR vs. Ctypes.char?
In-Reply-To: <9FB15BB1-E00A-4AB4-A580-71981F0A65C0@cs.purdue.edu>
References: <COL101-W44D06778829668CD8100FDE6C50@phx.gbl>,
	<9FB15BB1-E00A-4AB4-A580-71981F0A65C0@cs.purdue.edu>
Message-ID: <COL101-W4372CBD0AF692D3E5990CCE6C50@phx.gbl>


Something should change.
I'm not sure exactly what but I'll make some suggestions.


char_star changed from UNTRACED REF char to UNTRACED REF CHAR
? Probably not this.
? Possibly introduce Utypes.char_star = UNTRACED REF CHAR
? but leave Ctypes.char_star alone. Possibly. This is I think the least
? likely option.
? 

and/or


Utypes.CHAR_star introduced = UNTRACED REF CHAR
many uses of char_star in m3core/src/unix changed to CHAR_star


and/or


Text.i3 already has FromChars that takes array of CHAR
add function FromCChars or somesuch that takes array of Ctypes.char
This I think is most likely.
Even though it adds to a "standard" interface.
It could be TextEx or TextExtras or such if that helps.


In particular, we often have:


Unix.i3: PROCEDURE GetFoo(char_star);


Wrapper.i3:
PROCEDURE GetFoo():TEXT=
VAR buff; ARRAY [0..N] of CHAR;
BEGIN
? Unix.GetFoo(ADR(buff[0]));
? RETURN Text.FromChars(buff);
END GetFoo;


This doesn't work with -new_adr.
? because ADR(CHAR) != ADR(char).
? 

At a minimum you have to:
? Unix.GetFoo(LOOPHOLE(ADR(buff[0]), ADDRESS));


but I'd much rather something more typesafe.


e.g.:
Wrapper.i3:
PROCEDURE GetFoo():TEXT=
VAR buff; ARRAY [0..N] of Ctypes.char;
BEGIN
? Unix.GetFoo(ADR(buff[0]));
? RETURN Text.FromCChars(buff);
END GetFoo;

or

Unix.i3:
PROCEDURE GetFoo(CHAR_star);

Wrapper.i3:
PROCEDURE GetFoo():TEXT=
VAR buff; ARRAY [0..N] of CHAR;
BEGIN
? Unix.GetFoo(ADR(buff[0]));
? RETURN Text.FromChars(buff);
END GetFoo;


or even something fancier like:


Unix.i3:
PROCEDURE GetFoo():TEXT; !



To whatever extent this occurs in sysutils, if at all, probably have to just LOOPHOLE,
since it needs to be compatible with a mix of compilers and m3core.


?- Jay









----------------------------------------
> Subject: Re: [M3devel] CHAR vs. Ctypes.char?
> From: hosking at cs.purdue.edu
> Date: Wed, 23 Jun 2010 09:57:04 -0400
> CC: m3devel at elegosoft.com
> To: jay.krell at cornell.edu
>
> CHAR is an enumeration.
> Ctypes.char is a subrange.
>
> Never the twain shall meet.
>
> On 23 Jun 2010, at 09:40, Jay K wrote:
>
>>
>> Is it deliberate that CHAR and Ctypes.char don't match?
>> I'm building the tree with -new_adr.
>> "Many" of the breaks are due to this mismatch. Not real bugs. I use LOOPHOLE to let it compile.
>> "Many" are due to socklen_t. Real bugs on 64bit problems, at least in head.
>> I'm not sure there are any others yet.
>>
>> - Jay
>>
>
 		 	   		  

From jay.krell at cornell.edu  Thu Jun 24 00:59:10 2010
From: jay.krell at cornell.edu (Jay K)
Date: Wed, 23 Jun 2010 22:59:10 +0000
Subject: [M3devel] -new_adr the default?
Message-ID: <COL101-W54C167232C5F9B2A6C4963E6C50@phx.gbl>


I'd like to make -new_adr the default.
It is more typesafe than the current way and finds bugs.
? Granted, so far I think only bugs that I introduced.


First I will make the tree compile either way.
?Such as by fixing the bugs and resolving somehow the char vs. CHAR breaks.


Changing this does break code, albeit only unsafe code.
? There isn't much of that? Right? :)
Sometimes that code had bugs, sometimes not.


I believe type safety and static checking (and sometimes runtime checking) do have a place in unsafe code.
?Maybe not as much as in safe code, but definitely still something.


The old way is that ADR return ADDRESS, similar to void*, and it is silently convertable to any pointer type. I think.


The new way is that ADR(T) returns UNTRACED REF T is is only silently convertable to ADDRESS? Or nothing at all?
?Esp. not silently convertable to UNTRACED REF U.


So there are buggy places that do:
PROCEDURE Foo(UNTRACED REF T);

PROCEDURE Bar()
VAR u: U;
BEGIN
?Foo(ADR(u));
END Bar;


That compile with old ADR but not with new ADR.
As I changed socklent_t between int and INTEGER, such code silently kept compiling.
? But possibly silently corrupting the stack or producing the wrong data.


This -new_adr feature was already implemented in the compiler unknown long ago.
? I didn't know but Tony pointed it out.
We should probably look at its impementation make sure we aren't switching on some buggy unused code.
So far switching it on I've only seen correct new errors.


?- Jay
 		 	   		  

From hosking at cs.purdue.edu  Thu Jun 24 01:09:35 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Wed, 23 Jun 2010 19:09:35 -0400
Subject: [M3devel] CHAR vs. Ctypes.char?
In-Reply-To: <COL101-W4372CBD0AF692D3E5990CCE6C50@phx.gbl>
References: <COL101-W44D06778829668CD8100FDE6C50@phx.gbl>,
	<9FB15BB1-E00A-4AB4-A580-71981F0A65C0@cs.purdue.edu>
	<COL101-W4372CBD0AF692D3E5990CCE6C50@phx.gbl>
Message-ID: <44BE3590-165E-42A2-AB10-4330DBE45205@cs.purdue.edu>

ADR isn't safe so why not just LOOPHOLE?

Sent from my iPhone

On Jun 23, 2010, at 6:52 PM, Jay K <jay.krell at cornell.edu> wrote:

>
> Something should change.
> I'm not sure exactly what but I'll make some suggestions.
>
>
> char_star changed from UNTRACED REF char to UNTRACED REF CHAR
>   Probably not this.
>   Possibly introduce Utypes.char_star = UNTRACED REF CHAR
>   but leave Ctypes.char_star alone. Possibly. This is I think the  
> least
>   likely option.
>
>
> and/or
>
>
> Utypes.CHAR_star introduced = UNTRACED REF CHAR
> many uses of char_star in m3core/src/unix changed to CHAR_star
>
>
> and/or
>
>
> Text.i3 already has FromChars that takes array of CHAR
> add function FromCChars or somesuch that takes array of Ctypes.char
> This I think is most likely.
> Even though it adds to a "standard" interface.
> It could be TextEx or TextExtras or such if that helps.
>
>
> In particular, we often have:
>
>
> Unix.i3: PROCEDURE GetFoo(char_star);
>
>
> Wrapper.i3:
> PROCEDURE GetFoo():TEXT=
> VAR buff; ARRAY [0..N] of CHAR;
> BEGIN
>   Unix.GetFoo(ADR(buff[0]));
>   RETURN Text.FromChars(buff);
> END GetFoo;
>
>
> This doesn't work with -new_adr.
>   because ADR(CHAR) != ADR(char).
>
>
> At a minimum you have to:
>   Unix.GetFoo(LOOPHOLE(ADR(buff[0]), ADDRESS));
>
>
> but I'd much rather something more typesafe.
>
>
> e.g.:
> Wrapper.i3:
> PROCEDURE GetFoo():TEXT=
> VAR buff; ARRAY [0..N] of Ctypes.char;
> BEGIN
>   Unix.GetFoo(ADR(buff[0]));
>   RETURN Text.FromCChars(buff);
> END GetFoo;
>
> or
>
> Unix.i3:
> PROCEDURE GetFoo(CHAR_star);
>
> Wrapper.i3:
> PROCEDURE GetFoo():TEXT=
> VAR buff; ARRAY [0..N] of CHAR;
> BEGIN
>   Unix.GetFoo(ADR(buff[0]));
>   RETURN Text.FromChars(buff);
> END GetFoo;
>
>
> or even something fancier like:
>
>
> Unix.i3:
> PROCEDURE GetFoo():TEXT; !
>
>
>
> To whatever extent this occurs in sysutils, if at all, probably have  
> to just LOOPHOLE,
> since it needs to be compatible with a mix of compilers and m3core.
>
>
>  - Jay
>
>
>
>
>
>
>
>
>
> ----------------------------------------
>> Subject: Re: [M3devel] CHAR vs. Ctypes.char?
>> From: hosking at cs.purdue.edu
>> Date: Wed, 23 Jun 2010 09:57:04 -0400
>> CC: m3devel at elegosoft.com
>> To: jay.krell at cornell.edu
>>
>> CHAR is an enumeration.
>> Ctypes.char is a subrange.
>>
>> Never the twain shall meet.
>>
>> On 23 Jun 2010, at 09:40, Jay K wrote:
>>
>>>
>>> Is it deliberate that CHAR and Ctypes.char don't match?
>>> I'm building the tree with -new_adr.
>>> "Many" of the breaks are due to this mismatch. Not real bugs. I  
>>> use LOOPHOLE to let it compile.
>>> "Many" are due to socklen_t. Real bugs on 64bit problems, at least  
>>> in head.
>>> I'm not sure there are any others yet.
>>>
>>> - Jay
>>>
>>
>


From jay.krell at cornell.edu  Thu Jun 24 04:24:47 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 24 Jun 2010 02:24:47 +0000
Subject: [M3devel] CHAR vs. Ctypes.char?
In-Reply-To: <44BE3590-165E-42A2-AB10-4330DBE45205@cs.purdue.edu>
References: <COL101-W44D06778829668CD8100FDE6C50@phx.gbl>, ,
	<9FB15BB1-E00A-4AB4-A580-71981F0A65C0@cs.purdue.edu>,
	<COL101-W4372CBD0AF692D3E5990CCE6C50@phx.gbl>,
	<44BE3590-165E-42A2-AB10-4330DBE45205@cs.purdue.edu>
Message-ID: <COL101-W53DD740C001143B75A1426E6C60@phx.gbl>


ADR should be "less unsafe".
Perhaps in general Modula-3 "unsafe" can/should be "less unsafe".
e.g. "Only as unsafe as needed to get the 'usual' job done, and no more".
 
 
Imagine if the types involved actually changed in some other way.
LOOPHOLE would likely make almost anything compile.
Whereas my other suggestions add a significant amount of type checking and deliberately fail to compile many incorrect forms.
 
 
There is not, or should be, this "harsh" line where there are no rules or static checking in unsafe code.
There is still a significant amount of checking and a significant confidence that if it compiles, it has a certain amount of correctness and "odds" of working. I've written a lot of C code, even recently. It's not just a lost cause.
 
 
 
 - Jay

----------------------------------------
> From: hosking at cs.purdue.edu
> To: jay.krell at cornell.edu
> Date: Wed, 23 Jun 2010 19:09:35 -0400
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] CHAR vs. Ctypes.char?
>
> ADR isn't safe so why not just LOOPHOLE?
>
> Sent from my iPhone
>
> On Jun 23, 2010, at 6:52 PM, Jay K wrote:
>
>>
>> Something should change.
>> I'm not sure exactly what but I'll make some suggestions.
>>
>>
>> char_star changed from UNTRACED REF char to UNTRACED REF CHAR
>> Probably not this.
>> Possibly introduce Utypes.char_star = UNTRACED REF CHAR
>> but leave Ctypes.char_star alone. Possibly. This is I think the
>> least
>> likely option.
>>
>>
>> and/or
>>
>>
>> Utypes.CHAR_star introduced = UNTRACED REF CHAR
>> many uses of char_star in m3core/src/unix changed to CHAR_star
>>
>>
>> and/or
>>
>>
>> Text.i3 already has FromChars that takes array of CHAR
>> add function FromCChars or somesuch that takes array of Ctypes.char
>> This I think is most likely.
>> Even though it adds to a "standard" interface.
>> It could be TextEx or TextExtras or such if that helps.
>>
>>
>> In particular, we often have:
>>
>>
>> Unix.i3: PROCEDURE GetFoo(char_star);
>>
>>
>> Wrapper.i3:
>> PROCEDURE GetFoo():TEXT=
>> VAR buff; ARRAY [0..N] of CHAR;
>> BEGIN
>> Unix.GetFoo(ADR(buff[0]));
>> RETURN Text.FromChars(buff);
>> END GetFoo;
>>
>>
>> This doesn't work with -new_adr.
>> because ADR(CHAR) != ADR(char).
>>
>>
>> At a minimum you have to:
>> Unix.GetFoo(LOOPHOLE(ADR(buff[0]), ADDRESS));
>>
>>
>> but I'd much rather something more typesafe.
>>
>>
>> e.g.:
>> Wrapper.i3:
>> PROCEDURE GetFoo():TEXT=
>> VAR buff; ARRAY [0..N] of Ctypes.char;
>> BEGIN
>> Unix.GetFoo(ADR(buff[0]));
>> RETURN Text.FromCChars(buff);
>> END GetFoo;
>>
>> or
>>
>> Unix.i3:
>> PROCEDURE GetFoo(CHAR_star);
>>
>> Wrapper.i3:
>> PROCEDURE GetFoo():TEXT=
>> VAR buff; ARRAY [0..N] of CHAR;
>> BEGIN
>> Unix.GetFoo(ADR(buff[0]));
>> RETURN Text.FromChars(buff);
>> END GetFoo;
>>
>>
>> or even something fancier like:
>>
>>
>> Unix.i3:
>> PROCEDURE GetFoo():TEXT; !
>>
>>
>>
>> To whatever extent this occurs in sysutils, if at all, probably have
>> to just LOOPHOLE,
>> since it needs to be compatible with a mix of compilers and m3core.
>>
>>
>> - Jay
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> ----------------------------------------
>>> Subject: Re: [M3devel] CHAR vs. Ctypes.char?
>>> From: hosking at cs.purdue.edu
>>> Date: Wed, 23 Jun 2010 09:57:04 -0400
>>> CC: m3devel at elegosoft.com
>>> To: jay.krell at cornell.edu
>>>
>>> CHAR is an enumeration.
>>> Ctypes.char is a subrange.
>>>
>>> Never the twain shall meet.
>>>
>>> On 23 Jun 2010, at 09:40, Jay K wrote:
>>>
>>>>
>>>> Is it deliberate that CHAR and Ctypes.char don't match?
>>>> I'm building the tree with -new_adr.
>>>> "Many" of the breaks are due to this mismatch. Not real bugs. I
>>>> use LOOPHOLE to let it compile.
>>>> "Many" are due to socklen_t. Real bugs on 64bit problems, at least
>>>> in head.
>>>> I'm not sure there are any others yet.
>>>>
>>>> - Jay
>>>>
>>>
>> 		 	   		  

From jay.krell at cornell.edu  Thu Jun 24 04:27:31 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 24 Jun 2010 02:27:31 +0000
Subject: [M3devel] CHAR vs. Ctypes.char?
In-Reply-To: <COL101-W53DD740C001143B75A1426E6C60@phx.gbl>
References: <COL101-W44D06778829668CD8100FDE6C50@phx.gbl>,
	, , <9FB15BB1-E00A-4AB4-A580-71981F0A65C0@cs.purdue.edu>, ,
	<COL101-W4372CBD0AF692D3E5990CCE6C50@phx.gbl>, ,
	<44BE3590-165E-42A2-AB10-4330DBE45205@cs.purdue.edu>,
	<COL101-W53DD740C001143B75A1426E6C60@phx.gbl>
Message-ID: <COL101-W3D4D5225FE282315363ECE6C60@phx.gbl>


oops...perhaps LOOPHOLE to "CHAR_star" or "char_star" not so bad.
  Program can read locally and decide quickly that basically char==CHAR and casting related to moving between them not so bad. If the types "really" change, it'd be to WCHAR or such and the LOOPHOLE to CHAR/char_star would still fail to compile.
 
LOOPHOLE to ADDRESS is what I'm avoiding.
 
?
 
Still, I like the idea of Text.FromCtypesChars() or such.
 
 
 - Jay


----------------------------------------
> From: jay.krell at cornell.edu
> To: hosking at cs.purdue.edu
> Date: Thu, 24 Jun 2010 02:24:47 +0000
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] CHAR vs. Ctypes.char?
>
>
> ADR should be "less unsafe".
> Perhaps in general Modula-3 "unsafe" can/should be "less unsafe".
> e.g. "Only as unsafe as needed to get the 'usual' job done, and no more".
>
>
> Imagine if the types involved actually changed in some other way.
> LOOPHOLE would likely make almost anything compile.
> Whereas my other suggestions add a significant amount of type checking and deliberately fail to compile many incorrect forms.
>
>
> There is not, or should be, this "harsh" line where there are no rules or static checking in unsafe code.
> There is still a significant amount of checking and a significant confidence that if it compiles, it has a certain amount of correctness and "odds" of working. I've written a lot of C code, even recently. It's not just a lost cause.
>
>
>
> - Jay
>
> ----------------------------------------
>> From: hosking at cs.purdue.edu
>> To: jay.krell at cornell.edu
>> Date: Wed, 23 Jun 2010 19:09:35 -0400
>> CC: m3devel at elegosoft.com
>> Subject: Re: [M3devel] CHAR vs. Ctypes.char?
>>
>> ADR isn't safe so why not just LOOPHOLE?
>>
>> Sent from my iPhone
>>
>> On Jun 23, 2010, at 6:52 PM, Jay K wrote:
>>
>>>
>>> Something should change.
>>> I'm not sure exactly what but I'll make some suggestions.
>>>
>>>
>>> char_star changed from UNTRACED REF char to UNTRACED REF CHAR
>>> Probably not this.
>>> Possibly introduce Utypes.char_star = UNTRACED REF CHAR
>>> but leave Ctypes.char_star alone. Possibly. This is I think the
>>> least
>>> likely option.
>>>
>>>
>>> and/or
>>>
>>>
>>> Utypes.CHAR_star introduced = UNTRACED REF CHAR
>>> many uses of char_star in m3core/src/unix changed to CHAR_star
>>>
>>>
>>> and/or
>>>
>>>
>>> Text.i3 already has FromChars that takes array of CHAR
>>> add function FromCChars or somesuch that takes array of Ctypes.char
>>> This I think is most likely.
>>> Even though it adds to a "standard" interface.
>>> It could be TextEx or TextExtras or such if that helps.
>>>
>>>
>>> In particular, we often have:
>>>
>>>
>>> Unix.i3: PROCEDURE GetFoo(char_star);
>>>
>>>
>>> Wrapper.i3:
>>> PROCEDURE GetFoo():TEXT=
>>> VAR buff; ARRAY [0..N] of CHAR;
>>> BEGIN
>>> Unix.GetFoo(ADR(buff[0]));
>>> RETURN Text.FromChars(buff);
>>> END GetFoo;
>>>
>>>
>>> This doesn't work with -new_adr.
>>> because ADR(CHAR) != ADR(char).
>>>
>>>
>>> At a minimum you have to:
>>> Unix.GetFoo(LOOPHOLE(ADR(buff[0]), ADDRESS));
>>>
>>>
>>> but I'd much rather something more typesafe.
>>>
>>>
>>> e.g.:
>>> Wrapper.i3:
>>> PROCEDURE GetFoo():TEXT=
>>> VAR buff; ARRAY [0..N] of Ctypes.char;
>>> BEGIN
>>> Unix.GetFoo(ADR(buff[0]));
>>> RETURN Text.FromCChars(buff);
>>> END GetFoo;
>>>
>>> or
>>>
>>> Unix.i3:
>>> PROCEDURE GetFoo(CHAR_star);
>>>
>>> Wrapper.i3:
>>> PROCEDURE GetFoo():TEXT=
>>> VAR buff; ARRAY [0..N] of CHAR;
>>> BEGIN
>>> Unix.GetFoo(ADR(buff[0]));
>>> RETURN Text.FromChars(buff);
>>> END GetFoo;
>>>
>>>
>>> or even something fancier like:
>>>
>>>
>>> Unix.i3:
>>> PROCEDURE GetFoo():TEXT; !
>>>
>>>
>>>
>>> To whatever extent this occurs in sysutils, if at all, probably have
>>> to just LOOPHOLE,
>>> since it needs to be compatible with a mix of compilers and m3core.
>>>
>>>
>>> - Jay
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ----------------------------------------
>>>> Subject: Re: [M3devel] CHAR vs. Ctypes.char?
>>>> From: hosking at cs.purdue.edu
>>>> Date: Wed, 23 Jun 2010 09:57:04 -0400
>>>> CC: m3devel at elegosoft.com
>>>> To: jay.krell at cornell.edu
>>>>
>>>> CHAR is an enumeration.
>>>> Ctypes.char is a subrange.
>>>>
>>>> Never the twain shall meet.
>>>>
>>>> On 23 Jun 2010, at 09:40, Jay K wrote:
>>>>
>>>>>
>>>>> Is it deliberate that CHAR and Ctypes.char don't match?
>>>>> I'm building the tree with -new_adr.
>>>>> "Many" of the breaks are due to this mismatch. Not real bugs. I
>>>>> use LOOPHOLE to let it compile.
>>>>> "Many" are due to socklen_t. Real bugs on 64bit problems, at least
>>>>> in head.
>>>>> I'm not sure there are any others yet.
>>>>>
>>>>> - Jay
>>>>>
>>>>
>>> 		 	   		  

From jay.krell at cornell.edu  Thu Jun 24 11:46:27 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 24 Jun 2010 09:46:27 +0000
Subject: [M3devel] alignment in X.i3?
Message-ID: <COL101-W191F4612D5170DE1634C24E6C60@phx.gbl>


I don't suppose anyone else is seeing this?

-- building in AMD64_DARWIN ---

ignoring ../src/m3overrides

new source -> compiling XMachine.i3
new source -> compiling X.i3
"../src/Common/X.i3", line 1376: Could not find a legal alignment for the packed type.
"../src/Common/X.i3", line 1010: Could not find a legal alignment for the packed type.
2 errors encountered
new source -> compiling Xatom.i3
new source -> compiling Xmbuf.i3

I'll keep digging..
?- Jay

 		 	   		  

From jay.krell at cornell.edu  Thu Jun 24 12:01:10 2010
From: jay.krell at cornell.edu (Jay K)
Date: Thu, 24 Jun 2010 10:01:10 +0000
Subject: [M3devel] alignment in X.i3?
In-Reply-To: <COL101-W191F4612D5170DE1634C24E6C60@phx.gbl>
References: <COL101-W191F4612D5170DE1634C24E6C60@phx.gbl>
Message-ID: <COL101-W32744492F5C2FFF711E089E6C60@phx.gbl>


While I did this to myself by accident, there is a "real" question buried here.
I forgot I was experimenting with:

Index: 32BITS/BasicCtypes.i3
===================================================================
RCS file: /usr/cvs/cm3/m3-libs/m3core/src/C/32BITS/BasicCtypes.i3,v
retrieving revision 1.13
diff -u -r1.13 BasicCtypes.i3
--- 32BITS/BasicCtypes.i3??? 11 Feb 2010 12:24:33 -0000??? 1.13
+++ 32BITS/BasicCtypes.i3??? 24 Jun 2010 09:54:01 -0000
@@ -11,15 +11,15 @@
?
?TYPE
?? (* the four signed integer types *)
-? signed_char??????? = [-16_7f-1 .. 16_7f];
-? short_int????????? = [-16_7fff-1 .. 16_7fff];
-? int??????????????? = [-16_7fffffff-1 .. 16_7fffffff];
-? long_int?????????? = [-16_7fffffff-1 .. 16_7fffffff];
-? long_long????????? = [-16_7fffffffffffffffL-1L .. 16_7fffffffffffffffL];
+? signed_char??????? = BITS 8 FOR [-16_7f-1 .. 16_7f];
+? short_int????????? = BITS 16 FOR [-16_7fff-1 .. 16_7fff];
+? int??????????????? = BITS 32 FOR [-16_7fffffff-1 .. 16_7fffffff];
+? long_int?????????? = BITS 32 FOR [-16_7fffffff-1 .. 16_7fffffff];
+? long_long????????? = BITS 64 FOR [-16_7fffffffffffffffL-1L .. 16_7fffffffffffffffL];
?
?? (* the four unsigned integer types *)
-? unsigned_char????? = [16_0 .. 16_ff];
-? unsigned_short_int = [16_0 .. 16_ffff];
+? unsigned_char????? = BITS 8 FOR [16_0 .. 16_ff];
+? unsigned_short_int = BITS 16 FOR [16_0 .. 16_ffff];
?? unsigned_int?????? = Word.T;
?? unsigned_long_int? = Word.T;
?? unsigned_long_long = Long.T;
@@ -33,5 +33,3 @@
?? char?????????????? = signed_char;
?
?END BasicCtypes.
-
-
Index: 64BITS/BasicCtypes.i3
===================================================================
RCS file: /usr/cvs/cm3/m3-libs/m3core/src/C/64BITS/BasicCtypes.i3,v
retrieving revision 1.8
diff -u -r1.8 BasicCtypes.i3
--- 64BITS/BasicCtypes.i3??? 13 Apr 2008 19:44:02 -0000??? 1.8
+++ 64BITS/BasicCtypes.i3??? 24 Jun 2010 09:54:01 -0000
@@ -11,16 +11,16 @@
?
?TYPE
?? (* the four signed integer types *)
-? signed_char??????? = [-16_7f-1 .. 16_7f];
-? short_int????????? = [-16_7fff-1 .. 16_7fff];
-? int??????????????? = [-16_7fffffff-1 .. 16_7fffffff];
-? long_int?????????? = [-16_7fffffffffffffff -1? .. 16_7fffffffffffffff ];
-? long_long????????? = [-16_7fffffffffffffffL-1L .. 16_7fffffffffffffffL];
+? signed_char??????? = BITS 8 FOR [-16_7f-1 .. 16_7f];
+? short_int????????? = BITS 16 FOR [-16_7fff-1 .. 16_7fff];
+? int??????????????? = BITS 32 FOR [-16_7fffffff-1 .. 16_7fffffff];
+? long_int?????????? = BITS 64 FOR [-16_7fffffffffffffff -1? .. 16_7fffffffffffffff ];
+? long_long????????? = BITS 64 FOR [-16_7fffffffffffffffL-1L .. 16_7fffffffffffffffL];
?
?? (* the four unsigned integer types *)
-? unsigned_char????? = [16_0 .. 16_ff];
-? unsigned_short_int = [16_0 .. 16_ffff];
-? unsigned_int?????? = [16_0 .. 16_ffffffff];
+? unsigned_char????? = BITS 8 FOR [16_0 .. 16_ff];
+? unsigned_short_int = BITS 16 FOR [16_0 .. 16_ffff];
+? unsigned_int?????? = BITS 32 FOR [16_0 .. 16_ffffffff];
?? unsigned_long_int? = Word.T;
?? unsigned_long_long = Long.T;
?
@@ -33,5 +33,3 @@
?? char?????????????? = signed_char;
?
?END BasicCtypes.

and then I think there is a "hole" here:

? Int = int; Short = short; Long = long; Char = char;
? Bool????? = Int;

? XMotionEvent = RECORD
???? type: Int;???????????? (* of event *)

(* 32bits padding for alignment here likely *)

???? serial: unsigned_long; (* # of last request processed by server *)
???? send_event: Bool;????? (* true if this came from a SendEvent request *)

(* 32bits padding for alignment here likely also *)


???? display: DisplayStar;? (* Display the event was read from *)
???? window: Window;??????? (* "event" window reported relative to *)
???? root: Window;????????? (* root window that the event occured on *)
???? subwindow: Window;???? (* child window *)
???? time: Time;??????????? (* milliseconds *)
???? x, y: Int;???????????? (* pointer x, y coordinates in event window *)
???? x_root, y_root: Int;?? (* coordinates relative to root *)
???? state: unsigned_int;?? (* key or button mask *)
???? is_hint: Char;???????? (* detail *)
???? same_screen: Bool????? (* same screen flag *)
? END;


Am I write to be concerned with this cloning of header files?
Modula-3 probably inserts the holes/padding just like the C compiler probably inserts the holes/padding,
but it an area that deserves some extra close checking?


Like by passing the size of the record to some C that compares it to the size of the C type?
Or more aggressively the size/offset of each field?


Or maybe introducing a "more portable" C layer, where the "smallest" fields is an INTEGER or a LONGINT?


Or maybe soon someone else will apply some swig-like automation here, and generate the checks?


?- Jay


----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Date: Thu, 24 Jun 2010 09:46:27 +0000
> Subject: [M3devel] alignment in X.i3?
>
>
> I don't suppose anyone else is seeing this?
>
> -- building in AMD64_DARWIN ---
>
> ignoring ../src/m3overrides
>
> new source -> compiling XMachine.i3
> new source -> compiling X.i3
> "../src/Common/X.i3", line 1376: Could not find a legal alignment for the packed type.
> "../src/Common/X.i3", line 1010: Could not find a legal alignment for the packed type.
> 2 errors encountered
> new source -> compiling Xatom.i3
> new source -> compiling Xmbuf.i3
>
> I'll keep digging..
>  - Jay
>
>
 		 	   		  

From rodney_bates at lcwb.coop  Thu Jun 24 23:44:58 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Thu, 24 Jun 2010 16:44:58 -0500
Subject: [M3devel] alignment in X.i3?
In-Reply-To: <COL101-W32744492F5C2FFF711E089E6C60@phx.gbl>
References: <COL101-W191F4612D5170DE1634C24E6C60@phx.gbl>
	<COL101-W32744492F5C2FFF711E089E6C60@phx.gbl>
Message-ID: <4C23D1DA.60407@lcwb.coop>



Jay K wrote:
> While I did this to myself by accident, there is a "real" question buried here.
> I forgot I was experimenting with:
> 
> Index: 32BITS/BasicCtypes.i3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-libs/m3core/src/C/32BITS/BasicCtypes.i3,v
> retrieving revision 1.13
> diff -u -r1.13 BasicCtypes.i3
> --- 32BITS/BasicCtypes.i3    11 Feb 2010 12:24:33 -0000    1.13
> +++ 32BITS/BasicCtypes.i3    24 Jun 2010 09:54:01 -0000
> @@ -11,15 +11,15 @@
>  
>  TYPE
>    (* the four signed integer types *)
> -  signed_char        = [-16_7f-1 .. 16_7f];
> -  short_int          = [-16_7fff-1 .. 16_7fff];
> -  int                = [-16_7fffffff-1 .. 16_7fffffff];
> -  long_int           = [-16_7fffffff-1 .. 16_7fffffff];
> -  long_long          = [-16_7fffffffffffffffL-1L .. 16_7fffffffffffffffL];
> +  signed_char        = BITS 8 FOR [-16_7f-1 .. 16_7f];
> +  short_int          = BITS 16 FOR [-16_7fff-1 .. 16_7fff];
> +  int                = BITS 32 FOR [-16_7fffffff-1 .. 16_7fffffff];
> +  long_int           = BITS 32 FOR [-16_7fffffff-1 .. 16_7fffffff];
> +  long_long          = BITS 64 FOR [-16_7fffffffffffffffL-1L .. 16_7fffffffffffffffL];

This is a block I've been around before.  Packed (BITS) types are not what many
people seem to think.

1) They don't do anything at all for whole variables, parameters, etc. (Except
    create some non-assignabilities).  They *only* apply when used as the type of
    a record field, object field, or array element.

2) When they do apply, they require the compiler not only to use exactly the given
    number of bits, but also, to *add no padding* ahead of the field/element.

If 2) conflicts with normal alignment rules, or any other discretionary rules
the compiler uses (e.g., fields/elements cannot cross native word boundaries),
it may/must refuse.  And this means what you really need will vary from one
record/array to another.  This whole system  is really intended
only for explicit control of bit layouts of records and arrays.

I have finally gotten it that I never want to use BITS in a named type that
could be used in more than one place.  Instead, I always put the BITS in as
an anonymous part of the type of the field or element.  This avoids this
problem.  E.g.:

TYPE T = ...;
...
TYPE R = RECORD
            ...
            F: BITS 8 FOR T;
            ...
          END;

I really think this kind of explicit layout control is, for the most part,
incompatible with writing portable code.  Certainly, the original language
designers seem to have thought so.

It does raise another question.  To use LOOPHOLE, you have to know that the
BITSIZE values of the two types match up.  And what those are is implementation-
dependent.  So if, e.g., BITS 16 FOR [0..16_FF] must occupy 16 bits when a
field of a record, but the compiler might likely give it only 8 when an
autonomous variable (as it does now for [0..16_FF]), what is BITSIZE of
this type?  And I don't just mean what does the current implementation
do here.  I don't believe the language specifies this.

>  
>    (* the four unsigned integer types *)
> -  unsigned_char      = [16_0 .. 16_ff];
> -  unsigned_short_int = [16_0 .. 16_ffff];
> +  unsigned_char      = BITS 8 FOR [16_0 .. 16_ff];
> +  unsigned_short_int = BITS 16 FOR [16_0 .. 16_ffff];
>    unsigned_int       = Word.T;
>    unsigned_long_int  = Word.T;
>    unsigned_long_long = Long.T;
> @@ -33,5 +33,3 @@
>    char               = signed_char;
>  
>  END BasicCtypes.
> -
> -
> Index: 64BITS/BasicCtypes.i3
> ===================================================================
> RCS file: /usr/cvs/cm3/m3-libs/m3core/src/C/64BITS/BasicCtypes.i3,v
> retrieving revision 1.8
> diff -u -r1.8 BasicCtypes.i3
> --- 64BITS/BasicCtypes.i3    13 Apr 2008 19:44:02 -0000    1.8
> +++ 64BITS/BasicCtypes.i3    24 Jun 2010 09:54:01 -0000
> @@ -11,16 +11,16 @@
>  
>  TYPE
>    (* the four signed integer types *)
> -  signed_char        = [-16_7f-1 .. 16_7f];
> -  short_int          = [-16_7fff-1 .. 16_7fff];
> -  int                = [-16_7fffffff-1 .. 16_7fffffff];
> -  long_int           = [-16_7fffffffffffffff -1  .. 16_7fffffffffffffff ];
> -  long_long          = [-16_7fffffffffffffffL-1L .. 16_7fffffffffffffffL];
> +  signed_char        = BITS 8 FOR [-16_7f-1 .. 16_7f];
> +  short_int          = BITS 16 FOR [-16_7fff-1 .. 16_7fff];
> +  int                = BITS 32 FOR [-16_7fffffff-1 .. 16_7fffffff];
> +  long_int           = BITS 64 FOR [-16_7fffffffffffffff -1  .. 16_7fffffffffffffff ];
> +  long_long          = BITS 64 FOR [-16_7fffffffffffffffL-1L .. 16_7fffffffffffffffL];
>  
>    (* the four unsigned integer types *)
> -  unsigned_char      = [16_0 .. 16_ff];
> -  unsigned_short_int = [16_0 .. 16_ffff];
> -  unsigned_int       = [16_0 .. 16_ffffffff];
> +  unsigned_char      = BITS 8 FOR [16_0 .. 16_ff];
> +  unsigned_short_int = BITS 16 FOR [16_0 .. 16_ffff];
> +  unsigned_int       = BITS 32 FOR [16_0 .. 16_ffffffff];
>    unsigned_long_int  = Word.T;
>    unsigned_long_long = Long.T;
>  
> @@ -33,5 +33,3 @@
>    char               = signed_char;
>  
>  END BasicCtypes.
> 
> and then I think there is a "hole" here:
> 
>   Int = int; Short = short; Long = long; Char = char;
>   Bool      = Int;
> 
>   XMotionEvent = RECORD
>      type: Int;             (* of event *)
> 
> (* 32bits padding for alignment here likely *)
> 
>      serial: unsigned_long; (* # of last request processed by server *)
>      send_event: Bool;      (* true if this came from a SendEvent request *)
> 
> (* 32bits padding for alignment here likely also *)
> 
> 
>      display: DisplayStar;  (* Display the event was read from *)
>      window: Window;        (* "event" window reported relative to *)
>      root: Window;          (* root window that the event occured on *)
>      subwindow: Window;     (* child window *)
>      time: Time;            (* milliseconds *)
>      x, y: Int;             (* pointer x, y coordinates in event window *)
>      x_root, y_root: Int;   (* coordinates relative to root *)
>      state: unsigned_int;   (* key or button mask *)
>      is_hint: Char;         (* detail *)
>      same_screen: Bool      (* same screen flag *)
>   END;
> 
> 
> Am I write to be concerned with this cloning of header files?
> Modula-3 probably inserts the holes/padding just like the C compiler probably inserts the holes/padding,
> but it an area that deserves some extra close checking?
> 
> 
> Like by passing the size of the record to some C that compares it to the size of the C type?
> Or more aggressively the size/offset of each field?
> 
> 
> Or maybe introducing a "more portable" C layer, where the "smallest" fields is an INTEGER or a LONGINT?
> 
> 
> Or maybe soon someone else will apply some swig-like automation here, and generate the checks?
> 
> 
>  - Jay
> 
> 
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: m3devel at elegosoft.com
>> Date: Thu, 24 Jun 2010 09:46:27 +0000
>> Subject: [M3devel] alignment in X.i3?
>>
>>
>> I don't suppose anyone else is seeing this?
>>
>> -- building in AMD64_DARWIN ---
>>
>> ignoring ../src/m3overrides
>>
>> new source -> compiling XMachine.i3
>> new source -> compiling X.i3
>> "../src/Common/X.i3", line 1376: Could not find a legal alignment for the packed type.
>> "../src/Common/X.i3", line 1010: Could not find a legal alignment for the packed type.
>> 2 errors encountered
>> new source -> compiling Xatom.i3
>> new source -> compiling Xmbuf.i3
>>
>> I'll keep digging..
>>  - Jay
>>
>>
>  		 	   		  


From rodney_bates at lcwb.coop  Fri Jun 25 00:03:55 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Thu, 24 Jun 2010 17:03:55 -0500
Subject: [M3devel] LOOPHOLE and open array types
Message-ID: <4C23D64B.6050600@lcwb.coop>

The language definition says:
-------------------------------------------------------------------
An unchecked type transfer operation has the form:

     LOOPHOLE(e, T)

where e is an expression whose type is not an open array type and
T is a type.  It denotes e's bit pattern interpreted as a
variable or value of type T.  It is a designator if e is, and is
writable if e is.  An unchecked runtime error can occur if e's
bit pattern is not a legal T, or if e is a designator and some
legal bit pattern for T is not legal for e.

If T is not an open array type, BITSIZE(e) must equal
BITSIZE(T).  If T is an open array type, its element type must
not be an open array type, and e's bit pattern is interpreted as an
array whose length is BITSIZE(e) divided by BITSIZE(the element
type of T).  The division must come out even.
-------------------------------------------------------------------

Is there any reason not to allow e to have an open array type
*if* T is an open array type?  Element size of T would have to
evenly divide element size of e, to avoid runtime checks.

Other rules being the same, this would allow, e.g.:

PROCEDURE FromCtypes_chars (F: ARRAY OF Ctypes.char): TEXT

= BEGIN
     RETURN Text.FromChars(LOOPHOLE(F, ARRAY OF CHAR))
   END FromCtypes_chars

It would take a bit more implementation to handle the RT size of
e, but there is already the capability to produce a result value
of open array type.  The only difference would be the element
count would be element count of e times a constant instead of
just a constant.


From rodney_bates at lcwb.coop  Fri Jun 25 00:25:02 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Thu, 24 Jun 2010 17:25:02 -0500
Subject: [M3devel] -new_adr the default?
In-Reply-To: <COL101-W54C167232C5F9B2A6C4963E6C50@phx.gbl>
References: <COL101-W54C167232C5F9B2A6C4963E6C50@phx.gbl>
Message-ID: <4C23DB3E.7010603@lcwb.coop>



Jay K wrote:
> I'd like to make -new_adr the default.
> It is more typesafe than the current way and finds bugs.
>   Granted, so far I think only bugs that I introduced.
> 
> 
> First I will make the tree compile either way.
>  Such as by fixing the bugs and resolving somehow the char vs. CHAR breaks.
> 
> 
> Changing this does break code, albeit only unsafe code.
>   There isn't much of that? Right? :)
> Sometimes that code had bugs, sometimes not.
> 
> 
> I believe type safety and static checking (and sometimes runtime checking) do have a place in unsafe code.
>  Maybe not as much as in safe code, but definitely still something.
> 
> 
> The old way is that ADR return ADDRESS, similar to void*, and it is silently convertable to any pointer type. I think.
                                                                 ^
Yes, but only in UNSAFE code.  OtherPointerType <: ADDRESS.
> 
> 
> The new way is that ADR(T) returns UNTRACED REF T is is only silently convertable to ADDRESS? 
                                                        ^
Yes, even in safe code, because of the same subtype relation.

Or nothing at all?
>  Esp. not silently convertable to UNTRACED REF U.
Yes, this would require an explicit LOOPHOLE.  Or, you could convert in two steps,
to a variable of ADDRESS first, then to UNTRACED REF U.  Both require UNSAFE.

> 
> 
> So there are buggy places that do:
> PROCEDURE Foo(UNTRACED REF T);
> 
> PROCEDURE Bar()
> VAR u: U;

Not sure what this is doing, but it seems like just changing to VAR u: T; ought
to work too.  It would compile with either semantics of ADR.

> BEGIN
>  Foo(ADR(u));
> END Bar;
> 
> 
> That compile with old ADR but not with new ADR.
> As I changed socklent_t between int and INTEGER, such code silently kept compiling.
>   But possibly silently corrupting the stack or producing the wrong data.
> 
> 
> This -new_adr feature was already implemented in the compiler unknown long ago.
>   I didn't know but Tony pointed it out.
> We should probably look at its impementation make sure we aren't switching on some buggy unused code.
> So far switching it on I've only seen correct new errors.
> 
> 
>  - Jay
>  		 	   		  


From jay.krell at cornell.edu  Fri Jun 25 11:48:48 2010
From: jay.krell at cornell.edu (Jay K)
Date: Fri, 25 Jun 2010 09:48:48 +0000
Subject: [M3devel] gcc 4.5 static chain
Message-ID: <COL101-W4975CA91E3B1ED2707FA48E6C70@phx.gbl>


Here's some background as to why it is taking me so long to
get gcc 4.5 working.


Two of gcc's internal data structures are "tree" and "gimple".


"tree" is a somewhat intuitive structure that roughly
corresponds to a C AST ("abstract syntax tree").
It has stuff like plus, and call.
I believe it is meant to support any gcc frontend: Ada, Java, etc.


"tree" is produced by the C frontend and our "parse.c"
?(The Modula-3 gcc backend is structured as a gcc frontend,
?producing similar in-memory data as the C frontend. "backend"
?and "frontend" get confused.)


I believe "tree" has been there "forever", for as long
as DEC SRC Modula-3 has had a gcc backend.
(2.x presumably)


"gimple" is very much like tree, but it is less general.
it is more amenable to optimization.
Things like loops are deconstructed into goto.
I think.


"gimple" is newer, like dating to gcc 4.x.
Previously optimization operated on tree and/or rtx and neither was great.
rtx is too low level. tree is too high level.


Gimple I think was originally just exactly tree but with
some of the node types not used. Confusing. Faster to write it,
reused the tree code, but confusing. Gives "tree" multiple meanings.
In 4.4 or 4.5 they made it its own type.
I think, for one thing, it now is made up of nodes with small arrays
instead of nodes with node pointers.



Or something like this.
I'm mostly just repeating what you can read online elsewhere from
?more authoritative and clearer sources.
?

So, at some point, "tree" is converted to "gimple".
? Though, this is a very confusing point to me.
? It appears that really the compiler deals with a significant
? mix of "tree" and "gimple". Perhaps that is inevitable. Perhaps
? tree can only be gradually converted to gimple.
? 

Anyway, among the "tree codes" such as plus, call, etc., we add one.
We add to load a static link.
For the current function?
For a specific function to be called?
I find this point not obvious.


So then, given that we have introduced a tree code, we must teach
other parts of gcc about it.


Tangent.


tree-nested.c converts nested functions into non-nested functions.
As needed, it moves locals into structs, adds "display" parameters
to nested functions, changes references to outer locals into
accesses through the "display", etc.


Again, this is a transformation we probably could/should make ourselves in m3front.


Only the locals that are actually accessed are moved into a local struct.
Presumably only nested functions that reference outer locals get the extra parameter.
And so on.


In gcc-4.3/tree-nested.c we deal with our tree code.
We appear to do two things:
?
?- we ensure that the function we are getting a static link for has one
??? I don't understand that actually. gcc is already doing similar.
??? Why do we need to do more? 
? 
? - it replaces the load of the static link with, uh, the load of the
??? static link -- it replaces the tree node with our custom tree code
??? with the tree node representing actually computing/getting the value we want
??? It is a little fishy to me btw how this is done.
??? Is overwriting *tp really the way?
??? In 4.5 there are functions to insert/after/replace within the gimple
??? iterator. I wonder if there is similar in 4.3.


Now, the difference in 4.5 is that "gimplification" happens earlier.
The code in 4.3 that we change to deal with tree and our custom tree code,
is now dealing with gimple instead.


Therefore, I believe part of the 4.5 change is a simple translation
of the tree code to a new gimple code.


And then some corresponding change in 4.5.


Btw, it appears gimplify_expr is also a "lang hook", which means
more of our code can move out of line to parse.c.


I haven't figured it all out yet.


I should further note that gcc's notion of a nested function is almost
identical to Modula-3's.


You know, this movement of locals into a local struct, the accepting
an extra parameter pointing to that struct in nested functions, gcc
and Modula-3 are the same.


Therefore tree-nested.c does a lot of work and it is almost all useful/relevant
to us.


The difference is only what happens when you take the address of a nested function.
Or perhaps when you call them.


gcc generates a little bit of code at runtime to add the static link parameter
?(e.g. on x86/AMD64 to load into a designated register: r10 for AMD64, ecx for x86,
?see the function ix86_static_chain).
Modula-3 generates a little bit of data: marker, function pointer, static chain,
and the caller does extra work.


There are significant tradeoffs either way and there is, I'm convinced,
absolutely no good way to do this.
gcc generates code at runtime, generally on the stack.
? These days the stack is not by default executable, in order to
? protect against viruses etc. overflowing buffers on the stack
? and writing code to the stack.
Modula-3 has to check function pointers before calling them.


As I said, neither is good, there's no good solution.
? Better perhaps to do the transform yourself. Then you have
? the option of putting the context on the stack or heap as well.
? Better perhaps to expose programmer to the cost. Perhaps.


Perhaps the C ABIs could have reserved a register for this, but I'm not sure
that makes sense. Would you load it up and it remains preserved until changed?


But I digressed.


?- Jay 		 	   		  

From ttmrichter at gmail.com  Fri Jun 25 17:07:21 2010
From: ttmrichter at gmail.com (Michael Richter)
Date: Fri, 25 Jun 2010 23:07:21 +0800
Subject: [M3devel] gcc vs. clang as back-end
Message-ID: <AANLkTik63tUQqujL3yUi5MH8rOApxcqj8hMl5LuXTpqu@mail.gmail.com>

I've just read Jay K's long message about problems integrating with gcc 4.5.
 The LLVM project has clang out now which is ready for prime time as a C or
Objective-C compiler (not yet there for C++, but that's out of scope for CM3
I'd guess).  Since clang was specifically designed, as one of its goals, to
be easy to use as a form of library, would it not perhaps be better to start
using clang as a back-end instead of any version of gcc (which is
notoriously difficult to write front-ends, back-ends or tools for)?

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

From hosking at cs.purdue.edu  Fri Jun 25 17:46:39 2010
From: hosking at cs.purdue.edu (Tony Hosking)
Date: Fri, 25 Jun 2010 11:46:39 -0400
Subject: [M3devel] gcc vs. clang as back-end
In-Reply-To: <AANLkTik63tUQqujL3yUi5MH8rOApxcqj8hMl5LuXTpqu@mail.gmail.com>
References: <AANLkTik63tUQqujL3yUi5MH8rOApxcqj8hMl5LuXTpqu@mail.gmail.com>
Message-ID: <FDE20D78-F7CA-40B3-B2D4-66A0AA8CF274@cs.purdue.edu>

Hi Michael,

CM3 has a front-end compiler written in Modula-3 that targets an M3-specific IR.  Currently, that M3 IR is parsed and compiled by a simple front-end to gcc to generate assembler.  It's not clear that Clang itself is the way to go.  Rather, I think it would be better to build a translator from M3 IR to LLVM IR.

It would be much more effort to build a whole new M3 front-end around Clang.  Or do I misunderstand your suggestion?

-- Tony

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 25 Jun 2010, at 11:07, Michael Richter wrote:

> I've just read Jay K's long message about problems integrating with gcc 4.5.  The LLVM project has clang out now which is ready for prime time as a C or Objective-C compiler (not yet there for C++, but that's out of scope for CM3 I'd guess).  Since clang was specifically designed, as one of its goals, to be easy to use as a form of library, would it not perhaps be better to start using clang as a back-end instead of any version of gcc (which is notoriously difficult to write front-ends, back-ends or tools for)?
> 
> -- 
> "Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot."
> --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra.

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

From jay.krell at cornell.edu  Sat Jun 26 03:53:45 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 26 Jun 2010 01:53:45 +0000
Subject: [M3devel] gcc vs. clang as back-end
In-Reply-To: <FDE20D78-F7CA-40B3-B2D4-66A0AA8CF274@cs.purdue.edu>
References: <AANLkTik63tUQqujL3yUi5MH8rOApxcqj8hMl5LuXTpqu@mail.gmail.com>,
	<FDE20D78-F7CA-40B3-B2D4-66A0AA8CF274@cs.purdue.edu>
Message-ID: <COL101-W22F8C5289770196CD70115E6C80@phx.gbl>


gcc probably isn't as bad as people say.
?Most people are talking about C or C++ compilation, which is architecturally very problematic due the lack of a well designed module system. The same content gets parsed countless times.

? Any speed up you can make, apparently clang has made a few, will be multiplied by a very large amount.


clang doesn't make sense, for a Modula-3 backend.
LLVM does.
Anyone, yes, please feel free to contribute an LLVM backend.


I'll keep poking at the static chain stuff for now.


Thanks,
?- Jay

________________________________
> From: hosking at cs.purdue.edu
> Date: Fri, 25 Jun 2010 11:46:39 -0400
> To: ttmrichter at gmail.com
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] gcc vs. clang as back-end
>
>
>
> Hi Michael,
>
> CM3 has a front-end compiler written in Modula-3 that targets an M3-specific IR. Currently, that M3 IR is parsed and compiled by a simple front-end to gcc to generate assembler. It's not clear that Clang itself is the way to go. Rather, I think it would be better to build a translator from M3 IR to LLVM IR.
>
> It would be much more effort to build a whole new M3 front-end around Clang. Or do I misunderstand your suggestion?
>
> -- Tony
>
>
>
> 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 25 Jun 2010, at 11:07, Michael Richter wrote:
>
> I've just read Jay K's long message about problems integrating with gcc 4.5. The LLVM project has clang out now which is ready for prime time as a C or Objective-C compiler (not yet there for C++, but that's out of scope for CM3 I'd guess). Since clang was specifically designed, as one of its goals, to be easy to use as a form of library, would it not perhaps be better to start using clang as a back-end instead of any version of gcc (which is notoriously difficult to write front-ends, back-ends or tools for)?
>
>
> --
> "Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot."
>
>
> --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra.
>
>
 		 	   		  

From jay.krell at cornell.edu  Sat Jun 26 14:51:47 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sat, 26 Jun 2010 12:51:47 +0000
Subject: [M3devel] gcc 4.5 and how to pass the static link
Message-ID: <COL101-W17562D51BBB958218397FFE6C80@phx.gbl>


ok, I got "man vs. boy" to work.


Now I'm going back and revisiting some diffs I have, try to reduce them.
There isn't much.


I'm going to commit something that will seem odd,
and isn't easy to explain, and that I might not fully understand.


Here is what I suspect though.


In gcc 4.3, how to pass a static chain is always the same for each architecture.
?I think.
?
?
In 4.5, it depends on the function being called. At least for some architectures.
See the function ix86_static_chain.
x86 functions can have varying calling conventions, so how to pass
the static chain can vary from function to function.


This doesn't make complete sense for Modula-3 though.
We pass the static chain for function pointers as well.
?And gcc never does, because function pointers are "flattened" via "trampolines".
?That is, the caller of a function pointer doesn't have to pass a static link.
?A trampoline is built to pass it.
?Err. It does make partial sense. Function pointers still have calling conventions.


calls.c:prepare_call_address:
? if (static_chain_value != 0)
??? {
????? rtx chain;

????? gcc_assert (fndecl);
????? chain = targetm.calls.static_chain (fndecl, false);
????? static_chain_value = convert_memory_address (Pmode, static_chain_value);

????? emit_move_insn (chain, static_chain_value);
????? if (REG_P (chain))
??? use_reg (call_fusage, chain);
??? }


the assertion fails here:

m3-sys/m3link:

PROCEDURE ForEachUnit (VAR s: State;? p: UnitProc) =
? VAR x: MxMap.Contents;? u: Mx.Unit;
? BEGIN
??? x := MxMap.GetData (s.base.interfaces);
??? FOR i := 0 TO LAST (x^) DO
????? u := x[i].value;
????? IF (u # NIL) THEN p (s, u) END;??? *** here ***
??? END;
??? x := MxMap.GetData (s.base.modules);
??? FOR i := 0 TO LAST (x^) DO
????? u := x[i].value;
????? IF (u # NIL) THEN p (s, u) END;
??? END;
??? x := MxMap.GetData (s.base.virtuals);
??? FOR i := 0 TO LAST (x^) DO
????? u := x[i].value;
????? IF (u # NIL) THEN p (s, u) END;
??? END;
? END ForEachUnit;
? 
? 
So I'm going to quite alter that code to allow null and in such case
use the register 4.3 would have (ECX).


Arguably even for non-null we should do that.
We only support __cdecl and __stdcall, and ECX is correct for either.
gcc supports __fastcall and it appears possibly custom calling conventions.


?- Jay
 		 	   		  

From rcolebur at SCIRES.COM  Sat Jun 26 18:00:57 2010
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Sat, 26 Jun 2010 12:00:57 -0400
Subject: [M3devel] syntax errs in hand.c
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E605DBF557@ATLEX02-SRV.SCIRES.LOCAL>

Jay:

I'm getting compile errors in hand.c on Windows from the HEAD branch.

Regards,
Randy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100626/e067ca9f/attachment-0002.html>

From jay.krell at cornell.edu  Sun Jun 27 03:05:37 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 27 Jun 2010 01:05:37 +0000
Subject: [M3devel] syntax errs in hand.c
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E605DBF557@ATLEX02-SRV.SCIRES.LOCAL>
References: <D67F02DDC62F7545A6B84C285F88F3E605DBF557@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <COL101-W368E851606052D84250E89E6C90@phx.gbl>


Randy, can you please fix them?

Thanks,
?- Jay

________________________________
> From: rcolebur at SCIRES.COM
> To: m3devel at elegosoft.com
> Date: Sat, 26 Jun 2010 12:00:57 -0400
> Subject: [M3devel] syntax errs in hand.c
>
> Jay:
>
> I?m getting compile errors in hand.c on Windows from
> the HEAD branch.
>
> Regards,
>> Randy
 		 	   		  

From jay.krell at cornell.edu  Sun Jun 27 10:12:54 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 27 Jun 2010 08:12:54 +0000
Subject: [M3devel] m3cg 4.5 problem
Message-ID: <COL101-W728051433DA06972261F1E6C90@phx.gbl>


This tiny bit of code, which is cut down from m3front, causes an assertion failure in a 4.5 m3cg:
MODULE TypeCaseStmt;
IMPORT M3ID, CG, Expr, Stmt, StmtRep, Type, Variable, Scope;
PROCEDURE GetOutcomex (): Stmt.Outcomes =  VAR oc := Stmt.Outcomes {};  line 6  BEGIN    RETURN oc;  END GetOutcomex;
BEGINEND TypeCaseStmt.
../src/stmts/TypeCaseStmt.m3:6:0: internal compiler error: in gimplify_expr, at gimplify.c:7315Please submit a full bug report,

(1) begin_unit(2) set_source_file(3) set_source_line  source line    1(4) comment  comment: `module global constants'(5) declare_segment  segment L_1 typeid 0xffffffff(6) comment  comment: `module global data'(7) declare_segment  segment MM_TypeCaseStmt typeid 0xffffffff(8) set_source_line  source line   11(9) declare_procedure  type:addr  procedure:TypeCaseStmt_M3 nparams:0x1 rettype:addr lev:0 exported:1(10) declare_param  type:int64  param M3_AcxOUs_mode type:int64 typeid:0x195c2a74 bytesize:0x40 alignment:0x40 in_memory:0x0 up_level:0x0  mode 0x11 (DImode)(11) import_procedure  type:addr  procedure:TypeCaseStmt_I3 nparams:0x0 rettype:addr(12) export_unit(13) import_procedure  type:addr  procedure:Scope_I3 nparams:0x0 rettype:addr(14) import_unit(15) import_procedure  type:addr  procedure:Variable_I3 nparams:0x0 rettype:addr(16) import_unit(17) import_procedure  type:addr  procedure:Type_I3 nparams:0x0 rettype:addr(18) import_unit(19) import_procedure  type:addr  procedure:StmtRep_I3 nparams:0x0 rettype:addr(20) import_unit(21) import_procedure  type:addr  procedure:Stmt_I3 nparams:0x0 rettype:addr(22) import_unit(23) import_procedure  type:addr  procedure:Expr_I3 nparams:0x0 rettype:addr(24) import_unit(25) import_procedure  type:addr  procedure:CG_I3 nparams:0x0 rettype:addr(26) import_unit(27) import_procedure  type:addr  procedure:M3ID_I3 nparams:0x0 rettype:addr(28) import_unit(29) import_procedure  type:addr  procedure:RTHooks_I3 nparams:0x0 rettype:addr(30) import_unit(31) declare_procedure  type:word64  procedure:TypeCaseStmt__GetOutcomex nparams:0x0 rettype:word64 lev:0 exported:0(32) declare_local  type:word64  local var M3_EXQtd6_oc type:word64 size:0x40 alignment:0x40(33) declare_local  type:word64  local var M3_EXQtd6__result type:word64 size:0x40 alignment:0x40(34) comment  comment: `GetOutcomex'(35) set_source_line  source line    5(36) begin_procedure  procedure TypeCaseStmt__GetOutcomex TypeCaseStmt__GetOutcomex(37) set_source_line  source line    6(38) load_integer  type:int64  integer:0x0(39) store  type:int64  type:int64  store (M3_EXQtd6_oc) offset:0x0 src_t:int64 dst_t:int64(40) set_source_line  source line    8(41) load  type:word64  type:int64  m3cg_load (M3_EXQtd6_oc): offset 0x0, convert word64 -> int64(42) exit_proc  type:word64(43) end_procedure  procedure TypeCaseStmt__GetOutcomex

Breakpoint 1, fancy_abort (file=0x1009f0c6f "../../gcc-4.5/gcc/gimplify.c", line=7315, function=0x1009f1242 "gimplify_expr") at ../../gcc-4.5/gcc/diagnostic.c:763763	  internal_error ("in %s, at %s:%d", function, trim_filename (file), line);(gdb) bt#0  fancy_abort (file=0x1009f0c6f "../../gcc-4.5/gcc/gimplify.c", line=7315, function=0x1009f1242 "gimplify_expr") at ../../gcc-4.5/gcc/diagnostic.c:763#1  0x00000001004cc4d6 in gimplify_expr (expr_p=0x1410e2060, pre_p=0x7fff5fbff420, post_p=0x7fff5fbfeff8, gimple_test_f=0x1004aac7f <is_gimple_lvalue>, fallback=2) at ../../gcc-4.5/gcc/gimplify.c:7315#2  0x00000001004c5ad3 in gimplify_modify_expr (expr_p=0x1416a5f28, pre_p=0x7fff5fbff420, post_p=0x7fff5fbfeff8, want_value=0 '\0') at ../../gcc-4.5/gcc/gimplify.c:4444#3  0x00000001004caafc in gimplify_expr (expr_p=0x1416a5f28, pre_p=0x7fff5fbff420, post_p=0x7fff5fbfeff8, gimple_test_f=0x1004ab1a6 <is_gimple_stmt>, fallback=0) at ../../gcc-4.5/gcc/gimplify.c:6619#4  0x00000001004c7800 in gimplify_stmt (stmt_p=0x1416a5f28, seq_p=0x7fff5fbff420) at ../../gcc-4.5/gcc/gimplify.c:5264#5  0x00000001004be376 in gimplify_statement_list (expr_p=0x1416c4030, pre_p=0x7fff5fbff420) at ../../gcc-4.5/gcc/gimplify.c:1382#6  0x00000001004cb6f5 in gimplify_expr (expr_p=0x1416c4030, pre_p=0x7fff5fbff420, post_p=0x7fff5fbff2e8, gimple_test_f=0x1004ab1a6 <is_gimple_stmt>, fallback=0) at ../../gcc-4.5/gcc/gimplify.c:6935#7  0x00000001004c7800 in gimplify_stmt (stmt_p=0x1416c4030, seq_p=0x7fff5fbff420) at ../../gcc-4.5/gcc/gimplify.c:5264#8  0x00000001004bdb6c in gimplify_bind_expr (expr_p=0x1416c2298, pre_p=0x7fff5fbff778) at ../../gcc-4.5/gcc/gimplify.c:1127#9  0x00000001004cae2b in gimplify_expr (expr_p=0x1416c2298, pre_p=0x7fff5fbff778, post_p=0x7fff5fbff618, gimple_test_f=0x1004ab1a6 <is_gimple_stmt>, fallback=0) at ../../gcc-4.5/gcc/gimplify.c:6719#10 0x00000001004c7800 in gimplify_stmt (stmt_p=0x1416c2298, seq_p=0x7fff5fbff778) at ../../gcc-4.5/gcc/gimplify.c:5264#11 0x00000001004ccbe6 in gimplify_body (body_p=0x1416c2298, fndecl=0x1416c2200, do_parms=1 '\001') at ../../gcc-4.5/gcc/gimplify.c:7528#12 0x00000001004cceae in gimplify_function_tree (fndecl=0x1416c2200) at ../../gcc-4.5/gcc/gimplify.c:7624#13 0x00000001000069c7 in m3_gimplify_function (fndecl=0x1416c2200) at ../../gcc-4.5/gcc/m3cg/parse.c:2370#14 0x0000000100009cb4 in m3cg_end_procedure () at ../../gcc-4.5/gcc/m3cg/parse.c:3642#15 0x000000010000feb5 in m3_parse_file (xx=0) at ../../gcc-4.5/gcc/m3cg/parse.c:5550#16 0x00000001006be6a2 in compile_file () at ../../gcc-4.5/gcc/toplev.c:1053#17 0x00000001006c0e19 in do_compile () at ../../gcc-4.5/gcc/toplev.c:2415#18 0x00000001006c0ee0 in toplev_main (argc=3, argv=0x7fff5fbff930) at ../../gcc-4.5/gcc/toplev.c:2457#19 0x000000010001743b in main (argc=3, argv=0x7fff5fbff930) at ../../gcc-4.5/gcc/main.c:35(

Wierd, huh?
The only thing I can think of an int/word mismatch.I did change one instance of Integer to Word, after finding this.Stmt.Outcomes is an enumeration.So presumably Stmt.Outcomes { } is 0.Enumerations should work equally well as Integer or Word, right?Clearly above there is still a mix. I can try changing them all to Word.

I'll keep digging.

Maybe dump the entire function generic tree for this and similar C.

 - Jay 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100627/1814fee7/attachment-0002.html>

From jay.krell at cornell.edu  Sun Jun 27 11:23:13 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 27 Jun 2010 09:23:13 +0000
Subject: [M3devel] m3cg 4.5 problem
In-Reply-To: <COL101-W728051433DA06972261F1E6C90@phx.gbl>
References: <COL101-W728051433DA06972261F1E6C90@phx.gbl>
Message-ID: <COL101-W2519C65D63208BF55620CE6C90@phx.gbl>


I was a bit off. It is actually set of enum. Like this:
MODULE TypeCaseStmt;
TYPE T1 = {A,B};TYPE T2 = SET OF T1; PROCEDURE GetOutcomex (): T2 =  VAR oc := T2 {};  BEGIN    RETURN oc;  END GetOutcomex;
BEGINEND TypeCaseStmt.
 - Jay
From: jay.krell at cornell.edu
To: m3devel at elegosoft.com; hosking at cs.purdue.edu
Date: Sun, 27 Jun 2010 08:12:54 +0000
Subject: [M3devel] m3cg 4.5 problem








This tiny bit of code, which is cut down from m3front, causes an assertion failure in a 4.5 m3cg:
MODULE TypeCaseStmt;
IMPORT M3ID, CG, Expr, Stmt, StmtRep, Type, Variable, Scope;
PROCEDURE GetOutcomex (): Stmt.Outcomes =  VAR oc := Stmt.Outcomes {};  line 6  BEGIN    RETURN oc;  END GetOutcomex;
BEGINEND TypeCaseStmt.
../src/stmts/TypeCaseStmt.m3:6:0: internal compiler error: in gimplify_expr, at gimplify.c:7315Please submit a full bug report,

(1) begin_unit(2) set_source_file(3) set_source_line  source line    1(4) comment  comment: `module global constants'(5) declare_segment  segment L_1 typeid 0xffffffff(6) comment  comment: `module global data'(7) declare_segment  segment MM_TypeCaseStmt typeid 0xffffffff(8) set_source_line  source line   11(9) declare_procedure  type:addr  procedure:TypeCaseStmt_M3 nparams:0x1 rettype:addr lev:0 exported:1(10) declare_param  type:int64  param M3_AcxOUs_mode type:int64 typeid:0x195c2a74 bytesize:0x40 alignment:0x40 in_memory:0x0 up_level:0x0  mode 0x11 (DImode)(11) import_procedure  type:addr  procedure:TypeCaseStmt_I3 nparams:0x0 rettype:addr(12) export_unit(13) import_procedure  type:addr  procedure:Scope_I3 nparams:0x0 rettype:addr(14) import_unit(15) import_procedure  type:addr  procedure:Variable_I3 nparams:0x0 rettype:addr(16) import_unit(17) import_procedure  type:addr  procedure:Type_I3 nparams:0x0 rettype:addr(18) import_unit(19) import_procedure  type:addr  procedure:StmtRep_I3 nparams:0x0 rettype:addr(20) import_unit(21) import_procedure  type:addr  procedure:Stmt_I3 nparams:0x0 rettype:addr(22) import_unit(23) import_procedure  type:addr  procedure:Expr_I3 nparams:0x0 rettype:addr(24) import_unit(25) import_procedure  type:addr  procedure:CG_I3 nparams:0x0 rettype:addr(26) import_unit(27) import_procedure  type:addr  procedure:M3ID_I3 nparams:0x0 rettype:addr(28) import_unit(29) import_procedure  type:addr  procedure:RTHooks_I3 nparams:0x0 rettype:addr(30) import_unit(31) declare_procedure  type:word64  procedure:TypeCaseStmt__GetOutcomex nparams:0x0 rettype:word64 lev:0 exported:0(32) declare_local  type:word64  local var M3_EXQtd6_oc type:word64 size:0x40 alignment:0x40(33) declare_local  type:word64  local var M3_EXQtd6__result type:word64 size:0x40 alignment:0x40(34) comment  comment: `GetOutcomex'(35) set_source_line  source line    5(36) begin_procedure  procedure TypeCaseStmt__GetOutcomex TypeCaseStmt__GetOutcomex(37) set_source_line  source line    6(38) load_integer  type:int64  integer:0x0(39) store  type:int64  type:int64  store (M3_EXQtd6_oc) offset:0x0 src_t:int64 dst_t:int64(40) set_source_line  source line    8(41) load  type:word64  type:int64  m3cg_load (M3_EXQtd6_oc): offset 0x0, convert word64 -> int64(42) exit_proc  type:word64(43) end_procedure  procedure TypeCaseStmt__GetOutcomex

Breakpoint 1, fancy_abort (file=0x1009f0c6f "../../gcc-4.5/gcc/gimplify.c", line=7315, function=0x1009f1242 "gimplify_expr") at ../../gcc-4.5/gcc/diagnostic.c:763763	  internal_error ("in %s, at %s:%d", function, trim_filename (file), line);(gdb) bt#0  fancy_abort (file=0x1009f0c6f "../../gcc-4.5/gcc/gimplify.c", line=7315, function=0x1009f1242 "gimplify_expr") at ../../gcc-4.5/gcc/diagnostic.c:763#1  0x00000001004cc4d6 in gimplify_expr (expr_p=0x1410e2060, pre_p=0x7fff5fbff420, post_p=0x7fff5fbfeff8, gimple_test_f=0x1004aac7f <is_gimple_lvalue>, fallback=2) at ../../gcc-4.5/gcc/gimplify.c:7315#2  0x00000001004c5ad3 in gimplify_modify_expr (expr_p=0x1416a5f28, pre_p=0x7fff5fbff420, post_p=0x7fff5fbfeff8, want_value=0 '\0') at ../../gcc-4.5/gcc/gimplify.c:4444#3  0x00000001004caafc in gimplify_expr (expr_p=0x1416a5f28, pre_p=0x7fff5fbff420, post_p=0x7fff5fbfeff8, gimple_test_f=0x1004ab1a6 <is_gimple_stmt>, fallback=0) at ../../gcc-4.5/gcc/gimplify.c:6619#4  0x00000001004c7800 in gimplify_stmt (stmt_p=0x1416a5f28, seq_p=0x7fff5fbff420) at ../../gcc-4.5/gcc/gimplify.c:5264#5  0x00000001004be376 in gimplify_statement_list (expr_p=0x1416c4030, pre_p=0x7fff5fbff420) at ../../gcc-4.5/gcc/gimplify.c:1382#6  0x00000001004cb6f5 in gimplify_expr (expr_p=0x1416c4030, pre_p=0x7fff5fbff420, post_p=0x7fff5fbff2e8, gimple_test_f=0x1004ab1a6 <is_gimple_stmt>, fallback=0) at ../../gcc-4.5/gcc/gimplify.c:6935#7  0x00000001004c7800 in gimplify_stmt (stmt_p=0x1416c4030, seq_p=0x7fff5fbff420) at ../../gcc-4.5/gcc/gimplify.c:5264#8  0x00000001004bdb6c in gimplify_bind_expr (expr_p=0x1416c2298, pre_p=0x7fff5fbff778) at ../../gcc-4.5/gcc/gimplify.c:1127#9  0x00000001004cae2b in gimplify_expr (expr_p=0x1416c2298, pre_p=0x7fff5fbff778, post_p=0x7fff5fbff618, gimple_test_f=0x1004ab1a6 <is_gimple_stmt>, fallback=0) at ../../gcc-4.5/gcc/gimplify.c:6719#10 0x00000001004c7800 in gimplify_stmt (stmt_p=0x1416c2298, seq_p=0x7fff5fbff778) at ../../gcc-4.5/gcc/gimplify.c:5264#11 0x00000001004ccbe6 in gimplify_body (body_p=0x1416c2298, fndecl=0x1416c2200, do_parms=1 '\001') at ../../gcc-4.5/gcc/gimplify.c:7528#12 0x00000001004cceae in gimplify_function_tree (fndecl=0x1416c2200) at ../../gcc-4.5/gcc/gimplify.c:7624#13 0x00000001000069c7 in m3_gimplify_function (fndecl=0x1416c2200) at ../../gcc-4.5/gcc/m3cg/parse.c:2370#14 0x0000000100009cb4 in m3cg_end_procedure () at ../../gcc-4.5/gcc/m3cg/parse.c:3642#15 0x000000010000feb5 in m3_parse_file (xx=0) at ../../gcc-4.5/gcc/m3cg/parse.c:5550#16 0x00000001006be6a2 in compile_file () at ../../gcc-4.5/gcc/toplev.c:1053#17 0x00000001006c0e19 in do_compile () at ../../gcc-4.5/gcc/toplev.c:2415#18 0x00000001006c0ee0 in toplev_main (argc=3, argv=0x7fff5fbff930) at ../../gcc-4.5/gcc/toplev.c:2457#19 0x000000010001743b in main (argc=3, argv=0x7fff5fbff930) at ../../gcc-4.5/gcc/main.c:35(

Wierd, huh?
The only thing I can think of an int/word mismatch.I did change one instance of Integer to Word, after finding this.Stmt.Outcomes is an enumeration.So presumably Stmt.Outcomes { } is 0.Enumerations should work equally well as Integer or Word, right?Clearly above there is still a mix. I can try changing them all to Word.

I'll keep digging.

Maybe dump the entire function generic tree for this and similar C.

 - Jay 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100627/2ee35f81/attachment-0002.html>

From ttmrichter at gmail.com  Sun Jun 27 12:54:30 2010
From: ttmrichter at gmail.com (Michael Richter)
Date: Sun, 27 Jun 2010 18:54:30 +0800
Subject: [M3devel] cm3ide and Chrome
Message-ID: <AANLkTim77ivruVuNT21PtStijrhMlRD-bNc9VOIH669d@mail.gmail.com>

Is there a trick to making cm3ide work with Google Chrome?  The problem
seems to be that Google Chrome returns *immediately* upon invocation where
the default, Firefox, does not.  Cm3ide waits for the browser to exit to
decide that it's time to end, so what winds up happening for me when
specifying Chrome as the browser is that cm3ide starts, Chrome starts,
cm3ide starts serving up some content, Chrome's launcher returns
immediately, cm3ide dies.  The result is a partial opening page and nothing
else.

Also, when specifying the browser (any browser), it doesn't like me giving
options to the browser command line: it rejects "/usr/bin/google-chrome
--new-window" as an option when asking for the browser if I delete the
configuration file.  I have to go /usr/bin/google-chrome and then manually
edit the configuration file to include any command line switches I want to
use.

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

From jay.krell at cornell.edu  Sun Jun 27 13:07:06 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 27 Jun 2010 11:07:06 +0000
Subject: [M3devel] extra temporaries?
Message-ID: <COL101-W63DC70E1561934607F902CE6C90@phx.gbl>


Why all these extra temporaries?

static voidm3cg_max (void){  MTYPE (t);
  tree t1 = declare_temp (t);  tree t2 = declare_temp (t);
  add_stmt (m3_build2 (MODIFY_EXPR, t, t1, EXPR_REF (-1)));  add_stmt (m3_build2 (MODIFY_EXPR, t, t2, EXPR_REF (-2)));
  EXPR_REF (-2) = m3_build3 (COND_EXPR, t,                             m3_build2 (LE_EXPR, boolean_type_node, t2, t1),                             t1, t2);  EXPR_POP ();}

static voidm3cg_min (void){  MTYPE (t);
  tree t1 = declare_temp (t);  tree t2 = declare_temp (t);
  add_stmt (m3_build2 (MODIFY_EXPR, t, t1, EXPR_REF (-1)));  add_stmt (m3_build2 (MODIFY_EXPR, t, t2, EXPR_REF (-2)));
  EXPR_REF (-2) = m3_build3 (COND_EXPR, t,                             m3_build2 (LE_EXPR, boolean_type_node, t1, t2),                             t1, t2);  EXPR_POP ();}


static voidm3cg_check_nil (void){  INTEGER (code);
  tree temp1 = declare_temp (t_addr);
  m3_store (temp1, 0, t_addr, T_addr, t_addr, T_addr);  EXPR_PUSH (temp1);  add_stmt (build3 (COND_EXPR, t_void,                    m3_build2 (EQ_EXPR, boolean_type_node, temp1, v_null),                    generate_fault (code),                    NULL_TREE));}


static voidm3cg_check_lo (void){  MTYPE2         (t, T);  TARGET_INTEGER (a);  INTEGER        (code);
  tree temp1 = declare_temp (t);
  a = convert (t, a);
  if (option_exprs_trace)    fprintf (stderr, "  check low type:%s code:0x%lx\n", m3cg_typename(T), code);
  if (TREE_TYPE (EXPR_REF (-1)) != t)    EXPR_REF (-1) = m3_build1 (CONVERT_EXPR, t, EXPR_REF (-1));
  m3_store (temp1, 0, t, T, t, T);  EXPR_PUSH (temp1);  add_stmt (build3 (COND_EXPR, t_void,                    m3_build2 (LT_EXPR, boolean_type_node, temp1, a),                    generate_fault (code),                    NULL_TREE));}

static voidm3cg_check_hi (void){  MTYPE2         (t, T);  TARGET_INTEGER (a);  INTEGER        (code);
  tree temp1 = declare_temp (t);
  a = convert (t, a);
  if (option_exprs_trace)    fprintf (stderr, "  check high type:%s code:0x%lx\n", m3cg_typename(T), code);
  if (TREE_TYPE (EXPR_REF (-1)) != t)    EXPR_REF (-1) = m3_build1 (CONVERT_EXPR, t, EXPR_REF (-1));
  m3_store (temp1, 0, t, T, t, T);  EXPR_PUSH (temp1);  add_stmt (build3 (COND_EXPR, t_void,                    m3_build2 (GT_EXPR, boolean_type_node, temp1, a),                    generate_fault (code),                    NULL_TREE));}

static voidm3cg_check_range (void){  MTYPE2         (t, T);  TARGET_INTEGER (a);  TARGET_INTEGER (b);  INTEGER        (code);
  tree temp1 = declare_temp (t);
  a = convert (t, a);  b = convert (t, b);
  if (option_exprs_trace)    fprintf (stderr, "  check range type:%s code:0x%lx\n", m3cg_typename(T), code);
  if (TREE_TYPE (EXPR_REF (-1)) != t)    EXPR_REF (-1) = m3_build1 (CONVERT_EXPR, t, EXPR_REF (-1));
  m3_store (temp1, 0, t, T, t, T);  EXPR_PUSH (temp1);  add_stmt (build3 (COND_EXPR, t_void,                    m3_build2 (TRUTH_ORIF_EXPR, boolean_type_node,                               m3_build2 (LT_EXPR,                                          boolean_type_node, temp1, a),                               m3_build2 (GT_EXPR,                                          boolean_type_node, temp1, b)),                    generate_fault (code),                    NULL_TREE));}

static voidm3cg_check_eq (void){  MTYPE2  (t, T);  INTEGER (code);
  tree temp1 = declare_temp (t);  tree temp2 = declare_temp (t);
  m3_store (temp1, 0, t, T, t, T);  m3_store (temp2, 0, t, T, t, T);  add_stmt (build3 (COND_EXPR, t_void,                    m3_build2 (NE_EXPR, boolean_type_node, temp1, temp2),                    generate_fault (code),                    NULL_TREE));}

seem kind of wasteful.

 - Jay

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

From jay.krell at cornell.edu  Sun Jun 27 13:15:13 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 27 Jun 2010 11:15:13 +0000
Subject: [M3devel] cm3ide and Chrome
In-Reply-To: <AANLkTim77ivruVuNT21PtStijrhMlRD-bNc9VOIH669d@mail.gmail.com>
References: <AANLkTim77ivruVuNT21PtStijrhMlRD-bNc9VOIH669d@mail.gmail.com>
Message-ID: <COL101-W43C485848DE91DF690DFF3E6C90@phx.gbl>


Similar? stuff has been discussed. Like, Internet Explorer returning or continuing to run depends on if there is already an instance."start /wait" prefixed to the command line might help.
"When specifying the browser.." you mean cminstall?  You might try manually editing c:\cm3\bin\cm3.cfg or c:\cm3\bin\config\NT386* after running it.  cminstall is just making small edits to them.
 - Jay

Date: Sun, 27 Jun 2010 18:54:30 +0800
From: ttmrichter at gmail.com
To: m3devel at elegosoft.com
Subject: [M3devel] cm3ide and Chrome

Is there a trick to making cm3ide work with Google Chrome?  The problem seems to be that Google Chrome returns immediately upon invocation where the default, Firefox, does not.  Cm3ide waits for the browser to exit to decide that it's time to end, so what winds up happening for me when specifying Chrome as the browser is that cm3ide starts, Chrome starts, cm3ide starts serving up some content, Chrome's launcher returns immediately, cm3ide dies.  The result is a partial opening page and nothing else.

Also, when specifying the browser (any browser), it doesn't like me giving options to the browser command line: it rejects "/usr/bin/google-chrome --new-window" as an option when asking for the browser if I delete the configuration file.  I have to go /usr/bin/google-chrome and then manually edit the configuration file to include any command line switches I want to use.

-- 
"Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot."

--Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra.

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

From rcolebur at SCIRES.COM  Sun Jun 27 13:25:55 2010
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Sun, 27 Jun 2010 07:25:55 -0400
Subject: [M3devel] cm3ide and Chrome
In-Reply-To: <AANLkTim77ivruVuNT21PtStijrhMlRD-bNc9VOIH669d@mail.gmail.com>
References: <AANLkTim77ivruVuNT21PtStijrhMlRD-bNc9VOIH669d@mail.gmail.com>
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E605DBF572@ATLEX02-SRV.SCIRES.LOCAL>

Michael:

You can edit the cm3ide configuration file to change the behavior.  This file is usually located in ..\Documents\CM3_IDE_Home\CM3_IDE.cfg0 or CM3_IDE.cfg1

Find the ?start_browser? proc.  Change the return value to be FALSE.

FALSE means CM3_IDE should stay running when the browser terminates, whereas TRUE causes it to terminate when the browser terminates.

If you want to give command line options to the browser, you can specify them in the start_browser proc as well.

Regards,
Randy Coleburn

From: Michael Richter [mailto:ttmrichter at gmail.com]
Sent: Sunday, June 27, 2010 6:55 AM
To: m3devel
Subject: [M3devel] cm3ide and Chrome

Is there a trick to making cm3ide work with Google Chrome?  The problem seems to be that Google Chrome returns immediately upon invocation where the default, Firefox, does not.  Cm3ide waits for the browser to exit to decide that it's time to end, so what winds up happening for me when specifying Chrome as the browser is that cm3ide starts, Chrome starts, cm3ide starts serving up some content, Chrome's launcher returns immediately, cm3ide dies.  The result is a partial opening page and nothing else.

Also, when specifying the browser (any browser), it doesn't like me giving options to the browser command line: it rejects "/usr/bin/google-chrome --new-window" as an option when asking for the browser if I delete the configuration file.  I have to go /usr/bin/google-chrome and then manually edit the configuration file to include any command line switches I want to use.

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

From rcolebur at SCIRES.COM  Sun Jun 27 13:27:41 2010
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Sun, 27 Jun 2010 07:27:41 -0400
Subject: [M3devel] cm3ide and Chrome
In-Reply-To: <COL101-W43C485848DE91DF690DFF3E6C90@phx.gbl>
References: <AANLkTim77ivruVuNT21PtStijrhMlRD-bNc9VOIH669d@mail.gmail.com>
	<COL101-W43C485848DE91DF690DFF3E6C90@phx.gbl>
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E605DBF573@ATLEX02-SRV.SCIRES.LOCAL>

See my prior post instead.
--Randy

From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K
Sent: Sunday, June 27, 2010 7:15 AM
To: ttmrichter at gmail.com; m3devel
Subject: Re: [M3devel] cm3ide and Chrome

Similar? stuff has been discussed.
 Like, Internet Explorer returning or continuing to run depends on if there is already an instance.
"start /wait" prefixed to the command line might help.

"When specifying the browser.." you mean cminstall?
  You might try manually editing c:\cm3\bin\cm3.cfg or c:\cm3\bin\config\NT386* after running it.
  cminstall is just making small edits to them.

 - Jay

________________________________
Date: Sun, 27 Jun 2010 18:54:30 +0800
From: ttmrichter at gmail.com
To: m3devel at elegosoft.com
Subject: [M3devel] cm3ide and Chrome

Is there a trick to making cm3ide work with Google Chrome?  The problem seems to be that Google Chrome returns immediately upon invocation where the default, Firefox, does not.  Cm3ide waits for the browser to exit to decide that it's time to end, so what winds up happening for me when specifying Chrome as the browser is that cm3ide starts, Chrome starts, cm3ide starts serving up some content, Chrome's launcher returns immediately, cm3ide dies.  The result is a partial opening page and nothing else.

Also, when specifying the browser (any browser), it doesn't like me giving options to the browser command line: it rejects "/usr/bin/google-chrome --new-window" as an option when asking for the browser if I delete the configuration file.  I have to go /usr/bin/google-chrome and then manually edit the configuration file to include any command line switches I want to use.

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

From jay.krell at cornell.edu  Sun Jun 27 14:39:45 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 27 Jun 2010 12:39:45 +0000
Subject: [M3devel] div/mod?
Message-ID: <COL101-W52D2A18F8772E0667B8746E6C90@phx.gbl>


implementing div/mod?
The historical implementation is "ok". advantages:   stable   doesn't do any div/mod of negative numbers disadvantages:   I believe it gets a few cases wrong, e.g. involving minimal inputs   relies on silent overflow of signed math     There are gcc flags that warn about this,     and I think also optimizations that break it.

"new" C implementation:  advantages:    avoids silent overflow overflow of signed numbers (no warnings from gcc)    I believe it fixes the incorrect cases in the historical implementation.  disadvantages:    one nagging part of it is how it deals with two negative    inputs; it assumes C matches Modula-3

INTEGER__stdcallm3_div(INTEGER b, INTEGER a){  int aneg = (a < 0);  int bneg = (b < 0);  if (aneg == bneg || a == 0 || b == 0)    return (a / b);...
INTEGER__stdcallm3_mod(INTEGER b, INTEGER a){  int aneg = (a < 0);  int bneg = (b < 0);  if (aneg == bneg || a == 0 || b == 0)    return (a % b);...

This makes me a bit nervous regarding the case of aneg && bneg.Generally, as was said, everyone defines div/mod the same for positive inputs,but once either (or both?) inputs are negative, there are several options.But it seems to test out ok. At least on AMD64_DARWIN. I could test more platforms.

gcc "opcodes" (tree codes, there are different ones for   trunc/round/floor/ceil div/mod)  presumably fastest option    and maybe smallest though probably not  presumably not much used  64bit path doesn't work for ARM, for a mostly understood reason,     compiler goes down path of wanting 128bit integers ("TImode"), though     I suspect it doesn't really need them, either it ends     up doing something else, or they are a way of     moving around a pair of int64

Could go back to the hybrid I had briefly: always use gcc "opcodes", except 64bit operations on ARM or could even fix 64bit on ARM?   ?

Notice that m3back has always implemented 32bit div/mod inline.  But always calls the C for 64bit.Also my confidence in gcc "opcodes" was briefly shakenby noticing it still uses the "normal" helper functions, butupon closer inspection, it does "wrap" them in various formsof rounding, depending on the exact operation requested.
 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100627/22b0ff30/attachment-0002.html>

From ttmrichter at gmail.com  Sun Jun 27 14:47:12 2010
From: ttmrichter at gmail.com (Michael Richter)
Date: Sun, 27 Jun 2010 20:47:12 +0800
Subject: [M3devel] cm3ide and Chrome
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E605DBF572@ATLEX02-SRV.SCIRES.LOCAL>
References: <AANLkTim77ivruVuNT21PtStijrhMlRD-bNc9VOIH669d@mail.gmail.com>
	<D67F02DDC62F7545A6B84C285F88F3E605DBF572@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <AANLkTilNwMZJUnptlIJXPhbc7TJxw5PL4T0IotuE0VHD@mail.gmail.com>

On 27 June 2010 19:25, Coleburn, Randy <rcolebur at scires.com> wrote:

>  You can edit the cm3ide configuration file to change the behavior.  This
> file is usually located in ..\Documents\CM3_IDE_Home\*CM3_IDE.cfg0* or *
> CM3_IDE.cfg1*
>
> Find the ?*start_browser*? proc.  Change the return value to be *FALSE*.
>
I found the .cfg* file but I didn't catch that TRUE/FALSE return value
thing.  That makes a huge difference!  Thanks a lot.

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

From jay.krell at cornell.edu  Sun Jun 27 15:44:06 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 27 Jun 2010 13:44:06 +0000
Subject: [M3devel] m3cg 4.5 problem
In-Reply-To: <COL101-W2519C65D63208BF55620CE6C90@phx.gbl>
References: <COL101-W728051433DA06972261F1E6C90@phx.gbl>,
	<COL101-W2519C65D63208BF55620CE6C90@phx.gbl>
Message-ID: <COL101-W24F2979E24DCCB1CDD09B3E6C90@phx.gbl>


I almost have this figured out.

4.5:
(gdb) break is_gimple_lvalue(gdb) runBreakpoint 2, is_gimple_lvalue (t=0x414653b8) at ../../gcc-4.5/gcc/gimple.c:24562456	  return (is_gimple_addressable (t)(gdb) call debug_tree(t) <nop_expr 0x414653b8    type <integer_type 0x41417360 int_64 public DI        size <integer_cst 0x41405340 constant 64>        unit size <integer_cst 0x41405360 constant 8>        align 64 symtab 0 alias set -1 canonical type 0x41417360 precision 64 min <integer_cst 0x414052e0 -9223372036854775808> max <integer_cst 0x41405300 9223372036854775807>>       arg 0 <var_decl 0x414680b8 M3_DxNB17_oc        type <integer_type 0x414173c0 word_64 sizes-gimplified public unsigned DI size <integer_cst 0x41405340 64> unit size <integer_cst 0x41405360 8>            align 64 symtab 0 alias set -1 canonical type 0x414173c0 precision 64 min <integer_cst 0x41405380 0> max <integer_cst 0x41405320 18446744073709551615>>        unsigned DI file ../src/stmts/TypeCaseStmt.m3 line 12 col 0 size <integer_cst 0x41405340 64> unit size <integer_cst 0x41405360 8>        align 64 context <function_decl 0x41466400 TypeCaseStmt__GetOutcomex>>>


(gdb) finishRun till exit from #0  is_gimple_lvalue (t=0x414653b8) at ../../gcc-4.5/gcc/gimple.c:24560x004ea8bc in gimplify_expr (expr_p=0x41456218, pre_p=0xbffff510, post_p=0xbffff230, gimple_test_f=0x4c9bd5 <is_gimple_lvalue>, fallback=2) at ../../gcc-4.5/gcc/gimplify.c:72627262	gimple_test_f) (*expr_p))Value returned is $13 = 0 '\0'

4.3:(gdb) break is_gimple_lvalueBreakpoint 1 at 0x5708e3: file ../../gcc/gcc/tree-gimple.c, line 147.(gdb) runStarting program: /Users/jay/dev2/cm3/m3-sys/m3cc/I386_DARWIN-I386_DARWIN-4.3/gcc/m3cgc1 -m64 TypeCaseStmt.mcReading symbols for shared libraries ++. done TypeCaseStmt__GetOutcomexBreakpoint 1, is_gimple_lvalue (t=0x41141060) at ../../gcc/gcc/tree-gimple.c:147147	  return (is_gimple_addressable (t)(gdb) call debug_tree(t) <var_decl 0x41141060 M3_DxNB17_oc    type <integer_type 0x41111460 word_64 sizes-gimplified public unsigned DI        size <integer_cst 0x40b2d6f0 constant invariant 64>        unit size <integer_cst 0x40b2d720 constant invariant 8>        align 64 symtab 0 alias set -1 canonical type 0x41111460 precision 64 min <integer_cst 0x40b2d750 0> max <integer_cst 0x40b2d6c0 18446744073709551615>>    unsigned DI file ../src/stmts/TypeCaseStmt.m3 line 12 col 0 size <integer_cst 0x40b2d6f0 64> unit size <integer_cst 0x40b2d720 8>    align 64 context <function_decl 0x4113e100 TypeCaseStmt__GetOutcomex>>(gdb) finishRun till exit from #0  is_gimple_lvalue (t=0x41141060) at ../../gcc/gcc/tree-gimple.c:1470x003d7541 in gimplify_expr (expr_p=0x4113d16c, pre_p=0xbffff350, post_p=0xbffff34c, gimple_test_f=0x5708dd <is_gimple_lvalue>, fallback=fb_either) at ../../gcc/gcc/gimplify.c:6240warning: Source file is more recent than executable.6240	  if (!internal_post && (*gimple_test_f) (*expr_p))Value returned is $1 = 1 '\001'

nop_expr is what we use for casting.We are casting int64 to word64.The result of a cast is not an lvalue.I suspect 4.3 has removed this as a "useless conversion"...
In 4.5 we have: gdb: call debug_tree(*expr_p)
        stmt <modify_expr 0x41456200 type <integer_type 0x41417360 int_64>            side-effects used            arg 0 <nop_expr 0x414653b8 type <integer_type 0x41417360 int_64>                arg 0 <var_decl 0x414680b8 M3_DxNB17_oc>>            arg 1 <integer_cst 0x414057e0 constant 0>            ../src/stmts/TypeCaseStmt.m3:7:0>

in 4.3 we have:
        stmt <modify_expr 0x4113d180 type <integer_type 0x411113f0 int_64>            side-effects used            arg 0 <bit_field_ref 0x4113d150 type <integer_type 0x411113f0 int_64>                arg 0 <var_decl 0x41141060 M3_DxNB17_oc>                arg 1 <integer_cst 0x40b2d6f0 64>                arg 2 <integer_cst 0x40b2da20 constant invariant 0>>            arg 1 <integer_cst 0x40b2dde0 constant invariant 0>            ../src/stmts/TypeCaseStmt.m3:7:0> Again, 4.5 reads: (int64)oc = 0;
4.3 reads:  (bit field ref)oc = 0;
int64 cast is not an lvalue, bit field ref is. Something like that.
Either one of the #if GCC45 I have or gcc has done a transform in the meantime..
I'll keep digging.
I don't believe we need the cast -- we should just get the type right in the first place.But fixing that isn't necessarily what I'm going to do.I have to see where 4.3 vs. 4.5 difference comes from first..

 - Jay


From: jay.krell at cornell.edu
To: m3devel at elegosoft.com; hosking at cs.purdue.edu
Date: Sun, 27 Jun 2010 09:23:13 +0000
Subject: Re: [M3devel] m3cg 4.5 problem








I was a bit off. It is actually set of enum. Like this:
MODULE TypeCaseStmt;
TYPE T1 = {A,B};TYPE T2 = SET OF T1; PROCEDURE GetOutcomex (): T2 =  VAR oc := T2 {};  BEGIN    RETURN oc;  END GetOutcomex;
BEGINEND TypeCaseStmt.
 - Jay
From: jay.krell at cornell.edu
To: m3devel at elegosoft.com; hosking at cs.purdue.edu
Date: Sun, 27 Jun 2010 08:12:54 +0000
Subject: [M3devel] m3cg 4.5 problem








This tiny bit of code, which is cut down from m3front, causes an assertion failure in a 4.5 m3cg:
MODULE TypeCaseStmt;
IMPORT M3ID, CG, Expr, Stmt, StmtRep, Type, Variable, Scope;
PROCEDURE GetOutcomex (): Stmt.Outcomes =  VAR oc := Stmt.Outcomes {};  line 6  BEGIN    RETURN oc;  END GetOutcomex;
BEGINEND TypeCaseStmt.
../src/stmts/TypeCaseStmt.m3:6:0: internal compiler error: in gimplify_expr, at gimplify.c:7315Please submit a full bug report,

(1) begin_unit(2) set_source_file(3) set_source_line  source line    1(4) comment  comment: `module global constants'(5) declare_segment  segment L_1 typeid 0xffffffff(6) comment  comment: `module global data'(7) declare_segment  segment MM_TypeCaseStmt typeid 0xffffffff(8) set_source_line  source line   11(9) declare_procedure  type:addr  procedure:TypeCaseStmt_M3 nparams:0x1 rettype:addr lev:0 exported:1(10) declare_param  type:int64  param M3_AcxOUs_mode type:int64 typeid:0x195c2a74 bytesize:0x40 alignment:0x40 in_memory:0x0 up_level:0x0  mode 0x11 (DImode)(11) import_procedure  type:addr  procedure:TypeCaseStmt_I3 nparams:0x0 rettype:addr(12) export_unit(13) import_procedure  type:addr  procedure:Scope_I3 nparams:0x0 rettype:addr(14) import_unit(15) import_procedure  type:addr  procedure:Variable_I3 nparams:0x0 rettype:addr(16) import_unit(17) import_procedure  type:addr  procedure:Type_I3 nparams:0x0 rettype:addr(18) import_unit(19) import_procedure  type:addr  procedure:StmtRep_I3 nparams:0x0 rettype:addr(20) import_unit(21) import_procedure  type:addr  procedure:Stmt_I3 nparams:0x0 rettype:addr(22) import_unit(23) import_procedure  type:addr  procedure:Expr_I3 nparams:0x0 rettype:addr(24) import_unit(25) import_procedure  type:addr  procedure:CG_I3 nparams:0x0 rettype:addr(26) import_unit(27) import_procedure  type:addr  procedure:M3ID_I3 nparams:0x0 rettype:addr(28) import_unit(29) import_procedure  type:addr  procedure:RTHooks_I3 nparams:0x0 rettype:addr(30) import_unit(31) declare_procedure  type:word64  procedure:TypeCaseStmt__GetOutcomex nparams:0x0 rettype:word64 lev:0 exported:0(32) declare_local  type:word64  local var M3_EXQtd6_oc type:word64 size:0x40 alignment:0x40(33) declare_local  type:word64  local var M3_EXQtd6__result type:word64 size:0x40 alignment:0x40(34) comment  comment: `GetOutcomex'(35) set_source_line  source line    5(36) begin_procedure  procedure TypeCaseStmt__GetOutcomex TypeCaseStmt__GetOutcomex(37) set_source_line  source line    6(38) load_integer  type:int64  integer:0x0(39) store  type:int64  type:int64  store (M3_EXQtd6_oc) offset:0x0 src_t:int64 dst_t:int64(40) set_source_line  source line    8(41) load  type:word64  type:int64  m3cg_load (M3_EXQtd6_oc): offset 0x0, convert word64 -> int64(42) exit_proc  type:word64(43) end_procedure  procedure TypeCaseStmt__GetOutcomex

Breakpoint 1, fancy_abort (file=0x1009f0c6f "../../gcc-4.5/gcc/gimplify.c", line=7315, function=0x1009f1242 "gimplify_expr") at ../../gcc-4.5/gcc/diagnostic.c:763763	  internal_error ("in %s, at %s:%d", function, trim_filename (file), line);(gdb) bt#0  fancy_abort (file=0x1009f0c6f "../../gcc-4.5/gcc/gimplify.c", line=7315, function=0x1009f1242 "gimplify_expr") at ../../gcc-4.5/gcc/diagnostic.c:763#1  0x00000001004cc4d6 in gimplify_expr (expr_p=0x1410e2060, pre_p=0x7fff5fbff420, post_p=0x7fff5fbfeff8, gimple_test_f=0x1004aac7f <is_gimple_lvalue>, fallback=2) at ../../gcc-4.5/gcc/gimplify.c:7315#2  0x00000001004c5ad3 in gimplify_modify_expr (expr_p=0x1416a5f28, pre_p=0x7fff5fbff420, post_p=0x7fff5fbfeff8, want_value=0 '\0') at ../../gcc-4.5/gcc/gimplify.c:4444#3  0x00000001004caafc in gimplify_expr (expr_p=0x1416a5f28, pre_p=0x7fff5fbff420, post_p=0x7fff5fbfeff8, gimple_test_f=0x1004ab1a6 <is_gimple_stmt>, fallback=0) at ../../gcc-4.5/gcc/gimplify.c:6619#4  0x00000001004c7800 in gimplify_stmt (stmt_p=0x1416a5f28, seq_p=0x7fff5fbff420) at ../../gcc-4.5/gcc/gimplify.c:5264#5  0x00000001004be376 in gimplify_statement_list (expr_p=0x1416c4030, pre_p=0x7fff5fbff420) at ../../gcc-4.5/gcc/gimplify.c:1382#6  0x00000001004cb6f5 in gimplify_expr (expr_p=0x1416c4030, pre_p=0x7fff5fbff420, post_p=0x7fff5fbff2e8, gimple_test_f=0x1004ab1a6 <is_gimple_stmt>, fallback=0) at ../../gcc-4.5/gcc/gimplify.c:6935#7  0x00000001004c7800 in gimplify_stmt (stmt_p=0x1416c4030, seq_p=0x7fff5fbff420) at ../../gcc-4.5/gcc/gimplify.c:5264#8  0x00000001004bdb6c in gimplify_bind_expr (expr_p=0x1416c2298, pre_p=0x7fff5fbff778) at ../../gcc-4.5/gcc/gimplify.c:1127#9  0x00000001004cae2b in gimplify_expr (expr_p=0x1416c2298, pre_p=0x7fff5fbff778, post_p=0x7fff5fbff618, gimple_test_f=0x1004ab1a6 <is_gimple_stmt>, fallback=0) at ../../gcc-4.5/gcc/gimplify.c:6719#10 0x00000001004c7800 in gimplify_stmt (stmt_p=0x1416c2298, seq_p=0x7fff5fbff778) at ../../gcc-4.5/gcc/gimplify.c:5264#11 0x00000001004ccbe6 in gimplify_body (body_p=0x1416c2298, fndecl=0x1416c2200, do_parms=1 '\001') at ../../gcc-4.5/gcc/gimplify.c:7528#12 0x00000001004cceae in gimplify_function_tree (fndecl=0x1416c2200) at ../../gcc-4.5/gcc/gimplify.c:7624#13 0x00000001000069c7 in m3_gimplify_function (fndecl=0x1416c2200) at ../../gcc-4.5/gcc/m3cg/parse.c:2370#14 0x0000000100009cb4 in m3cg_end_procedure () at ../../gcc-4.5/gcc/m3cg/parse.c:3642#15 0x000000010000feb5 in m3_parse_file (xx=0) at ../../gcc-4.5/gcc/m3cg/parse.c:5550#16 0x00000001006be6a2 in compile_file () at ../../gcc-4.5/gcc/toplev.c:1053#17 0x00000001006c0e19 in do_compile () at ../../gcc-4.5/gcc/toplev.c:2415#18 0x00000001006c0ee0 in toplev_main (argc=3, argv=0x7fff5fbff930) at ../../gcc-4.5/gcc/toplev.c:2457#19 0x000000010001743b in main (argc=3, argv=0x7fff5fbff930) at ../../gcc-4.5/gcc/main.c:35(

Wierd, huh?
The only thing I can think of an int/word mismatch.I did change one instance of Integer to Word, after finding this.Stmt.Outcomes is an enumeration.So presumably Stmt.Outcomes { } is 0.Enumerations should work equally well as Integer or Word, right?Clearly above there is still a mix. I can try changing them all to Word.

I'll keep digging.

Maybe dump the entire function generic tree for this and similar C.

 - Jay 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100627/47649ec6/attachment-0002.html>

From jay.krell at cornell.edu  Sun Jun 27 17:04:59 2010
From: jay.krell at cornell.edu (Jay K)
Date: Sun, 27 Jun 2010 15:04:59 +0000
Subject: [M3devel] m3cg 4.5 problem
In-Reply-To: <COL101-W24F2979E24DCCB1CDD09B3E6C90@phx.gbl>
References: <COL101-W728051433DA06972261F1E6C90@phx.gbl>, ,
	<COL101-W2519C65D63208BF55620CE6C90@phx.gbl>,
	<COL101-W24F2979E24DCCB1CDD09B3E6C90@phx.gbl>
Message-ID: <COL101-W327A4E4C62AF02A66F7138E6C90@phx.gbl>


Problem seems to be here:

fold-const.c:fold_ternary_loc
...  switch (code)...    case BIT_FIELD_REF:...      /* A bit-field-ref that referenced the full argument can be stripped.  */      if (INTEGRAL_TYPE_P (TREE_TYPE (arg0))	  && TYPE_PRECISION (TREE_TYPE (arg0)) == tree_low_cst (arg1, 1)	  && integer_zerop (op2))	return fold_convert_loc (loc, type, arg0);

Turning our bit field refs which are lvalues into casts (nop_expr) which are not.For now I'll #if this out.Further investigation: see how it compares to trunk; see if we can get the types right.
 - Jay
From: jay.krell at cornell.edu
To: m3devel at elegosoft.com; hosking at cs.purdue.edu
Date: Sun, 27 Jun 2010 13:44:06 +0000
Subject: Re: [M3devel] m3cg 4.5 problem








I almost have this figured out.

4.5:
(gdb) break is_gimple_lvalue(gdb) runBreakpoint 2, is_gimple_lvalue (t=0x414653b8) at ../../gcc-4.5/gcc/gimple.c:24562456	  return (is_gimple_addressable (t)(gdb) call debug_tree(t) <nop_expr 0x414653b8    type <integer_type 0x41417360 int_64 public DI        size <integer_cst 0x41405340 constant 64>        unit size <integer_cst 0x41405360 constant 8>        align 64 symtab 0 alias set -1 canonical type 0x41417360 precision 64 min <integer_cst 0x414052e0 -9223372036854775808> max <integer_cst 0x41405300 9223372036854775807>>       arg 0 <var_decl 0x414680b8 M3_DxNB17_oc        type <integer_type 0x414173c0 word_64 sizes-gimplified public unsigned DI size <integer_cst 0x41405340 64> unit size <integer_cst 0x41405360 8>            align 64 symtab 0 alias set -1 canonical type 0x414173c0 precision 64 min <integer_cst 0x41405380 0> max <integer_cst 0x41405320 18446744073709551615>>        unsigned DI file ../src/stmts/TypeCaseStmt.m3 line 12 col 0 size <integer_cst 0x41405340 64> unit size <integer_cst 0x41405360 8>        align 64 context <function_decl 0x41466400 TypeCaseStmt__GetOutcomex>>>


(gdb) finishRun till exit from #0  is_gimple_lvalue (t=0x414653b8) at ../../gcc-4.5/gcc/gimple.c:24560x004ea8bc in gimplify_expr (expr_p=0x41456218, pre_p=0xbffff510, post_p=0xbffff230, gimple_test_f=0x4c9bd5 <is_gimple_lvalue>, fallback=2) at ../../gcc-4.5/gcc/gimplify.c:72627262	gimple_test_f) (*expr_p))Value returned is $13 = 0 '\0'

4.3:(gdb) break is_gimple_lvalueBreakpoint 1 at 0x5708e3: file ../../gcc/gcc/tree-gimple.c, line 147.(gdb) runStarting program: /Users/jay/dev2/cm3/m3-sys/m3cc/I386_DARWIN-I386_DARWIN-4.3/gcc/m3cgc1 -m64 TypeCaseStmt.mcReading symbols for shared libraries ++. done TypeCaseStmt__GetOutcomexBreakpoint 1, is_gimple_lvalue (t=0x41141060) at ../../gcc/gcc/tree-gimple.c:147147	  return (is_gimple_addressable (t)(gdb) call debug_tree(t) <var_decl 0x41141060 M3_DxNB17_oc    type <integer_type 0x41111460 word_64 sizes-gimplified public unsigned DI        size <integer_cst 0x40b2d6f0 constant invariant 64>        unit size <integer_cst 0x40b2d720 constant invariant 8>        align 64 symtab 0 alias set -1 canonical type 0x41111460 precision 64 min <integer_cst 0x40b2d750 0> max <integer_cst 0x40b2d6c0 18446744073709551615>>    unsigned DI file ../src/stmts/TypeCaseStmt.m3 line 12 col 0 size <integer_cst 0x40b2d6f0 64> unit size <integer_cst 0x40b2d720 8>    align 64 context <function_decl 0x4113e100 TypeCaseStmt__GetOutcomex>>(gdb) finishRun till exit from #0  is_gimple_lvalue (t=0x41141060) at ../../gcc/gcc/tree-gimple.c:1470x003d7541 in gimplify_expr (expr_p=0x4113d16c, pre_p=0xbffff350, post_p=0xbffff34c, gimple_test_f=0x5708dd <is_gimple_lvalue>, fallback=fb_either) at ../../gcc/gcc/gimplify.c:6240warning: Source file is more recent than executable.6240	  if (!internal_post && (*gimple_test_f) (*expr_p))Value returned is $1 = 1 '\001'

nop_expr is what we use for casting.We are casting int64 to word64.The result of a cast is not an lvalue.I suspect 4.3 has removed this as a "useless conversion"...
In 4.5 we have: gdb: call debug_tree(*expr_p)
        stmt <modify_expr 0x41456200 type <integer_type 0x41417360 int_64>            side-effects used            arg 0 <nop_expr 0x414653b8 type <integer_type 0x41417360 int_64>                arg 0 <var_decl 0x414680b8 M3_DxNB17_oc>>            arg 1 <integer_cst 0x414057e0 constant 0>            ../src/stmts/TypeCaseStmt.m3:7:0>

in 4.3 we have:
        stmt <modify_expr 0x4113d180 type <integer_type 0x411113f0 int_64>            side-effects used            arg 0 <bit_field_ref 0x4113d150 type <integer_type 0x411113f0 int_64>                arg 0 <var_decl 0x41141060 M3_DxNB17_oc>                arg 1 <integer_cst 0x40b2d6f0 64>                arg 2 <integer_cst 0x40b2da20 constant invariant 0>>            arg 1 <integer_cst 0x40b2dde0 constant invariant 0>            ../src/stmts/TypeCaseStmt.m3:7:0> Again, 4.5 reads: (int64)oc = 0;
4.3 reads:  (bit field ref)oc = 0;
int64 cast is not an lvalue, bit field ref is. Something like that.
Either one of the #if GCC45 I have or gcc has done a transform in the meantime..
I'll keep digging.
I don't believe we need the cast -- we should just get the type right in the first place.But fixing that isn't necessarily what I'm going to do.I have to see where 4.3 vs. 4.5 difference comes from first..

 - Jay


From: jay.krell at cornell.edu
To: m3devel at elegosoft.com; hosking at cs.purdue.edu
Date: Sun, 27 Jun 2010 09:23:13 +0000
Subject: Re: [M3devel] m3cg 4.5 problem








I was a bit off. It is actually set of enum. Like this:
MODULE TypeCaseStmt;
TYPE T1 = {A,B};TYPE T2 = SET OF T1; PROCEDURE GetOutcomex (): T2 =  VAR oc := T2 {};  BEGIN    RETURN oc;  END GetOutcomex;
BEGINEND TypeCaseStmt.
 - Jay
From: jay.krell at cornell.edu
To: m3devel at elegosoft.com; hosking at cs.purdue.edu
Date: Sun, 27 Jun 2010 08:12:54 +0000
Subject: [M3devel] m3cg 4.5 problem








This tiny bit of code, which is cut down from m3front, causes an assertion failure in a 4.5 m3cg:
MODULE TypeCaseStmt;
IMPORT M3ID, CG, Expr, Stmt, StmtRep, Type, Variable, Scope;
PROCEDURE GetOutcomex (): Stmt.Outcomes =  VAR oc := Stmt.Outcomes {};  line 6  BEGIN    RETURN oc;  END GetOutcomex;
BEGINEND TypeCaseStmt.
../src/stmts/TypeCaseStmt.m3:6:0: internal compiler error: in gimplify_expr, at gimplify.c:7315Please submit a full bug report,

(1) begin_unit(2) set_source_file(3) set_source_line  source line    1(4) comment  comment: `module global constants'(5) declare_segment  segment L_1 typeid 0xffffffff(6) comment  comment: `module global data'(7) declare_segment  segment MM_TypeCaseStmt typeid 0xffffffff(8) set_source_line  source line   11(9) declare_procedure  type:addr  procedure:TypeCaseStmt_M3 nparams:0x1 rettype:addr lev:0 exported:1(10) declare_param  type:int64  param M3_AcxOUs_mode type:int64 typeid:0x195c2a74 bytesize:0x40 alignment:0x40 in_memory:0x0 up_level:0x0  mode 0x11 (DImode)(11) import_procedure  type:addr  procedure:TypeCaseStmt_I3 nparams:0x0 rettype:addr(12) export_unit(13) import_procedure  type:addr  procedure:Scope_I3 nparams:0x0 rettype:addr(14) import_unit(15) import_procedure  type:addr  procedure:Variable_I3 nparams:0x0 rettype:addr(16) import_unit(17) import_procedure  type:addr  procedure:Type_I3 nparams:0x0 rettype:addr(18) import_unit(19) import_procedure  type:addr  procedure:StmtRep_I3 nparams:0x0 rettype:addr(20) import_unit(21) import_procedure  type:addr  procedure:Stmt_I3 nparams:0x0 rettype:addr(22) import_unit(23) import_procedure  type:addr  procedure:Expr_I3 nparams:0x0 rettype:addr(24) import_unit(25) import_procedure  type:addr  procedure:CG_I3 nparams:0x0 rettype:addr(26) import_unit(27) import_procedure  type:addr  procedure:M3ID_I3 nparams:0x0 rettype:addr(28) import_unit(29) import_procedure  type:addr  procedure:RTHooks_I3 nparams:0x0 rettype:addr(30) import_unit(31) declare_procedure  type:word64  procedure:TypeCaseStmt__GetOutcomex nparams:0x0 rettype:word64 lev:0 exported:0(32) declare_local  type:word64  local var M3_EXQtd6_oc type:word64 size:0x40 alignment:0x40(33) declare_local  type:word64  local var M3_EXQtd6__result type:word64 size:0x40 alignment:0x40(34) comment  comment: `GetOutcomex'(35) set_source_line  source line    5(36) begin_procedure  procedure TypeCaseStmt__GetOutcomex TypeCaseStmt__GetOutcomex(37) set_source_line  source line    6(38) load_integer  type:int64  integer:0x0(39) store  type:int64  type:int64  store (M3_EXQtd6_oc) offset:0x0 src_t:int64 dst_t:int64(40) set_source_line  source line    8(41) load  type:word64  type:int64  m3cg_load (M3_EXQtd6_oc): offset 0x0, convert word64 -> int64(42) exit_proc  type:word64(43) end_procedure  procedure TypeCaseStmt__GetOutcomex

Breakpoint 1, fancy_abort (file=0x1009f0c6f "../../gcc-4.5/gcc/gimplify.c", line=7315, function=0x1009f1242 "gimplify_expr") at ../../gcc-4.5/gcc/diagnostic.c:763763	  internal_error ("in %s, at %s:%d", function, trim_filename (file), line);(gdb) bt#0  fancy_abort (file=0x1009f0c6f "../../gcc-4.5/gcc/gimplify.c", line=7315, function=0x1009f1242 "gimplify_expr") at ../../gcc-4.5/gcc/diagnostic.c:763#1  0x00000001004cc4d6 in gimplify_expr (expr_p=0x1410e2060, pre_p=0x7fff5fbff420, post_p=0x7fff5fbfeff8, gimple_test_f=0x1004aac7f <is_gimple_lvalue>, fallback=2) at ../../gcc-4.5/gcc/gimplify.c:7315#2  0x00000001004c5ad3 in gimplify_modify_expr (expr_p=0x1416a5f28, pre_p=0x7fff5fbff420, post_p=0x7fff5fbfeff8, want_value=0 '\0') at ../../gcc-4.5/gcc/gimplify.c:4444#3  0x00000001004caafc in gimplify_expr (expr_p=0x1416a5f28, pre_p=0x7fff5fbff420, post_p=0x7fff5fbfeff8, gimple_test_f=0x1004ab1a6 <is_gimple_stmt>, fallback=0) at ../../gcc-4.5/gcc/gimplify.c:6619#4  0x00000001004c7800 in gimplify_stmt (stmt_p=0x1416a5f28, seq_p=0x7fff5fbff420) at ../../gcc-4.5/gcc/gimplify.c:5264#5  0x00000001004be376 in gimplify_statement_list (expr_p=0x1416c4030, pre_p=0x7fff5fbff420) at ../../gcc-4.5/gcc/gimplify.c:1382#6  0x00000001004cb6f5 in gimplify_expr (expr_p=0x1416c4030, pre_p=0x7fff5fbff420, post_p=0x7fff5fbff2e8, gimple_test_f=0x1004ab1a6 <is_gimple_stmt>, fallback=0) at ../../gcc-4.5/gcc/gimplify.c:6935#7  0x00000001004c7800 in gimplify_stmt (stmt_p=0x1416c4030, seq_p=0x7fff5fbff420) at ../../gcc-4.5/gcc/gimplify.c:5264#8  0x00000001004bdb6c in gimplify_bind_expr (expr_p=0x1416c2298, pre_p=0x7fff5fbff778) at ../../gcc-4.5/gcc/gimplify.c:1127#9  0x00000001004cae2b in gimplify_expr (expr_p=0x1416c2298, pre_p=0x7fff5fbff778, post_p=0x7fff5fbff618, gimple_test_f=0x1004ab1a6 <is_gimple_stmt>, fallback=0) at ../../gcc-4.5/gcc/gimplify.c:6719#10 0x00000001004c7800 in gimplify_stmt (stmt_p=0x1416c2298, seq_p=0x7fff5fbff778) at ../../gcc-4.5/gcc/gimplify.c:5264#11 0x00000001004ccbe6 in gimplify_body (body_p=0x1416c2298, fndecl=0x1416c2200, do_parms=1 '\001') at ../../gcc-4.5/gcc/gimplify.c:7528#12 0x00000001004cceae in gimplify_function_tree (fndecl=0x1416c2200) at ../../gcc-4.5/gcc/gimplify.c:7624#13 0x00000001000069c7 in m3_gimplify_function (fndecl=0x1416c2200) at ../../gcc-4.5/gcc/m3cg/parse.c:2370#14 0x0000000100009cb4 in m3cg_end_procedure () at ../../gcc-4.5/gcc/m3cg/parse.c:3642#15 0x000000010000feb5 in m3_parse_file (xx=0) at ../../gcc-4.5/gcc/m3cg/parse.c:5550#16 0x00000001006be6a2 in compile_file () at ../../gcc-4.5/gcc/toplev.c:1053#17 0x00000001006c0e19 in do_compile () at ../../gcc-4.5/gcc/toplev.c:2415#18 0x00000001006c0ee0 in toplev_main (argc=3, argv=0x7fff5fbff930) at ../../gcc-4.5/gcc/toplev.c:2457#19 0x000000010001743b in main (argc=3, argv=0x7fff5fbff930) at ../../gcc-4.5/gcc/main.c:35(

Wierd, huh?
The only thing I can think of an int/word mismatch.I did change one instance of Integer to Word, after finding this.Stmt.Outcomes is an enumeration.So presumably Stmt.Outcomes { } is 0.Enumerations should work equally well as Integer or Word, right?Clearly above there is still a mix. I can try changing them all to Word.

I'll keep digging.

Maybe dump the entire function generic tree for this and similar C.

 - Jay 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100627/0a29baa9/attachment-0002.html>

From jay.krell at cornell.edu  Mon Jun 28 03:39:35 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 28 Jun 2010 01:39:35 +0000
Subject: [M3devel] gcc 4.5 status
Message-ID: <COL101-W56446A25BC09D1C25A5AD9E6CA0@phx.gbl>


Gcc 4.5 complains about a few similar aspects of our trees.
These would all be errors but I hacked the gcc source to make them warnings.


Running cm3 build with gcc 4.5 crashes early in sysutils => PathReprCommon => Text.Length.


I think I'll try to fix up these type issues first.
You can see they aren't all that interesting, either widening an unsigned integer or
changing the signedness but not the width of an integer.

It's likely this checking isn't on by default, but that I enabled it, and that the errors/warnings are true,
?even though my enabling might have been by hacking the #idefs instead of the configure command.


I assume upgrading to gcc 4.5 is considered fairly unilaterly uncontroversially good.
I chose working on it for that reason.


D.1401 = TextClass__GetChar (M3_Bd56fi_t.11, M3_Cwb5VA_i.10);

cm3cg: warning: type mismatch in indirect reference
word_64

<unnamed type>

D.1408 = *D.1407;

cm3cg: warning: verify_gimple failed
../src/cm3/TextUtils.m3: In function 'TextUtils__SkipRight':
cm3cg: warning: invalid conversion in gimple call
word_8

word_64

D.1481 = TextClass__GetChar (M3_Bd56fi_t.36, D.1479);

cm3cg: warning: type mismatch in indirect reference
word_64

<unnamed type>

D.1488 = *D.1487;

cm3cg: warning: verify_gimple failed
../src/cm3/TextUtils.m3: In function 'TextUtils__Compress':
cm3cg: warning: invalid conversion in gimple call
word_8

word_64

D.1553 = TextClass__GetChar (M3_Bd56fi_t.59, M3_Cwb5VA_i.58);

cm3cg: warning: type mismatch in indirect reference
word_64

<unnamed type>

D.1560 = *D.1559;

cm3cg: warning: invalid conversion in gimple call
word_8

word_64

D.1591 = TextClass__GetChar (M3_Bd56fi_t.67, D.1589);

cm3cg: warning: type mismatch in indirect reference
word_64

<unnamed type>

D.1598 = *D.1597;

cm3cg: warning: verify_gimple failed
../src/cm3/TextUtils.m3: In function 'TextUtils__SubstChar':
cm3cg: warning: invalid conversion in gimple call
word_8

word_64

D.1683 = TextClass__GetChar (M3_Bd56fi_t.99, D.1681);

cm3cg: warning: type mismatch in binary expression
word_64

int_64

int_64

D.1701 = D.1700 & 1;

cm3cg: warning: type mismatch in binary expression
word_64

int_64

int_64






 		 	   		  

From dabenavidesd at yahoo.es  Mon Jun 28 04:37:11 2010
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Mon, 28 Jun 2010 02:37:11 +0000 (GMT)
Subject: [M3devel] gcc 4.5 status
In-Reply-To: <COL101-W56446A25BC09D1C25A5AD9E6CA0@phx.gbl>
Message-ID: <619968.30896.qm@web23605.mail.ird.yahoo.com>

Hi all:
please let me investigate before you make the simple changes you are trying because as I understand the type of the ADR operator might be of an unsafe module but that doesn't mean you can hack it to do your program better compile (that would be like use an ill behaved program to make "well" behaved ones). I mean is good to discard that the type system (the set of sound type rules that make a program compile run and if safely guarded do its work flawlessly, that is, the set of safe and well behaved programs without ill behaved in there) is not "hacked" hard coded to expect the type of ADR to be ADDRESS instead of the UNTRACED REF T.
I would like to be pointed out the way you are trying to solve the initial problem, I mean it is easy to see that ADR operator might return ADDRESS but probably not in all cases (programs) to be UNTRACED REF T though your programs show yes, changes reveal there is a problem indeed with current tree.
Anyway this needs to confirm there is a change in the type rules a check of original m3tk as before had happened with the new types or type introductions rules.
I might need explanations about your rationale behind the new ADR type so if you don't mind just tell me what are the reasons to do the mentioned changes if you don't mind. I know there are this emails:
https://mail.elegosoft.com/pipermail/m3devel/2010-June/007241.html
and
https://mail.elegosoft.com/pipermail/m3devel/2010-June/007249.html
BTW are the m3-sys/cm3/m3test shipped to the source browser in Elego web pages, I might need to check this test cases before the actual code, see:
http://opencm3.net/doc/help/gen_html/INDEX.html
If not we better make some ones testing UNSAFE features if they aren't shipped and/or already done (just to proof well behaved programs properties in UNSAFE modules to see if they actually work and if not why do they fail, I know there might be less panic with them but is better to have them than nothing, we might make some directory of them if somebody can point out where I can put then I have Elego ssh keys so I can see what I can do about it).

Thanks for your attention


--- El dom, 27/6/10, Jay K <jay.krell at cornell.edu> escribi?:

> De: Jay K <jay.krell at cornell.edu>
> Asunto: [M3devel] gcc 4.5 status
> Para: "m3devel" <m3devel at elegosoft.com>
> Fecha: domingo, 27 de junio, 2010 20:39
> 
> Gcc 4.5 complains about a few similar aspects of our
> trees.
> These would all be errors but I hacked the gcc source to
> make them warnings.
> 
> 
> Running cm3 build with gcc 4.5 crashes early in sysutils
> => PathReprCommon => Text.Length.
> 
> 
> I think I'll try to fix up these type issues first.
> You can see they aren't all that interesting, either
> widening an unsigned integer or
> changing the signedness but not the width of an integer.
> 
> It's likely this checking isn't on by default, but that I
> enabled it, and that the errors/warnings are true,
>  even though my enabling might have been by hacking the
> #idefs instead of the configure command.
> 
> 
> I assume upgrading to gcc 4.5 is considered fairly
> unilaterly uncontroversially good.
> I chose working on it for that reason.
> 
> 
> D.1401 = TextClass__GetChar (M3_Bd56fi_t.11,
> M3_Cwb5VA_i.10);
> 
> cm3cg: warning: type mismatch in indirect reference
> word_64
> 
> <unnamed type>
> 
> D.1408 = *D.1407;
> 
> cm3cg: warning: verify_gimple failed
> ../src/cm3/TextUtils.m3: In function
> 'TextUtils__SkipRight':
> cm3cg: warning: invalid conversion in gimple call
> word_8
> 
> word_64
> 
> D.1481 = TextClass__GetChar (M3_Bd56fi_t.36, D.1479);
> 
> cm3cg: warning: type mismatch in indirect reference
> word_64
> 
> <unnamed type>
> 
> D.1488 = *D.1487;
> 
> cm3cg: warning: verify_gimple failed
> ../src/cm3/TextUtils.m3: In function
> 'TextUtils__Compress':
> cm3cg: warning: invalid conversion in gimple call
> word_8
> 
> word_64
> 
> D.1553 = TextClass__GetChar (M3_Bd56fi_t.59,
> M3_Cwb5VA_i.58);
> 
> cm3cg: warning: type mismatch in indirect reference
> word_64
> 
> <unnamed type>
> 
> D.1560 = *D.1559;
> 
> cm3cg: warning: invalid conversion in gimple call
> word_8
> 
> word_64
> 
> D.1591 = TextClass__GetChar (M3_Bd56fi_t.67, D.1589);
> 
> cm3cg: warning: type mismatch in indirect reference
> word_64
> 
> <unnamed type>
> 
> D.1598 = *D.1597;
> 
> cm3cg: warning: verify_gimple failed
> ../src/cm3/TextUtils.m3: In function
> 'TextUtils__SubstChar':
> cm3cg: warning: invalid conversion in gimple call
> word_8
> 
> word_64
> 
> D.1683 = TextClass__GetChar (M3_Bd56fi_t.99, D.1681);
> 
> cm3cg: warning: type mismatch in binary expression
> word_64
> 
> int_64
> 
> int_64
> 
> D.1701 = D.1700 & 1;
> 
> cm3cg: warning: type mismatch in binary expression
> word_64
> 
> int_64
> 
> int_64
> 
> 
> 
> 
> 
> 
>     
>         
>           
>   


      


From jay.krell at cornell.edu  Mon Jun 28 10:08:13 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 28 Jun 2010 08:08:13 +0000
Subject: [M3devel] gcc 4.5 status
In-Reply-To: <619968.30896.qm@web23605.mail.ird.yahoo.com>
References: <COL101-W56446A25BC09D1C25A5AD9E6CA0@phx.gbl>,
	<619968.30896.qm@web23605.mail.ird.yahoo.com>
Message-ID: <COL101-W395F243446FE921432E2E3E6CA0@phx.gbl>


Daniel, I'm afraid I generally don't understand much that you say.
True, m3tools/m3tk should ideally follow the compiler's definition of ADR.
Moving to gcc 4.5 has nothing to do with changing the meaning of ADR. Granted, I jump around a bit.

current/old ADR return ADDRESS, which is silently assignable to any UNTRACED REF type.
new ADR(t) returns UNTRACED REF t.

Consider C.
In C, void* is assignable to any pointer type. (not so in C++)
In C, &T returns T*, not void*.
So &T is NOT assignable to any pointer type, only T* and void*.

The idea here would be elevate unsafe Modula-3 to C's level of safety.
Instead of being even less safe.

Despite the lack of safety, a certain amount of static checking is a good idea.


?- Jay

----------------------------------------
> Date: Mon, 28 Jun 2010 02:37:11 +0000
> From: dabenavidesd at yahoo.es
> To: m3devel at elegosoft.com; jay.krell at cornell.edu
> Subject: Re: [M3devel] gcc 4.5 status
>
> Hi all:
> please let me investigate before you make the simple changes you are trying because as I understand the type of the ADR operator might be of an unsafe module but that doesn't mean you can hack it to do your program better compile (that would be like use an ill behaved program to make "well" behaved ones). I mean is good to discard that the type system (the set of sound type rules that make a program compile run and if safely guarded do its work flawlessly, that is, the set of safe and well behaved programs without ill behaved in there) is not "hacked" hard coded to expect the type of ADR to be ADDRESS instead of the UNTRACED REF T.
> I would like to be pointed out the way you are trying to solve the initial problem, I mean it is easy to see that ADR operator might return ADDRESS but probably not in all cases (programs) to be UNTRACED REF T though your programs show yes, changes reveal there is a problem indeed with current tree.
> Anyway this needs to confirm there is a change in the type rules a check of original m3tk as before had happened with the new types or type introductions rules.
> I might need explanations about your rationale behind the new ADR type so if you don't mind just tell me what are the reasons to do the mentioned changes if you don't mind. I know there are this emails:
> https://mail.elegosoft.com/pipermail/m3devel/2010-June/007241.html
> and
> https://mail.elegosoft.com/pipermail/m3devel/2010-June/007249.html
> BTW are the m3-sys/cm3/m3test shipped to the source browser in Elego web pages, I might need to check this test cases before the actual code, see:
> http://opencm3.net/doc/help/gen_html/INDEX.html
> If not we better make some ones testing UNSAFE features if they aren't shipped and/or already done (just to proof well behaved programs properties in UNSAFE modules to see if they actually work and if not why do they fail, I know there might be less panic with them but is better to have them than nothing, we might make some directory of them if somebody can point out where I can put then I have Elego ssh keys so I can see what I can do about it).
>
> Thanks for your attention
>
>
> --- El dom, 27/6/10, Jay K  escribi?:
>
>> De: Jay K 
>> Asunto: [M3devel] gcc 4.5 status
>> Para: "m3devel" 
>> Fecha: domingo, 27 de junio, 2010 20:39
>>
>> Gcc 4.5 complains about a few similar aspects of our
>> trees.
>> These would all be errors but I hacked the gcc source to
>> make them warnings.
>>
>>
>> Running cm3 build with gcc 4.5 crashes early in sysutils
>> => PathReprCommon => Text.Length.
>>
>>
>> I think I'll try to fix up these type issues first.
>> You can see they aren't all that interesting, either
>> widening an unsigned integer or
>> changing the signedness but not the width of an integer.
>>
>> It's likely this checking isn't on by default, but that I
>> enabled it, and that the errors/warnings are true,
>> even though my enabling might have been by hacking the
>> #idefs instead of the configure command.
>>
>>
>> I assume upgrading to gcc 4.5 is considered fairly
>> unilaterly uncontroversially good.
>> I chose working on it for that reason.
>>
>>
>> D.1401 = TextClass__GetChar (M3_Bd56fi_t.11,
>> M3_Cwb5VA_i.10);
>>
>> cm3cg: warning: type mismatch in indirect reference
>> word_64
>>
>> 
>>
>> D.1408 = *D.1407;
>>
>> cm3cg: warning: verify_gimple failed
>> ../src/cm3/TextUtils.m3: In function
>> 'TextUtils__SkipRight':
>> cm3cg: warning: invalid conversion in gimple call
>> word_8
>>
>> word_64
>>
>> D.1481 = TextClass__GetChar (M3_Bd56fi_t.36, D.1479);
>>
>> cm3cg: warning: type mismatch in indirect reference
>> word_64
>>
>> 
>>
>> D.1488 = *D.1487;
>>
>> cm3cg: warning: verify_gimple failed
>> ../src/cm3/TextUtils.m3: In function
>> 'TextUtils__Compress':
>> cm3cg: warning: invalid conversion in gimple call
>> word_8
>>
>> word_64
>>
>> D.1553 = TextClass__GetChar (M3_Bd56fi_t.59,
>> M3_Cwb5VA_i.58);
>>
>> cm3cg: warning: type mismatch in indirect reference
>> word_64
>>
>> 
>>
>> D.1560 = *D.1559;
>>
>> cm3cg: warning: invalid conversion in gimple call
>> word_8
>>
>> word_64
>>
>> D.1591 = TextClass__GetChar (M3_Bd56fi_t.67, D.1589);
>>
>> cm3cg: warning: type mismatch in indirect reference
>> word_64
>>
>> 
>>
>> D.1598 = *D.1597;
>>
>> cm3cg: warning: verify_gimple failed
>> ../src/cm3/TextUtils.m3: In function
>> 'TextUtils__SubstChar':
>> cm3cg: warning: invalid conversion in gimple call
>> word_8
>>
>> word_64
>>
>> D.1683 = TextClass__GetChar (M3_Bd56fi_t.99, D.1681);
>>
>> cm3cg: warning: type mismatch in binary expression
>> word_64
>>
>> int_64
>>
>> int_64
>>
>> D.1701 = D.1700 & 1;
>>
>> cm3cg: warning: type mismatch in binary expression
>> word_64
>>
>> int_64
>>
>> int_64
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
 		 	   		  

From dabenavidesd at yahoo.es  Mon Jun 28 13:31:36 2010
From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.)
Date: Mon, 28 Jun 2010 11:31:36 +0000 (GMT)
Subject: [M3devel] gcc 4.5 status
In-Reply-To: <COL101-W395F243446FE921432E2E3E6CA0@phx.gbl>
Message-ID: <760071.93937.qm@web23605.mail.ird.yahoo.com>

Hi:
ok, here is a good reference of type systems by Luca Cardelli, it is sort of familiar language with better conceptualization
http://lucacardelli.name/Papers/TypeSystems.pdf
Hope it helps and thanks for the answer let me know if the above paper is a proper clarification (I think it is, specially pages 1-4).
Thanks for the info, hope it helps 

--- El lun, 28/6/10, Jay K <jay.krell at cornell.edu> escribi?:

> De: Jay K <jay.krell at cornell.edu>
> Asunto: RE: [M3devel] gcc 4.5 status
> Para: "Daniel (M3)" <dabenavidesd at yahoo.es>, "m3devel" <m3devel at elegosoft.com>
> Fecha: lunes, 28 de junio, 2010 03:08
> 
> Daniel, I'm afraid I generally don't understand much that
> you say.
> True, m3tools/m3tk should ideally follow the compiler's
> definition of ADR.
> Moving to gcc 4.5 has nothing to do with changing the
> meaning of ADR. Granted, I jump around a bit.
> 
> current/old ADR return ADDRESS, which is silently
> assignable to any UNTRACED REF type.
> new ADR(t) returns UNTRACED REF t.
> 
> Consider C.
> In C, void* is assignable to any pointer type. (not so in
> C++)
> In C, &T returns T*, not void*.
> So &T is NOT assignable to any pointer type, only T*
> and void*.
> 
> The idea here would be elevate unsafe Modula-3 to C's level
> of safety.
> Instead of being even less safe.
> 
> Despite the lack of safety, a certain amount of static
> checking is a good idea.
> 
> 
>  - Jay
> 
> ----------------------------------------
> > Date: Mon, 28 Jun 2010 02:37:11 +0000
> > From: dabenavidesd at yahoo.es
> > To: m3devel at elegosoft.com;
> jay.krell at cornell.edu
> > Subject: Re: [M3devel] gcc 4.5 status
> >
> > Hi all:
> > please let me investigate before you make the simple
> changes you are trying because as I understand the type of
> the ADR operator might be of an unsafe module but that
> doesn't mean you can hack it to do your program better
> compile (that would be like use an ill behaved program to
> make "well" behaved ones). I mean is good to discard that
> the type system (the set of sound type rules that make a
> program compile run and if safely guarded do its work
> flawlessly, that is, the set of safe and well behaved
> programs without ill behaved in there) is not "hacked" hard
> coded to expect the type of ADR to be ADDRESS instead of the
> UNTRACED REF T.
> > I would like to be pointed out the way you are trying
> to solve the initial problem, I mean it is easy to see that
> ADR operator might return ADDRESS but probably not in all
> cases (programs) to be UNTRACED REF T though your programs
> show yes, changes reveal there is a problem indeed with
> current tree.
> > Anyway this needs to confirm there is a change in the
> type rules a check of original m3tk as before had happened
> with the new types or type introductions rules.
> > I might need explanations about your rationale behind
> the new ADR type so if you don't mind just tell me what are
> the reasons to do the mentioned changes if you don't mind. I
> know there are this emails:
> > https://mail.elegosoft.com/pipermail/m3devel/2010-June/007241.html
> > and
> > https://mail.elegosoft.com/pipermail/m3devel/2010-June/007249.html
> > BTW are the m3-sys/cm3/m3test shipped to the source
> browser in Elego web pages, I might need to check this test
> cases before the actual code, see:
> > http://opencm3.net/doc/help/gen_html/INDEX.html
> > If not we better make some ones testing UNSAFE
> features if they aren't shipped and/or already done (just to
> proof well behaved programs properties in UNSAFE modules to
> see if they actually work and if not why do they fail, I
> know there might be less panic with them but is better to
> have them than nothing, we might make some directory of them
> if somebody can point out where I can put then I have Elego
> ssh keys so I can see what I can do about it).
> >
> > Thanks for your attention
> >
> >
> > --- El dom, 27/6/10, Jay K  escribi?:
> >
> >> De: Jay K 
> >> Asunto: [M3devel] gcc 4.5 status
> >> Para: "m3devel" 
> >> Fecha: domingo, 27 de junio, 2010 20:39
> >>
> >> Gcc 4.5 complains about a few similar aspects of
> our
> >> trees.
> >> These would all be errors but I hacked the gcc
> source to
> >> make them warnings.
> >>
> >>
> >> Running cm3 build with gcc 4.5 crashes early in
> sysutils
> >> => PathReprCommon => Text.Length.
> >>
> >>
> >> I think I'll try to fix up these type issues
> first.
> >> You can see they aren't all that interesting,
> either
> >> widening an unsigned integer or
> >> changing the signedness but not the width of an
> integer.
> >>
> >> It's likely this checking isn't on by default, but
> that I
> >> enabled it, and that the errors/warnings are
> true,
> >> even though my enabling might have been by hacking
> the
> >> #idefs instead of the configure command.
> >>
> >>
> >> I assume upgrading to gcc 4.5 is considered
> fairly
> >> unilaterly uncontroversially good.
> >> I chose working on it for that reason.
> >>
> >>
> >> D.1401 = TextClass__GetChar (M3_Bd56fi_t.11,
> >> M3_Cwb5VA_i.10);
> >>
> >> cm3cg: warning: type mismatch in indirect
> reference
> >> word_64
> >>
> >> 
> >>
> >> D.1408 = *D.1407;
> >>
> >> cm3cg: warning: verify_gimple failed
> >> ../src/cm3/TextUtils.m3: In function
> >> 'TextUtils__SkipRight':
> >> cm3cg: warning: invalid conversion in gimple call
> >> word_8
> >>
> >> word_64
> >>
> >> D.1481 = TextClass__GetChar (M3_Bd56fi_t.36,
> D.1479);
> >>
> >> cm3cg: warning: type mismatch in indirect
> reference
> >> word_64
> >>
> >> 
> >>
> >> D.1488 = *D.1487;
> >>
> >> cm3cg: warning: verify_gimple failed
> >> ../src/cm3/TextUtils.m3: In function
> >> 'TextUtils__Compress':
> >> cm3cg: warning: invalid conversion in gimple call
> >> word_8
> >>
> >> word_64
> >>
> >> D.1553 = TextClass__GetChar (M3_Bd56fi_t.59,
> >> M3_Cwb5VA_i.58);
> >>
> >> cm3cg: warning: type mismatch in indirect
> reference
> >> word_64
> >>
> >> 
> >>
> >> D.1560 = *D.1559;
> >>
> >> cm3cg: warning: invalid conversion in gimple call
> >> word_8
> >>
> >> word_64
> >>
> >> D.1591 = TextClass__GetChar (M3_Bd56fi_t.67,
> D.1589);
> >>
> >> cm3cg: warning: type mismatch in indirect
> reference
> >> word_64
> >>
> >> 
> >>
> >> D.1598 = *D.1597;
> >>
> >> cm3cg: warning: verify_gimple failed
> >> ../src/cm3/TextUtils.m3: In function
> >> 'TextUtils__SubstChar':
> >> cm3cg: warning: invalid conversion in gimple call
> >> word_8
> >>
> >> word_64
> >>
> >> D.1683 = TextClass__GetChar (M3_Bd56fi_t.99,
> D.1681);
> >>
> >> cm3cg: warning: type mismatch in binary
> expression
> >> word_64
> >>
> >> int_64
> >>
> >> int_64
> >>
> >> D.1701 = D.1700 & 1;
> >>
> >> cm3cg: warning: type mismatch in binary
> expression
> >> word_64
> >>
> >> int_64
> >>
> >> int_64
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
>     
>         
>           
>   


      


From jay.krell at cornell.edu  Mon Jun 28 14:08:47 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 28 Jun 2010 12:08:47 +0000
Subject: [M3devel] "the tree problems"
Message-ID: <COL101-W50F7EF3F8B51097C14CDF9E6CA0@phx.gbl>


The "tree problems" exist with gcc 4.3 also.
I'd like to clear these up ahead of most other work.
? Enable configure -enable-checking=something unconditionally.

There a few. Some are more trivial than others.

Here is a start that I'm testing:
It can be broken into two parts, "bit operations (and/or/xor/not)" and index_address.

Index: parse.c
===================================================================
RCS file: /usr/cvs/cm3/m3-sys/m3cc/gcc/gcc/m3cg/parse.c,v
retrieving revision 1.201
diff -u -5 -r1.201 parse.c
--- parse.c??? 27 Jun 2010 14:09:32 -0000??? 1.201
+++ parse.c??? 28 Jun 2010 12:04:49 -0000
@@ -4404,41 +4404,43 @@
?static void
?m3cg_not (void)
?{
?? MTYPE (t);
?
-? EXPR_REF (-1) = m3_build1 (BIT_NOT_EXPR, m3_unsigned_type (t),
-???????????????????????????? EXPR_REF (-1));
+? EXPR_REF (-1) = m3_build1 (BIT_NOT_EXPR, t, m3_cast (t, EXPR_REF (-1)));
?}
?
?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_REF (-2) = m3_build2 (BIT_AND_EXPR, t,
+???????????????????????????? m3_cast (t, EXPR_REF (-2)),
+???????????????????????????? m3_cast (t, EXPR_REF (-1)));
?? EXPR_POP ();
?}
?
?static void
?m3cg_or (void)
?{
?? MTYPE (t);
?
-? EXPR_REF (-2) = m3_build2 (BIT_IOR_EXPR, m3_unsigned_type (t),
-???????????????????????????? EXPR_REF (-2), EXPR_REF (-1));
+? EXPR_REF (-2) = m3_build2 (BIT_IOR_EXPR, t,
+???????????????????????????? m3_cast (t, EXPR_REF (-2)),
+???????????????????????????? m3_cast (t, EXPR_REF (-1)));
?? EXPR_POP ();
?}
?
?static void
?m3cg_xor (void)
?{
?? MTYPE (t);
?
-? EXPR_REF (-2) = m3_build2 (BIT_XOR_EXPR, m3_unsigned_type (t),
-???????????????????????????? EXPR_REF (-2), EXPR_REF (-1));
+? EXPR_REF (-2) = m3_build2 (BIT_XOR_EXPR, t,
+???????????????????????????? m3_cast (t, EXPR_REF (-2)),
+???????????????????????????? m3_cast (t, EXPR_REF (-1)));
?? EXPR_POP ();
?}
?
?static void
?m3cg_shift (void)
@@ -4972,28 +4974,29 @@
?}
?
?static void
?m3cg_index_address (void)
?{
-? enum tree_code plus = (GCC45 ? POINTER_PLUS_EXPR : PLUS_EXPR);
-? tree a = { 0 };
?? MTYPE2?? (t, T);
-? BYTESIZE (n);
+? BYTESIZE (bits);
+? long bytes = bits / BITS_PER_UNIT;
+? bool signd = IS_INTEGER_TYPE_TREE(t);? 
+? tree a = (signd ? ssize_int (bytes) : ssize_int (bytes));
?
?? if (option_vars_trace)
-??? fprintf(stderr, "? index address n:0x%lx n_bytes:0x%lx type:%s\n",
-??????????? n, n / BITS_PER_UNIT, m3cg_typename(T));
+??? fprintf(stderr, "? index address n_bytes:0x%lx type:%s\n",
+??????????? bytes, m3cg_typename(T));
?
-? a = m3_build2 (MULT_EXPR, t, EXPR_REF (-1), size_int (n / BITS_PER_UNIT));
-? if (GCC45)
-? {
-??? gcc_assert(IS_INTEGER_TYPE_TREE(t) || IS_WORD_TYPE_TREE(t));
-??? if (IS_INTEGER_TYPE_TREE(t))
-????? a = m3_cast(ssizetype, a);
-??? a = m3_cast(sizetype, a);
-? }
-? EXPR_REF (-2) = m3_build2 (plus, t_addr, m3_cast (t_addr, EXPR_REF (-2)), a);
+? gcc_assert(signd || IS_WORD_TYPE_TREE(t));
+? gcc_assert(bits>= 0);
+? gcc_assert(bytes>= 0);
+? 
+? a = m3_build2 (MULT_EXPR, t, m3_cast(t, EXPR_REF (-1)), a);
+? if (signd)
+??? a = m3_cast(ssizetype, a);
+? a = m3_cast(sizetype, a);
+? EXPR_REF (-2) = m3_build2 (POINTER_PLUS_EXPR, t_addr, m3_cast (t_addr, EXPR_REF (-2)), a);
?? EXPR_POP ();
?}
?

alternatively we could try like:


+? EXPR_REF (-2) = m3_build2 (BIT_AND_EXPR, t,

+???????????????????????????? EXPR_REF (-2),

+???????????????????????????? EXPR_REF (-1));



which is nicer, if it works.


Though I believe the more "forceful" (cast-ful) interpretation is what Tony described a while ago, in describing what the NT/x86 backend does wrong.
These "bit" are fairly uniquely uninteresting, since they don't vary for signed vs. unsigned.


There are more problems in shifting, where I'm treading more carefully, since right shift's and "extract" are affected by signed vs. unsigned.


? - Jay
 		 	   		  

From rcolebur at SCIRES.COM  Mon Jun 28 21:26:18 2010
From: rcolebur at SCIRES.COM (Coleburn, Randy)
Date: Mon, 28 Jun 2010 15:26:18 -0400
Subject: [M3devel] m3core compilation errors on HEAD branch
Message-ID: <D67F02DDC62F7545A6B84C285F88F3E62F8D76D1@ATLEX02-SRV.SCIRES.LOCAL>

Jay:

I'm getting a bunch of compile errors on m3core package.

These are all from various "C" files, not modula-3.

Regards,
Randy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100628/b04b23d6/attachment-0002.html>

From jay.krell at cornell.edu  Mon Jun 28 22:04:41 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 28 Jun 2010 20:04:41 +0000
Subject: [M3devel] m3core compilation errors on HEAD branch
In-Reply-To: <D67F02DDC62F7545A6B84C285F88F3E62F8D76D1@ATLEX02-SRV.SCIRES.LOCAL>
References: <D67F02DDC62F7545A6B84C285F88F3E62F8D76D1@ATLEX02-SRV.SCIRES.LOCAL>
Message-ID: <COL101-W482011876B9BE028B81FB4E6CA0@phx.gbl>


I fixed hand.c.
I'll look at the rest later.

?- Jay


________________________________
> From: rcolebur at SCIRES.COM
> To: m3devel at elegosoft.com
> Date: Mon, 28 Jun 2010 15:26:18 -0400
> Subject: [M3devel] m3core compilation errors on HEAD branch
>
> Jay:
>
> I?m getting a bunch of compile errors on m3core
> package.
>
> These are all from various ?C? files, not
> modula-3.
>
> Regards,

> Randy
>
>
 		 	   		  

From jay.krell at cornell.edu  Mon Jun 28 22:49:53 2010
From: jay.krell at cornell.edu (Jay K)
Date: Mon, 28 Jun 2010 20:49:53 +0000
Subject: [M3devel] windows msi, file ownership
Message-ID: <COL101-W4607C2990464A09FC2013DE6CA0@phx.gbl>


I'm using the msi and I noticed the files are owned by nt authority\system.
Kind of annoying. A little harder to replace than "normal".
Probably should be changed to administrator.

?- Jay




 		 	   		  

From jay.krell at cornell.edu  Tue Jun 29 11:25:37 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 29 Jun 2010 09:25:37 +0000
Subject: [M3devel] gcc tree checking
Message-ID: <COL101-W5454413A2730ED2963AFD1E6CB0@phx.gbl>


One of the (series of) tree type mismatches is like:


m3cgc1: warning: verify_gimple failed
?TextUtils__TextExtras_FindCharSet
../src/cm3/TextUtils.m3: In function 'TextUtils__TextExtras_FindCharSet':
m3cgc1: warning: invalid conversion in gimple call
word_8
word_64
D.3538 = Text__GetChar (M3_Bd56fi_t, M3_Cwb5VA_i.322);

GetChar returns word_8 but the call is asserted to return word_64.

I believe this comes from:

PROCEDURE EmitCall (t: T) =
? VAR result := ProcType.CGResult (t.signature);
? BEGIN
??? IF (t.impl_peer # NIL) THEN t := t.impl_peer; END;
??? CG.Call_direct (t.cg_proc, result);
??? EVAL Marker.EmitExceptionTest (t.signature, need_value := FALSE);
? END EmitCall;

PROCEDURE CGResult (t: Type.T): CG.Type =
? VAR p := Reduce (t);
? BEGIN
??? IF (p = NIL) OR (p.result = NIL) THEN
????? RETURN CG.Type.Void;
??? ELSIF NOT LargeResult (p.result) THEN
????? RETURN Type.CGType (p.result, in_memory := TRUE);
????? (*** 2/27/96 WKK:? in_memory = TRUE => so that Win32 code generator
?????????? can convert register return values to their full 32-bit width! ***)
??? ELSIF p.callConv.standard_structs THEN
????? RETURN CG.Type.Void;
??? ELSE
????? RETURN CG.Type.Struct;
??? END;
? END CGResult;

PROCEDURE CGType (t: T;? in_memory: BOOLEAN): CG.Type =
? BEGIN
??? t := Check (t);
??? IF (in_memory)
????? THEN RETURN t.info.mem_type;
????? ELSE RETURN t.info.stk_type;
??? END;
? END CGType;


I think in_memory needs to be FALSE, and the Win32 codegen should
I believe act the same, but I can check/fix that either way.

I'm thinking maybe I should make a test case that thoroughly exercise
each m3cg opcode and verifies that the output assembly is unchanged,
for a few architectures.

I believe this area really should be fixed, but almost must be very careful.. (like in everything..).

?- Jay

 		 	   		  

From jay.krell at cornell.edu  Tue Jun 29 14:17:27 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 29 Jun 2010 12:17:27 +0000
Subject: [M3devel] gcc tree checking
In-Reply-To: <COL101-W5454413A2730ED2963AFD1E6CB0@phx.gbl>
References: <COL101-W5454413A2730ED2963AFD1E6CB0@phx.gbl>
Message-ID: <COL101-W3C343C13C41DE503EDAE8E6CB0@phx.gbl>


Changing in_memory breaks cm3.
The fix is therefore probably in parse.c to cast or convert, similar to what m3back does.

?- Jay

----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Subject: gcc tree checking
> Date: Tue, 29 Jun 2010 09:25:37 +0000
>
>
> One of the (series of) tree type mismatches is like:
>
>
> m3cgc1: warning: verify_gimple failed
>  TextUtils__TextExtras_FindCharSet
> ../src/cm3/TextUtils.m3: In function 'TextUtils__TextExtras_FindCharSet':
> m3cgc1: warning: invalid conversion in gimple call
> word_8
> word_64
> D.3538 = Text__GetChar (M3_Bd56fi_t, M3_Cwb5VA_i.322);
>
> GetChar returns word_8 but the call is asserted to return word_64.
>
> I believe this comes from:
>
> PROCEDURE EmitCall (t: T) =
>   VAR result := ProcType.CGResult (t.signature);
>   BEGIN
>     IF (t.impl_peer # NIL) THEN t := t.impl_peer; END;
>     CG.Call_direct (t.cg_proc, result);
>     EVAL Marker.EmitExceptionTest (t.signature, need_value := FALSE);
>   END EmitCall;
>
> PROCEDURE CGResult (t: Type.T): CG.Type =
>   VAR p := Reduce (t);
>   BEGIN
>     IF (p = NIL) OR (p.result = NIL) THEN
>       RETURN CG.Type.Void;
>     ELSIF NOT LargeResult (p.result) THEN
>       RETURN Type.CGType (p.result, in_memory := TRUE);
>       (*** 2/27/96 WKK:  in_memory = TRUE => so that Win32 code generator
>            can convert register return values to their full 32-bit width! ***)
>     ELSIF p.callConv.standard_structs THEN
>       RETURN CG.Type.Void;
>     ELSE
>       RETURN CG.Type.Struct;
>     END;
>   END CGResult;
>
> PROCEDURE CGType (t: T;  in_memory: BOOLEAN): CG.Type =
>   BEGIN
>     t := Check (t);
>     IF (in_memory)
>       THEN RETURN t.info.mem_type;
>       ELSE RETURN t.info.stk_type;
>     END;
>   END CGType;
>
>
> I think in_memory needs to be FALSE, and the Win32 codegen should
> I believe act the same, but I can check/fix that either way.
>
> I'm thinking maybe I should make a test case that thoroughly exercise
> each m3cg opcode and verifies that the output assembly is unchanged,
> for a few architectures.
>
> I believe this area really should be fixed, but almost must be very careful.. (like in everything..).
>
>  - Jay
>
>
 		 	   		  

From rodney_bates at lcwb.coop  Tue Jun 29 19:59:01 2010
From: rodney_bates at lcwb.coop (Rodney M. Bates)
Date: Tue, 29 Jun 2010 12:59:01 -0500
Subject: [M3devel] gcc tree checking
In-Reply-To: <COL101-W5454413A2730ED2963AFD1E6CB0@phx.gbl>
References: <COL101-W5454413A2730ED2963AFD1E6CB0@phx.gbl>
Message-ID: <4C2A3465.1080308@lcwb.coop>



Jay K wrote:
> One of the (series of) tree type mismatches is like:
> 
> 
> m3cgc1: warning: verify_gimple failed
>  TextUtils__TextExtras_FindCharSet
> ../src/cm3/TextUtils.m3: In function 'TextUtils__TextExtras_FindCharSet':
> m3cgc1: warning: invalid conversion in gimple call
> word_8
> word_64
> D.3538 = Text__GetChar (M3_Bd56fi_t, M3_Cwb5VA_i.322);
> 
> GetChar returns word_8 but the call is asserted to return word_64.
> 
> I believe this comes from:
> 
> PROCEDURE EmitCall (t: T) =
>   VAR result := ProcType.CGResult (t.signature);
>   BEGIN
>     IF (t.impl_peer # NIL) THEN t := t.impl_peer; END;
>     CG.Call_direct (t.cg_proc, result);
>     EVAL Marker.EmitExceptionTest (t.signature, need_value := FALSE);
>   END EmitCall;
> 
> PROCEDURE CGResult (t: Type.T): CG.Type =
>   VAR p := Reduce (t);
>   BEGIN
>     IF (p = NIL) OR (p.result = NIL) THEN
>       RETURN CG.Type.Void;
>     ELSIF NOT LargeResult (p.result) THEN
>       RETURN Type.CGType (p.result, in_memory := TRUE);
>       (*** 2/27/96 WKK:  in_memory = TRUE => so that Win32 code generator
>            can convert register return values to their full 32-bit width! ***)
>     ELSIF p.callConv.standard_structs THEN
>       RETURN CG.Type.Void;
>     ELSE
>       RETURN CG.Type.Struct;
>     END;
>   END CGResult;
> 
> PROCEDURE CGType (t: T;  in_memory: BOOLEAN): CG.Type =
>   BEGIN
>     t := Check (t);
>     IF (in_memory)
>       THEN RETURN t.info.mem_type;
>       ELSE RETURN t.info.stk_type;
>     END;
>   END CGType;
> 
> 
> I think in_memory needs to be FALSE, and the Win32 codegen should
> I believe act the same, but I can check/fix that either way.
> 
> I'm thinking maybe I should make a test case that thoroughly exercise
> each m3cg opcode and verifies that the output assembly is unchanged,
> for a few architectures.

This is a very good idea.  It may be a lot of work, but I have found
many times over that regression testing tools of this kind pay for
themselves in the (not so) long run.  Some of the changes found will
be legitimate, but that's a lot easier to verify than to chase obscure
bugs from end symptoms.

> 
> I believe this area really should be fixed, but almost must be very careful.. (like in everything..).
> 
>  - Jay
> 
>  		 	   		  


From jay.krell at cornell.edu  Tue Jun 29 22:28:53 2010
From: jay.krell at cornell.edu (Jay K)
Date: Tue, 29 Jun 2010 20:28:53 +0000
Subject: [M3devel] gcc tree checking
In-Reply-To: <4C2A3465.1080308@lcwb.coop>
References: <COL101-W5454413A2730ED2963AFD1E6CB0@phx.gbl>,
	<4C2A3465.1080308@lcwb.coop>
Message-ID: <COL101-W622BF57F65B4D5A9A22DF2E6CB0@phx.gbl>


I staked a claim, put in the start of something and made it work.
But then got lazy. I've been using m3core as my test.
Compiling all of it with cm3 -keep.
mv AMD64_DARWIN AMD64_DARWIN.1
make a compiler change
cm3 -keep again
diff -u AMD64_DARWIN.1 AMD64_DARWIN

And then often recompiling compiler with itself to push the change further.
?Hoping the compiler itself gets pretty good coverage, which has proven
? right and wrong through the years.

The test I put in can still be developed further.

?- Jay


----------------------------------------
> Date: Tue, 29 Jun 2010 12:59:01 -0500
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] gcc tree checking
>
>
>
> Jay K wrote:
>> One of the (series of) tree type mismatches is like:
>>
>>
>> m3cgc1: warning: verify_gimple failed
>> TextUtils__TextExtras_FindCharSet
>> ../src/cm3/TextUtils.m3: In function 'TextUtils__TextExtras_FindCharSet':
>> m3cgc1: warning: invalid conversion in gimple call
>> word_8
>> word_64
>> D.3538 = Text__GetChar (M3_Bd56fi_t, M3_Cwb5VA_i.322);
>>
>> GetChar returns word_8 but the call is asserted to return word_64.
>>
>> I believe this comes from:
>>
>> PROCEDURE EmitCall (t: T) =
>> VAR result := ProcType.CGResult (t.signature);
>> BEGIN
>> IF (t.impl_peer # NIL) THEN t := t.impl_peer; END;
>> CG.Call_direct (t.cg_proc, result);
>> EVAL Marker.EmitExceptionTest (t.signature, need_value := FALSE);
>> END EmitCall;
>>
>> PROCEDURE CGResult (t: Type.T): CG.Type =
>> VAR p := Reduce (t);
>> BEGIN
>> IF (p = NIL) OR (p.result = NIL) THEN
>> RETURN CG.Type.Void;
>> ELSIF NOT LargeResult (p.result) THEN
>> RETURN Type.CGType (p.result, in_memory := TRUE);
>> (*** 2/27/96 WKK: in_memory = TRUE => so that Win32 code generator
>> can convert register return values to their full 32-bit width! ***)
>> ELSIF p.callConv.standard_structs THEN
>> RETURN CG.Type.Void;
>> ELSE
>> RETURN CG.Type.Struct;
>> END;
>> END CGResult;
>>
>> PROCEDURE CGType (t: T; in_memory: BOOLEAN): CG.Type =
>> BEGIN
>> t := Check (t);
>> IF (in_memory)
>> THEN RETURN t.info.mem_type;
>> ELSE RETURN t.info.stk_type;
>> END;
>> END CGType;
>>
>>
>> I think in_memory needs to be FALSE, and the Win32 codegen should
>> I believe act the same, but I can check/fix that either way.
>>
>> I'm thinking maybe I should make a test case that thoroughly exercise
>> each m3cg opcode and verifies that the output assembly is unchanged,
>> for a few architectures.
>
> This is a very good idea. It may be a lot of work, but I have found
> many times over that regression testing tools of this kind pay for
> themselves in the (not so) long run. Some of the changes found will
> be legitimate, but that's a lot easier to verify than to chase obscure
> bugs from end symptoms.
>
>>
>> I believe this area really should be fixed, but almost must be very careful.. (like in everything..).
>>
>> - Jay
>>
>>
 		 	   		  

From wagner at elegosoft.com  Wed Jun 30 09:06:31 2010
From: wagner at elegosoft.com (Olaf Wagner)
Date: Wed, 30 Jun 2010 09:06:31 +0200
Subject: [M3devel] gcc tree checking
In-Reply-To: <4C2A3465.1080308@lcwb.coop>
References: <COL101-W5454413A2730ED2963AFD1E6CB0@phx.gbl>
	<4C2A3465.1080308@lcwb.coop>
Message-ID: <20100630090631.10m2uzg52cs40sc8@mail.elegosoft.com>

Quoting "Rodney M. Bates" <rodney_bates at lcwb.coop>:

> Jay K wrote:
[...]
>> I'm thinking maybe I should make a test case that thoroughly exercise
>> each m3cg opcode and verifies that the output assembly is unchanged,
>> for a few architectures.
>
> This is a very good idea.  It may be a lot of work, but I have found
> many times over that regression testing tools of this kind pay for
> themselves in the (not so) long run.  Some of the changes found will
> be legitimate, but that's a lot easier to verify than to chase obscure
> bugs from end symptoms.

I second that. Regression testing for the generated code would be
great and give us much more safefy when changing the compiler.

So anybody who'd like to work in this area is greatly encouraged.

Of course a general easily extensible framework would be nice :-)
Preferrably written in quake and M3.

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