>=3B ../src/word/WordRep.i3:1:= > fatal error: *** illegal type: 0x6f=2C at m3cg_lineno 5

I thin= >k this is caused by cm3cg mismatching cm3.
upgrade.py is supposed to upg= >rade them at the proper time though.
I did used to have things a little = >wrong=2C esp. willingness to use an unshipped version laying around.
>
=3BOr maybe cm3cg has the wrong target.
=3Bcm3cg -v or -= >V or -version?

You could switch your AMD64_LINUX tools to the C= > backend.. :)
(It should work. I think I tested it on modula3.elegosoft.= >com.)

ves" target=3D"_blank">http://modula3.elegosoft.com/cm3/uploaded-archivesa>
Darn=2C nothing recent for AMD64_LINUX.
I can work on that this we= >ek..using the C backend.

There are also snapshots from Hudson he= >re=2C of varying dates:
ps/snapshot-index.html" target=3D"_blank">https://modula3.elegosoft.com/cm3= >/snaps/snapshot-index.html =3B

=3B- Jay

>

>=3B To: jay.krell at cornell.edu
>=3B CC: m3devel at elegosoft.com<= >br>>=3B Subject: Re: [M3devel] building CM3 on a Raspberry Pi?
>=3B = >Date: Mon=2C 14 Oct 2013 12:02:52 -0700
>=3B From: mika at async.caltech.= >edu
>=3B
>=3B More updates...
>=3B
>=3B after I remov= >e mklib=2C I do get a new compiler built=2C and I get to this point
>= >=3B
>=3B ignoring ../src/m3overrides
>=3B
>=3B =3D=3D>= >=3B /nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3/m3-win/import-libs = >done
>=3B
>=3B +++ /nfs/site/home/mnystroe/work/cm3/bin/cm3 -s= >hip -DROOT=3D/nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3 +++
>= >=3B --- shipping from AMD64_LINUX ---
>=3B
>=3B =3D=3D>=3B /n= >fs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3/m3-win/import-libs doner>>=3B
>=3B =3D=3D package /nfs/site/disks/wdisk.133/mnystroe/cm3-a= >non-cvs/cm3/m3-libs/m3core =3D=3D
>=3B
>=3B +++ /nfs/site/home/= >mnystroe/work/cm3/bin/cm3 -build -DROOT=3D/nfs/site/disks/wdisk.133/mnys= >troe/cm3-anon-cvs/cm3 +++
>=3B --- building in AMD64_LINUX ---
>= >=3B
>=3B ignoring ../src/m3overrides
>=3B
>=3B new source = >->=3B compiling RTHooks.i3
>=3B ../src/runtime/common/RTHooks.i3:15:= > fatal error: *** illegal type: 0x6f=2C at m3cg_lineno 5
>=3B compila= >tion terminated.
>=3B m3_backend =3D>=3B 1
>=3B m3cc (aka cm3= >cg) failed compiling: RTHooks.ic
>=3B Assembler messages:
>=3B Ca= >n't open RTHooks.is for reading: No such file or directory
>=3B new so= >urce ->=3B compiling RT0.i3
>=3B ../src/runtime/common/RT0.i3:19: fa= >tal error: *** illegal type: 0x6f=2C at m3cg_lineno 5
>=3B compilatio= >n terminated.
>=3B m3_backend =3D>=3B 1
>=3B m3cc (aka cm3cg)= > failed compiling: RT0.ic
>=3B Assembler messages:
>=3B Can't ope= >n RT0.is for reading: No such file or directory
>=3B new source ->= >=3B compiling RuntimeError.i3
>=3B ../src/runtime/common/RuntimeError.= >i3:10: fatal error: *** illegal type: 0x6f=2C at m3cg_lineno 5
>=3B c= >ompilation terminated.
>=3B m3_backend =3D>=3B 1
>=3B m3cc (a= >ka cm3cg) failed compiling: RuntimeError.ic
>=3B Assembler messages:r>>=3B Can't open RuntimeError.is for reading: No such file or directory<= >br>>=3B new source ->=3B compiling WordRep.i3
>=3B ../src/word/Wor= >dRep.i3:1: fatal error: *** illegal type: 0x6f=2C at m3cg_lineno 5
>= >=3B
>=3B I've seen this before but don't remember what the issue is.<= >br>>=3B
>=3B The compiler is new:
>=3B
>=3B -rwxr-x--- 1= > mnystroe rrc 9916732 2013-10-14 11:59 /nfs/site/home/mnystroe/work/cm3/bin= >/cm3
>=3B
>=3B This is on linux/amd64...
>=3B
>=3B r>>=3B mika writes:
>=3B >=3BMy toolsets are old=2C yes.
>=3B= > >=3B
>=3B >=3BI tried upgrade.py but you saw that that didn't wor= >k either.
>=3B >=3B
>=3B >=3BI guess I could go back and re= >-install from a recent binary image (where
>=3B >=3Bare the most rec= >ent ones? I only see really old ones on elegosoft...) and
>=3B >=3B= >build everything from scratch. It's just that all the systems that I
&g= >t=3B >=3Bhave M3 on are some sort of production systems and I don't want = >to mess
>=3B >=3Bup the installations unnecessarily... but if it's= > the only way...
>=3B >=3B
>=3B >=3B Mika
>=3B >= >=3B
>=3B >=3BJay K writes:
>=3B >=3B>=3B--_461a9835-225f-44= >8d-96a6-4c651ff66c13_
>=3B >=3B>=3BContent-Type: text/plain=3B cha= >rset=3D"iso-8859-1"
>=3B >=3B>=3BContent-Transfer-Encoding: quoted= >-printable
>=3B >=3B>=3B
>=3B >=3B>=3BTarget.i3/m3 look u= >p to date.
>=3B >=3B>=3BIs your host toolset very old?
>=3B &= >gt=3B>=3B
>=3B >=3B>=3Bhttps://modula3.elegosoft.com/cgi-bin/cvs= >web.cgi/cm3/m3-sys/m3middle/src/Ta=3D
>=3B >=3B>=3Brget.i3
>= >=3B >=3B>=3B
>=3B >=3B>=3BRevision 1.59: download - view: text= >=3D2C markup=3D2C annotated - select for di=3D
>=3B >=3B>=3Bffs>>=3B >=3B>=3B=3D0A=3D
>=3B >=3B>=3BSat Jun 19 06:56:32 2010= > (3 years=3D2C 3 months ago) by jkrell
>=3B >=3B>=3B=3D0A=3D
&= >gt=3B >=3B>=3BBranches: MAIN
>=3B >=3B>=3B=3D0A=3D
>=3B &= >gt=3B>=3BDiff to: previous 1.58: preferred=3D2C unified
>=3B >=3B&= >gt=3B=3D0A=3D
>=3B >=3B>=3BChanges since revision 1.58: +2 -0 line= >s
>=3B >=3B>=3B=3D0A=3D
>=3B >=3B>=3Badd ARMEL_LINUX with= > correct jmbuf size/align=3D0A=3D
>=3B >=3B>=3Bguessing about alig= >nment=3D0A=3D
>=3B >=3B>=3B"ARM" is an older ABI=3D0A=3D
>=3B= > >=3B>=3B"ARME" is the usual modern ABI=3D0A=3D
>=3B >=3B>=3BL= > for little endian=3D0A=3D
>=3B >=3B>=3B
>=3B >=3B>=3Bscr= >ipts/update.py ?
>=3B >=3B>=3B
>=3B >=3B>=3B - Jay
iv>

>= > >--_b7ef6d52-d09a-4017-8a20-e0fef4593137_-- From jay.krell at cornell.edu Mon Oct 14 23:06:22 2013 From: jay.krell at cornell.edu (Jay K) Date: Mon, 14 Oct 2013 21:06:22 +0000 Subject: [M3devel] building CM3 on a Raspberry Pi? In-Reply-To: <20131014204636.A77381A208E@async.async.caltech.edu> References: <20131013203501.35E651A208F@async.async.caltech.edu>, , , , <20131014151924.979A31A208E@async.async.caltech.edu>, , , , <20131014164008.685B81A208E@async.async.caltech.edu>, , ,

<20131014185302.4952B1A208E@async.async.caltech.edu>, <20131014190252.147321A208E@async.async.caltech.edu> , <20131014204636.A77381A208E@async.async.caltech.edu> Message-ID: > I thought we could bootstrap all the way back with SRC M3? I don't think so. I don't believe 4.0 or maybe 5.0/5.1 can bootstrap with 3.6, without applying and later reverting some diffs. The unicode stuff I think is partly to blame. But really the 3.6 stuff wasn't so good it turns out. It was much harder to port and contained overly tight dependencies on underlying implementation details of the operating systems. What we have now is approaching the portability of typical C or C++ code. (Still to fix the jmpbuf size and cooperative suspend...) > (907)tsvnc06:...cm3-anon-cvs/cm3/scripts/python>cm3cg -v > M3CG - Modula-3 Compiler back end4.3.0 At some point in the bootstrap that should advance higher. Are you running as a user that can overwrite cm3 and cm3cg? - Jay > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] building CM3 on a Raspberry Pi? > Date: Mon, 14 Oct 2013 13:46:36 -0700 > From: mika at async.caltech.edu > > > Well I think this error is what got me to give up building on MIPS > (Asus router) a couple of years ago. > > This stuff is really very difficult to get through. > > hmm... so here I am just trying to ./upgrade.py, no cross building yet. > > My tools aren't THAT old. 2-3 years at most. I thought we could bootstrap all the way back with SRC M3? > > (906)tsvnc06:...cm3-anon-cvs/cm3/scripts/python>cm3cg -version > Modula-3 backend (GCC) version 4.3.0 (x86_64-unknown-linux-gnu) > compiled by GNU C version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21), GMP version 4.2.1, MPFR version 2.3.0. > GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 > options passed: > options enabled: -falign-loops -fargument-alias > -fasynchronous-unwind-tables -fauto-inc-dec -fbranch-count-reg -fcommon > -fearly-inlining -feliminate-unused-debug-types -ffunction-cse -fgcse-lm > -fident -fivopts -fkeep-static-consts -fleading-underscore -fmath-errno > -fmerge-debug-strings -fmove-loop-invariants -fpeephole > -freg-struct-return -fsched-interblock -fsched-spec > -fsched-stalled-insns-dep -fsigned-zeros -fsplit-ivs-in-unroller > -ftoplevel-reorder -ftrapping-math -ftree-cselim -ftree-loop-im > -ftree-loop-ivcanon -ftree-loop-optimize -ftree-parallelize-loops= > -ftree-reassoc -ftree-scev-cprop -ftree-vect-loop-version -funwind-tables > -fvar-tracking -fvect-cost-model -fzero-initialized-in-bss > -m128bit-long-double -m64 -m80387 -maccumulate-outgoing-args > -malign-stringops -mfancy-math-387 -mfp-ret-in-387 -mfused-madd -mglibc > -mieee-fp -mmmx -mno-sse4 -mpush-args -mred-zone -msse -msse2 > -mtls-direct-seg-refs > > (907)tsvnc06:...cm3-anon-cvs/cm3/scripts/python>cm3cg -v > M3CG - Modula-3 Compiler back end4.3.0 > > (908)tsvnc06:...cm3-anon-cvs/cm3/scripts/python>which cm3cg > /nfs/site/home/mnystroe/work/cm3/bin/cm3cg > (909)tsvnc06:...cm3-anon-cvs/cm3/scripts/python>ls -l `!!` > ls -l `which cm3cg` > -rwxr-x--- 1 mnystroe rrc 29747222 2010-06-04 10:41 /nfs/site/home/mnystroe/work/cm3/bin/cm3cg > > > > > Jay K writes: > >--_b7ef6d52-d09a-4017-8a20-e0fef4593137_ > >Content-Type: text/plain; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > >> ../src/word/WordRep.i3:1: fatal error: *** illegal type: 0x6f=2C at m3cg= > >_lineno 5 > > > > > >I think this is caused by cm3cg mismatching cm3. > >upgrade.py is supposed to upgrade them at the proper time though. > >I did used to have things a little wrong=2C esp. willingness to use an unsh= > >ipped version laying around. > > > > > > Or maybe cm3cg has the wrong target.=20 > > cm3cg -v or -V or -version?=20 > > > > > >You could switch your AMD64_LINUX tools to the C backend.. :) > >(It should work. I think I tested it on modula3.elegosoft.com.) > > > > > >http://modula3.elegosoft.com/cm3/uploaded-archives > >Darn=2C nothing recent for AMD64_LINUX. > >I can work on that this week..using the C backend. > > > > > >There are also snapshots from Hudson here=2C of varying dates: > >https://modula3.elegosoft.com/cm3/snaps/snapshot-index.html =20 > > > > > > - Jay > > > > > >> To: jay.krell at cornell.edu > >> CC: m3devel at elegosoft.com > >> Subject: Re: [M3devel] building CM3 on a Raspberry Pi? > >> Date: Mon=2C 14 Oct 2013 12:02:52 -0700 > >> From: mika at async.caltech.edu > >>=20 > >> More updates... > >>=20 > >> after I remove mklib=2C I do get a new compiler built=2C and I get to thi= > >s point > >>=20 > >> ignoring ../src/m3overrides > >>=20 > >> =3D=3D> /nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3/m3-win/impor= > >t-libs done > >>=20 > >> +++ /nfs/site/home/mnystroe/work/cm3/bin/cm3 -ship -DROOT=3D/nfs/site/d= > >isks/wdisk.133/mnystroe/cm3-anon-cvs/cm3 +++ > >> --- shipping from AMD64_LINUX --- > >>=20 > >> =3D=3D> /nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3/m3-win/impor= > >t-libs done > >>=20 > >> =3D=3D package /nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3/m3-lib= > >s/m3core =3D=3D > >>=20 > >> +++ /nfs/site/home/mnystroe/work/cm3/bin/cm3 -build -DROOT=3D/nfs/sit= > >e/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3 +++ > >> --- building in AMD64_LINUX --- > >>=20 > >> ignoring ../src/m3overrides > >>=20 > >> new source -> compiling RTHooks.i3 > >> ../src/runtime/common/RTHooks.i3:15: fatal error: *** illegal type: 0x6f= > >=2C at m3cg_lineno 5 > >> compilation terminated. > >> m3_backend =3D> 1 > >> m3cc (aka cm3cg) failed compiling: RTHooks.ic > >> Assembler messages: > >> Can't open RTHooks.is for reading: No such file or directory > >> new source -> compiling RT0.i3 > >> ../src/runtime/common/RT0.i3:19: fatal error: *** illegal type: 0x6f=2C = > >at m3cg_lineno 5 > >> compilation terminated. > >> m3_backend =3D> 1 > >> m3cc (aka cm3cg) failed compiling: RT0.ic > >> Assembler messages: > >> Can't open RT0.is for reading: No such file or directory > >> new source -> compiling RuntimeError.i3 > >> ../src/runtime/common/RuntimeError.i3:10: fatal error: *** illegal type:= > > 0x6f=2C at m3cg_lineno 5 > >> compilation terminated. > >> m3_backend =3D> 1 > >> m3cc (aka cm3cg) failed compiling: RuntimeError.ic > >> Assembler messages: > >> Can't open RuntimeError.is for reading: No such file or directory > >> new source -> compiling WordRep.i3 > >> ../src/word/WordRep.i3:1: fatal error: *** illegal type: 0x6f=2C at m3cg= > >_lineno 5 > >>=20 > >> I've seen this before but don't remember what the issue is. > >>=20 > >> The compiler is new: > >>=20 > >> -rwxr-x--- 1 mnystroe rrc 9916732 2013-10-14 11:59 /nfs/site/home/mnystro= > >e/work/cm3/bin/cm3 > >>=20 > >> This is on linux/amd64... > >>=20 > >>=20 > >> mika writes: > >> >My toolsets are old=2C yes. > >> > > >> >I tried upgrade.py but you saw that that didn't work either. =20 > >> > > >> >I guess I could go back and re-install from a recent binary image (where > >> >are the most recent ones? I only see really old ones on elegosoft...) a= > >nd > >> >build everything from scratch. It's just that all the systems that I > >> >have M3 on are some sort of production systems and I don't want to mess > >> >up the installations unnecessarily... but if it's the only way... > >> >=20 > >> > Mika > >> > > >> >Jay K writes: > >> >>--_461a9835-225f-448d-96a6-4c651ff66c13_ > >> >>Content-Type: text/plain=3B charset=3D"iso-8859-1" > >> >>Content-Transfer-Encoding: quoted-printable > >> >> > >> >>Target.i3/m3 look up to date. > >> >>Is your host toolset very old? > >> >> > >> >>https://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3middle/sr= > >c/Ta=3D > >> >>rget.i3 > >> >> > >> >>Revision 1.59: download - view: text=3D2C markup=3D2C annotated - selec= > >t for di=3D > >> >>ffs > >> >>=3D0A=3D > >> >>Sat Jun 19 06:56:32 2010 (3 years=3D2C 3 months ago) by jkrell > >> >>=3D0A=3D > >> >>Branches: MAIN > >> >>=3D0A=3D > >> >>Diff to: previous 1.58: preferred=3D2C unified > >> >>=3D0A=3D > >> >>Changes since revision 1.58: +2 -0 lines > >> >>=3D0A=3D > >> >>add ARMEL_LINUX with correct jmbuf size/align=3D0A=3D > >> >>guessing about alignment=3D0A=3D > >> >>"ARM" is an older ABI=3D0A=3D > >> >>"ARME" is the usual modern ABI=3D0A=3D > >> >>L for little endian=3D0A=3D > >> >> > >> >>scripts/update.py ? > >> >> > >> >> - Jay > > = > > > >--_b7ef6d52-d09a-4017-8a20-e0fef4593137_ > >Content-Type: text/html; charset="iso-8859-1" > >Content-Transfer-Encoding: quoted-printable > > > > > > > > > >

>=3B ../src/word/WordRep.i3:1:= > > fatal error: *** illegal type: 0x6f=2C at m3cg_lineno 5

I thin= > >k this is caused by cm3cg mismatching cm3.
upgrade.py is supposed to upg= > >rade them at the proper time though.
I did used to have things a little = > >wrong=2C esp. willingness to use an unshipped version laying around.
>>
=3BOr maybe cm3cg has the wrong target.
=3Bcm3cg -v or -= > >V or -version?

You could switch your AMD64_LINUX tools to the C= > > backend.. :)
(It should work. I think I tested it on modula3.elegosoft.= > >com.)

>ves" target=3D"_blank">http://modula3.elegosoft.com/cm3/uploaded-archives >a>
Darn=2C nothing recent for AMD64_LINUX.
I can work on that this we= > >ek..using the C backend.

There are also snapshots from Hudson he= > >re=2C of varying dates:
>ps/snapshot-index.html" target=3D"_blank">https://modula3.elegosoft.com/cm3= > >/snaps/snapshot-index.html =3B

=3B- Jay

>>

>=3B To: jay.krell at cornell.edu
>=3B CC: m3devel at elegosoft.com<= > >br>>=3B Subject: Re: [M3devel] building CM3 on a Raspberry Pi?
>=3B = > >Date: Mon=2C 14 Oct 2013 12:02:52 -0700
>=3B From: mika at async.caltech.= > >edu
>=3B
>=3B More updates...
>=3B
>=3B after I remov= > >e mklib=2C I do get a new compiler built=2C and I get to this point
>= > >=3B
>=3B ignoring ../src/m3overrides
>=3B
>=3B =3D=3D>= > >=3B /nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3/m3-win/import-libs = > >done
>=3B
>=3B +++ /nfs/site/home/mnystroe/work/cm3/bin/cm3 -s= > >hip -DROOT=3D/nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3 +++
>= > >=3B --- shipping from AMD64_LINUX ---
>=3B
>=3B =3D=3D>=3B /n= > >fs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3/m3-win/import-libs done >r>>=3B
>=3B =3D=3D package /nfs/site/disks/wdisk.133/mnystroe/cm3-a= > >non-cvs/cm3/m3-libs/m3core =3D=3D
>=3B
>=3B +++ /nfs/site/home/= > >mnystroe/work/cm3/bin/cm3 -build -DROOT=3D/nfs/site/disks/wdisk.133/mnys= > >troe/cm3-anon-cvs/cm3 +++
>=3B --- building in AMD64_LINUX ---
>= > >=3B
>=3B ignoring ../src/m3overrides
>=3B
>=3B new source = > >->=3B compiling RTHooks.i3
>=3B ../src/runtime/common/RTHooks.i3:15:= > > fatal error: *** illegal type: 0x6f=2C at m3cg_lineno 5
>=3B compila= > >tion terminated.
>=3B m3_backend =3D>=3B 1
>=3B m3cc (aka cm3= > >cg) failed compiling: RTHooks.ic
>=3B Assembler messages:
>=3B Ca= > >n't open RTHooks.is for reading: No such file or directory
>=3B new so= > >urce ->=3B compiling RT0.i3
>=3B ../src/runtime/common/RT0.i3:19: fa= > >tal error: *** illegal type: 0x6f=2C at m3cg_lineno 5
>=3B compilatio= > >n terminated.
>=3B m3_backend =3D>=3B 1
>=3B m3cc (aka cm3cg)= > > failed compiling: RT0.ic
>=3B Assembler messages:
>=3B Can't ope= > >n RT0.is for reading: No such file or directory
>=3B new source ->= > >=3B compiling RuntimeError.i3
>=3B ../src/runtime/common/RuntimeError.= > >i3:10: fatal error: *** illegal type: 0x6f=2C at m3cg_lineno 5
>=3B c= > >ompilation terminated.
>=3B m3_backend =3D>=3B 1
>=3B m3cc (a= > >ka cm3cg) failed compiling: RuntimeError.ic
>=3B Assembler messages: >r>>=3B Can't open RuntimeError.is for reading: No such file or directory<= > >br>>=3B new source ->=3B compiling WordRep.i3
>=3B ../src/word/Wor= > >dRep.i3:1: fatal error: *** illegal type: 0x6f=2C at m3cg_lineno 5
>= > >=3B
>=3B I've seen this before but don't remember what the issue is.<= > >br>>=3B
>=3B The compiler is new:
>=3B
>=3B -rwxr-x--- 1= > > mnystroe rrc 9916732 2013-10-14 11:59 /nfs/site/home/mnystroe/work/cm3/bin= > >/cm3
>=3B
>=3B This is on linux/amd64...
>=3B
>=3B >r>>=3B mika writes:
>=3B >=3BMy toolsets are old=2C yes.
>=3B= > > >=3B
>=3B >=3BI tried upgrade.py but you saw that that didn't wor= > >k either.
>=3B >=3B
>=3B >=3BI guess I could go back and re= > >-install from a recent binary image (where
>=3B >=3Bare the most rec= > >ent ones? I only see really old ones on elegosoft...) and
>=3B >=3B= > >build everything from scratch. It's just that all the systems that I
&g= > >t=3B >=3Bhave M3 on are some sort of production systems and I don't want = > >to mess
>=3B >=3Bup the installations unnecessarily... but if it's= > > the only way...
>=3B >=3B
>=3B >=3B Mika
>=3B >= > >=3B
>=3B >=3BJay K writes:
>=3B >=3B>=3B--_461a9835-225f-44= > >8d-96a6-4c651ff66c13_
>=3B >=3B>=3BContent-Type: text/plain=3B cha= > >rset=3D"iso-8859-1"
>=3B >=3B>=3BContent-Transfer-Encoding: quoted= > >-printable
>=3B >=3B>=3B
>=3B >=3B>=3BTarget.i3/m3 look u= > >p to date.
>=3B >=3B>=3BIs your host toolset very old?
>=3B &= > >gt=3B>=3B
>=3B >=3B>=3Bhttps://modula3.elegosoft.com/cgi-bin/cvs= > >web.cgi/cm3/m3-sys/m3middle/src/Ta=3D
>=3B >=3B>=3Brget.i3
>= > >=3B >=3B>=3B
>=3B >=3B>=3BRevision 1.59: download - view: text= > >=3D2C markup=3D2C annotated - select for di=3D
>=3B >=3B>=3Bffs >>>=3B >=3B>=3B=3D0A=3D
>=3B >=3B>=3BSat Jun 19 06:56:32 2010= > > (3 years=3D2C 3 months ago) by jkrell
>=3B >=3B>=3B=3D0A=3D
&= > >gt=3B >=3B>=3BBranches: MAIN
>=3B >=3B>=3B=3D0A=3D
>=3B &= > >gt=3B>=3BDiff to: previous 1.58: preferred=3D2C unified
>=3B >=3B&= > >gt=3B=3D0A=3D
>=3B >=3B>=3BChanges since revision 1.58: +2 -0 line= > >s
>=3B >=3B>=3B=3D0A=3D
>=3B >=3B>=3Badd ARMEL_LINUX with= > > correct jmbuf size/align=3D0A=3D
>=3B >=3B>=3Bguessing about alig= > >nment=3D0A=3D
>=3B >=3B>=3B"ARM" is an older ABI=3D0A=3D
>=3B= > > >=3B>=3B"ARME" is the usual modern ABI=3D0A=3D
>=3B >=3B>=3BL= > > for little endian=3D0A=3D
>=3B >=3B>=3B
>=3B >=3B>=3Bscr= > >ipts/update.py ?
>=3B >=3B>=3B
>=3B >=3B>=3B - Jay
>iv>

> >= > > > >--_b7ef6d52-d09a-4017-8a20-e0fef4593137_-- -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Tue Oct 15 01:11:31 2013 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Mon, 14 Oct 2013 16:11:31 -0700 Subject: [M3devel] M3 on Raspberry Pi cont'd... Message-ID: <20131014231131.0CD631A208E@async.async.caltech.edu> A bit of success... I found that CVS had mangled RTMachine.i3 (why??) and that was causing things to go very wrong. I did manage to upgrade my compiler to the head. ./boot1.py ARMEL_LINUX still leads to the tree error: make: *** No rule to make target `c-family/c-pragma.h', needed by `arm.o'. Stop. ./boot1.py c ARMEL_LINUX results in a new problem: ../src/runtime/common/RTAllocator.m3", line 14: internal_begin_procedure: in_proc; C backend requires M3_FRONT_FLAGS = ["-unfold_nested_procs"] in config file but after fixing that I get a boot archive! Very exciting. What do I do now? I'm trying to run everything through cc -O3 -c This machine is quite slow, maybe it would be nice to have a version of the front end that generates C without comments? :) (I'm not saying it should be the default.) Mika From jay.krell at cornell.edu Tue Oct 15 01:55:44 2013 From: jay.krell at cornell.edu (Jay K) Date: Mon, 14 Oct 2013 23:55:44 +0000 Subject: [M3devel] M3 on Raspberry Pi cont'd... In-Reply-To: <20131014231131.0CD631A208E@async.async.caltech.edu> References: <20131014231131.0CD631A208E@async.async.caltech.edu> Message-ID: > I found that CVS had mangled RTMachine.i3 Maybe you had edited it? Maybe also I deleted it? In general we had way more than necessary target-specific code and files and in general I have significantly reduced it. CVS doesn't deal well with merge conflicts. It leaves merge markers in, and isn't quick to remind of the need to merge. Perforce is vastly superior here. > make: *** No rule to make target `c-family/c-pragma.h', needed by `arm.o'. Stop This is probably easy. I removed the gcc C frontends from the gcc backends. But its "tentacles" could be target-specific, and I didn't try building every target. > C backend requires M3_FRONT_FLAGS I *might* be sitting on a small config file change. I'm trying to flush my CVS checkouts of any pending changes. Either way, not a big deal. The error actually is good, if you know what it is talking about. While everyone sees just cm3 with very few command line options, interally there are many options. If you look at the 3.6 era config files, you'll start to get an idea. Or read through all of our config files -- we do use two of the three options available here. There are three orders the frontend (m3front) is wiling to output nested procedures, presumably: 1 before the functions they are in 2 at the point they are seen in the source 3 after the functions they are in There are advantages and disadvantages to each choice, and various backends might require one choice or the other. The frontend is I believe fairly stateful so it is easy to report things in different orders. #2 requires the backend to maintain more state, since it can see a function in the middle of a function. i.e. it has to merely push what it is working in when it sees begin_procedure, and pop when it sees end_procedure, instead of just maintaining a "current procedure". I believe the gcc backend can handle any order. Though I recall one/some of the orders introduce a psuedo call to the backend "note_procedure_origin" that the serializer between frontend and gcc errors on, deliberately. The integrated backend is very simple and relatively stateless, so I think it can't handle #2. Not that it is so difficult. The C backend was originally very stateless, so also couldn't deal with #2. IF nested functions aren't declared ahead of time -- I don't remember -- then the original C backend required #3. The C backend is now very stateful and I almost finished making it not care about the order here. But I didn't finish that quite yet. It maintains an in-memory array of records corresponding to the M3CG calls. It loops over them multiple times. With an ability to easily filter certain operations. I added the ability to loop over a range (i.e. begin_procedure to end_procedure), which should make this easy, but it doesn't work yet. The ramification is very minor. Look for M3_FRONT in the config files. I thought I already handled it based on the backend mode. For that matter, the "builder" could or C backend initialization could probably make it so. Ideally this configuration knob would go away. One order picked that works and all backends deal with it. As you mention, computers have gotten a lot faster since DEC SRC was designed/implemented. This desire to not require backends to hold an entire "program" in memory is largely antiquated. Mainstream commercial C and C++ compilers regularly do whole program codegen/optimization now and have been doing so for over 10 years. (our mklib.exe actually is in the way of using Visual C++'s whole program codegen..it reads .obj files.., but given our historical code quality being pretty poor anyway, and nobody noticing, I'm not too worried..) > but after fixing that I get a boot archive! Very exciting. What do I do now? One of two options: 1) Less usual: If you have a cross C compiler/linker, ignore the archive, cd into the directory it was built from, edit the Makefile, make I had built ARM_DARWIN this way, and the Makefile for that target assumes it, just the few lines at the top that set the C compiler name/flags. 2) Usual: If you don't have a cross C compiler/linker, and you do have a native C compiler/linker, copy the boot archive (or the directory it is built from) to the target machine, extract it, cd into it, make, possibly first editing the Makefile (you know, we don't use autoconf/automake, and a lot of what we do is duplicating them..) If that succeeds, you will have cm3. On the new target machine: Run it If it says "can't find cm3.cfg", that is success so far. If it doesn't say that, or crashes, debug it. mkdir -p /usr/local/cm3/bin cp cm3 /usr/local/cm3/bin cd somewhere (again, on the new target machine) cvs checkout scripts/python/boot2.py that will build the entire system starting from just the cm3 (and a native C compiler/linker) Document your experience better than I have and what needs to change. > This machine is quite slow, maybe it would be nice to have a version of the front end > that generates C without comments? :) (I'm not saying it should be the default.) Yeah..there are some globals controlling it. It is a tough tradeoff performance vs. debuggability...granted, the comments are gibberish to most people. But I like to have the debuggability... Going through C is also noticably slower. That is a downside to the ease of development and portability it brings. One thing I'd like to do is batch it up so we pass all the C files to the compiler at once. At least the out of date ones. I know that is much faster with the Microsoft C compiler -- I even changed the boot archive to work that way -- I think for all targets actually. - Jay > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: M3 on Raspberry Pi cont'd... > Date: Mon, 14 Oct 2013 16:11:31 -0700 > From: mika at async.caltech.edu > > > A bit of success... I found that CVS had mangled RTMachine.i3 (why??) and that was causing things to go very wrong. > > I did manage to upgrade my compiler to the head. > > ./boot1.py ARMEL_LINUX still leads to the tree error: > > make: *** No rule to make target `c-family/c-pragma.h', needed by `arm.o'. Stop. > > ./boot1.py c ARMEL_LINUX results in a new problem: > > ../src/runtime/common/RTAllocator.m3", line 14: internal_begin_procedure: in_proc; C backend requires M3_FRONT_FLAGS = ["-unfold_nested_procs"] in config file > > but after fixing that I get a boot archive! Very exciting. What do I do now? I'm trying to run everything through cc -O3 -c > > This machine is quite slow, maybe it would be nice to have a version of the front end that generates C without comments? :) (I'm not saying it should be the default.) > > Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Tue Oct 15 03:37:45 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Mon, 14 Oct 2013 20:37:45 -0500 Subject: [M3devel] Version number in m3linker Message-ID: <525C9C69.7060208@lcwb.coop> m3linker, in its private format link info file, uses the version string: "M3 v4.2". Does anybody know if this is intended to be m3linker's own private version numbering, or is it supposed to be the same as we get from "cm3 -version"? If so, it's way out of date. WARNING: Just editing it will produce a tricky bootstrap problem, so don't do it gratuitously. I happen to need to change it for another reason. From jay.krell at cornell.edu Tue Oct 15 04:25:09 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 15 Oct 2013 02:25:09 +0000 Subject: [M3devel] M3 on Raspberry Pi cont'd... In-Reply-To: References: <20131014231131.0CD631A208E@async.async.caltech.edu>, Message-ID: Mika, please double check this in your ARM machine: This is I386_DARWIN: jbook2:config jay$ cc jmpbuf.c? ./a.out jbook2:config jay$ ./a.out jmpbuf size: 72 sigjmpbuf size: 76 alignment: 4 4 jbook2:config jay$ pwd /Users/jay/dev2/cm3/scripts/config It looks like raspberry pi might use an ABI variant "ARMHF" HF for hard float, and I wouldn't be surprised if it uses a larger jmpbuf than m3-sys/m3middle/src/Target.m3 says. If so, I'd favor just growing the jmpbuf for ARMEL_LINUX and NOT introducing ARMHF_LINUX or such. All the targets are almost identical, and we have so many, they mostly confuse people. And this jmpbuf stuff will go away hopefully soon. ?- Jay ________________________________ > From: jay.krell at cornell.edu > To: mika at async.caltech.edu > Date: Mon, 14 Oct 2013 23:55:44 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] M3 on Raspberry Pi cont'd... > >> I found that CVS had mangled RTMachine.i3 > > > Maybe you had edited it? > Maybe also I deleted it? In general we had way more than necessary > target-specific code and files and in general I have significantly > reduced it. > CVS doesn't deal well with merge conflicts. It leaves merge markers in, and > isn't quick to remind of the need to merge. Perforce is vastly > superior here. > > > >> make: *** No rule to make target `c-family/c-pragma.h', needed by > `arm.o'. Stop > > > This is probably easy. > I removed the gcc C frontends from the gcc backends. > But its "tentacles" could be target-specific, and I didn't try building > every target. > > >> C backend requires M3_FRONT_FLAGS > > > I *might* be sitting on a small config file change. > I'm trying to flush my CVS checkouts of any pending changes. > Either way, not a big deal. > The error actually is good, if you know what it is talking about. > > > While everyone sees just cm3 with very few command line options, interally > there are many options. If you look at the 3.6 era config files, you'll > start to get an idea. Or read through all of our config files -- we do > use two of the three options available here. > > > There are three orders the frontend (m3front) is wiling to output > nested procedures, > presumably: > 1 before the functions they are in > 2 at the point they are seen in the source > 3 after the functions they are in > > > There are advantages and disadvantages to each choice, and various backends > might require one choice or the other. The frontend is I believe > fairly stateful > so it is easy to report things in different orders. > > > #2 requires the backend to maintain more state, since it can see a function > in the middle of a function. i.e. it has to merely push what it is > working in > when it sees begin_procedure, and pop when it sees end_procedure, > instead of > just maintaining a "current procedure". > > > I believe the gcc backend can handle any order. > > > Though I recall one/some of the orders introduce a psuedo call to the > backend "note_procedure_origin" > that the serializer between frontend and gcc errors on, deliberately. > > > > The integrated backend is very simple and relatively stateless, so I > think it > can't handle #2. Not that it is so difficult. > > > The C backend was originally very stateless, so also couldn't deal with #2. > IF nested functions aren't declared ahead of time -- I don't remember > -- then > the original C backend required #3. > > > The C backend is now very stateful and I almost finished making it > not care about the order here. > But I didn't finish that quite yet. > It maintains an in-memory array of records corresponding to the M3CG calls. > It loops over them multiple times. With an ability to easily filter > certain operations. > I added the ability to loop over a range (i.e. begin_procedure to > end_procedure), > which should make this easy, but it doesn't work yet. > > > > The ramification is very minor. > Look for M3_FRONT in the config files. > I thought I already handled it based on the backend mode. > For that matter, the "builder" could or C backend initialization could > probably make it so. > > > Ideally this configuration knob would go away. One order picked that > works and all backends > deal with it. > > > > As you mention, computers have gotten a lot faster since DEC SRC was > designed/implemented. > This desire to not require backends to hold an entire "program" in > memory is largely antiquated. > Mainstream commercial C and C++ compilers regularly do whole program > codegen/optimization now and have been > doing so for over 10 years. > > > (our mklib.exe actually is in the way of using Visual C++'s whole > program codegen..it reads .obj files.., > but given our historical code quality being pretty poor anyway, and > nobody noticing, I'm not too worried..) > > > >> but after fixing that I get a boot archive! Very exciting. What do > I do now? > > > One of two options: > > 1) Less usual: If you have a cross C compiler/linker, ignore the > archive, cd into the directory > it was built from, edit the Makefile, make > I had built ARM_DARWIN this way, and the Makefile for that target > assumes it, just the few > lines at the top that set the C compiler name/flags. > > > 2) Usual: If you don't have a cross C compiler/linker, and you do have > a native C compiler/linker, > copy the boot archive (or the directory it is built from) to the > target machine, extract it, cd into it, make, > possibly first editing the Makefile (you know, we don't use > autoconf/automake, and a lot > of what we do is duplicating them..) > > > If that succeeds, you will have cm3. > On the new target machine: > Run it > If it says "can't find cm3.cfg", that is success so far. > If it doesn't say that, or crashes, debug it. > mkdir -p /usr/local/cm3/bin > cp cm3 /usr/local/cm3/bin > cd somewhere (again, on the new target machine) > cvs checkout > scripts/python/boot2.py that will build the entire system starting > from just the cm3 (and a native C compiler/linker) > > > Document your experience better than I have and what needs to change. > > >> This machine is quite slow, maybe it would be nice to have a version > of the front end >> that generates C without comments? :) (I'm not saying it should be > the default.) > > > Yeah..there are some globals controlling it. > It is a tough tradeoff performance vs. debuggability...granted, the > comments are gibberish > to most people. But I like to have the debuggability... > > > > Going through C is also noticably slower. That is a downside to the > ease of development > and portability it brings. > One thing I'd like to do is batch it up so we pass all the C files to > the compiler at once. > At least the out of date ones. I know that is much faster with the > Microsoft C compiler -- > I even changed the boot archive to work that way -- I think for all > targets actually. > > > > - Jay > > > > >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: M3 on Raspberry Pi cont'd... >> Date: Mon, 14 Oct 2013 16:11:31 -0700 >> From: mika at async.caltech.edu >> >> >> A bit of success... I found that CVS had mangled RTMachine.i3 (why??) > and that was causing things to go very wrong. >> >> I did manage to upgrade my compiler to the head. >> >> ./boot1.py ARMEL_LINUX still leads to the tree error: >> >> make: *** No rule to make target `c-family/c-pragma.h', needed by > `arm.o'. Stop. >> >> ./boot1.py c ARMEL_LINUX results in a new problem: >> >> ../src/runtime/common/RTAllocator.m3", line 14: > internal_begin_procedure: in_proc; C backend requires M3_FRONT_FLAGS = > ["-unfold_nested_procs"] in config file >> >> but after fixing that I get a boot archive! Very exciting. What do I > do now? I'm trying to run everything through cc -O3 -c >> >> This machine is quite slow, maybe it would be nice to have a version > of the front end that generates C without comments? :) (I'm not saying > it should be the default.) >> >> Mika From jay.krell at cornell.edu Tue Oct 15 08:27:24 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 15 Oct 2013 06:27:24 +0000 Subject: [M3devel] M3 on Raspberry Pi cont'd... In-Reply-To: References: <20131014231131.0CD631A208E@async.async.caltech.edu>, Message-ID: The cm3cg compile error should be fixed now. I did not test this, and I still want to not use this backend. Don't you have this in cm3cfg.common? M3_FRONT_FLAGS = [ ] % --- internal configuration options passed directly to the Modula-3 front-end if equal(M3_BACKEND_MODE, "0") or equal(M3_BACKEND_MODE, "1") ? ? ? ? or equal(M3_BACKEND_MODE, "IntegratedObject") ? ? ? ? or equal(M3_BACKEND_MODE, "IntegratedAssembly") ? ? ? ? or equal(M3_BACKEND_MODE, "IntegratedC") ? ? ? ? or equal(M3_BACKEND_MODE, "C") ? ? ? ? or USE_C_BACKEND_VIA_M3CGCAT ? ? % M3_FRONT_FLAGS += ["-unfold_nested_procs"] ? ? % M3_FRONT_FLAGS += ["-check_procs" ] ? ? M3_FRONT_FLAGS = ["-unfold_nested_procs", "-check_procs" ] end ?- Jay ________________________________ > From: jay.krell at cornell.edu > To: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: RE: M3 on Raspberry Pi cont'd... > Date: Mon, 14 Oct 2013 23:55:44 +0000 > >> I found that CVS had mangled RTMachine.i3 > > > Maybe you had edited it? > Maybe also I deleted it? In general we had way more than necessary > target-specific code and files and in general I have significantly > reduced it. > CVS doesn't deal well with merge conflicts. It leaves merge markers in, and > isn't quick to remind of the need to merge. Perforce is vastly > superior here. > > > >> make: *** No rule to make target `c-family/c-pragma.h', needed by > `arm.o'. Stop > > > This is probably easy. > I removed the gcc C frontends from the gcc backends. > But its "tentacles" could be target-specific, and I didn't try building > every target. > > >> C backend requires M3_FRONT_FLAGS > > > I *might* be sitting on a small config file change. > I'm trying to flush my CVS checkouts of any pending changes. > Either way, not a big deal. > The error actually is good, if you know what it is talking about. > > > While everyone sees just cm3 with very few command line options, interally > there are many options. If you look at the 3.6 era config files, you'll > start to get an idea. Or read through all of our config files -- we do > use two of the three options available here. > > > There are three orders the frontend (m3front) is wiling to output > nested procedures, > presumably: > 1 before the functions they are in > 2 at the point they are seen in the source > 3 after the functions they are in > > > There are advantages and disadvantages to each choice, and various backends > might require one choice or the other. The frontend is I believe > fairly stateful > so it is easy to report things in different orders. > > > #2 requires the backend to maintain more state, since it can see a function > in the middle of a function. i.e. it has to merely push what it is > working in > when it sees begin_procedure, and pop when it sees end_procedure, > instead of > just maintaining a "current procedure". > > > I believe the gcc backend can handle any order. > > > Though I recall one/some of the orders introduce a psuedo call to the > backend "note_procedure_origin" > that the serializer between frontend and gcc errors on, deliberately. > > > > The integrated backend is very simple and relatively stateless, so I > think it > can't handle #2. Not that it is so difficult. > > > The C backend was originally very stateless, so also couldn't deal with #2. > IF nested functions aren't declared ahead of time -- I don't remember > -- then > the original C backend required #3. > > > The C backend is now very stateful and I almost finished making it > not care about the order here. > But I didn't finish that quite yet. > It maintains an in-memory array of records corresponding to the M3CG calls. > It loops over them multiple times. With an ability to easily filter > certain operations. > I added the ability to loop over a range (i.e. begin_procedure to > end_procedure), > which should make this easy, but it doesn't work yet. > > > > The ramification is very minor. > Look for M3_FRONT in the config files. > I thought I already handled it based on the backend mode. > For that matter, the "builder" could or C backend initialization could > probably make it so. > > > Ideally this configuration knob would go away. One order picked that > works and all backends > deal with it. > > > > As you mention, computers have gotten a lot faster since DEC SRC was > designed/implemented. > This desire to not require backends to hold an entire "program" in > memory is largely antiquated. > Mainstream commercial C and C++ compilers regularly do whole program > codegen/optimization now and have been > doing so for over 10 years. > > > (our mklib.exe actually is in the way of using Visual C++'s whole > program codegen..it reads .obj files.., > but given our historical code quality being pretty poor anyway, and > nobody noticing, I'm not too worried..) > > > >> but after fixing that I get a boot archive! Very exciting. What do > I do now? > > > One of two options: > > 1) Less usual: If you have a cross C compiler/linker, ignore the > archive, cd into the directory > it was built from, edit the Makefile, make > I had built ARM_DARWIN this way, and the Makefile for that target > assumes it, just the few > lines at the top that set the C compiler name/flags. > > > 2) Usual: If you don't have a cross C compiler/linker, and you do have > a native C compiler/linker, > copy the boot archive (or the directory it is built from) to the > target machine, extract it, cd into it, make, > possibly first editing the Makefile (you know, we don't use > autoconf/automake, and a lot > of what we do is duplicating them..) > > > If that succeeds, you will have cm3. > On the new target machine: > Run it > If it says "can't find cm3.cfg", that is success so far. > If it doesn't say that, or crashes, debug it. > mkdir -p /usr/local/cm3/bin > cp cm3 /usr/local/cm3/bin > cd somewhere (again, on the new target machine) > cvs checkout > scripts/python/boot2.py that will build the entire system starting > from just the cm3 (and a native C compiler/linker) > > > Document your experience better than I have and what needs to change. > > >> This machine is quite slow, maybe it would be nice to have a version > of the front end >> that generates C without comments? :) (I'm not saying it should be > the default.) > > > Yeah..there are some globals controlling it. > It is a tough tradeoff performance vs. debuggability...granted, the > comments are gibberish > to most people. But I like to have the debuggability... > > > > Going through C is also noticably slower. That is a downside to the > ease of development > and portability it brings. > One thing I'd like to do is batch it up so we pass all the C files to > the compiler at once. > At least the out of date ones. I know that is much faster with the > Microsoft C compiler -- > I even changed the boot archive to work that way -- I think for all > targets actually. > > > > - Jay > > > > >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: M3 on Raspberry Pi cont'd... >> Date: Mon, 14 Oct 2013 16:11:31 -0700 >> From: mika at async.caltech.edu >> >> >> A bit of success... I found that CVS had mangled RTMachine.i3 (why??) > and that was causing things to go very wrong. >> >> I did manage to upgrade my compiler to the head. >> >> ./boot1.py ARMEL_LINUX still leads to the tree error: >> >> make: *** No rule to make target `c-family/c-pragma.h', needed by > `arm.o'. Stop. >> >> ./boot1.py c ARMEL_LINUX results in a new problem: >> >> ../src/runtime/common/RTAllocator.m3", line 14: > internal_begin_procedure: in_proc; C backend requires M3_FRONT_FLAGS = > ["-unfold_nested_procs"] in config file >> >> but after fixing that I get a boot archive! Very exciting. What do I > do now? I'm trying to run everything through cc -O3 -c >> >> This machine is quite slow, maybe it would be nice to have a version > of the front end that generates C without comments? :) (I'm not saying > it should be the default.) >> >> Mika From mika at async.caltech.edu Tue Oct 15 16:39:46 2013 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Tue, 15 Oct 2013 07:39:46 -0700 Subject: [M3devel] M3 on Raspberry Pi cont'd... In-Reply-To: References: <20131014231131.0CD631A208E@async.async.caltech.edu>,

Message-ID: <20131015143946.0AABE1A2091@async.async.caltech.edu> Here are some notes on my experience so far. -- After finally figuring out what was wrong with my compiler (no I can't imagine I edited RTMachine, the two versions looked completely incompatible besides), I was able to build the bootstrap .tgz -- I had to add that flag we discussed yesterday -unfold_nested_procs -- I rsynced it to the Pi and was able to compile cc -c *.o / run make -- I had to edit the Makefile because it set cc to something other than cc, viz., arm-linux-gnueabi-gcc -- the Makefile tries to build two executables in a slightly confused fashion: cm3 and mklib. You get multiply defined labels for main that way. Basically it has multiple targets but seems to smush them together in one big mess somehow. Easy to hack out. -- Resulting cm3 links but segfaults immediately, I think it's because of the below: raspberrypi:/big/home2/mika/2/cm3-cvs/cm3/scripts/config# cc jmpbuf.c raspberrypi:/big/home2/mika/2/cm3-cvs/cm3/scripts/config# ./a.out jmpbuf size: 392 sigjmpbuf size: 392 alignment: 8 8 raspberrypi:/big/home2/mika/2/cm3-cvs/cm3/scripts/config# uname -a Linux raspberrypi 3.6.11+ #538 PREEMPT Fri Aug 30 20:42:08 BST 2013 armv6l GNU/Linux Will edit stuff and re-run. Mika Jay K writes: >Mika=2C please double check this in your ARM machine:=0A= >=0A= >=0A= >This is I386_DARWIN:=0A= >jbook2:config jay$ cc jmpbuf.c=A0=0A= >./a.out=0A= >jbook2:config jay$ ./a.out=0A= >jmpbuf size: 72=0A= >sigjmpbuf size: 76=0A= >alignment: 4 4=0A= >jbook2:config jay$ pwd=0A= >/Users/jay/dev2/cm3/scripts/config=0A= >=0A= >=0A= >It looks like raspberry pi might use an ABI variant "ARMHF" HF for hard flo= >at=2C=0A= >and I wouldn't be surprised if it uses a larger jmpbuf than m3-sys/m3middle= >/src/Target.m3 says.=0A= >=0A= >=0A= >If so=2C I'd favor just growing the jmpbuf for ARMEL_LINUX and NOT introduc= >ing ARMHF_LINUX or such.=0A= >All the targets are almost identical=2C and we have so many=2C they mostly = >confuse people.=0A= >And this jmpbuf stuff will go away hopefully soon.=0A= >=0A= >=0A= >=A0- Jay=0A= >=0A= >________________________________=0A= >> From: jay.krell at cornell.edu =0A= >> To: mika at async.caltech.edu =0A= >> Date: Mon=2C 14 Oct 2013 23:55:44 +0000 =0A= >> CC: m3devel at elegosoft.com =0A= >> Subject: Re: [M3devel] M3 on Raspberry Pi cont'd... =0A= >> =0A= >>> I found that CVS had mangled RTMachine.i3 =0A= >> =0A= >> =0A= >> Maybe you had edited it? =0A= >> Maybe also I deleted it? In general we had way more than necessary =0A= >> target-specific code and files and in general I have significantly =0A= >> reduced it. =0A= >> CVS doesn't deal well with merge conflicts. It leaves merge markers in=2C= > and =0A= >> isn't quick to remind of the need to merge. Perforce is vastly =0A= >> superior here. =0A= >> =0A= >> =0A= >> =0A= >>> make: *** No rule to make target `c-family/c-pragma.h'=2C needed by =0A= >> `arm.o'. Stop =0A= >> =0A= >> =0A= >> This is probably easy. =0A= >> I removed the gcc C frontends from the gcc backends. =0A= >> But its "tentacles" could be target-specific=2C and I didn't try building= > =0A= >> every target. =0A= >> =0A= >> =0A= >>> C backend requires M3_FRONT_FLAGS =0A= >> =0A= >> =0A= >> I *might* be sitting on a small config file change. =0A= >> I'm trying to flush my CVS checkouts of any pending changes. =0A= >> Either way=2C not a big deal. =0A= >> The error actually is good=2C if you know what it is talking about. =0A= >> =0A= >> =0A= >> While everyone sees just cm3 with very few command line options=2C intera= >lly =0A= >> there are many options. If you look at the 3.6 era config files=2C you'll= > =0A= >> start to get an idea. Or read through all of our config files -- we do = >=0A= >> use two of the three options available here. =0A= >> =0A= >> =0A= >> There are three orders the frontend (m3front) is wiling to output =0A= >> nested procedures=2C =0A= >> presumably: =0A= >> 1 before the functions they are in =0A= >> 2 at the point they are seen in the source =0A= >> 3 after the functions they are in =0A= >> =0A= >> =0A= >> There are advantages and disadvantages to each choice=2C and various back= >ends =0A= >> might require one choice or the other. The frontend is I believe =0A= >> fairly stateful =0A= >> so it is easy to report things in different orders. =0A= >> =0A= >> =0A= >> #2 requires the backend to maintain more state=2C since it can see a func= >tion =0A= >> in the middle of a function. i.e. it has to merely push what it is =0A= >> working in =0A= >> when it sees begin_procedure=2C and pop when it sees end_procedure=2C =0A= >> instead of =0A= >> just maintaining a "current procedure". =0A= >> =0A= >> =0A= >> I believe the gcc backend can handle any order. =0A= >> =0A= >> =0A= >> Though I recall one/some of the orders introduce a psuedo call to the =0A= >> backend "note_procedure_origin" =0A= >> that the serializer between frontend and gcc errors on=2C deliberately. = >=0A= >> =0A= >> =0A= >> =0A= >> The integrated backend is very simple and relatively stateless=2C so I = >=0A= >> think it =0A= >> can't handle #2. Not that it is so difficult. =0A= >> =0A= >> =0A= >> The C backend was originally very stateless=2C so also couldn't deal with= > #2. =0A= >> IF nested functions aren't declared ahead of time -- I don't remember =0A= >> -- then =0A= >> the original C backend required #3. =0A= >> =0A= >> =0A= >> The C backend is now very stateful and I almost finished making it =0A= >> not care about the order here. =0A= >> But I didn't finish that quite yet. =0A= >> It maintains an in-memory array of records corresponding to the M3CG call= >s. =0A= >> It loops over them multiple times. With an ability to easily filter =0A= >> certain operations. =0A= >> I added the ability to loop over a range (i.e. begin_procedure to =0A= >> end_procedure)=2C =0A= >> which should make this easy=2C but it doesn't work yet. =0A= >> =0A= >> =0A= >> =0A= >> The ramification is very minor. =0A= >> Look for M3_FRONT in the config files. =0A= >> I thought I already handled it based on the backend mode. =0A= >> For that matter=2C the "builder" could or C backend initialization could = >=0A= >> probably make it so. =0A= >> =0A= >> =0A= >> Ideally this configuration knob would go away. One order picked that =0A= >> works and all backends =0A= >> deal with it. =0A= >> =0A= >> =0A= >> =0A= >> As you mention=2C computers have gotten a lot faster since DEC SRC was = >=0A= >> designed/implemented. =0A= >> This desire to not require backends to hold an entire "program" in =0A= >> memory is largely antiquated. =0A= >> Mainstream commercial C and C++ compilers regularly do whole program =0A= >> codegen/optimization now and have been =0A= >> doing so for over 10 years. =0A= >> =0A= >> =0A= >> (our mklib.exe actually is in the way of using Visual C++'s whole =0A= >> program codegen..it reads .obj files..=2C =0A= >> but given our historical code quality being pretty poor anyway=2C and =0A= >> nobody noticing=2C I'm not too worried..) =0A= >> =0A= >> =0A= >> =0A= >>> but after fixing that I get a boot archive! Very exciting. What do =0A= >> I do now? =0A= >> =0A= >> =0A= >> One of two options: =0A= >> =0A= >> 1) Less usual: If you have a cross C compiler/linker=2C ignore the =0A= >> archive=2C cd into the directory =0A= >> it was built from=2C edit the Makefile=2C make =0A= >> I had built ARM_DARWIN this way=2C and the Makefile for that target =0A= >> assumes it=2C just the few =0A= >> lines at the top that set the C compiler name/flags. =0A= >> =0A= >> =0A= >> 2) Usual: If you don't have a cross C compiler/linker=2C and you do have = >=0A= >> a native C compiler/linker=2C =0A= >> copy the boot archive (or the directory it is built from) to the =0A= >> target machine=2C extract it=2C cd into it=2C make=2C =0A= >> possibly first editing the Makefile (you know=2C we don't use =0A= >> autoconf/automake=2C and a lot =0A= >> of what we do is duplicating them..) =0A= >> =0A= >> =0A= >> If that succeeds=2C you will have cm3. =0A= >> On the new target machine: =0A= >> Run it =0A= >> If it says "can't find cm3.cfg"=2C that is success so far. =0A= >> If it doesn't say that=2C or crashes=2C debug it. =0A= >> mkdir -p /usr/local/cm3/bin =0A= >> cp cm3 /usr/local/cm3/bin =0A= >> cd somewhere (again=2C on the new target machine) =0A= >> cvs checkout =0A= >> scripts/python/boot2.py that will build the entire system starting =0A= >> from just the cm3 (and a native C compiler/linker) =0A= >> =0A= >> =0A= >> Document your experience better than I have and what needs to change. =0A= >> =0A= >> =0A= >>> This machine is quite slow=2C maybe it would be nice to have a version = >=0A= >> of the front end =0A= >>> that generates C without comments? :) (I'm not saying it should be =0A= >> the default.) =0A= >> =0A= >> =0A= >> Yeah..there are some globals controlling it. =0A= >> It is a tough tradeoff performance vs. debuggability...granted=2C the =0A= >> comments are gibberish =0A= >> to most people. But I like to have the debuggability... =0A= >> =0A= >> =0A= >> =0A= >> Going through C is also noticably slower. That is a downside to the =0A= >> ease of development =0A= >> and portability it brings. =0A= >> One thing I'd like to do is batch it up so we pass all the C files to =0A= >> the compiler at once. =0A= >> At least the out of date ones. I know that is much faster with the =0A= >> Microsoft C compiler -- =0A= >> I even changed the boot archive to work that way -- I think for all =0A= >> targets actually. =0A= >> =0A= >> =0A= >> =0A= >> - Jay =0A= >> =0A= >> =0A= >> =0A= >> =0A= >>> To: jay.krell at cornell.edu =0A= >>> CC: m3devel at elegosoft.com =0A= >>> Subject: M3 on Raspberry Pi cont'd... =0A= >>> Date: Mon=2C 14 Oct 2013 16:11:31 -0700 =0A= >>> From: mika at async.caltech.edu =0A= >>> =0A= >>> =0A= >>> A bit of success... I found that CVS had mangled RTMachine.i3 (why??) = >=0A= >> and that was causing things to go very wrong. =0A= >>> =0A= >>> I did manage to upgrade my compiler to the head. =0A= >>> =0A= >>> ./boot1.py ARMEL_LINUX still leads to the tree error: =0A= >>> =0A= >>> make: *** No rule to make target `c-family/c-pragma.h'=2C needed by =0A= >> `arm.o'. Stop. =0A= >>> =0A= >>> ./boot1.py c ARMEL_LINUX results in a new problem: =0A= >>> =0A= >>> ../src/runtime/common/RTAllocator.m3"=2C line 14: =0A= >> internal_begin_procedure: in_proc=3B C backend requires M3_FRONT_FLAGS = >=3D =0A= >> ["-unfold_nested_procs"] in config file =0A= >>> =0A= >>> but after fixing that I get a boot archive! Very exciting. What do I =0A= >> do now? I'm trying to run everything through cc -O3 -c =0A= >>> =0A= >>> This machine is quite slow=2C maybe it would be nice to have a version = >=0A= >> of the front end that generates C without comments? :) (I'm not saying = >=0A= >> it should be the default.) =0A= >>> =0A= >>> Mika = From jay.krell at cornell.edu Tue Oct 15 18:08:39 2013 From: jay.krell at cornell.edu (Jay) Date: Tue, 15 Oct 2013 09:08:39 -0700 Subject: [M3devel] M3 on Raspberry Pi cont'd... In-Reply-To: <20131015143946.0AABE1A2091@async.async.caltech.edu> References: <20131014231131.0CD631A208E@async.async.caltech.edu>

<20131015143946.0AABE1A2091@async.async.caltech.edu> Message-ID: <82A022A1-6536-450B-97FB-CCA101BD3EBB@gmail.com> Cool. Makefile/mklib: recent change for amd64_nt. It worked there. I will look. The intent was "a bunch of objs plus mklibmain, a bunch of objs plus cm3main". Ultimately, for packaging/distribution, this should probably be fleshed out 1 to build the entire system 2 to use dynamic linking. And maybe automake/autoconf/libtool or cmake. arm-gcc: this is specific to arm or arm_darwin and was trying to cross compile. I did cross compile cm3 for arm_darwin. Generally there is a gcc with a name "like" this, but the exact name is very target specific. Jmpbuf: edit m3-sys/m3middle/src/Target.m3 and update.py (overkill -- rebuild m3middle, cm3, and copy the cm3 to install it; cm3 is special and "ship" doesn't install it) I'd like to eliminate knowing the jmpbuf size very soon. - Jay On Oct 15, 2013, at 7:39 AM, wrote: > Here are some notes on my experience so far. > > -- After finally figuring out what was wrong with my compiler (no I > can't imagine I edited RTMachine, the two versions looked completely > incompatible besides), I was able to build the bootstrap .tgz > > -- I had to add that flag we discussed yesterday -unfold_nested_procs > > -- I rsynced it to the Pi and was able to compile cc -c *.o / run make > > -- I had to edit the Makefile because it set cc to something other than > cc, viz., arm-linux-gnueabi-gcc > > -- the Makefile tries to build two executables in a slightly confused > fashion: cm3 and mklib. You get multiply defined labels for main that way. > Basically it has multiple targets but seems to smush them together in one big > mess somehow. Easy to hack out. > > -- Resulting cm3 links but segfaults immediately, I think it's because of the > below: > > raspberrypi:/big/home2/mika/2/cm3-cvs/cm3/scripts/config# cc jmpbuf.c > raspberrypi:/big/home2/mika/2/cm3-cvs/cm3/scripts/config# ./a.out > jmpbuf size: 392 > sigjmpbuf size: 392 > alignment: 8 8 > raspberrypi:/big/home2/mika/2/cm3-cvs/cm3/scripts/config# uname -a > Linux raspberrypi 3.6.11+ #538 PREEMPT Fri Aug 30 20:42:08 BST 2013 armv6l GNU/Linux > > Will edit stuff and re-run. > > Mika > > > Jay K writes: >> Mika=2C please double check this in your ARM machine:=0A= >> =0A= >> =0A= >> This is I386_DARWIN:=0A= >> jbook2:config jay$ cc jmpbuf.c=A0=0A= >> ./a.out=0A= >> jbook2:config jay$ ./a.out=0A= >> jmpbuf size: 72=0A= >> sigjmpbuf size: 76=0A= >> alignment: 4 4=0A= >> jbook2:config jay$ pwd=0A= >> /Users/jay/dev2/cm3/scripts/config=0A= >> =0A= >> =0A= >> It looks like raspberry pi might use an ABI variant "ARMHF" HF for hard flo= >> at=2C=0A= >> and I wouldn't be surprised if it uses a larger jmpbuf than m3-sys/m3middle= >> /src/Target.m3 says.=0A= >> =0A= >> =0A= >> If so=2C I'd favor just growing the jmpbuf for ARMEL_LINUX and NOT introduc= >> ing ARMHF_LINUX or such.=0A= >> All the targets are almost identical=2C and we have so many=2C they mostly = >> confuse people.=0A= >> And this jmpbuf stuff will go away hopefully soon.=0A= >> =0A= >> =0A= >> =A0- Jay=0A= >> =0A= >> ________________________________=0A= >>> From: jay.krell at cornell.edu =0A= >>> To: mika at async.caltech.edu =0A= >>> Date: Mon=2C 14 Oct 2013 23:55:44 +0000 =0A= >>> CC: m3devel at elegosoft.com =0A= >>> Subject: Re: [M3devel] M3 on Raspberry Pi cont'd... =0A= >>> =0A= >>>> I found that CVS had mangled RTMachine.i3 =0A= >>> =0A= >>> =0A= >>> Maybe you had edited it? =0A= >>> Maybe also I deleted it? In general we had way more than necessary =0A= >>> target-specific code and files and in general I have significantly =0A= >>> reduced it. =0A= >>> CVS doesn't deal well with merge conflicts. It leaves merge markers in=2C= >> and =0A= >>> isn't quick to remind of the need to merge. Perforce is vastly =0A= >>> superior here. =0A= >>> =0A= >>> =0A= >>> =0A= >>>> make: *** No rule to make target `c-family/c-pragma.h'=2C needed by =0A= >>> `arm.o'. Stop =0A= >>> =0A= >>> =0A= >>> This is probably easy. =0A= >>> I removed the gcc C frontends from the gcc backends. =0A= >>> But its "tentacles" could be target-specific=2C and I didn't try building= >> =0A= >>> every target. =0A= >>> =0A= >>> =0A= >>>> C backend requires M3_FRONT_FLAGS =0A= >>> =0A= >>> =0A= >>> I *might* be sitting on a small config file change. =0A= >>> I'm trying to flush my CVS checkouts of any pending changes. =0A= >>> Either way=2C not a big deal. =0A= >>> The error actually is good=2C if you know what it is talking about. =0A= >>> =0A= >>> =0A= >>> While everyone sees just cm3 with very few command line options=2C intera= >> lly =0A= >>> there are many options. If you look at the 3.6 era config files=2C you'll= >> =0A= >>> start to get an idea. Or read through all of our config files -- we do = >> =0A= >>> use two of the three options available here. =0A= >>> =0A= >>> =0A= >>> There are three orders the frontend (m3front) is wiling to output =0A= >>> nested procedures=2C =0A= >>> presumably: =0A= >>> 1 before the functions they are in =0A= >>> 2 at the point they are seen in the source =0A= >>> 3 after the functions they are in =0A= >>> =0A= >>> =0A= >>> There are advantages and disadvantages to each choice=2C and various back= >> ends =0A= >>> might require one choice or the other. The frontend is I believe =0A= >>> fairly stateful =0A= >>> so it is easy to report things in different orders. =0A= >>> =0A= >>> =0A= >>> #2 requires the backend to maintain more state=2C since it can see a func= >> tion =0A= >>> in the middle of a function. i.e. it has to merely push what it is =0A= >>> working in =0A= >>> when it sees begin_procedure=2C and pop when it sees end_procedure=2C =0A= >>> instead of =0A= >>> just maintaining a "current procedure". =0A= >>> =0A= >>> =0A= >>> I believe the gcc backend can handle any order. =0A= >>> =0A= >>> =0A= >>> Though I recall one/some of the orders introduce a psuedo call to the =0A= >>> backend "note_procedure_origin" =0A= >>> that the serializer between frontend and gcc errors on=2C deliberately. = >> =0A= >>> =0A= >>> =0A= >>> =0A= >>> The integrated backend is very simple and relatively stateless=2C so I = >> =0A= >>> think it =0A= >>> can't handle #2. Not that it is so difficult. =0A= >>> =0A= >>> =0A= >>> The C backend was originally very stateless=2C so also couldn't deal with= >> #2. =0A= >>> IF nested functions aren't declared ahead of time -- I don't remember =0A= >>> -- then =0A= >>> the original C backend required #3. =0A= >>> =0A= >>> =0A= >>> The C backend is now very stateful and I almost finished making it =0A= >>> not care about the order here. =0A= >>> But I didn't finish that quite yet. =0A= >>> It maintains an in-memory array of records corresponding to the M3CG call= >> s. =0A= >>> It loops over them multiple times. With an ability to easily filter =0A= >>> certain operations. =0A= >>> I added the ability to loop over a range (i.e. begin_procedure to =0A= >>> end_procedure)=2C =0A= >>> which should make this easy=2C but it doesn't work yet. =0A= >>> =0A= >>> =0A= >>> =0A= >>> The ramification is very minor. =0A= >>> Look for M3_FRONT in the config files. =0A= >>> I thought I already handled it based on the backend mode. =0A= >>> For that matter=2C the "builder" could or C backend initialization could = >> =0A= >>> probably make it so. =0A= >>> =0A= >>> =0A= >>> Ideally this configuration knob would go away. One order picked that =0A= >>> works and all backends =0A= >>> deal with it. =0A= >>> =0A= >>> =0A= >>> =0A= >>> As you mention=2C computers have gotten a lot faster since DEC SRC was = >> =0A= >>> designed/implemented. =0A= >>> This desire to not require backends to hold an entire "program" in =0A= >>> memory is largely antiquated. =0A= >>> Mainstream commercial C and C++ compilers regularly do whole program =0A= >>> codegen/optimization now and have been =0A= >>> doing so for over 10 years. =0A= >>> =0A= >>> =0A= >>> (our mklib.exe actually is in the way of using Visual C++'s whole =0A= >>> program codegen..it reads .obj files..=2C =0A= >>> but given our historical code quality being pretty poor anyway=2C and =0A= >>> nobody noticing=2C I'm not too worried..) =0A= >>> =0A= >>> =0A= >>> =0A= >>>> but after fixing that I get a boot archive! Very exciting. What do =0A= >>> I do now? =0A= >>> =0A= >>> =0A= >>> One of two options: =0A= >>> =0A= >>> 1) Less usual: If you have a cross C compiler/linker=2C ignore the =0A= >>> archive=2C cd into the directory =0A= >>> it was built from=2C edit the Makefile=2C make =0A= >>> I had built ARM_DARWIN this way=2C and the Makefile for that target =0A= >>> assumes it=2C just the few =0A= >>> lines at the top that set the C compiler name/flags. =0A= >>> =0A= >>> =0A= >>> 2) Usual: If you don't have a cross C compiler/linker=2C and you do have = >> =0A= >>> a native C compiler/linker=2C =0A= >>> copy the boot archive (or the directory it is built from) to the =0A= >>> target machine=2C extract it=2C cd into it=2C make=2C =0A= >>> possibly first editing the Makefile (you know=2C we don't use =0A= >>> autoconf/automake=2C and a lot =0A= >>> of what we do is duplicating them..) =0A= >>> =0A= >>> =0A= >>> If that succeeds=2C you will have cm3. =0A= >>> On the new target machine: =0A= >>> Run it =0A= >>> If it says "can't find cm3.cfg"=2C that is success so far. =0A= >>> If it doesn't say that=2C or crashes=2C debug it. =0A= >>> mkdir -p /usr/local/cm3/bin =0A= >>> cp cm3 /usr/local/cm3/bin =0A= >>> cd somewhere (again=2C on the new target machine) =0A= >>> cvs checkout =0A= >>> scripts/python/boot2.py that will build the entire system starting =0A= >>> from just the cm3 (and a native C compiler/linker) =0A= >>> =0A= >>> =0A= >>> Document your experience better than I have and what needs to change. =0A= >>> =0A= >>> =0A= >>>> This machine is quite slow=2C maybe it would be nice to have a version = >> =0A= >>> of the front end =0A= >>>> that generates C without comments? :) (I'm not saying it should be =0A= >>> the default.) =0A= >>> =0A= >>> =0A= >>> Yeah..there are some globals controlling it. =0A= >>> It is a tough tradeoff performance vs. debuggability...granted=2C the =0A= >>> comments are gibberish =0A= >>> to most people. But I like to have the debuggability... =0A= >>> =0A= >>> =0A= >>> =0A= >>> Going through C is also noticably slower. That is a downside to the =0A= >>> ease of development =0A= >>> and portability it brings. =0A= >>> One thing I'd like to do is batch it up so we pass all the C files to =0A= >>> the compiler at once. =0A= >>> At least the out of date ones. I know that is much faster with the =0A= >>> Microsoft C compiler -- =0A= >>> I even changed the boot archive to work that way -- I think for all =0A= >>> targets actually. =0A= >>> =0A= >>> =0A= >>> =0A= >>> - Jay =0A= >>> =0A= >>> =0A= >>> =0A= >>> =0A= >>>> To: jay.krell at cornell.edu =0A= >>>> CC: m3devel at elegosoft.com =0A= >>>> Subject: M3 on Raspberry Pi cont'd... =0A= >>>> Date: Mon=2C 14 Oct 2013 16:11:31 -0700 =0A= >>>> From: mika at async.caltech.edu =0A= >>>> =0A= >>>> =0A= >>>> A bit of success... I found that CVS had mangled RTMachine.i3 (why??) = >> =0A= >>> and that was causing things to go very wrong. =0A= >>>> =0A= >>>> I did manage to upgrade my compiler to the head. =0A= >>>> =0A= >>>> ./boot1.py ARMEL_LINUX still leads to the tree error: =0A= >>>> =0A= >>>> make: *** No rule to make target `c-family/c-pragma.h'=2C needed by =0A= >>> `arm.o'. Stop. =0A= >>>> =0A= >>>> ./boot1.py c ARMEL_LINUX results in a new problem: =0A= >>>> =0A= >>>> ../src/runtime/common/RTAllocator.m3"=2C line 14: =0A= >>> internal_begin_procedure: in_proc=3B C backend requires M3_FRONT_FLAGS = >> =3D =0A= >>> ["-unfold_nested_procs"] in config file =0A= >>>> =0A= >>>> but after fixing that I get a boot archive! Very exciting. What do I =0A= >>> do now? I'm trying to run everything through cc -O3 -c =0A= >>>> =0A= >>>> This machine is quite slow=2C maybe it would be nice to have a version = >> =0A= >>> of the front end that generates C without comments? :) (I'm not saying = >> =0A= >>> it should be the default.) =0A= >>>> =0A= >>>> Mika = From peter.mckinna at gmail.com Tue Oct 15 07:40:36 2013 From: peter.mckinna at gmail.com (Peter McKinna) Date: Tue, 15 Oct 2013 16:40:36 +1100 Subject: [M3devel] PThread collector problem Message-ID: Hi, I hope its not just me but I still have crashes with that thread test program on my linux amd_64 machine. There seems to be some incompatibility between pthreads and the collector. When I run it with the default tests It either crashes with a segv in the collector in Move or else in FileRd.init, with the buf field corrupted. Something does not like being moved by the look of things. Has anyone else experience problems like this? Regards Peter. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Tue Oct 15 20:52:50 2013 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Tue, 15 Oct 2013 11:52:50 -0700 Subject: [M3devel] PThread collector problem In-Reply-To: References: Message-ID: <20131015185250.ECFCA1A2091@async.async.caltech.edu> I gave up on pthreads long before I ever got the thread tester to work. I only ever used user threads for "serious stuff". It's been a long time, though, and I'd been hoping the issues had been fixed. Right now all my compilers are in flux but soon I hope to have time to check it out again. Mika Peter McKinna writes: >--089e01419acc2cfc1904e8c106e5 >Content-Type: text/plain; charset=ISO-8859-1 > >Hi, > > I hope its not just me but I still have crashes with that thread test >program on my linux amd_64 machine. There seems to be some incompatibility >between pthreads and the collector. When I run it with the default tests > It either crashes with a segv in the collector in Move or else in >FileRd.init, with the buf field > corrupted. Something does not like being moved by the look of things. > Has anyone else experience problems like this? > >Regards Peter. > >--089e01419acc2cfc1904e8c106e5 >Content-Type: text/html; charset=ISO-8859-1 >Content-Transfer-Encoding: quoted-printable > >

Hi,

=A0 I hope its not just me but I st= >ill have crashes with that thread test program on my linux amd_64 machine. = >There seems to be some incompatibility between pthreads and the collector. = >When I run it with the default tests

=A0 It either crashes with a segv in the collector in Move or else in = >FileRd.init, =A0with the buf field=A0

=A0corrupted. Something doe= >s not like being moved by the look of things.

=A0 Has anyone = >else experience problems like this?

Regards Peter.

> >--089e01419acc2cfc1904e8c106e5-- From mika at async.caltech.edu Wed Oct 16 00:49:49 2013 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Tue, 15 Oct 2013 15:49:49 -0700 Subject: [M3devel] Well, I'm impressed! Message-ID: <20131015224950.003841A2091@async.async.caltech.edu> Jay, Yes I am impressed! raspberrypi:/big/home/mika/xxx# cat Hello.m3 MODULE Hello EXPORTS Main; IMPORT IO; BEGIN IO.Put("Hi!\n"); END Hello. raspberrypi:/big/home/mika/xxx# cm3 --- building in ARMEL_LINUX --- new source -> compiling Hello.m3 -> linking prog raspberrypi:/big/home/mika/xxx# ARMEL_LINUX/prog Hi! raspberrypi:/big/home/mika/xxx# It's slow, that's for sure... not done rebuilding the compiler yet. A few notes: I'd say the hardest thing for me to figure out was actually how to upgrade the compiler on the AMD64 system. When I tried to rebuild cm3 first, I got tons of errors. When I tried to rebuild cm3cg first, I also got tons of errors! What gives? Well... you can do it by realizing that while upgrading cm3 makes a broken compiler, it's still good enough to run the bit of quake code needed to recompile cm3cg. Or you can compile cm3cg, and keep it around, not install it, and then recompile cm3, and only at that point copy cm3cg into place. That works too. Then recompile everything with the matching toolsets. To be honest I wouldn't even have been able to guess a method to solve this problem without reading between the lines of your emails. Totally non-obvious. On the Raspberry, yes, you were right, the jmpbuf was wrong size. I already fixed this in Target.m3 (committed to CVS). I added some extra padding for good measure. "49" looks too weird. 64 it is. I had to update ARMEL_LINUX config file to have M3_BACKEND_MODE="C" M3_FRONT_FLAGS += ["-unfold_nested_procs"] I noticed things are VERY touchy with versioning at this point. Everything has to match closely (much more so than I'm used to with Modula-3) to bootstrap properly. The fact that cm3cg/m3cc won't build right on MIPSEL_LINUX is a big hassle. It's in pkginfo.txt. Then it's in build2.sh. Then it's in various other places. It has to be removed from everywhere before rebuilding. Finally, SYSTEM_CC and SYSTEM_AS are set up for cross building in the configs. That leads to a ton more editing (as the settings propagate to a few places). The system is slow but does seem to work. It's not through building anything much yet, it looks like it will run for the rest of the day. Thanks for some very good work, Jay. This seems very promising, but of course I can't promise I won't be emailing m3devel a lot more soon. Is there anything I can do, assuming all works well, to upload an archive or something, to let other intrepid Raspberry users skip most of the steps? Mika ~ ~ ~ ~ From jay.krell at cornell.edu Wed Oct 16 01:25:11 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 15 Oct 2013 23:25:11 +0000 Subject: [M3devel] Well, I'm impressed! In-Reply-To: <20131015224950.003841A2091@async.async.caltech.edu> References: <20131015224950.003841A2091@async.async.caltech.edu> Message-ID: Cool. > to upload an archive or something, to let other intrepid Raspber scripts/make-dist.py ? And then you can scp the results to modula3.elegosoft.com/var/www/cm3/uploaded-archives. Feel free to do that for whatever are your favorite systems, maybe switching them to the C backend as you go. :) > SYSTEM_CC and SYSTEM_AS are set up for cross building Only for ARM. I thought only ARM_DARWIN. I guess that wasn't ideal in retrospect. Or rather, there is more work to do here, so we have a complete native and cross story with reasonable ease of use. I am so tempted to throw out quake and the config files and just generate a little automake/autoconf/cmake input and let them deal with it.. > MIPSEL_LINUX Why is MIPS relevant? I guess I didn't get far there, on my Loongson I replaced Debian with OpenBSD. Anyway, with the C backend, it likely just works. Did you mean ARMEL_LINUX? And the pragma thing? I fixed that. Problem is, when upgrading cm3cg, one I guess should build for every target, to catch this. I guess I should do that. But this is hopefully going away. I built some cm3cg backends last night..and hit OpenBSD missing in 4.7.. > I'd say the hardest thing for me to figure out was actually how to upgrade Upgrade.py? The version sensitivity has always been there, it is just that we go long durations without changing things. But things are changable and do get changed. Tony added LONGINT and the atomics. Good. And upgrade.py deals with that. I modified the M3CG enum slightly. Upgrade.py deals with that. It isn't a bunch of special cases, it is just a particular ordering. We depend on a working system to give us cm3, m3core, and libm3. That is all you need for a native upgrade. One thing upgrade.py is touchy about is, that someone hit recently, is that I replaced upgrade.h's uname use with looking at what cm3's host is. But older cm3 doesn't report it. So he didn't use ugprade.py. If you don't have native cm3, then you can cross build cm3. You went through both of those paths. Good! I'm hoping additional people can become comfortable with this, so more people can work on it. And maybe we need to restructure some. In particular, upgrade should not be so in-place. make-dist.py does this better -- it builds a whole new system, but w/o changing the existing one at all. At the end you can copy the new onto the old. Realize upgrade.py was based on upgrade.sh, for better and worse. I did miss that upgrade.sh built everything and not just cm3/m3core/libm3, so upgrade.py doesn't build everything. > Finally, SYSTEM_CC and SYSTEM_AS are set up for cross building in the > configs. That leads to a ton more editing (as the settings propagate > to a few places). There is a version of cm3.cfg that reachs back into the CVS checkout. I did that as a response to my often editing the wrong files. But this also is hazardous sometimes wrt upgrade, sometimes these need to be separate. - Jay > To: m3devel at elegosoft.com; jay.krell at cornell.edu > Subject: Well, I'm impressed! > Date: Tue, 15 Oct 2013 15:49:49 -0700 > From: mika at async.caltech.edu > > Jay, > > Yes I am impressed! > > raspberrypi:/big/home/mika/xxx# cat Hello.m3 > MODULE Hello EXPORTS Main; > IMPORT IO; > > BEGIN > IO.Put("Hi!\n"); > END Hello. > raspberrypi:/big/home/mika/xxx# cm3 > --- building in ARMEL_LINUX --- > > new source -> compiling Hello.m3 > -> linking prog > raspberrypi:/big/home/mika/xxx# ARMEL_LINUX/prog > Hi! > raspberrypi:/big/home/mika/xxx# > > It's slow, that's for sure... not done rebuilding the compiler yet. > > A few notes: > > I'd say the hardest thing for me to figure out was actually how to upgrade > the compiler on the AMD64 system. When I tried to rebuild cm3 first, > I got tons of errors. When I tried to rebuild cm3cg first, I also got > tons of errors! What gives? Well... you can do it by realizing that > while upgrading cm3 makes a broken compiler, it's still good enough to > run the bit of quake code needed to recompile cm3cg. > > Or you can compile cm3cg, and keep it around, not install it, and > then recompile cm3, and only at that point copy cm3cg into place. > That works too. > > Then recompile everything with the matching toolsets. > > To be honest I wouldn't even have been able to guess a method to solve > this problem without reading between the lines of your emails. Totally > non-obvious. > > On the Raspberry, yes, you were right, the jmpbuf was wrong size. I already > fixed this in Target.m3 (committed to CVS). I added some extra padding for > good measure. "49" looks too weird. 64 it is. > > I had to update ARMEL_LINUX config file to have > > M3_BACKEND_MODE="C" > M3_FRONT_FLAGS += ["-unfold_nested_procs"] > > I noticed things are VERY touchy with versioning at this point. > Everything has to match closely (much more so than I'm used to with > Modula-3) to bootstrap properly. > > The fact that cm3cg/m3cc won't build right on MIPSEL_LINUX is a big > hassle. It's in pkginfo.txt. Then it's in build2.sh. Then it's in > various other places. It has to be removed from everywhere before > rebuilding. > > Finally, SYSTEM_CC and SYSTEM_AS are set up for cross building in the > configs. That leads to a ton more editing (as the settings propagate > to a few places). > > The system is slow but does seem to work. It's not through building > anything much yet, it looks like it will run for the rest of the day. > > Thanks for some very good work, Jay. This seems very promising, but of > course I can't promise I won't be emailing m3devel a lot more soon. > > Is there anything I can do, assuming all works well, to upload an > archive or something, to let other intrepid Raspberry users skip most > of the steps? > > Mika > ~ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Wed Oct 16 01:29:59 2013 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Tue, 15 Oct 2013 16:29:59 -0700 Subject: [M3devel] Well, I'm impressed! In-Reply-To: References: <20131015224950.003841A2091@async.async.caltech.edu> Message-ID: <20131015232959.274F01A2091@async.async.caltech.edu> Jay K writes: >--_700bb45a-d31c-45ed-b67c-42fa9cd6d925_ ... > >=20 > > MIPSEL_LINUX=20 > > > Why is MIPS relevant?=20 Sorry I meant ARMEL_LINUX of course. > I guess I didn't get far there=2C on my Loongson I replaced Debian with Op= >enBSD.=20 > Anyway=2C with the C backend=2C it likely just works. > > > Did you mean ARMEL_LINUX? And the pragma thing? I fixed that.=20 > Problem is=2C when upgrading cm3cg=2C one I guess should build for every t= >arget=2C to catch this.=20 > I guess I should do that. But this is hopefully going away.=20 > I built some cm3cg backends last night..and hit OpenBSD missing in 4.7.. > > > > I'd say the hardest thing for me to figure out was actually how to upgra= >de > > > Upgrade.py? > upgrade.py didn't seem to work for me. I think it dropped me at a point where the front and back ends were incompatible. I had to delete everything and start over. Mika From jay.krell at cornell.edu Wed Oct 16 01:58:11 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 15 Oct 2013 23:58:11 +0000 Subject: [M3devel] Well, I'm impressed! In-Reply-To: <20131015232959.274F01A2091@async.async.caltech.edu> References: <20131015224950.003841A2091@async.async.caltech.edu> , <20131015232959.274F01A2091@async.async.caltech.edu> Message-ID: > I think it dropped me at a point where > the front and back ends were incompatible It should work. It isn't that difficult, but it does what is needed for it to work. I have used it many times and I have very occasionally introduced incompatibilities. - Jay > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: Well, I'm impressed! > Date: Tue, 15 Oct 2013 16:29:59 -0700 > From: mika at async.caltech.edu > > Jay K writes: > >--_700bb45a-d31c-45ed-b67c-42fa9cd6d925_ > ... > > > >=20 > > > MIPSEL_LINUX=20 > > > > > > Why is MIPS relevant?=20 > > Sorry I meant ARMEL_LINUX of course. > > > I guess I didn't get far there=2C on my Loongson I replaced Debian with Op= > >enBSD.=20 > > Anyway=2C with the C backend=2C it likely just works. > > > > > > Did you mean ARMEL_LINUX? And the pragma thing? I fixed that.=20 > > Problem is=2C when upgrading cm3cg=2C one I guess should build for every t= > >arget=2C to catch this.=20 > > I guess I should do that. But this is hopefully going away.=20 > > I built some cm3cg backends last night..and hit OpenBSD missing in 4.7.. > > > > > > > I'd say the hardest thing for me to figure out was actually how to upgra= > >de > > > > > > Upgrade.py? > > > > upgrade.py didn't seem to work for me. I think it dropped me at a point where > the front and back ends were incompatible. I had to delete everything and > start over. > > Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Wed Oct 16 21:05:43 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 16 Oct 2013 14:05:43 -0500 Subject: [M3devel] Licenses and copyright ownership Message-ID: <525EE387.7060703@lcwb.coop> I have checked in a few written-from-scratch source files without copyright/license notices recently. I plan to fix this, but wonder if there is a consensus about the choices here. We already have a hodge-podge of copyright owners and licenses in the Modula-3 repository. That may be difficult or impossible to fix, but I would like to move things in the right direction when adding all-new code. I checked in some earlier ones naming myself as owner and GPL as license. But I recall reading some hints on this list suggesting that people felt that the GPL was not a good idea here. Also, is there any organization that would be good to take ownership where possible, in order to get Modula-3 more consistent in this regard? From hosking at cs.purdue.edu Wed Oct 16 21:11:57 2013 From: hosking at cs.purdue.edu (Tony Hosking) Date: Wed, 16 Oct 2013 15:11:57 -0400 Subject: [M3devel] Licenses and copyright ownership In-Reply-To: <525EE387.7060703@lcwb.coop> References: <525EE387.7060703@lcwb.coop> Message-ID: <27C4541E-5390-4096-969C-6EFC9EB99E9D@cs.purdue.edu> I think GPL is inherently incompatible with the original DEC/SRC license. Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Mobile +1 765 427 5484 On Oct 16, 2013, at 3:05 PM, "Rodney M. Bates" wrote: > I have checked in a few written-from-scratch source files without copyright/license > notices recently. I plan to fix this, but wonder if there is a consensus about > the choices here. We already have a hodge-podge of copyright owners and licenses > in the Modula-3 repository. That may be difficult or impossible to fix, but I > would like to move things in the right direction when adding all-new code. > > I checked in some earlier ones naming myself as owner and GPL as license. > But I recall reading some hints on this list suggesting that people felt > that the GPL was not a good idea here. > > Also, is there any organization that would be good to take ownership where > possible, in order to get Modula-3 more consistent in this regard? > > From rodney_bates at lcwb.coop Wed Oct 16 21:36:21 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 16 Oct 2013 14:36:21 -0500 Subject: [M3devel] Licenses and copyright ownership In-Reply-To: <27C4541E-5390-4096-969C-6EFC9EB99E9D@cs.purdue.edu> References: <525EE387.7060703@lcwb.coop> <27C4541E-5390-4096-969C-6EFC9EB99E9D@cs.purdue.edu> Message-ID: <525EEAB5.2030403@lcwb.coop> On 10/16/2013 02:11 PM, Tony Hosking wrote: > I think GPL is inherently incompatible with the original DEC/SRC license. So what do you propose instead? > > Antony Hosking | Associate Professor | Computer Science | Purdue University > 305 N. University Street | West Lafayette | IN 47907 | USA > Mobile +1 765 427 5484 > > > > > > On Oct 16, 2013, at 3:05 PM, "Rodney M. Bates" wrote: > >> I have checked in a few written-from-scratch source files without copyright/license >> notices recently. I plan to fix this, but wonder if there is a consensus about >> the choices here. We already have a hodge-podge of copyright owners and licenses >> in the Modula-3 repository. That may be difficult or impossible to fix, but I >> would like to move things in the right direction when adding all-new code. >> >> I checked in some earlier ones naming myself as owner and GPL as license. >> But I recall reading some hints on this list suggesting that people felt >> that the GPL was not a good idea here. >> >> Also, is there any organization that would be good to take ownership where >> possible, in order to get Modula-3 more consistent in this regard? >> >> > > From jay.krell at cornell.edu Wed Oct 16 21:55:09 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 16 Oct 2013 19:55:09 +0000 Subject: [M3devel] Licenses and copyright ownership In-Reply-To: <525EEAB5.2030403@lcwb.coop> References: <525EE387.7060703@lcwb.coop>, <27C4541E-5390-4096-969C-6EFC9EB99E9D@cs.purdue.edu>, <525EEAB5.2030403@lcwb.coop> Message-ID: Use a "BSD" or "MIT" license. Maybe LGPL. Don't use Apache 2.0 or Mozilla. Don't make up your own. OpenBSD folks reject such things as not worth the (lawyer) time to understand. OpenBSD folks reject the Apache 2.0 license for some reaosn -- maybe the previous, it is long and custom. Best is modern BSD, which some years ago dropped a clause from the old BSD license. See OpenBSD, FreeBSD, and NetBSD. ?- Jay ---------------------------------------- > Date: Wed, 16 Oct 2013 14:36:21 -0500 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Licenses and copyright ownership > > > > On 10/16/2013 02:11 PM, Tony Hosking wrote: >> I think GPL is inherently incompatible with the original DEC/SRC license. > > So what do you propose instead? > >> >> Antony Hosking | Associate Professor | Computer Science | Purdue University >> 305 N. University Street | West Lafayette | IN 47907 | USA >> Mobile +1 765 427 5484 >> >> >> >> >> >> On Oct 16, 2013, at 3:05 PM, "Rodney M. Bates" wrote: >> >>> I have checked in a few written-from-scratch source files without copyright/license >>> notices recently. I plan to fix this, but wonder if there is a consensus about >>> the choices here. We already have a hodge-podge of copyright owners and licenses >>> in the Modula-3 repository. That may be difficult or impossible to fix, but I >>> would like to move things in the right direction when adding all-new code. >>> >>> I checked in some earlier ones naming myself as owner and GPL as license. >>> But I recall reading some hints on this list suggesting that people felt >>> that the GPL was not a good idea here. >>> >>> Also, is there any organization that would be good to take ownership where >>> possible, in order to get Modula-3 more consistent in this regard? >>> >>> >> >> > From mika at async.caltech.edu Wed Oct 16 22:31:05 2013 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Wed, 16 Oct 2013 13:31:05 -0700 Subject: [M3devel] ARMEL_LINUX on Raspberry Pi progress report Message-ID: <20131016203105.88B8B1A208E@async.async.caltech.edu> It's still working its way through boot2.sh .. here is what I have run into so far that looks wrong: 1. I get the following warning whenever I link a program (I think only as "mika", not as "root"): new source -> compiling Main.m3 -> linking tnmtsetup /usr/bin/ld: /usr/local/cm3/pkg/m3core/ARMEL_LINUX/libm3core.a(ThreadPThreadC.o)(.stab+0x2e28): R_ARM_ABS32 used with TLS symbol activations I think it's just a warning because the executables still work. 2. I can't get anything with Trestle working. I'm running in a VNC session on a remote machine. Not sure this has anything to do with the compiler or even the ARM. Has anyone seen it before (on any system)? (gdb) cont Continuing. [New Thread 0x42276430 (LWP 24451)] [Thread 0x42276430 (LWP 24451) exited] [New Thread 0x424c6430 (LWP 24454)] *** *** runtime error: *** Exception "ZChildVBT.BadPercentage" not in RAISES list *** file "../src/lego/ZChildVBT.m3", line 61 *** Program received signal SIGABRT, Aborted. backtrace: (gdb) where #0 ZChildVBT__Init (z_L_120=0x422bbf70 "H\357K", ch_L_121=0x422bdb84 "\260\326K", h_L_122=0, v_L_123=1.75, loc_L_124=4 '\004', type_L_125=1 '\001', shaper_L_126=0x41a32b54, open_L_127=0 '\000') at ../src/lego/ZCh ildVBT.m3:61 #1 0x40637518 in FormsVBT__pZChild (cl_L_1042=0x42280444, list_L_1043=0x424c54c4, s_L_1044=0x424c55dc) at ../src/FormsVBT.m3:2593 #2 0x40609f30 in FormsVBT__Item (cl_L_301=0x42280444, exp_L_302=0x41a45994 "", state_L_303=0x424c55dc) at ../src/FormsVBT.m3:250 #3 0x40648b3c in FormsVBT__AddChildren (cl_L_1229=0x42280444, v_L_1230=0x422b0634 " \365K", list_L_1231=0x41a48504, state_L_1232=0x424c55dc) at ../src/FormsVBT.m3:3671 #4 0x40634138 in FormsVBT__pZSplit (cl_L_999=0x42280444, list_L_1000=0x424c56bc, s_L_1001=0x424c57c4) at ../src/FormsVBT.m3:2454 #5 0x40609f30 in FormsVBT__Item (cl_L_301=0x42280444, exp_L_302=0x41a40ec0 "", state_L_303=0x424c57c4) at ../src/FormsVBT.m3:250 #6 0x4064838c in FormsVBT__OneChild (cl_L_1224=0x42280444, list_L_1225=0x0, state_L_1226=0x424c57c4) at ../src/FormsVBT.m3:3642 #7 0x406129c0 in FormsVBT__pShape (cl_L_496=0x42280444, list_L_497=0x424c58a4, s_L_498=0x424c59a4) at ../src/FormsVBT.m3:948 #8 0x40609f30 in FormsVBT__Item (cl_L_301=0x42280444, exp_L_302=0x41a402a4 "", state_L_303=0x424c59a4) at ../src/FormsVBT.m3:250 #9 0x4064838c in FormsVBT__OneChild (cl_L_1224=0x42280444, list_L_1225=0x0, state_L_1226=0x424c59a4) at ../src/FormsVBT.m3:3642 #10 0x4062ca10 in FormsVBT__pScale (cl_L_905=0x42280444, list_L_906=0x424c5a84, s_L_907=0x42280458) at ../src/FormsVBT.m3:2165 #11 0x40609f30 in FormsVBT__Item (cl_L_301=0x42280444, exp_L_302=0x41a4006c "", state_L_303=0x42280458) at ../src/FormsVBT.m3:250 #12 0x40606dec in FormsVBT__Apply (cl_L_293=0x42280444) at ../src/FormsVBT.m3:84 #13 0x40d27bd4 in ThreadPThread__RunThread (me_L_231=0x4c5d78 "0SLB\330]L") at ../src/thread/PTHREAD/ThreadPThread.m3:449 #14 0x40d27590 in ThreadPThread__ThreadBase (param_L_229=0x4c5d78 "0SLB\330]L") at ../src/thread/PTHREAD/ThreadPThread.m3:422 #15 0x41850bfc in start_thread () from /lib/arm-linux-gnueabihf/libpthread.so.0 #16 0x41933758 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6 #17 0x41933758 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6 Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb) cont Continuing. 3. looking at the generated C and binaries I am wondering if everything is quite all right. The binaries are twice as large as on x86_64 (give or take). Mentor is 13MB... Looking at the C code it also looks to me like the intent was to inline things such as the following: 00000048 : 48: e52db004 push {fp} ; (str fp, [sp, #-4]!) 4c: e28db000 add fp, sp, #0 50: e24dd00c sub sp, sp, #12 54: e50b0008 str r0, [fp, #-8] 58: e50b100c str r1, [fp, #-12] 5c: e51b2008 ldr r2, [fp, #-8] 60: e51b300c ldr r3, [fp, #-12] 64: e1520003 cmp r2, r3 68: 13a03000 movne r3, #0 6c: 03a03001 moveq r3, #1 70: e1a00003 mov r0, r3 74: e28bd000 add sp, fp, #0 78: e8bd0800 pop {fp} 7c: e12fff1e bx lr yet it's not getting inlined but "threaded"... e.g., (92)raspberrypi:/big/home2/mika/2/cm3-cvs/cm3/m3-ui/ui/ARMEL_LINUX>nm libm3ui.a | grep m3_eq_ADDRESS | wc 79 237 1975 or indeed: (95)raspberrypi:/big/home2/mika/2/cm3-cvs/cm3/m3-ui/ui/ARMEL_LINUX>nm libm3ui.a | grep ^0 | awk '{print $3}' | sort | uniq -c | sort -n | tail -50 2 L_82_L_83 2 m3_lt_float 2 m3_max_float 2 m3_min_float 2 m3_trunc 3 L_11_L_12 3 L_17_L_18 3 L_18_L_19 3 L_19_L_20 3 L_35_L_36 3 L_46_L_47 3 L_8_L_9 3 m3_ge_float 3 m3_le_float 3 m3_mod_INT32 3 m3_set_member 3 m3_shift_UINT32 4 L_7_L_8 5 L_28_L_29 5 m3_ne_float 6 L_16_L_17 6 L_21_L_22 6 L_5_L_6 7 L_3_L_4 8 L_10_L_11 8 m3_div_INT32 9 L_0_L_1 10 L_9_L_10 10 m3_round 11 L_14_L_15 11 L_6_L_7 11 m3_check_range_INT32 12 m3_sign_extend_INT32 13 L_2_L_3 13 L_4_L_5 15 L_1_L_2 16 m3_pop_INT32 18 m3_min_INT32 22 m3_lt_INT32 22 m3_max_INT32 27 m3_eq_UINT32 27 m3_le_INT32 31 m3_gt_INT32 42 m3_ne_UINT32 57 m3_ge_INT32 64 m3_ne_ADDRESS 79 m3_eq_ADDRESS 81 m3_extract_UINT32 83 m3_ne_INT32 208 m3_eq_INT32 where... (judging from the macros in the .c this might be important): (96)raspberrypi:/big/home2/mika/2/cm3-cvs/cm3/m3-ui/ui/ARMEL_LINUX>gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/4.6/lto-wrapper Target: arm-linux-gnueabihf Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.3-14+rpi1' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --disable-sjlj-exceptions --with-arch=armv6 --with-fpu=vfp --with-float=hard --enable-checking=release --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf Thread model: posix gcc version 4.6.3 (Debian 4.6.3-14+rpi1) Mika From jay.krell at cornell.edu Wed Oct 16 22:54:35 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 16 Oct 2013 20:54:35 +0000 Subject: [M3devel] ARMEL_LINUX on Raspberry Pi progress report In-Reply-To: <20131016203105.88B8B1A208E@async.async.caltech.edu> References: <20131016203105.88B8B1A208E@async.async.caltech.edu> Message-ID: TLS: On Linux and only Linux we use __thread as a possible optimization. On all other Posix platforms we use pthread_setspecific/pthread_getspecific. Several other platforms support this, but not always older versions. ?You compiled with -fPIC?? ?Or did you/we just cc -c *.c ?? I suppose..in m3core/src/thread/PTHREAD/ThreadPThreadC.c change: ? #if defined(__linux) ? ? to ? ? #if defined(__linux) && !defined(__arm__) ? ? Search the web for the warning? ? ? I can't right now. ? ?m3_eq_ADDRESS: This is slow/not-inline because? ? For a long time I was avoiding gcc warnings, unconditionally.? ? When using -Wall -Wextra. That is tricky.? ? It warns about stuff like:? ? unsigned a = 0;? ? if (a < 0) // always false? ? and I worked around it by introducing functions for all such? ? comparisons. I tried value tracking to make the optimizations? ? ?myself, but that has failed so far.? ? ? But upon stepping into those functions a lot on AMD64_NT,? ? I did make it conditional, but didn't finish testing.? ? ? The relevant code is in m3back/src/M3C.m3:? ?"#if (GCC_VERSION> 0 && GCC_VERSION < 430)",? ?"#define m3_eq_T(T) static WORD_T __stdcall m3_eq_##T(T x, T y){return x==y;}\n" &? ?Can you do cm3 -keep and the gcc -E on some files?? ?I'll do that later.? Oh, maybe: "#define GCC_VERSION (__GNUC__ * 100 + __GNUC_MINOR__)", with: "#define GCC_VERSION (__GNUC__ * 100 + __GNUC_MINOR__ * 10)", ?I'm torn on this matter.? ?I like my code to be warning free, but catering to? ?gcc 4.0 -Wall -Wextra isn't easy.? ?BadPercentage:? ? Um, to isolate variables, and cause you extra pain..? ? try with cm3cg?? ? You know, try a different implementation to help? ? determine where the problem is?? ? Something floating point related?? ? ? - Jay ---------------------------------------- > To: jay.krell at cornell.edu > Date: Wed, 16 Oct 2013 13:31:05 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: [M3devel] ARMEL_LINUX on Raspberry Pi progress report > > > It's still working its way through boot2.sh .. > > here is what I have run into so far that looks wrong: > > 1. I get the following warning whenever I link a program (I think only as > "mika", not as "root"): > > new source -> compiling Main.m3 > -> linking tnmtsetup > /usr/bin/ld: /usr/local/cm3/pkg/m3core/ARMEL_LINUX/libm3core.a(ThreadPThreadC.o)(.stab+0x2e28): R_ARM_ABS32 used with TLS symbol activations > > I think it's just a warning because the executables still work. > > 2. I can't get anything with Trestle working. I'm running in a VNC > session on a remote machine. Not sure this has anything to do with the > compiler or even the ARM. Has anyone seen it before (on any system)? > > (gdb) cont > Continuing. > [New Thread 0x42276430 (LWP 24451)] > [Thread 0x42276430 (LWP 24451) exited] > [New Thread 0x424c6430 (LWP 24454)] > > > *** > *** runtime error: > *** Exception "ZChildVBT.BadPercentage" not in RAISES list > *** file "../src/lego/ZChildVBT.m3", line 61 > *** > > > Program received signal SIGABRT, Aborted. > > backtrace: > > (gdb) where > #0 ZChildVBT__Init (z_L_120=0x422bbf70 "H\357K", ch_L_121=0x422bdb84 "\260\326K", h_L_122=0, v_L_123=1.75, loc_L_124=4 '\004', type_L_125=1 '\001', shaper_L_126=0x41a32b54, open_L_127=0 '\000') at ../src/lego/ZCh > ildVBT.m3:61 > #1 0x40637518 in FormsVBT__pZChild (cl_L_1042=0x42280444, list_L_1043=0x424c54c4, s_L_1044=0x424c55dc) at ../src/FormsVBT.m3:2593 > #2 0x40609f30 in FormsVBT__Item (cl_L_301=0x42280444, exp_L_302=0x41a45994 "", state_L_303=0x424c55dc) at ../src/FormsVBT.m3:250 > #3 0x40648b3c in FormsVBT__AddChildren (cl_L_1229=0x42280444, v_L_1230=0x422b0634 " \365K", list_L_1231=0x41a48504, state_L_1232=0x424c55dc) at ../src/FormsVBT.m3:3671 > #4 0x40634138 in FormsVBT__pZSplit (cl_L_999=0x42280444, list_L_1000=0x424c56bc, s_L_1001=0x424c57c4) at ../src/FormsVBT.m3:2454 > #5 0x40609f30 in FormsVBT__Item (cl_L_301=0x42280444, exp_L_302=0x41a40ec0 "", state_L_303=0x424c57c4) at ../src/FormsVBT.m3:250 > #6 0x4064838c in FormsVBT__OneChild (cl_L_1224=0x42280444, list_L_1225=0x0, state_L_1226=0x424c57c4) at ../src/FormsVBT.m3:3642 > #7 0x406129c0 in FormsVBT__pShape (cl_L_496=0x42280444, list_L_497=0x424c58a4, s_L_498=0x424c59a4) at ../src/FormsVBT.m3:948 > #8 0x40609f30 in FormsVBT__Item (cl_L_301=0x42280444, exp_L_302=0x41a402a4 "", state_L_303=0x424c59a4) at ../src/FormsVBT.m3:250 > #9 0x4064838c in FormsVBT__OneChild (cl_L_1224=0x42280444, list_L_1225=0x0, state_L_1226=0x424c59a4) at ../src/FormsVBT.m3:3642 > #10 0x4062ca10 in FormsVBT__pScale (cl_L_905=0x42280444, list_L_906=0x424c5a84, s_L_907=0x42280458) at ../src/FormsVBT.m3:2165 > #11 0x40609f30 in FormsVBT__Item (cl_L_301=0x42280444, exp_L_302=0x41a4006c "", state_L_303=0x42280458) at ../src/FormsVBT.m3:250 > #12 0x40606dec in FormsVBT__Apply (cl_L_293=0x42280444) at ../src/FormsVBT.m3:84 > #13 0x40d27bd4 in ThreadPThread__RunThread (me_L_231=0x4c5d78 "0SLB\330]L") at ../src/thread/PTHREAD/ThreadPThread.m3:449 > #14 0x40d27590 in ThreadPThread__ThreadBase (param_L_229=0x4c5d78 "0SLB\330]L") at ../src/thread/PTHREAD/ThreadPThread.m3:422 > #15 0x41850bfc in start_thread () from /lib/arm-linux-gnueabihf/libpthread.so.0 > #16 0x41933758 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6 > #17 0x41933758 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6 > Backtrace stopped: previous frame identical to this frame (corrupt stack?) > (gdb) cont > Continuing. > > 3. looking at the generated C and binaries I am wondering if everything > is quite all right. The binaries are twice as large as on x86_64 (give > or take). Mentor is 13MB... > > Looking at the C code it also looks to me like the intent was to inline things such as the following: > > 00000048 : > 48: e52db004 push {fp} ; (str fp, [sp, #-4]!) > 4c: e28db000 add fp, sp, #0 > 50: e24dd00c sub sp, sp, #12 > 54: e50b0008 str r0, [fp, #-8] > 58: e50b100c str r1, [fp, #-12] > 5c: e51b2008 ldr r2, [fp, #-8] > 60: e51b300c ldr r3, [fp, #-12] > 64: e1520003 cmp r2, r3 > 68: 13a03000 movne r3, #0 > 6c: 03a03001 moveq r3, #1 > 70: e1a00003 mov r0, r3 > 74: e28bd000 add sp, fp, #0 > 78: e8bd0800 pop {fp} > 7c: e12fff1e bx lr > > yet it's not getting inlined but "threaded"... > > e.g., > > (92)raspberrypi:/big/home2/mika/2/cm3-cvs/cm3/m3-ui/ui/ARMEL_LINUX>nm libm3ui.a | grep m3_eq_ADDRESS | wc > 79 237 1975 > > or indeed: > > (95)raspberrypi:/big/home2/mika/2/cm3-cvs/cm3/m3-ui/ui/ARMEL_LINUX>nm libm3ui.a | grep ^0 | awk '{print $3}' | sort | uniq -c | sort -n | tail -50 > 2 L_82_L_83 > 2 m3_lt_float > 2 m3_max_float > 2 m3_min_float > 2 m3_trunc > 3 L_11_L_12 > 3 L_17_L_18 > 3 L_18_L_19 > 3 L_19_L_20 > 3 L_35_L_36 > 3 L_46_L_47 > 3 L_8_L_9 > 3 m3_ge_float > 3 m3_le_float > 3 m3_mod_INT32 > 3 m3_set_member > 3 m3_shift_UINT32 > 4 L_7_L_8 > 5 L_28_L_29 > 5 m3_ne_float > 6 L_16_L_17 > 6 L_21_L_22 > 6 L_5_L_6 > 7 L_3_L_4 > 8 L_10_L_11 > 8 m3_div_INT32 > 9 L_0_L_1 > 10 L_9_L_10 > 10 m3_round > 11 L_14_L_15 > 11 L_6_L_7 > 11 m3_check_range_INT32 > 12 m3_sign_extend_INT32 > 13 L_2_L_3 > 13 L_4_L_5 > 15 L_1_L_2 > 16 m3_pop_INT32 > 18 m3_min_INT32 > 22 m3_lt_INT32 > 22 m3_max_INT32 > 27 m3_eq_UINT32 > 27 m3_le_INT32 > 31 m3_gt_INT32 > 42 m3_ne_UINT32 > 57 m3_ge_INT32 > 64 m3_ne_ADDRESS > 79 m3_eq_ADDRESS > 81 m3_extract_UINT32 > 83 m3_ne_INT32 > 208 m3_eq_INT32 > > where... (judging from the macros in the .c this might be important): > > (96)raspberrypi:/big/home2/mika/2/cm3-cvs/cm3/m3-ui/ui/ARMEL_LINUX>gcc -v > Using built-in specs. > COLLECT_GCC=gcc > COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/4.6/lto-wrapper > Target: arm-linux-gnueabihf > Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.3-14+rpi1' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --disable-sjlj-exceptions --with-arch=armv6 --with-fpu=vfp --with-float=hard --enable-checking=release --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf > Thread model: posix > gcc version 4.6.3 (Debian 4.6.3-14+rpi1) > > > > Mika From dragisha at m3w.org Wed Oct 16 22:56:28 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 16 Oct 2013 22:56:28 +0200 Subject: [M3devel] state of atomic implementation in cm3? Message-ID: <6A6A0819-5E6B-4F5B-A1AC-EB9AC55067F4@m3w.org> Jay, had you implemented atomics in M3C? TIA -- Dragi?a Duri? dragisha at m3w.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From jay.krell at cornell.edu Wed Oct 16 23:02:55 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 16 Oct 2013 21:02:55 +0000 Subject: [M3devel] ARMEL_LINUX on Raspberry Pi progress report In-Reply-To: References: <20131016203105.88B8B1A208E@async.async.caltech.edu>, Message-ID: I likely addressed the TLS and m3_eq_ADDRESS problem. TLS could use more investigation, but ok. m3_eq_ADDRESS maybe double checking/testing. BadPercentage I can try to look at later...do we have any non-Trestle GUI apps that use Xlib more directly? Try those? Try a C/C++ GUI app? ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: mika at async.caltech.edu > Date: Wed, 16 Oct 2013 20:54:35 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] ARMEL_LINUX on Raspberry Pi progress report > > TLS: On Linux and only Linux we use __thread as a possible > optimization. On all other Posix platforms we use > pthread_setspecific/pthread_getspecific. > Several other platforms support this, but not always older versions. > > > You compiled with -fPIC? > Or did you/we just cc -c *.c ? > > I suppose..in m3core/src/thread/PTHREAD/ThreadPThreadC.c > change: > > #if defined(__linux) > to > #if defined(__linux) && !defined(__arm__) > > > Search the web for the warning? > I can't right now. > > > m3_eq_ADDRESS: This is slow/not-inline because > For a long time I was avoiding gcc warnings, unconditionally. > When using -Wall -Wextra. That is tricky. > It warns about stuff like: > unsigned a = 0; > if (a < 0) // always false > and I worked around it by introducing functions for all such > comparisons. I tried value tracking to make the optimizations > myself, but that has failed so far. > > > But upon stepping into those functions a lot on AMD64_NT, > I did make it conditional, but didn't finish testing. > > > The relevant code is in m3back/src/M3C.m3: > "#if (GCC_VERSION> 0 && GCC_VERSION < 430)", > "#define m3_eq_T(T) static WORD_T __stdcall m3_eq_##T(T x, T y){return x==y;}\n" & > > Can you do cm3 -keep and the gcc -E on some files? > I'll do that later. > > Oh, maybe: > "#define GCC_VERSION (__GNUC__ * 100 + __GNUC_MINOR__)", > with: > "#define GCC_VERSION (__GNUC__ * 100 + __GNUC_MINOR__ * 10)", > > I'm torn on this matter. > I like my code to be warning free, but catering to > gcc 4.0 -Wall -Wextra isn't easy. > > > BadPercentage: > Um, to isolate variables, and cause you extra pain.. > try with cm3cg? > You know, try a different implementation to help > determine where the problem is? > Something floating point related? > > > - Jay > > ---------------------------------------- >> To: jay.krell at cornell.edu >> Date: Wed, 16 Oct 2013 13:31:05 -0700 >> From: mika at async.caltech.edu >> CC: m3devel at elegosoft.com >> Subject: [M3devel] ARMEL_LINUX on Raspberry Pi progress report >> >> >> It's still working its way through boot2.sh .. >> >> here is what I have run into so far that looks wrong: >> >> 1. I get the following warning whenever I link a program (I think only as >> "mika", not as "root"): >> >> new source -> compiling Main.m3 >> -> linking tnmtsetup >> /usr/bin/ld: /usr/local/cm3/pkg/m3core/ARMEL_LINUX/libm3core.a(ThreadPThreadC.o)(.stab+0x2e28): R_ARM_ABS32 used with TLS symbol activations >> >> I think it's just a warning because the executables still work. >> >> 2. I can't get anything with Trestle working. I'm running in a VNC >> session on a remote machine. Not sure this has anything to do with the >> compiler or even the ARM. Has anyone seen it before (on any system)? >> >> (gdb) cont >> Continuing. >> [New Thread 0x42276430 (LWP 24451)] >> [Thread 0x42276430 (LWP 24451) exited] >> [New Thread 0x424c6430 (LWP 24454)] >> >> >> *** >> *** runtime error: >> *** Exception "ZChildVBT.BadPercentage" not in RAISES list >> *** file "../src/lego/ZChildVBT.m3", line 61 >> *** >> >> >> Program received signal SIGABRT, Aborted. >> >> backtrace: >> >> (gdb) where >> #0 ZChildVBT__Init (z_L_120=0x422bbf70 "H\357K", ch_L_121=0x422bdb84 "\260\326K", h_L_122=0, v_L_123=1.75, loc_L_124=4 '\004', type_L_125=1 '\001', shaper_L_126=0x41a32b54, open_L_127=0 '\000') at ../src/lego/ZCh >> ildVBT.m3:61 >> #1 0x40637518 in FormsVBT__pZChild (cl_L_1042=0x42280444, list_L_1043=0x424c54c4, s_L_1044=0x424c55dc) at ../src/FormsVBT.m3:2593 >> #2 0x40609f30 in FormsVBT__Item (cl_L_301=0x42280444, exp_L_302=0x41a45994 "", state_L_303=0x424c55dc) at ../src/FormsVBT.m3:250 >> #3 0x40648b3c in FormsVBT__AddChildren (cl_L_1229=0x42280444, v_L_1230=0x422b0634 " \365K", list_L_1231=0x41a48504, state_L_1232=0x424c55dc) at ../src/FormsVBT.m3:3671 >> #4 0x40634138 in FormsVBT__pZSplit (cl_L_999=0x42280444, list_L_1000=0x424c56bc, s_L_1001=0x424c57c4) at ../src/FormsVBT.m3:2454 >> #5 0x40609f30 in FormsVBT__Item (cl_L_301=0x42280444, exp_L_302=0x41a40ec0 "", state_L_303=0x424c57c4) at ../src/FormsVBT.m3:250 >> #6 0x4064838c in FormsVBT__OneChild (cl_L_1224=0x42280444, list_L_1225=0x0, state_L_1226=0x424c57c4) at ../src/FormsVBT.m3:3642 >> #7 0x406129c0 in FormsVBT__pShape (cl_L_496=0x42280444, list_L_497=0x424c58a4, s_L_498=0x424c59a4) at ../src/FormsVBT.m3:948 >> #8 0x40609f30 in FormsVBT__Item (cl_L_301=0x42280444, exp_L_302=0x41a402a4 "", state_L_303=0x424c59a4) at ../src/FormsVBT.m3:250 >> #9 0x4064838c in FormsVBT__OneChild (cl_L_1224=0x42280444, list_L_1225=0x0, state_L_1226=0x424c59a4) at ../src/FormsVBT.m3:3642 >> #10 0x4062ca10 in FormsVBT__pScale (cl_L_905=0x42280444, list_L_906=0x424c5a84, s_L_907=0x42280458) at ../src/FormsVBT.m3:2165 >> #11 0x40609f30 in FormsVBT__Item (cl_L_301=0x42280444, exp_L_302=0x41a4006c "", state_L_303=0x42280458) at ../src/FormsVBT.m3:250 >> #12 0x40606dec in FormsVBT__Apply (cl_L_293=0x42280444) at ../src/FormsVBT.m3:84 >> #13 0x40d27bd4 in ThreadPThread__RunThread (me_L_231=0x4c5d78 "0SLB\330]L") at ../src/thread/PTHREAD/ThreadPThread.m3:449 >> #14 0x40d27590 in ThreadPThread__ThreadBase (param_L_229=0x4c5d78 "0SLB\330]L") at ../src/thread/PTHREAD/ThreadPThread.m3:422 >> #15 0x41850bfc in start_thread () from /lib/arm-linux-gnueabihf/libpthread.so.0 >> #16 0x41933758 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6 >> #17 0x41933758 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6 >> Backtrace stopped: previous frame identical to this frame (corrupt stack?) >> (gdb) cont >> Continuing. >> >> 3. looking at the generated C and binaries I am wondering if everything >> is quite all right. The binaries are twice as large as on x86_64 (give >> or take). Mentor is 13MB... >> >> Looking at the C code it also looks to me like the intent was to inline things such as the following: >> >> 00000048 : >> 48: e52db004 push {fp} ; (str fp, [sp, #-4]!) >> 4c: e28db000 add fp, sp, #0 >> 50: e24dd00c sub sp, sp, #12 >> 54: e50b0008 str r0, [fp, #-8] >> 58: e50b100c str r1, [fp, #-12] >> 5c: e51b2008 ldr r2, [fp, #-8] >> 60: e51b300c ldr r3, [fp, #-12] >> 64: e1520003 cmp r2, r3 >> 68: 13a03000 movne r3, #0 >> 6c: 03a03001 moveq r3, #1 >> 70: e1a00003 mov r0, r3 >> 74: e28bd000 add sp, fp, #0 >> 78: e8bd0800 pop {fp} >> 7c: e12fff1e bx lr >> >> yet it's not getting inlined but "threaded"... >> >> e.g., >> >> (92)raspberrypi:/big/home2/mika/2/cm3-cvs/cm3/m3-ui/ui/ARMEL_LINUX>nm libm3ui.a | grep m3_eq_ADDRESS | wc >> 79 237 1975 >> >> or indeed: >> >> (95)raspberrypi:/big/home2/mika/2/cm3-cvs/cm3/m3-ui/ui/ARMEL_LINUX>nm libm3ui.a | grep ^0 | awk '{print $3}' | sort | uniq -c | sort -n | tail -50 >> 2 L_82_L_83 >> 2 m3_lt_float >> 2 m3_max_float >> 2 m3_min_float >> 2 m3_trunc >> 3 L_11_L_12 >> 3 L_17_L_18 >> 3 L_18_L_19 >> 3 L_19_L_20 >> 3 L_35_L_36 >> 3 L_46_L_47 >> 3 L_8_L_9 >> 3 m3_ge_float >> 3 m3_le_float >> 3 m3_mod_INT32 >> 3 m3_set_member >> 3 m3_shift_UINT32 >> 4 L_7_L_8 >> 5 L_28_L_29 >> 5 m3_ne_float >> 6 L_16_L_17 >> 6 L_21_L_22 >> 6 L_5_L_6 >> 7 L_3_L_4 >> 8 L_10_L_11 >> 8 m3_div_INT32 >> 9 L_0_L_1 >> 10 L_9_L_10 >> 10 m3_round >> 11 L_14_L_15 >> 11 L_6_L_7 >> 11 m3_check_range_INT32 >> 12 m3_sign_extend_INT32 >> 13 L_2_L_3 >> 13 L_4_L_5 >> 15 L_1_L_2 >> 16 m3_pop_INT32 >> 18 m3_min_INT32 >> 22 m3_lt_INT32 >> 22 m3_max_INT32 >> 27 m3_eq_UINT32 >> 27 m3_le_INT32 >> 31 m3_gt_INT32 >> 42 m3_ne_UINT32 >> 57 m3_ge_INT32 >> 64 m3_ne_ADDRESS >> 79 m3_eq_ADDRESS >> 81 m3_extract_UINT32 >> 83 m3_ne_INT32 >> 208 m3_eq_INT32 >> >> where... (judging from the macros in the .c this might be important): >> >> (96)raspberrypi:/big/home2/mika/2/cm3-cvs/cm3/m3-ui/ui/ARMEL_LINUX>gcc -v >> Using built-in specs. >> COLLECT_GCC=gcc >> COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/4.6/lto-wrapper >> Target: arm-linux-gnueabihf >> Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.3-14+rpi1' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --disable-sjlj-exceptions --with-arch=armv6 --with-fpu=vfp --with-float=hard --enable-checking=release --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf >> Thread model: posix >> gcc version 4.6.3 (Debian 4.6.3-14+rpi1) >> >> >> >> Mika From jay.krell at cornell.edu Wed Oct 16 23:05:02 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 16 Oct 2013 21:05:02 +0000 Subject: [M3devel] state of atomic implementation in cm3/C? In-Reply-To: <6A6A0819-5E6B-4F5B-A1AC-EB9AC55067F4@m3w.org> References: <6A6A0819-5E6B-4F5B-A1AC-EB9AC55067F4@m3w.org> Message-ID: eek, good question. No. load/store do the load and store, but not atomically. And other operations are silently omitted! Not good! I'll work on that.. ?- Jay ________________________________ > From: dragisha at m3w.org > Date: Wed, 16 Oct 2013 22:56:28 +0200 > To: m3devel at elegosoft.com > Subject: [M3devel] state of atomic implementation in cm3? > > Jay, had you implemented atomics in M3C? > > TIA > -- > Dragi?a Duri? > dragisha at m3w.org > > > From mika at async.caltech.edu Thu Oct 17 00:27:06 2013 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Wed, 16 Oct 2013 15:27:06 -0700 Subject: [M3devel] ARMEL_LINUX on Raspberry Pi progress report In-Reply-To: References: <20131016203105.88B8B1A208E@async.async.caltech.edu>,

Message-ID: <20131016222706.84B191A208E@async.async.caltech.edu> Jay K writes: >I likely addressed the TLS and m3_eq_ADDRESS problem.=0A= >TLS could use more investigation=2C but ok.=0A= >m3_eq_ADDRESS maybe double checking/testing.=0A= >BadPercentage I can try to look at later...do we have any non-Trestle GUI a= >pps that use Xlib more directly? Try those?=0A= Tetris works (Modula-3). I still haven't gotten cm3cg working on the Raspberry (RPi I guess the groupies call it). Did you think your edits have fixed it? >Try a C/C++ GUI app?=0A= >=0A= >=0A= >=A0- Jay=0A= >=0A= From jay.krell at cornell.edu Thu Oct 17 01:10:08 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 16 Oct 2013 23:10:08 +0000 Subject: [M3devel] ARMEL_LINUX on Raspberry Pi progress report In-Reply-To: <20131016222706.84B191A208E@async.async.caltech.edu> References: <20131016203105.88B8B1A208E@async.async.caltech.edu>,

, <20131016222706.84B191A208E@async.async.caltech.edu> Message-ID: > cm3cg > Did you think your edits have fixed it? I think so. There are some intermediate edits that don't compile/link, but in the past day or two I've built many cm3cg for many targets, on amd64_darwin host (m3-sys/m3cc/src/buildmany.sh, not necessarily all the way through, but I sort broken ones to the end). If you do try it, keep in mind that cm3cg and C-backend aren't necessarily compatible. Passing and returning structs by value is a particular sticking point, which I might be fixing soon, but I don't make promises there to either make the compatible, or keep them compatible. Install them to different places, e.g. /cm3.cm3cg and /cm3.c. That is good that tetris works. Trestle apps do work on Darwin/amd64/c and NT/amd64/c. At least mostly. If you do get cm3cg working, please report back perceived compiler performance differences. And, hopefully, remember, and report again much later when I get "batching" implemented -- cc -c foo.c bar.c instead of cc -c foo.c && cc -c bar.c; on Windows I know it makes a noticable difference. Thank you for bearing with all this, - Jay > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] ARMEL_LINUX on Raspberry Pi progress report > Date: Wed, 16 Oct 2013 15:27:06 -0700 > From: mika at async.caltech.edu > > Jay K writes: > >I likely addressed the TLS and m3_eq_ADDRESS problem.=0A= > >TLS could use more investigation=2C but ok.=0A= > >m3_eq_ADDRESS maybe double checking/testing.=0A= > >BadPercentage I can try to look at later...do we have any non-Trestle GUI a= > >pps that use Xlib more directly? Try those?=0A= > > Tetris works (Modula-3). > > I still haven't gotten cm3cg working on the Raspberry (RPi I guess the > groupies call it). Did you think your edits have fixed it? > > >Try a C/C++ GUI app?=0A= > >=0A= > >=0A= > >=A0- Jay=0A= > >=0A= -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Thu Oct 17 04:23:02 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 16 Oct 2013 21:23:02 -0500 Subject: [M3devel] missing m3makefile in odbc/src/POSIX Message-ID: <525F4A06.60101@lcwb.coop> Why can't' I get cvs to give me m3-db/odbc/src/POSIX/m3makefile? According to rodney at allegheny:~/proj/m3/cm3-head/cm3/m3-db/odbc/src/POSIX$ cvs log m3makefile. ..... total revisions: 5; selected revisions: 5 description: ---------------------------- revision 1.4 date: 2013-09-25 21:47:06 -0500; author: jkrell; state: Exp; lines: +2 -1; commitid: eUlcRHBNTCZJsT6x; restore file TEMPORARILY, until the next release... ---------------------------- revision 1.3 date: 2010-05-09 01:03:19 -0500; author: jkrell; state: dead; lines: +0 -0; commitid: 1EK0bvKwEdaQg4yu; another 1500 lines of cloned C headers gone, now that compiler accepts Win32 calling conventions on all platforms These files were essentially otherwise identical. The log file we define in terms of Compiler.OS. WinDef.HWND is basically ADDRESS on all platforms already. Again the "Win32" directory is now "common" or "only". ---------------------------- it was restored. But I can't get it. My cvs book says, for cvs update, -d option "Without this option, update only operates on the directories present in the working copy; new files are brought down from the repository, but new directories are not." This directory is present in my working copy. Without the m3makefile, I odbc won't build. From dragisha at m3w.org Thu Oct 17 07:54:16 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Thu, 17 Oct 2013 07:54:16 +0200 Subject: [M3devel] state of atomic implementation in cm3/C? In-Reply-To: References: <6A6A0819-5E6B-4F5B-A1AC-EB9AC55067F4@m3w.org> Message-ID: <6AB29C16-FAB8-4214-B01C-4E85752D2675@m3w.org> And what is exact state of Atomic support in cm3cg backend? Anthony? TIA -- Dragi?a Duri? dragisha at m3w.org On Oct 16, 2013, at 11:05 PM, Jay K wrote: > eek, good question. > No. > > > load/store do the load and store, but not atomically. > And other operations are silently omitted! > Not good! > I'll work on that.. > > > - Jay > > ________________________________ >> From: dragisha at m3w.org >> Date: Wed, 16 Oct 2013 22:56:28 +0200 >> To: m3devel at elegosoft.com >> Subject: [M3devel] state of atomic implementation in cm3? >> >> Jay, had you implemented atomics in M3C? >> >> TIA >> -- >> Dragi?a Duri? >> dragisha at m3w.org >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From jay.krell at cornell.edu Thu Oct 17 08:05:29 2013 From: jay.krell at cornell.edu (Jay K) Date: Thu, 17 Oct 2013 06:05:29 +0000 Subject: [M3devel] state of atomic implementation in cm3/C? In-Reply-To: References: <6A6A0819-5E6B-4F5B-A1AC-EB9AC55067F4@m3w.org> <6AB29C16-FAB8-4214-B01C-4E85752D2675@m3w.org>, Message-ID: It has actually always looked pretty complete to me in cm3cg. At least for most architectures. Some were a little challenged, like PowerPC. But maybe the spec wasn't correct? What is needed? Anyway, I'll work on M3C. I did update M3x86.m3 and it might be complete. ?- Jay ________________________________ > Subject: Re: [M3devel] state of atomic implementation in cm3/C? > From: antony.hosking at gmail.com > Date: Thu, 17 Oct 2013 02:03:32 -0400 > CC: jay.krell at cornell.edu; m3devel at elegosoft.com > To: dragisha at m3w.org > > Incomplete. > > On Oct 17, 2013, at 1:54 AM, Dragi?a Duri? > > wrote: > > And what is exact state of Atomic support in cm3cg backend? Anthony? > > TIA > -- > Dragi?a Duri? > dragisha at m3w.org > > > > On Oct 16, 2013, at 11:05 PM, Jay K wrote: > > eek, good question. > No. > > > load/store do the load and store, but not atomically. > And other operations are silently omitted! > Not good! > I'll work on that.. > > > - Jay > > ________________________________ > From: dragisha at m3w.org > Date: Wed, 16 Oct 2013 22:56:28 +0200 > To: m3devel at elegosoft.com > Subject: [M3devel] state of atomic implementation in cm3? > > Jay, had you implemented atomics in M3C? > > TIA > -- > Dragi?a Duri? > dragisha at m3w.org > > > > > From danielal.benavides at bancoagrario.gov.co Thu Oct 17 16:27:57 2013 From: danielal.benavides at bancoagrario.gov.co (Daniel Alejandro Benavides Diaz) Date: Thu, 17 Oct 2013 14:27:57 +0000 Subject: [M3devel] state of atomic implementation in cm3/C? In-Reply-To: References: <6A6A0819-5E6B-4F5B-A1AC-EB9AC55067F4@m3w.org> <6AB29C16-FAB8-4214-B01C-4E85752D2675@m3w.org>,

Message-ID: <1AF4998819C60A40A4CD8C3B6582D3DA3F11774A@DRG008W8SMBX014.bancoagrario.gov.co> Hi all: I would look at research in DEC HPS group on experimental Pascal compiler for DEC MPP prototypes :) Thanks in advance -----Mensaje original----- De: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] En nombre de Jay K Enviado el: Thursday, 17 de October de 2013 1:05 a.m. Para: Antony Hosking; Dragi?a Duri? CC: m3devel Asunto: Re: [M3devel] state of atomic implementation in cm3/C? It has actually always looked pretty complete to me in cm3cg. At least for most architectures. Some were a little challenged, like PowerPC. But maybe the spec wasn't correct? What is needed? Anyway, I'll work on M3C. I did update M3x86.m3 and it might be complete. ?- Jay ________________________________ > Subject: Re: [M3devel] state of atomic implementation in cm3/C? > From: antony.hosking at gmail.com > Date: Thu, 17 Oct 2013 02:03:32 -0400 > CC: jay.krell at cornell.edu; m3devel at elegosoft.com > To: dragisha at m3w.org > > Incomplete. > > On Oct 17, 2013, at 1:54 AM, Dragi?a Duri? > > wrote: > > And what is exact state of Atomic support in cm3cg backend? Anthony? > > TIA > -- > Dragi?a Duri? > dragisha at m3w.org > > > > On Oct 16, 2013, at 11:05 PM, Jay K wrote: > > eek, good question. > No. > > > load/store do the load and store, but not atomically. > And other operations are silently omitted! > Not good! > I'll work on that.. > > > - Jay > > ________________________________ > From: dragisha at m3w.org > Date: Wed, 16 Oct 2013 22:56:28 +0200 > To: m3devel at elegosoft.com > Subject: [M3devel] state of atomic implementation in cm3? > > Jay, had you implemented atomics in M3C? > > TIA > -- > Dragi?a Duri? > dragisha at m3w.org > > > > > From hendrik at topoi.pooq.com Thu Oct 17 17:27:36 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Thu, 17 Oct 2013 11:27:36 -0400 Subject: [M3devel] Licenses and copyright ownership In-Reply-To: <27C4541E-5390-4096-969C-6EFC9EB99E9D@cs.purdue.edu> References: <525EE387.7060703@lcwb.coop> <27C4541E-5390-4096-969C-6EFC9EB99E9D@cs.purdue.edu> Message-ID: <20131017152736.GA32309@topoi.pooq.com> On Wed, Oct 16, 2013 at 03:11:57PM -0400, Tony Hosking wrote: > I think GPL is inherently incompatible with the original DEC/SRC license. You can't distribute executables linking DEC/SRC-licensed code with GPL-d code. It's just that GPL insists on being linked only to GPL'd code (though I gether there are a few exceptions). There's no problem, though, if you are the copyright holder, licensing it with as many licenses as you wish, including the GPL and the DEC licenses, witth working giving the user the right to modufy and redistribute under any of these licenses. This is how so-called dual-licensing, a way of making software fit with software licensed under different licenses. We'd probably do this with all the original Modula 3 code is we could, but it's not us that hold the copyright, so we can't addd more permissive licensing terms. So I'd advise dual-licensing with the user's choice of the SRC license *or* another GPL-compatible license (such as the MIT license. Some find the GPL licenses too restrictive). For more information, consult http://opensource.org -- hendrik From hendrik at topoi.pooq.com Thu Oct 17 17:50:45 2013 From: hendrik at topoi.pooq.com (Hendrik Boom) Date: Thu, 17 Oct 2013 11:50:45 -0400 Subject: [M3devel] Licenses and copyright ownership In-Reply-To: References: <525EE387.7060703@lcwb.coop> <27C4541E-5390-4096-969C-6EFC9EB99E9D@cs.purdue.edu> <525EEAB5.2030403@lcwb.coop> Message-ID: <20131017155045.GB32309@topoi.pooq.com> On Wed, Oct 16, 2013 at 07:55:09PM +0000, Jay K wrote: > Use a "BSD" or "MIT" license. I believe those don't place restrictions on what other code you can link with. Maybe LGPL. LGPL does place some restrictions on linking, but they're not as severe as GPL. > Don't use Apache 2.0 or Mozilla. "Public domain" might seem to be an option, except that (1) It doesn't count as a license; instead, it means tht no license is needed, and (2) Some countries in the world don't recognise it, leaving your users there in legal limbo. > Don't make up your own. OpenBSD folks reject such things as not worth the (lawyer) time to understand.> OpenBSD folks reject the Apache 2.0 license for some reaosn -- maybe the previous, it is long and custom. > Best is modern BSD, which some years ago dropped a clause from the old BSD license. > See OpenBSD, FreeBSD, and NetBSD. For an introduction to dual-licensing, please see the Wikipedia article, http://en.wikipedia.org/wiki/Multi-licensing Especially the section on License Compatibility, which is our concern here. > > ?- Jay > > > ---------------------------------------- > > Date: Wed, 16 Oct 2013 14:36:21 -0500 > > From: rodney_bates at lcwb.coop > > To: m3devel at elegosoft.com > > Subject: Re: [M3devel] Licenses and copyright ownership > > > > > > > > On 10/16/2013 02:11 PM, Tony Hosking wrote: > >> I think GPL is inherently incompatible with the original DEC/SRC license. > > > > So what do you propose instead? > > > >> > >> Antony Hosking | Associate Professor | Computer Science | Purdue University > >> 305 N. University Street | West Lafayette | IN 47907 | USA > >> Mobile +1 765 427 5484 > >> > >> > >> > >> > >> > >> On Oct 16, 2013, at 3:05 PM, "Rodney M. Bates" wrote: > >> > >>> I have checked in a few written-from-scratch source files without copyright/license > >>> notices recently. I plan to fix this, but wonder if there is a consensus about > >>> the choices here. We already have a hodge-podge of copyright owners and licenses > >>> in the Modula-3 repository. That may be difficult or impossible to fix, but I > >>> would like to move things in the right direction when adding all-new code. > >>> > >>> I checked in some earlier ones naming myself as owner and GPL as license. > >>> But I recall reading some hints on this list suggesting that people felt > >>> that the GPL was not a good idea here. > >>> > >>> Also, is there any organization that would be good to take ownership where > >>> possible, in order to get Modula-3 more consistent in this regard? > >>> > >>> > >> > >> > > From jay.krell at cornell.edu Thu Oct 17 21:25:06 2013 From: jay.krell at cornell.edu (Jay K) Date: Thu, 17 Oct 2013 19:25:06 +0000 Subject: [M3devel] Licenses and copyright ownership In-Reply-To: <20131017155045.GB32309@topoi.pooq.com> References: <525EE387.7060703@lcwb.coop>, <27C4541E-5390-4096-969C-6EFC9EB99E9D@cs.purdue.edu>, <525EEAB5.2030403@lcwb.coop>, , <20131017155045.GB32309@topoi.pooq.com> Message-ID: I find dual licensing confusing and I sympathize with the OpenBSD preference for licensing simplicity. I also do wonder when I copy/paste/edit, if I must keep the DEC license. I also wonder if we or anyone can relicense the DEC stuff, i.e. to be BSD licensed. I fear not. - Jay > Date: Thu, 17 Oct 2013 11:50:45 -0400 > From: hendrik at topoi.pooq.com > To: m3devel at elegosoft.com > Subject: Re: [M3devel] Licenses and copyright ownership > > On Wed, Oct 16, 2013 at 07:55:09PM +0000, Jay K wrote: > > Use a "BSD" or "MIT" license. > > I believe those don't place restrictions on what other code you can > link with. > > Maybe LGPL. > > LGPL does place some restrictions on linking, but they're not as > severe as GPL. > > > Don't use Apache 2.0 or Mozilla. > > "Public domain" might seem to be an option, except that > > (1) It doesn't count as a license; instead, it means tht no license is > needed, > > and > > (2) Some countries in the world don't recognise it, leaving your users > there in legal limbo. > > > Don't make up your own. OpenBSD folks reject such things as not worth the (lawyer) time to understand.> OpenBSD folks reject the Apache 2.0 license for some reaosn -- maybe the previous, it is long and custom. > > Best is modern BSD, which some years ago dropped a clause from the old BSD license. > > See OpenBSD, FreeBSD, and NetBSD. > > For an introduction to dual-licensing, please see the Wikipedia > article, http://en.wikipedia.org/wiki/Multi-licensing > Especially the section on License Compatibility, which is our concern > here. > > > > > - Jay > > > > > > ---------------------------------------- > > > Date: Wed, 16 Oct 2013 14:36:21 -0500 > > > From: rodney_bates at lcwb.coop > > > To: m3devel at elegosoft.com > > > Subject: Re: [M3devel] Licenses and copyright ownership > > > > > > > > > > > > On 10/16/2013 02:11 PM, Tony Hosking wrote: > > >> I think GPL is inherently incompatible with the original DEC/SRC license. > > > > > > So what do you propose instead? > > > > > >> > > >> Antony Hosking | Associate Professor | Computer Science | Purdue University > > >> 305 N. University Street | West Lafayette | IN 47907 | USA > > >> Mobile +1 765 427 5484 > > >> > > >> > > >> > > >> > > >> > > >> On Oct 16, 2013, at 3:05 PM, "Rodney M. Bates" wrote: > > >> > > >>> I have checked in a few written-from-scratch source files without copyright/license > > >>> notices recently. I plan to fix this, but wonder if there is a consensus about > > >>> the choices here. We already have a hodge-podge of copyright owners and licenses > > >>> in the Modula-3 repository. That may be difficult or impossible to fix, but I > > >>> would like to move things in the right direction when adding all-new code. > > >>> > > >>> I checked in some earlier ones naming myself as owner and GPL as license. > > >>> But I recall reading some hints on this list suggesting that people felt > > >>> that the GPL was not a good idea here. > > >>> > > >>> Also, is there any organization that would be good to take ownership where > > >>> possible, in order to get Modula-3 more consistent in this regard? > > >>> > > >>> > > >> > > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Sat Oct 19 02:44:16 2013 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Fri, 18 Oct 2013 17:44:16 -0700 Subject: [M3devel] attempting to use cm3cg on Raspberry Message-ID: <20131019004416.435071A208E@async.async.caltech.edu> Jay, Finally got around to attempting cm3cg on the Raspberry. Lots of things compile, then... RTHeapRep.ms: Assembler messages: RTHeapRep.ms:449: Error: selected processor does not support ARM mode `sfmfd f4,4,[sp]!' RTHeapRep.ms:661: Error: selected processor does not support ARM mode `lfmfd f4,4,[sp]!' RTHeapRep.ms:721: Error: selected processor does not support ARM mode `sfmfd f4,4,[sp]!' RTHeapRep.ms:1302: Error: selected processor does not support ARM mode `lfmfd f4,4,[sp]!' I understand this has something to do with floating point. There are a few other instructions that show up. Now if I write a little C program that uses floats and run gcc -v, I see this: (173)raspberrypi:~>cc -v x.c Using built-in specs. COLLECT_GCC=cc COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/4.6/lto-wrapper Target: arm-linux-gnueabihf Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.3-14+rpi1' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --disable-sjlj-exceptions --with-arch=armv6 --with-fpu=vfp --with-float=hard --enable-checking=release --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf Thread model: posix gcc version 4.6.3 (Debian 4.6.3-14+rpi1) COLLECT_GCC_OPTIONS='-v' '-march=armv6' '-mfloat-abi=hard' '-mfpu=vfp' /usr/lib/gcc/arm-linux-gnueabihf/4.6/cc1 -quiet -v -imultilib . -imultiarch arm-linux-gnueabihf x.c -quiet -dumpbase x.c -march=armv6 -mfloat-abi=hard -mfpu=vfp -auxbase x -version -o /tmp/ccJfxZ1e.s GNU C (Debian 4.6.3-14+rpi1) version 4.6.3 (arm-linux-gnueabihf) compiled by GNU C version 4.6.3, GMP version 5.0.5, MPFR version 3.1.0-p10, MPC version 0.9 GGC heuristics: --param ggc-min-expand=59 --param ggc-min-heapsize=56092 ignoring nonexistent directory "/usr/local/include/arm-linux-gnueabihf" ignoring nonexistent directory "/usr/lib/gcc/arm-linux-gnueabihf/4.6/../../../../arm-linux-gnueabihf/include" #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc/arm-linux-gnueabihf/4.6/include /usr/local/include /usr/lib/gcc/arm-linux-gnueabihf/4.6/include-fixed /usr/include/arm-linux-gnueabihf /usr/include End of search list. GNU C (Debian 4.6.3-14+rpi1) version 4.6.3 (arm-linux-gnueabihf) compiled by GNU C version 4.6.3, GMP version 5.0.5, MPFR version 3.1.0-p10, MPC version 0.9 GGC heuristics: --param ggc-min-expand=59 --param ggc-min-heapsize=56092 Compiler executable checksum: cf78bfe2d99d4ca6e0637950db1b4acd COLLECT_GCC_OPTIONS='-v' '-march=armv6' '-mfloat-abi=hard' '-mfpu=vfp' as -march=armv6 -mfloat-abi=hard -mfpu=vfp -meabi=5 -o /tmp/ccirJ34v.o /tmp/ccJfxZ1e.s COMPILER_PATH=/usr/lib/gcc/arm-linux-gnueabihf/4.6/:/usr/lib/gcc/arm-linux-gnueabihf/4.6/:/usr/lib/gcc/arm-linux-gnueabihf/:/usr/lib/gcc/arm-linux-gnueabihf/4.6/:/usr/lib/gcc/arm-linux-gnueabihf/ LIBRARY_PATH=/usr/lib/gcc/arm-linux-gnueabihf/4.6/:/usr/lib/gcc/arm-linux-gnueabihf/4.6/../../../arm-linux-gnueabihf/:/usr/lib/gcc/arm-linux-gnueabihf/4.6/../../../:/lib/arm-linux-gnueabihf/:/lib/:/usr/lib/arm-linux-gnueabihf/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-march=armv6' '-mfloat-abi=hard' '-mfpu=vfp' /usr/lib/gcc/arm-linux-gnueabihf/4.6/collect2 --sysroot=/ --build-id --no-add-needed --eh-frame-hdr -dynamic-linker /lib/ld-linux-armhf.so.3 -X --hash-style=both -m armelf_linux_eabi /usr/lib/gcc/arm-linux-gnueabihf/4.6/../../../arm-linux-gnueabihf/crt1.o /usr/lib/gcc/arm-linux-gnueabihf/4.6/../../../arm-linux-gnueabihf/crti.o /usr/lib/gcc/arm-linux-gnueabihf/4.6/crtbegin.o -L/usr/lib/gcc/arm-linux-gnueabihf/4.6 -L/usr/lib/gcc/arm-linux-gnueabihf/4.6/../../../arm-linux-gnueabihf -L/usr/lib/gcc/arm-linux-gnueabihf/4.6/../../.. -L/lib/arm-linux-gnueabihf -L/usr/lib/arm-linux-gnueabihf /tmp/ccirJ34v.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/arm-linux-gnueabihf/4.6/crtend.o /usr/lib/gcc/arm-linux-gnueabihf/4.6/../../../arm-linux-gnueabihf/crtn.o But if I try to reproduce the same options with the CM3 tools I get this: raspberrypi:/big/home2/mika/2/cm3-cvs/cm3/m3-libs/m3core/ARMEL_LINUX# /usr/local/cm3//bin/cm3cg -march=armv6 -mfloat-abi=hard -mfpu=vfp -auxbase x -mfloat-abi=hard -quiet -fno-reorder-blocks -funwind-tables -gstabs+ RTHeapRep.mc -o RTHeapRep.ms cm3cg: sorry, unimplemented: -mfloat-abi=hard and VFP I can get things to compile with "-mfloat-abi=soft" but I suspect performance will suffer a lot... Mika From mika at async.caltech.edu Sat Oct 19 03:26:02 2013 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Fri, 18 Oct 2013 18:26:02 -0700 Subject: [M3devel] more cm3cg on Raspberry Pi Message-ID: <20131019012602.C96441A208E@async.async.caltech.edu> After setting up for soft float, I got a lot of these warnings/errors... new source -> compiling RTHeapInfo.m3 RTHeapInfo.ms: Assembler messages: RTHeapInfo.ms:859: rdhi, rdlo and rm must all be different RTHeapInfo.ms:907: rdhi, rdlo and rm must all be different RTHeapInfo.ms:927: rdhi, rdlo and rm must all be different new source -> compiling RTHeapMap.i3 This is with the following configuration: in /usr/local/cm3 I have the C-generating compiler installed. It seems to mostly work, as discussed. Then I run boot2.sh boot.sh finally ends with the following output, which doesn't look quite right: == package /big/home2/mika/2/cm3-cvs/cm3/m3-sys/mklib == +++ /usr/local/cm3/bin/cm3 -build -DROOT=/big/home2/mika/2/cm3-cvs/cm3 +++ --- building in ARMEL_LINUX --- ignoring ../src/m3overrides new source -> compiling Main.m3 -> linking mklib ==> /big/home2/mika/2/cm3-cvs/cm3/m3-sys/mklib done +++ /usr/local/cm3/bin/cm3 -ship -DROOT=/big/home2/mika/2/cm3-cvs/cm3 +++ --- shipping from ARMEL_LINUX --- . => /usr/local/cm3/pkg/mklib/ARMEL_LINUX .M3EXPORTS .M3WEB ../src => /usr/local/cm3/pkg/mklib/src Main.m3 . => /usr/local/cm3/bin mklib ==> /big/home2/mika/2/cm3-cvs/cm3/m3-sys/mklib done /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cggen/ARMEL_LINUX/m3cggen > /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/gcc/gcc/m3cg/m3cg.h mkdir -p /usr/local/cm3/bin cp -Pv /big/home2/mika/2/cm3-cvs/cm3/m3-sys/cm3/ARMEL_LINUX/cm3 /usr/local/cm3/bin/cm3 Traceback (most recent call last): File "./upgrade.py", line 72, in reload(pylib) # compiler host type may have changed and need to recompute stuff File "/big/home2/mika/2/cm3-cvs/cm3/scripts/python/pylib.py", line 650, in if Host.endswith("_NT") or Host == "NT386": AttributeError: 'NoneType' object has no attribute 'endswith' raspberrypi:/big/home2/mika/2/cm3-cvs/cm3/scripts/python# Mika From jay.krell at cornell.edu Sat Oct 19 04:33:21 2013 From: jay.krell at cornell.edu (Jay K) Date: Sat, 19 Oct 2013 02:33:21 +0000 Subject: [M3devel] more cm3cg on Raspberry Pi In-Reply-To: <20131019012602.C96441A208E@async.async.caltech.edu> References: <20131019012602.C96441A208E@async.async.caltech.edu> Message-ID: Oh, sorry, here are things to try edit m3-sys/m3cc/src/platforms.quake look for ARMEL_LINUX, change the right hand side to arm-linux-gnueabihf and/or in src/m3makefile, you want to add -with-hard-float or -with-hardfloat..no, wait, from your other mail: ?And, really, the guide here is what you showed for gcc:? ?Configured with: ../src/configure ? ? ? -v \? ? ? ... ? ? ? --with-arch=armv6 ? ? ? --with-fpu=vfp? ? ? --with-float=hard ? ? ? --target=arm-linux-gnueabihf? ?One/some/all of those are relevant.? ?You might as well go ahead and throw them all in for now.? ?Hey -- isn't that C backend convenient? :)? ?- Jay ---------------------------------------- > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: more cm3cg on Raspberry Pi > Date: Fri, 18 Oct 2013 18:26:02 -0700 > From: mika at async.caltech.edu > > After setting up for soft float, I got a lot of these warnings/errors... > > new source -> compiling RTHeapInfo.m3 > RTHeapInfo.ms: Assembler messages: > RTHeapInfo.ms:859: rdhi, rdlo and rm must all be different > RTHeapInfo.ms:907: rdhi, rdlo and rm must all be different > RTHeapInfo.ms:927: rdhi, rdlo and rm must all be different > new source -> compiling RTHeapMap.i3 > > This is with the following configuration: > > in /usr/local/cm3 I have the C-generating compiler installed. It seems to mostly work, as discussed. > > Then I run boot2.sh > > boot.sh finally ends with the following output, which doesn't look quite right: > > == package /big/home2/mika/2/cm3-cvs/cm3/m3-sys/mklib == > > +++ /usr/local/cm3/bin/cm3 -build -DROOT=/big/home2/mika/2/cm3-cvs/cm3 +++ > --- building in ARMEL_LINUX --- > > ignoring ../src/m3overrides > > new source -> compiling Main.m3 > -> linking mklib > ==> /big/home2/mika/2/cm3-cvs/cm3/m3-sys/mklib done > > +++ /usr/local/cm3/bin/cm3 -ship -DROOT=/big/home2/mika/2/cm3-cvs/cm3 +++ > --- shipping from ARMEL_LINUX --- > > . => /usr/local/cm3/pkg/mklib/ARMEL_LINUX > .M3EXPORTS .M3WEB > ../src => /usr/local/cm3/pkg/mklib/src > Main.m3 > . => /usr/local/cm3/bin > mklib > ==> /big/home2/mika/2/cm3-cvs/cm3/m3-sys/mklib done > > /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cggen/ARMEL_LINUX/m3cggen> /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/gcc/gcc/m3cg/m3cg.h > mkdir -p /usr/local/cm3/bin > cp -Pv /big/home2/mika/2/cm3-cvs/cm3/m3-sys/cm3/ARMEL_LINUX/cm3 /usr/local/cm3/bin/cm3 > Traceback (most recent call last): > File "./upgrade.py", line 72, in > reload(pylib) # compiler host type may have changed and need to recompute stuff > File "/big/home2/mika/2/cm3-cvs/cm3/scripts/python/pylib.py", line 650, in > if Host.endswith("_NT") or Host == "NT386": > AttributeError: 'NoneType' object has no attribute 'endswith' > raspberrypi:/big/home2/mika/2/cm3-cvs/cm3/scripts/python# > > Mika From jay.krell at cornell.edu Sat Oct 19 05:04:45 2013 From: jay.krell at cornell.edu (Jay K) Date: Sat, 19 Oct 2013 03:04:45 +0000 Subject: [M3devel] more cm3cg on Raspberry Pi In-Reply-To: References: <20131019012602.C96441A208E@async.async.caltech.edu>, Message-ID: Debian has an armhf port, which suggests ARMHF_LINUX for us. But their armhf port requires v7. Raspberry Pi is v6. It wouldn't be great if their armhf binaries didn't work where our armhf_linux was meant. So we'd want to call it armhfv6_linux, armv6hf_linux or armv6hfvfp_linux or somesuch. For now I suggest repurposing ARMEL_LINUX as v6/hf/vfp, until/unless we get users of older arm_linux systems. I'll do this shortly. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: mika at async.caltech.edu > Date: Sat, 19 Oct 2013 02:33:21 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] more cm3cg on Raspberry Pi > > Oh, sorry, here are things to try > > edit m3-sys/m3cc/src/platforms.quake > look for ARMEL_LINUX, change the right hand side to arm-linux-gnueabihf > > and/or in src/m3makefile, you want to add -with-hard-float or -with-hardfloat..no, wait, from your other mail: > > And, really, the guide here is what you showed for gcc: > > Configured with: ../src/configure > -v \ > ... > --with-arch=armv6 > --with-fpu=vfp > --with-float=hard > --target=arm-linux-gnueabihf > > One/some/all of those are relevant. > You might as well go ahead and throw them all in for now. > > Hey -- isn't that C backend convenient? :) > > > - Jay > > ---------------------------------------- >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: more cm3cg on Raspberry Pi >> Date: Fri, 18 Oct 2013 18:26:02 -0700 >> From: mika at async.caltech.edu >> >> After setting up for soft float, I got a lot of these warnings/errors... >> >> new source -> compiling RTHeapInfo.m3 >> RTHeapInfo.ms: Assembler messages: >> RTHeapInfo.ms:859: rdhi, rdlo and rm must all be different >> RTHeapInfo.ms:907: rdhi, rdlo and rm must all be different >> RTHeapInfo.ms:927: rdhi, rdlo and rm must all be different >> new source -> compiling RTHeapMap.i3 >> >> This is with the following configuration: >> >> in /usr/local/cm3 I have the C-generating compiler installed. It seems to mostly work, as discussed. >> >> Then I run boot2.sh >> >> boot.sh finally ends with the following output, which doesn't look quite right: >> >> == package /big/home2/mika/2/cm3-cvs/cm3/m3-sys/mklib == >> >> +++ /usr/local/cm3/bin/cm3 -build -DROOT=/big/home2/mika/2/cm3-cvs/cm3 +++ >> --- building in ARMEL_LINUX --- >> >> ignoring ../src/m3overrides >> >> new source -> compiling Main.m3 >> -> linking mklib >> ==> /big/home2/mika/2/cm3-cvs/cm3/m3-sys/mklib done >> >> +++ /usr/local/cm3/bin/cm3 -ship -DROOT=/big/home2/mika/2/cm3-cvs/cm3 +++ >> --- shipping from ARMEL_LINUX --- >> >> . => /usr/local/cm3/pkg/mklib/ARMEL_LINUX >> .M3EXPORTS .M3WEB >> ../src => /usr/local/cm3/pkg/mklib/src >> Main.m3 >> . => /usr/local/cm3/bin >> mklib >> ==> /big/home2/mika/2/cm3-cvs/cm3/m3-sys/mklib done >> >> /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cggen/ARMEL_LINUX/m3cggen> /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/gcc/gcc/m3cg/m3cg.h >> mkdir -p /usr/local/cm3/bin >> cp -Pv /big/home2/mika/2/cm3-cvs/cm3/m3-sys/cm3/ARMEL_LINUX/cm3 /usr/local/cm3/bin/cm3 >> Traceback (most recent call last): >> File "./upgrade.py", line 72, in >> reload(pylib) # compiler host type may have changed and need to recompute stuff >> File "/big/home2/mika/2/cm3-cvs/cm3/scripts/python/pylib.py", line 650, in >> if Host.endswith("_NT") or Host == "NT386": >> AttributeError: 'NoneType' object has no attribute 'endswith' >> raspberrypi:/big/home2/mika/2/cm3-cvs/cm3/scripts/python# >> >> Mika From mika at async.caltech.edu Sat Oct 19 21:21:35 2013 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Sat, 19 Oct 2013 12:21:35 -0700 Subject: [M3devel] more cm3cg on Raspberry Pi In-Reply-To: References: <20131019012602.C96441A208E@async.async.caltech.edu> Message-ID: <20131019192135.5F59D1A208E@async.async.caltech.edu> Hi Jay, Yes the C backend is certainly convenient and cool. No argument there. But all this has me thinking about something... if the code generated by the C backend isn't compatible with that generated by cm3cg, shouldn't the target names be different, so that you could even have both systems installed at the same time. E.g., ARMEL_LINUX_C and ARMEL_LINUX (or whatever). Of course it makes it a bit more fiddly to bootstrap since you're cross-compiling even though it's actually native..? I haven't thought through all the ramifications. Is it difficult to change the name? Would it be desirable? Mika Jay K writes: >Oh=2C sorry=2C here are things to try=0A= >=0A= >edit m3-sys/m3cc/src/platforms.quake=0A= >look for ARMEL_LINUX=2C change the right hand side to arm-linux-gnueabihf= >=0A= >=0A= >and/or in src/m3makefile=2C you want to add -with-hard-float or -with-hardf= >loat..no=2C wait=2C from your other mail:=0A= >=0A= >=A0And=2C really=2C the guide here is what you showed for gcc:=A0=0A= >=0A= >=A0Configured with: ../src/configure =A0=0A= >=A0 =A0 -v \=A0=0A= >=A0 =A0 ... =A0=0A= >=A0 =A0 --with-arch=3Darmv6 =A0=0A= >=A0 =A0 --with-fpu=3Dvfp=A0=0A= >=A0 =A0 --with-float=3Dhard =A0=0A= >=A0 =A0 --target=3Darm-linux-gnueabihf=A0=0A= >=0A= >=A0One/some/all of those are relevant.=A0=0A= >=A0You might as well go ahead and throw them all in for now.=A0=0A= >=0A= >=A0Hey -- isn't that C backend convenient? :)=A0=0A= >=0A= >=0A= >=A0- Jay=0A= >=0A= >----------------------------------------=0A= >> To: jay.krell at cornell.edu=0A= >> CC: m3devel at elegosoft.com=0A= >> Subject: more cm3cg on Raspberry Pi=0A= >> Date: Fri=2C 18 Oct 2013 18:26:02 -0700=0A= >> From: mika at async.caltech.edu=0A= >>=0A= >> After setting up for soft float=2C I got a lot of these warnings/errors..= >.=0A= >>=0A= >> new source -> compiling RTHeapInfo.m3=0A= >> RTHeapInfo.ms: Assembler messages:=0A= >> RTHeapInfo.ms:859: rdhi=2C rdlo and rm must all be different=0A= >> RTHeapInfo.ms:907: rdhi=2C rdlo and rm must all be different=0A= >> RTHeapInfo.ms:927: rdhi=2C rdlo and rm must all be different=0A= >> new source -> compiling RTHeapMap.i3=0A= >>=0A= >> This is with the following configuration:=0A= >>=0A= >> in /usr/local/cm3 I have the C-generating compiler installed. It seems to= > mostly work=2C as discussed.=0A= >>=0A= >> Then I run boot2.sh=0A= >>=0A= >> boot.sh finally ends with the following output=2C which doesn't look quit= >e right:=0A= >>=0A= >> =3D=3D package /big/home2/mika/2/cm3-cvs/cm3/m3-sys/mklib =3D=3D=0A= >>=0A= >> +++ /usr/local/cm3/bin/cm3 -build -DROOT=3D/big/home2/mika/2/cm3-cvs/cm3 = >+++=0A= >> --- building in ARMEL_LINUX ---=0A= >>=0A= >> ignoring ../src/m3overrides=0A= >>=0A= >> new source -> compiling Main.m3=0A= >> -> linking mklib=0A= >> =3D=3D> /big/home2/mika/2/cm3-cvs/cm3/m3-sys/mklib done=0A= >>=0A= >> +++ /usr/local/cm3/bin/cm3 -ship -DROOT=3D/big/home2/mika/2/cm3-cvs/cm3 += >++=0A= >> --- shipping from ARMEL_LINUX ---=0A= >>=0A= >> . =3D> /usr/local/cm3/pkg/mklib/ARMEL_LINUX=0A= >> .M3EXPORTS .M3WEB=0A= >> ../src =3D> /usr/local/cm3/pkg/mklib/src=0A= >> Main.m3=0A= >> . =3D> /usr/local/cm3/bin=0A= >> mklib=0A= >> =3D=3D> /big/home2/mika/2/cm3-cvs/cm3/m3-sys/mklib done=0A= >>=0A= >> /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cggen/ARMEL_LINUX/m3cggen> /big/ho= >me2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/gcc/gcc/m3cg/m3cg.h=0A= >> mkdir -p /usr/local/cm3/bin=0A= >> cp -Pv /big/home2/mika/2/cm3-cvs/cm3/m3-sys/cm3/ARMEL_LINUX/cm3 /usr/loca= >l/cm3/bin/cm3=0A= >> Traceback (most recent call last):=0A= >> File "./upgrade.py"=2C line 72=2C in =0A= >> reload(pylib) # compiler host type may have changed and need to recompute= > stuff=0A= >> File "/big/home2/mika/2/cm3-cvs/cm3/scripts/python/pylib.py"=2C line 650= >=2C in =0A= >> if Host.endswith("_NT") or Host =3D=3D "NT386":=0A= >> AttributeError: 'NoneType' object has no attribute 'endswith'=0A= >> raspberrypi:/big/home2/mika/2/cm3-cvs/cm3/scripts/python#=0A= >>=0A= >> Mika = From jay.krell at cornell.edu Sat Oct 19 21:44:00 2013 From: jay.krell at cornell.edu (Jay K) Date: Sat, 19 Oct 2013 19:44:00 +0000 Subject: [M3devel] more cm3cg on Raspberry Pi In-Reply-To: <20131019192135.5F59D1A208E@async.async.caltech.edu> References: <20131019012602.C96441A208E@async.async.caltech.edu> , <20131019192135.5F59D1A208E@async.async.caltech.edu> Message-ID: Yes, maybe. But the C backend works for everything. We'd have to double the number of targets, for little gain. You can't install both to the same root either way. The pkg directories are separate, but bin and lib are not. Upgrade.py from on to the other should work asis. ?- Jay ---------------------------------------- > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: more cm3cg on Raspberry Pi > Date: Sat, 19 Oct 2013 12:21:35 -0700 > From: mika at async.caltech.edu > > Hi Jay, > > Yes the C backend is certainly convenient and cool. No argument there. > > But all this has me thinking about something... if the code generated by > the C backend isn't compatible with that generated by cm3cg, shouldn't > the target names be different, so that you could even have both systems > installed at the same time. E.g., ARMEL_LINUX_C and ARMEL_LINUX > (or whatever). Of course it makes it a bit more fiddly to bootstrap > since you're cross-compiling even though it's actually native..? I haven't > thought through all the ramifications. Is it difficult to change the name? > Would it be desirable? > > Mika > > Jay K writes: >>Oh=2C sorry=2C here are things to try=0A= >>=0A= >>edit m3-sys/m3cc/src/platforms.quake=0A= >>look for ARMEL_LINUX=2C change the right hand side to arm-linux-gnueabihf= >>=0A= >>=0A= >>and/or in src/m3makefile=2C you want to add -with-hard-float or -with-hardf= >>loat..no=2C wait=2C from your other mail:=0A= >>=0A= >>=A0And=2C really=2C the guide here is what you showed for gcc:=A0=0A= >>=0A= >>=A0Configured with: ../src/configure =A0=0A= >>=A0 =A0 -v \=A0=0A= >>=A0 =A0 ... =A0=0A= >>=A0 =A0 --with-arch=3Darmv6 =A0=0A= >>=A0 =A0 --with-fpu=3Dvfp=A0=0A= >>=A0 =A0 --with-float=3Dhard =A0=0A= >>=A0 =A0 --target=3Darm-linux-gnueabihf=A0=0A= >>=0A= >>=A0One/some/all of those are relevant.=A0=0A= >>=A0You might as well go ahead and throw them all in for now.=A0=0A= >>=0A= >>=A0Hey -- isn't that C backend convenient? :)=A0=0A= >>=0A= >>=0A= >>=A0- Jay=0A= >>=0A= >>----------------------------------------=0A= >>> To: jay.krell at cornell.edu=0A= >>> CC: m3devel at elegosoft.com=0A= >>> Subject: more cm3cg on Raspberry Pi=0A= >>> Date: Fri=2C 18 Oct 2013 18:26:02 -0700=0A= >>> From: mika at async.caltech.edu=0A= >>>=0A= >>> After setting up for soft float=2C I got a lot of these warnings/errors..= >>.=0A= >>>=0A= >>> new source -> compiling RTHeapInfo.m3=0A= >>> RTHeapInfo.ms: Assembler messages:=0A= >>> RTHeapInfo.ms:859: rdhi=2C rdlo and rm must all be different=0A= >>> RTHeapInfo.ms:907: rdhi=2C rdlo and rm must all be different=0A= >>> RTHeapInfo.ms:927: rdhi=2C rdlo and rm must all be different=0A= >>> new source -> compiling RTHeapMap.i3=0A= >>>=0A= >>> This is with the following configuration:=0A= >>>=0A= >>> in /usr/local/cm3 I have the C-generating compiler installed. It seems to= >> mostly work=2C as discussed.=0A= >>>=0A= >>> Then I run boot2.sh=0A= >>>=0A= >>> boot.sh finally ends with the following output=2C which doesn't look quit= >>e right:=0A= >>>=0A= >>> =3D=3D package /big/home2/mika/2/cm3-cvs/cm3/m3-sys/mklib =3D=3D=0A= >>>=0A= >>> +++ /usr/local/cm3/bin/cm3 -build -DROOT=3D/big/home2/mika/2/cm3-cvs/cm3 = >>+++=0A= >>> --- building in ARMEL_LINUX ---=0A= >>>=0A= >>> ignoring ../src/m3overrides=0A= >>>=0A= >>> new source -> compiling Main.m3=0A= >>> -> linking mklib=0A= >>> =3D=3D> /big/home2/mika/2/cm3-cvs/cm3/m3-sys/mklib done=0A= >>>=0A= >>> +++ /usr/local/cm3/bin/cm3 -ship -DROOT=3D/big/home2/mika/2/cm3-cvs/cm3 += >>++=0A= >>> --- shipping from ARMEL_LINUX ---=0A= >>>=0A= >>> . =3D> /usr/local/cm3/pkg/mklib/ARMEL_LINUX=0A= >>> .M3EXPORTS .M3WEB=0A= >>> ../src =3D> /usr/local/cm3/pkg/mklib/src=0A= >>> Main.m3=0A= >>> . =3D> /usr/local/cm3/bin=0A= >>> mklib=0A= >>> =3D=3D> /big/home2/mika/2/cm3-cvs/cm3/m3-sys/mklib done=0A= >>>=0A= >>> /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cggen/ARMEL_LINUX/m3cggen> /big/ho= >>me2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/gcc/gcc/m3cg/m3cg.h=0A= >>> mkdir -p /usr/local/cm3/bin=0A= >>> cp -Pv /big/home2/mika/2/cm3-cvs/cm3/m3-sys/cm3/ARMEL_LINUX/cm3 /usr/loca= >>l/cm3/bin/cm3=0A= >>> Traceback (most recent call last):=0A= >>> File "./upgrade.py"=2C line 72=2C in =0A= >>> reload(pylib) # compiler host type may have changed and need to recompute= >> stuff=0A= >>> File "/big/home2/mika/2/cm3-cvs/cm3/scripts/python/pylib.py"=2C line 650= >>=2C in =0A= >>> if Host.endswith("_NT") or Host =3D=3D "NT386":=0A= >>> AttributeError: 'NoneType' object has no attribute 'endswith'=0A= >>> raspberrypi:/big/home2/mika/2/cm3-cvs/cm3/scripts/python#=0A= >>>=0A= >>> Mika = From mika at async.caltech.edu Sat Oct 19 21:52:55 2013 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Sat, 19 Oct 2013 12:52:55 -0700 Subject: [M3devel] more cm3cg on Raspberry Pi In-Reply-To: References: <20131019012602.C96441A208E@async.async.caltech.edu> , <20131019192135.5F59D1A208E@async.async.caltech.edu> Message-ID: <20131019195255.306DE1A208E@async.async.caltech.edu> The gain would be that I could compile my whole tree of non-CM3 software (which is a fair fraction of the size of the CM3 tree), as well as the CM3 tree itself, with both compilers without having to clean everything and start over in between. On a slow machine it can make a difference. But sure in the long run I'd probably stick with one or the other, and I suspect most people would do too. On the other hand, for as long as there's debug work going on on either or both of the compilers in question it seems it would be helpful to be able to have both. And yes I get that they would have to be installed in different places. But they wouldn't be able to step on each other's toes if the derived directories were named differently... Well not a big deal, really. I now tar and rm and untar to switch. Jay K writes: >Yes=2C maybe. But the C backend works for everything.=0A= >We'd have to double the number of targets=2C for little gain.=0A= >=0A= >You can't install both to the same root either way.=0A= >The pkg directories are separate=2C but bin and lib are not.=0A= >=0A= >Upgrade.py from on to the other should work asis.=0A= >=0A= >=A0- Jay=0A= >=0A= >----------------------------------------=0A= >> To: jay.krell at cornell.edu=0A= >> CC: m3devel at elegosoft.com=0A= >> Subject: Re: more cm3cg on Raspberry Pi=0A= >> Date: Sat=2C 19 Oct 2013 12:21:35 -0700=0A= >> From: mika at async.caltech.edu=0A= >>=0A= >> Hi Jay=2C=0A= >>=0A= >> Yes the C backend is certainly convenient and cool. No argument there.=0A= >>=0A= >> But all this has me thinking about something... if the code generated by= >=0A= >> the C backend isn't compatible with that generated by cm3cg=2C shouldn't= >=0A= >> the target names be different=2C so that you could even have both systems= >=0A= >> installed at the same time. E.g.=2C ARMEL_LINUX_C and ARMEL_LINUX=0A= >> (or whatever). Of course it makes it a bit more fiddly to bootstrap=0A= >> since you're cross-compiling even though it's actually native..? I haven'= >t=0A= >> thought through all the ramifications. Is it difficult to change the name= >?=0A= >> Would it be desirable?=0A= >>=0A= >> Mika=0A= >>=0A= >> Jay K writes:=0A= >>>Oh=3D2C sorry=3D2C here are things to try=3D0A=3D=0A= >>>=3D0A=3D=0A= >>>edit m3-sys/m3cc/src/platforms.quake=3D0A=3D=0A= >>>look for ARMEL_LINUX=3D2C change the right hand side to arm-linux-gnueabi= >hf=3D=0A= >>>=3D0A=3D=0A= >>>=3D0A=3D=0A= >>>and/or in src/m3makefile=3D2C you want to add -with-hard-float or -with-h= >ardf=3D=0A= >>>loat..no=3D2C wait=3D2C from your other mail:=3D0A=3D=0A= >>>=3D0A=3D=0A= >>>=3DA0And=3D2C really=3D2C the guide here is what you showed for gcc:=3DA0= >=3D0A=3D=0A= >>>=3D0A=3D=0A= >>>=3DA0Configured with: ../src/configure =3DA0=3D0A=3D=0A= >>>=3DA0 =3DA0 -v \=3DA0=3D0A=3D=0A= >>>=3DA0 =3DA0 ... =3DA0=3D0A=3D=0A= >>>=3DA0 =3DA0 --with-arch=3D3Darmv6 =3DA0=3D0A=3D=0A= >>>=3DA0 =3DA0 --with-fpu=3D3Dvfp=3DA0=3D0A=3D=0A= >>>=3DA0 =3DA0 --with-float=3D3Dhard =3DA0=3D0A=3D=0A= >>>=3DA0 =3DA0 --target=3D3Darm-linux-gnueabihf=3DA0=3D0A=3D=0A= >>>=3D0A=3D=0A= >>>=3DA0One/some/all of those are relevant.=3DA0=3D0A=3D=0A= >>>=3DA0You might as well go ahead and throw them all in for now.=3DA0=3D0A= >=3D=0A= >>>=3D0A=3D=0A= >>>=3DA0Hey -- isn't that C backend convenient? :)=3DA0=3D0A=3D=0A= >>>=3D0A=3D=0A= >>>=3D0A=3D=0A= >>>=3DA0- Jay=3D0A=3D=0A= >>>=3D0A=3D=0A= >>>----------------------------------------=3D0A=3D=0A= >>>> To: jay.krell at cornell.edu=3D0A=3D=0A= >>>> CC: m3devel at elegosoft.com=3D0A=3D=0A= >>>> Subject: more cm3cg on Raspberry Pi=3D0A=3D=0A= >>>> Date: Fri=3D2C 18 Oct 2013 18:26:02 -0700=3D0A=3D=0A= >>>> From: mika at async.caltech.edu=3D0A=3D=0A= >>>>=3D0A=3D=0A= >>>> After setting up for soft float=3D2C I got a lot of these warnings/erro= >rs..=3D=0A= >>>.=3D0A=3D=0A= >>>>=3D0A=3D=0A= >>>> new source -> compiling RTHeapInfo.m3=3D0A=3D=0A= >>>> RTHeapInfo.ms: Assembler messages:=3D0A=3D=0A= >>>> RTHeapInfo.ms:859: rdhi=3D2C rdlo and rm must all be different=3D0A=3D= >=0A= >>>> RTHeapInfo.ms:907: rdhi=3D2C rdlo and rm must all be different=3D0A=3D= >=0A= >>>> RTHeapInfo.ms:927: rdhi=3D2C rdlo and rm must all be different=3D0A=3D= >=0A= >>>> new source -> compiling RTHeapMap.i3=3D0A=3D=0A= >>>>=3D0A=3D=0A= >>>> This is with the following configuration:=3D0A=3D=0A= >>>>=3D0A=3D=0A= >>>> in /usr/local/cm3 I have the C-generating compiler installed. It seems = >to=3D=0A= >>> mostly work=3D2C as discussed.=3D0A=3D=0A= >>>>=3D0A=3D=0A= >>>> Then I run boot2.sh=3D0A=3D=0A= >>>>=3D0A=3D=0A= >>>> boot.sh finally ends with the following output=3D2C which doesn't look = >quit=3D=0A= >>>e right:=3D0A=3D=0A= >>>>=3D0A=3D=0A= >>>> =3D3D=3D3D package /big/home2/mika/2/cm3-cvs/cm3/m3-sys/mklib =3D3D=3D3= >D=3D0A=3D=0A= >>>>=3D0A=3D=0A= >>>> +++ /usr/local/cm3/bin/cm3 -build -DROOT=3D3D/big/home2/mika/2/cm3-cvs/= >cm3 =3D=0A= >>>+++=3D0A=3D=0A= >>>> --- building in ARMEL_LINUX ---=3D0A=3D=0A= >>>>=3D0A=3D=0A= >>>> ignoring ../src/m3overrides=3D0A=3D=0A= >>>>=3D0A=3D=0A= >>>> new source -> compiling Main.m3=3D0A=3D=0A= >>>> -> linking mklib=3D0A=3D=0A= >>>> =3D3D=3D3D> /big/home2/mika/2/cm3-cvs/cm3/m3-sys/mklib done=3D0A=3D=0A= >>>>=3D0A=3D=0A= >>>> +++ /usr/local/cm3/bin/cm3 -ship -DROOT=3D3D/big/home2/mika/2/cm3-cvs/c= >m3 +=3D=0A= >>>++=3D0A=3D=0A= >>>> --- shipping from ARMEL_LINUX ---=3D0A=3D=0A= >>>>=3D0A=3D=0A= >>>> . =3D3D> /usr/local/cm3/pkg/mklib/ARMEL_LINUX=3D0A=3D=0A= >>>> .M3EXPORTS .M3WEB=3D0A=3D=0A= >>>> ../src =3D3D> /usr/local/cm3/pkg/mklib/src=3D0A=3D=0A= >>>> Main.m3=3D0A=3D=0A= >>>> . =3D3D> /usr/local/cm3/bin=3D0A=3D=0A= >>>> mklib=3D0A=3D=0A= >>>> =3D3D=3D3D> /big/home2/mika/2/cm3-cvs/cm3/m3-sys/mklib done=3D0A=3D=0A= >>>>=3D0A=3D=0A= >>>> /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cggen/ARMEL_LINUX/m3cggen> /big/= >ho=3D=0A= >>>me2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/gcc/gcc/m3cg/m3cg.h=3D0A=3D=0A= >>>> mkdir -p /usr/local/cm3/bin=3D0A=3D=0A= >>>> cp -Pv /big/home2/mika/2/cm3-cvs/cm3/m3-sys/cm3/ARMEL_LINUX/cm3 /usr/lo= >ca=3D=0A= >>>l/cm3/bin/cm3=3D0A=3D=0A= >>>> Traceback (most recent call last):=3D0A=3D=0A= >>>> File "./upgrade.py"=3D2C line 72=3D2C in =3D0A=3D=0A= >>>> reload(pylib) # compiler host type may have changed and need to recompu= >te=3D=0A= >>> stuff=3D0A=3D=0A= >>>> File "/big/home2/mika/2/cm3-cvs/cm3/scripts/python/pylib.py"=3D2C line = >650=3D=0A= >>>=3D2C in =3D0A=3D=0A= >>>> if Host.endswith("_NT") or Host =3D3D=3D3D "NT386":=3D0A=3D=0A= >>>> AttributeError: 'NoneType' object has no attribute 'endswith'=3D0A=3D= >=0A= >>>> raspberrypi:/big/home2/mika/2/cm3-cvs/cm3/scripts/python#=3D0A=3D=0A= >>>>=3D0A=3D=0A= >>>> Mika =3D = From jay.krell at cornell.edu Sat Oct 19 22:03:58 2013 From: jay.krell at cornell.edu (Jay K) Date: Sat, 19 Oct 2013 20:03:58 +0000 Subject: [M3devel] more cm3cg on Raspberry Pi In-Reply-To: <20131019195255.306DE1A208E@async.async.caltech.edu> References: <20131019012602.C96441A208E@async.async.caltech.edu> , <20131019192135.5F59D1A208E@async.async.caltech.edu> , <20131019195255.306DE1A208E@async.async.caltech.edu> Message-ID: Two separate CVS checkouts? Onerous. Put all the outputs outside the entire source tree? Yes, that is what I want. Where is the root of the source tree? i.e. if you are mixing CVS tree and other trees. In the other system I use..: ? ?There is one large tree with a root, called $BASEDIR.? ? ?All outputs go under $OBJECT_ROOT.? ? ?The relative path under $BASEDIR is computed, and that is appended to $OBJECT_ROOT and outputs go there.? ? ?If you are doing something unusual outside of $BASEDIR, then the full path, changing colons to slash,? ? ?is appended to $OBJECT_ROOT. I believe also that really "target" and "output directory" are separate in cm3. Just that all the config files set them the same. You can copy ARMEL_LINUX, leave TARGET alone, and there is another variable that is usually assigned from TARGET, but you can assign it anything: "1", "arm.1", "foo". That is likely the way to go. Probably append something, and then clean can optionally append a star. ? ?- Jay ---------------------------------------- > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: more cm3cg on Raspberry Pi > Date: Sat, 19 Oct 2013 12:52:55 -0700 > From: mika at async.caltech.edu > > > The gain would be that I could compile my whole tree of non-CM3 software > (which is a fair fraction of the size of the CM3 tree), as well as the > CM3 tree itself, with both compilers without having to clean everything > and start over in between. On a slow machine it can make a difference. > But sure in the long run I'd probably stick with one or the other, and I > suspect most people would do too. On the other hand, for as long as there's > debug work going on on either or both of the compilers in question it seems > it would be helpful to be able to have both. And yes I get that they > would have to be installed in different places. But they wouldn't be able > to step on each other's toes if the derived directories were named differently... > > Well not a big deal, really. I now tar and rm and untar to switch. > > Jay K writes: >>Yes=2C maybe. But the C backend works for everything.=0A= >>We'd have to double the number of targets=2C for little gain.=0A= >>=0A= >>You can't install both to the same root either way.=0A= >>The pkg directories are separate=2C but bin and lib are not.=0A= >>=0A= >>Upgrade.py from on to the other should work asis.=0A= >>=0A= >>=A0- Jay=0A= >>=0A= >>----------------------------------------=0A= >>> To: jay.krell at cornell.edu=0A= >>> CC: m3devel at elegosoft.com=0A= >>> Subject: Re: more cm3cg on Raspberry Pi=0A= >>> Date: Sat=2C 19 Oct 2013 12:21:35 -0700=0A= >>> From: mika at async.caltech.edu=0A= >>>=0A= >>> Hi Jay=2C=0A= >>>=0A= >>> Yes the C backend is certainly convenient and cool. No argument there.=0A= >>>=0A= >>> But all this has me thinking about something... if the code generated by= >>=0A= >>> the C backend isn't compatible with that generated by cm3cg=2C shouldn't= >>=0A= >>> the target names be different=2C so that you could even have both systems= >>=0A= >>> installed at the same time. E.g.=2C ARMEL_LINUX_C and ARMEL_LINUX=0A= >>> (or whatever). Of course it makes it a bit more fiddly to bootstrap=0A= >>> since you're cross-compiling even though it's actually native..? I haven'= >>t=0A= >>> thought through all the ramifications. Is it difficult to change the name= >>?=0A= >>> Would it be desirable?=0A= >>>=0A= >>> Mika=0A= >>>=0A= >>> Jay K writes:=0A= >>>>Oh=3D2C sorry=3D2C here are things to try=3D0A=3D=0A= >>>>=3D0A=3D=0A= >>>>edit m3-sys/m3cc/src/platforms.quake=3D0A=3D=0A= >>>>look for ARMEL_LINUX=3D2C change the right hand side to arm-linux-gnueabi= >>hf=3D=0A= >>>>=3D0A=3D=0A= >>>>=3D0A=3D=0A= >>>>and/or in src/m3makefile=3D2C you want to add -with-hard-float or -with-h= >>ardf=3D=0A= >>>>loat..no=3D2C wait=3D2C from your other mail:=3D0A=3D=0A= >>>>=3D0A=3D=0A= >>>>=3DA0And=3D2C really=3D2C the guide here is what you showed for gcc:=3DA0= >>=3D0A=3D=0A= >>>>=3D0A=3D=0A= >>>>=3DA0Configured with: ../src/configure =3DA0=3D0A=3D=0A= >>>>=3DA0 =3DA0 -v \=3DA0=3D0A=3D=0A= >>>>=3DA0 =3DA0 ... =3DA0=3D0A=3D=0A= >>>>=3DA0 =3DA0 --with-arch=3D3Darmv6 =3DA0=3D0A=3D=0A= >>>>=3DA0 =3DA0 --with-fpu=3D3Dvfp=3DA0=3D0A=3D=0A= >>>>=3DA0 =3DA0 --with-float=3D3Dhard =3DA0=3D0A=3D=0A= >>>>=3DA0 =3DA0 --target=3D3Darm-linux-gnueabihf=3DA0=3D0A=3D=0A= >>>>=3D0A=3D=0A= >>>>=3DA0One/some/all of those are relevant.=3DA0=3D0A=3D=0A= >>>>=3DA0You might as well go ahead and throw them all in for now.=3DA0=3D0A= >>=3D=0A= >>>>=3D0A=3D=0A= >>>>=3DA0Hey -- isn't that C backend convenient? :)=3DA0=3D0A=3D=0A= >>>>=3D0A=3D=0A= >>>>=3D0A=3D=0A= >>>>=3DA0- Jay=3D0A=3D=0A= >>>>=3D0A=3D=0A= >>>>----------------------------------------=3D0A=3D=0A= >>>>> To: jay.krell at cornell.edu=3D0A=3D=0A= >>>>> CC: m3devel at elegosoft.com=3D0A=3D=0A= >>>>> Subject: more cm3cg on Raspberry Pi=3D0A=3D=0A= >>>>> Date: Fri=3D2C 18 Oct 2013 18:26:02 -0700=3D0A=3D=0A= >>>>> From: mika at async.caltech.edu=3D0A=3D=0A= >>>>>=3D0A=3D=0A= >>>>> After setting up for soft float=3D2C I got a lot of these warnings/erro= >>rs..=3D=0A= >>>>.=3D0A=3D=0A= >>>>>=3D0A=3D=0A= >>>>> new source -> compiling RTHeapInfo.m3=3D0A=3D=0A= >>>>> RTHeapInfo.ms: Assembler messages:=3D0A=3D=0A= >>>>> RTHeapInfo.ms:859: rdhi=3D2C rdlo and rm must all be different=3D0A=3D= >>=0A= >>>>> RTHeapInfo.ms:907: rdhi=3D2C rdlo and rm must all be different=3D0A=3D= >>=0A= >>>>> RTHeapInfo.ms:927: rdhi=3D2C rdlo and rm must all be different=3D0A=3D= >>=0A= >>>>> new source -> compiling RTHeapMap.i3=3D0A=3D=0A= >>>>>=3D0A=3D=0A= >>>>> This is with the following configuration:=3D0A=3D=0A= >>>>>=3D0A=3D=0A= >>>>> in /usr/local/cm3 I have the C-generating compiler installed. It seems = >>to=3D=0A= >>>> mostly work=3D2C as discussed.=3D0A=3D=0A= >>>>>=3D0A=3D=0A= >>>>> Then I run boot2.sh=3D0A=3D=0A= >>>>>=3D0A=3D=0A= >>>>> boot.sh finally ends with the following output=3D2C which doesn't look = >>quit=3D=0A= >>>>e right:=3D0A=3D=0A= >>>>>=3D0A=3D=0A= >>>>> =3D3D=3D3D package /big/home2/mika/2/cm3-cvs/cm3/m3-sys/mklib =3D3D=3D3= >>D=3D0A=3D=0A= >>>>>=3D0A=3D=0A= >>>>> +++ /usr/local/cm3/bin/cm3 -build -DROOT=3D3D/big/home2/mika/2/cm3-cvs/= >>cm3 =3D=0A= >>>>+++=3D0A=3D=0A= >>>>> --- building in ARMEL_LINUX ---=3D0A=3D=0A= >>>>>=3D0A=3D=0A= >>>>> ignoring ../src/m3overrides=3D0A=3D=0A= >>>>>=3D0A=3D=0A= >>>>> new source -> compiling Main.m3=3D0A=3D=0A= >>>>> -> linking mklib=3D0A=3D=0A= >>>>> =3D3D=3D3D> /big/home2/mika/2/cm3-cvs/cm3/m3-sys/mklib done=3D0A=3D=0A= >>>>>=3D0A=3D=0A= >>>>> +++ /usr/local/cm3/bin/cm3 -ship -DROOT=3D3D/big/home2/mika/2/cm3-cvs/c= >>m3 +=3D=0A= >>>>++=3D0A=3D=0A= >>>>> --- shipping from ARMEL_LINUX ---=3D0A=3D=0A= >>>>>=3D0A=3D=0A= >>>>> . =3D3D> /usr/local/cm3/pkg/mklib/ARMEL_LINUX=3D0A=3D=0A= >>>>> .M3EXPORTS .M3WEB=3D0A=3D=0A= >>>>> ../src =3D3D> /usr/local/cm3/pkg/mklib/src=3D0A=3D=0A= >>>>> Main.m3=3D0A=3D=0A= >>>>> . =3D3D> /usr/local/cm3/bin=3D0A=3D=0A= >>>>> mklib=3D0A=3D=0A= >>>>> =3D3D=3D3D> /big/home2/mika/2/cm3-cvs/cm3/m3-sys/mklib done=3D0A=3D=0A= >>>>>=3D0A=3D=0A= >>>>> /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cggen/ARMEL_LINUX/m3cggen> /big/= >>ho=3D=0A= >>>>me2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/gcc/gcc/m3cg/m3cg.h=3D0A=3D=0A= >>>>> mkdir -p /usr/local/cm3/bin=3D0A=3D=0A= >>>>> cp -Pv /big/home2/mika/2/cm3-cvs/cm3/m3-sys/cm3/ARMEL_LINUX/cm3 /usr/lo= >>ca=3D=0A= >>>>l/cm3/bin/cm3=3D0A=3D=0A= >>>>> Traceback (most recent call last):=3D0A=3D=0A= >>>>> File "./upgrade.py"=3D2C line 72=3D2C in =3D0A=3D=0A= >>>>> reload(pylib) # compiler host type may have changed and need to recompu= >>te=3D=0A= >>>> stuff=3D0A=3D=0A= >>>>> File "/big/home2/mika/2/cm3-cvs/cm3/scripts/python/pylib.py"=3D2C line = >>650=3D=0A= >>>>=3D2C in =3D0A=3D=0A= >>>>> if Host.endswith("_NT") or Host =3D3D=3D3D "NT386":=3D0A=3D=0A= >>>>> AttributeError: 'NoneType' object has no attribute 'endswith'=3D0A=3D= >>=0A= >>>>> raspberrypi:/big/home2/mika/2/cm3-cvs/cm3/scripts/python#=3D0A=3D=0A= >>>>>=3D0A=3D=0A= >>>>> Mika =3D = From jay.krell at cornell.edu Sat Oct 19 22:14:18 2013 From: jay.krell at cornell.edu (Jay K) Date: Sat, 19 Oct 2013 20:14:18 +0000 Subject: [M3devel] more cm3cg on Raspberry Pi In-Reply-To: References: <20131019012602.C96441A208E@async.async.caltech.edu>, , , <20131019192135.5F59D1A208E@async.async.caltech.edu>, , , <20131019195255.306DE1A208E@async.async.caltech.edu>, Message-ID: BUILD_DIR I think it is called. Profiling uses it, for example. Let's try that. Later. > From: jay.krell at cornell.edu > To: mika at async.caltech.edu > Date: Sat, 19 Oct 2013 20:03:58 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] more cm3cg on Raspberry Pi > > Two separate CVS checkouts? > Onerous. > > > Put all the outputs outside the entire source tree? > Yes, that is what I want. > Where is the root of the source tree? > i.e. if you are mixing CVS tree and other trees. > > > In the other system I use..: > There is one large tree with a root, called $BASEDIR. > All outputs go under $OBJECT_ROOT. > The relative path under $BASEDIR is computed, and that is appended to $OBJECT_ROOT and outputs go there. > If you are doing something unusual outside of $BASEDIR, then the full path, changing colons to slash, > is appended to $OBJECT_ROOT. > > > I believe also that really "target" and "output directory" are separate in cm3. > Just that all the config files set them the same. > You can copy ARMEL_LINUX, leave TARGET alone, and there is another variable that is usually assigned from TARGET, but you can assign it anything: "1", "arm.1", "foo". That is likely the way to go. Probably append something, and then clean can optionally append a star. > > ? > > - Jay > > ---------------------------------------- > > To: jay.krell at cornell.edu > > CC: m3devel at elegosoft.com > > Subject: Re: more cm3cg on Raspberry Pi > > Date: Sat, 19 Oct 2013 12:52:55 -0700 > > From: mika at async.caltech.edu > > > > > > The gain would be that I could compile my whole tree of non-CM3 software > > (which is a fair fraction of the size of the CM3 tree), as well as the > > CM3 tree itself, with both compilers without having to clean everything > > and start over in between. On a slow machine it can make a difference. > > But sure in the long run I'd probably stick with one or the other, and I > > suspect most people would do too. On the other hand, for as long as there's > > debug work going on on either or both of the compilers in question it seems > > it would be helpful to be able to have both. And yes I get that they > > would have to be installed in different places. But they wouldn't be able > > to step on each other's toes if the derived directories were named differently... > > > > Well not a big deal, really. I now tar and rm and untar to switch. > > > > Jay K writes: > >>Yes=2C maybe. But the C backend works for everything.=0A= > >>We'd have to double the number of targets=2C for little gain.=0A= > >>=0A= > >>You can't install both to the same root either way.=0A= > >>The pkg directories are separate=2C but bin and lib are not.=0A= > >>=0A= > >>Upgrade.py from on to the other should work asis.=0A= > >>=0A= > >>=A0- Jay=0A= > >>=0A= > >>----------------------------------------=0A= > >>> To: jay.krell at cornell.edu=0A= > >>> CC: m3devel at elegosoft.com=0A= > >>> Subject: Re: more cm3cg on Raspberry Pi=0A= > >>> Date: Sat=2C 19 Oct 2013 12:21:35 -0700=0A= > >>> From: mika at async.caltech.edu=0A= > >>>=0A= > >>> Hi Jay=2C=0A= > >>>=0A= > >>> Yes the C backend is certainly convenient and cool. No argument there.=0A= > >>>=0A= > >>> But all this has me thinking about something... if the code generated by= > >>=0A= > >>> the C backend isn't compatible with that generated by cm3cg=2C shouldn't= > >>=0A= > >>> the target names be different=2C so that you could even have both systems= > >>=0A= > >>> installed at the same time. E.g.=2C ARMEL_LINUX_C and ARMEL_LINUX=0A= > >>> (or whatever). Of course it makes it a bit more fiddly to bootstrap=0A= > >>> since you're cross-compiling even though it's actually native..? I haven'= > >>t=0A= > >>> thought through all the ramifications. Is it difficult to change the name= > >>?=0A= > >>> Would it be desirable?=0A= > >>>=0A= > >>> Mika=0A= > >>>=0A= > >>> Jay K writes:=0A= > >>>>Oh=3D2C sorry=3D2C here are things to try=3D0A=3D=0A= > >>>>=3D0A=3D=0A= > >>>>edit m3-sys/m3cc/src/platforms.quake=3D0A=3D=0A= > >>>>look for ARMEL_LINUX=3D2C change the right hand side to arm-linux-gnueabi= > >>hf=3D=0A= > >>>>=3D0A=3D=0A= > >>>>=3D0A=3D=0A= > >>>>and/or in src/m3makefile=3D2C you want to add -with-hard-float or -with-h= > >>ardf=3D=0A= > >>>>loat..no=3D2C wait=3D2C from your other mail:=3D0A=3D=0A= > >>>>=3D0A=3D=0A= > >>>>=3DA0And=3D2C really=3D2C the guide here is what you showed for gcc:=3DA0= > >>=3D0A=3D=0A= > >>>>=3D0A=3D=0A= > >>>>=3DA0Configured with: ../src/configure =3DA0=3D0A=3D=0A= > >>>>=3DA0 =3DA0 -v \=3DA0=3D0A=3D=0A= > >>>>=3DA0 =3DA0 ... =3DA0=3D0A=3D=0A= > >>>>=3DA0 =3DA0 --with-arch=3D3Darmv6 =3DA0=3D0A=3D=0A= > >>>>=3DA0 =3DA0 --with-fpu=3D3Dvfp=3DA0=3D0A=3D=0A= > >>>>=3DA0 =3DA0 --with-float=3D3Dhard =3DA0=3D0A=3D=0A= > >>>>=3DA0 =3DA0 --target=3D3Darm-linux-gnueabihf=3DA0=3D0A=3D=0A= > >>>>=3D0A=3D=0A= > >>>>=3DA0One/some/all of those are relevant.=3DA0=3D0A=3D=0A= > >>>>=3DA0You might as well go ahead and throw them all in for now.=3DA0=3D0A= > >>=3D=0A= > >>>>=3D0A=3D=0A= > >>>>=3DA0Hey -- isn't that C backend convenient? :)=3DA0=3D0A=3D=0A= > >>>>=3D0A=3D=0A= > >>>>=3D0A=3D=0A= > >>>>=3DA0- Jay=3D0A=3D=0A= > >>>>=3D0A=3D=0A= > >>>>----------------------------------------=3D0A=3D=0A= > >>>>> To: jay.krell at cornell.edu=3D0A=3D=0A= > >>>>> CC: m3devel at elegosoft.com=3D0A=3D=0A= > >>>>> Subject: more cm3cg on Raspberry Pi=3D0A=3D=0A= > >>>>> Date: Fri=3D2C 18 Oct 2013 18:26:02 -0700=3D0A=3D=0A= > >>>>> From: mika at async.caltech.edu=3D0A=3D=0A= > >>>>>=3D0A=3D=0A= > >>>>> After setting up for soft float=3D2C I got a lot of these warnings/erro= > >>rs..=3D=0A= > >>>>.=3D0A=3D=0A= > >>>>>=3D0A=3D=0A= > >>>>> new source -> compiling RTHeapInfo.m3=3D0A=3D=0A= > >>>>> RTHeapInfo.ms: Assembler messages:=3D0A=3D=0A= > >>>>> RTHeapInfo.ms:859: rdhi=3D2C rdlo and rm must all be different=3D0A=3D= > >>=0A= > >>>>> RTHeapInfo.ms:907: rdhi=3D2C rdlo and rm must all be different=3D0A=3D= > >>=0A= > >>>>> RTHeapInfo.ms:927: rdhi=3D2C rdlo and rm must all be different=3D0A=3D= > >>=0A= > >>>>> new source -> compiling RTHeapMap.i3=3D0A=3D=0A= > >>>>>=3D0A=3D=0A= > >>>>> This is with the following configuration:=3D0A=3D=0A= > >>>>>=3D0A=3D=0A= > >>>>> in /usr/local/cm3 I have the C-generating compiler installed. It seems = > >>to=3D=0A= > >>>> mostly work=3D2C as discussed.=3D0A=3D=0A= > >>>>>=3D0A=3D=0A= > >>>>> Then I run boot2.sh=3D0A=3D=0A= > >>>>>=3D0A=3D=0A= > >>>>> boot.sh finally ends with the following output=3D2C which doesn't look = > >>quit=3D=0A= > >>>>e right:=3D0A=3D=0A= > >>>>>=3D0A=3D=0A= > >>>>> =3D3D=3D3D package /big/home2/mika/2/cm3-cvs/cm3/m3-sys/mklib =3D3D=3D3= > >>D=3D0A=3D=0A= > >>>>>=3D0A=3D=0A= > >>>>> +++ /usr/local/cm3/bin/cm3 -build -DROOT=3D3D/big/home2/mika/2/cm3-cvs/= > >>cm3 =3D=0A= > >>>>+++=3D0A=3D=0A= > >>>>> --- building in ARMEL_LINUX ---=3D0A=3D=0A= > >>>>>=3D0A=3D=0A= > >>>>> ignoring ../src/m3overrides=3D0A=3D=0A= > >>>>>=3D0A=3D=0A= > >>>>> new source -> compiling Main.m3=3D0A=3D=0A= > >>>>> -> linking mklib=3D0A=3D=0A= > >>>>> =3D3D=3D3D> /big/home2/mika/2/cm3-cvs/cm3/m3-sys/mklib done=3D0A=3D=0A= > >>>>>=3D0A=3D=0A= > >>>>> +++ /usr/local/cm3/bin/cm3 -ship -DROOT=3D3D/big/home2/mika/2/cm3-cvs/c= > >>m3 +=3D=0A= > >>>>++=3D0A=3D=0A= > >>>>> --- shipping from ARMEL_LINUX ---=3D0A=3D=0A= > >>>>>=3D0A=3D=0A= > >>>>> . =3D3D> /usr/local/cm3/pkg/mklib/ARMEL_LINUX=3D0A=3D=0A= > >>>>> .M3EXPORTS .M3WEB=3D0A=3D=0A= > >>>>> ../src =3D3D> /usr/local/cm3/pkg/mklib/src=3D0A=3D=0A= > >>>>> Main.m3=3D0A=3D=0A= > >>>>> . =3D3D> /usr/local/cm3/bin=3D0A=3D=0A= > >>>>> mklib=3D0A=3D=0A= > >>>>> =3D3D=3D3D> /big/home2/mika/2/cm3-cvs/cm3/m3-sys/mklib done=3D0A=3D=0A= > >>>>>=3D0A=3D=0A= > >>>>> /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cggen/ARMEL_LINUX/m3cggen> /big/= > >>ho=3D=0A= > >>>>me2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/gcc/gcc/m3cg/m3cg.h=3D0A=3D=0A= > >>>>> mkdir -p /usr/local/cm3/bin=3D0A=3D=0A= > >>>>> cp -Pv /big/home2/mika/2/cm3-cvs/cm3/m3-sys/cm3/ARMEL_LINUX/cm3 /usr/lo= > >>ca=3D=0A= > >>>>l/cm3/bin/cm3=3D0A=3D=0A= > >>>>> Traceback (most recent call last):=3D0A=3D=0A= > >>>>> File "./upgrade.py"=3D2C line 72=3D2C in =3D0A=3D=0A= > >>>>> reload(pylib) # compiler host type may have changed and need to recompu= > >>te=3D=0A= > >>>> stuff=3D0A=3D=0A= > >>>>> File "/big/home2/mika/2/cm3-cvs/cm3/scripts/python/pylib.py"=3D2C line = > >>650=3D=0A= > >>>>=3D2C in =3D0A=3D=0A= > >>>>> if Host.endswith("_NT") or Host =3D3D=3D3D "NT386":=3D0A=3D=0A= > >>>>> AttributeError: 'NoneType' object has no attribute 'endswith'=3D0A=3D= > >>=0A= > >>>>> raspberrypi:/big/home2/mika/2/cm3-cvs/cm3/scripts/python#=3D0A=3D=0A= > >>>>>=3D0A=3D=0A= > >>>>> Mika =3D = -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Oct 20 09:54:48 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 20 Oct 2013 07:54:48 +0000 Subject: [M3devel] more cm3cg on Raspberry Pi In-Reply-To: References: <20131019012602.C96441A208E@async.async.caltech.edu>, , , , , <20131019192135.5F59D1A208E@async.async.caltech.edu>, , , , , <20131019195255.306DE1A208E@async.async.caltech.edu>, , , Message-ID: I commited this. It does what you want? Without multiplying out config files or targets in the frontend. I suppose we should also add like the following: if not equal($CM3_BUILD_DIR, "") ? BUILD_DIR = $CM3_BUILD_DIR end ? Let you set it arbitrarily with an environment variable. Also, todo, is like I said, CM3_BUILD_DIR_ROOT or such. We should discuss a bit first perhaps. ?- Jay Index: m3-sys/cminstall/src/config-no-install/cm3cfg.common =================================================================== RCS file: /usr/cvs/cm3/m3-sys/cminstall/src/config-no-install/cm3cfg.common,v retrieving revision 1.71 diff -u -r1.71 cm3cfg.common --- m3-sys/cminstall/src/config-no-install/cm3cfg.common 22 Sep 2013 04:21:00 -0000 1.71 +++ m3-sys/cminstall/src/config-no-install/cm3cfg.common 20 Oct 2013 07:50:19 -0000 @@ -22,6 +22,14 @@ ? ?%------------------------------------------------------------------- ? +if equal(M3_BACKEND_MODE, "IntegratedC") + ? ? ? ?or equal(M3_BACKEND_MODE, "C") + ? ? ? ?or USE_C_BACKEND_VIA_M3CGCAT + ? ?readonly BUILD_DIR_C = "c" +else + ? ?readonly BUILD_DIR_C = "" +end + ?if not defined("PROFILING_P") ? ? ?if M3_PROFILING ? ? ? ? ?readonly PROFILING_P = "p" @@ -31,7 +39,7 @@ ?end ? ?if not defined("BUILD_DIR") - ? ?readonly BUILD_DIR ? ?= TARGET & PROFILING_P % directory for results + ? ?readonly BUILD_DIR ? ?= TARGET & PROFILING_P & BUILD_DIR_C % directory for results ?end ? ?%------------------------------------------------------------------------------ Index: scripts/python/pylib.py =================================================================== RCS file: /usr/cvs/cm3/scripts/python/pylib.py,v retrieving revision 1.407 diff -u -r1.407 pylib.py --- scripts/python/pylib.py 19 Oct 2013 08:18:30 -0000 1.407 +++ scripts/python/pylib.py 20 Oct 2013 07:50:19 -0000 @@ -365,6 +365,7 @@ ?#----------------------------------------------------------------------------- ? ?_CBackend = "c" in sys.argv +_BuildDirC = ["", "c"][_CBackend] ?_PossibleCm3Flags = ["boot", "keep", "override", "commands", "verbose", "why"] ?_SkipGccFlags = ["nogcc", "skipgcc", "omitgcc"] ?_PossiblePylibFlags = ["noclean", "nocleangcc", "c"] + _SkipGccFlags + _PossibleCm3Flags @@ -764,10 +765,11 @@ ? ?# other commands ? + ? ?_BuildDir = ("%(Config)s%(_BuildDirC)s" % vars()) ? ? ?if os.name == "nt": - ? ? ? ?RealClean = RealClean or "if exist %(Config)s rmdir /q/s %(Config)s" + ? ? ? ?RealClean = RealClean or "if exist %(_BuildDir)s rmdir /q/s %(_BuildDir)s" ? ? ?else: - ? ? ? ?RealClean = RealClean or "rm -rf %(Config)s" + ? ? ? ?RealClean = RealClean or "rm -rf %(_BuildDir)s" ? ? ? ?RealClean = (RealClean % vars()) ? ________________________________ > From: jay.krell at cornell.edu > To: mika at async.caltech.edu > Date: Sat, 19 Oct 2013 20:14:18 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] more cm3cg on Raspberry Pi > > BUILD_DIR I think it is called. Profiling uses it, for example. Let's > try that. Later. > >> From: jay.krell at cornell.edu >> To: mika at async.caltech.edu >> Date: Sat, 19 Oct 2013 20:03:58 +0000 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] more cm3cg on Raspberry Pi >> >> Two separate CVS checkouts? >> Onerous. >> >> >> Put all the outputs outside the entire source tree? >> Yes, that is what I want. >> Where is the root of the source tree? >> i.e. if you are mixing CVS tree and other trees. >> >> >> In the other system I use..: >> There is one large tree with a root, called $BASEDIR. >> All outputs go under $OBJECT_ROOT. >> The relative path under $BASEDIR is computed, and that is appended > to $OBJECT_ROOT and outputs go there. >> If you are doing something unusual outside of $BASEDIR, then the > full path, changing colons to slash, >> is appended to $OBJECT_ROOT. >> >> >> I believe also that really "target" and "output directory" are > separate in cm3. >> Just that all the config files set them the same. >> You can copy ARMEL_LINUX, leave TARGET alone, and there is another > variable that is usually assigned from TARGET, but you can assign it > anything: "1", "arm.1", "foo". That is likely the way to go. Probably > append something, and then clean can optionally append a star. >> >> ? >> >> - Jay >> >> ---------------------------------------- >>> To: jay.krell at cornell.edu >>> CC: m3devel at elegosoft.com >>> Subject: Re: more cm3cg on Raspberry Pi >>> Date: Sat, 19 Oct 2013 12:52:55 -0700 >>> From: mika at async.caltech.edu >>> >>> >>> The gain would be that I could compile my whole tree of non-CM3 software >>> (which is a fair fraction of the size of the CM3 tree), as well as the >>> CM3 tree itself, with both compilers without having to clean everything >>> and start over in between. On a slow machine it can make a difference. >>> But sure in the long run I'd probably stick with one or the other, and I >>> suspect most people would do too. On the other hand, for as long as > there's >>> debug work going on on either or both of the compilers in question > it seems >>> it would be helpful to be able to have both. And yes I get that they >>> would have to be installed in different places. But they wouldn't be able >>> to step on each other's toes if the derived directories were named > differently... >>> >>> Well not a big deal, really. I now tar and rm and untar to switch. >>> >>> Jay K writes: >>>>Yes=2C maybe. But the C backend works for everything.=0A= >>>>We'd have to double the number of targets=2C for little gain.=0A= >>>>=0A= >>>>You can't install both to the same root either way.=0A= >>>>The pkg directories are separate=2C but bin and lib are not.=0A= >>>>=0A= >>>>Upgrade.py from on to the other should work asis.=0A= >>>>=0A= >>>>=A0- Jay=0A= >>>>=0A= >>>>----------------------------------------=0A= >>>>> To: jay.krell at cornell.edu=0A= >>>>> CC: m3devel at elegosoft.com=0A= >>>>> Subject: Re: more cm3cg on Raspberry Pi=0A= >>>>> Date: Sat=2C 19 Oct 2013 12:21:35 -0700=0A= >>>>> From: mika at async.caltech.edu=0A= >>>>>=0A= >>>>> Hi Jay=2C=0A= >>>>>=0A= >>>>> Yes the C backend is certainly convenient and cool. No argument > there.=0A= >>>>>=0A= >>>>> But all this has me thinking about something... if the code > generated by= >>>>=0A= >>>>> the C backend isn't compatible with that generated by cm3cg=2C > shouldn't= >>>>=0A= >>>>> the target names be different=2C so that you could even have both > systems= >>>>=0A= >>>>> installed at the same time. E.g.=2C ARMEL_LINUX_C and ARMEL_LINUX=0A= >>>>> (or whatever). Of course it makes it a bit more fiddly to bootstrap=0A= >>>>> since you're cross-compiling even though it's actually native..? > I haven'= >>>>t=0A= >>>>> thought through all the ramifications. Is it difficult to change > the name= >>>>?=0A= >>>>> Would it be desirable?=0A= >>>>>=0A= >>>>> Mika=0A= >>>>>=0A= >>>>> Jay K writes:=0A= >>>>>>Oh=3D2C sorry=3D2C here are things to try=3D0A=3D=0A= >>>>>>=3D0A=3D=0A= >>>>>>edit m3-sys/m3cc/src/platforms.quake=3D0A=3D=0A= >>>>>>look for ARMEL_LINUX=3D2C change the right hand side to > arm-linux-gnueabi= >>>>hf=3D=0A= >>>>>>=3D0A=3D=0A= >>>>>>=3D0A=3D=0A= >>>>>>and/or in src/m3makefile=3D2C you want to add -with-hard-float or > -with-h= >>>>ardf=3D=0A= >>>>>>loat..no=3D2C wait=3D2C from your other mail:=3D0A=3D=0A= >>>>>>=3D0A=3D=0A= >>>>>>=3DA0And=3D2C really=3D2C the guide here is what you showed for > gcc:=3DA0= >>>>=3D0A=3D=0A= >>>>>>=3D0A=3D=0A= >>>>>>=3DA0Configured with: ../src/configure =3DA0=3D0A=3D=0A= >>>>>>=3DA0 =3DA0 -v \=3DA0=3D0A=3D=0A= >>>>>>=3DA0 =3DA0 ... =3DA0=3D0A=3D=0A= >>>>>>=3DA0 =3DA0 --with-arch=3D3Darmv6 =3DA0=3D0A=3D=0A= >>>>>>=3DA0 =3DA0 --with-fpu=3D3Dvfp=3DA0=3D0A=3D=0A= >>>>>>=3DA0 =3DA0 --with-float=3D3Dhard =3DA0=3D0A=3D=0A= >>>>>>=3DA0 =3DA0 --target=3D3Darm-linux-gnueabihf=3DA0=3D0A=3D=0A= >>>>>>=3D0A=3D=0A= >>>>>>=3DA0One/some/all of those are relevant.=3DA0=3D0A=3D=0A= >>>>>>=3DA0You might as well go ahead and throw them all in for > now.=3DA0=3D0A= >>>>=3D=0A= >>>>>>=3D0A=3D=0A= >>>>>>=3DA0Hey -- isn't that C backend convenient? :)=3DA0=3D0A=3D=0A= >>>>>>=3D0A=3D=0A= >>>>>>=3D0A=3D=0A= >>>>>>=3DA0- Jay=3D0A=3D=0A= >>>>>>=3D0A=3D=0A= >>>>>>----------------------------------------=3D0A=3D=0A= >>>>>>> To: jay.krell at cornell.edu=3D0A=3D=0A= >>>>>>> CC: m3devel at elegosoft.com=3D0A=3D=0A= >>>>>>> Subject: more cm3cg on Raspberry Pi=3D0A=3D=0A= >>>>>>> Date: Fri=3D2C 18 Oct 2013 18:26:02 -0700=3D0A=3D=0A= >>>>>>> From: mika at async.caltech.edu=3D0A=3D=0A= >>>>>>>=3D0A=3D=0A= >>>>>>> After setting up for soft float=3D2C I got a lot of these > warnings/erro= >>>>rs..=3D=0A= >>>>>>.=3D0A=3D=0A= >>>>>>>=3D0A=3D=0A= >>>>>>> new source -> compiling RTHeapInfo.m3=3D0A=3D=0A= >>>>>>> RTHeapInfo.ms: Assembler messages:=3D0A=3D=0A= >>>>>>> RTHeapInfo.ms:859: rdhi=3D2C rdlo and rm must all be > different=3D0A=3D= >>>>=0A= >>>>>>> RTHeapInfo.ms:907: rdhi=3D2C rdlo and rm must all be > different=3D0A=3D= >>>>=0A= >>>>>>> RTHeapInfo.ms:927: rdhi=3D2C rdlo and rm must all be > different=3D0A=3D= >>>>=0A= >>>>>>> new source -> compiling RTHeapMap.i3=3D0A=3D=0A= >>>>>>>=3D0A=3D=0A= >>>>>>> This is with the following configuration:=3D0A=3D=0A= >>>>>>>=3D0A=3D=0A= >>>>>>> in /usr/local/cm3 I have the C-generating compiler installed. > It seems = >>>>to=3D=0A= >>>>>> mostly work=3D2C as discussed.=3D0A=3D=0A= >>>>>>>=3D0A=3D=0A= >>>>>>> Then I run boot2.sh=3D0A=3D=0A= >>>>>>>=3D0A=3D=0A= >>>>>>> boot.sh finally ends with the following output=3D2C which > doesn't look = >>>>quit=3D=0A= >>>>>>e right:=3D0A=3D=0A= >>>>>>>=3D0A=3D=0A= >>>>>>> =3D3D=3D3D package /big/home2/mika/2/cm3-cvs/cm3/m3-sys/mklib > =3D3D=3D3= >>>>D=3D0A=3D=0A= >>>>>>>=3D0A=3D=0A= >>>>>>> +++ /usr/local/cm3/bin/cm3 -build > -DROOT=3D3D/big/home2/mika/2/cm3-cvs/= >>>>cm3 =3D=0A= >>>>>>+++=3D0A=3D=0A= >>>>>>> --- building in ARMEL_LINUX ---=3D0A=3D=0A= >>>>>>>=3D0A=3D=0A= >>>>>>> ignoring ../src/m3overrides=3D0A=3D=0A= >>>>>>>=3D0A=3D=0A= >>>>>>> new source -> compiling Main.m3=3D0A=3D=0A= >>>>>>> -> linking mklib=3D0A=3D=0A= >>>>>>> =3D3D=3D3D> /big/home2/mika/2/cm3-cvs/cm3/m3-sys/mklib > done=3D0A=3D=0A= >>>>>>>=3D0A=3D=0A= >>>>>>> +++ /usr/local/cm3/bin/cm3 -ship > -DROOT=3D3D/big/home2/mika/2/cm3-cvs/c= >>>>m3 +=3D=0A= >>>>>>++=3D0A=3D=0A= >>>>>>> --- shipping from ARMEL_LINUX ---=3D0A=3D=0A= >>>>>>>=3D0A=3D=0A= >>>>>>> . =3D3D> /usr/local/cm3/pkg/mklib/ARMEL_LINUX=3D0A=3D=0A= >>>>>>> .M3EXPORTS .M3WEB=3D0A=3D=0A= >>>>>>> ../src =3D3D> /usr/local/cm3/pkg/mklib/src=3D0A=3D=0A= >>>>>>> Main.m3=3D0A=3D=0A= >>>>>>> . =3D3D> /usr/local/cm3/bin=3D0A=3D=0A= >>>>>>> mklib=3D0A=3D=0A= >>>>>>> =3D3D=3D3D> /big/home2/mika/2/cm3-cvs/cm3/m3-sys/mklib > done=3D0A=3D=0A= >>>>>>>=3D0A=3D=0A= >>>>>>> > /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cggen/ARMEL_LINUX/m3cggen> > /big/= >>>>ho=3D=0A= >>>>>>me2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/gcc/gcc/m3cg/m3cg.h=3D0A=3D=0A= >>>>>>> mkdir -p /usr/local/cm3/bin=3D0A=3D=0A= >>>>>>> cp -Pv /big/home2/mika/2/cm3-cvs/cm3/m3-sys/cm3/ARMEL_LINUX/cm3 > /usr/lo= >>>>ca=3D=0A= >>>>>>l/cm3/bin/cm3=3D0A=3D=0A= >>>>>>> Traceback (most recent call last):=3D0A=3D=0A= >>>>>>> File "./upgrade.py"=3D2C line 72=3D2C in =3D0A=3D=0A= >>>>>>> reload(pylib) # compiler host type may have changed and need to > recompu= >>>>te=3D=0A= >>>>>> stuff=3D0A=3D=0A= >>>>>>> File > "/big/home2/mika/2/cm3-cvs/cm3/scripts/python/pylib.py"=3D2C line = >>>>650=3D=0A= >>>>>>=3D2C in =3D0A=3D=0A= >>>>>>> if Host.endswith("_NT") or Host =3D3D=3D3D "NT386":=3D0A=3D=0A= >>>>>>> AttributeError: 'NoneType' object has no attribute > 'endswith'=3D0A=3D= >>>>=0A= >>>>>>> raspberrypi:/big/home2/mika/2/cm3-cvs/cm3/scripts/python#=3D0A=3D=0A= >>>>>>>=3D0A=3D=0A= >>>>>>> Mika =3D = From jay.krell at cornell.edu Sun Oct 20 10:10:27 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 20 Oct 2013 08:10:27 +0000 Subject: [M3devel] missing m3makefile in odbc/src/POSIX In-Reply-To: <525F4A06.60101@lcwb.coop> References: <525F4A06.60101@lcwb.coop> Message-ID: It works for me. Maybe you are in a branch? (or whatever CVS calls a branch.. Perforce has the right model..) ? ?jbook2:odbc jay$ rm -rf src ? ? ?jbook2:odbc jay$ cvs -z3 upd -dAP ? ? ?... ?? ? ?U src/POSIX/m3makefile ?? ? ? jbook2:odbc jay$ pwd ?? ? ?/dev2/cm3/m3-db/odbc ?? ?- Jay ---------------------------------------- > Date: Wed, 16 Oct 2013 21:23:02 -0500 > From: rodney_bates at lcwb.coop > To: m3devel at elegosoft.com > Subject: [M3devel] missing m3makefile in odbc/src/POSIX > > Why can't' I get cvs to give me m3-db/odbc/src/POSIX/m3makefile? > > According to > rodney at allegheny:~/proj/m3/cm3-head/cm3/m3-db/odbc/src/POSIX$ cvs log m3makefile. > > ..... > > total revisions: 5; selected revisions: 5 > description: > ---------------------------- > revision 1.4 > date: 2013-09-25 21:47:06 -0500; author: jkrell; state: Exp; lines: +2 -1; commitid: eUlcRHBNTCZJsT6x; > restore file TEMPORARILY, until the next release... > ---------------------------- > revision 1.3 > date: 2010-05-09 01:03:19 -0500; author: jkrell; state: dead; lines: +0 -0; commitid: 1EK0bvKwEdaQg4yu; > another 1500 lines of cloned C headers gone, now that compiler > accepts Win32 calling conventions on all platforms > These files were essentially otherwise identical. > The log file we define in terms of Compiler.OS. > WinDef.HWND is basically ADDRESS on all platforms already. > Again the "Win32" directory is now "common" or "only". > ---------------------------- > > it was restored. But I can't get it. My cvs book says, for cvs update, -d option > > "Without this option, update only operates on the directories present in the working > copy; new files are brought down from the repository, but new directories are not." > > This directory is present in my working copy. > > Without the m3makefile, I odbc won't build. > > > > > > From jay.krell at cornell.edu Sun Oct 20 11:10:27 2013 From: jay.krell at cornell.edu (Jay K) Date: Sun, 20 Oct 2013 09:10:27 +0000 Subject: [M3devel] cm3 -DTARGET=foo In-Reply-To: References: Message-ID: attached, ok? I recently split ScanCommandLine into ScanCommandLine1 and ScanCommandLine2. This puts them back together. You could already say cm3 -DFOO=BAR, but the processing worked like so: ? write FOO = BAR into build_dir/m3make.args ? read/run cm3.cfg ? read/run m3make.args ?? ?? The intent of the change is to reverse the order, somewhat. So that -D on the command line can precede/override cm3.cfg. I don't see the signficance of m3make.args, other than cm3 -keep leaves it to be viewed. This change defines the values directly into memory, before reading/running cm3.cfg. This change continues to write m3make.args the same, but changes quake to allow assigning read only values, if the new value is equivalent to the old. The assignment is silently ignored and the old value kept (i.e. equivalent, not equal). I'd also be ok with an approach that removes m3make.args entirely. I suspect its existance is related to when makefiles were generated for each package (which I might bring back..for distribution/packing purposes...) ?- Jay ________________________________ > From: jay.krell at cornell.edu > To: m3devel at elegosoft.com > Date: Fri, 30 Aug 2013 06:02:41 +0000 > Subject: [M3devel] cm3 -DTARGET=foo > > I'd like the above to work. > > Or cm3 -target=foo or -target:foo. > The underlying implementation would be "like" -DTARGET=foo. > > This doesn't work due to the order of evaluation, command line vs. > config file vs. -D written to a file. > > I don't have the change yet. > > Any objection to the intent? > > I wonder if it might subtlely reorder things though. > > > - Jay > > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 2.txt URL: From mika at async.caltech.edu Tue Oct 22 03:34:33 2013 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Mon, 21 Oct 2013 18:34:33 -0700 Subject: [M3devel] more cm3cg on Raspberry Pi In-Reply-To: References: <20131019012602.C96441A208E@async.async.caltech.edu> Message-ID: <20131022013433.A39161A208E@async.async.caltech.edu> Jay, you did these changes to the repository, for ARMEL_LINUX, right? I recompiled everything, but I'm not sure I got the whole configuration or how to check. My cm3cg in any case reports as follows: raspberrypi:/big/home2/mika/2/cm3-cvs/cm3/scripts/python# cm3cg -version Modula-3 backend (GCC) version 4.7.1 (armv6l-unknown-linux-gnueabihf) compiled by GNU C version 4.6.3, GGC heuristics: --param ggc-min-expand=59 --param ggc-min-heapsize=56092 Modula-3 backend (GCC) version 4.7.1 (armv6l-unknown-linux-gnueabihf) compiled by GNU C version 4.6.3, GGC heuristics: --param ggc-min-expand=59 --param ggc-min-heapsize=56092 options passed: options enabled: -fauto-inc-dec -fbranch-count-reg -fcommon -fdebug-types-section -fdelete-null-pointer-checks -fdwarf2-cfi-asm -fearly-inlining -feliminate-unused-debug-types -fexceptions -ffunction-cse -fgcse-lm -fgnu-runtime -fident -finline-atomics -fira-share-save-slots -fira-share-spill-slots -fivopts -fkeep-static-consts -fleading-underscore -fmath-errno -fmerge-debug-strings -fmove-loop-invariants -fpeephole -fprefetch-loop-arrays -freg-struct-return -fsched-critical-path-heuristic -fsched-dep-count-heuristic -fsched-group-heuristic -fsched-interblock -fsched-last-insn-heuristic -fsched-rank-heuristic -fsched-spec -fsched-spec-insn-heuristic -fsched-stalled-insns-dep -fshow-column -fsigned-zeros -fsplit-ivs-in-unroller -fstrict-volatile-bitfields -ftrapping-math -ftree-cselim -ftree-forwprop -ftree-loop-if-convert -ftree-loop-im -ftree-loop-ivcanon -ftree-loop-optimize -ftree-parallelize-loops= -ftree-phiprop -ftree-pta -ftree-reassoc -ftree-scev-cprop -ftree-slp-vectorize -ftree-vect-loop-version -funit-at-a-time -fvar-tracking -fvar-tracking-assignments -fzero-initialized-in-bss -marm -mglibc -mlittle-endian -msched-prolog -mvectorize-with-neon-quad unfortunately this is what happens now.... raspberrypi:/big/home2/mika/2/cm3-cvs/cm3/scripts/python# ./do-pkg.py m3core libm3 buildship CM3_TARGET=ARMEL_LINUX export CM3_TARGET CM3_INSTALL=/usr/local/cm3 export CM3_INSTALL CM3_ROOT=/big/home2/mika/2/cm3-cvs/cm3 export CM3_ROOT == package /big/home2/mika/2/cm3-cvs/cm3/m3-libs/m3core == +++ /usr/local/cm3/bin/cm3 -build -DROOT=/big/home2/mika/2/cm3-cvs/cm3 +++ --- building in ARMEL_LINUX --- ignoring ../src/m3overrides new source -> compiling RTHooks.i3 cm3cg: sorry, unimplemented: -mfloat-abi=hard and VFP m3_backend => 1 m3cc (aka cm3cg) failed compiling: RTHooks.ic Assembler messages: Error: can't open RTHooks.is for reading: No such file or directory assemble => 1 assembler failed assembling: RTHooks.is I'm not sure what's up here because it seems to contradict my C flags. Mika Jay K writes: >Oh=2C sorry=2C here are things to try=0A= >=0A= >edit m3-sys/m3cc/src/platforms.quake=0A= >look for ARMEL_LINUX=2C change the right hand side to arm-linux-gnueabihf= >=0A= >=0A= >and/or in src/m3makefile=2C you want to add -with-hard-float or -with-hardf= >loat..no=2C wait=2C from your other mail:=0A= >=0A= >=A0And=2C really=2C the guide here is what you showed for gcc:=A0=0A= >=0A= >=A0Configured with: ../src/configure =A0=0A= >=A0 =A0 -v \=A0=0A= >=A0 =A0 ... =A0=0A= >=A0 =A0 --with-arch=3Darmv6 =A0=0A= >=A0 =A0 --with-fpu=3Dvfp=A0=0A= >=A0 =A0 --with-float=3Dhard =A0=0A= >=A0 =A0 --target=3Darm-linux-gnueabihf=A0=0A= >=0A= >=A0One/some/all of those are relevant.=A0=0A= >=A0You might as well go ahead and throw them all in for now.=A0=0A= >=0A= >=A0Hey -- isn't that C backend convenient? :)=A0=0A= >=0A= >=0A= >=A0- Jay=0A= >=0A= >----------------------------------------=0A= >> To: jay.krell at cornell.edu=0A= >> CC: m3devel at elegosoft.com=0A= >> Subject: more cm3cg on Raspberry Pi=0A= >> Date: Fri=2C 18 Oct 2013 18:26:02 -0700=0A= >> From: mika at async.caltech.edu=0A= >>=0A= >> After setting up for soft float=2C I got a lot of these warnings/errors..= >.=0A= >>=0A= >> new source -> compiling RTHeapInfo.m3=0A= >> RTHeapInfo.ms: Assembler messages:=0A= >> RTHeapInfo.ms:859: rdhi=2C rdlo and rm must all be different=0A= >> RTHeapInfo.ms:907: rdhi=2C rdlo and rm must all be different=0A= >> RTHeapInfo.ms:927: rdhi=2C rdlo and rm must all be different=0A= >> new source -> compiling RTHeapMap.i3=0A= >>=0A= >> This is with the following configuration:=0A= >>=0A= >> in /usr/local/cm3 I have the C-generating compiler installed. It seems to= > mostly work=2C as discussed.=0A= >>=0A= >> Then I run boot2.sh=0A= >>=0A= >> boot.sh finally ends with the following output=2C which doesn't look quit= >e right:=0A= >>=0A= >> =3D=3D package /big/home2/mika/2/cm3-cvs/cm3/m3-sys/mklib =3D=3D=0A= >>=0A= >> +++ /usr/local/cm3/bin/cm3 -build -DROOT=3D/big/home2/mika/2/cm3-cvs/cm3 = >+++=0A= >> --- building in ARMEL_LINUX ---=0A= >>=0A= >> ignoring ../src/m3overrides=0A= >>=0A= >> new source -> compiling Main.m3=0A= >> -> linking mklib=0A= >> =3D=3D> /big/home2/mika/2/cm3-cvs/cm3/m3-sys/mklib done=0A= >>=0A= >> +++ /usr/local/cm3/bin/cm3 -ship -DROOT=3D/big/home2/mika/2/cm3-cvs/cm3 += >++=0A= >> --- shipping from ARMEL_LINUX ---=0A= >>=0A= >> . =3D> /usr/local/cm3/pkg/mklib/ARMEL_LINUX=0A= >> .M3EXPORTS .M3WEB=0A= >> ../src =3D> /usr/local/cm3/pkg/mklib/src=0A= >> Main.m3=0A= >> . =3D> /usr/local/cm3/bin=0A= >> mklib=0A= >> =3D=3D> /big/home2/mika/2/cm3-cvs/cm3/m3-sys/mklib done=0A= >>=0A= >> /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cggen/ARMEL_LINUX/m3cggen> /big/ho= >me2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/gcc/gcc/m3cg/m3cg.h=0A= >> mkdir -p /usr/local/cm3/bin=0A= >> cp -Pv /big/home2/mika/2/cm3-cvs/cm3/m3-sys/cm3/ARMEL_LINUX/cm3 /usr/loca= >l/cm3/bin/cm3=0A= >> Traceback (most recent call last):=0A= >> File "./upgrade.py"=2C line 72=2C in =0A= >> reload(pylib) # compiler host type may have changed and need to recompute= > stuff=0A= >> File "/big/home2/mika/2/cm3-cvs/cm3/scripts/python/pylib.py"=2C line 650= >=2C in =0A= >> if Host.endswith("_NT") or Host =3D=3D "NT386":=0A= >> AttributeError: 'NoneType' object has no attribute 'endswith'=0A= >> raspberrypi:/big/home2/mika/2/cm3-cvs/cm3/scripts/python#=0A= >>=0A= >> Mika = From jay.krell at cornell.edu Tue Oct 22 04:40:49 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 22 Oct 2013 02:40:49 +0000 Subject: [M3devel] more cm3cg on Raspberry Pi In-Reply-To: <20131022013433.A39161A208E@async.async.caltech.edu> References: <20131019012602.C96441A208E@async.async.caltech.edu> , <20131022013433.A39161A208E@async.async.caltech.edu> Message-ID: > cm3cg: sorry, unimplemented: -mfloat-abi=hard and VFP drat. I'll try to cross build a boot archive, but I should see the same thing. Maybe the support is not in mainline? And we should port it from some Raspberry Pi place? Or maybe those last switches aren't needed? Or maybe just give up and stick with C? ?- Jay ---------------------------------------- > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: more cm3cg on Raspberry Pi > Date: Mon, 21 Oct 2013 18:34:33 -0700 > From: mika at async.caltech.edu > > Jay, you did these changes to the repository, for ARMEL_LINUX, right? > > I recompiled everything, but I'm not sure I got the whole configuration > or how to check. My cm3cg in any case reports as follows: > > raspberrypi:/big/home2/mika/2/cm3-cvs/cm3/scripts/python# cm3cg -version > Modula-3 backend (GCC) version 4.7.1 (armv6l-unknown-linux-gnueabihf) > compiled by GNU C version 4.6.3, GGC heuristics: --param ggc-min-expand=59 --param ggc-min-heapsize=56092 > Modula-3 backend (GCC) version 4.7.1 (armv6l-unknown-linux-gnueabihf) > compiled by GNU C version 4.6.3, GGC heuristics: --param ggc-min-expand=59 --param ggc-min-heapsize=56092 > options passed: > options enabled: -fauto-inc-dec -fbranch-count-reg -fcommon > -fdebug-types-section -fdelete-null-pointer-checks -fdwarf2-cfi-asm > -fearly-inlining -feliminate-unused-debug-types -fexceptions > -ffunction-cse -fgcse-lm -fgnu-runtime -fident -finline-atomics > -fira-share-save-slots -fira-share-spill-slots -fivopts > -fkeep-static-consts -fleading-underscore -fmath-errno > -fmerge-debug-strings -fmove-loop-invariants -fpeephole > -fprefetch-loop-arrays -freg-struct-return -fsched-critical-path-heuristic > -fsched-dep-count-heuristic -fsched-group-heuristic -fsched-interblock > -fsched-last-insn-heuristic -fsched-rank-heuristic -fsched-spec > -fsched-spec-insn-heuristic -fsched-stalled-insns-dep -fshow-column > -fsigned-zeros -fsplit-ivs-in-unroller -fstrict-volatile-bitfields > -ftrapping-math -ftree-cselim -ftree-forwprop -ftree-loop-if-convert > -ftree-loop-im -ftree-loop-ivcanon -ftree-loop-optimize > -ftree-parallelize-loops= -ftree-phiprop -ftree-pta -ftree-reassoc > -ftree-scev-cprop -ftree-slp-vectorize -ftree-vect-loop-version > -funit-at-a-time -fvar-tracking -fvar-tracking-assignments > -fzero-initialized-in-bss -marm -mglibc -mlittle-endian -msched-prolog > -mvectorize-with-neon-quad > > unfortunately this is what happens now.... > > raspberrypi:/big/home2/mika/2/cm3-cvs/cm3/scripts/python# ./do-pkg.py m3core libm3 buildship > CM3_TARGET=ARMEL_LINUX > export CM3_TARGET > CM3_INSTALL=/usr/local/cm3 > export CM3_INSTALL > CM3_ROOT=/big/home2/mika/2/cm3-cvs/cm3 > export CM3_ROOT > == package /big/home2/mika/2/cm3-cvs/cm3/m3-libs/m3core == > > +++ /usr/local/cm3/bin/cm3 -build -DROOT=/big/home2/mika/2/cm3-cvs/cm3 +++ > --- building in ARMEL_LINUX --- > > ignoring ../src/m3overrides > > new source -> compiling RTHooks.i3 > cm3cg: sorry, unimplemented: -mfloat-abi=hard and VFP > m3_backend => 1 > m3cc (aka cm3cg) failed compiling: RTHooks.ic > Assembler messages: > Error: can't open RTHooks.is for reading: No such file or directory > assemble => 1 > assembler failed assembling: RTHooks.is > > I'm not sure what's up here because it seems to contradict my C flags. > > Mika > > Jay K writes: >>Oh=2C sorry=2C here are things to try=0A= >>=0A= >>edit m3-sys/m3cc/src/platforms.quake=0A= >>look for ARMEL_LINUX=2C change the right hand side to arm-linux-gnueabihf= >>=0A= >>=0A= >>and/or in src/m3makefile=2C you want to add -with-hard-float or -with-hardf= >>loat..no=2C wait=2C from your other mail:=0A= >>=0A= >>=A0And=2C really=2C the guide here is what you showed for gcc:=A0=0A= >>=0A= >>=A0Configured with: ../src/configure =A0=0A= >>=A0 =A0 -v \=A0=0A= >>=A0 =A0 ... =A0=0A= >>=A0 =A0 --with-arch=3Darmv6 =A0=0A= >>=A0 =A0 --with-fpu=3Dvfp=A0=0A= >>=A0 =A0 --with-float=3Dhard =A0=0A= >>=A0 =A0 --target=3Darm-linux-gnueabihf=A0=0A= >>=0A= >>=A0One/some/all of those are relevant.=A0=0A= >>=A0You might as well go ahead and throw them all in for now.=A0=0A= >>=0A= >>=A0Hey -- isn't that C backend convenient? :)=A0=0A= >>=0A= >>=0A= >>=A0- Jay=0A= >>=0A= >>----------------------------------------=0A= >>> To: jay.krell at cornell.edu=0A= >>> CC: m3devel at elegosoft.com=0A= >>> Subject: more cm3cg on Raspberry Pi=0A= >>> Date: Fri=2C 18 Oct 2013 18:26:02 -0700=0A= >>> From: mika at async.caltech.edu=0A= >>>=0A= >>> After setting up for soft float=2C I got a lot of these warnings/errors..= >>.=0A= >>>=0A= >>> new source -> compiling RTHeapInfo.m3=0A= >>> RTHeapInfo.ms: Assembler messages:=0A= >>> RTHeapInfo.ms:859: rdhi=2C rdlo and rm must all be different=0A= >>> RTHeapInfo.ms:907: rdhi=2C rdlo and rm must all be different=0A= >>> RTHeapInfo.ms:927: rdhi=2C rdlo and rm must all be different=0A= >>> new source -> compiling RTHeapMap.i3=0A= >>>=0A= >>> This is with the following configuration:=0A= >>>=0A= >>> in /usr/local/cm3 I have the C-generating compiler installed. It seems to= >> mostly work=2C as discussed.=0A= >>>=0A= >>> Then I run boot2.sh=0A= >>>=0A= >>> boot.sh finally ends with the following output=2C which doesn't look quit= >>e right:=0A= >>>=0A= >>> =3D=3D package /big/home2/mika/2/cm3-cvs/cm3/m3-sys/mklib =3D=3D=0A= >>>=0A= >>> +++ /usr/local/cm3/bin/cm3 -build -DROOT=3D/big/home2/mika/2/cm3-cvs/cm3 = >>+++=0A= >>> --- building in ARMEL_LINUX ---=0A= >>>=0A= >>> ignoring ../src/m3overrides=0A= >>>=0A= >>> new source -> compiling Main.m3=0A= >>> -> linking mklib=0A= >>> =3D=3D> /big/home2/mika/2/cm3-cvs/cm3/m3-sys/mklib done=0A= >>>=0A= >>> +++ /usr/local/cm3/bin/cm3 -ship -DROOT=3D/big/home2/mika/2/cm3-cvs/cm3 += >>++=0A= >>> --- shipping from ARMEL_LINUX ---=0A= >>>=0A= >>> . =3D> /usr/local/cm3/pkg/mklib/ARMEL_LINUX=0A= >>> .M3EXPORTS .M3WEB=0A= >>> ../src =3D> /usr/local/cm3/pkg/mklib/src=0A= >>> Main.m3=0A= >>> . =3D> /usr/local/cm3/bin=0A= >>> mklib=0A= >>> =3D=3D> /big/home2/mika/2/cm3-cvs/cm3/m3-sys/mklib done=0A= >>>=0A= >>> /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cggen/ARMEL_LINUX/m3cggen> /big/ho= >>me2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/gcc/gcc/m3cg/m3cg.h=0A= >>> mkdir -p /usr/local/cm3/bin=0A= >>> cp -Pv /big/home2/mika/2/cm3-cvs/cm3/m3-sys/cm3/ARMEL_LINUX/cm3 /usr/loca= >>l/cm3/bin/cm3=0A= >>> Traceback (most recent call last):=0A= >>> File "./upgrade.py"=2C line 72=2C in =0A= >>> reload(pylib) # compiler host type may have changed and need to recompute= >> stuff=0A= >>> File "/big/home2/mika/2/cm3-cvs/cm3/scripts/python/pylib.py"=2C line 650= >>=2C in =0A= >>> if Host.endswith("_NT") or Host =3D=3D "NT386":=0A= >>> AttributeError: 'NoneType' object has no attribute 'endswith'=0A= >>> raspberrypi:/big/home2/mika/2/cm3-cvs/cm3/scripts/python#=0A= >>>=0A= >>> Mika = From jay.krell at cornell.edu Tue Oct 22 04:52:20 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 22 Oct 2013 02:52:20 +0000 Subject: [M3devel] more cm3cg on Raspberry Pi In-Reply-To: References: <20131019012602.C96441A208E@async.async.caltech.edu>, , , <20131022013433.A39161A208E@async.async.caltech.edu>, Message-ID: sorry, maybe that was sloppy and easily fixed.. ---------------------------------------- > From: jay.krell at cornell.edu > To: mika at async.caltech.edu > Date: Tue, 22 Oct 2013 02:40:49 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] more cm3cg on Raspberry Pi > >> cm3cg: sorry, unimplemented: -mfloat-abi=hard and VFP > > drat. I'll try to cross build a boot archive, but I should see the same thing. > Maybe the support is not in mainline? And we should port it from some Raspberry Pi place? > Or maybe those last switches aren't needed? > Or maybe just give up and stick with C? > > > - Jay > > ---------------------------------------- >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: more cm3cg on Raspberry Pi >> Date: Mon, 21 Oct 2013 18:34:33 -0700 >> From: mika at async.caltech.edu >> >> Jay, you did these changes to the repository, for ARMEL_LINUX, right? >> >> I recompiled everything, but I'm not sure I got the whole configuration >> or how to check. My cm3cg in any case reports as follows: >> >> raspberrypi:/big/home2/mika/2/cm3-cvs/cm3/scripts/python# cm3cg -version >> Modula-3 backend (GCC) version 4.7.1 (armv6l-unknown-linux-gnueabihf) >> compiled by GNU C version 4.6.3, GGC heuristics: --param ggc-min-expand=59 --param ggc-min-heapsize=56092 >> Modula-3 backend (GCC) version 4.7.1 (armv6l-unknown-linux-gnueabihf) >> compiled by GNU C version 4.6.3, GGC heuristics: --param ggc-min-expand=59 --param ggc-min-heapsize=56092 >> options passed: >> options enabled: -fauto-inc-dec -fbranch-count-reg -fcommon >> -fdebug-types-section -fdelete-null-pointer-checks -fdwarf2-cfi-asm >> -fearly-inlining -feliminate-unused-debug-types -fexceptions >> -ffunction-cse -fgcse-lm -fgnu-runtime -fident -finline-atomics >> -fira-share-save-slots -fira-share-spill-slots -fivopts >> -fkeep-static-consts -fleading-underscore -fmath-errno >> -fmerge-debug-strings -fmove-loop-invariants -fpeephole >> -fprefetch-loop-arrays -freg-struct-return -fsched-critical-path-heuristic >> -fsched-dep-count-heuristic -fsched-group-heuristic -fsched-interblock >> -fsched-last-insn-heuristic -fsched-rank-heuristic -fsched-spec >> -fsched-spec-insn-heuristic -fsched-stalled-insns-dep -fshow-column >> -fsigned-zeros -fsplit-ivs-in-unroller -fstrict-volatile-bitfields >> -ftrapping-math -ftree-cselim -ftree-forwprop -ftree-loop-if-convert >> -ftree-loop-im -ftree-loop-ivcanon -ftree-loop-optimize >> -ftree-parallelize-loops= -ftree-phiprop -ftree-pta -ftree-reassoc >> -ftree-scev-cprop -ftree-slp-vectorize -ftree-vect-loop-version >> -funit-at-a-time -fvar-tracking -fvar-tracking-assignments >> -fzero-initialized-in-bss -marm -mglibc -mlittle-endian -msched-prolog >> -mvectorize-with-neon-quad >> >> unfortunately this is what happens now.... >> >> raspberrypi:/big/home2/mika/2/cm3-cvs/cm3/scripts/python# ./do-pkg.py m3core libm3 buildship >> CM3_TARGET=ARMEL_LINUX >> export CM3_TARGET >> CM3_INSTALL=/usr/local/cm3 >> export CM3_INSTALL >> CM3_ROOT=/big/home2/mika/2/cm3-cvs/cm3 >> export CM3_ROOT >> == package /big/home2/mika/2/cm3-cvs/cm3/m3-libs/m3core == >> >> +++ /usr/local/cm3/bin/cm3 -build -DROOT=/big/home2/mika/2/cm3-cvs/cm3 +++ >> --- building in ARMEL_LINUX --- >> >> ignoring ../src/m3overrides >> >> new source -> compiling RTHooks.i3 >> cm3cg: sorry, unimplemented: -mfloat-abi=hard and VFP >> m3_backend => 1 >> m3cc (aka cm3cg) failed compiling: RTHooks.ic >> Assembler messages: >> Error: can't open RTHooks.is for reading: No such file or directory >> assemble => 1 >> assembler failed assembling: RTHooks.is >> >> I'm not sure what's up here because it seems to contradict my C flags. >> >> Mika >> >> Jay K writes: >>>Oh=2C sorry=2C here are things to try=0A= >>>=0A= >>>edit m3-sys/m3cc/src/platforms.quake=0A= >>>look for ARMEL_LINUX=2C change the right hand side to arm-linux-gnueabihf= >>>=0A= >>>=0A= >>>and/or in src/m3makefile=2C you want to add -with-hard-float or -with-hardf= >>>loat..no=2C wait=2C from your other mail:=0A= >>>=0A= >>>=A0And=2C really=2C the guide here is what you showed for gcc:=A0=0A= >>>=0A= >>>=A0Configured with: ../src/configure =A0=0A= >>>=A0 =A0 -v \=A0=0A= >>>=A0 =A0 ... =A0=0A= >>>=A0 =A0 --with-arch=3Darmv6 =A0=0A= >>>=A0 =A0 --with-fpu=3Dvfp=A0=0A= >>>=A0 =A0 --with-float=3Dhard =A0=0A= >>>=A0 =A0 --target=3Darm-linux-gnueabihf=A0=0A= >>>=0A= >>>=A0One/some/all of those are relevant.=A0=0A= >>>=A0You might as well go ahead and throw them all in for now.=A0=0A= >>>=0A= >>>=A0Hey -- isn't that C backend convenient? :)=A0=0A= >>>=0A= >>>=0A= >>>=A0- Jay=0A= >>>=0A= >>>----------------------------------------=0A= >>>> To: jay.krell at cornell.edu=0A= >>>> CC: m3devel at elegosoft.com=0A= >>>> Subject: more cm3cg on Raspberry Pi=0A= >>>> Date: Fri=2C 18 Oct 2013 18:26:02 -0700=0A= >>>> From: mika at async.caltech.edu=0A= >>>>=0A= >>>> After setting up for soft float=2C I got a lot of these warnings/errors..= >>>.=0A= >>>>=0A= >>>> new source -> compiling RTHeapInfo.m3=0A= >>>> RTHeapInfo.ms: Assembler messages:=0A= >>>> RTHeapInfo.ms:859: rdhi=2C rdlo and rm must all be different=0A= >>>> RTHeapInfo.ms:907: rdhi=2C rdlo and rm must all be different=0A= >>>> RTHeapInfo.ms:927: rdhi=2C rdlo and rm must all be different=0A= >>>> new source -> compiling RTHeapMap.i3=0A= >>>>=0A= >>>> This is with the following configuration:=0A= >>>>=0A= >>>> in /usr/local/cm3 I have the C-generating compiler installed. It seems to= >>> mostly work=2C as discussed.=0A= >>>>=0A= >>>> Then I run boot2.sh=0A= >>>>=0A= >>>> boot.sh finally ends with the following output=2C which doesn't look quit= >>>e right:=0A= >>>>=0A= >>>> =3D=3D package /big/home2/mika/2/cm3-cvs/cm3/m3-sys/mklib =3D=3D=0A= >>>>=0A= >>>> +++ /usr/local/cm3/bin/cm3 -build -DROOT=3D/big/home2/mika/2/cm3-cvs/cm3 = >>>+++=0A= >>>> --- building in ARMEL_LINUX ---=0A= >>>>=0A= >>>> ignoring ../src/m3overrides=0A= >>>>=0A= >>>> new source -> compiling Main.m3=0A= >>>> -> linking mklib=0A= >>>> =3D=3D> /big/home2/mika/2/cm3-cvs/cm3/m3-sys/mklib done=0A= >>>>=0A= >>>> +++ /usr/local/cm3/bin/cm3 -ship -DROOT=3D/big/home2/mika/2/cm3-cvs/cm3 += >>>++=0A= >>>> --- shipping from ARMEL_LINUX ---=0A= >>>>=0A= >>>> . =3D> /usr/local/cm3/pkg/mklib/ARMEL_LINUX=0A= >>>> .M3EXPORTS .M3WEB=0A= >>>> ../src =3D> /usr/local/cm3/pkg/mklib/src=0A= >>>> Main.m3=0A= >>>> . =3D> /usr/local/cm3/bin=0A= >>>> mklib=0A= >>>> =3D=3D> /big/home2/mika/2/cm3-cvs/cm3/m3-sys/mklib done=0A= >>>>=0A= >>>> /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cggen/ARMEL_LINUX/m3cggen> /big/ho= >>>me2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/gcc/gcc/m3cg/m3cg.h=0A= >>>> mkdir -p /usr/local/cm3/bin=0A= >>>> cp -Pv /big/home2/mika/2/cm3-cvs/cm3/m3-sys/cm3/ARMEL_LINUX/cm3 /usr/loca= >>>l/cm3/bin/cm3=0A= >>>> Traceback (most recent call last):=0A= >>>> File "./upgrade.py"=2C line 72=2C in =0A= >>>> reload(pylib) # compiler host type may have changed and need to recompute= >>> stuff=0A= >>>> File "/big/home2/mika/2/cm3-cvs/cm3/scripts/python/pylib.py"=2C line 650= >>>=2C in =0A= >>>> if Host.endswith("_NT") or Host =3D=3D "NT386":=0A= >>>> AttributeError: 'NoneType' object has no attribute 'endswith'=0A= >>>> raspberrypi:/big/home2/mika/2/cm3-cvs/cm3/scripts/python#=0A= >>>>=0A= >>>> Mika = From jay.krell at cornell.edu Tue Oct 22 05:13:07 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 22 Oct 2013 03:13:07 +0000 Subject: [M3devel] more cm3cg on Raspberry Pi In-Reply-To: References: <20131019012602.C96441A208E@async.async.caltech.edu>, , , , , <20131022013433.A39161A208E@async.async.caltech.edu>, , , Message-ID: Try again? I was able to build a boot archive. The main change was just removing the flags from m3-sys/cminstall/src/config-no-install. ARM_LINUX also wasn't equivalent to ARMEL_LINUX as I had intended. ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > To: mika at async.caltech.edu > Date: Tue, 22 Oct 2013 02:52:20 +0000 > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] more cm3cg on Raspberry Pi > > sorry, maybe that was sloppy and easily fixed.. > > > ---------------------------------------- >> From: jay.krell at cornell.edu >> To: mika at async.caltech.edu >> Date: Tue, 22 Oct 2013 02:40:49 +0000 >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] more cm3cg on Raspberry Pi >> >>> cm3cg: sorry, unimplemented: -mfloat-abi=hard and VFP >> >> drat. I'll try to cross build a boot archive, but I should see the same thing. >> Maybe the support is not in mainline? And we should port it from some Raspberry Pi place? >> Or maybe those last switches aren't needed? >> Or maybe just give up and stick with C? >> >> >> - Jay >> >> ---------------------------------------- >>> To: jay.krell at cornell.edu >>> CC: m3devel at elegosoft.com >>> Subject: Re: more cm3cg on Raspberry Pi >>> Date: Mon, 21 Oct 2013 18:34:33 -0700 >>> From: mika at async.caltech.edu >>> >>> Jay, you did these changes to the repository, for ARMEL_LINUX, right? >>> >>> I recompiled everything, but I'm not sure I got the whole configuration >>> or how to check. My cm3cg in any case reports as follows: >>> >>> raspberrypi:/big/home2/mika/2/cm3-cvs/cm3/scripts/python# cm3cg -version >>> Modula-3 backend (GCC) version 4.7.1 (armv6l-unknown-linux-gnueabihf) >>> compiled by GNU C version 4.6.3, GGC heuristics: --param ggc-min-expand=59 --param ggc-min-heapsize=56092 >>> Modula-3 backend (GCC) version 4.7.1 (armv6l-unknown-linux-gnueabihf) >>> compiled by GNU C version 4.6.3, GGC heuristics: --param ggc-min-expand=59 --param ggc-min-heapsize=56092 >>> options passed: >>> options enabled: -fauto-inc-dec -fbranch-count-reg -fcommon >>> -fdebug-types-section -fdelete-null-pointer-checks -fdwarf2-cfi-asm >>> -fearly-inlining -feliminate-unused-debug-types -fexceptions >>> -ffunction-cse -fgcse-lm -fgnu-runtime -fident -finline-atomics >>> -fira-share-save-slots -fira-share-spill-slots -fivopts >>> -fkeep-static-consts -fleading-underscore -fmath-errno >>> -fmerge-debug-strings -fmove-loop-invariants -fpeephole >>> -fprefetch-loop-arrays -freg-struct-return -fsched-critical-path-heuristic >>> -fsched-dep-count-heuristic -fsched-group-heuristic -fsched-interblock >>> -fsched-last-insn-heuristic -fsched-rank-heuristic -fsched-spec >>> -fsched-spec-insn-heuristic -fsched-stalled-insns-dep -fshow-column >>> -fsigned-zeros -fsplit-ivs-in-unroller -fstrict-volatile-bitfields >>> -ftrapping-math -ftree-cselim -ftree-forwprop -ftree-loop-if-convert >>> -ftree-loop-im -ftree-loop-ivcanon -ftree-loop-optimize >>> -ftree-parallelize-loops= -ftree-phiprop -ftree-pta -ftree-reassoc >>> -ftree-scev-cprop -ftree-slp-vectorize -ftree-vect-loop-version >>> -funit-at-a-time -fvar-tracking -fvar-tracking-assignments >>> -fzero-initialized-in-bss -marm -mglibc -mlittle-endian -msched-prolog >>> -mvectorize-with-neon-quad >>> >>> unfortunately this is what happens now.... >>> >>> raspberrypi:/big/home2/mika/2/cm3-cvs/cm3/scripts/python# ./do-pkg.py m3core libm3 buildship >>> CM3_TARGET=ARMEL_LINUX >>> export CM3_TARGET >>> CM3_INSTALL=/usr/local/cm3 >>> export CM3_INSTALL >>> CM3_ROOT=/big/home2/mika/2/cm3-cvs/cm3 >>> export CM3_ROOT >>> == package /big/home2/mika/2/cm3-cvs/cm3/m3-libs/m3core == >>> >>> +++ /usr/local/cm3/bin/cm3 -build -DROOT=/big/home2/mika/2/cm3-cvs/cm3 +++ >>> --- building in ARMEL_LINUX --- >>> >>> ignoring ../src/m3overrides >>> >>> new source -> compiling RTHooks.i3 >>> cm3cg: sorry, unimplemented: -mfloat-abi=hard and VFP >>> m3_backend => 1 >>> m3cc (aka cm3cg) failed compiling: RTHooks.ic >>> Assembler messages: >>> Error: can't open RTHooks.is for reading: No such file or directory >>> assemble => 1 >>> assembler failed assembling: RTHooks.is >>> >>> I'm not sure what's up here because it seems to contradict my C flags. >>> >>> Mika >>> >>> Jay K writes: >>>>Oh=2C sorry=2C here are things to try=0A= >>>>=0A= >>>>edit m3-sys/m3cc/src/platforms.quake=0A= >>>>look for ARMEL_LINUX=2C change the right hand side to arm-linux-gnueabihf= >>>>=0A= >>>>=0A= >>>>and/or in src/m3makefile=2C you want to add -with-hard-float or -with-hardf= >>>>loat..no=2C wait=2C from your other mail:=0A= >>>>=0A= >>>>=A0And=2C really=2C the guide here is what you showed for gcc:=A0=0A= >>>>=0A= >>>>=A0Configured with: ../src/configure =A0=0A= >>>>=A0 =A0 -v \=A0=0A= >>>>=A0 =A0 ... =A0=0A= >>>>=A0 =A0 --with-arch=3Darmv6 =A0=0A= >>>>=A0 =A0 --with-fpu=3Dvfp=A0=0A= >>>>=A0 =A0 --with-float=3Dhard =A0=0A= >>>>=A0 =A0 --target=3Darm-linux-gnueabihf=A0=0A= >>>>=0A= >>>>=A0One/some/all of those are relevant.=A0=0A= >>>>=A0You might as well go ahead and throw them all in for now.=A0=0A= >>>>=0A= >>>>=A0Hey -- isn't that C backend convenient? :)=A0=0A= >>>>=0A= >>>>=0A= >>>>=A0- Jay=0A= >>>>=0A= >>>>----------------------------------------=0A= >>>>> To: jay.krell at cornell.edu=0A= >>>>> CC: m3devel at elegosoft.com=0A= >>>>> Subject: more cm3cg on Raspberry Pi=0A= >>>>> Date: Fri=2C 18 Oct 2013 18:26:02 -0700=0A= >>>>> From: mika at async.caltech.edu=0A= >>>>>=0A= >>>>> After setting up for soft float=2C I got a lot of these warnings/errors..= >>>>.=0A= >>>>>=0A= >>>>> new source -> compiling RTHeapInfo.m3=0A= >>>>> RTHeapInfo.ms: Assembler messages:=0A= >>>>> RTHeapInfo.ms:859: rdhi=2C rdlo and rm must all be different=0A= >>>>> RTHeapInfo.ms:907: rdhi=2C rdlo and rm must all be different=0A= >>>>> RTHeapInfo.ms:927: rdhi=2C rdlo and rm must all be different=0A= >>>>> new source -> compiling RTHeapMap.i3=0A= >>>>>=0A= >>>>> This is with the following configuration:=0A= >>>>>=0A= >>>>> in /usr/local/cm3 I have the C-generating compiler installed. It seems to= >>>> mostly work=2C as discussed.=0A= >>>>>=0A= >>>>> Then I run boot2.sh=0A= >>>>>=0A= >>>>> boot.sh finally ends with the following output=2C which doesn't look quit= >>>>e right:=0A= >>>>>=0A= >>>>> =3D=3D package /big/home2/mika/2/cm3-cvs/cm3/m3-sys/mklib =3D=3D=0A= >>>>>=0A= >>>>> +++ /usr/local/cm3/bin/cm3 -build -DROOT=3D/big/home2/mika/2/cm3-cvs/cm3 = >>>>+++=0A= >>>>> --- building in ARMEL_LINUX ---=0A= >>>>>=0A= >>>>> ignoring ../src/m3overrides=0A= >>>>>=0A= >>>>> new source -> compiling Main.m3=0A= >>>>> -> linking mklib=0A= >>>>> =3D=3D> /big/home2/mika/2/cm3-cvs/cm3/m3-sys/mklib done=0A= >>>>>=0A= >>>>> +++ /usr/local/cm3/bin/cm3 -ship -DROOT=3D/big/home2/mika/2/cm3-cvs/cm3 += >>>>++=0A= >>>>> --- shipping from ARMEL_LINUX ---=0A= >>>>>=0A= >>>>> . =3D> /usr/local/cm3/pkg/mklib/ARMEL_LINUX=0A= >>>>> .M3EXPORTS .M3WEB=0A= >>>>> ../src =3D> /usr/local/cm3/pkg/mklib/src=0A= >>>>> Main.m3=0A= >>>>> . =3D> /usr/local/cm3/bin=0A= >>>>> mklib=0A= >>>>> =3D=3D> /big/home2/mika/2/cm3-cvs/cm3/m3-sys/mklib done=0A= >>>>>=0A= >>>>> /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cggen/ARMEL_LINUX/m3cggen> /big/ho= >>>>me2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/gcc/gcc/m3cg/m3cg.h=0A= >>>>> mkdir -p /usr/local/cm3/bin=0A= >>>>> cp -Pv /big/home2/mika/2/cm3-cvs/cm3/m3-sys/cm3/ARMEL_LINUX/cm3 /usr/loca= >>>>l/cm3/bin/cm3=0A= >>>>> Traceback (most recent call last):=0A= >>>>> File "./upgrade.py"=2C line 72=2C in =0A= >>>>> reload(pylib) # compiler host type may have changed and need to recompute= >>>> stuff=0A= >>>>> File "/big/home2/mika/2/cm3-cvs/cm3/scripts/python/pylib.py"=2C line 650= >>>>=2C in =0A= >>>>> if Host.endswith("_NT") or Host =3D=3D "NT386":=0A= >>>>> AttributeError: 'NoneType' object has no attribute 'endswith'=0A= >>>>> raspberrypi:/big/home2/mika/2/cm3-cvs/cm3/scripts/python#=0A= >>>>>=0A= >>>>> Mika = From jay.krell at cornell.edu Tue Oct 22 17:39:35 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 22 Oct 2013 15:39:35 +0000 Subject: [M3devel] m3dl/DL.i3 In-Reply-To: <20131015185250.ECFCA1A2091@async.async.caltech.edu> References: , <20131015185250.ECFCA1A2091@async.async.caltech.edu> Message-ID: This is wrong for Darwin and partly wrong for NetBSD. It is correct for Solaris. I haven't checked OpenBSD and FreeBSD yet. Please look at how m3-libs/m3core/src/unix is structured for a more portable approach. Plus this can be #ifdefed to Windows fairly easily, ignoring the flags. ? dlopen => LoadLibrary ?(LoadLibraryA I guess)? ? dlsym => GetProcAddress ? ? dlclose => FreeLibrary ? And please consider a BSD license. ? - Jay From mika at async.caltech.edu Tue Oct 22 18:28:02 2013 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Tue, 22 Oct 2013 09:28:02 -0700 Subject: [M3devel] more cm3cg on Raspberry Pi In-Reply-To: References: <20131019012602.C96441A208E@async.async.caltech.edu>, , , , , <20131022013433.A39161A208E@async.async.caltech.edu>, , ,

Message-ID: <20131022162802.5E33E1A208E@async.async.caltech.edu> Well I deleted ARMEL_LINUX/m3cc for good measure and still... TickPortable.ms:294: Error: selected processor does not support ARM mode `ldfd f1,[sp],#8' TickPortable.ms:295: Error: selected processor does not support ARM mode `dvfd f0,f0,f1' TickPortable.ms:296: Error: selected processor does not support ARM mode `stfd f0,[sp,#-8]!' TickPortable.ms:312: Error: selected processor does not support ARM mode `ldfd f2,[sp],#8' TickPortable.ms:314: Error: selected processor does not support ARM mode `ldfd f0,[sp],#8' TickPortable.ms:315: Error: selected processor does not support ARM mode `cmfe f2,f0' TickPortable.ms:322: Error: selected processor does not support ARM mode `ldfd f1,[sp],#8' TickPortable.ms:323: Error: selected processor does not support ARM mode `fixz r3,f1' TickPortable.ms:333: Error: selected processor does not support ARM mode `ldfd f2,[sp],#8' TickPortable.ms:335: Error: selected processor does not support ARM mode `ldfd f0,[sp],#8' TickPortable.ms:336: Error: selected processor does not support ARM mode `cmfe f2,f0' TickPortable.ms:345: Error: selected processor does not support ARM mode `ldfd f1,[sp],#8' TickPortable.ms:347: Error: selected processor does not support ARM mode `ldfd f2,[sp],#8' TickPortable.ms:348: Error: selected processor does not support ARM mode `sufd f0,f1,f2' TickPortable.ms:349: Error: selected processor does not support ARM mode `fixz r3,f0' assemble => 1 assembler failed assembling: TickPortable.ms (etc.) I'm really quite happy to use the C-generating compiler but need to make sure it is working right. Although of course it would be a bonus to have a "native" compiler, too. I was hoping to do performance comparisons but can of course do those on FreeBSD4 or some x86-based Linux too. Or have you already done them? Mika Jay K writes: >Try again? I was able to build a boot archive.=0A= >The main change was just removing the flags from m3-sys/cminstall/src/confi= >g-no-install.=0A= >ARM_LINUX also wasn't equivalent to ARMEL_LINUX as I had intended.=0A= >=0A= >=A0- Jay=0A= >=0A= >----------------------------------------=0A= >> From: jay.krell at cornell.edu=0A= >> To: mika at async.caltech.edu=0A= >> Date: Tue=2C 22 Oct 2013 02:52:20 +0000=0A= >> CC: m3devel at elegosoft.com=0A= >> Subject: Re: [M3devel] more cm3cg on Raspberry Pi=0A= >>=0A= >> sorry=2C maybe that was sloppy and easily fixed..=0A= >>=0A= >>=0A= >> ----------------------------------------=0A= >>> From: jay.krell at cornell.edu=0A= >>> To: mika at async.caltech.edu=0A= >>> Date: Tue=2C 22 Oct 2013 02:40:49 +0000=0A= >>> CC: m3devel at elegosoft.com=0A= >>> Subject: Re: [M3devel] more cm3cg on Raspberry Pi=0A= >>>=0A= >>>> cm3cg: sorry=2C unimplemented: -mfloat-abi=3Dhard and VFP=0A= >>>=0A= >>> drat. I'll try to cross build a boot archive=2C but I should see the sam= >e thing.=0A= >>> Maybe the support is not in mainline? And we should port it from some Ra= >spberry Pi place?=0A= >>> Or maybe those last switches aren't needed?=0A= >>> Or maybe just give up and stick with C?=0A= >>>=0A= >>>=0A= >>> - Jay=0A= >>>=0A= >>> ----------------------------------------=0A= >>>> To: jay.krell at cornell.edu=0A= >>>> CC: m3devel at elegosoft.com=0A= >>>> Subject: Re: more cm3cg on Raspberry Pi=0A= >>>> Date: Mon=2C 21 Oct 2013 18:34:33 -0700=0A= >>>> From: mika at async.caltech.edu=0A= >>>>=0A= >>>> Jay=2C you did these changes to the repository=2C for ARMEL_LINUX=2C ri= >ght?=0A= >>>>=0A= >>>> I recompiled everything=2C but I'm not sure I got the whole configurati= >on=0A= >>>> or how to check. My cm3cg in any case reports as follows:=0A= >>>>=0A= >>>> raspberrypi:/big/home2/mika/2/cm3-cvs/cm3/scripts/python# cm3cg -versio= >n=0A= >>>> Modula-3 backend (GCC) version 4.7.1 (armv6l-unknown-linux-gnueabihf)= >=0A= >>>> compiled by GNU C version 4.6.3=2C GGC heuristics: --param ggc-min-expa= >nd=3D59 --param ggc-min-heapsize=3D56092=0A= >>>> Modula-3 backend (GCC) version 4.7.1 (armv6l-unknown-linux-gnueabihf)= >=0A= >>>> compiled by GNU C version 4.6.3=2C GGC heuristics: --param ggc-min-expa= >nd=3D59 --param ggc-min-heapsize=3D56092=0A= >>>> options passed:=0A= >>>> options enabled: -fauto-inc-dec -fbranch-count-reg -fcommon=0A= >>>> -fdebug-types-section -fdelete-null-pointer-checks -fdwarf2-cfi-asm=0A= >>>> -fearly-inlining -feliminate-unused-debug-types -fexceptions=0A= >>>> -ffunction-cse -fgcse-lm -fgnu-runtime -fident -finline-atomics=0A= >>>> -fira-share-save-slots -fira-share-spill-slots -fivopts=0A= >>>> -fkeep-static-consts -fleading-underscore -fmath-errno=0A= >>>> -fmerge-debug-strings -fmove-loop-invariants -fpeephole=0A= >>>> -fprefetch-loop-arrays -freg-struct-return -fsched-critical-path-heuris= >tic=0A= >>>> -fsched-dep-count-heuristic -fsched-group-heuristic -fsched-interblock= >=0A= >>>> -fsched-last-insn-heuristic -fsched-rank-heuristic -fsched-spec=0A= >>>> -fsched-spec-insn-heuristic -fsched-stalled-insns-dep -fshow-column=0A= >>>> -fsigned-zeros -fsplit-ivs-in-unroller -fstrict-volatile-bitfields=0A= >>>> -ftrapping-math -ftree-cselim -ftree-forwprop -ftree-loop-if-convert=0A= >>>> -ftree-loop-im -ftree-loop-ivcanon -ftree-loop-optimize=0A= >>>> -ftree-parallelize-loops=3D -ftree-phiprop -ftree-pta -ftree-reassoc=0A= >>>> -ftree-scev-cprop -ftree-slp-vectorize -ftree-vect-loop-version=0A= >>>> -funit-at-a-time -fvar-tracking -fvar-tracking-assignments=0A= >>>> -fzero-initialized-in-bss -marm -mglibc -mlittle-endian -msched-prolog= >=0A= >>>> -mvectorize-with-neon-quad=0A= >>>>=0A= >>>> unfortunately this is what happens now....=0A= >>>>=0A= >>>> raspberrypi:/big/home2/mika/2/cm3-cvs/cm3/scripts/python# ./do-pkg.py m= >3core libm3 buildship=0A= >>>> CM3_TARGET=3DARMEL_LINUX=0A= >>>> export CM3_TARGET=0A= >>>> CM3_INSTALL=3D/usr/local/cm3=0A= >>>> export CM3_INSTALL=0A= >>>> CM3_ROOT=3D/big/home2/mika/2/cm3-cvs/cm3=0A= >>>> export CM3_ROOT=0A= >>>> =3D=3D package /big/home2/mika/2/cm3-cvs/cm3/m3-libs/m3core =3D=3D=0A= >>>>=0A= >>>> +++ /usr/local/cm3/bin/cm3 -build -DROOT=3D/big/home2/mika/2/cm3-cvs/cm= >3 +++=0A= >>>> --- building in ARMEL_LINUX ---=0A= >>>>=0A= >>>> ignoring ../src/m3overrides=0A= >>>>=0A= >>>> new source -> compiling RTHooks.i3=0A= >>>> cm3cg: sorry=2C unimplemented: -mfloat-abi=3Dhard and VFP=0A= >>>> m3_backend =3D> 1=0A= >>>> m3cc (aka cm3cg) failed compiling: RTHooks.ic=0A= >>>> Assembler messages:=0A= >>>> Error: can't open RTHooks.is for reading: No such file or directory=0A= >>>> assemble =3D> 1=0A= >>>> assembler failed assembling: RTHooks.is=0A= >>>>=0A= >>>> I'm not sure what's up here because it seems to contradict my C flags.= >=0A= >>>>=0A= >>>> Mika=0A= >>>>=0A= >>>> Jay K writes:=0A= >>>>>Oh=3D2C sorry=3D2C here are things to try=3D0A=3D=0A= >>>>>=3D0A=3D=0A= >>>>>edit m3-sys/m3cc/src/platforms.quake=3D0A=3D=0A= >>>>>look for ARMEL_LINUX=3D2C change the right hand side to arm-linux-gnuea= >bihf=3D=0A= >>>>>=3D0A=3D=0A= >>>>>=3D0A=3D=0A= >>>>>and/or in src/m3makefile=3D2C you want to add -with-hard-float or -with= >-hardf=3D=0A= >>>>>loat..no=3D2C wait=3D2C from your other mail:=3D0A=3D=0A= >>>>>=3D0A=3D=0A= >>>>>=3DA0And=3D2C really=3D2C the guide here is what you showed for gcc:=3D= >A0=3D0A=3D=0A= >>>>>=3D0A=3D=0A= >>>>>=3DA0Configured with: ../src/configure =3DA0=3D0A=3D=0A= >>>>>=3DA0 =3DA0 -v \=3DA0=3D0A=3D=0A= >>>>>=3DA0 =3DA0 ... =3DA0=3D0A=3D=0A= >>>>>=3DA0 =3DA0 --with-arch=3D3Darmv6 =3DA0=3D0A=3D=0A= >>>>>=3DA0 =3DA0 --with-fpu=3D3Dvfp=3DA0=3D0A=3D=0A= >>>>>=3DA0 =3DA0 --with-float=3D3Dhard =3DA0=3D0A=3D=0A= >>>>>=3DA0 =3DA0 --target=3D3Darm-linux-gnueabihf=3DA0=3D0A=3D=0A= >>>>>=3D0A=3D=0A= >>>>>=3DA0One/some/all of those are relevant.=3DA0=3D0A=3D=0A= >>>>>=3DA0You might as well go ahead and throw them all in for now.=3DA0=3D0= >A=3D=0A= >>>>>=3D0A=3D=0A= >>>>>=3DA0Hey -- isn't that C backend convenient? :)=3DA0=3D0A=3D=0A= >>>>>=3D0A=3D=0A= >>>>>=3D0A=3D=0A= >>>>>=3DA0- Jay=3D0A=3D=0A= >>>>>=3D0A=3D=0A= >>>>>----------------------------------------=3D0A=3D=0A= >>>>>> To: jay.krell at cornell.edu=3D0A=3D=0A= >>>>>> CC: m3devel at elegosoft.com=3D0A=3D=0A= >>>>>> Subject: more cm3cg on Raspberry Pi=3D0A=3D=0A= >>>>>> Date: Fri=3D2C 18 Oct 2013 18:26:02 -0700=3D0A=3D=0A= >>>>>> From: mika at async.caltech.edu=3D0A=3D=0A= >>>>>>=3D0A=3D=0A= >>>>>> After setting up for soft float=3D2C I got a lot of these warnings/er= >rors..=3D=0A= >>>>>.=3D0A=3D=0A= >>>>>>=3D0A=3D=0A= >>>>>> new source -> compiling RTHeapInfo.m3=3D0A=3D=0A= >>>>>> RTHeapInfo.ms: Assembler messages:=3D0A=3D=0A= >>>>>> RTHeapInfo.ms:859: rdhi=3D2C rdlo and rm must all be different=3D0A= >=3D=0A= >>>>>> RTHeapInfo.ms:907: rdhi=3D2C rdlo and rm must all be different=3D0A= >=3D=0A= >>>>>> RTHeapInfo.ms:927: rdhi=3D2C rdlo and rm must all be different=3D0A= >=3D=0A= >>>>>> new source -> compiling RTHeapMap.i3=3D0A=3D=0A= >>>>>>=3D0A=3D=0A= >>>>>> This is with the following configuration:=3D0A=3D=0A= >>>>>>=3D0A=3D=0A= >>>>>> in /usr/local/cm3 I have the C-generating compiler installed. It seem= >s to=3D=0A= >>>>> mostly work=3D2C as discussed.=3D0A=3D=0A= >>>>>>=3D0A=3D=0A= >>>>>> Then I run boot2.sh=3D0A=3D=0A= >>>>>>=3D0A=3D=0A= >>>>>> boot.sh finally ends with the following output=3D2C which doesn't loo= >k quit=3D=0A= >>>>>e right:=3D0A=3D=0A= >>>>>>=3D0A=3D=0A= >>>>>> =3D3D=3D3D package /big/home2/mika/2/cm3-cvs/cm3/m3-sys/mklib =3D3D= >=3D3D=3D0A=3D=0A= >>>>>>=3D0A=3D=0A= >>>>>> +++ /usr/local/cm3/bin/cm3 -build -DROOT=3D3D/big/home2/mika/2/cm3-cv= >s/cm3 =3D=0A= >>>>>+++=3D0A=3D=0A= >>>>>> --- building in ARMEL_LINUX ---=3D0A=3D=0A= >>>>>>=3D0A=3D=0A= >>>>>> ignoring ../src/m3overrides=3D0A=3D=0A= >>>>>>=3D0A=3D=0A= >>>>>> new source -> compiling Main.m3=3D0A=3D=0A= >>>>>> -> linking mklib=3D0A=3D=0A= >>>>>> =3D3D=3D3D> /big/home2/mika/2/cm3-cvs/cm3/m3-sys/mklib done=3D0A=3D= >=0A= >>>>>>=3D0A=3D=0A= >>>>>> +++ /usr/local/cm3/bin/cm3 -ship -DROOT=3D3D/big/home2/mika/2/cm3-cvs= >/cm3 +=3D=0A= >>>>>++=3D0A=3D=0A= >>>>>> --- shipping from ARMEL_LINUX ---=3D0A=3D=0A= >>>>>>=3D0A=3D=0A= >>>>>> . =3D3D> /usr/local/cm3/pkg/mklib/ARMEL_LINUX=3D0A=3D=0A= >>>>>> .M3EXPORTS .M3WEB=3D0A=3D=0A= >>>>>> ../src =3D3D> /usr/local/cm3/pkg/mklib/src=3D0A=3D=0A= >>>>>> Main.m3=3D0A=3D=0A= >>>>>> . =3D3D> /usr/local/cm3/bin=3D0A=3D=0A= >>>>>> mklib=3D0A=3D=0A= >>>>>> =3D3D=3D3D> /big/home2/mika/2/cm3-cvs/cm3/m3-sys/mklib done=3D0A=3D= >=0A= >>>>>>=3D0A=3D=0A= >>>>>> /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cggen/ARMEL_LINUX/m3cggen> /bi= >g/ho=3D=0A= >>>>>me2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/gcc/gcc/m3cg/m3cg.h=3D0A=3D=0A= >>>>>> mkdir -p /usr/local/cm3/bin=3D0A=3D=0A= >>>>>> cp -Pv /big/home2/mika/2/cm3-cvs/cm3/m3-sys/cm3/ARMEL_LINUX/cm3 /usr/= >loca=3D=0A= >>>>>l/cm3/bin/cm3=3D0A=3D=0A= >>>>>> Traceback (most recent call last):=3D0A=3D=0A= >>>>>> File "./upgrade.py"=3D2C line 72=3D2C in =3D0A=3D=0A= >>>>>> reload(pylib) # compiler host type may have changed and need to recom= >pute=3D=0A= >>>>> stuff=3D0A=3D=0A= >>>>>> File "/big/home2/mika/2/cm3-cvs/cm3/scripts/python/pylib.py"=3D2C lin= >e 650=3D=0A= >>>>>=3D2C in =3D0A=3D=0A= >>>>>> if Host.endswith("_NT") or Host =3D3D=3D3D "NT386":=3D0A=3D=0A= >>>>>> AttributeError: 'NoneType' object has no attribute 'endswith'=3D0A=3D= >=0A= >>>>>> raspberrypi:/big/home2/mika/2/cm3-cvs/cm3/scripts/python#=3D0A=3D=0A= >>>>>>=3D0A=3D=0A= >>>>>> Mika =3D = From mika at async.caltech.edu Tue Oct 22 18:38:21 2013 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Tue, 22 Oct 2013 09:38:21 -0700 Subject: [M3devel] more cm3cg on Raspberry Pi In-Reply-To: References: <20131019012602.C96441A208E@async.async.caltech.edu>, , , , , <20131022013433.A39161A208E@async.async.caltech.edu>, , ,

Message-ID: <20131022163821.930EE1A208E@async.async.caltech.edu> I think I am at the same state as before. The compiler runs and things assemble with the float ABI set to "soft", except for a few assembler messages as follows: new source -> compiling RTTipe.i3 new source -> compiling RTTipe.m3 RTTipe.ms: Assembler messages: RTTipe.ms:2332: Rd and Rm should be different in mul RTTipe.ms:4064: Rd and Rm should be different in mul But I suspect this means it won't link with C code on the system? When I got as far as a cm3 binary like this, I just got a segfault out of it. Unless I am missing some m3cc configuration step. But as I mentioned, I deleted everything and started from scratch. It still says it doesn't support the "hard" ABI and -mfpu=vfp. Mika Jay K writes: >Try again? I was able to build a boot archive.=0A= >The main change was just removing the flags from m3-sys/cminstall/src/confi= >g-no-install.=0A= >ARM_LINUX also wasn't equivalent to ARMEL_LINUX as I had intended.=0A= >=0A= >=A0- Jay=0A= >=0A= From mika at async.caltech.edu Tue Oct 22 18:47:01 2013 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Tue, 22 Oct 2013 09:47:01 -0700 Subject: [M3devel] more cm3cg on Raspberry Pi In-Reply-To: References: <20131019012602.C96441A208E@async.async.caltech.edu>, , , , , <20131022013433.A39161A208E@async.async.caltech.edu>, , ,

Message-ID: <20131022164701.3A9E21A208E@async.async.caltech.edu> One more thing ... from https://wiki.debian.org/ArmHardFloatPort/VfpComparison "The combination of -mfpu=vfp and -mfloat-abi=hard is not available in FSF GCC 4.4, but the CodeSourcery 2009q1 compiler (and later, current release is 2010q1) supports it as does FSF GCC 4.5." but the way cm3cg is compiled it says: root at raspberrypi:/big/home/mika# /usr/local/cm3/bin/cm3cg -version Modula-3 backend (GCC) version 4.7.1 (armv6l-unknown-linux-gnueabihf) compiled by GNU C version 4.6.3, GGC heuristics: --param ggc-min-expand=59 --param ggc-min-heapsize=56092 Modula-3 backend (GCC) version 4.7.1 (armv6l-unknown-linux-gnueabihf) compiled by GNU C version 4.6.3, GGC heuristics: --param ggc-min-expand=59 --param ggc-min-heapsize=56092 options passed: Hmm... so it should support the combination? But: root at raspberrypi:/big/home/mika# /usr/local/cm3/bin/cm3cg -mfpu=vfp -mfloat-abi=hard cm3cg: sorry, unimplemented: -mfloat-abi=hard and VFP Execution times (seconds) TOTAL : 0.00 0.00 0.02 0 kB Mika From jay.krell at cornell.edu Tue Oct 22 20:56:36 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 22 Oct 2013 18:56:36 +0000 Subject: [M3devel] more cm3cg on Raspberry Pi In-Reply-To: <20131022164701.3A9E21A208E@async.async.caltech.edu> References: <20131019012602.C96441A208E@async.async.caltech.edu>, , , , , <20131022013433.A39161A208E@async.async.caltech.edu>, , ,

, <20131022164701.3A9E21A208E@async.async.caltech.edu> Message-ID: A few things. I'm sorry this is so hard to get working. It shouldn't be. > The compiler runs and things assemble with the float ABI set to "soft" Can you tell from the assembly? I looked very quickly and couldn't tell. Ok me for me to be less lazy, please do this on the rpi: void f1(float); void f2(double); void f3() { f1(1); f2(2); } cc -c -s 1.c # or cc -c -S 1.c I can't remember cat 1.s # or cat 1.S I can't remember This will help. I'd like to be able to discern hardfloat from softfloat code. Er, I think in ARM there is "softfloat" and "softfp". "softfloat" is "everything is an integer" "softfp" is parameter passing in integer registers but use floating point hardware, I don't know if it is conditional or not. What is actually a big factor here is not what instructions are used, but how parameters are passed. (Because, you know, let's change that up every few years to add confusion and complexity...) I was of the impression, in my "second try" that the configuration of cm3cg made the later flags redundant. Though, granted, one wouldn't expect the error in that case. Also, maybe there is more configuration/flags here than nececessary? i.e. what if you say "hard float" but not vfp? Is that viable? And, in any case, please show again: gcc -v or gcc -V (I get confused) show we can see how it was configured and then I think, also, the above C code with -v or -V to see what flags are passed to cc1. And, and, and we should find out where your gcc was built from. And possibly merge it with ours. And, I agree, ours should already work, since it is FSF 4.7. And, we should try building an unpatched FSF gcc 4.7 cc/cc1. That is, the C above, I can cross compile easily enough -- to assembly at least. Linking and running are more difficult, but building a cross gcc that only produces assembly is quite easy -- our cm3cg is like that. Later. Personally I find it ridiculous that there so many variables here. Things are much better on Windows. There is usually only one calling convention per architecture, and where there are multiple, one compiler can produce any of them, the calling convention is encoded in the function name, and any "type" can call any "type". Perhaps we should entertain the idea of "native configuration". What if we cross compile cm3 using C, and then in m3-sys/m3cc/src/m3makefile on the rpi, you remove all the switches, even -target, and let it configure native? What does config.guess report? Can you build a native FSF gcc 4.7? Can you give me ssh access? - Jay > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] more cm3cg on Raspberry Pi > Date: Tue, 22 Oct 2013 09:47:01 -0700 > From: mika at async.caltech.edu > > > One more thing ... > > from > > https://wiki.debian.org/ArmHardFloatPort/VfpComparison > > "The combination of -mfpu=vfp and -mfloat-abi=hard is not available in FSF GCC 4.4, but the CodeSourcery 2009q1 compiler (and later, current release is 2010q1) supports it as does FSF GCC 4.5." > > but the way cm3cg is compiled it says: > > root at raspberrypi:/big/home/mika# /usr/local/cm3/bin/cm3cg -version > Modula-3 backend (GCC) version 4.7.1 (armv6l-unknown-linux-gnueabihf) > compiled by GNU C version 4.6.3, GGC heuristics: --param ggc-min-expand=59 --param ggc-min-heapsize=56092 > Modula-3 backend (GCC) version 4.7.1 (armv6l-unknown-linux-gnueabihf) > compiled by GNU C version 4.6.3, GGC heuristics: --param ggc-min-expand=59 --param ggc-min-heapsize=56092 > options passed: > > Hmm... so it should support the combination? But: > > root at raspberrypi:/big/home/mika# /usr/local/cm3/bin/cm3cg -mfpu=vfp -mfloat-abi=hard > cm3cg: sorry, unimplemented: -mfloat-abi=hard and VFP > > Execution times (seconds) > TOTAL : 0.00 0.00 0.02 0 kB > > Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From cornstalk at columbus.rr.com Tue Oct 22 22:36:46 2013 From: cornstalk at columbus.rr.com (Mark Morss) Date: Tue, 22 Oct 2013 16:36:46 -0400 Subject: [M3devel] Unsubscribe? Message-ID: <5266E1DE.6010508@columbus.rr.com> This list never seems to send out any unsubscribe opportunities. Sorry to bother everyone, but I would like to be unsubscribed. From wagner at elegosoft.com Wed Oct 23 08:56:53 2013 From: wagner at elegosoft.com (Olaf Wagner) Date: Wed, 23 Oct 2013 08:56:53 +0200 Subject: [M3devel] Unsubscribe? In-Reply-To: <5266E1DE.6010508@columbus.rr.com> References: <5266E1DE.6010508@columbus.rr.com> Message-ID: <20131023085653.0948e8a0cd2b9c2a7979ef67@elegosoft.com> On Tue, 22 Oct 2013 16:36:46 -0400 Mark Morss wrote: > This list never seems to send out any unsubscribe opportunities. Sorry > to bother everyone, but I would like to be unsubscribed. I've removed you from the list m3-devel. Olaf -- Olaf Wagner -- elego Software Solutions GmbH -- http://www.elegosoft.com 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 Gesch?ftsf?hrer: Michael Diers, Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 From dragisha at m3w.org Wed Oct 23 20:23:38 2013 From: dragisha at m3w.org (=?utf-8?Q?Dragi=C5=A1a_Duri=C4=87?=) Date: Wed, 23 Oct 2013 20:23:38 +0200 Subject: [M3devel] m3dl/DL.i3 In-Reply-To: References: , <20131015185250.ECFCA1A2091@async.async.caltech.edu> Message-ID: <7A1B4004-3445-47F9-8D20-9384B9581194@m3w.org> I have DL working for Linux, Darwin and Windows? since forever? Obviously I forgot to check it in :). As my plan is to make planned switch to Git in next weeks, if not days, I'll first do it before any checkins. If anybody has need for mentioned code, please let me know and I will post it somewhere. dd -- Dragi?a Duri? dragisha at m3w.org On Oct 22, 2013, at 5:39 PM, Jay K wrote: > This is wrong for Darwin and partly wrong for NetBSD. > It is correct for Solaris. > I haven't checked OpenBSD and FreeBSD yet. > > > Please look at how m3-libs/m3core/src/unix is structured for a more portable approach. > > > Plus this can be #ifdefed to Windows fairly easily, ignoring the flags. > dlopen => LoadLibrary (LoadLibraryA I guess) > dlsym => GetProcAddress > dlclose => FreeLibrary > > > And please consider a BSD license. > > > - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From jay.krell at cornell.edu Wed Oct 23 17:35:37 2013 From: jay.krell at cornell.edu (Jay) Date: Wed, 23 Oct 2013 08:35:37 -0700 Subject: [M3devel] more cm3cg on Raspberry Pi In-Reply-To: <20131022164701.3A9E21A208E@async.async.caltech.edu> References: <20131019012602.C96441A208E@async.async.caltech.edu> <20131022013433.A39161A208E@async.async.caltech.edu>

<20131022164701.3A9E21A208E@async.async.caltech.edu> Message-ID: <4FBD4CBA-6AF2-4323-99A2-F0F9B285BD86@gmail.com> Let's maybe backup and build a working gcc? And, "apt get source" on the rpi and compare to stock FSF gcc 4.7.x? And/or give me ssh access? I haven't compared cm3cg with C wrt performance. - Jay On Oct 22, 2013, at 9:47 AM, wrote: > > One more thing ... > > from > > https://wiki.debian.org/ArmHardFloatPort/VfpComparison > > "The combination of -mfpu=vfp and -mfloat-abi=hard is not available in FSF GCC 4.4, but the CodeSourcery 2009q1 compiler (and later, current release is 2010q1) supports it as does FSF GCC 4.5." > > but the way cm3cg is compiled it says: > > root at raspberrypi:/big/home/mika# /usr/local/cm3/bin/cm3cg -version > Modula-3 backend (GCC) version 4.7.1 (armv6l-unknown-linux-gnueabihf) > compiled by GNU C version 4.6.3, GGC heuristics: --param ggc-min-expand=59 --param ggc-min-heapsize=56092 > Modula-3 backend (GCC) version 4.7.1 (armv6l-unknown-linux-gnueabihf) > compiled by GNU C version 4.6.3, GGC heuristics: --param ggc-min-expand=59 --param ggc-min-heapsize=56092 > options passed: > > Hmm... so it should support the combination? But: > > root at raspberrypi:/big/home/mika# /usr/local/cm3/bin/cm3cg -mfpu=vfp -mfloat-abi=hard > cm3cg: sorry, unimplemented: -mfloat-abi=hard and VFP > > Execution times (seconds) > TOTAL : 0.00 0.00 0.02 0 kB > > Mika From jay.krell at cornell.edu Thu Oct 24 09:45:59 2013 From: jay.krell at cornell.edu (Jay K) Date: Thu, 24 Oct 2013 07:45:59 +0000 Subject: [M3devel] more cm3cg on Raspberry Pi In-Reply-To: <4FBD4CBA-6AF2-4323-99A2-F0F9B285BD86@gmail.com> References: <20131019012602.C96441A208E@async.async.caltech.edu>, , <20131022013433.A39161A208E@async.async.caltech.edu>, , , , <20131022164701.3A9E21A208E@async.async.caltech.edu>, <4FBD4CBA-6AF2-4323-99A2-F0F9B285BD86@gmail.com> Message-ID: Stock FSF gcc 4.7.0 does not appear to have armhf support. Maybe 4.7.3 or 4.8 or 4.9. Debian patches gcc extensively, though mostly in irrelevant ways. ?And Apple patches gcc, also mostly irrelevantly. ? ?And Interix has patches for gcc, also mostly irrelevant. ? ?And OpenBSD maintains gcc patches, also mostly irrelevant. ?? ?But these do contribute to me not liking the cm3cg backend.? ?cc is the interface to the patched/supported compiler. Alas.? ?With some random hacking on it, I get to:? pi at raspberrypi ~/cm3-boot-ARM_LINUX-d5.9.0-20131024 $ ./cm3 Fatal Error: unable to locate configuration file, "cm3.cfg" pi at raspberrypi ~/cm3-boot-ARM_LINUX-d5.9.0-20131024 $ file cm3 cm3: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, BuildID[sha1]=0x94ee12b113014741789e53db9c9ae8c0a0b24461, not stripped Which is what is expected at that point. Is that progress or you had already done that? Can you ? - free up some space maybe? ? - apt-get install cvs maybe? I guess I should learn to use rsync and/or scp in some sort of sync mode. Thanks, ?- Jay ---------------------------------------- > From: jay.krell at cornell.edu > Date: Wed, 23 Oct 2013 08:35:37 -0700 > To: mika at async.caltech.edu > CC: m3devel at elegosoft.com; jay.krell at cornell.edu > Subject: Re: [M3devel] more cm3cg on Raspberry Pi > > Let's maybe backup and build a working gcc? And, "apt get source" on the rpi and compare to stock FSF gcc 4.7.x? And/or give me ssh access? > > I haven't compared cm3cg with C wrt performance. > > - Jay > > On Oct 22, 2013, at 9:47 AM, wrote: > >> >> One more thing ... >> >> from >> >> https://wiki.debian.org/ArmHardFloatPort/VfpComparison >> >> "The combination of -mfpu=vfp and -mfloat-abi=hard is not available in FSF GCC 4.4, but the CodeSourcery 2009q1 compiler (and later, current release is 2010q1) supports it as does FSF GCC 4.5." >> >> but the way cm3cg is compiled it says: >> >> root at raspberrypi:/big/home/mika# /usr/local/cm3/bin/cm3cg -version >> Modula-3 backend (GCC) version 4.7.1 (armv6l-unknown-linux-gnueabihf) >> compiled by GNU C version 4.6.3, GGC heuristics: --param ggc-min-expand=59 --param ggc-min-heapsize=56092 >> Modula-3 backend (GCC) version 4.7.1 (armv6l-unknown-linux-gnueabihf) >> compiled by GNU C version 4.6.3, GGC heuristics: --param ggc-min-expand=59 --param ggc-min-heapsize=56092 >> options passed: >> >> Hmm... so it should support the combination? But: >> >> root at raspberrypi:/big/home/mika# /usr/local/cm3/bin/cm3cg -mfpu=vfp -mfloat-abi=hard >> cm3cg: sorry, unimplemented: -mfloat-abi=hard and VFP >> >> Execution times (seconds) >> TOTAL : 0.00 0.00 0.02 0 kB >> >> Mika From rodney_bates at lcwb.coop Tue Oct 1 02:22:20 2013 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Mon, 30 Sep 2013 19:22:20 -0500 Subject: [M3devel] caltech-parser test build error In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF369BD@ATLEX04-SRV.SCIRES.LOCAL> References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF369BD@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: <524A15BC.30007@lcwb.coop> On 09/29/2013 04:44 PM, Coleburn, Randy wrote: > I'm getting a build error for "caltech-parser\parserlib\parserlib\test". (See below.) > I'm not real familiar with this package, but the problem seems to be a path problem in invoking "ktok.exe". > > In the output below, the path being requested is: > C:\cm3\caltech-parser\parserlib\ktok\NT386\ktok.exe > > I think this path should instead be: > C:\cm3\*Sandbox\cm3\*caltech-parser\parserlib\ktok\NT386\ktok.exe > > Or, alternately, if one wanted the "ktok.exe" in "bin", the path should be: > C:\cm3\bin\ktok.exe > > The choice of path seems to be coming from a template file, but it isn't dealing properly with the location of the source tree (which could be rooted anywhere desired; mine is rooted at C:\cm3\Sandbox\cm3). > > Does anyone know if this package builds properly on other systems? If so, perhaps the template needs adjusting for NT386. Otherwise, there is a problem common to all platforms that should be repaired. > About 6 months ago, I tried rebuilding everything in the head, using the release compiler, on AMD64_LINUX and LINUXLIBC6. Just today, I did the same, using the head compiler on the head. I finished up with do-cm3-all.sh. Only a few things failed to build, and caltech-parser succeeded in all cases. It's a bit confusing to check everything that happened and what the state of my copy of pkginfo.txt ended up, but caltech-parser has its own scripts, so I have the notes that it built. BTW, the do-cm3-*.sh scripts used to stop when a package failed to build. Now I sometimes see them continuing to try more packages. Anyone know what the criterion is here? > Here is the output of my attempt to build this package: > > C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test\src>cm3 > --- building in ..\NT386 --- > > ignoring ..\src\m3overrides > > C:\cm3\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 > C:\cm3\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 > The system cannot find the path specified. > "C:\cm3\pkg\cit_util\src\generics.tmpl", line 38: quake runtime error: exit 1: C:\cm3\caltech-parser\parserlib\ktok\NT386\ktok ..\src\Calc.t -o CalcTok.i3 > > --procedure-- -line- -file--- > exec -- > _exec 38 C:\cm3\pkg\cit_util\src\generics.tmpl > _xCons 37 C:\cm3\pkg\parserlib\src\parser.tmpl > _tCons 70 C:\cm3\pkg\parserlib\src\parser.tmpl > _tConsUn 71 C:\cm3\pkg\parserlib\src\parser.tmpl > token 73 C:\cm3\pkg\parserlib\src\parser.tmpl > include_dir 4 C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test\src\m3makefile > 4 C:\cm3\Sandbox\cm3\caltech-parser\parserlib\parserlib\test\NT386\m3make.args > > Fatal Error: package build failed > > Thanks, > Randy Coleburn > From dabenavidesd at yahoo.es Tue Oct 1 03:33:40 2013 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Tue, 1 Oct 2013 02:33:40 +0100 (BST) Subject: [M3devel] Modula-3 Language Specification TR Message-ID: <1380591220.20365.YahooMailNeo@web171901.mail.ir2.yahoo.com> Hi all: I was browsing and suddenly saw a document reference I didn't know existed cited as this text below: "[Cardelli et al. 1987] L. Cardelli, J. Donahue, and G Nelson. The Modula 3 Type System. Draft Technical Report DEC SRC, October 1987. Appendix to Draft Modula 3 Language Specification." from: http://www.emeraldprogramminglanguage.org/nil.pdf Maybe somebody with high profile (not me )? for HP could ask them if we may have a working copy of it. The other way around would be writing the original authors of the document about it. Any volunteer? It would be a great technical document for my dreamed theoretical Modula-3 web page. Thanks in advance -------------- next part -------------- An HTML attachment was scrubbed... URL: From hosking at cs.purdue.edu Tue Oct 1 04:36:05 2013 From: hosking at cs.purdue.edu (Tony Hosking) Date: Mon, 30 Sep 2013 22:36:05 -0400 Subject: [M3devel] Modula-3 Language Specification TR In-Reply-To: <1380591220.20365.YahooMailNeo@web171901.mail.ir2.yahoo.com> References: <1380591220.20365.YahooMailNeo@web171901.mail.ir2.yahoo.com> Message-ID: <0C7CA448-EE75-4AC7-8C19-DB55B1915DA2@cs.purdue.edu> http://dx.doi.org/10.1145/75277.75295 On Sep 30, 2013, at 9:33 PM, "Daniel Alejandro Benavides D." wrote: > Hi all: > I was browsing and suddenly saw a document reference I didn't know existed cited as this text below: > "[Cardelli et al. 1987] L. Cardelli, J. Donahue, and G Nelson. The Modula 3 Type System. Draft Technical Report DEC SRC, October 1987. Appendix to Draft Modula 3 Language Specification." > from: > http://www.emeraldprogramminglanguage.org/nil.pdf > > Maybe somebody with high profile (not me ) for HP could ask them if we may have a working copy of it. The other way around would be writing the original authors of the document about it. Any volunteer? > > It would be a great technical document for my dreamed theoretical Modula-3 web page. > > Thanks in advance Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Mobile +1 765 427 5484 From jay.krell at cornell.edu Tue Oct 1 15:44:04 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 1 Oct 2013 13:44:04 +0000 Subject: [M3devel] AMD64_NT failing on null def to RTAllocator__GetTracedObj In-Reply-To: References: , Message-ID: It works now. I didn't really change anything. I'm guessing it was the ScanTypes thing in m3front/src/misc/CG.m3. I would encourage anyone at this time to try AMD64_NT. But I haven't uploaded a distribution yet, sorry. Cross building is required a short time longer. I mildly encourage that. It could use testing/feedback from other than me. There is a boot archive: https://modula3.elegosoft.com/cm3/uploaded-archives/cm3-boot-AMD64_NT-d5.9.0-20130921.zip - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Sun, 22 Sep 2013 09:53:54 +0000 Subject: Re: [M3devel] AMD64_NT failing on null def to RTAllocator__GetTracedObj hm. indeed. darwin @M3tracelinker shows a few PathnamePosix but nt never shows PathnameWin32. - Jay From: jay.krell at cornell.edu To: m3devel at elegosoft.com Date: Sun, 22 Sep 2013 09:10:02 +0000 Subject: [M3devel] AMD64_NT failing on null def to RTAllocator__GetTracedObj darn, AMD4_NT isn't working any longer. It gets here: 0:000> k Child-SP RetAddr Call Site 00000000`002bee90 00000001`3fac0f1f cm3!RTAllocator__GetTracedObj+0x91 [c:\dev2\src\runtime\common\rtallocator.m3 @ 221] 00000000`002bef10 00000001`3fa3fe96 cm3!RTHooks__AllocateTracedObj+0x2f [c:\dev2\src\runtime\common\rtallocator.m3 @ 123] 00000000`002bef60 00000001`3fa3f774 cm3!Pathname__Decompose+0x86 [c:\dev2\src\os\win32\pathnamewin32.m3 @ 40] 00000000`002beff0 00000001`3fa3f55f cm3!PathRepr__Root+0xb4 [c:\dev2\src\pathreprcommon.m3 @ 38] 00000000`002bf1c0 00000001`3fae37fc cm3!PathReprCommon_M3+0xcf [c:\dev2\src\pathreprcommon.m3 @ 46] 00000000`002bf380 00000001`3fae3653 cm3!RTLinker__RunMainBody+0x46c [c:\dev2\src\runtime\common\rtlinker.m3 @ 409] 0:000> dv /V 00000000`002bef10 @rsp+0x0080 def_L_96 = 0x00000000`00000000 ... 0:000> u . -10 cm3!RTAllocator__GetTracedObj+0x81 [c:\dev2\src\runtime\common\rtallocator.m3 @217]: ... 00000001`3fac23b9 488b842480000000 mov rax,qword ptr [rsp+80h] 00000001`3fac23c1 488b08 mov rcx,qword ptr [rax] 0:000> u . l1 cm3!RTAllocator__GetTracedObj+0x91 [c:\dev2\src\runtime\common\rtallocator.m3 @ 221]: 00000001`3fac23c1 488b08 mov rcx,qword ptr [rax] 0:000> r rax rax=0000000000000000 def is NULL. It comes from here: Pathname__Decompose: ... RTHooks__AllocateTracedObj( (((ADDRESS)(*((ADDRESS*)(INT64_(192)+((ADDRESS)(&M_PathnameWin32_L_33)))))))); M_PathnameWin32_L_33 + 192 is NULL. "_L_33" is an annoying uniquifier from the C backend, sprinkled on far more than needed. global data allocation for M_PathnameWin32 ... 192 16 8 typecell ptr Is that supposed to be statically initialized or filled in by RTLinker? It noticably is not in the constants, but the writables. Help? Debug RTLinker? - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Tue Oct 1 16:35:19 2013 From: jay.krell at cornell.edu (Jay K) Date: Tue, 1 Oct 2013 14:35:19 +0000 Subject: [M3devel] first AMD64_NT release Message-ID: first AMD64_NT release http://modula3.elegosoft.com/cm3/uploaded-archives/ http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-AMD64_NT-d5.9.0-VC110-20131001.tar.gz http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-all-AMD64_NT-d5.9.0-VC110-20131001.tar.gz Folks please try it out? I forgot..there is likely a bug on Windows 7 w/o SP1. I can fix it, but I don't have such a machine currently. But Windows XP/amd64, Windows 7/SP1/amd64, Windows 8/amd64, Windows 8.1/amd64 are all likely good. I only tested Windows 7/SP1. Thank you, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at SCIRES.COM Tue Oct 1 18:14:58 2013 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Tue, 1 Oct 2013 16:14:58 +0000 Subject: [M3devel] first AMD64_NT release Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF3934F@ATLEX04-SRV.SCIRES.LOCAL> Will this work on Intel 64-bit Win7, or just AMD? I have a couple of Win7 machines, but none are AMD. The one I using right now is Intel Core i5-2430 w/8GB RAM. --Randy From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Tuesday, October 01, 2013 10:35 AM To: m3devel Subject: EXT:[M3devel] first AMD64_NT release first AMD64_NT release http://modula3.elegosoft.com/cm3/uploaded-archives/ http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-AMD64_NT-d5.9.0-VC110-20131001.tar.gz http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-all-AMD64_NT-d5.9.0-VC110-20131001.tar.gz Folks please try it out? I forgot..there is likely a bug on Windows 7 w/o SP1. I can fix it, but I don't have such a machine currently. But Windows XP/amd64, Windows 7/SP1/amd64, Windows 8/amd64, Windows 8.1/amd64 are all likely good. I only tested Windows 7/SP1. Thank you, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From danielal.benavides at bancoagrario.gov.co Tue Oct 1 19:54:43 2013 From: danielal.benavides at bancoagrario.gov.co (Daniel Alejandro Benavides Diaz) Date: Tue, 1 Oct 2013 17:54:43 +0000 Subject: [M3devel] Modula-3 Language Specification TR In-Reply-To: <0C7CA448-EE75-4AC7-8C19-DB55B1915DA2@cs.purdue.edu> References: <1380591220.20365.YahooMailNeo@web171901.mail.ir2.yahoo.com> <0C7CA448-EE75-4AC7-8C19-DB55B1915DA2@cs.purdue.edu> Message-ID: <1AF4998819C60A40A4CD8C3B6582D3DA3F10FF77@DRG008W8SMBX014.bancoagrario.gov.co> Hi all: If that's the same document, I'm just curious, for my private collection. Cardelli stated in not so old interview that the most difficult part of the language definition was the type system, so much complicated that they produced that paper. So it might not be the same easy to read paper, perhaps. Thanks in advance -----Mensaje original----- De: Tony Hosking [mailto:hosking at cs.purdue.edu] Enviado el: Monday, 30 de September de 2013 9:36 p.m. Para: Daniel Alejandro Benavides D. CC: m3devel at elegosoft.com Asunto: Re: [M3devel] Modula-3 Language Specification TR http://dx.doi.org/10.1145/75277.75295 On Sep 30, 2013, at 9:33 PM, "Daniel Alejandro Benavides D." wrote: > Hi all: > I was browsing and suddenly saw a document reference I didn't know existed cited as this text below: > "[Cardelli et al. 1987] L. Cardelli, J. Donahue, and G Nelson. The Modula 3 Type System. Draft Technical Report DEC SRC, October 1987. Appendix to Draft Modula 3 Language Specification." > from: > http://www.emeraldprogramminglanguage.org/nil.pdf > > Maybe somebody with high profile (not me ) for HP could ask them if we may have a working copy of it. The other way around would be writing the original authors of the document about it. Any volunteer? > > It would be a great technical document for my dreamed theoretical Modula-3 web page. > > Thanks in advance Antony Hosking | Associate Professor | Computer Science | Purdue University 305 N. University Street | West Lafayette | IN 47907 | USA Mobile +1 765 427 5484 From jay.krell at cornell.edu Wed Oct 2 05:46:11 2013 From: jay.krell at cornell.edu (Jay K) Date: Wed, 2 Oct 2013 03:46:11 +0000 Subject: [M3devel] first AMD64_NT release In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF3934F@ATLEX04-SRV.SCIRES.LOCAL> References: <0BB8FA59C2932741A3A2941A8B9D8BFF5CF3934F@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: Yes it it will work. %PROCESSOR_ARCHITECTURE% is AMD64. That is the name of the architecture. Intel and AMD are roughly the same and there is nothing specific to either one here. Similarly we have AMD64_DARWIN, AMD64_LINUX, etc. If you haven't updated to SP1, I have an experiment for you to try and report the results of. Thank you, - Jay From: rcolebur at SCIRES.COM To: m3devel at elegosoft.com Date: Tue, 1 Oct 2013 16:14:58 +0000 Subject: Re: [M3devel] first AMD64_NT release Will this work on Intel 64-bit Win7, or just AMD? I have a couple of Win7 machines, but none are AMD. The one I using right now is Intel Core i5-2430 w/8GB RAM. --Randy From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Tuesday, October 01, 2013 10:35 AM To: m3devel Subject: EXT:[M3devel] first AMD64_NT release first AMD64_NT release http://modula3.elegosoft.com/cm3/uploaded-archives/ http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-AMD64_NT-d5.9.0-VC110-20131001.tar.gz http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-all-AMD64_NT-d5.9.0-VC110-20131001.tar.gz Folks please try it out? I forgot..there is likely a bug on Windows 7 w/o SP1. I can fix it, but I don't have such a machine currently. But Windows XP/amd64, Windows 7/SP1/amd64, Windows 8/amd64, Windows 8.1/amd64 are all likely good. I only tested Windows 7/SP1. Thank you, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcolebur at SCIRES.COM Wed Oct 2 17:11:31 2013 From: rcolebur at SCIRES.COM (Coleburn, Randy) Date: Wed, 2 Oct 2013 15:11:31 +0000 Subject: [M3devel] first AMD64_NT release Message-ID: <0BB8FA59C2932741A3A2941A8B9D8BFF92451C60@ATLEX04-SRV.SCIRES.LOCAL> Jay: Thanks. Sorry, but I am using SP1. --Randy From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Tuesday, October 01, 2013 11:46 PM To: Coleburn, Randy; m3devel Subject: EXT:RE: [M3devel] first AMD64_NT release Yes it it will work. %PROCESSOR_ARCHITECTURE% is AMD64. That is the name of the architecture. Intel and AMD are roughly the same and there is nothing specific to either one here. Similarly we have AMD64_DARWIN, AMD64_LINUX, etc. If you haven't updated to SP1, I have an experiment for you to try and report the results of. Thank you, - Jay ________________________________ From: rcolebur at SCIRES.COM To: m3devel at elegosoft.com Date: Tue, 1 Oct 2013 16:14:58 +0000 Subject: Re: [M3devel] first AMD64_NT release Will this work on Intel 64-bit Win7, or just AMD? I have a couple of Win7 machines, but none are AMD. The one I using right now is Intel Core i5-2430 w/8GB RAM. --Randy From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K Sent: Tuesday, October 01, 2013 10:35 AM To: m3devel Subject: EXT:[M3devel] first AMD64_NT release first AMD64_NT release http://modula3.elegosoft.com/cm3/uploaded-archives/ http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-AMD64_NT-d5.9.0-VC110-20131001.tar.gz http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-all-AMD64_NT-d5.9.0-VC110-20131001.tar.gz Folks please try it out? I forgot..there is likely a bug on Windows 7 w/o SP1. I can fix it, but I don't have such a machine currently. But Windows XP/amd64, Windows 7/SP1/amd64, Windows 8/amd64, Windows 8.1/amd64 are all likely good. I only tested Windows 7/SP1. Thank you, - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Sun Oct 13 01:11:43 2013 From: jay.krell at cornell.edu (Jay K) Date: Sat, 12 Oct 2013 23:11:43 +0000 Subject: [M3devel] first AMD64_NT release In-Reply-To: <0BB8FA59C2932741A3A2941A8B9D8BFF92451C60@ATLEX04-SRV.SCIRES.LOCAL> References: <0BB8FA59C2932741A3A2941A8B9D8BFF92451C60@ATLEX04-SRV.SCIRES.LOCAL> Message-ID: There are now .zips and .msis here: ? https://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-AMD64_NT-d5.9.0-VC110-20131012.msi ? ? https://modula3.elegosoft.com/cm3/uploaded-archives/cm3-all-AMD64_NT-d5.9.0-VC110-20131012.msi ? ? https://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-AMD64_NT-d5.9.0-VC110-20131012.zip ? ? https://modula3.elegosoft.com/cm3/uploaded-archives/cm3-all-AMD64_NT-d5.9.0-VC110-20131012.zip ? ?Folks please try it out??? ? Thanks, ? ? ?- Jay ? ________________________________ > From: rcolebur at SCIRES.COM > To: m3devel at elegosoft.com > Date: Wed, 2 Oct 2013 15:11:31 +0000 > Subject: Re: [M3devel] first AMD64_NT release > > > Jay: > > > > Thanks. > > > > Sorry, but I am using SP1. > > > > --Randy > > > > From: jayk123 at hotmail.com [mailto:jayk123 at hotmail.com] On Behalf Of Jay K > Sent: Tuesday, October 01, 2013 11:46 PM > To: Coleburn, Randy; m3devel > Subject: EXT:RE: [M3devel] first AMD64_NT release > > > > Yes it it will work. > %PROCESSOR_ARCHITECTURE% is AMD64. That is the name of the > architecture. Intel and AMD are roughly the same and there is nothing > specific to either one here. Similarly we have AMD64_DARWIN, > AMD64_LINUX, etc. > If you haven't updated to SP1, I have an experiment for you to try and > report the results of. > > Thank you, > - Jay > > > > ________________________________ > > From: rcolebur at SCIRES.COM > To: m3devel at elegosoft.com > Date: Tue, 1 Oct 2013 16:14:58 +0000 > Subject: Re: [M3devel] first AMD64_NT release > > Will this work on Intel 64-bit Win7, or just AMD? > > > > I have a couple of Win7 machines, but none are AMD. > > > > The one I using right now is Intel Core i5-2430 w/8GB RAM. > > > > --Randy > > > > From: jayk123 at hotmail.com > [mailto:jayk123 at hotmail.com] On Behalf Of Jay K > Sent: Tuesday, October 01, 2013 10:35 AM > To: m3devel > Subject: EXT:[M3devel] first AMD64_NT release > > > > first AMD64_NT release > > > http://modula3.elegosoft.com/cm3/uploaded-archives/ > > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-min-AMD64_NT-d5.9.0-VC110-20131001.tar.gz > http://modula3.elegosoft.com/cm3/uploaded-archives/cm3-all-AMD64_NT-d5.9.0-VC110-20131001.tar.gz > > > > Folks please try it out? > > > > I forgot..there is likely a bug on Windows 7 w/o SP1. I can fix it, but > I don't have such a machine currently. > But Windows XP/amd64, Windows 7/SP1/amd64, Windows 8/amd64, Windows > 8.1/amd64 are all likely good. > I only tested Windows 7/SP1. > > > Thank you, > - Jay From mika at async.caltech.edu Sun Oct 13 22:35:01 2013 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Sun, 13 Oct 2013 13:35:01 -0700 Subject: [M3devel] building CM3 on a Raspberry Pi? Message-ID: <20131013203501.35E651A208F@async.async.caltech.edu> Hi everyone (mostly Jay), Last time I tried to port CM3 to a new architecture I really got nowhere. I thought it might be time to try again. I have a Raspberry Pi, forty-dollar computer. It has "Raspbian" installed on it. The following output is probably relevant: pi at raspberrypi ~ $ uname -a Linux raspberrypi 3.6.11+ #538 PREEMPT Fri Aug 30 20:42:08 BST 2013 armv6l GNU/Linux pi at raspberrypi ~ $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/4.6/lto-wrapper Target: arm-linux-gnueabihf Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.3-14+rpi1' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --disable-sjlj-exceptions --with-arch=armv6 --with-fpu=vfp --with-float=hard --enable-checking=release --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf Thread model: posix gcc version 4.6.3 (Debian 4.6.3-14+rpi1) Further, in the CM3 tree there is something called "ARMEL_LINUX". I thought, from reading some old messages on this mailing list, that doing the following on my "big" system would result in something interesting: 1. CVS updating to the latest version of the tree 2. cd to scripts/python 3. ./boot1.py ARMEL_LINUX but all it did was mess up the cm3.cfg on my host system (FreeBSD4) and error out very quickly... ... rm -f /usr/local/cm3/bin/IA64_LINUX rm -f /usr/local/cm3/bin/NT.common rm -f /usr/local/cm3/bin/SPARC32_SOLARIS.common cp -Pv /big/home2/mika/2/cm3-cvs/cm3/m3-sys/cminstall/src/config-no-install/cm3.cfg /usr/local/cm3/bin/cm3.cfg == package /big/home2/mika/2/cm3-cvs/cm3/m3-win/import-libs == +++ /usr/local/cm3/bin/cm3 -build -override -DROOT=/big/home2/mika/2/cm3-cvs/cm3 -boot -keep -DM3CC_TARGET=ARMEL_LINUX +++ --- building in ARMEL_LINUX --- ==> /big/home2/mika/2/cm3-cvs/cm3/m3-win/import-libs done == package /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc == +++ /usr/local/cm3/bin/cm3 -build -override -DROOT=/big/home2/mika/2/cm3-cvs/cm3 -boot -keep -DM3CC_TARGET=ARMEL_LINUX +++ --- building in ARMEL_LINUX --- type make make is /home/mika/cm3-build-bin//make make --version | grep "GNU Make" GNU Make 3.82 GNU_MAKE is make cd ../FreeBSD4-ARMEL_LINUX && MAKE="make -j4 " AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: ../gcc-4.7/configure -with-sysroot -target=arm-linux-gnueabi -srcdir=../gcc-4.7 -disable-bootstrap -disable-intl -disable-libgomp -disable-libmudflap -disable-libssp -disable-nls -enable-languages=m3cg -disable-fixincludes -disable-libgcc -disable-decimal-float -disable-fixed-point -disable-tls cd ../FreeBSD4-ARMEL_LINUX && MAKE="make -j4 " AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: ../gcc-4.7/configure -with-sysroot -target=arm-linux-gnueabi -srcdir=../gcc-4.7 -disable-bootstrap -disable-intl -disable-libgomp -disable-libmudflap -disable-libssp -disable-nls -enable-languages=m3cg -disable-fixincludes -disable-libgcc -disable-decimal-float -disable-fixed-point -disable-tls ../gcc-4.7/configure: not found "/big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/m3makefile", line 339: quake runtime error: exit 127: cd ../FreeBSD4-ARMEL_LINUX && MAKE="make -j4 " AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: ../gcc-4.7/configure -with-sysroot -target=arm-linux-gnueabi -srcdir=../gcc-4.7 -disable-bootstrap -disable-intl -disable-libgomp -disable-libmudflap -disable-libssp -disable-nls -enable-languages=m3cg -disable-fixincludes -disable-libgcc -disable-decimal-float -disable-fixed-point -disable-tls --procedure-- -line- -file--- exec -- m3cc_Run 339 /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/m3makefile include_dir 537 /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/m3makefile 9 /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/ARMEL_LINUX/m3make.args Fatal Error: package build failed *** execution of [] failed *** (238)rover:~/cm3-cvs-anon/cm3/scripts/python> So I'm not really sure what state porting of CM3 is in. I think it would be really interesting to have it running on the Raspberry Pi, partly because Modula-3 and Python are in many ways similar but Modula-3 code tends to be many times more efficient (at least in runtime) and the computer is slow by modern standards. A few questions... Is ARMEL_LINUX a real port? Does it work? Has it worked for anyone? Am I going about it the right way per latest recommendations---that is, trying to cross-compile from an existing CM3 installation on 32-bit i386 system? Clearly just running ./boot1.py ARMEL_LINUX on the FreeBSD system is not the right approach... maybe someone knows what is? Do I maybe need to upgrade the host CM3 to the head first? (Sounds like a whole other can of worms but ok...) The Pi I think is more than powerful enough to compile everything natively. When I started with Modula-3, I had a 120-MHz Pentium on my desk with 128 MB of RAM, and that was considered a powerful system at the time. This is a 700 MHz ARM with 512 MB of RAM. So I'm not against compiling stuff natively (in fact I think it makes things easier), but cross-compiling is fine too if that gets me to the goal easier. I am happy to try C generating compilers but I would prefer to keep things as un-experimental as possible for now, because I have some control applications I'd like to try to build without having to debug lots and lots of software first. Finally I think it would be *really* cool if we had a distribution of Modula-3 that was polished enough to be distributable to Raspberry Pi users. Just based on the gross characteristics of the two systems, I think the Pi and Modula-3 ought to be a very good match for each other. Basically, the Pi is a full-featured but slow hardware system with good networking facilities. It could use a safe, modern, efficient systems programming language running on it. Most things on it nowadays are written in Python from what i understand. Mika From jay.krell at cornell.edu Mon Oct 14 06:07:25 2013 From: jay.krell at cornell.edu (Jay K) Date: Mon, 14 Oct 2013 04:07:25 +0000 Subject: [M3devel] building CM3 on a Raspberry Pi? In-Reply-To: <20131013203501.35E651A208F@async.async.caltech.edu> References: <20131013203501.35E651A208F@async.async.caltech.edu> Message-ID: Porting to new systems is pretty easy. I had ARMEL_LINUX pretty far along. I forgot how far. I did have to add sort of support for 128bit integers in the gcc backend. Sort of. > ../gcc-4.7/configure: not found Make sure you cvs upd -dAP so you get new directories. We should switch to the C backend though. It is just a one line change in the config file. Look at the Darwin config files. It is not experimental. It has been essentially working for over a year (since September 2012) and it is in very good shape now. I have used it for a number of architectures and operating systems already, like I think every Solaris architecture, Linux, Darwin, NT. I'd like to see more people use it, and I'd like to drop the gcc backend entirely. This is an important step in leaving Modula-3 very portable and easier to support. - Jay > To: m3devel at elegosoft.com > Date: Sun, 13 Oct 2013 13:35:01 -0700 > From: mika at async.caltech.edu > Subject: [M3devel] building CM3 on a Raspberry Pi? > > > Hi everyone (mostly Jay), > > Last time I tried to port CM3 to a new architecture I really got nowhere. > > I thought it might be time to try again. I have a Raspberry Pi, forty-dollar computer. > > It has "Raspbian" installed on it. > > The following output is probably relevant: > > pi at raspberrypi ~ $ uname -a > Linux raspberrypi 3.6.11+ #538 PREEMPT Fri Aug 30 20:42:08 BST 2013 armv6l GNU/Linux > > pi at raspberrypi ~ $ gcc -v > Using built-in specs. > COLLECT_GCC=gcc > COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/4.6/lto-wrapper > Target: arm-linux-gnueabihf > Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.3-14+rpi1' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --disable-sjlj-exceptions --with-arch=armv6 --with-fpu=vfp --with-float=hard --enable-checking=release --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf > Thread model: posix > gcc version 4.6.3 (Debian 4.6.3-14+rpi1) > > > Further, in the CM3 tree there is something called "ARMEL_LINUX". > I thought, from reading some old messages on this mailing list, that doing > the following on my "big" system would result in something interesting: > > 1. CVS updating to the latest version of the tree > > 2. cd to scripts/python > > 3. ./boot1.py ARMEL_LINUX > > but all it did was mess up the cm3.cfg on my host system (FreeBSD4) and error out very quickly... > > ... > rm -f /usr/local/cm3/bin/IA64_LINUX > rm -f /usr/local/cm3/bin/NT.common > rm -f /usr/local/cm3/bin/SPARC32_SOLARIS.common > cp -Pv /big/home2/mika/2/cm3-cvs/cm3/m3-sys/cminstall/src/config-no-install/cm3.cfg /usr/local/cm3/bin/cm3.cfg > == package /big/home2/mika/2/cm3-cvs/cm3/m3-win/import-libs == > > +++ /usr/local/cm3/bin/cm3 -build -override -DROOT=/big/home2/mika/2/cm3-cvs/cm3 -boot -keep -DM3CC_TARGET=ARMEL_LINUX +++ > --- building in ARMEL_LINUX --- > > ==> /big/home2/mika/2/cm3-cvs/cm3/m3-win/import-libs done > > == package /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc == > > +++ /usr/local/cm3/bin/cm3 -build -override -DROOT=/big/home2/mika/2/cm3-cvs/cm3 -boot -keep -DM3CC_TARGET=ARMEL_LINUX +++ > --- building in ARMEL_LINUX --- > > type make > make is /home/mika/cm3-build-bin//make > make --version | grep "GNU Make" > GNU Make 3.82 > GNU_MAKE is make > cd ../FreeBSD4-ARMEL_LINUX && MAKE="make -j4 " AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: ../gcc-4.7/configure -with-sysroot -target=arm-linux-gnueabi -srcdir=../gcc-4.7 -disable-bootstrap -disable-intl -disable-libgomp -disable-libmudflap -disable-libssp -disable-nls -enable-languages=m3cg -disable-fixincludes -disable-libgcc -disable-decimal-float -disable-fixed-point -disable-tls > cd ../FreeBSD4-ARMEL_LINUX && MAKE="make -j4 " AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: ../gcc-4.7/configure -with-sysroot -target=arm-linux-gnueabi -srcdir=../gcc-4.7 -disable-bootstrap -disable-intl -disable-libgomp -disable-libmudflap -disable-libssp -disable-nls -enable-languages=m3cg -disable-fixincludes -disable-libgcc -disable-decimal-float -disable-fixed-point -disable-tls > ../gcc-4.7/configure: not found > "/big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/m3makefile", line 339: quake runtime error: exit 127: cd ../FreeBSD4-ARMEL_LINUX && MAKE="make -j4 " AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: ../gcc-4.7/configure -with-sysroot -target=arm-linux-gnueabi -srcdir=../gcc-4.7 -disable-bootstrap -disable-intl -disable-libgomp -disable-libmudflap -disable-libssp -disable-nls -enable-languages=m3cg -disable-fixincludes -disable-libgcc -disable-decimal-float -disable-fixed-point -disable-tls > > --procedure-- -line- -file--- > exec -- > m3cc_Run 339 /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/m3makefile > include_dir 537 /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/m3makefile > 9 /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/ARMEL_LINUX/m3make.args > > Fatal Error: package build failed > *** execution of [] failed *** > (238)rover:~/cm3-cvs-anon/cm3/scripts/python> > > > So I'm not really sure what state porting of CM3 is in. I think it > would be really interesting to have it running on the Raspberry Pi, > partly because Modula-3 and Python are in many ways similar but Modula-3 > code tends to be many times more efficient (at least in runtime) and > the computer is slow by modern standards. > > A few questions... > > Is ARMEL_LINUX a real port? Does it work? Has it worked for anyone? > > Am I going about it the right way per latest recommendations---that is, > trying to cross-compile from an existing CM3 installation on 32-bit > i386 system? > > Clearly just running ./boot1.py ARMEL_LINUX on the FreeBSD system is > not the right approach... maybe someone knows what is? > > Do I maybe need to upgrade the host CM3 to the head first? (Sounds > like a whole other can of worms but ok...) > > The Pi I think is more than powerful enough to compile everything > natively. When I started with Modula-3, I had a 120-MHz Pentium on > my desk with 128 MB of RAM, and that was considered a powerful > system at the time. This is a 700 MHz ARM with 512 MB of RAM. > So I'm not against compiling stuff natively (in fact I think it makes > things easier), but cross-compiling is fine too if that gets me to > the goal easier. > > I am happy to try C generating compilers but I would prefer to keep > things as un-experimental as possible for now, because I have some > control applications I'd like to try to build without having to debug > lots and lots of software first. > > Finally I think it would be *really* cool if we had a distribution of > Modula-3 that was polished enough to be distributable to Raspberry Pi > users. Just based on the gross characteristics of the two systems, > I think the Pi and Modula-3 ought to be a very good match for each > other. Basically, the Pi is a full-featured but slow hardware system > with good networking facilities. It could use a safe, modern, efficient > systems programming language running on it. Most things on it nowadays > are written in Python from what i understand. > > Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Mon Oct 14 17:15:16 2013 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Mon, 14 Oct 2013 08:15:16 -0700 Subject: [M3devel] building CM3 on a Raspberry Pi? In-Reply-To: References: <20131013203501.35E651A208F@async.async.caltech.edu> Message-ID: <20131014151516.2871B1A208E@async.async.caltech.edu> Jay you're right of course. I forgot the -d ... argh! I'm starting to get used to using other revision control systems than CVS, I think. But still, am I doing the right thing? It seems somehow wrong that the very first thing the build process does is blows away the cm3.cfg of my host compiler. Again all I'm doing is cding to scripts and running ./boot1.py ARMEL_LINUX I'm happy to try C generation if you think it's easier. Whatever works in the end... BTW, I checked the performance of the Pi and on the benchmarks I had it was quite a bit faster than the AlphaStation 4/266 my research group once paid $26,000 for. (Four times as much RAM, too.) I'm using a floating-point benchmark called flops20.c and compared to the systems on my list, it benchmarks closest to a single node of the HP/Convex Exemplar X-class CC-NUMA supercomputer. Mika Jay K writes: >--_dddec029-8cf2-4528-8c46-8d0a40bef349_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > Porting to new systems is pretty easy. =20 > I had ARMEL_LINUX pretty far along. =20 > I forgot how far. =20 > I did have to add sort of support for 128bit integers in the gcc backend.= > Sort of. =20 >=20 > > > ../gcc-4.7/configure: not found=20 > >=20 > Make sure you cvs upd -dAP so you get new directories.=20 > >=20 > We should switch to the C backend though. It is just a one line change =20 > in the config file. Look at the Darwin config files. =20 > It is not experimental. =20 > It has been essentially working for over a year (since September 2012)=20 > and it is in very good shape now.=20 > I have used it for a number of architectures and operating systems alread= >y=2C=20 > like I think every Solaris architecture=2C Linux=2C Darwin=2C NT.=20 > I'd like to see more people use it=2C and I'd like to drop the gcc backen= >d entirely.=20 > This is an important step in leaving Modula-3 very portable and easier to= > support.=20 >=20 > > - Jay > >=20 >> To: m3devel at elegosoft.com >> Date: Sun=2C 13 Oct 2013 13:35:01 -0700 >> From: mika at async.caltech.edu >> Subject: [M3devel] building CM3 on a Raspberry Pi? >>=20 >>=20 >> Hi everyone (mostly Jay)=2C >>=20 >> Last time I tried to port CM3 to a new architecture I really got nowhere. >>=20 >> I thought it might be time to try again. I have a Raspberry Pi=2C forty-= >dollar computer. >>=20 >> It has "Raspbian" installed on it. >>=20 >> The following output is probably relevant: >>=20 >> pi at raspberrypi ~ $ uname -a >> Linux raspberrypi 3.6.11+ #538 PREEMPT Fri Aug 30 20:42:08 BST 2013 armv6= >l GNU/Linux >>=20 >> pi at raspberrypi ~ $ gcc -v >> Using built-in specs. >> COLLECT_GCC=3Dgcc >> COLLECT_LTO_WRAPPER=3D/usr/lib/gcc/arm-linux-gnueabihf/4.6/lto-wrapper >> Target: arm-linux-gnueabihf >> Configured with: ../src/configure -v --with-pkgversion=3D'Debian 4.6.3-14= >+rpi1' --with-bugurl=3Dfile:///usr/share/doc/gcc-4.6/README.Bugs --enable-l= >anguages=3Dc=2Cc++=2Cfortran=2Cobjc=2Cobj-c++ --prefix=3D/usr --program-suf= >fix=3D-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --li= >bexecdir=3D/usr/lib --without-included-gettext --enable-threads=3Dposix --w= >ith-gxx-include-dir=3D/usr/include/c++/4.6 --libdir=3D/usr/lib --enable-nls= > --with-sysroot=3D/ --enable-clocale=3Dgnu --enable-libstdcxx-debug --enabl= >e-libstdcxx-time=3Dyes --enable-gnu-unique-object --enable-plugin --enable-= >objc-gc --disable-sjlj-exceptions --with-arch=3Darmv6 --with-fpu=3Dvfp --wi= >th-float=3Dhard --enable-checking=3Drelease --build=3Darm-linux-gnueabihf -= >-host=3Darm-linux-gnueabihf --target=3Darm-linux-gnueabihf >> Thread model: posix >> gcc version 4.6.3 (Debian 4.6.3-14+rpi1)=20 >>=20 >>=20 >> Further=2C in the CM3 tree there is something called "ARMEL_LINUX". >> I thought=2C from reading some old messages on this mailing list=2C that = >doing >> the following on my "big" system would result in something interesting: >>=20 >> 1. CVS updating to the latest version of the tree >>=20 >> 2. cd to scripts/python >>=20 >> 3. ./boot1.py ARMEL_LINUX >>=20 >> but all it did was mess up the cm3.cfg on my host system (FreeBSD4) and e= >rror out very quickly... >>=20 >> ... >> rm -f /usr/local/cm3/bin/IA64_LINUX >> rm -f /usr/local/cm3/bin/NT.common >> rm -f /usr/local/cm3/bin/SPARC32_SOLARIS.common >> cp -Pv /big/home2/mika/2/cm3-cvs/cm3/m3-sys/cminstall/src/config-no-insta= >ll/cm3.cfg /usr/local/cm3/bin/cm3.cfg >> =3D=3D package /big/home2/mika/2/cm3-cvs/cm3/m3-win/import-libs =3D=3D >>=20 >> +++ /usr/local/cm3/bin/cm3 -build -override -DROOT=3D/big/home2/mika/= >2/cm3-cvs/cm3 -boot -keep -DM3CC_TARGET=3DARMEL_LINUX +++ >> --- building in ARMEL_LINUX --- >>=20 >> =3D=3D> /big/home2/mika/2/cm3-cvs/cm3/m3-win/import-libs done >>=20 >> =3D=3D package /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc =3D=3D >>=20 >> +++ /usr/local/cm3/bin/cm3 -build -override -DROOT=3D/big/home2/mika/= >2/cm3-cvs/cm3 -boot -keep -DM3CC_TARGET=3DARMEL_LINUX +++ >> --- building in ARMEL_LINUX --- >>=20 >> type make >> make is /home/mika/cm3-build-bin//make >> make --version | grep "GNU Make" >> GNU Make 3.82 >> GNU_MAKE is make >> cd ../FreeBSD4-ARMEL_LINUX && MAKE=3D"make -j4 " AUTOCONF=3D: AUTOMAK= >E=3D: LEX=3D'touch lex.yy.c' MAKEINFO=3D: ../gcc-4.7/configure -with-sy= >sroot -target=3Darm-linux-gnueabi -srcdir=3D../gcc-4.7 -disable-bootstrap -= >disable-intl -disable-libgomp -disable-libmudflap -disable-libssp -disable-= >nls -enable-languages=3Dm3cg -disable-fixincludes -disable-libgcc -disable-= >decimal-float -disable-fixed-point -disable-tls >> cd ../FreeBSD4-ARMEL_LINUX && MAKE=3D"make -j4 " AUTOCONF=3D: AUTOMAK= >E=3D: LEX=3D'touch lex.yy.c' MAKEINFO=3D: ../gcc-4.7/configure -with-sy= >sroot -target=3Darm-linux-gnueabi -srcdir=3D../gcc-4.7 -disable-bootstrap -= >disable-intl -disable-libgomp -disable-libmudflap -disable-libssp -disable-= >nls -enable-languages=3Dm3cg -disable-fixincludes -disable-libgcc -disable-= >decimal-float -disable-fixed-point -disable-tls >> ../gcc-4.7/configure: not found >> "/big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/m3makefile"=2C line 339: q= >uake runtime error: exit 127: cd ../FreeBSD4-ARMEL_LINUX && MAKE=3D"make = >-j4 " AUTOCONF=3D: AUTOMAKE=3D: LEX=3D'touch lex.yy.c' MAKEINFO=3D: ../gc= >c-4.7/configure -with-sysroot -target=3Darm-linux-gnueabi -srcdir=3D../= >gcc-4.7 -disable-bootstrap -disable-intl -disable-libgomp -disable-libmudfl= >ap -disable-libssp -disable-nls -enable-languages=3Dm3cg -disable-fixinclud= >es -disable-libgcc -disable-decimal-float -disable-fixed-point -disable-tls >>=20 >> --procedure-- -line- -file--- >> exec -- >> m3cc_Run 339 /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/m3ma= >kefile >> include_dir 537 /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/m3ma= >kefile >> 9 /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/ARMEL_LI= >NUX/m3make.args >>=20 >> Fatal Error: package build failed >> *** execution of [] failed **= >* >> (238)rover:~/cm3-cvs-anon/cm3/scripts/python> >>=20 >>=20 >> So I'm not really sure what state porting of CM3 is in. I think it >> would be really interesting to have it running on the Raspberry Pi=2C >> partly because Modula-3 and Python are in many ways similar but Modula-3 >> code tends to be many times more efficient (at least in runtime) and >> the computer is slow by modern standards. >>=20 >> A few questions... >>=20 >> Is ARMEL_LINUX a real port? Does it work? Has it worked for anyone? =20 >>=20 >> Am I going about it the right way per latest recommendations---that is=2C >> trying to cross-compile from an existing CM3 installation on 32-bit >> i386 system? >>=20 >> Clearly just running ./boot1.py ARMEL_LINUX on the FreeBSD system is >> not the right approach... maybe someone knows what is? >>=20 >> Do I maybe need to upgrade the host CM3 to the head first? (Sounds >> like a whole other can of worms but ok...) >>=20 >> The Pi I think is more than powerful enough to compile everything >> natively. When I started with Modula-3=2C I had a 120-MHz Pentium on >> my desk with 128 MB of RAM=2C and that was considered a powerful >> system at the time. This is a 700 MHz ARM with 512 MB of RAM. >> So I'm not against compiling stuff natively (in fact I think it makes >> things easier)=2C but cross-compiling is fine too if that gets me to >> the goal easier. >>=20 >> I am happy to try C generating compilers but I would prefer to keep >> things as un-experimental as possible for now=2C because I have some >> control applications I'd like to try to build without having to debug >> lots and lots of software first. >>=20 >> Finally I think it would be *really* cool if we had a distribution of >> Modula-3 that was polished enough to be distributable to Raspberry Pi >> users. Just based on the gross characteristics of the two systems=2C >> I think the Pi and Modula-3 ought to be a very good match for each >> other. Basically=2C the Pi is a full-featured but slow hardware system >> with good networking facilities. It could use a safe=2C modern=2C effici= >ent >> systems programming language running on it. Most things on it nowadays >> are written in Python from what i understand. >>=20 >> Mika > = > >--_dddec029-8cf2-4528-8c46-8d0a40bef349_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > >

=3B Porting to new systems = >is pretty easy. =3B
=3B I had ARMEL_LINUX pretty far along.&nb= >sp=3B
=3B I forgot how far. =3B
=3B =3BI did have= > to =3Badd sort of support for 128bit integers in the =3Bgcc backen= >d. Sort of. =3B
=3B

=3B>=3B ../gcc-4.7/configure= >: not found

=3B
=3B Make sure you cvs upd -dAP so you = >get new directories.

=3B
=3B We should switch to the C= > backend though. It is just a one line change =3B
=3B =3B = >in the config file. Look at the Darwin config files. =3B
=3B I= >t is not experimental. =3B
=3B It has been essentially working= > for over a year (since September 2012)
=3B =3B and it is in v= >ery good shape now.
=3B I have used it for a number of architectur= >es and operating systems already=2C
=3B like I think every Solaris= > architecture=2C Linux=2C Darwin=2C NT.
=3B I'd like to see more p= >eople use it=2C and I'd like to drop the gcc backend entirely.
=3B= > This is an important step in leaving Modula-3 very portable and easier to = >support.
=3B

=3B- Jay

=3B

>=3B T= >o: m3devel at elegosoft.com
>=3B Date: Sun=2C 13 Oct 2013 13:35:01 -0700<= >br>>=3B From: mika at async.caltech.edu
>=3B Subject: [M3devel] buildin= >g CM3 on a Raspberry Pi?
>=3B
>=3B
>=3B Hi everyone (mostl= >y Jay)=2C
>=3B
>=3B Last time I tried to port CM3 to a new archi= >tecture I really got nowhere.
>=3B
>=3B I thought it might be ti= >me to try again. I have a Raspberry Pi=2C forty-dollar computer.
>=3B= >
>=3B It has "Raspbian" installed on it.
>=3B
>=3B The fol= >lowing output is probably relevant:
>=3B
>=3B pi at raspberrypi ~ $= > uname -a
>=3B Linux raspberrypi 3.6.11+ #538 PREEMPT Fri Aug 30 20:42= >:08 BST 2013 armv6l GNU/Linux
>=3B
>=3B pi at raspberrypi ~ $ gcc -= >v
>=3B Using built-in specs.
>=3B COLLECT_GCC=3Dgcc
>=3B COL= >LECT_LTO_WRAPPER=3D/usr/lib/gcc/arm-linux-gnueabihf/4.6/lto-wrapper
>= >=3B Target: arm-linux-gnueabihf
>=3B Configured with: ../src/configure= > -v --with-pkgversion=3D'Debian 4.6.3-14+rpi1' --with-bugurl=3Dfile:///usr/= >share/doc/gcc-4.6/README.Bugs --enable-languages=3Dc=2Cc++=2Cfortran=2Cobjc= >=2Cobj-c++ --prefix=3D/usr --program-suffix=3D-4.6 --enable-shared --enable= >-linker-build-id --with-system-zlib --libexecdir=3D/usr/lib --without-inclu= >ded-gettext --enable-threads=3Dposix --with-gxx-include-dir=3D/usr/include/= >c++/4.6 --libdir=3D/usr/lib --enable-nls --with-sysroot=3D/ --enable-clocal= >e=3Dgnu --enable-libstdcxx-debug --enable-libstdcxx-time=3Dyes --enable-gnu= >-unique-object --enable-plugin --enable-objc-gc --disable-sjlj-exceptions -= >-with-arch=3Darmv6 --with-fpu=3Dvfp --with-float=3Dhard --enable-checking= >=3Drelease --build=3Darm-linux-gnueabihf --host=3Darm-linux-gnueabihf --tar= >get=3Darm-linux-gnueabihf
>=3B Thread model: posix
>=3B gcc versi= >on 4.6.3 (Debian 4.6.3-14+rpi1)
>=3B
>=3B
>=3B Further=2C= > in the CM3 tree there is something called "ARMEL_LINUX".
>=3B I thoug= >ht=2C from reading some old messages on this mailing list=2C that doing
= >>=3B the following on my "big" system would result in something interesti= >ng:
>=3B
>=3B 1. CVS updating to the latest version of the tree<= >br>>=3B
>=3B 2. cd to scripts/python
>=3B
>=3B 3. ./boot= >1.py ARMEL_LINUX
>=3B
>=3B but all it did was mess up the cm3.cf= >g on my host system (FreeBSD4) and error out very quickly...
>=3B
= >>=3B ...
>=3B rm -f /usr/local/cm3/bin/IA64_LINUX
>=3B rm -f /u= >sr/local/cm3/bin/NT.common
>=3B rm -f /usr/local/cm3/bin/SPARC32_SOLAR= >IS.common
>=3B cp -Pv /big/home2/mika/2/cm3-cvs/cm3/m3-sys/cminstall/s= >rc/config-no-install/cm3.cfg /usr/local/cm3/bin/cm3.cfg
>=3B =3D=3D pa= >ckage /big/home2/mika/2/cm3-cvs/cm3/m3-win/import-libs =3D=3D
>=3B >>=3B +++ /usr/local/cm3/bin/cm3 -build -override -DROOT=3D/big/home2= >/mika/2/cm3-cvs/cm3 -boot -keep -DM3CC_TARGET=3DARMEL_LINUX +++
>=3B -= >-- building in ARMEL_LINUX ---
>=3B
>=3B =3D=3D>=3B /big/home= >2/mika/2/cm3-cvs/cm3/m3-win/import-libs done
>=3B
>=3B =3D=3D pa= >ckage /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc =3D=3D
>=3B
>=3B= > +++ /usr/local/cm3/bin/cm3 -build -override -DROOT=3D/big/home2/mika/2= >/cm3-cvs/cm3 -boot -keep -DM3CC_TARGET=3DARMEL_LINUX +++
>=3B --- buil= >ding in ARMEL_LINUX ---
>=3B
>=3B type make
>=3B make is /h= >ome/mika/cm3-build-bin//make
>=3B make --version | grep "GNU Make"
= >>=3B GNU Make 3.82
>=3B GNU_MAKE is make
>=3B cd ../FreeBSD4-AR= >MEL_LINUX &=3B&=3B MAKE=3D"make -j4 " AUTOCONF=3D: AUTOMAKE=3D: L= >EX=3D'touch lex.yy.c' MAKEINFO=3D: ../gcc-4.7/configure -with-sysroot -= >target=3Darm-linux-gnueabi -srcdir=3D../gcc-4.7 -disable-bootstrap -disable= >-intl -disable-libgomp -disable-libmudflap -disable-libssp -disable-nls -en= >able-languages=3Dm3cg -disable-fixincludes -disable-libgcc -disable-decimal= >-float -disable-fixed-point -disable-tls
>=3B cd ../FreeBSD4-ARMEL_LIN= >UX &=3B&=3B MAKE=3D"make -j4 " AUTOCONF=3D: AUTOMAKE=3D: LEX=3D't= >ouch lex.yy.c' MAKEINFO=3D: ../gcc-4.7/configure -with-sysroot -target= >=3Darm-linux-gnueabi -srcdir=3D../gcc-4.7 -disable-bootstrap -disable-intl = >-disable-libgomp -disable-libmudflap -disable-libssp -disable-nls -enable-l= >anguages=3Dm3cg -disable-fixincludes -disable-libgcc -disable-decimal-float= > -disable-fixed-point -disable-tls
>=3B ../gcc-4.7/configure: not foun= >d
>=3B "/big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/m3makefile"=2C l= >ine 339: quake runtime error: exit 127: cd ../FreeBSD4-ARMEL_LINUX &=3B&= >amp=3B MAKE=3D"make -j4 " AUTOCONF=3D: AUTOMAKE=3D: LEX=3D'touch lex.yy= >.c' MAKEINFO=3D: ../gcc-4.7/configure -with-sysroot -target=3Darm-linux= >-gnueabi -srcdir=3D../gcc-4.7 -disable-bootstrap -disable-intl -disable-lib= >gomp -disable-libmudflap -disable-libssp -disable-nls -enable-languages=3Dm= >3cg -disable-fixincludes -disable-libgcc -disable-decimal-float -disable-fi= >xed-point -disable-tls
>=3B
>=3B --procedure-- -line- -file---= >
>=3B exec -- <=3Bbuiltin>=3B
>=3B m3cc_Run = > 339 /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/m3makefile
>= >=3B include_dir 537 /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/m3= >makefile
>=3B 9 /big/home2/mika/2/cm3-cvs/cm3/m3-= >sys/m3cc/ARMEL_LINUX/m3make.args
>=3B
>=3B Fatal Error: package = >build failed
>=3B *** execution of [<=3Bfunction _BuildLocalFunctio= >n at 0x82d55a4>=3B] failed ***
>=3B (238)rover:~/cm3-cvs-anon/cm3/sc= >ripts/python>=3B
>=3B
>=3B
>=3B So I'm not really sure w= >hat state porting of CM3 is in. I think it
>=3B would be really inter= >esting to have it running on the Raspberry Pi=2C
>=3B partly because M= >odula-3 and Python are in many ways similar but Modula-3
>=3B code ten= >ds to be many times more efficient (at least in runtime) and
>=3B the = >computer is slow by modern standards.
>=3B
>=3B A few questions.= >..
>=3B
>=3B Is ARMEL_LINUX a real port? Does it work? Has it = >worked for anyone?
>=3B
>=3B Am I going about it the right way= > per latest recommendations---that is=2C
>=3B trying to cross-compile = >from an existing CM3 installation on 32-bit
>=3B i386 system?
>= >=3B
>=3B Clearly just running ./boot1.py ARMEL_LINUX on the FreeBSD s= >ystem is
>=3B not the right approach... maybe someone knows what is?r>>=3B
>=3B Do I maybe need to upgrade the host CM3 to the head fir= >st? (Sounds
>=3B like a whole other can of worms but ok...)
>=3B= >
>=3B The Pi I think is more than powerful enough to compile everythi= >ng
>=3B natively. When I started with Modula-3=2C I had a 120-MHz Pen= >tium on
>=3B my desk with 128 MB of RAM=2C and that was considered a p= >owerful
>=3B system at the time. This is a 700 MHz ARM with 512 MB of= > RAM.
>=3B So I'm not against compiling stuff natively (in fact I thin= >k it makes
>=3B things easier)=2C but cross-compiling is fine too if t= >hat gets me to
>=3B the goal easier.
>=3B
>=3B I am happy t= >o try C generating compilers but I would prefer to keep
>=3B things as= > un-experimental as possible for now=2C because I have some
>=3B contr= >ol applications I'd like to try to build without having to debug
>=3B = >lots and lots of software first.
>=3B
>=3B Finally I think it wo= >uld be *really* cool if we had a distribution of
>=3B Modula-3 that wa= >s polished enough to be distributable to Raspberry Pi
>=3B users. Jus= >t based on the gross characteristics of the two systems=2C
>=3B I thin= >k the Pi and Modula-3 ought to be a very good match for each
>=3B othe= >r. Basically=2C the Pi is a full-featured but slow hardware system
>= >=3B with good networking facilities. It could use a safe=2C modern=2C effi= >cient
>=3B systems programming language running on it. Most things on= > it nowadays
>=3B are written in Python from what i understand.
>= >=3B
>=3B Mika

>= > >--_dddec029-8cf2-4528-8c46-8d0a40bef349_-- From mika at async.caltech.edu Mon Oct 14 17:19:24 2013 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Mon, 14 Oct 2013 08:19:24 -0700 Subject: [M3devel] building CM3 on a Raspberry Pi? In-Reply-To: References: <20131013203501.35E651A208F@async.async.caltech.edu> Message-ID: <20131014151924.979A31A208E@async.async.caltech.edu> OK, with the new cvs update, this happens: gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gcc-4.7/libiberty/../include -W -Wall -Wwrite-strings -Wstrict-prototypes -pedantic ../../gcc-4.7/libiberty/strerror.c -o strerror.o ../../gcc-4.7/libiberty/stack-limit.c: In function `stack_limit_increase': ../../gcc-4.7/libiberty/stack-limit.c:52: error: `u_quad_t' undeclared (first use in this function)if [ x"" != x ]; then \ gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gcc-4.7/libiberty/../include -W -Wall -Wwrite-strings -Wstrict-prototypes -pedantic ../../gcc-4.7/libiberty/strsignal.c -o pic/strsignal.o; \ ../../gcc-4.7/libiberty/stack-limit.c:52: error: (Each undeclared identifier is reported only oncechecking for string.h... else true; fi ../../gcc-4.7/libiberty/stack-limit.c:52: error: for each function it appears in.) gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gcc-4.7/libiberty/../include -W -Wall -Wwrite-strings -Wstrict-prototypes -pedantic ../../gcc-4.7/libiberty/strsignal.c -o strsignal.o ../../gcc-4.7/libiberty/stack-limit.c:52: error: syntax error before numeric constant if [ x"" != x ]; then \ ../../gcc-4.7/libiberty/stack-limit.c:54: error: syntax error before numeric constant ../../gcc-4.7/libiberty/stack-limit.c:57: error: syntax error before numeric constant gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gcc-4.7/libiberty/../include -W -Wall -Wwrite-strings -Wstrict-prototypes -pedantic ../../gcc-4.7/libiberty/timeval-utils.c -o pic/timeval-utils.o; \ else true; fi gmake[1]: *** [stack-limit.o] Error 1 gmake[1]: *** Waiting for unfinished jobs.... gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gcc-4.7/libiberty/../include -W -Wall -Wwrite-strings -Wstrict-prototypes -pedantic ../../gcc-4.7/libiberty/timeval-utils.c -o timeval-utils.o yes gmake[1]: Leaving directory `/big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/FreeBSD4-ARMEL_LINUX/libiberty' gmake: *** [all-libiberty] Error 2 gmake: *** Waiting for unfinished jobs.... checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes [ more config output ] checking for getpagesize... (cached) yes checking for working mmap... yes checking for working strncmp... yes configure: updating cache ../config.cache configure: creating ./config.status config.status: creating Makefile config.status: creating testsuite/Makefile config.status: creating config.h config.status: executing default commands "/big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/m3makefile", line 339: quake runtime error: exit 2: cd ../FreeBSD4-ARMEL_LINUX && gmake MAKE="gmake -j4 " AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: -j4 all-build-libiberty all-libiberty --procedure-- -line- -file--- exec -- m3cc_Run 339 /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/m3makefile include_dir 580 /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/m3makefile 9 /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/ARMEL_LINUX/m3make.args Fatal Error: package build failed *** execution of [] failed *** (129)rover:~/cm3-cvs-anon/cm3/scripts/python> From mika at async.caltech.edu Mon Oct 14 17:54:47 2013 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Mon, 14 Oct 2013 08:54:47 -0700 Subject: [M3devel] building CM3 on a Raspberry Pi? In-Reply-To: <20131014151924.979A31A208E@async.async.caltech.edu> References: <20131013203501.35E651A208F@async.async.caltech.edu> <20131014151924.979A31A208E@async.async.caltech.edu> Message-ID: <20131014155447.8C1C31A208E@async.async.caltech.edu> Well it looked to me like the quad_t issue was a mistake in the GCC code. getrlimit requires #include on my system at least. But this is less clear to me: echo '#include "tree.def"' > tmp-all-tree.def echo timestamp > s-gtyp-input echo 'END_OF_BASE_TREE_CODES' >> tmp-all-tree.def echo "#define BUILDING_GCC_PATCHLEVEL `echo 4.7.1 | sed -e 's/^[0-9]*\.[0-9]*\.$[0-9]*$$/\1/'`" >> bversion.h echo '#include "c-family/c-common.def"' >> tmp-all-tree.def TARGET_CPU_DEFAULT="" \ HEADERS="auto-host.h ansidecl.h" DEFINES="" \ /bin/bash ../../gcc-4.7/gcc/mkconfig.sh config.h gmake: *** No rule to make target `c-family/c-pragma.h', needed by `arm.o'. Stop. gmake: *** Waiting for unfinished jobs.... ltf=""; for f in $ltf; do \ echo "#include \"$f\""; \ done | sed 's|../../gcc-4.7/gcc/||' >> tmp-all-tree.def echo "#define BUILDING_GCC_VERSION (BUILDING_GCC_MAJOR * 1000 + BUILDING_GCC_MINOR)" >> bversion.h /bin/bash ../../gcc-4.7/gcc/../move-if-change tmp-all-tree.def all-tree.def echo timestamp > s-bversion echo timestamp > s-alltree "/big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/m3makefile", line 339: quake runtime error: exit 2: cd ../FreeBSD4-ARMEL_LINUX && cd gcc && gmake MAKE="gmake -j4 " AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: -j4 s-modes insn-config.h m3cg --procedure-- -line- -file--- exec -- m3cc_Run 339 /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/m3makefile include_dir 589 /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/m3makefile 9 /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/ARMEL_LINUX/m3make.args Fatal Error: package build failed *** execution of [] failed *** (137)rover:~/cm3-cvs-anon/cm3/scripts/python> I don't know if this matters: (137)rover:~/cm3-cvs-anon/cm3/scripts/python>uname -a FreeBSD rover 5.5-RELEASE FreeBSD 5.5-RELEASE #0: Sat May 24 10:13:58 PDT 2008 root at rover:/usr/src/sys/i386/compile/ROVERSMP i386 (138)rover:~/cm3-cvs-anon/cm3/scripts/python>gcc -v Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.4.2 [FreeBSD] 20040728 mika writes: > >OK, with the new cvs update, this happens: > >gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gcc-4.7/libiberty/../include -W -Wall -Wwrite-strings -Wstrict-prototypes -pedantic ../../gcc-4.7/libiberty/strerror.c -o strerro >r.o >../../gcc-4.7/libiberty/stack-limit.c: In function `stack_limit_increase': >../../gcc-4.7/libiberty/stack-limit.c:52: error: `u_quad_t' undeclared (first use in this function)if [ x"" != x ]; then \ > > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gcc-4.7/libiberty/../include -W -Wall -Wwrite-strings -Wstrict-prototypes -pedantic ../../gcc-4.7/libiberty/strsignal.c -o pic >/strsignal.o; \ >../../gcc-4.7/libiberty/stack-limit.c:52: error: (Each undeclared identifier is reported only oncechecking for string.h... else true; fi > >../../gcc-4.7/libiberty/stack-limit.c:52: error: for each function it appears in.) >gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gcc-4.7/libiberty/../include -W -Wall -Wwrite-strings -Wstrict-prototypes -pedantic ../../gcc-4.7/libiberty/strsignal.c -o strsig >nal.o >../../gcc-4.7/libiberty/stack-limit.c:52: error: syntax error before numeric constant >if [ x"" != x ]; then \ >../../gcc-4.7/libiberty/stack-limit.c:54: error: syntax error before numeric constant >../../gcc-4.7/libiberty/stack-limit.c:57: error: syntax error before numeric constant > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gcc-4.7/libiberty/../include -W -Wall -Wwrite-strings -Wstrict-prototypes -pedantic ../../gcc-4.7/libiberty/timeval-utils.c -o > pic/timeval-utils.o; \ >else true; fi >gmake[1]: *** [stack-limit.o] Error 1 >gmake[1]: *** Waiting for unfinished jobs.... >gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gcc-4.7/libiberty/../include -W -Wall -Wwrite-strings -Wstrict-prototypes -pedantic ../../gcc-4.7/libiberty/timeval-utils.c -o ti >meval-utils.o >yes >gmake[1]: Leaving directory `/big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/FreeBSD4-ARMEL_LINUX/libiberty' >gmake: *** [all-libiberty] Error 2 >gmake: *** Waiting for unfinished jobs.... >checking for memory.h... yes >checking for strings.h... yes >checking for inttypes.h... yes >checking for stdint.h... yes >checking for unistd.h... yes > >[ more config output ] > >checking for getpagesize... (cached) yes >checking for working mmap... yes >checking for working strncmp... yes >configure: updating cache ../config.cache >configure: creating ./config.status >config.status: creating Makefile >config.status: creating testsuite/Makefile >config.status: creating config.h >config.status: executing default commands >"/big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/m3makefile", line 339: quake runtime error: exit 2: cd ../FreeBSD4-ARMEL_LINUX && gmake MAKE="gmake -j4 " AUTOCONF=: AUTOMA >KE=: LEX='touch lex.yy.c' MAKEINFO=: -j4 all-build-libiberty all-libiberty > >--procedure-- -line- -file--- >exec -- >m3cc_Run 339 /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/m3makefile >include_dir 580 /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/m3makefile > 9 /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/ARMEL_LINUX/m3make.args > >Fatal Error: package build failed > *** execution of [] failed *** >(129)rover:~/cm3-cvs-anon/cm3/scripts/python> From mika at async.caltech.edu Mon Oct 14 18:01:34 2013 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Mon, 14 Oct 2013 09:01:34 -0700 Subject: [M3devel] building CM3 on a Raspberry Pi? In-Reply-To: References: <20131013203501.35E651A208F@async.async.caltech.edu> Message-ID: <20131014160134.4D0B61A208E@async.async.caltech.edu> [sorry for sending so many small messages..] I get the same error about c-family/c-pragma.h if I add M3_BACKEND_MODE = "C" to the bottom of the ARMEL_LINUX config in config-no-install and re-run boot1.py ... Jay K writes: >--_dddec029-8cf2-4528-8c46-8d0a40bef349_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > Porting to new systems is pretty easy. =20 > I had ARMEL_LINUX pretty far along. =20 > I forgot how far. =20 > I did have to add sort of support for 128bit integers in the gcc backend.= > Sort of. =20 >=20 > > > ../gcc-4.7/configure: not found=20 > >=20 > Make sure you cvs upd -dAP so you get new directories.=20 > >=20 > We should switch to the C backend though. It is just a one line change =20 > in the config file. Look at the Darwin config files. =20 > It is not experimental. =20 > It has been essentially working for over a year (since September 2012)=20 > and it is in very good shape now.=20 > I have used it for a number of architectures and operating systems alread= >y=2C=20 > like I think every Solaris architecture=2C Linux=2C Darwin=2C NT.=20 > I'd like to see more people use it=2C and I'd like to drop the gcc backen= >d entirely.=20 > This is an important step in leaving Modula-3 very portable and easier to= > support.=20 >=20 > > - Jay > >=20 >> To: m3devel at elegosoft.com >> Date: Sun=2C 13 Oct 2013 13:35:01 -0700 >> From: mika at async.caltech.edu >> Subject: [M3devel] building CM3 on a Raspberry Pi? >>=20 >>=20 >> Hi everyone (mostly Jay)=2C >>=20 >> Last time I tried to port CM3 to a new architecture I really got nowhere. >>=20 >> I thought it might be time to try again. I have a Raspberry Pi=2C forty-= >dollar computer. >>=20 >> It has "Raspbian" installed on it. >>=20 >> The following output is probably relevant: >>=20 >> pi at raspberrypi ~ $ uname -a >> Linux raspberrypi 3.6.11+ #538 PREEMPT Fri Aug 30 20:42:08 BST 2013 armv6= >l GNU/Linux >>=20 >> pi at raspberrypi ~ $ gcc -v >> Using built-in specs. >> COLLECT_GCC=3Dgcc >> COLLECT_LTO_WRAPPER=3D/usr/lib/gcc/arm-linux-gnueabihf/4.6/lto-wrapper >> Target: arm-linux-gnueabihf >> Configured with: ../src/configure -v --with-pkgversion=3D'Debian 4.6.3-14= >+rpi1' --with-bugurl=3Dfile:///usr/share/doc/gcc-4.6/README.Bugs --enable-l= >anguages=3Dc=2Cc++=2Cfortran=2Cobjc=2Cobj-c++ --prefix=3D/usr --program-suf= >fix=3D-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --li= >bexecdir=3D/usr/lib --without-included-gettext --enable-threads=3Dposix --w= >ith-gxx-include-dir=3D/usr/include/c++/4.6 --libdir=3D/usr/lib --enable-nls= > --with-sysroot=3D/ --enable-clocale=3Dgnu --enable-libstdcxx-debug --enabl= >e-libstdcxx-time=3Dyes --enable-gnu-unique-object --enable-plugin --enable-= >objc-gc --disable-sjlj-exceptions --with-arch=3Darmv6 --with-fpu=3Dvfp --wi= >th-float=3Dhard --enable-checking=3Drelease --build=3Darm-linux-gnueabihf -= >-host=3Darm-linux-gnueabihf --target=3Darm-linux-gnueabihf >> Thread model: posix >> gcc version 4.6.3 (Debian 4.6.3-14+rpi1)=20 >>=20 >>=20 >> Further=2C in the CM3 tree there is something called "ARMEL_LINUX". >> I thought=2C from reading some old messages on this mailing list=2C that = >doing >> the following on my "big" system would result in something interesting: >>=20 >> 1. CVS updating to the latest version of the tree >>=20 >> 2. cd to scripts/python >>=20 >> 3. ./boot1.py ARMEL_LINUX >>=20 >> but all it did was mess up the cm3.cfg on my host system (FreeBSD4) and e= >rror out very quickly... >>=20 >> ... >> rm -f /usr/local/cm3/bin/IA64_LINUX >> rm -f /usr/local/cm3/bin/NT.common >> rm -f /usr/local/cm3/bin/SPARC32_SOLARIS.common >> cp -Pv /big/home2/mika/2/cm3-cvs/cm3/m3-sys/cminstall/src/config-no-insta= >ll/cm3.cfg /usr/local/cm3/bin/cm3.cfg >> =3D=3D package /big/home2/mika/2/cm3-cvs/cm3/m3-win/import-libs =3D=3D >>=20 >> +++ /usr/local/cm3/bin/cm3 -build -override -DROOT=3D/big/home2/mika/= >2/cm3-cvs/cm3 -boot -keep -DM3CC_TARGET=3DARMEL_LINUX +++ >> --- building in ARMEL_LINUX --- >>=20 >> =3D=3D> /big/home2/mika/2/cm3-cvs/cm3/m3-win/import-libs done >>=20 >> =3D=3D package /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc =3D=3D >>=20 >> +++ /usr/local/cm3/bin/cm3 -build -override -DROOT=3D/big/home2/mika/= >2/cm3-cvs/cm3 -boot -keep -DM3CC_TARGET=3DARMEL_LINUX +++ >> --- building in ARMEL_LINUX --- >>=20 >> type make >> make is /home/mika/cm3-build-bin//make >> make --version | grep "GNU Make" >> GNU Make 3.82 >> GNU_MAKE is make >> cd ../FreeBSD4-ARMEL_LINUX && MAKE=3D"make -j4 " AUTOCONF=3D: AUTOMAK= >E=3D: LEX=3D'touch lex.yy.c' MAKEINFO=3D: ../gcc-4.7/configure -with-sy= >sroot -target=3Darm-linux-gnueabi -srcdir=3D../gcc-4.7 -disable-bootstrap -= >disable-intl -disable-libgomp -disable-libmudflap -disable-libssp -disable-= >nls -enable-languages=3Dm3cg -disable-fixincludes -disable-libgcc -disable-= >decimal-float -disable-fixed-point -disable-tls >> cd ../FreeBSD4-ARMEL_LINUX && MAKE=3D"make -j4 " AUTOCONF=3D: AUTOMAK= >E=3D: LEX=3D'touch lex.yy.c' MAKEINFO=3D: ../gcc-4.7/configure -with-sy= >sroot -target=3Darm-linux-gnueabi -srcdir=3D../gcc-4.7 -disable-bootstrap -= >disable-intl -disable-libgomp -disable-libmudflap -disable-libssp -disable-= >nls -enable-languages=3Dm3cg -disable-fixincludes -disable-libgcc -disable-= >decimal-float -disable-fixed-point -disable-tls >> ../gcc-4.7/configure: not found >> "/big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/m3makefile"=2C line 339: q= >uake runtime error: exit 127: cd ../FreeBSD4-ARMEL_LINUX && MAKE=3D"make = >-j4 " AUTOCONF=3D: AUTOMAKE=3D: LEX=3D'touch lex.yy.c' MAKEINFO=3D: ../gc= >c-4.7/configure -with-sysroot -target=3Darm-linux-gnueabi -srcdir=3D../= >gcc-4.7 -disable-bootstrap -disable-intl -disable-libgomp -disable-libmudfl= >ap -disable-libssp -disable-nls -enable-languages=3Dm3cg -disable-fixinclud= >es -disable-libgcc -disable-decimal-float -disable-fixed-point -disable-tls >>=20 >> --procedure-- -line- -file--- >> exec -- >> m3cc_Run 339 /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/m3ma= >kefile >> include_dir 537 /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/m3ma= >kefile >> 9 /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/ARMEL_LI= >NUX/m3make.args >>=20 >> Fatal Error: package build failed >> *** execution of [] failed **= >* >> (238)rover:~/cm3-cvs-anon/cm3/scripts/python> >>=20 >>=20 >> So I'm not really sure what state porting of CM3 is in. I think it >> would be really interesting to have it running on the Raspberry Pi=2C >> partly because Modula-3 and Python are in many ways similar but Modula-3 >> code tends to be many times more efficient (at least in runtime) and >> the computer is slow by modern standards. >>=20 >> A few questions... >>=20 >> Is ARMEL_LINUX a real port? Does it work? Has it worked for anyone? =20 >>=20 >> Am I going about it the right way per latest recommendations---that is=2C >> trying to cross-compile from an existing CM3 installation on 32-bit >> i386 system? >>=20 >> Clearly just running ./boot1.py ARMEL_LINUX on the FreeBSD system is >> not the right approach... maybe someone knows what is? >>=20 >> Do I maybe need to upgrade the host CM3 to the head first? (Sounds >> like a whole other can of worms but ok...) >>=20 >> The Pi I think is more than powerful enough to compile everything >> natively. When I started with Modula-3=2C I had a 120-MHz Pentium on >> my desk with 128 MB of RAM=2C and that was considered a powerful >> system at the time. This is a 700 MHz ARM with 512 MB of RAM. >> So I'm not against compiling stuff natively (in fact I think it makes >> things easier)=2C but cross-compiling is fine too if that gets me to >> the goal easier. >>=20 >> I am happy to try C generating compilers but I would prefer to keep >> things as un-experimental as possible for now=2C because I have some >> control applications I'd like to try to build without having to debug >> lots and lots of software first. >>=20 >> Finally I think it would be *really* cool if we had a distribution of >> Modula-3 that was polished enough to be distributable to Raspberry Pi >> users. Just based on the gross characteristics of the two systems=2C >> I think the Pi and Modula-3 ought to be a very good match for each >> other. Basically=2C the Pi is a full-featured but slow hardware system >> with good networking facilities. It could use a safe=2C modern=2C effici= >ent >> systems programming language running on it. Most things on it nowadays >> are written in Python from what i understand. >>=20 >> Mika > = > >--_dddec029-8cf2-4528-8c46-8d0a40bef349_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > >

>= > >--_dddec029-8cf2-4528-8c46-8d0a40bef349_-- From mika at async.caltech.edu Mon Oct 14 18:15:48 2013 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Mon, 14 Oct 2013 09:15:48 -0700 Subject: [M3devel] building CM3 on a Raspberry Pi? In-Reply-To: References: <20131013203501.35E651A208F@async.async.caltech.edu> <20131014151924.979A31A208E@async.async.caltech.edu> Message-ID: <20131014161548.EF7521A208E@async.async.caltech.edu> Jay writes: ... >Cm3.cfg: yes it might do that. I can see about using a separate file but no p= >romises there. A flaw perhaps in some of my earlier thinking was over eagern= >ess in when the config files get updated. The older config files were in gen= >eral very flawed IMHO. But maybe good to leave them alone in early bootstrap= >, if they worked. But I really had a lot of problems with them. The current o= >nes don't require cminstall, have less version/target-specific code, have fa= >r less duplication, and are meant to work with older cm3 (albeit maybe give u= >p on dynamic linking with older versions). ... My point here was just this... I have a system with a working compiler. Everything is set up carefully to work with all the various packages and things and strange flags I might need to get everything working on my very very special machine. It's all in cm3.cfg, no? Now, I want to build a cross compiler, just so I can bootstrap an installation on another system. And the first thing that happens is I lose my own very carefully crafted installation configuration? Is that really right? Or am I misunderstanding something about the process? More updates are that I got the same error about the tree file on Linux (quite recent install), so it must be an issue with the gcc. I'll try your suggestions.. Mika From jay.krell at cornell.edu Mon Oct 14 18:07:42 2013 From: jay.krell at cornell.edu (Jay) Date: Mon, 14 Oct 2013 09:07:42 -0700 Subject: [M3devel] building CM3 on a Raspberry Pi? In-Reply-To: <20131014151924.979A31A208E@async.async.caltech.edu> References: <20131013203501.35E651A208F@async.async.caltech.edu> <20131014151924.979A31A208E@async.async.caltech.edu> Message-ID: ./../gcc-4.7/libiberty/stack-limit.c:52: error: `u_quad_t' undeclared (first use in this function)if [ x"" != x ]; then \ Maybe I removed too much. I.e. libquadmath. That should be easy to fix and/or switch to C backend. I forgot: besides switching the config file: add the parameter "c" to boot1.py. I'll *try* to build a bootstrap archive with cm3cg or C this week. Cm3.cfg: yes it might do that. I can see about using a separate file but no promises there. A flaw perhaps in some of my earlier thinking was over eagerness in when the config files get updated. The older config files were in general very flawed IMHO. But maybe good to leave them alone in early bootstrap, if they worked. But I really had a lot of problems with them. The current ones don't require cminstall, have less version/target-specific code, have far less duplication, and are meant to work with older cm3 (albeit maybe give up on dynamic linking with older versions). - Jay On Oct 14, 2013, at 8:19 AM, wrote: > > OK, with the new cvs update, this happens: > > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gcc-4.7/libiberty/../include -W -Wall -Wwrite-strings -Wstrict-prototypes -pedantic ../../gcc-4.7/libiberty/strerror.c -o strerror.o > ../../gcc-4.7/libiberty/stack-limit.c: In function `stack_limit_increase': > ../../gcc-4.7/libiberty/stack-limit.c:52: error: `u_quad_t' undeclared (first use in this function)if [ x"" != x ]; then \ > > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gcc-4.7/libiberty/../include -W -Wall -Wwrite-strings -Wstrict-prototypes -pedantic ../../gcc-4.7/libiberty/strsignal.c -o pic/strsignal.o; \ > ../../gcc-4.7/libiberty/stack-limit.c:52: error: (Each undeclared identifier is reported only oncechecking for string.h... else true; fi > > ../../gcc-4.7/libiberty/stack-limit.c:52: error: for each function it appears in.) > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gcc-4.7/libiberty/../include -W -Wall -Wwrite-strings -Wstrict-prototypes -pedantic ../../gcc-4.7/libiberty/strsignal.c -o strsignal.o > ../../gcc-4.7/libiberty/stack-limit.c:52: error: syntax error before numeric constant > if [ x"" != x ]; then \ > ../../gcc-4.7/libiberty/stack-limit.c:54: error: syntax error before numeric constant > ../../gcc-4.7/libiberty/stack-limit.c:57: error: syntax error before numeric constant > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gcc-4.7/libiberty/../include -W -Wall -Wwrite-strings -Wstrict-prototypes -pedantic ../../gcc-4.7/libiberty/timeval-utils.c -o pic/timeval-utils.o; \ > else true; fi > gmake[1]: *** [stack-limit.o] Error 1 > gmake[1]: *** Waiting for unfinished jobs.... > gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gcc-4.7/libiberty/../include -W -Wall -Wwrite-strings -Wstrict-prototypes -pedantic ../../gcc-4.7/libiberty/timeval-utils.c -o timeval-utils.o > yes > gmake[1]: Leaving directory `/big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/FreeBSD4-ARMEL_LINUX/libiberty' > gmake: *** [all-libiberty] Error 2 > gmake: *** Waiting for unfinished jobs.... > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > > [ more config output ] > > checking for getpagesize... (cached) yes > checking for working mmap... yes > checking for working strncmp... yes > configure: updating cache ../config.cache > configure: creating ./config.status > config.status: creating Makefile > config.status: creating testsuite/Makefile > config.status: creating config.h > config.status: executing default commands > "/big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/m3makefile", line 339: quake runtime error: exit 2: cd ../FreeBSD4-ARMEL_LINUX && gmake MAKE="gmake -j4 " AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: -j4 all-build-libiberty all-libiberty > > --procedure-- -line- -file--- > exec -- > m3cc_Run 339 /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/m3makefile > include_dir 580 /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/m3makefile > 9 /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/ARMEL_LINUX/m3make.args > > Fatal Error: package build failed > *** execution of [] failed *** > (129)rover:~/cm3-cvs-anon/cm3/scripts/python> > From jay.krell at cornell.edu Mon Oct 14 18:15:11 2013 From: jay.krell at cornell.edu (Jay) Date: Mon, 14 Oct 2013 09:15:11 -0700 Subject: [M3devel] building CM3 on a Raspberry Pi? In-Reply-To: <20131014155447.8C1C31A208E@async.async.caltech.edu> References: <20131013203501.35E651A208F@async.async.caltech.edu> <20131014151924.979A31A208E@async.async.caltech.edu> <20131014155447.8C1C31A208E@async.async.caltech.edu> Message-ID: <8C59867A-6D81-4CFD-8E87-928C8166BA86@gmail.com> Could be related to my removal of the C frontends. C frontend sometimes gets intermingled with backends, possibly target-specific parts. Should be easy to deal with... - Jay On Oct 14, 2013, at 8:54 AM, wrote: > > Well it looked to me like the quad_t issue was a mistake in the GCC code. getrlimit requires #include on my system at least. > > But this is less clear to me: > > echo '#include "tree.def"' > tmp-all-tree.def > echo timestamp > s-gtyp-input > echo 'END_OF_BASE_TREE_CODES' >> tmp-all-tree.def > echo "#define BUILDING_GCC_PATCHLEVEL `echo 4.7.1 | sed -e 's/^[0-9]*\.[0-9]*\.$[0-9]*$$/\1/'`" >> bversion.h > echo '#include "c-family/c-common.def"' >> tmp-all-tree.def > TARGET_CPU_DEFAULT="" \ > HEADERS="auto-host.h ansidecl.h" DEFINES="" \ > /bin/bash ../../gcc-4.7/gcc/mkconfig.sh config.h > gmake: *** No rule to make target `c-family/c-pragma.h', needed by `arm.o'. Stop. > gmake: *** Waiting for unfinished jobs.... > ltf=""; for f in $ltf; do \ > echo "#include \"$f\""; \ > done | sed 's|../../gcc-4.7/gcc/||' >> tmp-all-tree.def > echo "#define BUILDING_GCC_VERSION (BUILDING_GCC_MAJOR * 1000 + BUILDING_GCC_MINOR)" >> bversion.h > /bin/bash ../../gcc-4.7/gcc/../move-if-change tmp-all-tree.def all-tree.def > echo timestamp > s-bversion > echo timestamp > s-alltree > "/big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/m3makefile", line 339: quake runtime error: exit 2: cd ../FreeBSD4-ARMEL_LINUX && cd gcc && gmake MAKE="gmake -j4 " AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: -j4 s-modes insn-config.h m3cg > > --procedure-- -line- -file--- > exec -- > m3cc_Run 339 /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/m3makefile > include_dir 589 /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/m3makefile > 9 /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/ARMEL_LINUX/m3make.args > > Fatal Error: package build failed > *** execution of [] failed *** > (137)rover:~/cm3-cvs-anon/cm3/scripts/python> > > I don't know if this matters: > > (137)rover:~/cm3-cvs-anon/cm3/scripts/python>uname -a > FreeBSD rover 5.5-RELEASE FreeBSD 5.5-RELEASE #0: Sat May 24 10:13:58 PDT 2008 root at rover:/usr/src/sys/i386/compile/ROVERSMP i386 > (138)rover:~/cm3-cvs-anon/cm3/scripts/python>gcc -v > Using built-in specs. > Configured with: FreeBSD/i386 system compiler > Thread model: posix > gcc version 3.4.2 [FreeBSD] 20040728 > > mika writes: >> >> OK, with the new cvs update, this happens: >> >> gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gcc-4.7/libiberty/../include -W -Wall -Wwrite-strings -Wstrict-prototypes -pedantic ../../gcc-4.7/libiberty/strerror.c -o strerro >> r.o >> ../../gcc-4.7/libiberty/stack-limit.c: In function `stack_limit_increase': >> ../../gcc-4.7/libiberty/stack-limit.c:52: error: `u_quad_t' undeclared (first use in this function)if [ x"" != x ]; then \ >> >> gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gcc-4.7/libiberty/../include -W -Wall -Wwrite-strings -Wstrict-prototypes -pedantic ../../gcc-4.7/libiberty/strsignal.c -o pic >> /strsignal.o; \ >> ../../gcc-4.7/libiberty/stack-limit.c:52: error: (Each undeclared identifier is reported only oncechecking for string.h... else true; fi >> >> ../../gcc-4.7/libiberty/stack-limit.c:52: error: for each function it appears in.) >> gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gcc-4.7/libiberty/../include -W -Wall -Wwrite-strings -Wstrict-prototypes -pedantic ../../gcc-4.7/libiberty/strsignal.c -o strsig >> nal.o >> ../../gcc-4.7/libiberty/stack-limit.c:52: error: syntax error before numeric constant >> if [ x"" != x ]; then \ >> ../../gcc-4.7/libiberty/stack-limit.c:54: error: syntax error before numeric constant >> ../../gcc-4.7/libiberty/stack-limit.c:57: error: syntax error before numeric constant >> gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gcc-4.7/libiberty/../include -W -Wall -Wwrite-strings -Wstrict-prototypes -pedantic ../../gcc-4.7/libiberty/timeval-utils.c -o >> pic/timeval-utils.o; \ >> else true; fi >> gmake[1]: *** [stack-limit.o] Error 1 >> gmake[1]: *** Waiting for unfinished jobs.... >> gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gcc-4.7/libiberty/../include -W -Wall -Wwrite-strings -Wstrict-prototypes -pedantic ../../gcc-4.7/libiberty/timeval-utils.c -o ti >> meval-utils.o >> yes >> gmake[1]: Leaving directory `/big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/FreeBSD4-ARMEL_LINUX/libiberty' >> gmake: *** [all-libiberty] Error 2 >> gmake: *** Waiting for unfinished jobs.... >> checking for memory.h... yes >> checking for strings.h... yes >> checking for inttypes.h... yes >> checking for stdint.h... yes >> checking for unistd.h... yes >> >> [ more config output ] >> >> checking for getpagesize... (cached) yes >> checking for working mmap... yes >> checking for working strncmp... yes >> configure: updating cache ../config.cache >> configure: creating ./config.status >> config.status: creating Makefile >> config.status: creating testsuite/Makefile >> config.status: creating config.h >> config.status: executing default commands >> "/big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/m3makefile", line 339: quake runtime error: exit 2: cd ../FreeBSD4-ARMEL_LINUX && gmake MAKE="gmake -j4 " AUTOCONF=: AUTOMA >> KE=: LEX='touch lex.yy.c' MAKEINFO=: -j4 all-build-libiberty all-libiberty >> >> --procedure-- -line- -file--- >> exec -- >> m3cc_Run 339 /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/m3makefile >> include_dir 580 /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/m3makefile >> 9 /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/ARMEL_LINUX/m3make.args >> >> Fatal Error: package build failed >> *** execution of [] failed *** >> (129)rover:~/cm3-cvs-anon/cm3/scripts/python> From mika at async.caltech.edu Mon Oct 14 18:40:08 2013 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Mon, 14 Oct 2013 09:40:08 -0700 Subject: [M3devel] building CM3 on a Raspberry Pi? In-Reply-To: References: <20131013203501.35E651A208F@async.async.caltech.edu> <20131014151924.979A31A208E@async.async.caltech.edu> Message-ID: <20131014164008.685B81A208E@async.async.caltech.edu> Jay writes: >./../gcc-4.7/libiberty/stack-limit.c:52: error: `u_quad_t' undeclared (first= > use in this function)if [ x"" !=3D x ]; then \ > > >Maybe I removed too much. I.e. libquadmath. That should be easy to fix and/o= >r switch to C backend. > > >I forgot: besides switching the config file: add the parameter "c" to boot1.= >py. > > If I put in config-no-install/ARMEL_LINUX M3_BACKEND_MODE="C" and run ./boot1.py c ARMEL_LINUX the following happens: ... rm -f /nfs/site/home/mnystroe/work/cm3/bin/cm3.cfg rm -f /nfs/site/home/mnystroe/work/cm3/bin/cm3cfg.common rm -f /nfs/site/home/mnystroe/work/cm3/bin/gnuld.common cp -Pv /nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3/m3-sys/cminstall/src/config-no-install/cm3.cfg /nfs/site/home/mnystroe/work/cm3/bin/cm3.cfg == package /nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3/m3-win/import-libs == +++ /nfs/site/home/mnystroe/work/cm3/bin/cm3 -build -override -DROOT=/nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3 -boot -keep -DM3CC_TARGET=ARMEL_LINUX +++ --- building in ARMEL_LINUX --- ==> /nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3/m3-win/import-libs done == package /nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3/m3-libs/m3core == +++ /nfs/site/home/mnystroe/work/cm3/bin/cm3 -build -override -DROOT=/nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3 -boot -keep -DM3CC_TARGET=ARMEL_LINUX +++ --- building in ARMEL_LINUX --- Fatal Error: unrecognized backend mode: C *** execution of [] failed *** But if I remove M3_BACKEND_MODE from ARMEL_LINUX and run the same command, the following: ... rm -f /nfs/site/home/mnystroe/work/cm3/bin/cm3cfg.common rm -f /nfs/site/home/mnystroe/work/cm3/bin/gnuld.common cp -Pv /nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3/m3-sys/cminstall/src/config-no-install/cm3.cfg /nfs/site/home/mnystroe/work/cm3/bin/cm3.cfg == package /nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3/m3-win/import-libs == +++ /nfs/site/home/mnystroe/work/cm3/bin/cm3 -build -override -DROOT=/nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3 -boot -keep -DM3CC_TARGET=ARMEL_LINUX +++ --- building in ARMEL_LINUX --- ==> /nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3/m3-win/import-libs done == package /nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3/m3-libs/m3core == +++ /nfs/site/home/mnystroe/work/cm3/bin/cm3 -build -override -DROOT=/nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3 -boot -keep -DM3CC_TARGET=ARMEL_LINUX +++ --- building in ARMEL_LINUX --- Fatal Error: unrecognized target machine: TARGET = ARMEL_LINUX *** execution of [] failed *** From jay.krell at cornell.edu Mon Oct 14 18:59:21 2013 From: jay.krell at cornell.edu (Jay K) Date: Mon, 14 Oct 2013 16:59:21 +0000 Subject: [M3devel] building CM3 on a Raspberry Pi? In-Reply-To: <20131014164008.685B81A208E@async.async.caltech.edu> References: <20131013203501.35E651A208F@async.async.caltech.edu> <20131014151924.979A31A208E@async.async.caltech.edu> , <20131014164008.685B81A208E@async.async.caltech.edu> Message-ID: > Fatal Error: unrecognized backend mode: C Make sure you ./update.py your main toolset first. Also, while the C backend was working a year ago, for quite a while I did not change the builder to know about it directly. I was going via m3cgcat. So you need to be fairly current, or else modify the config files a different way, and have it be slower. - Jay > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] building CM3 on a Raspberry Pi? > Date: Mon, 14 Oct 2013 09:40:08 -0700 > From: mika at async.caltech.edu > > Jay writes: > >./../gcc-4.7/libiberty/stack-limit.c:52: error: `u_quad_t' undeclared (first= > > use in this function)if [ x"" !=3D x ]; then \ > > > > > >Maybe I removed too much. I.e. libquadmath. That should be easy to fix and/o= > >r switch to C backend. > > > > > >I forgot: besides switching the config file: add the parameter "c" to boot1.= > >py. > > > > > > If I put in config-no-install/ARMEL_LINUX > > M3_BACKEND_MODE="C" > > and run > > ./boot1.py c ARMEL_LINUX > > the following happens: > > ... > rm -f /nfs/site/home/mnystroe/work/cm3/bin/cm3.cfg > rm -f /nfs/site/home/mnystroe/work/cm3/bin/cm3cfg.common > rm -f /nfs/site/home/mnystroe/work/cm3/bin/gnuld.common > cp -Pv /nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3/m3-sys/cminstall/src/config-no-install/cm3.cfg /nfs/site/home/mnystroe/work/cm3/bin/cm3.cfg > == package /nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3/m3-win/import-libs == > > +++ /nfs/site/home/mnystroe/work/cm3/bin/cm3 -build -override -DROOT=/nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3 -boot -keep -DM3CC_TARGET=ARMEL_LINUX +++ > --- building in ARMEL_LINUX --- > > ==> /nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3/m3-win/import-libs done > > == package /nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3/m3-libs/m3core == > > +++ /nfs/site/home/mnystroe/work/cm3/bin/cm3 -build -override -DROOT=/nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3 -boot -keep -DM3CC_TARGET=ARMEL_LINUX +++ > --- building in ARMEL_LINUX --- > > > Fatal Error: unrecognized backend mode: C > > *** execution of [] failed *** > > > But if I remove M3_BACKEND_MODE from ARMEL_LINUX and run the same command, the following: > > ... > rm -f /nfs/site/home/mnystroe/work/cm3/bin/cm3cfg.common > rm -f /nfs/site/home/mnystroe/work/cm3/bin/gnuld.common > cp -Pv /nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3/m3-sys/cminstall/src/config-no-install/cm3.cfg /nfs/site/home/mnystroe/work/cm3/bin/cm3.cfg > == package /nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3/m3-win/import-libs == > > +++ /nfs/site/home/mnystroe/work/cm3/bin/cm3 -build -override -DROOT=/nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3 -boot -keep -DM3CC_TARGET=ARMEL_LINUX +++ > --- building in ARMEL_LINUX --- > > ==> /nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3/m3-win/import-libs done > > == package /nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3/m3-libs/m3core == > > +++ /nfs/site/home/mnystroe/work/cm3/bin/cm3 -build -override -DROOT=/nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3 -boot -keep -DM3CC_TARGET=ARMEL_LINUX +++ > --- building in ARMEL_LINUX --- > > > Fatal Error: unrecognized target machine: TARGET = ARMEL_LINUX > > *** execution of [] failed *** > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Mon Oct 14 19:14:08 2013 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Mon, 14 Oct 2013 10:14:08 -0700 Subject: [M3devel] building CM3 on a Raspberry Pi? In-Reply-To: References: <20131013203501.35E651A208F@async.async.caltech.edu> <20131014151924.979A31A208E@async.async.caltech.edu> , <20131014164008.685B81A208E@async.async.caltech.edu> Message-ID: <20131014171408.EB4711A208E@async.async.caltech.edu> upgrade.py , OK... not great. == package /nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3/m3-sys/mklib == +++ /nfs/site/home/mnystroe/work/cm3/bin/cm3 -build -DROOT=/nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3 +++ --- building in AMD64_LINUX --- ignoring ../src/m3overrides new source -> compiling Main.m3 "../src/Main.m3", line 659: incompatible types (b) "../src/Main.m3", line 660: incompatible types (b) "../src/Main.m3", line 661: incompatible types (b) "../src/Main.m3", line 662: incompatible types (b) "../src/Main.m3", line 663: incompatible types (b) "../src/Main.m3", line 664: incompatible types (b) "../src/Main.m3", line 665: incompatible types (b) 7 errors encountered compilation failed => not building program "mklib" Fatal Error: package build failed *** execution of [, ] failed *** (892)tsvnc06:...cm3-anon-cvs/cm3/scripts/python> This is now on a Linux system, figured it's going to be more recent and easier to work with overall: (893)tsvnc06:...cm3-anon-cvs/cm3/scripts/python>gcc -v Reading specs from /nfs/ts/itools/em64t_SLES10/pkgs/gcc/4.7.0/.bin/../lib64/gcc/x86_64-suse-linux/4.7.0/specs COLLECT_GCC=/usr/intel/pkgs/gcc/4.7.0/.bin/gcc COLLECT_LTO_WRAPPER=/nfs/ts/itools/em64t_SLES10/pkgs/gcc/4.7.0/.bin/../libexec/gcc/x86_64-suse-linux/4.7.0/lto-wrapper Target: x86_64-suse-linux Configured with: ./configure --prefix=/usr/intel/pkgs/gcc/4.7.0 --libdir=/usr/intel/pkgs/gcc/4.7.0/lib64 --libexecdir=/usr/intel/pkgs/gcc/4.7.0/libexec --bindir=/usr/intel/pkgs/gcc/4.7.0/bin --with-ppl=/usr/intel/pkgs/gcc/4.7.0 --enable-cloog-backend=ppl --with-cloog=/usr/intel/pkgs/gcc/4.7.0 --with-libelf=/usr/intel/pkgs/gcc/4.7.0 --with-mpfr=/usr/intel/pkgs/gcc/4.7.0 --with-gmp=/usr/intel/pkgs/gcc/4.7.0 --with-mpc=/usr/intel/pkgs/gcc/4.7.0 --enable-lto --enable-languages=c,c++,objc,fortran,java --build=x86_64-suse-linux --host=x86_64-suse-linux --target=x86_64-suse-linux Thread model: posix gcc version 4.7.0 (GCC) The code it's complaining about is: PROCEDURE WriteHeader (nm: TEXT; mode: TEXT; time: Time.T; size: INTEGER) RAISES {Wr.Failure, Thread.Alerted} = TYPE HdrChars = ARRAY [0..BYTESIZE(Header)-1] OF CHAR; VAR hdr: Header; BEGIN StuffT (hdr.Name, nm); (* line 659 *) StuffI (hdr.Date, ROUND (time - CoffTime.EpochAdjust)); StuffT (hdr.UserID, ""); StuffT (hdr.GroupID, ""); StuffT (hdr.Mode, mode); StuffI (hdr.Size, size); StuffT (hdr.EndHeader, EndHeader); Wr.PutString (lib_wr, LOOPHOLE (hdr, HdrChars)); END WriteHeader; where: PROCEDURE StuffT (VAR b: ARRAY OF UINT8; txt: TEXT) = VAR len := Text.Length (txt); BEGIN FOR i := 0 TO MIN (len - 1, LAST (b)) DO b[i] := ORD (Text.GetChar (txt, i)); END; FOR i := len TO LAST (b) DO b[i] := ORD (' '); END; END StuffT; Jay K writes: >--_0e9e017a-7bf6-48f0-afbe-640bab935860_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > Fatal Error: unrecognized backend mode: C > > >Make sure you ./update.py your main toolset first. >Also=2C while the C backend was working a year ago=2C for quite >a while I did not change the builder to know about it directly. >I was going via m3cgcat. >So you need to be fairly current=2C or else modify the >config files a different way=2C and have it be slower. > > > - Jay > > >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] building CM3 on a Raspberry Pi? >> Date: Mon=2C 14 Oct 2013 09:40:08 -0700 >> From: mika at async.caltech.edu >>=20 >> Jay writes: >> >./../gcc-4.7/libiberty/stack-limit.c:52: error: `u_quad_t' undeclared (f= >irst=3D >> > use in this function)if [ x"" !=3D3D x ]=3B then \ >> > >> > >> >Maybe I removed too much. I.e. libquadmath. That should be easy to fix a= >nd/o=3D >> >r switch to C backend. >> > >> > >> >I forgot: besides switching the config file: add the parameter "c" to bo= >ot1.=3D >> >py. >> > >> > >>=20 >> If I put in config-no-install/ARMEL_LINUX >>=20 >> M3_BACKEND_MODE=3D"C" >>=20 >> and run >>=20 >> ./boot1.py c ARMEL_LINUX >>=20 >> the following happens: >>=20 >> ... >> rm -f /nfs/site/home/mnystroe/work/cm3/bin/cm3.cfg >> rm -f /nfs/site/home/mnystroe/work/cm3/bin/cm3cfg.common >> rm -f /nfs/site/home/mnystroe/work/cm3/bin/gnuld.common >> cp -Pv /nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3/m3-sys/cminsta= >ll/src/config-no-install/cm3.cfg /nfs/site/home/mnystroe/work/cm3/bin/cm3.c= >fg >> =3D=3D package /nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3/m3-win= >/import-libs =3D=3D >>=20 >> +++ /nfs/site/home/mnystroe/work/cm3/bin/cm3 -build -override -DROOT= >=3D/nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3 -boot -keep -DM3CC_T= >ARGET=3DARMEL_LINUX +++ >> --- building in ARMEL_LINUX --- >>=20 >> =3D=3D> /nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3/m3-win/impor= >t-libs done >>=20 >> =3D=3D package /nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3/m3-lib= >s/m3core =3D=3D >>=20 >> +++ /nfs/site/home/mnystroe/work/cm3/bin/cm3 -build -override -DROOT= >=3D/nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3 -boot -keep -DM3CC_T= >ARGET=3DARMEL_LINUX +++ >> --- building in ARMEL_LINUX --- >>=20 >>=20 >> Fatal Error: unrecognized backend mode: C >>=20 >> *** execution of [] fail= >ed *** >>=20 >>=20 >> But if I remove M3_BACKEND_MODE from ARMEL_LINUX and run the same command= >=2C the following: >>=20 >> ... >> rm -f /nfs/site/home/mnystroe/work/cm3/bin/cm3cfg.common >> rm -f /nfs/site/home/mnystroe/work/cm3/bin/gnuld.common >> cp -Pv /nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3/m3-sys/cminsta= >ll/src/config-no-install/cm3.cfg /nfs/site/home/mnystroe/work/cm3/bin/cm3.c= >fg >> =3D=3D package /nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3/m3-win= >/import-libs =3D=3D >>=20 >> +++ /nfs/site/home/mnystroe/work/cm3/bin/cm3 -build -override -DROOT= >=3D/nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3 -boot -keep -DM3CC_T= >ARGET=3DARMEL_LINUX +++ >> --- building in ARMEL_LINUX --- >>=20 >> =3D=3D> /nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3/m3-win/impor= >t-libs done >>=20 >> =3D=3D package /nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3/m3-lib= >s/m3core =3D=3D >>=20 >> +++ /nfs/site/home/mnystroe/work/cm3/bin/cm3 -build -override -DROOT= >=3D/nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3 -boot -keep -DM3CC_T= >ARGET=3DARMEL_LINUX +++ >> --- building in ARMEL_LINUX --- >>=20 >>=20 >> Fatal Error: unrecognized target machine: TARGET =3D ARMEL_LINUX >>=20 >> *** execution of [] fail= >ed *** >>=20 >>=20 > = > >--_0e9e017a-7bf6-48f0-afbe-640bab935860_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > >

 >=3B Fatal Error: unreco=
>gnized backend mode: C


Make sure you ./update.py your main tools=
>et first.
Also=2C while the C backend was working a year ago=2C for quit=
>e
a while I did not change the builder to know about it directly.
I w=
>as going via m3cgcat.
So you need to be fairly current=2C or else modify=
> the
config files a different way=2C and have it be slower.


 =
>- Jay

>=3B To: jay.krell at cornell.edu
>=3B CC: = >m3devel at elegosoft.com
>=3B Subject: Re: [M3devel] building CM3 on a Ra= >spberry Pi?
>=3B Date: Mon=2C 14 Oct 2013 09:40:08 -0700
>=3B Fro= >m: mika at async.caltech.edu
>=3B
>=3B Jay writes:
>=3B >=3B= >./../gcc-4.7/libiberty/stack-limit.c:52: error: `u_quad_t' undeclared (firs= >t=3D
>=3B >=3B use in this function)if [ x"" !=3D3D x ]=3B then \>>=3B >=3B
>=3B >=3B
>=3B >=3BMaybe I removed too much. I= >.e. libquadmath. That should be easy to fix and/o=3D
>=3B >=3Br swit= >ch to C backend.
>=3B >=3B
>=3B >=3B
>=3B >=3BI forgot= >: besides switching the config file: add the parameter "c" to boot1.=3D
= >>=3B >=3Bpy.
>=3B >=3B
>=3B >=3B
>=3B
>=3B If = >I put in config-no-install/ARMEL_LINUX
>=3B
>=3B M3_BACKEND_MODE= >=3D"C"
>=3B
>=3B and run
>=3B
>=3B ./boot1.py c ARMEL= >_LINUX
>=3B
>=3B the following happens:
>=3B
>=3B ...= >
>=3B rm -f /nfs/site/home/mnystroe/work/cm3/bin/cm3.cfg
>=3B rm = >-f /nfs/site/home/mnystroe/work/cm3/bin/cm3cfg.common
>=3B rm -f /nfs/= >site/home/mnystroe/work/cm3/bin/gnuld.common
>=3B cp -Pv /nfs/site/dis= >ks/wdisk.133/mnystroe/cm3-anon-cvs/cm3/m3-sys/cminstall/src/config-no-insta= >ll/cm3.cfg /nfs/site/home/mnystroe/work/cm3/bin/cm3.cfg
>=3B =3D=3D pa= >ckage /nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3/m3-win/import-lib= >s =3D=3D
>=3B
>=3B +++ /nfs/site/home/mnystroe/work/cm3/bin/cm3= > -build -override -DROOT=3D/nfs/site/disks/wdisk.133/mnystroe/cm3-anon-c= >vs/cm3 -boot -keep -DM3CC_TARGET=3DARMEL_LINUX +++
>=3B --- building i= >n ARMEL_LINUX ---
>=3B
>=3B =3D=3D>=3B /nfs/site/disks/wdisk.= >133/mnystroe/cm3-anon-cvs/cm3/m3-win/import-libs done
>=3B
>=3B = >=3D=3D package /nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3/m3-libs/= >m3core =3D=3D
>=3B
>=3B +++ /nfs/site/home/mnystroe/work/cm3/bi= >n/cm3 -build -override -DROOT=3D/nfs/site/disks/wdisk.133/mnystroe/cm3-a= >non-cvs/cm3 -boot -keep -DM3CC_TARGET=3DARMEL_LINUX +++
>=3B --- build= >ing in ARMEL_LINUX ---
>=3B
>=3B
>=3B Fatal Error: unrecog= >nized backend mode: C
>=3B
>=3B *** execution of [<=3Bfunctio= >n _BuildLocalFunction at 0x2aaaab5728c0>=3B] failed ***
>=3B
>= >=3B
>=3B But if I remove M3_BACKEND_MODE from ARMEL_LINUX and run the= > same command=2C the following:
>=3B
>=3B ...
>=3B rm -f /n= >fs/site/home/mnystroe/work/cm3/bin/cm3cfg.common
>=3B rm -f /nfs/site/= >home/mnystroe/work/cm3/bin/gnuld.common
>=3B cp -Pv /nfs/site/disks/wd= >isk.133/mnystroe/cm3-anon-cvs/cm3/m3-sys/cminstall/src/config-no-install/cm= >3.cfg /nfs/site/home/mnystroe/work/cm3/bin/cm3.cfg
>=3B =3D=3D package= > /nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3/m3-win/import-libs =3D= >=3D
>=3B
>=3B +++ /nfs/site/home/mnystroe/work/cm3/bin/cm3 -= >build -override -DROOT=3D/nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm= >3 -boot -keep -DM3CC_TARGET=3DARMEL_LINUX +++
>=3B --- building in ARM= >EL_LINUX ---
>=3B
>=3B =3D=3D>=3B /nfs/site/disks/wdisk.133/m= >nystroe/cm3-anon-cvs/cm3/m3-win/import-libs done
>=3B
>=3B =3D= >=3D package /nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3/m3-libs/m3c= >ore =3D=3D
>=3B
>=3B +++ /nfs/site/home/mnystroe/work/cm3/bin/c= >m3 -build -override -DROOT=3D/nfs/site/disks/wdisk.133/mnystroe/cm3-anon= >-cvs/cm3 -boot -keep -DM3CC_TARGET=3DARMEL_LINUX +++
>=3B --- building= > in ARMEL_LINUX ---
>=3B
>=3B
>=3B Fatal Error: unrecogniz= >ed target machine: TARGET =3D ARMEL_LINUX
>=3B
>=3B *** executi= >on of [<=3Bfunction _BuildLocalFunction at 0x2aaaab5728c0>=3B] failed *= >**
>=3B
>=3B

>= > >--_0e9e017a-7bf6-48f0-afbe-640bab935860_-- From jay.krell at cornell.edu Mon Oct 14 19:08:22 2013 From: jay.krell at cornell.edu (Jay K) Date: Mon, 14 Oct 2013 17:08:22 +0000 Subject: [M3devel] building CM3 on a Raspberry Pi? In-Reply-To: References: <20131013203501.35E651A208F@async.async.caltech.edu>, , <20131014151924.979A31A208E@async.async.caltech.edu>, , <20131014164008.685B81A208E@async.async.caltech.edu>, Message-ID: > Fatal Error: unrecognized target machine: TARGET = ARMEL_LINUX Darn. That suggests I didn't get as far as.. update m3-sys/m3middle/src/Target.i3 and Target.m3. The three facts needed are: endian -- it is somewhat automatic, e.g. I386_anything is little endian word size -- will default to 32 unless "64" is in the name jmpbuf size -- an overestimate is ok, or use https://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/scripts/config/jmpbuf.c This is particularly high on the list of things to fix/remove. You might get a few similar errors around the tree. Historically there were target lists in a few places, but I have reduced them significantly, i.e. switching on kernel and processor instead of kernel/processor cross product. The main other piece of code that changes for almost every target is getting the instruction counter out of a context_t for faults (except NetBSD which abstracts it). See https://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/runtime/POSIX/RTSignalC.c But it looks like I already handled Linux/arm. - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] building CM3 on a Raspberry Pi? Date: Mon, 14 Oct 2013 16:59:21 +0000 > Fatal Error: unrecognized backend mode: C Make sure you ./update.py your main toolset first. Also, while the C backend was working a year ago, for quite a while I did not change the builder to know about it directly. I was going via m3cgcat. So you need to be fairly current, or else modify the config files a different way, and have it be slower. - Jay > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] building CM3 on a Raspberry Pi? > Date: Mon, 14 Oct 2013 09:40:08 -0700 > From: mika at async.caltech.edu > > Jay writes: > >./../gcc-4.7/libiberty/stack-limit.c:52: error: `u_quad_t' undeclared (first= > > use in this function)if [ x"" !=3D x ]; then \ > > > > > >Maybe I removed too much. I.e. libquadmath. That should be easy to fix and/o= > >r switch to C backend. > > > > > >I forgot: besides switching the config file: add the parameter "c" to boot1.= > >py. > > > > > > If I put in config-no-install/ARMEL_LINUX > > M3_BACKEND_MODE="C" > > and run > > ./boot1.py c ARMEL_LINUX > > the following happens: > > ... > rm -f /nfs/site/home/mnystroe/work/cm3/bin/cm3.cfg > rm -f /nfs/site/home/mnystroe/work/cm3/bin/cm3cfg.common > rm -f /nfs/site/home/mnystroe/work/cm3/bin/gnuld.common > cp -Pv /nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3/m3-sys/cminstall/src/config-no-install/cm3.cfg /nfs/site/home/mnystroe/work/cm3/bin/cm3.cfg > == package /nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3/m3-win/import-libs == > > +++ /nfs/site/home/mnystroe/work/cm3/bin/cm3 -build -override -DROOT=/nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3 -boot -keep -DM3CC_TARGET=ARMEL_LINUX +++ > --- building in ARMEL_LINUX --- > > ==> /nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3/m3-win/import-libs done > > == package /nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3/m3-libs/m3core == > > +++ /nfs/site/home/mnystroe/work/cm3/bin/cm3 -build -override -DROOT=/nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3 -boot -keep -DM3CC_TARGET=ARMEL_LINUX +++ > --- building in ARMEL_LINUX --- > > > Fatal Error: unrecognized backend mode: C > > *** execution of [] failed *** > > > But if I remove M3_BACKEND_MODE from ARMEL_LINUX and run the same command, the following: > > ... > rm -f /nfs/site/home/mnystroe/work/cm3/bin/cm3cfg.common > rm -f /nfs/site/home/mnystroe/work/cm3/bin/gnuld.common > cp -Pv /nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3/m3-sys/cminstall/src/config-no-install/cm3.cfg /nfs/site/home/mnystroe/work/cm3/bin/cm3.cfg > == package /nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3/m3-win/import-libs == > > +++ /nfs/site/home/mnystroe/work/cm3/bin/cm3 -build -override -DROOT=/nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3 -boot -keep -DM3CC_TARGET=ARMEL_LINUX +++ > --- building in ARMEL_LINUX --- > > ==> /nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3/m3-win/import-libs done > > == package /nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3/m3-libs/m3core == > > +++ /nfs/site/home/mnystroe/work/cm3/bin/cm3 -build -override -DROOT=/nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3 -boot -keep -DM3CC_TARGET=ARMEL_LINUX +++ > --- building in ARMEL_LINUX --- > > > Fatal Error: unrecognized target machine: TARGET = ARMEL_LINUX > > *** execution of [] failed *** > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Oct 14 19:26:59 2013 From: jay.krell at cornell.edu (Jay K) Date: Mon, 14 Oct 2013 17:26:59 +0000 Subject: [M3devel] building CM3 on a Raspberry Pi? In-Reply-To: References: <20131013203501.35E651A208F@async.async.caltech.edu>, , , , <20131014151924.979A31A208E@async.async.caltech.edu>, , , , <20131014164008.685B81A208E@async.async.caltech.edu>, , , Message-ID: Target.i3/m3 look up to date. Is your host toolset very old? https://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3middle/src/Target.i3 Revision 1.59: download - view: text, markup, annotated - select for diffs Sat Jun 19 06:56:32 2010 (3 years, 3 months ago) by jkrell Branches: MAIN Diff to: previous 1.58: preferred, unified Changes since revision 1.58: +2 -0 lines add ARMEL_LINUX with correct jmbuf size/align guessing about alignment "ARM" is an older ABI "ARME" is the usual modern ABI L for little endian scripts/update.py ? - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu Date: Mon, 14 Oct 2013 17:08:22 +0000 CC: m3devel at elegosoft.com Subject: Re: [M3devel] building CM3 on a Raspberry Pi? > Fatal Error: unrecognized target machine: TARGET = ARMEL_LINUX Darn. That suggests I didn't get as far as.. update m3-sys/m3middle/src/Target.i3 and Target.m3. The three facts needed are: endian -- it is somewhat automatic, e.g. I386_anything is little endian word size -- will default to 32 unless "64" is in the name jmpbuf size -- an overestimate is ok, or use https://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/scripts/config/jmpbuf.c This is particularly high on the list of things to fix/remove. You might get a few similar errors around the tree. Historically there were target lists in a few places, but I have reduced them significantly, i.e. switching on kernel and processor instead of kernel/processor cross product. The main other piece of code that changes for almost every target is getting the instruction counter out of a context_t for faults (except NetBSD which abstracts it). See https://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/m3core/src/runtime/POSIX/RTSignalC.c But it looks like I already handled Linux/arm. - Jay From: jay.krell at cornell.edu To: mika at async.caltech.edu CC: m3devel at elegosoft.com Subject: RE: [M3devel] building CM3 on a Raspberry Pi? Date: Mon, 14 Oct 2013 16:59:21 +0000 > Fatal Error: unrecognized backend mode: C Make sure you ./update.py your main toolset first. Also, while the C backend was working a year ago, for quite a while I did not change the builder to know about it directly. I was going via m3cgcat. So you need to be fairly current, or else modify the config files a different way, and have it be slower. - Jay > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] building CM3 on a Raspberry Pi? > Date: Mon, 14 Oct 2013 09:40:08 -0700 > From: mika at async.caltech.edu > > Jay writes: > >./../gcc-4.7/libiberty/stack-limit.c:52: error: `u_quad_t' undeclared (first= > > use in this function)if [ x"" !=3D x ]; then \ > > > > > >Maybe I removed too much. I.e. libquadmath. That should be easy to fix and/o= > >r switch to C backend. > > > > > >I forgot: besides switching the config file: add the parameter "c" to boot1.= > >py. > > > > > > If I put in config-no-install/ARMEL_LINUX > > M3_BACKEND_MODE="C" > > and run > > ./boot1.py c ARMEL_LINUX > > the following happens: > > ... > rm -f /nfs/site/home/mnystroe/work/cm3/bin/cm3.cfg > rm -f /nfs/site/home/mnystroe/work/cm3/bin/cm3cfg.common > rm -f /nfs/site/home/mnystroe/work/cm3/bin/gnuld.common > cp -Pv /nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3/m3-sys/cminstall/src/config-no-install/cm3.cfg /nfs/site/home/mnystroe/work/cm3/bin/cm3.cfg > == package /nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3/m3-win/import-libs == > > +++ /nfs/site/home/mnystroe/work/cm3/bin/cm3 -build -override -DROOT=/nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3 -boot -keep -DM3CC_TARGET=ARMEL_LINUX +++ > --- building in ARMEL_LINUX --- > > ==> /nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3/m3-win/import-libs done > > == package /nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3/m3-libs/m3core == > > +++ /nfs/site/home/mnystroe/work/cm3/bin/cm3 -build -override -DROOT=/nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3 -boot -keep -DM3CC_TARGET=ARMEL_LINUX +++ > --- building in ARMEL_LINUX --- > > > Fatal Error: unrecognized backend mode: C > > *** execution of [] failed *** > > > But if I remove M3_BACKEND_MODE from ARMEL_LINUX and run the same command, the following: > > ... > rm -f /nfs/site/home/mnystroe/work/cm3/bin/cm3cfg.common > rm -f /nfs/site/home/mnystroe/work/cm3/bin/gnuld.common > cp -Pv /nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3/m3-sys/cminstall/src/config-no-install/cm3.cfg /nfs/site/home/mnystroe/work/cm3/bin/cm3.cfg > == package /nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3/m3-win/import-libs == > > +++ /nfs/site/home/mnystroe/work/cm3/bin/cm3 -build -override -DROOT=/nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3 -boot -keep -DM3CC_TARGET=ARMEL_LINUX +++ > --- building in ARMEL_LINUX --- > > ==> /nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3/m3-win/import-libs done > > == package /nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3/m3-libs/m3core == > > +++ /nfs/site/home/mnystroe/work/cm3/bin/cm3 -build -override -DROOT=/nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3 -boot -keep -DM3CC_TARGET=ARMEL_LINUX +++ > --- building in ARMEL_LINUX --- > > > Fatal Error: unrecognized target machine: TARGET = ARMEL_LINUX > > *** execution of [] failed *** > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Oct 14 18:11:11 2013 From: jay.krell at cornell.edu (Jay) Date: Mon, 14 Oct 2013 09:11:11 -0700 Subject: [M3devel] building CM3 on a Raspberry Pi? In-Reply-To: <20131014160134.4D0B61A208E@async.async.caltech.edu> References: <20131013203501.35E651A208F@async.async.caltech.edu> <20131014160134.4D0B61A208E@async.async.caltech.edu> Message-ID: <780D5BF8-8E95-4E43-8B6C-8FBABD305301@gmail.com> Right: add "c" to boot1.py command line. - Jay On Oct 14, 2013, at 9:01 AM, wrote: > > [sorry for sending so many small messages..] > > I get the same error about c-family/c-pragma.h if I add > > M3_BACKEND_MODE = "C" > > to the bottom of the ARMEL_LINUX config in config-no-install and re-run boot1.py ... > > Jay K writes: >> --_dddec029-8cf2-4528-8c46-8d0a40bef349_ >> Content-Type: text/plain; charset="iso-8859-1" >> Content-Transfer-Encoding: quoted-printable >> >> Porting to new systems is pretty easy. =20 >> I had ARMEL_LINUX pretty far along. =20 >> I forgot how far. =20 >> I did have to add sort of support for 128bit integers in the gcc backend.= >> Sort of. =20 >> =20 >> >>> ../gcc-4.7/configure: not found=20 >> >> =20 >> Make sure you cvs upd -dAP so you get new directories.=20 >> >> =20 >> We should switch to the C backend though. It is just a one line change =20 >> in the config file. Look at the Darwin config files. =20 >> It is not experimental. =20 >> It has been essentially working for over a year (since September 2012)=20 >> and it is in very good shape now.=20 >> I have used it for a number of architectures and operating systems alread= >> y=2C=20 >> like I think every Solaris architecture=2C Linux=2C Darwin=2C NT.=20 >> I'd like to see more people use it=2C and I'd like to drop the gcc backen= >> d entirely.=20 >> This is an important step in leaving Modula-3 very portable and easier to= >> support.=20 >> =20 >> >> - Jay >> >> =20 >>> To: m3devel at elegosoft.com >>> Date: Sun=2C 13 Oct 2013 13:35:01 -0700 >>> From: mika at async.caltech.edu >>> Subject: [M3devel] building CM3 on a Raspberry Pi? >>> =20 >>> =20 >>> Hi everyone (mostly Jay)=2C >>> =20 >>> Last time I tried to port CM3 to a new architecture I really got nowhere. >>> =20 >>> I thought it might be time to try again. I have a Raspberry Pi=2C forty-= >> dollar computer. >>> =20 >>> It has "Raspbian" installed on it. >>> =20 >>> The following output is probably relevant: >>> =20 >>> pi at raspberrypi ~ $ uname -a >>> Linux raspberrypi 3.6.11+ #538 PREEMPT Fri Aug 30 20:42:08 BST 2013 armv6= >> l GNU/Linux >>> =20 >>> pi at raspberrypi ~ $ gcc -v >>> Using built-in specs. >>> COLLECT_GCC=3Dgcc >>> COLLECT_LTO_WRAPPER=3D/usr/lib/gcc/arm-linux-gnueabihf/4.6/lto-wrapper >>> Target: arm-linux-gnueabihf >>> Configured with: ../src/configure -v --with-pkgversion=3D'Debian 4.6.3-14= >> +rpi1' --with-bugurl=3Dfile:///usr/share/doc/gcc-4.6/README.Bugs --enable-l= >> anguages=3Dc=2Cc++=2Cfortran=2Cobjc=2Cobj-c++ --prefix=3D/usr --program-suf= >> fix=3D-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --li= >> bexecdir=3D/usr/lib --without-included-gettext --enable-threads=3Dposix --w= >> ith-gxx-include-dir=3D/usr/include/c++/4.6 --libdir=3D/usr/lib --enable-nls= >> --with-sysroot=3D/ --enable-clocale=3Dgnu --enable-libstdcxx-debug --enabl= >> e-libstdcxx-time=3Dyes --enable-gnu-unique-object --enable-plugin --enable-= >> objc-gc --disable-sjlj-exceptions --with-arch=3Darmv6 --with-fpu=3Dvfp --wi= >> th-float=3Dhard --enable-checking=3Drelease --build=3Darm-linux-gnueabihf -= >> -host=3Darm-linux-gnueabihf --target=3Darm-linux-gnueabihf >>> Thread model: posix >>> gcc version 4.6.3 (Debian 4.6.3-14+rpi1)=20 >>> =20 >>> =20 >>> Further=2C in the CM3 tree there is something called "ARMEL_LINUX". >>> I thought=2C from reading some old messages on this mailing list=2C that = >> doing >>> the following on my "big" system would result in something interesting: >>> =20 >>> 1. CVS updating to the latest version of the tree >>> =20 >>> 2. cd to scripts/python >>> =20 >>> 3. ./boot1.py ARMEL_LINUX >>> =20 >>> but all it did was mess up the cm3.cfg on my host system (FreeBSD4) and e= >> rror out very quickly... >>> =20 >>> ... >>> rm -f /usr/local/cm3/bin/IA64_LINUX >>> rm -f /usr/local/cm3/bin/NT.common >>> rm -f /usr/local/cm3/bin/SPARC32_SOLARIS.common >>> cp -Pv /big/home2/mika/2/cm3-cvs/cm3/m3-sys/cminstall/src/config-no-insta= >> ll/cm3.cfg /usr/local/cm3/bin/cm3.cfg >>> =3D=3D package /big/home2/mika/2/cm3-cvs/cm3/m3-win/import-libs =3D=3D >>> =20 >>> +++ /usr/local/cm3/bin/cm3 -build -override -DROOT=3D/big/home2/mika/= >> 2/cm3-cvs/cm3 -boot -keep -DM3CC_TARGET=3DARMEL_LINUX +++ >>> --- building in ARMEL_LINUX --- >>> =20 >>> =3D=3D> /big/home2/mika/2/cm3-cvs/cm3/m3-win/import-libs done >>> =20 >>> =3D=3D package /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc =3D=3D >>> =20 >>> +++ /usr/local/cm3/bin/cm3 -build -override -DROOT=3D/big/home2/mika/= >> 2/cm3-cvs/cm3 -boot -keep -DM3CC_TARGET=3DARMEL_LINUX +++ >>> --- building in ARMEL_LINUX --- >>> =20 >>> type make >>> make is /home/mika/cm3-build-bin//make >>> make --version | grep "GNU Make" >>> GNU Make 3.82 >>> GNU_MAKE is make >>> cd ../FreeBSD4-ARMEL_LINUX && MAKE=3D"make -j4 " AUTOCONF=3D: AUTOMAK= >> E=3D: LEX=3D'touch lex.yy.c' MAKEINFO=3D: ../gcc-4.7/configure -with-sy= >> sroot -target=3Darm-linux-gnueabi -srcdir=3D../gcc-4.7 -disable-bootstrap -= >> disable-intl -disable-libgomp -disable-libmudflap -disable-libssp -disable-= >> nls -enable-languages=3Dm3cg -disable-fixincludes -disable-libgcc -disable-= >> decimal-float -disable-fixed-point -disable-tls >>> cd ../FreeBSD4-ARMEL_LINUX && MAKE=3D"make -j4 " AUTOCONF=3D: AUTOMAK= >> E=3D: LEX=3D'touch lex.yy.c' MAKEINFO=3D: ../gcc-4.7/configure -with-sy= >> sroot -target=3Darm-linux-gnueabi -srcdir=3D../gcc-4.7 -disable-bootstrap -= >> disable-intl -disable-libgomp -disable-libmudflap -disable-libssp -disable-= >> nls -enable-languages=3Dm3cg -disable-fixincludes -disable-libgcc -disable-= >> decimal-float -disable-fixed-point -disable-tls >>> ../gcc-4.7/configure: not found >>> "/big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/m3makefile"=2C line 339: q= >> uake runtime error: exit 127: cd ../FreeBSD4-ARMEL_LINUX && MAKE=3D"make = >> -j4 " AUTOCONF=3D: AUTOMAKE=3D: LEX=3D'touch lex.yy.c' MAKEINFO=3D: ../gc= >> c-4.7/configure -with-sysroot -target=3Darm-linux-gnueabi -srcdir=3D../= >> gcc-4.7 -disable-bootstrap -disable-intl -disable-libgomp -disable-libmudfl= >> ap -disable-libssp -disable-nls -enable-languages=3Dm3cg -disable-fixinclud= >> es -disable-libgcc -disable-decimal-float -disable-fixed-point -disable-tls >>> =20 >>> --procedure-- -line- -file--- >>> exec -- >>> m3cc_Run 339 /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/m3ma= >> kefile >>> include_dir 537 /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/m3ma= >> kefile >>> 9 /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/ARMEL_LI= >> NUX/m3make.args >>> =20 >>> Fatal Error: package build failed >>> *** execution of [] failed **= >> * >>> (238)rover:~/cm3-cvs-anon/cm3/scripts/python> >>> =20 >>> =20 >>> So I'm not really sure what state porting of CM3 is in. I think it >>> would be really interesting to have it running on the Raspberry Pi=2C >>> partly because Modula-3 and Python are in many ways similar but Modula-3 >>> code tends to be many times more efficient (at least in runtime) and >>> the computer is slow by modern standards. >>> =20 >>> A few questions... >>> =20 >>> Is ARMEL_LINUX a real port? Does it work? Has it worked for anyone? =20 >>> =20 >>> Am I going about it the right way per latest recommendations---that is=2C >>> trying to cross-compile from an existing CM3 installation on 32-bit >>> i386 system? >>> =20 >>> Clearly just running ./boot1.py ARMEL_LINUX on the FreeBSD system is >>> not the right approach... maybe someone knows what is? >>> =20 >>> Do I maybe need to upgrade the host CM3 to the head first? (Sounds >>> like a whole other can of worms but ok...) >>> =20 >>> The Pi I think is more than powerful enough to compile everything >>> natively. When I started with Modula-3=2C I had a 120-MHz Pentium on >>> my desk with 128 MB of RAM=2C and that was considered a powerful >>> system at the time. This is a 700 MHz ARM with 512 MB of RAM. >>> So I'm not against compiling stuff natively (in fact I think it makes >>> things easier)=2C but cross-compiling is fine too if that gets me to >>> the goal easier. >>> =20 >>> I am happy to try C generating compilers but I would prefer to keep >>> things as un-experimental as possible for now=2C because I have some >>> control applications I'd like to try to build without having to debug >>> lots and lots of software first. >>> =20 >>> Finally I think it would be *really* cool if we had a distribution of >>> Modula-3 that was polished enough to be distributable to Raspberry Pi >>> users. Just based on the gross characteristics of the two systems=2C >>> I think the Pi and Modula-3 ought to be a very good match for each >>> other. Basically=2C the Pi is a full-featured but slow hardware system >>> with good networking facilities. It could use a safe=2C modern=2C effici= >> ent >>> systems programming language running on it. Most things on it nowadays >>> are written in Python from what i understand. >>> =20 >>> Mika >> = >> >> --_dddec029-8cf2-4528-8c46-8d0a40bef349_ >> Content-Type: text/html; charset="iso-8859-1" >> Content-Transfer-Encoding: quoted-printable >> >> >> >> >>

=3B Porting to new systems = >> is pretty easy. =3B
=3B I had ARMEL_LINUX pretty far along.&nb= >> sp=3B
=3B I forgot how far. =3B
=3B =3BI did have= >> to =3Badd sort of support for 128bit integers in the =3Bgcc backen= >> d. Sort of. =3B
=3B

=3B>=3B ../gcc-4.7/configure= >> : not found

=3B
=3B Make sure you cvs upd -dAP so you = >> get new directories.

=3B
=3B We should switch to the C= >> backend though. It is just a one line change =3B
=3B =3B = >> in the config file. Look at the Darwin config files. =3B
=3B I= >> t is not experimental. =3B
=3B It has been essentially working= >> for over a year (since September 2012)
=3B =3B and it is in v= >> ery good shape now.
=3B I have used it for a number of architectur= >> es and operating systems already=2C
=3B like I think every Solaris= >> architecture=2C Linux=2C Darwin=2C NT.
=3B I'd like to see more p= >> eople use it=2C and I'd like to drop the gcc backend entirely.
=3B= >> This is an important step in leaving Modula-3 very portable and easier to = >> support.
=3B

=3B- Jay

=3B

>=3B T= >> o: m3devel at elegosoft.com
>=3B Date: Sun=2C 13 Oct 2013 13:35:01 -0700<= >> br>>=3B From: mika at async.caltech.edu
>=3B Subject: [M3devel] buildin= >> g CM3 on a Raspberry Pi?
>=3B
>=3B
>=3B Hi everyone (mostl= >> y Jay)=2C
>=3B
>=3B Last time I tried to port CM3 to a new archi= >> tecture I really got nowhere.
>=3B
>=3B I thought it might be ti= >> me to try again. I have a Raspberry Pi=2C forty-dollar computer.
>=3B= >>
>=3B It has "Raspbian" installed on it.
>=3B
>=3B The fol= >> lowing output is probably relevant:
>=3B
>=3B pi at raspberrypi ~ $= >> uname -a
>=3B Linux raspberrypi 3.6.11+ #538 PREEMPT Fri Aug 30 20:42= >> :08 BST 2013 armv6l GNU/Linux
>=3B
>=3B pi at raspberrypi ~ $ gcc -= >> v
>=3B Using built-in specs.
>=3B COLLECT_GCC=3Dgcc
>=3B COL= >> LECT_LTO_WRAPPER=3D/usr/lib/gcc/arm-linux-gnueabihf/4.6/lto-wrapper
>= >> =3B Target: arm-linux-gnueabihf
>=3B Configured with: ../src/configure= >> -v --with-pkgversion=3D'Debian 4.6.3-14+rpi1' --with-bugurl=3Dfile:///usr/= >> share/doc/gcc-4.6/README.Bugs --enable-languages=3Dc=2Cc++=2Cfortran=2Cobjc= >> =2Cobj-c++ --prefix=3D/usr --program-suffix=3D-4.6 --enable-shared --enable= >> -linker-build-id --with-system-zlib --libexecdir=3D/usr/lib --without-inclu= >> ded-gettext --enable-threads=3Dposix --with-gxx-include-dir=3D/usr/include/= >> c++/4.6 --libdir=3D/usr/lib --enable-nls --with-sysroot=3D/ --enable-clocal= >> e=3Dgnu --enable-libstdcxx-debug --enable-libstdcxx-time=3Dyes --enable-gnu= >> -unique-object --enable-plugin --enable-objc-gc --disable-sjlj-exceptions -= >> -with-arch=3Darmv6 --with-fpu=3Dvfp --with-float=3Dhard --enable-checking= >> =3Drelease --build=3Darm-linux-gnueabihf --host=3Darm-linux-gnueabihf --tar= >> get=3Darm-linux-gnueabihf
>=3B Thread model: posix
>=3B gcc versi= >> on 4.6.3 (Debian 4.6.3-14+rpi1)
>=3B
>=3B
>=3B Further=2C= >> in the CM3 tree there is something called "ARMEL_LINUX".
>=3B I thoug= >> ht=2C from reading some old messages on this mailing list=2C that doing
= >> >=3B the following on my "big" system would result in something interesti= >> ng:
>=3B
>=3B 1. CVS updating to the latest version of the tree<= >> br>>=3B
>=3B 2. cd to scripts/python
>=3B
>=3B 3. ./boot= >> 1.py ARMEL_LINUX
>=3B
>=3B but all it did was mess up the cm3.cf= >> g on my host system (FreeBSD4) and error out very quickly...
>=3B
= >> >=3B ...
>=3B rm -f /usr/local/cm3/bin/IA64_LINUX
>=3B rm -f /u= >> sr/local/cm3/bin/NT.common
>=3B rm -f /usr/local/cm3/bin/SPARC32_SOLAR= >> IS.common
>=3B cp -Pv /big/home2/mika/2/cm3-cvs/cm3/m3-sys/cminstall/s= >> rc/config-no-install/cm3.cfg /usr/local/cm3/bin/cm3.cfg
>=3B =3D=3D pa= >> ckage /big/home2/mika/2/cm3-cvs/cm3/m3-win/import-libs =3D=3D
>=3B >> >=3B +++ /usr/local/cm3/bin/cm3 -build -override -DROOT=3D/big/home2= >> /mika/2/cm3-cvs/cm3 -boot -keep -DM3CC_TARGET=3DARMEL_LINUX +++
>=3B -= >> -- building in ARMEL_LINUX ---
>=3B
>=3B =3D=3D>=3B /big/home= >> 2/mika/2/cm3-cvs/cm3/m3-win/import-libs done
>=3B
>=3B =3D=3D pa= >> ckage /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc =3D=3D
>=3B
>=3B= >> +++ /usr/local/cm3/bin/cm3 -build -override -DROOT=3D/big/home2/mika/2= >> /cm3-cvs/cm3 -boot -keep -DM3CC_TARGET=3DARMEL_LINUX +++
>=3B --- buil= >> ding in ARMEL_LINUX ---
>=3B
>=3B type make
>=3B make is /h= >> ome/mika/cm3-build-bin//make
>=3B make --version | grep "GNU Make"
= >> >=3B GNU Make 3.82
>=3B GNU_MAKE is make
>=3B cd ../FreeBSD4-AR= >> MEL_LINUX &=3B&=3B MAKE=3D"make -j4 " AUTOCONF=3D: AUTOMAKE=3D: L= >> EX=3D'touch lex.yy.c' MAKEINFO=3D: ../gcc-4.7/configure -with-sysroot -= >> target=3Darm-linux-gnueabi -srcdir=3D../gcc-4.7 -disable-bootstrap -disable= >> -intl -disable-libgomp -disable-libmudflap -disable-libssp -disable-nls -en= >> able-languages=3Dm3cg -disable-fixincludes -disable-libgcc -disable-decimal= >> -float -disable-fixed-point -disable-tls
>=3B cd ../FreeBSD4-ARMEL_LIN= >> UX &=3B&=3B MAKE=3D"make -j4 " AUTOCONF=3D: AUTOMAKE=3D: LEX=3D't= >> ouch lex.yy.c' MAKEINFO=3D: ../gcc-4.7/configure -with-sysroot -target= >> =3Darm-linux-gnueabi -srcdir=3D../gcc-4.7 -disable-bootstrap -disable-intl = >> -disable-libgomp -disable-libmudflap -disable-libssp -disable-nls -enable-l= >> anguages=3Dm3cg -disable-fixincludes -disable-libgcc -disable-decimal-float= >> -disable-fixed-point -disable-tls
>=3B ../gcc-4.7/configure: not foun= >> d
>=3B "/big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/m3makefile"=2C l= >> ine 339: quake runtime error: exit 127: cd ../FreeBSD4-ARMEL_LINUX &=3B&= >> amp=3B MAKE=3D"make -j4 " AUTOCONF=3D: AUTOMAKE=3D: LEX=3D'touch lex.yy= >> .c' MAKEINFO=3D: ../gcc-4.7/configure -with-sysroot -target=3Darm-linux= >> -gnueabi -srcdir=3D../gcc-4.7 -disable-bootstrap -disable-intl -disable-lib= >> gomp -disable-libmudflap -disable-libssp -disable-nls -enable-languages=3Dm= >> 3cg -disable-fixincludes -disable-libgcc -disable-decimal-float -disable-fi= >> xed-point -disable-tls
>=3B
>=3B --procedure-- -line- -file---= >>
>=3B exec -- <=3Bbuiltin>=3B
>=3B m3cc_Run = >> 339 /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/m3makefile
>= >> =3B include_dir 537 /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/m3= >> makefile
>=3B 9 /big/home2/mika/2/cm3-cvs/cm3/m3-= >> sys/m3cc/ARMEL_LINUX/m3make.args
>=3B
>=3B Fatal Error: package = >> build failed
>=3B *** execution of [<=3Bfunction _BuildLocalFunctio= >> n at 0x82d55a4>=3B] failed ***
>=3B (238)rover:~/cm3-cvs-anon/cm3/sc= >> ripts/python>=3B
>=3B
>=3B
>=3B So I'm not really sure w= >> hat state porting of CM3 is in. I think it
>=3B would be really inter= >> esting to have it running on the Raspberry Pi=2C
>=3B partly because M= >> odula-3 and Python are in many ways similar but Modula-3
>=3B code ten= >> ds to be many times more efficient (at least in runtime) and
>=3B the = >> computer is slow by modern standards.
>=3B
>=3B A few questions.= >> ..
>=3B
>=3B Is ARMEL_LINUX a real port? Does it work? Has it = >> worked for anyone?
>=3B
>=3B Am I going about it the right way= >> per latest recommendations---that is=2C
>=3B trying to cross-compile = >> from an existing CM3 installation on 32-bit
>=3B i386 system?
>= >> =3B
>=3B Clearly just running ./boot1.py ARMEL_LINUX on the FreeBSD s= >> ystem is
>=3B not the right approach... maybe someone knows what is?> r>>=3B
>=3B Do I maybe need to upgrade the host CM3 to the head fir= >> st? (Sounds
>=3B like a whole other can of worms but ok...)
>=3B= >>
>=3B The Pi I think is more than powerful enough to compile everythi= >> ng
>=3B natively. When I started with Modula-3=2C I had a 120-MHz Pen= >> tium on
>=3B my desk with 128 MB of RAM=2C and that was considered a p= >> owerful
>=3B system at the time. This is a 700 MHz ARM with 512 MB of= >> RAM.
>=3B So I'm not against compiling stuff natively (in fact I thin= >> k it makes
>=3B things easier)=2C but cross-compiling is fine too if t= >> hat gets me to
>=3B the goal easier.
>=3B
>=3B I am happy t= >> o try C generating compilers but I would prefer to keep
>=3B things as= >> un-experimental as possible for now=2C because I have some
>=3B contr= >> ol applications I'd like to try to build without having to debug
>=3B = >> lots and lots of software first.
>=3B
>=3B Finally I think it wo= >> uld be *really* cool if we had a distribution of
>=3B Modula-3 that wa= >> s polished enough to be distributable to Raspberry Pi
>=3B users. Jus= >> t based on the gross characteristics of the two systems=2C
>=3B I thin= >> k the Pi and Modula-3 ought to be a very good match for each
>=3B othe= >> r. Basically=2C the Pi is a full-featured but slow hardware system
>= >> =3B with good networking facilities. It could use a safe=2C modern=2C effi= >> cient
>=3B systems programming language running on it. Most things on= >> it nowadays
>=3B are written in Python from what i understand.
>= >> =3B
>=3B Mika

>> = >> >> --_dddec029-8cf2-4528-8c46-8d0a40bef349_-- From jay.krell at cornell.edu Mon Oct 14 18:09:44 2013 From: jay.krell at cornell.edu (Jay) Date: Mon, 14 Oct 2013 09:09:44 -0700 Subject: [M3devel] building CM3 on a Raspberry Pi? In-Reply-To: References: <20131013203501.35E651A208F@async.async.caltech.edu> <20131014151924.979A31A208E@async.async.caltech.edu> Message-ID: <6041F554-8B87-4DB3-BED1-0E2B585D4AA8@gmail.com> Another thing you can try is from the history, figure out which gcc version I was using when I added Armel/Linux. Or just try older. See m3-sys/m3cc/m3makefile. It is meant to support a few versions. - Jay On Oct 14, 2013, at 9:07 AM, Jay wrote: > ./../gcc-4.7/libiberty/stack-limit.c:52: error: `u_quad_t' undeclared (first use in this function)if [ x"" != x ]; then \ > > > Maybe I removed too much. I.e. libquadmath. That should be easy to fix and/or switch to C backend. > > > I forgot: besides switching the config file: add the parameter "c" to boot1.py. > > > I'll *try* to build a bootstrap archive with cm3cg or C this week. > > > Cm3.cfg: yes it might do that. I can see about using a separate file but no promises there. A flaw perhaps in some of my earlier thinking was over eagerness in when the config files get updated. The older config files were in general very flawed IMHO. But maybe good to leave them alone in early bootstrap, if they worked. But I really had a lot of problems with them. The current ones don't require cminstall, have less version/target-specific code, have far less duplication, and are meant to work with older cm3 (albeit maybe give up on dynamic linking with older versions). > > > - Jay > > On Oct 14, 2013, at 8:19 AM, wrote: > >> >> OK, with the new cvs update, this happens: >> >> gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gcc-4.7/libiberty/../include -W -Wall -Wwrite-strings -Wstrict-prototypes -pedantic ../../gcc-4.7/libiberty/strerror.c -o strerror.o >> ../../gcc-4.7/libiberty/stack-limit.c: In function `stack_limit_increase': >> ../../gcc-4.7/libiberty/stack-limit.c:52: error: `u_quad_t' undeclared (first use in this function)if [ x"" != x ]; then \ >> >> gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gcc-4.7/libiberty/../include -W -Wall -Wwrite-strings -Wstrict-prototypes -pedantic ../../gcc-4.7/libiberty/strsignal.c -o pic/strsignal.o; \ >> ../../gcc-4.7/libiberty/stack-limit.c:52: error: (Each undeclared identifier is reported only oncechecking for string.h... else true; fi >> >> ../../gcc-4.7/libiberty/stack-limit.c:52: error: for each function it appears in.) >> gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gcc-4.7/libiberty/../include -W -Wall -Wwrite-strings -Wstrict-prototypes -pedantic ../../gcc-4.7/libiberty/strsignal.c -o strsignal.o >> ../../gcc-4.7/libiberty/stack-limit.c:52: error: syntax error before numeric constant >> if [ x"" != x ]; then \ >> ../../gcc-4.7/libiberty/stack-limit.c:54: error: syntax error before numeric constant >> ../../gcc-4.7/libiberty/stack-limit.c:57: error: syntax error before numeric constant >> gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gcc-4.7/libiberty/../include -W -Wall -Wwrite-strings -Wstrict-prototypes -pedantic ../../gcc-4.7/libiberty/timeval-utils.c -o pic/timeval-utils.o; \ >> else true; fi >> gmake[1]: *** [stack-limit.o] Error 1 >> gmake[1]: *** Waiting for unfinished jobs.... >> gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gcc-4.7/libiberty/../include -W -Wall -Wwrite-strings -Wstrict-prototypes -pedantic ../../gcc-4.7/libiberty/timeval-utils.c -o timeval-utils.o >> yes >> gmake[1]: Leaving directory `/big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/FreeBSD4-ARMEL_LINUX/libiberty' >> gmake: *** [all-libiberty] Error 2 >> gmake: *** Waiting for unfinished jobs.... >> checking for memory.h... yes >> checking for strings.h... yes >> checking for inttypes.h... yes >> checking for stdint.h... yes >> checking for unistd.h... yes >> >> [ more config output ] >> >> checking for getpagesize... (cached) yes >> checking for working mmap... yes >> checking for working strncmp... yes >> configure: updating cache ../config.cache >> configure: creating ./config.status >> config.status: creating Makefile >> config.status: creating testsuite/Makefile >> config.status: creating config.h >> config.status: executing default commands >> "/big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/m3makefile", line 339: quake runtime error: exit 2: cd ../FreeBSD4-ARMEL_LINUX && gmake MAKE="gmake -j4 " AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: -j4 all-build-libiberty all-libiberty >> >> --procedure-- -line- -file--- >> exec -- >> m3cc_Run 339 /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/m3makefile >> include_dir 580 /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/src/m3makefile >> 9 /big/home2/mika/2/cm3-cvs/cm3/m3-sys/m3cc/ARMEL_LINUX/m3make.args >> >> Fatal Error: package build failed >> *** execution of [] failed *** >> (129)rover:~/cm3-cvs-anon/cm3/scripts/python> >> From mika at async.caltech.edu Mon Oct 14 20:53:02 2013 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Mon, 14 Oct 2013 11:53:02 -0700 Subject: [M3devel] building CM3 on a Raspberry Pi? In-Reply-To: References: <20131013203501.35E651A208F@async.async.caltech.edu>, , , , <20131014151924.979A31A208E@async.async.caltech.edu>, , , , <20131014164008.685B81A208E@async.async.caltech.edu>, , ,

Message-ID: <20131014185302.4952B1A208E@async.async.caltech.edu> My toolsets are old, yes. I tried upgrade.py but you saw that that didn't work either. I guess I could go back and re-install from a recent binary image (where are the most recent ones? I only see really old ones on elegosoft...) and build everything from scratch. It's just that all the systems that I have M3 on are some sort of production systems and I don't want to mess up the installations unnecessarily... but if it's the only way... Mika Jay K writes: >--_461a9835-225f-448d-96a6-4c651ff66c13_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >Target.i3/m3 look up to date. >Is your host toolset very old? > >https://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3middle/src/Ta= >rget.i3 > >Revision 1.59: download - view: text=2C markup=2C annotated - select for di= >ffs >=0A= >Sat Jun 19 06:56:32 2010 (3 years=2C 3 months ago) by jkrell >=0A= >Branches: MAIN >=0A= >Diff to: previous 1.58: preferred=2C unified >=0A= >Changes since revision 1.58: +2 -0 lines >=0A= >add ARMEL_LINUX with correct jmbuf size/align=0A= >guessing about alignment=0A= >"ARM" is an older ABI=0A= >"ARME" is the usual modern ABI=0A= >L for little endian=0A= > >scripts/update.py ? > > - Jay From mika at async.caltech.edu Mon Oct 14 20:58:31 2013 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Mon, 14 Oct 2013 11:58:31 -0700 Subject: [M3devel] mklib in upgrade.py ... Message-ID: <20131014185831.9AD871A208E@async.async.caltech.edu> And now I see that mklib talks a lot about WinNT. I suspect I have no use for it??? I took it out of upgrade.py since it doesn't compile and breaks the upgrade procedure... perhaps there should be a test somewhere to ensure it won't get compiled on non-Windows systems? Or fix it so it does compile.. Mika From mika at async.caltech.edu Mon Oct 14 21:02:52 2013 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Mon, 14 Oct 2013 12:02:52 -0700 Subject: [M3devel] building CM3 on a Raspberry Pi? In-Reply-To: <20131014185302.4952B1A208E@async.async.caltech.edu> References: <20131013203501.35E651A208F@async.async.caltech.edu>, , , , <20131014151924.979A31A208E@async.async.caltech.edu>, , , , <20131014164008.685B81A208E@async.async.caltech.edu>, , ,

<20131014185302.4952B1A208E@async.async.caltech.edu> Message-ID: <20131014190252.147321A208E@async.async.caltech.edu> More updates... after I remove mklib, I do get a new compiler built, and I get to this point ignoring ../src/m3overrides ==> /nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3/m3-win/import-libs done +++ /nfs/site/home/mnystroe/work/cm3/bin/cm3 -ship -DROOT=/nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3 +++ --- shipping from AMD64_LINUX --- ==> /nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3/m3-win/import-libs done == package /nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3/m3-libs/m3core == +++ /nfs/site/home/mnystroe/work/cm3/bin/cm3 -build -DROOT=/nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3 +++ --- building in AMD64_LINUX --- ignoring ../src/m3overrides new source -> compiling RTHooks.i3 ../src/runtime/common/RTHooks.i3:15: fatal error: *** illegal type: 0x6f, at m3cg_lineno 5 compilation terminated. m3_backend => 1 m3cc (aka cm3cg) failed compiling: RTHooks.ic Assembler messages: Can't open RTHooks.is for reading: No such file or directory new source -> compiling RT0.i3 ../src/runtime/common/RT0.i3:19: fatal error: *** illegal type: 0x6f, at m3cg_lineno 5 compilation terminated. m3_backend => 1 m3cc (aka cm3cg) failed compiling: RT0.ic Assembler messages: Can't open RT0.is for reading: No such file or directory new source -> compiling RuntimeError.i3 ../src/runtime/common/RuntimeError.i3:10: fatal error: *** illegal type: 0x6f, at m3cg_lineno 5 compilation terminated. m3_backend => 1 m3cc (aka cm3cg) failed compiling: RuntimeError.ic Assembler messages: Can't open RuntimeError.is for reading: No such file or directory new source -> compiling WordRep.i3 ../src/word/WordRep.i3:1: fatal error: *** illegal type: 0x6f, at m3cg_lineno 5 I've seen this before but don't remember what the issue is. The compiler is new: -rwxr-x--- 1 mnystroe rrc 9916732 2013-10-14 11:59 /nfs/site/home/mnystroe/work/cm3/bin/cm3 This is on linux/amd64... mika writes: >My toolsets are old, yes. > >I tried upgrade.py but you saw that that didn't work either. > >I guess I could go back and re-install from a recent binary image (where >are the most recent ones? I only see really old ones on elegosoft...) and >build everything from scratch. It's just that all the systems that I >have M3 on are some sort of production systems and I don't want to mess >up the installations unnecessarily... but if it's the only way... > > Mika > >Jay K writes: >>--_461a9835-225f-448d-96a6-4c651ff66c13_ >>Content-Type: text/plain; charset="iso-8859-1" >>Content-Transfer-Encoding: quoted-printable >> >>Target.i3/m3 look up to date. >>Is your host toolset very old? >> >>https://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3middle/src/Ta= >>rget.i3 >> >>Revision 1.59: download - view: text=2C markup=2C annotated - select for di= >>ffs >>=0A= >>Sat Jun 19 06:56:32 2010 (3 years=2C 3 months ago) by jkrell >>=0A= >>Branches: MAIN >>=0A= >>Diff to: previous 1.58: preferred=2C unified >>=0A= >>Changes since revision 1.58: +2 -0 lines >>=0A= >>add ARMEL_LINUX with correct jmbuf size/align=0A= >>guessing about alignment=0A= >>"ARM" is an older ABI=0A= >>"ARME" is the usual modern ABI=0A= >>L for little endian=0A= >> >>scripts/update.py ? >> >> - Jay From jay.krell at cornell.edu Mon Oct 14 21:21:31 2013 From: jay.krell at cornell.edu (Jay K) Date: Mon, 14 Oct 2013 19:21:31 +0000 Subject: [M3devel] mklib in upgrade.py ... In-Reply-To: <20131014185831.9AD871A208E@async.async.caltech.edu> References: <20131014185831.9AD871A208E@async.async.caltech.edu> Message-ID: mklib: I fixed it to compile long ago, broke it recently, fixed it recently. There is a dependency on m3core having the Win32 typedefs/defines. Which it has had for years. If we really need to stay compatible with very old versions, I can copy those typedefs/defines into mklib, again. mklib's utility on non-Windows systems is hypothetical at this point. If we had/used a cross linker and cross C compiler, then mklib would help round out a cross build solution. Without a cross linker, it is kind of pointless. (Then again, with a cross linker and C compiler, we'd probably have "cross ar", though mklib does a bit more than that..) I guess I can filter mklib out of for non-Windows. But more likely I will leave it in. I'd rather copy the few relevant types/constants into mklib. Or just require everyone to have an up to date m3core.. There are so many things in the system that do work, but people keep trying to use old libraries/toolsets. The odbc duplication is another example -- a bunch of identical files except for calling convention, calling convention previously being an error on non-Windows systems, but for years now being ignored instead. - Jay > To: jay.krell at cornell.edu > Date: Mon, 14 Oct 2013 11:58:31 -0700 > From: mika at async.caltech.edu > CC: m3devel at elegosoft.com > Subject: [M3devel] mklib in upgrade.py ... > > > And now I see that mklib talks a lot about WinNT. I suspect I have no > use for it??? I took it out of upgrade.py since it doesn't compile and > breaks the upgrade procedure... perhaps there should be a test somewhere > to ensure it won't get compiled on non-Windows systems? Or fix it so it > does compile.. > > Mika -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay.krell at cornell.edu Mon Oct 14 21:28:30 2013 From: jay.krell at cornell.edu (Jay K) Date: Mon, 14 Oct 2013 19:28:30 +0000 Subject: [M3devel] building CM3 on a Raspberry Pi? In-Reply-To: <20131014190252.147321A208E@async.async.caltech.edu> References: <20131013203501.35E651A208F@async.async.caltech.edu>, , , , <20131014151924.979A31A208E@async.async.caltech.edu>, , , , <20131014164008.685B81A208E@async.async.caltech.edu>, , ,

<20131014185302.4952B1A208E@async.async.caltech.edu>, <20131014190252.147321A208E@async.async.caltech.edu> Message-ID: > ../src/word/WordRep.i3:1: fatal error: *** illegal type: 0x6f, at m3cg_lineno 5 I think this is caused by cm3cg mismatching cm3. upgrade.py is supposed to upgrade them at the proper time though. I did used to have things a little wrong, esp. willingness to use an unshipped version laying around. Or maybe cm3cg has the wrong target. cm3cg -v or -V or -version? You could switch your AMD64_LINUX tools to the C backend.. :) (It should work. I think I tested it on modula3.elegosoft.com.) http://modula3.elegosoft.com/cm3/uploaded-archives Darn, nothing recent for AMD64_LINUX. I can work on that this week..using the C backend. There are also snapshots from Hudson here, of varying dates: https://modula3.elegosoft.com/cm3/snaps/snapshot-index.html - Jay > To: jay.krell at cornell.edu > CC: m3devel at elegosoft.com > Subject: Re: [M3devel] building CM3 on a Raspberry Pi? > Date: Mon, 14 Oct 2013 12:02:52 -0700 > From: mika at async.caltech.edu > > More updates... > > after I remove mklib, I do get a new compiler built, and I get to this point > > ignoring ../src/m3overrides > > ==> /nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3/m3-win/import-libs done > > +++ /nfs/site/home/mnystroe/work/cm3/bin/cm3 -ship -DROOT=/nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3 +++ > --- shipping from AMD64_LINUX --- > > ==> /nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3/m3-win/import-libs done > > == package /nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3/m3-libs/m3core == > > +++ /nfs/site/home/mnystroe/work/cm3/bin/cm3 -build -DROOT=/nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3 +++ > --- building in AMD64_LINUX --- > > ignoring ../src/m3overrides > > new source -> compiling RTHooks.i3 > ../src/runtime/common/RTHooks.i3:15: fatal error: *** illegal type: 0x6f, at m3cg_lineno 5 > compilation terminated. > m3_backend => 1 > m3cc (aka cm3cg) failed compiling: RTHooks.ic > Assembler messages: > Can't open RTHooks.is for reading: No such file or directory > new source -> compiling RT0.i3 > ../src/runtime/common/RT0.i3:19: fatal error: *** illegal type: 0x6f, at m3cg_lineno 5 > compilation terminated. > m3_backend => 1 > m3cc (aka cm3cg) failed compiling: RT0.ic > Assembler messages: > Can't open RT0.is for reading: No such file or directory > new source -> compiling RuntimeError.i3 > ../src/runtime/common/RuntimeError.i3:10: fatal error: *** illegal type: 0x6f, at m3cg_lineno 5 > compilation terminated. > m3_backend => 1 > m3cc (aka cm3cg) failed compiling: RuntimeError.ic > Assembler messages: > Can't open RuntimeError.is for reading: No such file or directory > new source -> compiling WordRep.i3 > ../src/word/WordRep.i3:1: fatal error: *** illegal type: 0x6f, at m3cg_lineno 5 > > I've seen this before but don't remember what the issue is. > > The compiler is new: > > -rwxr-x--- 1 mnystroe rrc 9916732 2013-10-14 11:59 /nfs/site/home/mnystroe/work/cm3/bin/cm3 > > This is on linux/amd64... > > > mika writes: > >My toolsets are old, yes. > > > >I tried upgrade.py but you saw that that didn't work either. > > > >I guess I could go back and re-install from a recent binary image (where > >are the most recent ones? I only see really old ones on elegosoft...) and > >build everything from scratch. It's just that all the systems that I > >have M3 on are some sort of production systems and I don't want to mess > >up the installations unnecessarily... but if it's the only way... > > > > Mika > > > >Jay K writes: > >>--_461a9835-225f-448d-96a6-4c651ff66c13_ > >>Content-Type: text/plain; charset="iso-8859-1" > >>Content-Transfer-Encoding: quoted-printable > >> > >>Target.i3/m3 look up to date. > >>Is your host toolset very old? > >> > >>https://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3middle/src/Ta= > >>rget.i3 > >> > >>Revision 1.59: download - view: text=2C markup=2C annotated - select for di= > >>ffs > >>=0A= > >>Sat Jun 19 06:56:32 2010 (3 years=2C 3 months ago) by jkrell > >>=0A= > >>Branches: MAIN > >>=0A= > >>Diff to: previous 1.58: preferred=2C unified > >>=0A= > >>Changes since revision 1.58: +2 -0 lines > >>=0A= > >>add ARMEL_LINUX with correct jmbuf size/align=0A= > >>guessing about alignment=0A= > >>"ARM" is an older ABI=0A= > >>"ARME" is the usual modern ABI=0A= > >>L for little endian=0A= > >> > >>scripts/update.py ? > >> > >> - Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Mon Oct 14 22:46:36 2013 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Mon, 14 Oct 2013 13:46:36 -0700 Subject: [M3devel] building CM3 on a Raspberry Pi? In-Reply-To: References: <20131013203501.35E651A208F@async.async.caltech.edu>, , , , <20131014151924.979A31A208E@async.async.caltech.edu>, , , , <20131014164008.685B81A208E@async.async.caltech.edu>, , ,

<20131014185302.4952B1A208E@async.async.caltech.edu>, <20131014190252.147321A208E@async.async.caltech.edu> Message-ID: <20131014204636.A77381A208E@async.async.caltech.edu> Well I think this error is what got me to give up building on MIPS (Asus router) a couple of years ago. This stuff is really very difficult to get through. hmm... so here I am just trying to ./upgrade.py, no cross building yet. My tools aren't THAT old. 2-3 years at most. I thought we could bootstrap all the way back with SRC M3? (906)tsvnc06:...cm3-anon-cvs/cm3/scripts/python>cm3cg -version Modula-3 backend (GCC) version 4.3.0 (x86_64-unknown-linux-gnu) compiled by GNU C version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21), GMP version 4.2.1, MPFR version 2.3.0. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 options passed: options enabled: -falign-loops -fargument-alias -fasynchronous-unwind-tables -fauto-inc-dec -fbranch-count-reg -fcommon -fearly-inlining -feliminate-unused-debug-types -ffunction-cse -fgcse-lm -fident -fivopts -fkeep-static-consts -fleading-underscore -fmath-errno -fmerge-debug-strings -fmove-loop-invariants -fpeephole -freg-struct-return -fsched-interblock -fsched-spec -fsched-stalled-insns-dep -fsigned-zeros -fsplit-ivs-in-unroller -ftoplevel-reorder -ftrapping-math -ftree-cselim -ftree-loop-im -ftree-loop-ivcanon -ftree-loop-optimize -ftree-parallelize-loops= -ftree-reassoc -ftree-scev-cprop -ftree-vect-loop-version -funwind-tables -fvar-tracking -fvect-cost-model -fzero-initialized-in-bss -m128bit-long-double -m64 -m80387 -maccumulate-outgoing-args -malign-stringops -mfancy-math-387 -mfp-ret-in-387 -mfused-madd -mglibc -mieee-fp -mmmx -mno-sse4 -mpush-args -mred-zone -msse -msse2 -mtls-direct-seg-refs (907)tsvnc06:...cm3-anon-cvs/cm3/scripts/python>cm3cg -v M3CG - Modula-3 Compiler back end4.3.0 (908)tsvnc06:...cm3-anon-cvs/cm3/scripts/python>which cm3cg /nfs/site/home/mnystroe/work/cm3/bin/cm3cg (909)tsvnc06:...cm3-anon-cvs/cm3/scripts/python>ls -l `!!` ls -l `which cm3cg` -rwxr-x--- 1 mnystroe rrc 29747222 2010-06-04 10:41 /nfs/site/home/mnystroe/work/cm3/bin/cm3cg Jay K writes: >--_b7ef6d52-d09a-4017-8a20-e0fef4593137_ >Content-Type: text/plain; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > >> ../src/word/WordRep.i3:1: fatal error: *** illegal type: 0x6f=2C at m3cg= >_lineno 5 > > >I think this is caused by cm3cg mismatching cm3. >upgrade.py is supposed to upgrade them at the proper time though. >I did used to have things a little wrong=2C esp. willingness to use an unsh= >ipped version laying around. > > > Or maybe cm3cg has the wrong target.=20 > cm3cg -v or -V or -version?=20 > > >You could switch your AMD64_LINUX tools to the C backend.. :) >(It should work. I think I tested it on modula3.elegosoft.com.) > > >http://modula3.elegosoft.com/cm3/uploaded-archives >Darn=2C nothing recent for AMD64_LINUX. >I can work on that this week..using the C backend. > > >There are also snapshots from Hudson here=2C of varying dates: >https://modula3.elegosoft.com/cm3/snaps/snapshot-index.html =20 > > > - Jay > > >> To: jay.krell at cornell.edu >> CC: m3devel at elegosoft.com >> Subject: Re: [M3devel] building CM3 on a Raspberry Pi? >> Date: Mon=2C 14 Oct 2013 12:02:52 -0700 >> From: mika at async.caltech.edu >>=20 >> More updates... >>=20 >> after I remove mklib=2C I do get a new compiler built=2C and I get to thi= >s point >>=20 >> ignoring ../src/m3overrides >>=20 >> =3D=3D> /nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3/m3-win/impor= >t-libs done >>=20 >> +++ /nfs/site/home/mnystroe/work/cm3/bin/cm3 -ship -DROOT=3D/nfs/site/d= >isks/wdisk.133/mnystroe/cm3-anon-cvs/cm3 +++ >> --- shipping from AMD64_LINUX --- >>=20 >> =3D=3D> /nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3/m3-win/impor= >t-libs done >>=20 >> =3D=3D package /nfs/site/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3/m3-lib= >s/m3core =3D=3D >>=20 >> +++ /nfs/site/home/mnystroe/work/cm3/bin/cm3 -build -DROOT=3D/nfs/sit= >e/disks/wdisk.133/mnystroe/cm3-anon-cvs/cm3 +++ >> --- building in AMD64_LINUX --- >>=20 >> ignoring ../src/m3overrides >>=20 >> new source -> compiling RTHooks.i3 >> ../src/runtime/common/RTHooks.i3:15: fatal error: *** illegal type: 0x6f= >=2C at m3cg_lineno 5 >> compilation terminated. >> m3_backend =3D> 1 >> m3cc (aka cm3cg) failed compiling: RTHooks.ic >> Assembler messages: >> Can't open RTHooks.is for reading: No such file or directory >> new source -> compiling RT0.i3 >> ../src/runtime/common/RT0.i3:19: fatal error: *** illegal type: 0x6f=2C = >at m3cg_lineno 5 >> compilation terminated. >> m3_backend =3D> 1 >> m3cc (aka cm3cg) failed compiling: RT0.ic >> Assembler messages: >> Can't open RT0.is for reading: No such file or directory >> new source -> compiling RuntimeError.i3 >> ../src/runtime/common/RuntimeError.i3:10: fatal error: *** illegal type:= > 0x6f=2C at m3cg_lineno 5 >> compilation terminated. >> m3_backend =3D> 1 >> m3cc (aka cm3cg) failed compiling: RuntimeError.ic >> Assembler messages: >> Can't open RuntimeError.is for reading: No such file or directory >> new source -> compiling WordRep.i3 >> ../src/word/WordRep.i3:1: fatal error: *** illegal type: 0x6f=2C at m3cg= >_lineno 5 >>=20 >> I've seen this before but don't remember what the issue is. >>=20 >> The compiler is new: >>=20 >> -rwxr-x--- 1 mnystroe rrc 9916732 2013-10-14 11:59 /nfs/site/home/mnystro= >e/work/cm3/bin/cm3 >>=20 >> This is on linux/amd64... >>=20 >>=20 >> mika writes: >> >My toolsets are old=2C yes. >> > >> >I tried upgrade.py but you saw that that didn't work either. =20 >> > >> >I guess I could go back and re-install from a recent binary image (where >> >are the most recent ones? I only see really old ones on elegosoft...) a= >nd >> >build everything from scratch. It's just that all the systems that I >> >have M3 on are some sort of production systems and I don't want to mess >> >up the installations unnecessarily... but if it's the only way... >> >=20 >> > Mika >> > >> >Jay K writes: >> >>--_461a9835-225f-448d-96a6-4c651ff66c13_ >> >>Content-Type: text/plain=3B charset=3D"iso-8859-1" >> >>Content-Transfer-Encoding: quoted-printable >> >> >> >>Target.i3/m3 look up to date. >> >>Is your host toolset very old? >> >> >> >>https://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-sys/m3middle/sr= >c/Ta=3D >> >>rget.i3 >> >> >> >>Revision 1.59: download - view: text=3D2C markup=3D2C annotated - selec= >t for di=3D >> >>ffs >> >>=3D0A=3D >> >>Sat Jun 19 06:56:32 2010 (3 years=3D2C 3 months ago) by jkrell >> >>=3D0A=3D >> >>Branches: MAIN >> >>=3D0A=3D >> >>Diff to: previous 1.58: preferred=3D2C unified >> >>=3D0A=3D >> >>Changes since revision 1.58: +2 -0 lines >> >>=3D0A=3D >> >>add ARMEL_LINUX with correct jmbuf size/align=3D0A=3D >> >>guessing about alignment=3D0A=3D >> >>"ARM" is an older ABI=3D0A=3D >> >>"ARME" is the usual modern ABI=3D0A=3D >> >>L for little endian=3D0A=3D >> >> >> >>scripts/update.py ? >> >> >> >> - Jay > = > >--_b7ef6d52-d09a-4017-8a20-e0fef4593137_ >Content-Type: text/html; charset="iso-8859-1" >Content-Transfer-Encoding: quoted-printable > > > > >

Hi,

=A0 It either crashes with a segv in the collector in Move or else in = >FileRd.init, =A0with the buf field=A0

=A0corrupted. Something doe= >s not like being moved by the look of things.

=A0 Has anyone = >else experience problems like this?

Regards Peter.