How do I get started? #1188
blakemcbride
started this conversation in
General
How do I get started?
#1188
Replies: 13 comments 1 reply
-
|
Blake
That would be very welcome. I am sure you would get no opposition to including your documentation.
I am happy to help in any way I can. There are others here with more knowledge than I of installing,
rebootstrapping, multiple platforms, etc who would likely help too. I am most familiar with the
language, compiler, and libraries.
Rodney Bates
…On 11/15/24 16:12, Blake McBride wrote:
Greetings,
I am a long-time software engineer with a lot of C and Java experience running on a current Linux machine. I would like to play with CM3 a bit. However, I find the instructions inadequate. My sense is that if I play with it for a whole day I'll figure it out and get it working. However, I'd rather not spend hours figuring out really basic stuff. The problem is that there is obviously a lot of knowledge assumed in the docs that are unknown to someone new. For example:
1. I see the files:
|cm3-boot-AMD64_LINUX-d5.11.4.tar.xz cm3-dist-AMD64_LINUX-d5.11.4.tar.xz cm3-d5.11.4.tar.gz |
At this point, I just want to get the system up and running as easily as possible. It is unclear what I need, what is in each file, and the exact steps to follow to install and use the system.
My sense is that |cm3-d5.11.4.tar.gz| is just the complete raw source code to everything and I do not need it at this stage.
The word 'dist' in one of the files hints to me that this is an entire distribution already built. Other files hint that you have to build it with the 'boot' code first, and that it is not an already built distribution. It is all very unclear.
2, Build doesn't work
I went into the scripts directory of the 'dist' directory as instructed. It tells me a need a pre-existing CM3. I guess that;s the 'boot' stuff.
The boot stuff has no README and no documentation.
I tried:
|cmake . make |
That's doing something but I have no idea where to go from here.
Here is an offer. I am willing to spend the time to, with the help of the community, figure it all out and get it running. I will then write all of the documentation so that others can easily get up and running. (You can see a sample of me writing at https://blakemcbride.github.io/Dynace/manual/Dynace.pdf and https://blakemcbride.github.io/Kiss/manual/man/ The only think I ask is that there is a reasonable change the documentation will be incorporated into the CM3 distribution. In other words, I don't want to spend the time and write the document for myself alone.
—
Reply to this email directly, view it on GitHub <#1188>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABSVZNHDYCFYLEW7POBOZV32AZWTVAVCNFSM6AAAAABR4B5EXWVHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZXGQ4TCMZXGY>.
You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
1 reply
-
|
i tried to install cm3 several times. first times i failed. one time i was able to by building c (or c++?) version of cm3, then using it to bootstrap the m3 version of m3 i think. then later i failed to install some libraries i wanted to tinker with like trestle. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks, Rodney. Perhaps I can suggest that we, along with others that can help, communicate via email. This way we can communicate quickly and without filling up the message board. I am at blake@mcbridemail.com If you email me with a subject: CM3, I will add you to an email chain. Thanks! |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
I'd like to keep this in the M3 groups. There are people who should see it, and there is
usually not much other traffic.
…On 11/16/24 19:09, Blake McBride wrote:
Thanks, Rodney. Perhaps I can suggest that we, along with others that can help, communicate via email. This way we can communicate quickly and without filling up the message board. I am at ***@***.*** If you email me with a subject: CM3, I will add you to an email chain. Thanks!
—
Reply to this email directly, view it on GitHub <#1188 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABSVZNCW3OFJMMLPUBFHHBT2A7UDHAVCNFSM6AAAAABR4B5EXWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMRYGA4TIMA>.
You are receiving this because you commented.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
0 replies
-
|
I found the problem and the system builds just fine. The problem was the README files! The README files (README & scripts/README) disagree with what is said on the website. I had no way of knowing which was correct. I followed the README files which (as you'd guess) do not work. I then tried what was on the website but was left thinking I somehow needed a pre-existing CM3 (which I now understand it builds). This led me on a fruitless odyssey. I still think a better "getting started" doc is necessary. I also think depending in the wiki page is very bad. If you download and archive an old version, and then try to resurrect it years later, you can't build it because the wiki page is gone. You need this information in the README file. Having a wiki page also is fine. I feel strongly that all of the important information like building, using, overview, user manual, etc. should always be pat of the distribution. Again, we're all going to die some day. Our websites will disappear. But people who download the distribution will be left with junk if all of the documentation is gone. I will start to write up the documentation. I'll surely need a lot of answers to questions since I know very little. I am inclined to use texinfo to do these docs. It should look something like this https://blakemcbride.github.io/Kiss/manual/man/ and this https://blakemcbride.us/software/kiss/Kiss.pdf I am also hopeful it would be included in the distribution so that it would survive the disappearance of a wiki. |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Hi Blake,
I think our experience (we = a small group of people at Intel) recently has
been that you can indeed build CM3 directly from sources without
bootstrapping from a binary release.
The traditional method is to bootstrap using a binary distribution for your
host and using that to rebuild everything in an "upgrade" mode.
Jay Krell put a lot of effort into making a C++-based version of CM3 that
works differently. It compiles into C and then links with a C++ linker.
I think the first thing to understand is that there are multiple different
compiler back-ends included with CM3. There's an integrated x86 back-end
(for Windows), there is a "native" back-end that uses a modified version of
gcc as a back-end, and there's a newer version that compiles the M3 code
into C, which it then compiles with the C compiler. In both of the latter
cases, the C++ compiler (g++) is used for linking. It's been so many years
since I used M3 on (native) Windows that I don't remember how that system
works. There are plenty of ways of using the "unix" CM3 on Windows (WSL,
cygwin, ...) so I've done it that way for over ten years.
Our experience has been that yes you can build from the C version, but
there are a few things that don't work well with it. One of the things
that's a must-have for us is interoperability with C (and Fortran), and
(ironically?) I am not quite sure how to get that working with the C-based
compiler. What has worked for decades just doesn't seem to work with the
new compiler and fails in ways that are not obviously easy to debug (at
least not to me).
So what we were able to do is that we built the system using the C-based
back-end, and then used that to compile the "native" back end (which took
hacking a couple of lines in one of the build scripts, so it's not a fully
automatic process by any means). Then the native back end seems to work as
it always has. But no binary bootstrap is required doing it this way.
I will try to get you more detailed information this coming week if you
want to know more about our experience. Our goal is actually to
open-source a bit of M3 code, but we need to make sure we know how to build
it before we publish anything further.
Mika
…On Sun, Nov 17, 2024 at 11:10 AM Blake McBride ***@***.***> wrote:
I found the problem and the system builds just fine. The problem was the
README files! The README files (README & scripts/README) disagree with what
is said on the website. I had no way of knowing which was correct. I
followed the README files which (as you'd guess) do not work.
I then tried what was on the website but was left thinking I somehow
needed a pre-existing CM3 (which I now understand it builds). This led me
on a fruitless odyssey.
I still think a better "getting started" doc is necessary. I also think
depending in the wiki page is very bad. If you download and archive an old
version, and then try to resurrect it years later, you can't build it
because the wiki page is gone. You need this information in the README
file. Having a wiki page ALSO is fine.
I feel strongly that all of the important information like building,
using, overview, user manual, etc. should always be pat of the
distribution. Again, we're all going to die some day. Our websites will
disappear. But people who download the distribution will be left with junk
if all of the documentation is gone.
I will start to write up the documentation. I'll surely need a lot of
answers to questions since I know very little. I am inclined to use texinfo
to do these docs. It soule look something like this
https://blakemcbride.github.io/Kiss/manual/man/ and this
https://blakemcbride.us/software/kiss/Kiss.pdf I am also hopeful it would
be included in the distribution so that it would survive the disappearance
of a wiki.
—
Reply to this email directly, view it on GitHub
<#1188 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABKYNJJNLW6KWHXWRWRBM632BDS3TAVCNFSM6AAAAABR4B5EXWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMRYGQ4TEMQ>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Hello Mika,
Thank you for the input!
What I gather is that the three back-ends are:
- A Windows-specific back-end that generates an exe directly.
- A modified GCC back-end
- A compiler to C
Is that an accurate summary? When I download and run through their current build process on my Linux box, which am I using?
Are some of those back-ends being deprecated?
Which are considered the future?
Yes, getting more details would be very interesting and helpful. Thank you!
Meanwhile, I think the first step is to correct the README files by putting correct build instructions into them.
If people like, I can make the changes and do a pull request. As I learn more, I'll add to them.
Thanks!
Blake
…On Sunday, November 17th, 2024 at 2:08 PM, Mika Nyström ***@***.***> wrote:
Hi Blake,
I think our experience (we = a small group of people at Intel) recently has
been that you can indeed build CM3 directly from sources without
bootstrapping from a binary release.
The traditional method is to bootstrap using a binary distribution for your
host and using that to rebuild everything in an "upgrade" mode.
Jay Krell put a lot of effort into making a C++-based version of CM3 that
works differently. It compiles into C and then links with a C++ linker.
I think the first thing to understand is that there are multiple different
compiler back-ends included with CM3. There's an integrated x86 back-end
(for Windows), there is a "native" back-end that uses a modified version of
gcc as a back-end, and there's a newer version that compiles the M3 code
into C, which it then compiles with the C compiler. In both of the latter
cases, the C++ compiler (g++) is used for linking. It's been so many years
since I used M3 on (native) Windows that I don't remember how that system
works. There are plenty of ways of using the "unix" CM3 on Windows (WSL,
cygwin, ...) so I've done it that way for over ten years.
Our experience has been that yes you can build from the C version, but
there are a few things that don't work well with it. One of the things
that's a must-have for us is interoperability with C (and Fortran), and
(ironically?) I am not quite sure how to get that working with the C-based
compiler. What has worked for decades just doesn't seem to work with the
new compiler and fails in ways that are not obviously easy to debug (at
least not to me).
So what we were able to do is that we built the system using the C-based
back-end, and then used that to compile the "native" back end (which took
hacking a couple of lines in one of the build scripts, so it's not a fully
automatic process by any means). Then the native back end seems to work as
it always has. But no binary bootstrap is required doing it this way.
I will try to get you more detailed information this coming week if you
want to know more about our experience. Our goal is actually to
open-source a bit of M3 code, but we need to make sure we know how to build
it before we publish anything further.
Mika
On Sun, Nov 17, 2024 at 11:10 AM Blake McBride ***@***.***>
wrote:
> I found the problem and the system builds just fine. The problem was the
> README files! The README files (README & scripts/README) disagree with what
> is said on the website. I had no way of knowing which was correct. I
> followed the README files which (as you'd guess) do not work.
>
> I then tried what was on the website but was left thinking I somehow
> needed a pre-existing CM3 (which I now understand it builds). This led me
> on a fruitless odyssey.
>
> I still think a better "getting started" doc is necessary. I also think
> depending in the wiki page is very bad. If you download and archive an old
> version, and then try to resurrect it years later, you can't build it
> because the wiki page is gone. You need this information in the README
> file. Having a wiki page ALSO is fine.
>
> I feel strongly that all of the important information like building,
> using, overview, user manual, etc. should always be pat of the
> distribution. Again, we're all going to die some day. Our websites will
> disappear. But people who download the distribution will be left with junk
> if all of the documentation is gone.
>
> I will start to write up the documentation. I'll surely need a lot of
> answers to questions since I know very little. I am inclined to use texinfo
> to do these docs. It soule look something like this
> https://blakemcbride.github.io/Kiss/manual/man/ and this
> https://blakemcbride.us/software/kiss/Kiss.pdf I am also hopeful it would
> be included in the distribution so that it would survive the disappearance
> of a wiki.
>
> —
> Reply to this email directly, view it on GitHub
> <#1188 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ABKYNJJNLW6KWHXWRWRBM632BDS3TAVCNFSM6AAAAABR4B5EXWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMRYGQ4TEMQ>
> .
> You are receiving this because you are subscribed to this thread.Message
> ID: ***@***.***>
>
—
Reply to this email directly, [view it on GitHub](#1188 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/ABRLAAAPQMT464UWWWGKYWD2BDZTRAVCNFSM6AAAAABR4B5EXWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMRYGUYTOMQ).
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Well... I think Jay wanted the C compiler to be the future, because it is a
lot easier to maintain.
At this point, I think it's actually pretty cool that the C compiler is
good enough to be able to bootstrap the native compiler. It means that
binary distributions are no longer necessary.
I don't know that there is anyone willing to put in what might be really
significant effort to get the C-based back-end working across the board...
anyone on the list can correct me if I am wrong!
Mika
On Sun, Nov 17, 2024 at 4:27 PM Blake McBride ***@***.***>
wrote:
… Hello Mika,
Thank you for the input!
What I gather is that the three back-ends are:
- A Windows-specific back-end that generates an exe directly.
- A modified GCC back-end
- A compiler to C
Is that an accurate summary? When I download and run through their current
build process on my Linux box, which am I using?
Are some of those back-ends being deprecated?
Which are considered the future?
Yes, getting more details would be very interesting and helpful. Thank you!
Meanwhile, I think the first step is to correct the README files by
putting correct build instructions into them.
If people like, I can make the changes and do a pull request. As I learn
more, I'll add to them.
Thanks!
Blake
On Sunday, November 17th, 2024 at 2:08 PM, Mika Nyström ***@***.***> wrote:
> Hi Blake,
>
> I think our experience (we = a small group of people at Intel) recently
has
> been that you can indeed build CM3 directly from sources without
> bootstrapping from a binary release.
>
> The traditional method is to bootstrap using a binary distribution for
your
> host and using that to rebuild everything in an "upgrade" mode.
>
> Jay Krell put a lot of effort into making a C++-based version of CM3 that
> works differently. It compiles into C and then links with a C++ linker.
>
> I think the first thing to understand is that there are multiple
different
> compiler back-ends included with CM3. There's an integrated x86 back-end
> (for Windows), there is a "native" back-end that uses a modified version
of
> gcc as a back-end, and there's a newer version that compiles the M3 code
> into C, which it then compiles with the C compiler. In both of the latter
> cases, the C++ compiler (g++) is used for linking. It's been so many
years
> since I used M3 on (native) Windows that I don't remember how that system
> works. There are plenty of ways of using the "unix" CM3 on Windows (WSL,
> cygwin, ...) so I've done it that way for over ten years.
>
> Our experience has been that yes you can build from the C version, but
> there are a few things that don't work well with it. One of the things
> that's a must-have for us is interoperability with C (and Fortran), and
> (ironically?) I am not quite sure how to get that working with the
C-based
> compiler. What has worked for decades just doesn't seem to work with the
> new compiler and fails in ways that are not obviously easy to debug (at
> least not to me).
>
> So what we were able to do is that we built the system using the C-based
> back-end, and then used that to compile the "native" back end (which took
> hacking a couple of lines in one of the build scripts, so it's not a
fully
> automatic process by any means). Then the native back end seems to work
as
> it always has. But no binary bootstrap is required doing it this way.
>
> I will try to get you more detailed information this coming week if you
> want to know more about our experience. Our goal is actually to
> open-source a bit of M3 code, but we need to make sure we know how to
build
> it before we publish anything further.
>
> Mika
>
> On Sun, Nov 17, 2024 at 11:10 AM Blake McBride ***@***.***>
> wrote:
>
>> I found the problem and the system builds just fine. The problem was the
>> README files! The README files (README & scripts/README) disagree with
what
>> is said on the website. I had no way of knowing which was correct. I
>> followed the README files which (as you'd guess) do not work.
>>
>> I then tried what was on the website but was left thinking I somehow
>> needed a pre-existing CM3 (which I now understand it builds). This led
me
>> on a fruitless odyssey.
>>
>> I still think a better "getting started" doc is necessary. I also think
>> depending in the wiki page is very bad. If you download and archive an
old
>> version, and then try to resurrect it years later, you can't build it
>> because the wiki page is gone. You need this information in the README
>> file. Having a wiki page ALSO is fine.
>>
>> I feel strongly that all of the important information like building,
>> using, overview, user manual, etc. should always be pat of the
>> distribution. Again, we're all going to die some day. Our websites will
>> disappear. But people who download the distribution will be left with
junk
>> if all of the documentation is gone.
>>
>> I will start to write up the documentation. I'll surely need a lot of
>> answers to questions since I know very little. I am inclined to use
texinfo
>> to do these docs. It soule look something like this
>> https://blakemcbride.github.io/Kiss/manual/man/ and this
>> https://blakemcbride.us/software/kiss/Kiss.pdf I am also hopeful it
would
>> be included in the distribution so that it would survive the
disappearance
>> of a wiki.
>>
>> —
>> Reply to this email directly, view it on GitHub
>> <
#1188 (comment)
>,
>> or unsubscribe
>> <
https://github.com/notifications/unsubscribe-auth/ABKYNJJNLW6KWHXWRWRBM632BDS3TAVCNFSM6AAAAABR4B5EXWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMRYGQ4TEMQ
>
>> .
>> You are receiving this because you are subscribed to this thread.Message
>> ID: ***@***.***>
>>
>
> —
> Reply to this email directly, [view it on GitHub](
#1188 (comment)),
or [unsubscribe](
https://github.com/notifications/unsubscribe-auth/ABRLAAAPQMT464UWWWGKYWD2BDZTRAVCNFSM6AAAAABR4B5EXWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMRYGUYTOMQ
).
> You are receiving this because you authored the thread.Message ID:
***@***.***>
—
Reply to this email directly, view it on GitHub
<#1188 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABKYNJKO4AXATINOT5EDANT2BEX5VAVCNFSM6AAAAABR4B5EXWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMRYGYYTOMY>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
0 replies
-
|
On 11/17/24 18:27, Blake McBride wrote:
Hello Mika,
Thank you for the input!
What I gather is that the three back-ends are:
- A Windows-specific back-end that generates an exe directly.
This one works on Linux too, but only X86 CPUs. Usually referred-to
as the integrated back end. Linked into same executable with the front end.
- A modified GCC back-end
Front end output is in a file in a CM3-specific internal notation, which
the modified GCC reads. Historically, I understand this was done to avoid
having the GPL of GCC propagate into the front end.
- A compiler to C
Linked into same executable with the front end.
Also,
- A compiler that makes calls directly on linked-in LLVM.
Usually code goes through the native assembler, but the different
back ends have some varying alternatives here. The variety of backend
modes is dizzying, not all necessarily very useful.
Is that an accurate summary? When I download and run through their current build process on my Linux box, which am I using?
Most likely the GCC back end. That is what my installed CM3 uses.
I don't recall changing the backend mode from the distribution.
Are some of those back-ends being deprecated?
I don't think so, although I suspect the integrated back end gets little use these days.
Which are considered the future?
Just IMO, but LLVM provides the best debug info for a really good M3 debugger,
which we don't have. m3gdb, which is indispensible to me and constantly
used by me, has a lot of M3-specific capabilities, but needs quite a bit more
to be really good. It reads the debug info produced by the integrated and
GCC back ends, which is an extensibly bastardized variant of stabs. It's
derived from an old gdb so also handles pretty much everything that gdb does.
C code regardless of how produced, carries far too little info to support
much of anything specific to M3. My hopes for a better debugger depend on
LLVM, but AFIK, no work being done on that.
Yes, getting more details would be very interesting and helpful. Thank you!
Meanwhile, I think the first step is to correct the README files by putting correct build instructions into them.
If people like, I can make the changes and do a pull request. As I learn more, I'll add to them.
Please do.
…
Thanks!
Blake
On Sunday, November 17th, 2024 at 2:08 PM, Mika Nyström ***@***.***> wrote:
> Hi Blake,
>
> I think our experience (we = a small group of people at Intel) recently has
> been that you can indeed build CM3 directly from sources without
> bootstrapping from a binary release.
>
> The traditional method is to bootstrap using a binary distribution for your
> host and using that to rebuild everything in an "upgrade" mode.
>
> Jay Krell put a lot of effort into making a C++-based version of CM3 that
> works differently. It compiles into C and then links with a C++ linker.
>
> I think the first thing to understand is that there are multiple different
> compiler back-ends included with CM3. There's an integrated x86 back-end
> (for Windows), there is a "native" back-end that uses a modified version of
> gcc as a back-end, and there's a newer version that compiles the M3 code
> into C, which it then compiles with the C compiler. In both of the latter
> cases, the C++ compiler (g++) is used for linking. It's been so many years
> since I used M3 on (native) Windows that I don't remember how that system
> works. There are plenty of ways of using the "unix" CM3 on Windows (WSL,
> cygwin, ...) so I've done it that way for over ten years.
>
> Our experience has been that yes you can build from the C version, but
> there are a few things that don't work well with it. One of the things
> that's a must-have for us is interoperability with C (and Fortran), and
> (ironically?) I am not quite sure how to get that working with the C-based
> compiler. What has worked for decades just doesn't seem to work with the
> new compiler and fails in ways that are not obviously easy to debug (at
> least not to me).
>
> So what we were able to do is that we built the system using the C-based
> back-end, and then used that to compile the "native" back end (which took
> hacking a couple of lines in one of the build scripts, so it's not a fully
> automatic process by any means). Then the native back end seems to work as
> it always has. But no binary bootstrap is required doing it this way.
>
> I will try to get you more detailed information this coming week if you
> want to know more about our experience. Our goal is actually to
> open-source a bit of M3 code, but we need to make sure we know how to build
> it before we publish anything further.
>
> Mika
>
> On Sun, Nov 17, 2024 at 11:10 AM Blake McBride ***@***.***>
> wrote:
>
>> I found the problem and the system builds just fine. The problem was the
>> README files! The README files (README & scripts/README) disagree with what
>> is said on the website. I had no way of knowing which was correct. I
>> followed the README files which (as you'd guess) do not work.
>>
>> I then tried what was on the website but was left thinking I somehow
>> needed a pre-existing CM3 (which I now understand it builds). This led me
>> on a fruitless odyssey.
>>
>> I still think a better "getting started" doc is necessary. I also think
>> depending in the wiki page is very bad. If you download and archive an old
>> version, and then try to resurrect it years later, you can't build it
>> because the wiki page is gone. You need this information in the README
>> file. Having a wiki page ALSO is fine.
>>
>> I feel strongly that all of the important information like building,
>> using, overview, user manual, etc. should always be pat of the
>> distribution. Again, we're all going to die some day. Our websites will
>> disappear. But people who download the distribution will be left with junk
>> if all of the documentation is gone.
>>
>> I will start to write up the documentation. I'll surely need a lot of
>> answers to questions since I know very little. I am inclined to use texinfo
>> to do these docs. It soule look something like this
>> https://blakemcbride.github.io/Kiss/manual/man/ and this
>> https://blakemcbride.us/software/kiss/Kiss.pdf I am also hopeful it would
>> be included in the distribution so that it would survive the disappearance
>> of a wiki.
>>
>> —
>> Reply to this email directly, view it on GitHub
>> <#1188 (comment)>,
>> or unsubscribe
>> <https://github.com/notifications/unsubscribe-auth/ABKYNJJNLW6KWHXWRWRBM632BDS3TAVCNFSM6AAAAABR4B5EXWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMRYGQ4TEMQ>
>> .
>> You are receiving this because you are subscribed to this thread.Message
>> ID: ***@***.***>
>>
>
> —
> Reply to this email directly, [view it on GitHub](#1188 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/ABRLAAAPQMT464UWWWGKYWD2BDZTRAVCNFSM6AAAAABR4B5EXWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMRYGUYTOMQ).
> You are receiving this because you authored the thread.Message ID: ***@***.***>
—
Reply to this email directly, view it on GitHub <#1188 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABSVZNCJHMU367BJJDTL56D2BEX5VAVCNFSM6AAAAABR4B5EXWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMRYGYYTOMY>.
You are receiving this because you commented.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Rodney, I think the standard in the distribution these days is the C
backend. At least I recall having to hack something to get the regular
gcc-based backend. As I described, it's possible to bootstrap the compiler
from Jay's C and build it all in C, and then change the settings, use the
C-based compiler to build the gcc-based compiler.
I have never tried the LLVM backend. m3gdb broke for me long ago and I
wasn't able to get it working again. I do miss it but have fancy debug
libraries ...
Mika
On Mon, Nov 18, 2024 at 12:22 PM Rodney M. Bates ***@***.***>
wrote:
…
On 11/17/24 18:27, Blake McBride wrote:
> Hello Mika,
>
> Thank you for the input!
>
> What I gather is that the three back-ends are:
>
> - A Windows-specific back-end that generates an exe directly.
This one works on Linux too, but only X86 CPUs. Usually referred-to
as the integrated back end. Linked into same executable with the front
end.
> - A modified GCC back-end
Front end output is in a file in a CM3-specific internal notation, which
the modified GCC reads. Historically, I understand this was done to
avoid
having the GPL of GCC propagate into the front end.
> - A compiler to C
Linked into same executable with the front end.
Also,
- A compiler that makes calls directly on linked-in LLVM.
Usually code goes through the native assembler, but the different
back ends have some varying alternatives here. The variety of backend
modes is dizzying, not all necessarily very useful.
>
> Is that an accurate summary? When I download and run through their
current build process on my Linux box, which am I using?
Most likely the GCC back end. That is what my installed CM3 uses.
I don't recall changing the backend mode from the distribution.
>
> Are some of those back-ends being deprecated?
I don't think so, although I suspect the integrated back end gets little
use these days.
>
> Which are considered the future?
Just IMO, but LLVM provides the best debug info for a really good M3
debugger,
which we don't have. m3gdb, which is indispensible to me and constantly
used by me, has a lot of M3-specific capabilities, but needs quite a bit
more
to be really good. It reads the debug info produced by the integrated and
GCC back ends, which is an extensibly bastardized variant of stabs. It's
derived from an old gdb so also handles pretty much everything that gdb
does.
C code regardless of how produced, carries far too little info to support
much of anything specific to M3. My hopes for a better debugger depend on
LLVM, but AFIK, no work being done on that.
>
> Yes, getting more details would be very interesting and helpful. Thank
you!
>
> Meanwhile, I think the first step is to correct the README files by
putting correct build instructions into them.
>
> If people like, I can make the changes and do a pull request. As I learn
more, I'll add to them.
Please do.
>
> Thanks!
>
> Blake
>
> On Sunday, November 17th, 2024 at 2:08 PM, Mika Nyström ***@***.***>
wrote:
>
> > Hi Blake,
> >
> > I think our experience (we = a small group of people at Intel)
recently has
> > been that you can indeed build CM3 directly from sources without
> > bootstrapping from a binary release.
> >
> > The traditional method is to bootstrap using a binary distribution for
your
> > host and using that to rebuild everything in an "upgrade" mode.
> >
> > Jay Krell put a lot of effort into making a C++-based version of CM3
that
> > works differently. It compiles into C and then links with a C++
linker.
> >
> > I think the first thing to understand is that there are multiple
different
> > compiler back-ends included with CM3. There's an integrated x86
back-end
> > (for Windows), there is a "native" back-end that uses a modified
version of
> > gcc as a back-end, and there's a newer version that compiles the M3
code
> > into C, which it then compiles with the C compiler. In both of the
latter
> > cases, the C++ compiler (g++) is used for linking. It's been so many
years
> > since I used M3 on (native) Windows that I don't remember how that
system
> > works. There are plenty of ways of using the "unix" CM3 on Windows
(WSL,
> > cygwin, ...) so I've done it that way for over ten years.
> >
> > Our experience has been that yes you can build from the C version, but
> > there are a few things that don't work well with it. One of the things
> > that's a must-have for us is interoperability with C (and Fortran),
and
> > (ironically?) I am not quite sure how to get that working with the
C-based
> > compiler. What has worked for decades just doesn't seem to work with
the
> > new compiler and fails in ways that are not obviously easy to debug
(at
> > least not to me).
> >
> > So what we were able to do is that we built the system using the
C-based
> > back-end, and then used that to compile the "native" back end (which
took
> > hacking a couple of lines in one of the build scripts, so it's not a
fully
> > automatic process by any means). Then the native back end seems to
work as
> > it always has. But no binary bootstrap is required doing it this way.
> >
> > I will try to get you more detailed information this coming week if
you
> > want to know more about our experience. Our goal is actually to
> > open-source a bit of M3 code, but we need to make sure we know how to
build
> > it before we publish anything further.
> >
> > Mika
> >
> > On Sun, Nov 17, 2024 at 11:10 AM Blake McBride ***@***.***>
> > wrote:
> >
> >> I found the problem and the system builds just fine. The problem was
the
> >> README files! The README files (README & scripts/README) disagree
with what
> >> is said on the website. I had no way of knowing which was correct. I
> >> followed the README files which (as you'd guess) do not work.
> >>
> >> I then tried what was on the website but was left thinking I somehow
> >> needed a pre-existing CM3 (which I now understand it builds). This
led me
> >> on a fruitless odyssey.
> >>
> >> I still think a better "getting started" doc is necessary. I also
think
> >> depending in the wiki page is very bad. If you download and archive
an old
> >> version, and then try to resurrect it years later, you can't build it
> >> because the wiki page is gone. You need this information in the
README
> >> file. Having a wiki page ALSO is fine.
> >>
> >> I feel strongly that all of the important information like building,
> >> using, overview, user manual, etc. should always be pat of the
> >> distribution. Again, we're all going to die some day. Our websites
will
> >> disappear. But people who download the distribution will be left with
junk
> >> if all of the documentation is gone.
> >>
> >> I will start to write up the documentation. I'll surely need a lot of
> >> answers to questions since I know very little. I am inclined to use
texinfo
> >> to do these docs. It soule look something like this
> >> https://blakemcbride.github.io/Kiss/manual/man/ and this
> >> https://blakemcbride.us/software/kiss/Kiss.pdf I am also hopeful it
would
> >> be included in the distribution so that it would survive the
disappearance
> >> of a wiki.
> >>
> >> —
> >> Reply to this email directly, view it on GitHub
> >> <
#1188 (comment)>,
> >> or unsubscribe
> >> <
https://github.com/notifications/unsubscribe-auth/ABKYNJJNLW6KWHXWRWRBM632BDS3TAVCNFSM6AAAAABR4B5EXWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMRYGQ4TEMQ>
> >> .
> >> You are receiving this because you are subscribed to this
thread.Message
> >> ID: ***@***.***>
> >>
> >
> > —
> > Reply to this email directly, [view it on GitHub](
#1188 (comment)),
or [unsubscribe](
https://github.com/notifications/unsubscribe-auth/ABRLAAAPQMT464UWWWGKYWD2BDZTRAVCNFSM6AAAAABR4B5EXWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMRYGUYTOMQ).
> > You are receiving this because you authored the thread.Message ID:
***@***.***>
>
> —
> Reply to this email directly, view it on GitHub <
#1188 (comment)>,
or unsubscribe <
https://github.com/notifications/unsubscribe-auth/ABSVZNCJHMU367BJJDTL56D2BEX5VAVCNFSM6AAAAABR4B5EXWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMRYGYYTOMY>.
> You are receiving this because you commented.Message ID: ***@***.***>
>
—
Reply to this email directly, view it on GitHub
<#1188 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABKYNJJWSTTQUF7RMVDQF632BJEBHAVCNFSM6AAAAABR4B5EXWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMRZGY2TENA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
0 replies
-
|
On 11/18/24 14:37, Mika Nyström wrote:
Rodney, I think the standard in the distribution these days is the C
backend. At least I recall having to hack something to get the regular
gcc-based backend. As I described, it's possible to bootstrap the compiler
from Jay's C and build it all in C, and then change the settings, use the
C-based compiler to build the gcc-based compiler.
I have never tried the LLVM backend. m3gdb broke for me long ago and I
wasn't able to get it working again. I do miss it but have fancy debug
libraries ...
m3gdb works for me on AND64_LINUX, and I have successfully rebuilt it in
the last perhaps 2 years. I doubt it has seen any changes on github in
that time.
There is one problem building it. As I recall, at some point
a gnu update of the linker changed a position-independent-code option to
reverse its meaning. So if you have an older linker, it works only as
distributed, otherwise only if the option is changed, as in my case.
I left it alone on github because I have no idea at what linker version
the change occurred in nor who might be using which. I have changed it
in my local copy. I saw no way to set it up to work with either linker
version.
If anybody wants to try it, I will dredge up the exact change needed.
The symptom is it builds and starts up but crashes the first time you
try to run the debuggee with a breakpoint set.
Despite its shortcomings, m3gdb does have quite a few nice Modula-3-specific
capabilities, for example executing a user-typed dispatching method call.
See docs/help/m3gdb/m3gdb-onepage.html
…
Mika
On Mon, Nov 18, 2024 at 12:22 PM Rodney M. Bates ***@***.***>
wrote:
>
>
> On 11/17/24 18:27, Blake McBride wrote:
> > Hello Mika,
> >
> > Thank you for the input!
> >
> > What I gather is that the three back-ends are:
> >
> > - A Windows-specific back-end that generates an exe directly.
> This one works on Linux too, but only X86 CPUs. Usually referred-to
> as the integrated back end. Linked into same executable with the front
> end.
>
> > - A modified GCC back-end
> Front end output is in a file in a CM3-specific internal notation, which
> the modified GCC reads. Historically, I understand this was done to
> avoid
> having the GPL of GCC propagate into the front end.
>
> > - A compiler to C
> Linked into same executable with the front end.
>
>
> Also,
> - A compiler that makes calls directly on linked-in LLVM.
>
>
> Usually code goes through the native assembler, but the different
> back ends have some varying alternatives here. The variety of backend
> modes is dizzying, not all necessarily very useful.
> >
> > Is that an accurate summary? When I download and run through their
> current build process on my Linux box, which am I using?
>
> Most likely the GCC back end. That is what my installed CM3 uses.
> I don't recall changing the backend mode from the distribution.
> >
> > Are some of those back-ends being deprecated?
>
> I don't think so, although I suspect the integrated back end gets little
> use these days.
> >
> > Which are considered the future?
>
> Just IMO, but LLVM provides the best debug info for a really good M3
> debugger,
> which we don't have. m3gdb, which is indispensible to me and constantly
> used by me, has a lot of M3-specific capabilities, but needs quite a bit
> more
> to be really good. It reads the debug info produced by the integrated and
> GCC back ends, which is an extensibly bastardized variant of stabs. It's
> derived from an old gdb so also handles pretty much everything that gdb
> does.
> C code regardless of how produced, carries far too little info to support
> much of anything specific to M3. My hopes for a better debugger depend on
> LLVM, but AFIK, no work being done on that.
>
> >
> > Yes, getting more details would be very interesting and helpful. Thank
> you!
> >
> > Meanwhile, I think the first step is to correct the README files by
> putting correct build instructions into them.
> >
> > If people like, I can make the changes and do a pull request. As I learn
> more, I'll add to them.
> Please do.
>
> >
> > Thanks!
> >
> > Blake
> >
> > On Sunday, November 17th, 2024 at 2:08 PM, Mika Nyström ***@***.***>
> wrote:
> >
> > > Hi Blake,
> > >
> > > I think our experience (we = a small group of people at Intel)
> recently has
> > > been that you can indeed build CM3 directly from sources without
> > > bootstrapping from a binary release.
> > >
> > > The traditional method is to bootstrap using a binary distribution for
> your
> > > host and using that to rebuild everything in an "upgrade" mode.
> > >
> > > Jay Krell put a lot of effort into making a C++-based version of CM3
> that
> > > works differently. It compiles into C and then links with a C++
> linker.
> > >
> > > I think the first thing to understand is that there are multiple
> different
> > > compiler back-ends included with CM3. There's an integrated x86
> back-end
> > > (for Windows), there is a "native" back-end that uses a modified
> version of
> > > gcc as a back-end, and there's a newer version that compiles the M3
> code
> > > into C, which it then compiles with the C compiler. In both of the
> latter
> > > cases, the C++ compiler (g++) is used for linking. It's been so many
> years
> > > since I used M3 on (native) Windows that I don't remember how that
> system
> > > works. There are plenty of ways of using the "unix" CM3 on Windows
> (WSL,
> > > cygwin, ...) so I've done it that way for over ten years.
> > >
> > > Our experience has been that yes you can build from the C version, but
> > > there are a few things that don't work well with it. One of the things
> > > that's a must-have for us is interoperability with C (and Fortran),
> and
> > > (ironically?) I am not quite sure how to get that working with the
> C-based
> > > compiler. What has worked for decades just doesn't seem to work with
> the
> > > new compiler and fails in ways that are not obviously easy to debug
> (at
> > > least not to me).
> > >
> > > So what we were able to do is that we built the system using the
> C-based
> > > back-end, and then used that to compile the "native" back end (which
> took
> > > hacking a couple of lines in one of the build scripts, so it's not a
> fully
> > > automatic process by any means). Then the native back end seems to
> work as
> > > it always has. But no binary bootstrap is required doing it this way.
> > >
> > > I will try to get you more detailed information this coming week if
> you
> > > want to know more about our experience. Our goal is actually to
> > > open-source a bit of M3 code, but we need to make sure we know how to
> build
> > > it before we publish anything further.
> > >
> > > Mika
> > >
> > > On Sun, Nov 17, 2024 at 11:10 AM Blake McBride ***@***.***>
> > > wrote:
> > >
> > >> I found the problem and the system builds just fine. The problem was
> the
> > >> README files! The README files (README & scripts/README) disagree
> with what
> > >> is said on the website. I had no way of knowing which was correct. I
> > >> followed the README files which (as you'd guess) do not work.
> > >>
> > >> I then tried what was on the website but was left thinking I somehow
> > >> needed a pre-existing CM3 (which I now understand it builds). This
> led me
> > >> on a fruitless odyssey.
> > >>
> > >> I still think a better "getting started" doc is necessary. I also
> think
> > >> depending in the wiki page is very bad. If you download and archive
> an old
> > >> version, and then try to resurrect it years later, you can't build it
> > >> because the wiki page is gone. You need this information in the
> README
> > >> file. Having a wiki page ALSO is fine.
> > >>
> > >> I feel strongly that all of the important information like building,
> > >> using, overview, user manual, etc. should always be pat of the
> > >> distribution. Again, we're all going to die some day. Our websites
> will
> > >> disappear. But people who download the distribution will be left with
> junk
> > >> if all of the documentation is gone.
> > >>
> > >> I will start to write up the documentation. I'll surely need a lot of
> > >> answers to questions since I know very little. I am inclined to use
> texinfo
> > >> to do these docs. It soule look something like this
> > >> https://blakemcbride.github.io/Kiss/manual/man/ and this
> > >> https://blakemcbride.us/software/kiss/Kiss.pdf I am also hopeful it
> would
> > >> be included in the distribution so that it would survive the
> disappearance
> > >> of a wiki.
> > >>
> > >> —
> > >> Reply to this email directly, view it on GitHub
> > >> <
> #1188 (comment)>,
>
> > >> or unsubscribe
> > >> <
> https://github.com/notifications/unsubscribe-auth/ABKYNJJNLW6KWHXWRWRBM632BDS3TAVCNFSM6AAAAABR4B5EXWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMRYGQ4TEMQ>
>
> > >> .
> > >> You are receiving this because you are subscribed to this
> thread.Message
> > >> ID: ***@***.***>
> > >>
> > >
> > > —
> > > Reply to this email directly, [view it on GitHub](
> #1188 (comment)),
> or [unsubscribe](
> https://github.com/notifications/unsubscribe-auth/ABRLAAAPQMT464UWWWGKYWD2BDZTRAVCNFSM6AAAAABR4B5EXWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMRYGUYTOMQ).
>
> > > You are receiving this because you authored the thread.Message ID:
> ***@***.***>
> >
> > —
> > Reply to this email directly, view it on GitHub <
> #1188 (comment)>,
> or unsubscribe <
> https://github.com/notifications/unsubscribe-auth/ABSVZNCJHMU367BJJDTL56D2BEX5VAVCNFSM6AAAAABR4B5EXWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMRYGYYTOMY>.
>
> > You are receiving this because you commented.Message ID: ***@***.***>
> >
>
> —
> Reply to this email directly, view it on GitHub
> <#1188 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ABKYNJJWSTTQUF7RMVDQF632BJEBHAVCNFSM6AAAAABR4B5EXWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMRZGY2TENA>
> .
> You are receiving this because you commented.Message ID:
> ***@***.***>
>
—
Reply to this email directly, view it on GitHub <#1188 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABSVZNC72UZKKPK7N6VU33D2BJFX3AVCNFSM6AAAAABR4B5EXWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMRZGY3DSMY>.
You are receiving this because you commented.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Respectfully, given the popularity of Modula-3, it seems to me that having multiple back-ends just complicates something already not popular. In other words, it diminishes Modula-3's attractiveness and adds build and maintenance complexity.
Is there a real need for all of these options?
Which is simpler? Which is more portable? Which works the best?
I am just wondering about these things.
If it is clear that a single back-end meets all of my above criteria, I would argue that removing the other back-ends is a good idea. Thus:
- The old back-end would still be available via git history.
-
Things would be a lot simpler.
-
This would reduce the entry barrier for new users.
-
This would focus maintenance efforts.
Just a thought...
Blake
…On Tuesday, November 19th, 2024 at 10:07 AM, Rodney Bates ***@***.***> wrote:
On 11/18/24 14:37, Mika Nyström wrote:
> Rodney, I think the standard in the distribution these days is the C
> backend. At least I recall having to hack something to get the regular
> gcc-based backend. As I described, it's possible to bootstrap the compiler
> from Jay's C and build it all in C, and then change the settings, use the
> C-based compiler to build the gcc-based compiler.
>
> I have never tried the LLVM backend. m3gdb broke for me long ago and I
> wasn't able to get it working again. I do miss it but have fancy debug
> libraries ...
m3gdb works for me on AND64_LINUX, and I have successfully rebuilt it in
the last perhaps 2 years. I doubt it has seen any changes on github in
that time.
There is one problem building it. As I recall, at some point
a gnu update of the linker changed a position-independent-code option to
reverse its meaning. So if you have an older linker, it works only as
distributed, otherwise only if the option is changed, as in my case.
I left it alone on github because I have no idea at what linker version
the change occurred in nor who might be using which. I have changed it
in my local copy. I saw no way to set it up to work with either linker
version.
If anybody wants to try it, I will dredge up the exact change needed.
The symptom is it builds and starts up but crashes the first time you
try to run the debuggee with a breakpoint set.
Despite its shortcomings, m3gdb does have quite a few nice Modula-3-specific
capabilities, for example executing a user-typed dispatching method call.
See docs/help/m3gdb/m3gdb-onepage.html
> Mika
>
> On Mon, Nov 18, 2024 at 12:22 PM Rodney M. Bates ***@***.***>
> wrote:
>
>>
>>
>> On 11/17/24 18:27, Blake McBride wrote:
>> > Hello Mika,
>> >
>> > Thank you for the input!
>> >
>> > What I gather is that the three back-ends are:
>> >
>> > - A Windows-specific back-end that generates an exe directly.
>> This one works on Linux too, but only X86 CPUs. Usually referred-to
>> as the integrated back end. Linked into same executable with the front
>> end.
>>
>> > - A modified GCC back-end
>> Front end output is in a file in a CM3-specific internal notation, which
>> the modified GCC reads. Historically, I understand this was done to
>> avoid
>> having the GPL of GCC propagate into the front end.
>>
>> > - A compiler to C
>> Linked into same executable with the front end.
>>
>>
>> Also,
>> - A compiler that makes calls directly on linked-in LLVM.
>>
>>
>> Usually code goes through the native assembler, but the different
>> back ends have some varying alternatives here. The variety of backend
>> modes is dizzying, not all necessarily very useful.
>> >
>> > Is that an accurate summary? When I download and run through their
>> current build process on my Linux box, which am I using?
>>
>> Most likely the GCC back end. That is what my installed CM3 uses.
>> I don't recall changing the backend mode from the distribution.
>> >
>> > Are some of those back-ends being deprecated?
>>
>> I don't think so, although I suspect the integrated back end gets little
>> use these days.
>> >
>> > Which are considered the future?
>>
>> Just IMO, but LLVM provides the best debug info for a really good M3
>> debugger,
>> which we don't have. m3gdb, which is indispensible to me and constantly
>> used by me, has a lot of M3-specific capabilities, but needs quite a bit
>> more
>> to be really good. It reads the debug info produced by the integrated and
>> GCC back ends, which is an extensibly bastardized variant of stabs. It's
>> derived from an old gdb so also handles pretty much everything that gdb
>> does.
>> C code regardless of how produced, carries far too little info to support
>> much of anything specific to M3. My hopes for a better debugger depend on
>> LLVM, but AFIK, no work being done on that.
>>
>> >
>> > Yes, getting more details would be very interesting and helpful. Thank
>> you!
>> >
>> > Meanwhile, I think the first step is to correct the README files by
>> putting correct build instructions into them.
>> >
>> > If people like, I can make the changes and do a pull request. As I learn
>> more, I'll add to them.
>> Please do.
>>
>> >
>> > Thanks!
>> >
>> > Blake
>> >
>> > On Sunday, November 17th, 2024 at 2:08 PM, Mika Nyström ***@***.***>
>> wrote:
>> >
>> > > Hi Blake,
>> > >
>> > > I think our experience (we = a small group of people at Intel)
>> recently has
>> > > been that you can indeed build CM3 directly from sources without
>> > > bootstrapping from a binary release.
>> > >
>> > > The traditional method is to bootstrap using a binary distribution for
>> your
>> > > host and using that to rebuild everything in an "upgrade" mode.
>> > >
>> > > Jay Krell put a lot of effort into making a C++-based version of CM3
>> that
>> > > works differently. It compiles into C and then links with a C++
>> linker.
>> > >
>> > > I think the first thing to understand is that there are multiple
>> different
>> > > compiler back-ends included with CM3. There's an integrated x86
>> back-end
>> > > (for Windows), there is a "native" back-end that uses a modified
>> version of
>> > > gcc as a back-end, and there's a newer version that compiles the M3
>> code
>> > > into C, which it then compiles with the C compiler. In both of the
>> latter
>> > > cases, the C++ compiler (g++) is used for linking. It's been so many
>> years
>> > > since I used M3 on (native) Windows that I don't remember how that
>> system
>> > > works. There are plenty of ways of using the "unix" CM3 on Windows
>> (WSL,
>> > > cygwin, ...) so I've done it that way for over ten years.
>> > >
>> > > Our experience has been that yes you can build from the C version, but
>> > > there are a few things that don't work well with it. One of the things
>> > > that's a must-have for us is interoperability with C (and Fortran),
>> and
>> > > (ironically?) I am not quite sure how to get that working with the
>> C-based
>> > > compiler. What has worked for decades just doesn't seem to work with
>> the
>> > > new compiler and fails in ways that are not obviously easy to debug
>> (at
>> > > least not to me).
>> > >
>> > > So what we were able to do is that we built the system using the
>> C-based
>> > > back-end, and then used that to compile the "native" back end (which
>> took
>> > > hacking a couple of lines in one of the build scripts, so it's not a
>> fully
>> > > automatic process by any means). Then the native back end seems to
>> work as
>> > > it always has. But no binary bootstrap is required doing it this way.
>> > >
>> > > I will try to get you more detailed information this coming week if
>> you
>> > > want to know more about our experience. Our goal is actually to
>> > > open-source a bit of M3 code, but we need to make sure we know how to
>> build
>> > > it before we publish anything further.
>> > >
>> > > Mika
>> > >
>> > > On Sun, Nov 17, 2024 at 11:10 AM Blake McBride ***@***.***>
>> > > wrote:
>> > >
>> > >> I found the problem and the system builds just fine. The problem was
>> the
>> > >> README files! The README files (README & scripts/README) disagree
>> with what
>> > >> is said on the website. I had no way of knowing which was correct. I
>> > >> followed the README files which (as you'd guess) do not work.
>> > >>
>> > >> I then tried what was on the website but was left thinking I somehow
>> > >> needed a pre-existing CM3 (which I now understand it builds). This
>> led me
>> > >> on a fruitless odyssey.
>> > >>
>> > >> I still think a better "getting started" doc is necessary. I also
>> think
>> > >> depending in the wiki page is very bad. If you download and archive
>> an old
>> > >> version, and then try to resurrect it years later, you can't build it
>> > >> because the wiki page is gone. You need this information in the
>> README
>> > >> file. Having a wiki page ALSO is fine.
>> > >>
>> > >> I feel strongly that all of the important information like building,
>> > >> using, overview, user manual, etc. should always be pat of the
>> > >> distribution. Again, we're all going to die some day. Our websites
>> will
>> > >> disappear. But people who download the distribution will be left with
>> junk
>> > >> if all of the documentation is gone.
>> > >>
>> > >> I will start to write up the documentation. I'll surely need a lot of
>> > >> answers to questions since I know very little. I am inclined to use
>> texinfo
>> > >> to do these docs. It soule look something like this
>> > >> https://blakemcbride.github.io/Kiss/manual/man/ and this
>> > >> https://blakemcbride.us/software/kiss/Kiss.pdf I am also hopeful it
>> would
>> > >> be included in the distribution so that it would survive the
>> disappearance
>> > >> of a wiki.
>> > >>
>> > >> —
>> > >> Reply to this email directly, view it on GitHub
>> > >> <
>> #1188 (comment)>,
>>
>> > >> or unsubscribe
>> > >> <
>> https://github.com/notifications/unsubscribe-auth/ABKYNJJNLW6KWHXWRWRBM632BDS3TAVCNFSM6AAAAABR4B5EXWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMRYGQ4TEMQ>
>>
>> > >> .
>> > >> You are receiving this because you are subscribed to this
>> thread.Message
>> > >> ID: ***@***.***>
>> > >>
>> > >
>> > > —
>> > > Reply to this email directly, [view it on GitHub](
>> #1188 (comment)),
>> or [unsubscribe](
>> https://github.com/notifications/unsubscribe-auth/ABRLAAAPQMT464UWWWGKYWD2BDZTRAVCNFSM6AAAAABR4B5EXWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMRYGUYTOMQ).
>>
>> > > You are receiving this because you authored the thread.Message ID:
>> ***@***.***>
>> >
>> > —
>> > Reply to this email directly, view it on GitHub <
>> #1188 (comment)>,
>> or unsubscribe <
>> https://github.com/notifications/unsubscribe-auth/ABSVZNCJHMU367BJJDTL56D2BEX5VAVCNFSM6AAAAABR4B5EXWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMRYGYYTOMY>.
>>
>> > You are receiving this because you commented.Message ID: ***@***.***>
>> >
>>
>> —
>> Reply to this email directly, view it on GitHub
>> [<#1188 (comment)>](https://github.com/modula3/cm3/discussions/1188#discussioncomment-11296524),
>> or unsubscribe
>> [<https://github.com/notifications/unsubscribe-auth/ABKYNJJWSTTQUF7RMVDQF632BJEBHAVCNFSM6AAAAABR4B5EXWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMRZGY2TENA>](https://github.com/notifications/unsubscribe-auth/ABKYNJJWSTTQUF7RMVDQF632BJEBHAVCNFSM6AAAAABR4B5EXWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMRZGY2TENA)
>> .
>> You are receiving this because you commented.Message ID:
>> ***@***.***>
>>
>
> —
> Reply to this email directly, [view it on GitHub](#1188 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/ABSVZNC72UZKKPK7N6VU33D2BJFX3AVCNFSM6AAAAABR4B5EXWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMRZGY3DSMY).
> You are receiving this because you commented.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
0 replies
-
|
On 11/19/24 10:24, Blake McBride wrote:
Respectfully, given the popularity of Modula-3, it seems to me that having multiple back-ends just complicates something already not popular. In other words, it diminishes Modula-3's attractiveness and adds build and maintenance complexity.
Is there a real need for all of these options?
Which is simpler? Which is more portable? Which works the best?
I am just wondering about these things.
If it is clear that a single back-end meets all of my above criteria, I would argue that removing the other back-ends is a good idea. Thus:
1. The old back-end would still be available via git history.
2.
Things would be a lot simpler.
3.
This would reduce the entry barrier for new users.
4.
This would focus maintenance efforts.
Just a thought...
Blake
The C backend's ability for bootstrapping on any machine is very valuable.
Well, any machine with a C compiler, but we can pretty much take that
for granted. Using it to bootstrap another back end circumvents its compiling
limitations and C language's and compilers' inability to funnel M3 debug info
through. It needs very little maintenance for this, and the process should be
entirely scriptable, so everyday users need not be aware of it. Aren't we
pretty close already?
The integrated back end compiles only to x86 and pretty much can be replaced
by the GCC backend.
I believe the majority of use these days is with the GCC backend. It supports a
lot of Modula-3 debugging. I has needed very little maintenance for a long time.
I think LLVM has not had a lot of testing. Its biggest drawback IMO, is the lack
of a M3 interactive debugger to go with it. That will be a lot of work, but
LLVM provides the best debug info by far, namely DWARF. LLVM seems to compile quite
a bit slower than GCC. But after decades of skepticism about the throw-more-
hardware-at-it-and-wait-for-Moore's-law philosophy, I don't think that matters
in today's world. Not for compiling, anyway. I doubt anybody will be running
a lot of compilation on smart thermostats. LLVM would probably help unravel
the licensing tangle.
So my suggestion is deprecate the integrated BE, keep the C BE for scripted
bootstrapping, use the GCC BE with m3gdb for everyday use, and aspire towards
a debugger for LLVM.
None of the back ends have been needing much maintenance.
…
On Tuesday, November 19th, 2024 at 10:07 AM, Rodney Bates ***@***.***> wrote:
>
>
> On 11/18/24 14:37, Mika Nyström wrote:
>> Rodney, I think the standard in the distribution these days is the C
>> backend. At least I recall having to hack something to get the regular
>> gcc-based backend. As I described, it's possible to bootstrap the compiler
>> from Jay's C and build it all in C, and then change the settings, use the
>> C-based compiler to build the gcc-based compiler.
>>
>> I have never tried the LLVM backend. m3gdb broke for me long ago and I
>> wasn't able to get it working again. I do miss it but have fancy debug
>> libraries ...
> —
>>
>> Reply to this email directly, view it on GitHub <#1188 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABSVZNC72UZKKPK7N6VU33D2BJFX3AVCNFSM6AAAAABR4B5EXWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMRZGY3DSMY>.
>> You are receiving this because you commented.Message ID: ***@***.***>
>>
>
|
Beta Was this translation helpful? Give feedback.
0 replies
-
|
I would agree with Rodney. The C backend's ability to bootstrap from
source code I think is extremely valuable. It's "not quite there yet" as
far as day-to-day usability and probably never will be as good as a
direct-generating backend because of the issues around tracking debugging
information.
You can use (and install, and bootstrap) the system without even knowing
that there is an integrated or LLVM backend included.
So I don't think you need to remove the backends you don't want to use.
I think the issue is more to ensure that the setup scripts are able to
build a usable compiler cleanly for the vast majority of users. This will
require (as of today) a two-step build process.
Anyhow, I think the reasons for the lack of popularity of Modula-3 don't
really have that much to do with technical issues. I think the reasons are
mostly legal fears or uncertainty (justified or not---I think mostly not
justified), a focus on very superficial matters (ALL CAPS, begin/end), or
just poor marketing on "our side".
That being said of course it would be nice and beneficial if it were
possible for a new user to download some sort of package and more or less
trivially get started.
There is another consideration here. It's possible that there's a few of
us that don't necessarily want much more attention for Modula-3. One
troubling aspect with open-source projects these days is that there seems
to be a *need* for them to constantly be "moving". It seems to be either
"move" or "die" for OSS today. If I may project a bit, the few people that
do use Modula-3 I think are likely quite happy that no one is "tinkering"
with the language. Even extremely minor changes to the language spec have
the potential to cause us users a lot of grief (we've seen that over the
years---Modula-3 is great at supporting lots of different hardware
architectures but it's really NOT very good at supporting multiple versions
of itself, multiple versions of the Modula-3 language supported by a single
code base that is). So let's say you did get a lot of attention for M3 and
attracted a bunch of open-source people to work on it. What would they
actually do? I hope they would do things like write new libraries (I know
I do that), or... write more compiler back-ends, fix m3gdb, etc. Yeah it's
not very "sexy" as open-source work goes, but it's better than attracting
people to try to build "Modula-3.1" or some such thing.
But of course I am always happy to see new users!
Mika
On Tue, Nov 19, 2024 at 10:32 AM Rodney M. Bates ***@***.***>
wrote:
…
On 11/19/24 10:24, Blake McBride wrote:
>
> Respectfully, given the popularity of Modula-3, it seems to me that
having multiple back-ends just complicates something already not popular.
In other words, it diminishes Modula-3's attractiveness and adds build and
maintenance complexity.
>
> Is there a real need for all of these options?
>
> Which is simpler? Which is more portable? Which works the best?
>
> I am just wondering about these things.
>
> If it is clear that a single back-end meets all of my above criteria, I
would argue that removing the other back-ends is a good idea. Thus:
>
> 1. The old back-end would still be available via git history.
> 2.
>
> Things would be a lot simpler.
>
> 3.
>
> This would reduce the entry barrier for new users.
>
> 4.
>
> This would focus maintenance efforts.
>
>
> Just a thought...
>
> Blake
>
The C backend's ability for bootstrapping on any machine is very valuable.
Well, any machine with a C compiler, but we can pretty much take that
for granted. Using it to bootstrap another back end circumvents its
compiling
limitations and C language's and compilers' inability to funnel M3 debug
info
through. It needs very little maintenance for this, and the process
should be
entirely scriptable, so everyday users need not be aware of it. Aren't we
pretty close already?
The integrated back end compiles only to x86 and pretty much can be
replaced
by the GCC backend.
I believe the majority of use these days is with the GCC backend. It
supports a
lot of Modula-3 debugging. I has needed very little maintenance for a
long time.
I think LLVM has not had a lot of testing. Its biggest drawback IMO, is
the lack
of a M3 interactive debugger to go with it. That will be a lot of work,
but
LLVM provides the best debug info by far, namely DWARF. LLVM seems to
compile quite
a bit slower than GCC. But after decades of skepticism about the
throw-more-
hardware-at-it-and-wait-for-Moore's-law philosophy, I don't think that
matters
in today's world. Not for compiling, anyway. I doubt anybody will be
running
a lot of compilation on smart thermostats. LLVM would probably help
unravel
the licensing tangle.
So my suggestion is deprecate the integrated BE, keep the C BE for
scripted
bootstrapping, use the GCC BE with m3gdb for everyday use, and aspire
towards
a debugger for LLVM.
None of the back ends have been needing much maintenance.
>
> On Tuesday, November 19th, 2024 at 10:07 AM, Rodney Bates ***@***.***>
wrote:
>>
>>
>> On 11/18/24 14:37, Mika Nyström wrote:
>>> Rodney, I think the standard in the distribution these days is the C
>>> backend. At least I recall having to hack something to get the regular
>>> gcc-based backend. As I described, it's possible to bootstrap the
compiler
>>> from Jay's C and build it all in C, and then change the settings, use
the
>>> C-based compiler to build the gcc-based compiler.
>>>
>>> I have never tried the LLVM backend. m3gdb broke for me long ago and I
>>> wasn't able to get it working again. I do miss it but have fancy debug
>>> libraries ...
>> —
>>>
>>> Reply to this email directly, view it on GitHub <
#1188 (comment)>,
or unsubscribe <
https://github.com/notifications/unsubscribe-auth/ABSVZNC72UZKKPK7N6VU33D2BJFX3AVCNFSM6AAAAABR4B5EXWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMRZGY3DSMY>.
>>> You are receiving this because you commented.Message ID: ***@***.***>
>>>
>>
>
—
Reply to this email directly, view it on GitHub
<#1188 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABKYNJJ4LUNES47P2VNLCPT2BN73JAVCNFSM6AAAAABR4B5EXWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCMZQHE4DEMI>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Greetings,
I am a long-time software engineer with a lot of C and Java experience running on a current Linux machine. I would like to play with CM3 a bit. However, I find the instructions inadequate. My sense is that if I play with it for a whole day, I'll figure it out and get it working. However, I'd rather not spend hours figuring out really basic stuff. The problem is that there is obviously a lot of knowledge assumed in the docs that is unknown to someone new. For example:
At this point, I just want to get the system up and running as easily as possible. It is unclear what I need, what is in each file, and the exact steps to follow to install and use the system.
My sense is that
cm3-d5.11.4.tar.gzis just the complete raw source code to everything, and I do not need it at this stage.The word 'dist' in one of the files hints to me that this is an entire distribution already built. Other files hint that you have to build it with the 'boot' code first, and that it is not an already built distribution. It is all very unclear.
2, Build doesn't work
I went into the scripts directory of the 'dist' directory as instructed. It tells me I need a pre-existing CM3. I guess that's the 'boot' stuff.
The boot stuff has no README and no documentation.
I tried:
That's doing something but I have no idea where to go from here.
Here is an offer. I am willing to spend the time to, with the help of the community, figure it all out and get it running. I will then write all of the documentation so that others can easily get up and running. (You can see a sample of my writing at https://blakemcbride.github.io/Dynace/manual/Dynace.pdf and https://blakemcbride.github.io/Kiss/manual/man/) The only thing I ask is that there is a reasonable chance the documentation will be incorporated into the CM3 distribution. In other words, I don't want to spend the time and write the document for myself alone.
Beta Was this translation helpful? Give feedback.
All reactions