search

modula3 / cm3

Critical Mass Modula-3
http://modula3.github.io/cm3/
Other
133 stars 26 forks source link

Porting CM3 to Haiku x86 32 bits #16

Open DKnoto opened 7 years ago

DKnoto commented 7 years ago

Hi,

I have been using Haiku for a long time and decided to port CM3 to this system. In the first step I reduced the number of packages from the pkginfo.txt file to the minimum necessary. So make-dist.py script makes CM3 distribution seamlessly. The whole thing I prepared on Linux Fedora 25 on AMD64. I read carefully the file doc/notses/porting.txt and performed the following steps: a) I added the new target I386_HAIKU to Target.i3; b) I added a buffer size to Jumpbuf_size, 32 bytes as 8 x address size; c) I rebuilt CM3 with the make-dist.py script; d) I have installed the reworked CM3-min distribution on the host system; CM3 --version:

Critical Mass Modula-3 version d5.10.0 last updated: 2016-10-05 compiled: 2017-04-01 14:38:59 configuration: /opt/cm3-devel-5.10.0-dkk/bin/cm3.cfg host: AMD64_LINUX target: AMD64_LINUX

e) I added the entry "I386_HAIKIU": "i586-pc-haiku" to the file m3-sys/m3cc/src/platforms.quake; f) I added the entry "I386_HAIKU" : "-with-gnu-as -with-gnu-ld" and added "I386_HIAKU" in line 475 in the file m3makefile in the same directory; g) I tried to run the command: cm3 -DM3CC_TARGET=I386_HAIKU.

After that I have got the following message:

checking for clock_t... yes checking if mkdir takes one argument... no *** Configuration i586-pc-haiku not supported Makefile:3413: recipe for target 'configure-gcc' failed make: *** [configure-gcc] Error 1 "/run/media/dknoto/ARCHIWUM/Oprogramowanie/Critical.Mass.Modula-3/cm3-d5.10.0-20161121/m3-sys/m3cc/src/m3makefile", line 332: quake runtime error: exit 2: cd ../AMD64_LINUX-I386_HAIKU && make MAKE="make -j4 " AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: configure-host `--procedure-- -line- -file---` `exec -- <builtin>` `m3cc_Run 332 /run/media/dknoto/ARCHIWUM/Oprogramowanie/Critical.Mass.Modula-3/cm3-d5.10.0-20161121/m3-sys/m3cc/src/m3makefile` `include_dir 543 /run/media/dknoto/ARCHIWUM/Oprogramowanie/Critical.Mass.Modula-3/cm3-d5.10.0-20161121/m3-sys/m3cc/src/m3makefile` ` 5 /run/media/dknoto/ARCHIWUM/Oprogramowanie/Critical.Mass.Modula-3/cm3-d5.10.0-20161121/m3-sys/m3cc/AMD64_LINUX/m3make.args` Fatal Error: package build failed

I tried manually to run gcc47 compiling commands but I did not go much further.

darko20 commented 7 years ago

I'm not sure if it's the cause of this error but I believe you need to use GCC 4.8 or greater with CM3.

On Sun, Apr 2, 2017 at 12:12 PM, Dariusz Knociński <notifications@github.com

wrote:

Hi,

I have been using Haiku for a long time and decided to port CM3 to this system. In the first step I reduced the number of packages from the pkginfo.txt file to the minimum necessary. So make-dist.py script makes CM3 distribution seamlessly. The whole thing I prepared on Linux Fedora 25 on AMD64. I read carefully the file doc/notses/porting.txt and performed the following steps: a) I added the new target I386_HAIKU to Target.i3; b) I added a buffer size to Jumpbuf_size, 32 bytes as 8 x address size; c) I rebuilt CM3 with the make-dist.py script; d) I have installed the reworked CM3-min distribution on the host system; CM3 --version:

Critical Mass Modula-3 version d5.10.0 last updated: 2016-10-05 compiled: 2017-04-01 14:38:59 configuration: /opt/cm3-devel-5.10.0-dkk/bin/cm3.cfg host: AMD64_LINUX target: AMD64_LINUX

e) I added the entry "I386_HAIKIU": "i586-pc-haiku" to the file m3-sys/m3cc/src/platforms.quake; f) I added the entry "I386_HAIKU" : "-with-gnu-as -with-gnu-ld" and added "I386_HIAKU" in line 475 in the file m3makefile in the same directory; g) I tried to run the command: cm3 -DM3CC_TARGET=I386_HAIKU.

After that I have got the following message:

checking for clock_t... yes checking if mkdir takes one argument... no Configuration i586-pc-haiku not supported Makefile:3413: recipe for target 'configure-gcc' failed make: [configure-gcc] Error 1 "/run/media/dknoto/ARCHIWUM/Oprogramowanie/Critical.Mass. Modula-3/cm3-d5.10.0-20161121/m3-sys/m3cc/src/m3makefile", line 332: quake runtime error: exit 2: cd ../AMD64_LINUX-I386_HAIKU && make MAKE="make -j4 " AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: configure-host --procedure-- -line- -file--- exec -- <builtin> m3cc_Run 332 /run/media/dknoto/ARCHIWUM/Oprogramowanie/Critical.Mass. Modula-3/cm3-d5.10.0-20161121/m3-sys/m3cc/src/m3makefile include_dir 543 /run/media/dknoto/ARCHIWUM/Oprogramowanie/Critical.Mass. Modula-3/cm3-d5.10.0-20161121/m3-sys/m3cc/src/m3makefile 5 /run/media/dknoto/ARCHIWUM/Oprogramowanie/Critical.Mass. Modula-3/cm3-d5.10.0-20161121/m3-sys/m3cc/AMD64_LINUX/m3make.args Fatal Error: package build failed

I tried manually to run gcc47 compiling commands but I did not go much further.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/modula3/cm3/issues/16, or mute the thread https://github.com/notifications/unsubscribe-auth/AEDI7iJ7ZVzlzbY87oSyLmqSj5YqiXnwks5rr3RzgaJpZM4Mwwg_ .

DKnoto commented 7 years ago

I think that gcc47 is the default backend in CM3.

darko20 commented 7 years ago

No I mean the GCC you're using to compile. CM3 needs GCC installed in order to work, on some platforms having a version less than 4.8 causes problems. This is independent of the version of GCC that is used as the back end.

On Sun, Apr 2, 2017 at 4:27 PM, Dariusz Knociński notifications@github.com wrote:

I think that gcc47 is the default backend in CM3.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/modula3/cm3/issues/16#issuecomment-290989774, or mute the thread https://github.com/notifications/unsubscribe-auth/AEDI7vnIFMqPkaiyoVix9wGTsy4PxSUjks5rr7BrgaJpZM4Mwwg_ .

DKnoto commented 7 years ago

Ok. I use gcc-5.4 from Fedora 25. The AMD64_LINUX version compiles correctly with this compiler.

DKnoto commented 7 years ago

Sorry, now I have gcc-6.3.1.

DKnoto commented 7 years ago

I checked again. The command "cm3 -DM3CC_TARGET=AMD64_LINUX" executes correctly.

jaykrell commented 7 years ago

You need to port gcc first -- our slightly forked backend, Or use one of the other backends.

I suggest the C backend. :)

Porting gcc isn't necessarily what it sounds like. Probably someone already has ported gcc, and you just need to move over a few lines here or there.

A newer gcc might already have the changes merged in, but updating our gcc is probably more difficult than that. I've done it a few times, but last time I offered there wasn't really interest.

The host gcc doesn't matter much. "We" (gcc!) should have pretty broad portability.

Really I need to get the C backend back fully working (something rotted

a little I think) and we should remove the gcc backend imho.

And then do the "packaging" work so download and install from C source

is viable. Some day..

From: Dariusz Knociński notifications@github.com Sent: Sunday, April 2, 2017 4:40 PM To: modula3/cm3 Cc: Subscribed Subject: Re: [modula3/cm3] Porting CM3 to Haiku x86 32 bits (#16)

I checked again. The command "cm3 -DM3CC_TARGET=AMD64_LINUX" executes correctly.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/modula3/cm3/issues/16#issuecomment-290997861, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABj1kJA5nksQQ8NTL1Yp6FErboeyeeanks5rr89kgaJpZM4Mwwg_.

DKnoto commented 7 years ago

I have a fog in my head :(

jaykrell commented 7 years ago

No. Where did you get this idea?

On Apr 2, 2017, at 3:18 AM, darko20 notifications@github.com wrote:

I'm not sure if it's the cause of this error but I believe you need to use GCC 4.8 or greater with CM3.

On Sun, Apr 2, 2017 at 12:12 PM, Dariusz Knociński <notifications@github.com

wrote:

Hi,

I have been using Haiku for a long time and decided to port CM3 to this system. In the first step I reduced the number of packages from the pkginfo.txt file to the minimum necessary. So make-dist.py script makes CM3 distribution seamlessly. The whole thing I prepared on Linux Fedora 25 on AMD64. I read carefully the file doc/notses/porting.txt and performed the following steps: a) I added the new target I386_HAIKU to Target.i3; b) I added a buffer size to Jumpbuf_size, 32 bytes as 8 x address size; c) I rebuilt CM3 with the make-dist.py script; d) I have installed the reworked CM3-min distribution on the host system; CM3 --version:

Critical Mass Modula-3 version d5.10.0 last updated: 2016-10-05 compiled: 2017-04-01 14:38:59 configuration: /opt/cm3-devel-5.10.0-dkk/bin/cm3.cfg host: AMD64_LINUX target: AMD64_LINUX

e) I added the entry "I386_HAIKIU": "i586-pc-haiku" to the file m3-sys/m3cc/src/platforms.quake; f) I added the entry "I386_HAIKU" : "-with-gnu-as -with-gnu-ld" and added "I386_HIAKU" in line 475 in the file m3makefile in the same directory; g) I tried to run the command: cm3 -DM3CC_TARGET=I386_HAIKU.

After that I have got the following message:

checking for clock_t... yes checking if mkdir takes one argument... no Configuration i586-pc-haiku not supported Makefile:3413: recipe for target 'configure-gcc' failed make: [configure-gcc] Error 1 "/run/media/dknoto/ARCHIWUM/Oprogramowanie/Critical.Mass. Modula-3/cm3-d5.10.0-20161121/m3-sys/m3cc/src/m3makefile", line 332: quake runtime error: exit 2: cd ../AMD64_LINUX-I386_HAIKU && make MAKE="make -j4 " AUTOCONF=: AUTOMAKE=: LEX='touch lex.yy.c' MAKEINFO=: configure-host --procedure-- -line- -file--- exec -- <builtin> m3cc_Run 332 /run/media/dknoto/ARCHIWUM/Oprogramowanie/Critical.Mass. Modula-3/cm3-d5.10.0-20161121/m3-sys/m3cc/src/m3makefile include_dir 543 /run/media/dknoto/ARCHIWUM/Oprogramowanie/Critical.Mass. Modula-3/cm3-d5.10.0-20161121/m3-sys/m3cc/src/m3makefile 5 /run/media/dknoto/ARCHIWUM/Oprogramowanie/Critical.Mass. Modula-3/cm3-d5.10.0-20161121/m3-sys/m3cc/AMD64_LINUX/m3make.args Fatal Error: package build failed

I tried manually to run gcc47 compiling commands but I did not go much further.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/modula3/cm3/issues/16, or mute the thread https://github.com/notifications/unsubscribe-auth/AEDI7iJ7ZVzlzbY87oSyLmqSj5YqiXnwks5rr3RzgaJpZM4Mwwg_ .

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

DKnoto commented 7 years ago

Using C backend we have a Modula-3 translator but not a compiler?

I would like to learn how to prepare gcc to cm3 but I need time for it :(

jaykrell commented 7 years ago

What do you see as the difference and does it matter?

Do you think the "level" is key? Translating to C provides a wide avenue toward translation to assembly or machine code, and execution. Translation to gcc IR provides similar but a C compiler for your system may be more accessible than a gcc IR translator.

There are systems that kinda bounce the "level" up and down before finally arriving at machine executable code.

On Apr 3, 2017, at 11:59 AM, Dariusz Knociński notifications@github.com wrote:

Using C backend we have a Modula-3 translator but not a compiler?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

DKnoto commented 7 years ago

Do you think the "level" is key?

Generally yes. If the Modula-3 is to be a system language then it must allow gnerating the machine code to the raw machine without the help of the C compiler.

DKnoto commented 7 years ago

In addition, redundant levels in the compilation process are unnecessary load.

jaykrell commented 7 years ago

I disagree wholeheartedly. For example, C++ went a long time with the only compilers also translating to C.

But it is a systems programming language as much as C and Modula-3.

We have systems that take binaries, "raise them", and "relower" them to other architectures.

Is that a compiler, or translator, or no label is needed?

I mean, sure, if you want to label it translator or compiler, ok, but the result is about as good and about as useful.

It is true going through C tends to compile more slowly.

But, for example, compared to NT386, it will provide better codegen (inlining), and compared to nonexistent AMD64_NT, infinitely better.

As well, it somewhat produces better debugging information than all the other backends. (there is the problem that all locals get unique names, even if not needed -- it'd be nice if frontend didn't collapse scopes...)

It can/should be seen as merely an implementation detail.

As well, it should be noted, it doesn't translate to idiomatic C.

It goes through same frontend/backend flow as the gcc backend -- the C it generates it just as low level as the gcc IR -- horrendously unreadable and somewhat unportable C.

Perhaps perhaps with the exception of how nested functions, "display" and "static link" work. That is represented in a somewhat higher level form, and doesn't take advantage of features in some ABIs that the gcc backend is able to.

From: Dariusz Knociński notifications@github.com Sent: Tuesday, April 4, 2017 6:45 AM To: modula3/cm3 Cc: jaykrell; Comment Subject: Re: [modula3/cm3] Porting CM3 to Haiku x86 32 bits (#16)

Do you think the "level" is key? Generally yes. If the Modula-3 is to be a system language then it must allow gnerating the machine code to the raw machine without the help of the C compiler.

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/modula3/cm3/issues/16#issuecomment-291408812, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABj1kPE4xQnnGxFXLZjgmdMTOyC82xkHks5rsecIgaJpZM4Mwwg_.

jaykrell commented 7 years ago

It is true the compilation process is a bit slow.

But so is even the gcc backend compared to the integrated NT386 backend.

From: Dariusz Knociński notifications@github.com Sent: Tuesday, April 4, 2017 6:49 AM To: modula3/cm3 Cc: jaykrell; Comment Subject: Re: [modula3/cm3] Porting CM3 to Haiku x86 32 bits (#16)

In addition, redundant levels in the compilation process are unnecessary load.

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/modula3/cm3/issues/16#issuecomment-291409561, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABj1kLSfBdjs9XJ6_j8_3LQP4zCToxvKks5rseffgaJpZM4Mwwg_.

DKnoto commented 7 years ago

Jay understands your arguments and in this particular case I guess. Unfortunately, this approach makes it impossible to build an operating system in pure Modula-3.

olaf-wagner commented 7 years ago

On Tue, 04 Apr 2017 01:05:48 -0700 Dariusz Knociński notifications@github.com wrote:

Jay understands your arguments and in this particular case I guess. Unfortunately, this approach makes it impossible to build an operating system in pure Modula-3.

As far as I know that has already been done once. I'm not aware if it is still available anywhere though.

CM3 has a flexible architecture that allows for different backends on different levels. You may start with the C backend for a certain target architecture, then switch to cm3cg and if that still doesn't match your needs, write your own target-specific backend generating object code or intermediate code or whatever you like.

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: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194

jaykrell commented 7 years ago

If you consider the operating system to include the compiler, which is not clear, then true. And, does it matter? Do you have the system written except for this? And even if so, why does it matter?

On Apr 4, 2017, at 1:47 AM, Olaf Wagner notifications@github.com wrote:

On Tue, 04 Apr 2017 01:05:48 -0700 Dariusz Knociński notifications@github.com wrote:

Jay understands your arguments and in this particular case I guess. Unfortunately, this approach makes it impossible to build an operating system in pure Modula-3.

As far as I know that has already been done once. I'm not aware if it is still available anywhere though.

CM3 has a flexible architecture that allows for different backends on different levels. You may start with the C backend for a certain target architecture, then switch to cm3cg and if that still doesn't match your needs, write your own target-specific backend generating object code or intermediate code or whatever you like.

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: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194 — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

RodneyBates commented 7 years ago

On 04/04/2017 01:45 AM, Dariusz Knociński wrote:

Do you think the "level" is key?
Generally yes. If the Modula-3 is to be a system language then it must allow gnerating the machine code to the raw machine without the help of the C compiler.

I allows this just fine if you use the gcc-derived backend, or, for 368, the integrated backend. Eventually, the llvm backend will work too.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/modula3/cm3/issues/16#issuecomment-291408812, or mute the thread https://github.com/notifications/unsubscribe-auth/AGVctPXFPWtCrcMauIw4RI_7V0zwzytSks5rsecIgaJpZM4Mwwg_.

RodneyBates commented 7 years ago

On 04/04/2017 02:03 AM, jaykrell wrote:

I disagree wholeheartedly. For example, C++ went a long time with the only compilers also translating to C.

But it is a systems programming language as much as C and Modula-3.

We have systems that take binaries, "raise them", and "relower" them to other architectures.

Is that a compiler, or translator, or no label is needed?

I mean, sure, if you want to label it translator or compiler, ok, but the result is about as good and about as useful.

It is true going through C tends to compile more slowly.

It always seems to me that compiling Modula-3, which entails running both the Modula-3 front end and the gcc-derived backend as separate executables, is considerably faster than compiling human-written C code of similar line count, using gcc. This is hard to imagine why, since the back end is just a modified version of gcc, mostly gcc.

Llvm, is a lot slower compiling than gcc, and so will the llvm backend be. Compiling llvm with llvm, compared to compiling llvm with gcc will show this very clearly. This is not surprising, as llvm purports to be a very sophisticated optimizing back end, and it's implemented in a way that is very slow, but very flexible for adding new optimizations, with minimal interaction (of the implementing optimizer code.)

But, for example, compared to NT386, it will provide better codegen (inlining), and compared to nonexistent AMD64_NT, infinitely better.

As well, it somewhat produces better debugging information than all the other backends. (there is the problem that all locals get unique names, even if not needed -- it'd be nice if frontend didn't collapse scopes...)

No, this is absolutely false. The debug information is devastated by going through C, which is devoid of many counterparts of concepts of Modula-3. m3gdb is still far short of a really nice Modula-3 debugger, but it is at least as far ahead of anything that could be done with the debug information that can be pushed through a C compiler. Read the m3gdb documentation. It is full of stuff that can't be done using C-produced debug info.

Going through C is a good way to simplify porting to new architectures, as well as just building/installing on a machine of already-supported architecture, but lacking a preexisting Modula-3 compiler. It's a nonstarter for decent debuggability.

It can/should be seen as merely an implementation detail.

As well, it should be noted, it doesn't translate to idiomatic C.

Yet another hit on ease of debugging.

It goes through same frontend/backend flow as the gcc backend -- the C it generates it just as low level as the gcc IR -- horrendously unreadable and somewhat unportable C.

Perhaps perhaps with the exception of how nested functions, "display" and "static link" work. That is represented in a somewhat higher level form, and doesn't take advantage of features in some ABIs that the gcc backend is able to.

  • Jay

From: Dariusz Knociński notifications@github.com Sent: Tuesday, April 4, 2017 6:45 AM To: modula3/cm3 Cc: jaykrell; Comment Subject: Re: [modula3/cm3] Porting CM3 to Haiku x86 32 bits (#16)

Do you think the "level" is key? Generally yes. If the Modula-3 is to be a system language then it must allow gnerating the machine code to the raw machine without the help of the C compiler.

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/modula3/cm3/issues/16#issuecomment-291408812, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABj1kPE4xQnnGxFXLZjgmdMTOyC82xkHks5rsecIgaJpZM4Mwwg_.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/modula3/cm3/issues/16#issuecomment-291412590, or mute the thread https://github.com/notifications/unsubscribe-auth/AGVctJXoUsIyQXg9429uXGgAC31XgSvYks5rsetNgaJpZM4Mwwg_.

RodneyBates commented 7 years ago

On 04/04/2017 03:47 AM, Olaf Wagner wrote:

On Tue, 04 Apr 2017 01:05:48 -0700 Dariusz Knociński notifications@github.com wrote:

Jay understands your arguments and in this particular case I guess. Unfortunately, this approach makes it impossible to build an operating system in pure Modula-3.

As far as I know that has already been done once. I'm not aware if it is still available anywhere though.

In case it is not, I have kept a local copy for some time, though I've never tried doing anything with it. If needed, I can supply it.

CM3 has a flexible architecture that allows for different backends on different levels. You may start with the C backend for a certain target architecture, then switch to cm3cg and if that still doesn't match your needs, write your own target-specific backend generating object code or intermediate code or whatever you like.

Yes, that is the range of options we need to support.

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: Olaf Wagner | Sitz: Berlin Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/modula3/cm3/issues/16#issuecomment-291434310, or mute the thread https://github.com/notifications/unsubscribe-auth/AGVctAW0qCaYHRO53zwdmbi85YP1Wqplks5rsgOKgaJpZM4Mwwg_.

DKnoto commented 7 years ago

@Olaf

As far as I know that has already been done once. I'm not aware if it is still available anywhere though.

I remeber, it was SPIN OS.

DKnoto commented 7 years ago

Thanks a lot for the comments. Next weekend I will try to find the cause of this error. The ./configure script works fine when I run it manually.

DKnoto commented 7 years ago

BTW. Why did not you try a development path like FPC + Lazarus?

jaykrell commented 7 years ago

When you run it -- on what host?

It defaults to a native build.

If this version of gcc supports haiku, which I doubt, then we are closer to it working than I thought.

You need to ensure of the backends supports your target -- integrated (no), gcc (maybe or close), llvm (works at all?), or C (sort of definitely does, but need to unbitrot)

From: Dariusz Knociński notifications@github.com Sent: Tuesday, April 4, 2017 8:38 PM To: modula3/cm3 Cc: jaykrell; Comment Subject: Re: [modula3/cm3] Porting CM3 to Haiku x86 32 bits (#16)

Thanks a lot for the comments. Next weekend I will try to find the cause of this error. The ./configure script works fine when I run it manually.

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/modula3/cm3/issues/16#issuecomment-291624652, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABj1kBv8LOu5dT-53Wm-tzIPLp58uP5Gks5rsqpHgaJpZM4Mwwg_.

DKnoto commented 7 years ago

HOST=AMD64, Linux, gcc-6.3.1 TARGET=i586-pc-haiku This gcc47 support Haiku, properly from 2.95 to 5.4.

jaykrell commented 7 years ago

We are not communicating, and I'm still going to be imprecise, but you need to try and see if something like the following works:

mkdir cm3src/.../m3cc/temp

cd cm3src/.../m3cc/temp

cm3src/.../gcc/configure --host=amd64-linux --target=i586-pc-haiku

or

cm3src/.../gcc/gcc/configure --host=amd64-linux --target=i586-pc-haiku

or copy this specific copy of gcc to your Haiku machine and run configure.

i.e. We have a somewhat patched fork of gcc. Did we fork a version that supports Haiku? (and keep it working?) Or did Haiku support come in later? Or is Haiku support in unmerged forked?

If ours already supports it, then, great, less work to do. If the support came in later, or is unmerged, then you merge it in.

And I am kinda exaggerating. Gcc is well factored along the various factors -- that is, all of the x86 ports share almost all of the x86 code. For example, you don't have to say that Linux/x86 is 32bit and little endian, just that x86 is 32bit and little endian, and then all x86 ports share that.

All of the Linux ports share almost all of the Linux code. For example, you don't have to say that Linux/x86 size_t is "unsigned long", just that on Linux that size_t is "unsigned long" and then Linux in all processors already have that correct.

Furthermore, a lot of gcc porting is actually things like saying size_t is "unsigned long" -- a lot is in the C and C++ frontend, stuff that we don't use, and possibly don't build, and possibly deleted.

So there is less port-seeming work than there might be.

It is actually even better than this -- many ports use the asm object file format, and/or same dynamic linkage system, and/or same ABI, and/or same assembly syntax. Gcc is structured to minimize repetition whenever there are common factors.

From: Dariusz Knociński notifications@github.com Sent: Tuesday, April 4, 2017 8:50 PM To: modula3/cm3 Cc: jaykrell; Comment Subject: Re: [modula3/cm3] Porting CM3 to Haiku x86 32 bits (#16)

HOST=AMD64, Linux, gcc-6.3.1 TAGET=i586-pc-haiku This gcc47 support Haiku, properly from 2.95 to 5.4.

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/modula3/cm3/issues/16#issuecomment-291627923, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABj1kCQ5bJQHI8O-XdXaj-FHWz9dhSGsks5rsq0qgaJpZM4Mwwg_.

jaykrell commented 7 years ago

It always seems to me that compiling Modula-3, which entails running both the Modula-3 front end and the gcc-derived backend as separate executables, is considerably faster than compiling human-written C code of similar line count, using gcc

The preprocessor is the death of apparent C compiler performance. C compilers are actually quite fast, but they are vastly overworked, doing the same, or almost the same work countless times.

No other language system has this problem. Everyone else is good like Modula-3. C# (metadata), Java (class files contain interface and implementation), Python (at least the .pyc files). Everyone else avoids reparsing the same code more than once, let alone many many times.

There are likely other factors as you say, the structure/sophistication of the backend, etc. but I believe this is the biggest by far.

You will enjoy hearing that there is a solution afoot for C++, and it is called "modules".

No, this is absolutely false. The debug information is devastated by going through C,

The reason I claim the debug information is better is because standard unmodified debuggers can see structs and potentially enums.

The "better" debug information output by cm3cg is only consumable by the customized m3gdb.

It doesn't handle Darwin, NT, or HP-UX.

When you use standard debuggers like Visual Studio, windbg, gdb/lldb-on-Darwin, the best I believe there was line numbers.

The simple reason it didn't quite get to the level I wanted, is that so far the C backend numbers every local for uniqueness, in case there are duplicates. It needs to do that only for duplicates.

Or better yet, the IR should have scopes that make up for the difference. I don't think that was dependeable at the time but I do need to check again. (includigg of course parameters).

I understand there is another area maybe, like TEXTs, where the C backend still might need work or might not be viable. We'll see.

So there is a tradeoff. If you have m3gdb, you might be better off. But if you want a selection of multiple "standard" debuggers -- nothing else understands cm3cg rich information and C is a decent conduit for pretty decent information.

But I did just remember, I think another area the C backend might fail in is globals. I forget how well they are rendered -- being all shoved into two structs as I recall they are (readonly and writable). This needs to have named fields, and/or possibly statics, or statics referring to them (I understand the struct probably helps with garbage collected globals, to refer to them via common bases and small offsets, instead of a pointer for each one, but not all globals are garbage collected. Anyway, TBD...)

From: Rodney M. Bates notifications@github.com Sent: Tuesday, April 4, 2017 5:21 PM To: modula3/cm3 Cc: jaykrell; Comment Subject: Re: [modula3/cm3] Porting CM3 to Haiku x86 32 bits (#16)

On 04/04/2017 02:03 AM, jaykrell wrote:

I disagree wholeheartedly. For example, C++ went a long time with the only compilers also translating to C.

But it is a systems programming language as much as C and Modula-3.

We have systems that take binaries, "raise them", and "relower" them to other architectures.

Is that a compiler, or translator, or no label is needed?

I mean, sure, if you want to label it translator or compiler, ok, but the result is about as good and about as useful.

It is true going through C tends to compile more slowly.

It always seems to me that compiling Modula-3, which entails running both the Modula-3 front end and the gcc-derived backend as separate executables, is considerably faster than compiling human-written C code of similar line count, using gcc. This is hard to imagine why, since the back end is just a modified version of gcc, mostly gcc.

Llvm, is a lot slower compiling than gcc, and so will the llvm backend be. Compiling llvm with llvm, compared to compiling llvm with gcc will show this very clearly. This is not surprising, as llvm purports to be a very sophisticated optimizing back end, and it's implemented in a way that is very slow, but very flexible for adding new optimizations, with minimal interaction (of the implementing optimizer code.)

But, for example, compared to NT386, it will provide better codegen (inlining), and compared to nonexistent AMD64_NT, infinitely better.

As well, it somewhat produces better debugging information than all the other backends. (there is the problem that all locals get unique names, even if not needed -- it'd be nice if frontend didn't collapse scopes...)

No, this is absolutely false. The debug information is devastated by going through C, which is devoid of many counterparts of concepts of Modula-3. m3gdb is still far short of a really nice Modula-3 debugger, but it is at least as far ahead of anything that could be done with the debug information that can be pushed through a C compiler. Read the m3gdb documentation. It is full of stuff that can't be done using C-produced debug info.

Going through C is a good way to simplify porting to new architectures, as well as just building/installing on a machine of already-supported architecture, but lacking a preexisting Modula-3 compiler. It's a nonstarter for decent debuggability.

It can/should be seen as merely an implementation detail.

As well, it should be noted, it doesn't translate to idiomatic C.

Yet another hit on ease of debugging.

It goes through same frontend/backend flow as the gcc backend -- the C it generates it just as low level as the gcc IR -- horrendously unreadable and somewhat unportable C.

Perhaps perhaps with the exception of how nested functions, "display" and "static link" work. That is represented in a somewhat higher level form, and doesn't take advantage of features in some ABIs that the gcc backend is able to.

  • Jay

From: Dariusz Knociński notifications@github.com Sent: Tuesday, April 4, 2017 6:45 AM To: modula3/cm3 Cc: jaykrell; Comment Subject: Re: [modula3/cm3] Porting CM3 to Haiku x86 32 bits (#16)

Do you think the "level" is key? Generally yes. If the Modula-3 is to be a system language then it must allow gnerating the machine code to the raw machine without the help of the C compiler.

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/modula3/cm3/issues/16#issuecomment-291408812, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABj1kPE4xQnnGxFXLZjgmdMTOyC82xkHks5rsecIgaJpZM4Mwwg_.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/modula3/cm3/issues/16#issuecomment-291412590, or mute the thread https://github.com/notifications/unsubscribe-auth/AGVctJXoUsIyQXg9429uXGgAC31XgSvYks5rsetNgaJpZM4Mwwg_.

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/modula3/cm3/issues/16#issuecomment-291570869, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABj1kM6DBRfN0sjjo72-wGOX-eC4rglvks5rsnwLgaJpZM4Mwwg_.

DKnoto commented 7 years ago

Hi Jay,

I did what you advised. Gcc-4.7 with CM3 has the i586-pc-haiku target but unfortunately this setup does not work: $ ../gcc-4.7/configure --host=amd64-linux --target=i586-pc-haiku ... $ make ... *** Configuration i586-pc-haiku not supported

Haiku uses gcc-5.4.0, can you approximate how much work to do to build CM3 based on this backend?

jaykrell commented 7 years ago

Sorry I never responded to this from a proper keyboard.

If you want to port Modula-3 to some new system, and you want to use the gcc backend, then you need gcc ported to that system.

And you need said port, which is probably a fork, merged into our fork of gcc.

Our fork of gcc is not heavy, but it is old, and it is not your fork (it is from mainline).

And you probably have a fork.

Find your baseline. Generate your diffs against that baseline. Apply them to ours.

Or vice versa, perhaps -- merge ours into yours. But this might be more work. And import your fork into our repository and have m3-sys/m3cc/m3makefile use it instead. We already have multiple gcc there to chose from.

As well, we don't use the vast majority of gcc, so most of your diffs can probably be ignored.

I have as I recall merged three forks into our fork of mainline: Apple, OpenBSD, Interix. Most of this was stuff like chosing size_t/ptrdiff_t in C -- ignore Or having -fPIC be ignored on Interix since it produces incorrect code (debug that..)

As to what gcc we require to compile our C or link, almost anything will work.

If you want to use the C backend, then you have even less work to do.

Which reminds me -- you do have to grovel through a few pieces of m3-libs/m3core and add your target. Like declaring if it is little endian or big, 32bit or 64bit, and Posix or NT, or some new thing -- you might have to rewrite the file i/o layers for example.

This isn't all in m3-libs/m3core -- m3-sys/m3middle/Target.m3 needs attention. I have narrowed down what all parts you need to touch to port and documented then. There was older documentation that isn't wrong per se, just that it is a superset.

I'd really like to move to the C backend and have its output be the same across all targets, and move any target-specific code into C/C++, possibly under the influence of autoconf or cmake, so that many kinds of ports are automated.

We really have precious little code that depends on x86 vs. sparc, or 32bit vs. 64bit, or little endian vs. big endian, that as well can't do math using BITSIZE or BYTESIZE or runtime checks. There is a large incorrect tendency in software to over specialize code in my opinion, or to think something is over specific when it isn't. i.e. most "Linux" code is "Posix", or even portable to Windows. Not all. There really are variations in the systems and really is code that depends on it.

None of this is much work really.

From: Dariusz Knociński notifications@github.com Sent: Sunday, April 9, 2017 11:12 AM To: modula3/cm3 Cc: jaykrell; Comment Subject: Re: [modula3/cm3] Porting CM3 to Haiku x86 32 bits (#16)

Hi Jay,

I did what you advised. Gcc-4.7 with CM3 has the i586-pc-haiku target but unfortunately this setup does not work: $ ../gcc-4.7/configure --host=amd64-linux --target=i586-pc-haiku ... $ make ... *** Configuration i586-pc-haiku not supported

Haiku uses gcc-5.4.0, can you approximate how much work to do to build CM3 based on this backend?

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/modula3/cm3/issues/16#issuecomment-292779375, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABj1kEBEnpHbO61rFgrgFxz_2C0NLazAks5ruL0dgaJpZM4Mwwg_.

jaykrell commented 3 years ago

I know that people feel somehow unsatisfied with the C backend. It does not mean that Modula-3 is somehow not a real programming language. You can write a backend in Modula-3. There is one in the system. The NT386 backend writes out .obj files. But then we still depend on the system linker. And debugger. And kernel.

And the other backend so often discussed, based on GCC, also doesn't really do codegen in Modula-3 either. It is the GCC backend, written in C/C++, and a custom frontend, also in C/C++, that reads the Modula-3 IR from files. The Modula-3 in this system "stops" at writing IR to files. It still does a lot. It still does all the source parsing and type checking. So there is still a ton of C/C++ code involved.

Whether or not there is an extra intermediate represenation hop as textual C code, does not matter.

The C backend has successfully run on a number of systems and imho proven its value. The gcc-based backend has some advantages, but it is much more work to maintain, and not worthwhile imho. It was last updated to gcc 4.7.

It is true we could write our own smaller faster backend, producing moderately decent code. Again, we have one such. We should port it. But for great breadth of target support and speed of bringup, C is good. Sorry to belabor this point so many times through the years. Now I need to update the C backend slightly and bring up some new targets rapidly. :)

jaykrell commented 3 years ago

And yeah, someone should try the C backend on Haiku.

mikanystrom commented 3 years ago

I, for one, am not concerned that your backend runs slower. I'm more concerned that the extra indirection through the generated C code loses enough information to reduce the performance (speed or memory or ... features?) of the compiled Modula-3 code. Tony was talking about how it makes the GC more difficult in some way...I forgot the details.

I use Modula-3 for things I used to use C or Fortran for. Performance and code quality can be important (not always, sure, but sometimes it is). And it needs to work... the quality of the gcc backend seems quite good (I agree that it's a bit surprising that it is still OK after being a dusty deck for so long).

Of course it would be great to have a super portable implementation that works well notwithstanding all of the above, so I think it's great you're working on it!

 Mika

On Tue, Feb 23, 2021 at 4:23 PM Jay Krell notifications@github.com wrote:

I know that people feel somehow unsatisfied with the C backend. It does not mean that Modula-3 is somehow not a real programming language. You can write a backend in Modula-3. There is one in the system. The NT386 backend writes out .obj files. But then we still depend on the system linker. And debugger. And kernel.

And the other backend so often discussed, based on GCC, also doesn't really do codegen in Modula-3 either. It is the GCC backend, written in C/C++, and a custom frontend, also in C/C++, that reads the Modula-3 IR from files. The Modula-3 in this system "stops" at writing IR to files. It still does a lot. It still does all the source parsing and type checking. So there is still a ton of C/C++ code involved.

Whether or not there is an extra intermediate represenation hop as textual C code, does not matter.

The C backend has successfully run on a number of systems and imho proven its value. The gcc-based backend has some advantages, but it is much more work to maintain, and not worthwhile imho. It was last updated to gcc 4.7.

It is true we could write our own smaller faster backend, producing moderately decent code. Again, we have one such. We should port it. But for great breadth of target support and speed of bringup, C is good. Sorry to belabor this point so many times through the years. Now I need to update the C backend slightly and bring up some new targets rapidly. :)

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/modula3/cm3/issues/16#issuecomment-784632329, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABKYNJLHWJ4SYVCG45MWVTDTARBJPANCNFSM4DGDBA7Q .

jaykrell commented 3 years ago

I have a feeling, though I don't know, that the C compiles about the same as m3cc.

I think they both have problems because of garbage collection.

I have a few ideas to speed it up.

The gcc still works, yes, for older targets. But now I want ARM64_{NT,LINUX,DARWIN} and RISCV64_LINUX. :) And the C backend gave us AMD64_NT and I believe ARM32_LINUX. It also works well to cross/bootstrap from NT. I don't have to build gcc there. :)

RodneyBates commented 3 years ago

My only dissatisfaction with (any) C back end is debug info. The C language itself and some C compilers for it are entirely inadequate conduits for Modula-3 debug information. m3gdb has lots of M3-specific functions that can't be provided through C. And it needs some more.

Just a few examples: you can type a dispatching method call in m3gdb and it will dispatch. Or you can name the method of a runtime object, without the parentheses, thus not a call, and see the plain procedure it denotes and would dispatch to, if called. You can print nonlocal variables. You don't need mangled names. The documentation pretty well covers it and often identifies additional needs.

The debug info is a horribly cobbled up thing, with lots of stuff that is not actually stabs at all, just wrapped inside stabs. But m3cc and the integrated backend pipe it right on through to object modules, unchanged, so the front end and m3gdb can communicate whatever is needed.

I had great hopes for llvm, because, according to its documentation, it not only handles (a semantically equivalent of) Dwarf, but alters it to reflect optimizations. And Dwarf is, as far as I can see, entirely adequate for Modula-3 debug info. And it's not such a mess. Sadly, it turns out that llvm only does this for a rather severe subset of Dwarf, presumably just what is needed for the languages it truly supports.

O 2/23/21 6:23 PM, Jay Krell wrote:

I know that people feel somehow unsatisfied with the C backend. It does not mean that Modula-3 is somehow not a real programming language. You can write a backend in Modula-3. There is one in the system. The NT386 backend writes out .obj files. But then we still depend on the system linker. And debugger. And kernel.

And the other backend so often discussed, based on GCC, also doesn't really do codegen in Modula-3 either. It is the GCC backend, written in C/C++, and a custom frontend, also in C/C++, that reads the Modula-3 IR from files. The Modula-3 in this system "stops" at writing IR to files. It still does a lot. It still does all the source parsing and type checking. So there is still a ton of C/C++ code involved.

Whether or not there is an extra intermediate represenation hop as textual C code, does not matter.

It matters greatly for a debugger.

The C backend has successfully run on a number of systems and imho proven its value. The gcc-based backend has some advantages, but it is much more work to maintain, and not worthwhile imho. It was last updated to gcc 4.7.

It is true we could write our own smaller faster backend, producing moderately decent code. Again, we have one such. We should port it. But for great breadth of target support and speed of bringup, C is good. Sorry to belabor this point so many times through the years. Now I need to update the C backend slightly and bring up some new targets rapidly. :)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/modula3/cm3/issues/16#issuecomment-784632329, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABSVZNF3NY27VC276KSVS3TTARBJNANCNFSM4DGDBA7Q.

jaykrell commented 3 years ago

Unfortunately, this approach makes it impossible to build an operating system in pure Modula-3.

No it does not. It does not matter what the compiler is written in. Unless you consider the compiler to be part of the operating system. But then, how about the BIOS and the boot loader? Or the hypervisor if you are using a virtual machine? Or the router your network traffic is going through. You are always going to be running C and C++ somehow. That doesn't mean you cannot use other languages or detract from their use.

As well, it should be noted, it doesn't translate to idiomatic C. Yet another hit on ease of debugging.

No it does not. There are line directives. You step through the Modula-3. The ugly C does not matter. Just like the ugly assembly does not matter.

jaykrell commented 3 years ago

The answer is to use the C backend. It is now to the point where the output is the same across many targets. I mean, run boot1.py I386_LINUX and copy the result to Haiku and see if it builds and runs. It quite likely will. Someday maybe I will try. I guess keep this open until then.

VictorMiasnikov commented 2 years ago

I see in https://github.com/modula3/cm3/discussions/833 comment https://github.com/modula3/cm3/discussions/833#discussioncomment-1983332

I ( DKnoto) have full version of CM3 on Haiku! Warnings still exists.

I.e. we can can close this issue?