Porting CM3 to Haiku x86 32 bits #16
Comments
|
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 ***@***.*** > 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
<#16>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AEDI7iJ7ZVzlzbY87oSyLmqSj5YqiXnwks5rr3RzgaJpZM4Mwwg_>
.
|
|
I think that gcc47 is the default backend in CM3. |
|
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 ***@***.***> 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
<#16 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AEDI7vnIFMqPkaiyoVix9wGTsy4PxSUjks5rr7BrgaJpZM4Mwwg_>
.
|
|
Ok. I use gcc-5.4 from Fedora 25. The AMD64_LINUX version compiles correctly with this compiler. |
|
Sorry, now I have gcc-6.3.1. |
|
I checked again. The command "cm3 -DM3CC_TARGET=AMD64_LINUX" executes correctly. |
|
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..
- Jay
…________________________________
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 GitHub<#16 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ABj1kJA5nksQQ8NTL1Yp6FErboeyeeanks5rr89kgaJpZM4Mwwg_>.
|
|
I have a fog in my head :( |
|
No. Where did you get this idea?
- Jay
… On Apr 2, 2017, at 3:18 AM, darko20 ***@***.***> 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 ***@***.***
> 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
> <#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.
|
|
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 :( |
|
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.
- Jay
… On Apr 3, 2017, at 11:59 AM, Dariusz Knociński ***@***.***> 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.
|
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. |
|
In addition, redundant levels in the compilation process are unnecessary load. |
|
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.
- 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 GitHub<#16 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ABj1kPE4xQnnGxFXLZjgmdMTOyC82xkHks5rsecIgaJpZM4Mwwg_>.
|
|
It is true the compilation process is a bit slow.
But so is even the gcc backend compared to the integrated NT386 backend.
- Jay
…________________________________
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 GitHub<#16 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ABj1kLSfBdjs9XJ6_j8_3LQP4zCToxvKks5rseffgaJpZM4Mwwg_>.
|
|
Jay understands your arguments and in this particular case I guess. |
|
On Tue, 04 Apr 2017 01:05:48 -0700 Dariusz Knociński ***@***.***> 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
|
|
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?
- Jay
… On Apr 4, 2017, at 1:47 AM, Olaf Wagner ***@***.***> wrote:
On Tue, 04 Apr 2017 01:05:48 -0700
Dariusz Knociński ***@***.***> 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.
|
|
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 <#16 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGVctPXFPWtCrcMauIw4RI_7V0zwzytSks5rsecIgaJpZM4Mwwg_>.
|
|
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 ***@***.***>
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 GitHub<#16 (comment)>, or mute the thread<https://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 <#16 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGVctJXoUsIyQXg9429uXGgAC31XgSvYks5rsetNgaJpZM4Mwwg_>.
|
|
On 04/04/2017 03:47 AM, Olaf Wagner wrote:
On Tue, 04 Apr 2017 01:05:48 -0700
Dariusz Knociński ***@***.***> 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 <#16 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGVctAW0qCaYHRO53zwdmbi85YP1Wqplks5rsgOKgaJpZM4Mwwg_>.
|
I remeber, it was SPIN OS. |
|
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. |
|
BTW. Why did not you try a development path like FPC + Lazarus? |
|
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)
- Jay
…________________________________
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 GitHub<#16 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ABj1kBv8LOu5dT-53Wm-tzIPLp58uP5Gks5rsqpHgaJpZM4Mwwg_>.
|
|
HOST=AMD64, Linux, gcc-6.3.1 |
|
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<something>/configure --host=amd64-linux --target=i586-pc-haiku
or
cm3src/.../gcc<something>/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.
- Jay
…________________________________
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 GitHub<#16 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ABj1kCQ5bJQHI8O-XdXaj-FHWz9dhSGsks5rsq0qgaJpZM4Mwwg_>.
|
|
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...)
- Jay
________________________________
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 ***@***.***>
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 GitHub<#16 (comment)>, or mute the thread<https://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 <#16 (comment)>, 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 GitHub<#16 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ABj1kM6DBRfN0sjjo72-wGOX-eC4rglvks5rsnwLgaJpZM4Mwwg_>.
|
|
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: Haiku uses gcc-5.4.0, can you approximate how much work to do to build CM3 based on this backend? |
|
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.
- Jay
…________________________________
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 GitHub<#16 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ABj1kEBEnpHbO61rFgrgFxz_2C0NLazAks5ruL0dgaJpZM4Mwwg_>.
|
|
I know that people feel somehow unsatisfied with the C backend. And the other backend so often discussed, based on GCC, also doesn't really do codegen in Modula-3 either. 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. It is true we could write our own smaller faster backend, producing moderately decent code. |
|
And yeah, someone should try the C backend on Haiku. |
|
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 ***@***.***> 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
<#16 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABKYNJLHWJ4SYVCG45MWVTDTARBJPANCNFSM4DGDBA7Q>
.
|
|
I have a feeling, though I don't know, that the C compiles I think they both have problems because of garbage collection. I have a few ideas to speed it up.
This is really the easy thing to do and will help.
touch foo.m3 bar.m3 abc.m3 but I don't see how that'd really work, when you link. Unless, well, um. And then you link foobar.o foobarabc.o all-the-function-pointers.o For the data also. Kinda complicated, but it'd by running the C compiler The gcc still works, yes, for older targets. |
|
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 <#16 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABSVZNF3NY27VC276KSVS3TTARBJNANCNFSM4DGDBA7Q>.
|
No it does not.
No it does not. There are line directives. You step through the Modula-3. |
|
The answer is to use the C backend. |
|
I see in #833 comment #833 (reply in thread)
I.e. we can can close this issue? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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... yeschecking if mkdir takes one argument... no*** Configuration i586-pc-haiku not supportedMakefile:3413: recipe for target 'configure-gcc' failedmake: *** [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 failedI tried manually to run gcc47 compiling commands but I did not go much further.
The text was updated successfully, but these errors were encountered: