Support Pelles C as C compiler

[ghost]

Pelles C is Windows only. Able to generate both 32 bit and 64 bit binaries. CMake doesn't support Pelles C but since Pelles C is Windows only, you can do something to add support for it (maybe custom build scripts for just Pelles C? or extends existing build scripts? the ones based on cmake obviously will not works without extra works). This is about the external builder, the internal part is also needed to cover. cm3 itself has to be modifed to support Pelles C as the C compiler.

Why Pelles C? Pelles C is small and lightweight. MSVC and mingw64 are beasts, eating gigabytes of precious disk space. Pelles C is widely used to other project. e.g: OpenDylan use Pelles C as C compiler on Windows.

https://opendylan.org/download/#installation-on-windows

Oh almost forgot, this is Pelles C: http://www.smorgasbordet.com/pellesc/

[VictorMiasnikov]

I remember some discussions . . .

https://m3lists.elegosoft.com/pipermail/m3devel/2021-March.txt {{

free C tools (e.g. Pelles C)

Is it has free source code? It's based on lcc, that's good.

}}

[VictorMiasnikov]

{{{ On Mon, Mar 8, 2021 at 9:48 AM Jay K ( . . .) wrote: No.

Windows 7 is good. Windows 10 is good. The Microsoft C++ toolchain is good. If you don't like them, use Linux or Mac, etc. or turn off your computer. I will not be converting Modula-x to Modula-y. There are source to source transforms that are useful, but not that. Consider instead C++ or JavaScript or TypeScript or Rust or LLVM IR or Java, as a means to connecting to other good backends.

Writing a linker is a lot of work and not likely worthwhile. Are you prepared to write symbols for debugging?

NT on Mips/PowerPC/Alpha might be nice, but OpenNT is apparently ancient unlicensed code.

Mips/PowerPC/Alpha are plenty usable otherwise, for example Linux in Qemu, or real hardware.

Though I find it difficult to care about any more than, already a long target list: amd64, arm64, riscv64, WebAssembly (32 now, 64 soon), NT, Darwin, Linux, Fuschia.

And generating C++, really, gets you extremely broad reach. Though even then, closures, threads, exception handling, can be problems (esp. in wasm presently).

}}}

{{{ 08.03.2021, 21:13, "Mika Nystrom" ( . . .): I sort of agree with Jay here. It's super important for M3 code to be able to co-exist well with C, and ideally with C++ as well.

There is so much software out there that's written with C interfaces that we really want to be able to use. The fact that M3 interfaces poorly with C++ is starting to be an issue. M3 on the other hand interfaces amazingly well with C, if the C code is written well (i.e., if the C code is written in an "interface-based style" because that is what M3 itself lends itself to well). Most modern C code I have seen is indeed written in an interface-based style. The C folks finally learned something from the Modula world (ok the rest of the world calls it "Pascal" but we know that's a bit inaccurate), even if it has been slow going!

In short, being able to interface to C/C++ is absolutely essential to being able to write useful M3 applications today.

Although, Jay, I do disagree about rewriting m3front in C. I think m3front should be in M3 and you can bootstrap (or for you, cross-compile) as needed. Really think you should minimize the amount of C in the compiler and system in general, BUT maintain good general compatibity with C/C++.

The reason I think it's important that the tools be written in M3 is a bit philosophical. I write a lot of code generators. And code "understanders" [not a real word I know but it's probably clear what I mean]. In my opinion, this is one of the strongest areas of M3: it's among the simplest of the practical imperative programming languages (maybe Oberon or some dialect of M2 is simpler, I dunno?) to parse and generate. These are also extremely strong and effective general-purpose programming techniques. If we can't use the code understanders and generators from M3 (eating our own dogfood) we are really not making a good show of programming. In fact this I think is one of the real holes in the Java ecosystem: that the Java system itself is written in C++. If M3 can't even implement its own compiler, I think it has no claim on the title "systems programming language". And, in fact, I think it's quite a good "systems programming language" (doesn't everyone on this list???? you'd assume so...)

Mika

}}}

{{{ ________________________________ From: vvm ( . . .) Sent: Monday, March 8, 2021 6:37 PM To: ( . . .) Cc: ( . . .) Subject: Re: [M3devel] eliminating lazy/strict align

Hi!

I agree with all ideas/theses ( 2022-09-01 VVM: ideas of Mika Nystrom) .

(

> (maybe Oberon or some dialect of M2 is simpler, I dunno?)

They are simply "more than need".

)

Beat regards, Victor Miasnikov ( 2022-09-01 VVM: read as "Best")

}}}

[ghost]

I remember some discussions . . .

https://m3lists.elegosoft.com/pipermail/m3devel/2021-March.txt {{

free C tools (e.g. Pelles C)

Is it has free source code? It's based on lcc, that's good.

}}

Pelles C is closed source. Free to use but closed source.

[ghost]

Sorry man but I will not read your wall of text mess. If you don't like it then I will close.