# compiler question:  why bsd disowned BSD's C?  Gcc, and clang



## debguy (May 12, 2021)

My belief is GCC became convoluted needed "gold" and recipes to cross compile.  Clang ... has a legal message saying "it should be free but some authors need to contact them" (saying that 15 yrs now).  c++ ?  I don't trust it compared to C version 2:  it can't compile itself wholey relies on gcc?  Runs real slow?  Says it cross compiles but cannot get itself on to the compiled machine?  Is C portable??  Meanwhile MS compilers now support only intel fastcall and if you access another users folder it days 10 minutes to open the folder (why??), but MS is machining for ARM for pc store sale of touch notebooks profits.

MS hacked BFD and LD, and clang is still working on making LDD so it has linker scripts like LD but I'm unsure why they are redoing those.  Meanwhile, apparently clang has to re-release AS(1) to be clang-ish.  I can't say I ever liked GAS(1) syntax I was a fan of TASM.

So these are misconceptions maybe.  I'd like to hear the history from anyone who knows about how FreeBSD disowned their own fast C compiler (was/is it a cross compiler???) and went for GCC (and so has Intel, including vulkan aware gcc), and then later FreeBSD has disowned GCC to use CLANG++ instead of gcc (clang to me looks like hacky c++ from people whodon't understand what a parsing issue they are creating and slow compile speed issue they are creating).  More misconceptions I'm sure.

*What is the history of FreeBSD's compiler choices and cross compiling ability impacts?*   Why should people use contribute to CLANG (which I think requires gcc in it's chain)?  Why did apple choose clang?


----------



## obsigna (May 12, 2021)

Clang can very well build LLVM and itself *without GCC*. For example, this is how I setup a cross-building environment including the complete toolchain on a fast x86_64 system (i7 @ 4GHz, 4 core) for my BeagleBone Black - ARMv7.

`# mkdir -p ~/install/BBB`
`# cd ~/install/BBB`
`# git clone https://git.freebsd.org/src.git src`
`# cd src`
`# setenv BASEDIR /root/install/BBB`
`# setenv MAKEOBJDIRPREFIX $BASEDIR/obj`
`# make -j4 buildworld TARGET_ARCH=armv7 WORLD_FLAGS="MK_LLDB=yes"`
`# ee sys/arm/conf/BBBCustom`
`# make -j4 buildkernel TARGET_ARCH=armv7 KERNCONF=BBBCustom`

On said i7 system, having yet a spinning HDD, building the ARM world takes about 2 hours. This inludes the bootstrap phase, where the system toolchain builds the cross-building tool chain from the sources, and the ARMv7 tool-chain as well which can be readily deployed to the BBB. Then cross-building the custom BBB kernel takes less than half an hour.

Again, in the course of buildworld, the LLVM/Clang x86_64/ARMv7 cross-building tool chain including the linker and debugger is  produced, and that on a system which even remotely didn't see/know anything about GCC.


----------



## leebrown66 (May 12, 2021)

I thought the move away from GCC was just another step in getting rid of GNU licensed things in base.


----------



## obsigna (May 12, 2021)

leebrown66 said:


> I thought the move away from GCC was just another step in getting rid of GNU licensed things in base.



Yes, of course, everybody knows this. Only some don't want to accept the fact that the name of FreeBSD does not start with 'GEEEH', but with an 'EFF'.

The actual incentive was, the switch of the GCC license to the GPLv3, which is completely incompatible with the BSD license. GCC 4.2.1 was the last version which was GPLv2 licensed, but this one came to age after all.


----------



## Alain De Vos (May 12, 2021)

Should an enduser care about licenses. If it  works it's ok ?


----------



## obsigna (May 12, 2021)

Alain De Vos said:


> Should an enduser care about licenses. If it  works it's ok ?


License complications do not start when the enduser simply uses software. Complications start when somebody distributes software. GPLv3 stuff may not be intermixed with BSD stuff in the base and be distributed in the whole package. Therefore, the latest GCC with the GPLv3 may be in the ports as a separate entity, and there is no problem in simply using it from the endusers point of view.

Anyway, you as the enduser, be careful when you setup a system not for you but for somebody else, e.g. your grandma. She can sue you, if you shipped (kind of a distribution) the system to her with GCC installed, but forgot to leave the sources and the license on the platters.


----------



## Alain De Vos (May 12, 2021)

I'm not a legal specialist but i installed linux on a zfs filesystem. The linux-kernel and the zfs-kernel-module have different licenses.
Yet it is ok ?


----------



## obsigna (May 12, 2021)

Alain De Vos said:


> I'm not a legal specialist but i installed linux on a zfs filesystem. The linux-kernel and the zfs-kernel-module have different licenses.
> Yet it is ok ?


Yes, it is OK, as long as you do not distribute it as a whole. If you do distribute GPL'ed stuff together with something else, you better consult legal specialists before. Usually, you are safe, if you leave the source code and the licence on a prominent place.

Like Hamlet:
_To distribute, or not to distribute, that is the question:_​_Whether 'tis nobler in the mind to suffer_​_The slings and arrows of outrageous fortune,_​_Or to take Arms against a Sea of troubles,_​_And by opposing end them: to die, to ..._​


----------



## Alain De Vos (May 12, 2021)

As I understand it is a problem if you print both on one CD.


----------



## zirias@ (May 12, 2021)

Posting ridiculously wrong claims
by the dozen
chosen so they _might_ provoke emotional reactions
and hidden behind best-innocent "ignorance"
while not ever reacting on the actual content of any reply
… rings a bell? Yes, you guys are falling for it. Just ignore that nonsense thread.


----------



## obsigna (May 12, 2021)

Wer andere für blöd hält, ist selber blöd.


----------



## zirias@ (May 12, 2021)

That's pretty close to the kind of answer someone on here is obviously hoping for…

(btw, very first nonsensical take is the "own fast C compiler". Even 386BSD 1.0 – and of course FreeBSD 1.0 – shipped with GCC… and more gibberish follows. should really be obvious to anyone)


----------



## bakul (May 12, 2021)

People interested in such questions should visit or (if you have a couple of GB spare) download Prof. Diomidis Spinellis' excellent unix history repo @ https://github.com/dspinellis/unix-history-repo -- you can not only see what was shipped in 386BSD-0.1 but go all the way back to the beginning of unix and see how it evolved.


----------



## kpedersen (May 12, 2021)

Zirias said:


> That's pretty close to the kind of answer someone on here is obviously hoping for…
> 
> (btw, very first nonsensical take is the "own fast C compiler". Even 386BSD 1.0 – and of course FreeBSD 1.0 – shipped with GCC… and more gibberish follows. should really be obvious to anyone)


Yep, it was the "why bsd disowned BSD's C?" that convinced me the whole premise was daft and I stayed quiet.

But the best thing to do with these kinds of threads is... to turn them into a history lesson! 

In particular it is interesting that as early as 1.0 shipped with GCC. I don't suppose you know what the system compiler was before that? I recall looking for this info before but came up blank.


----------



## ralphbsz (May 12, 2021)

Search for "Ken Thompson compiler". I think somewhere on the web you can find a writeup by Dennis Ritchie on the early history of C, and how it evolved (in terms of compiler technology) from BCPL via B.

I was going to say "Google for Ken Thompson compiler", but Ken works for Google, so that would be self-referential. If you want to learn some language history, also read about Bliss (another BCPL derivative), which became the language VMS was mostly implemented in. And if you want to have even more historical fun, look up PL/S: It is a small and restricted derivative of PL/1, which was used (roughly at the same time, the early to mid 70s) at IBM for OS development.

Anyone remember who wrote PCC, the portable C compiler (which I think also came out of Bell Labs)? I think that was the compile that was in use when BSD started at Berkeley. I vaguely remember using pcc, but I don't remember on which machine (Sun? Next?). By the way, the first letter of BSD is neither G nor F, so flame wars about licenses are wholly pointless.

And obviously debguy is just posting a troll thread here.


----------



## kpedersen (May 12, 2021)

ralphbsz said:


> Anyone remember who wrote PCC, the portable C compiler (which I think also came out of Bell Labs)? I think that was the compile that was in use when BSD started at Berkeley. I vaguely remember using pcc, but I don't remember on which machine (Sun? Next?).


Hmm, I have used both Ken's C compiler and PCC (I think) as part of Plan 9. Unless the PCC there is not quite the same. Maybe that is to do with the APE Posix compat layer.


----------



## bakul (May 12, 2021)

pcc was by Steve C. Johnson. What was used on v7. BSD also used it until 4.4BSD when it was replaced by gcc. plan9's pcc has a different pedigree. I think Ken's C compiler debuted on plan9. It is one of the fastest compilers and cross-compiling needs no more than setting an environment variable. I once cross-compiled i386 plan9 userland + kernel on the original raspberryPI where it took 4 minutes! Half of it was for compiling ghostscript.


----------



## zirias@ (May 13, 2021)

kpedersen said:


> But the best thing to do with these kinds of threads is... to turn them into a history lesson!


Yeah probably. I don't know enough about Unix/BSD history to tell anything about compilers used on PDP-11/VAX.

But when the system should target i386, well, you needed a compiler targeting it. And it seems that GCC was for a long time the only decent (free / opensource) compiler for that purpose. So, sure it was used. Although GNU never completed the operating system project (yep, that HURDs *scnr*, the rest is [Linux] history), they _did_ complete a decent compiler for i386.


----------



## ralphbsz (May 13, 2021)

bakul said:


> I think Ken's C compiler debuted on plan9.


Who wrote the original B and C compilers, using BCPL on the old Bell labs mainframe? Was that Dennis or Ken? Most likely, that's sort of a meaningless question: They probably both contributed, although only one was doing the typing.


----------



## bakul (May 13, 2021)

ralphbsz said:


> Who wrote the original B and C compilers, using BCPL on the old Bell labs mainframe?


Ken wrote the original B compiler. Ritchie the original C compiler. See https://www.bell-labs.com/usr/dmr/www/chist.html


----------



## kpedersen (May 13, 2021)

bakul said:


> See https://www.bell-labs.com/usr/dmr/www/chist.html


Oh nice. I missed this document during my searches. Some bed time reading tonight!


----------



## debguy (May 15, 2021)

Thank you.  It'd be very difficult to track down why these things happened.

"Clang can very well build LLVM and itself without gcc"

did you say BBC custom?   well I was (trying to) build LLVM  bootstrapping earlier to later, recently.  i had to first upgrade my gcc to compile LLVM.    llvm compiled but clang failed.  i eventually ran into the fact even had i succeeded that RECENT GCC BUILDS are required to build parts of LLVM+CLANG, since clang "doesn't make all of these products itself" (if forget what, was it gas or bfd or ld?  i forget.  but you CANNOT build LLVM+CLANG and build a cross compiler and go from 32bit to 64bit linux "just like that".  it's way more involved than that.  and it's scary really because these knots in the base systems have only been getting worse not better).

your free to disagree!

"Should an enduser care about licenses. If it works it's ok ?"  I will not argue with that.  However suprise lawsuits are bad: meaning many GPL sources have SUED users of their code and won the lawsuits while other GLP'ers who never had the lawsuit clout:  got 0.  That's not ok:  getting a surprise lawsuit for warez you thought were free, or paying some and ... punishing others.  But licenses I think are "ok".


"Posting ridiculously wrong claims"
That's why i disclaimed they might be wrong.  However:  from my perspective, a lowly end user not in the know, that's what I had collected by _experience_.

===============

I have to say no one answered any of the FreeBSD history question:  why PCC was shot down replaced with gcc then gcc was dismissed for llvm (which in the back end requires gcc for parts of the build according to me!)

thank you very much for discussing


----------



## zirias@ (May 15, 2021)

There was never any "pcc" in FreeBSD. You continue blabbering.

As for switching to llvm, licensing is important, but it has a few other advantages as well. And OF COURSE it can bootstrap, that's what every FreeBSD build is doing. Plus it can cross-compile without the need of building it specifically for each target platform.

Now stop the nonsense please.


----------



## obsigna (May 15, 2021)

debguy said:


> ... did you say BBC custom?


No, read again. Anyway, now I am no more surprised at all, since it is well known that dyslexics run into all sorts of problems when following written installation instructions.



debguy said:


> ... but you CANNOT build LLVM+CLANG and build a cross compiler and go from 32bit to 64bit *linux*


Just another fault caused by dyslexia, these forums are called FreeBSD and you want to discuss your Linux problem on a Linux support forum.

PoC of building LLVM without GCC on a vanilla FreeBSD 13.0-RELEASE (x86-64):
`which gcc`

```
gcc: Command not found.
```
`cc --version`

```
FreeBSD clang version 11.0.1 (git@github.com:llvm/llvm-project.git llvmorg-11.0.1-0-g43ff75f2c3fe)
Target: x86_64-unknown-freebsd13.0
Thread model: posix
InstalledDir: /usr/bin
```
`cd /usr/ports/devel/llvm`
`make install clean`

A few hours later you have another version of LLVM/Clang and its toolchain under /usr/local/(bin|lib).


----------



## mark_j (Oct 27, 2021)

debguy said:


> My belief is GCC became convoluted needed "gold" and recipes to cross compile.  Clang ... has a legal message saying "it should be free but some authors need to contact them" (saying that 15 yrs now).  c++ ?  I don't trust it compared to C version 2:  it can't compile itself wholey relies on gcc?  Runs real slow?  Says it cross compiles but cannot get itself on to the compiled machine?  Is C portable??  Meanwhile MS compilers now support only intel fastcall and if you access another users folder it days 10 minutes to open the folder (why??), but MS is machining for ARM for pc store sale of touch notebooks profits.
> 
> MS hacked BFD and LD, and clang is still working on making LDD so it has linker scripts like LD but I'm unsure why they are redoing those.  Meanwhile, apparently clang has to re-release AS(1) to be clang-ish.  I can't say I ever liked GAS(1) syntax I was a fan of TASM.
> 
> ...


FreeBSD  used gnu's c since inception, because it was the only one around at the time. They kept using it until gnu changed the licence from gpl2 to gpl3, which is contrary to views held by bsd-style licences, but couldn't dump it without an alternative, obviously.

Once clang came along, with the correct licence and a mature product, with better error emitting and less bloat, it was a no-brainer.

Gcc is still a better choice for cross-compiling and supports far more languages and architectures and that is why it's in ports (oh and some programs depend on it - possibly because of a compiler language not support by clang among other reasons).

Lldb is still inferior to gdb. But that part of the tool chain is getting better.


----------



## freebuser (Oct 28, 2021)

TLDR:
I think the licensing becomes an issue when used commercially rather than individual end users.


----------



## kpedersen (Oct 28, 2021)

freebuser said:


> TLDR:
> I think the licensing becomes an issue when used commercially rather than individual end users.


If you are providing some compiler extensions and keeping the rest of the compiler proprietary then maybe.

However the vast majority of individuals will simply use a compiler to release a potentially closed-source product. This is fine. The GPL doesn't spread to binaries generated by GPL licensed programs.

The only weird spot was the LCC compiler that states "for non-commercial use only" which is awkward because I believe it spreads to output binaries (from some experience of its use in Quake III). I use this compiler a lot for developing extensions / tools (it is the only codebase I truly understand because of this book). However looking through the compiler source code (and the generated machine code)... no-one will tell if I used it or not


----------



## zirias@ (Oct 28, 2021)

kpedersen said:


> However the vast majority of individuals will simply use a compiler to release a potentially closed-source product. This is fine. The GPL doesn't spread to binaries generated by GPL licensed programs.


This is interesting: What about parts of the runtime distributed with the compiler (e.g. libgcc) and often linked statically? Are there specific exceptions for them?


----------



## hardworkingnewbie (Oct 28, 2021)

This is what the GNU Lesser General Public License (LGPL) was invented for: it allows that use case. For example the GNU Libc is licensed under it.


----------



## zirias@ (Oct 28, 2021)

hardworkingnewbie well, static linking of non-GPL software with LGPL is allowed in principle, but you must provide the user with a way to "re-link" himself, which, in practice, is quite cumbersome… (at least for closed-source stuff. for opensource, it's implicit of course)
(I think this whole GNU idea of "enforcing freedom by imposing restrictions" is an oxymoron and badly flawed…)


----------



## astyle (Oct 28, 2021)

Zirias said:


> hardworkingnewbie well, static linking of non-GPL software with LGPL is allowed in principle, but you must provide the user with a way to "re-link" himself, which, in practice, is quite cumbersome… (at least for closed-source stuff. for opensource, it's implicit of course)
> (I think this whole GNU idea of "enforcing freedom by imposing restrictions" is an oxymoron and badly flawed…)


I do agree with freebuser ...


freebuser said:


> TLDR:
> I think the licensing becomes an issue when used commercially rather than individual end users.


As for OP,  I think his posts are improving as far as striking a decent tone, but could still stand some improvement in how they're written. Best I was able to understand, OP is wondering about how FreeBSD decided to use first its own homegrown C compiler, then switching to GCC, and then dropping GCC in favor of Clang.

My own reaction is that I've seen some info on the Internet about FreeBSD dropping GCC in favor of Clang at least partly due to size and performance issues, and the switch officially happened with 13-RELEASE. But I had no idea that FreeBSD had its own homegrown C compiler prior to adopting GCC as default C/C++ compiler. So, to be honest, I'm kinda interested myself. I tried a quick Google search - but was unable to find that info.


----------



## _martin (Oct 28, 2021)

bakul said:


> People interested in such questions should visit or (if you have a couple of GB spare) download Prof. Diomidis Spinellis' excellent unix history repo @ https://github.com/dspinellis/unix-history-repo -- you can not only see what was shipped in 386BSD-0.1 but go all the way back to the beginning of unix and see how it evolved.


I think this is the only post I ever saw on this forum since 2009 that I'd like to give thanks and like at the same time.


----------



## mrbeastie0x19 (Oct 28, 2021)

gpl 3 is 'freedom with restrictions' in their opinion in order to be free you have to be able to run, modify, distribute code etc, gpl 3 was more strict than 2 and would have possibly prevented freebsd code being used in commercial projects


----------



## kpedersen (Oct 29, 2021)

Zirias said:


> This is interesting: What about parts of the runtime distributed with the compiler (e.g. libgcc) and often linked statically? Are there specific exceptions for them?


I think these are addressed here. The FAQ at the bottom is useful too.





						GCC Runtime Library Exception Rationale and FAQ - GNU Project - Free Software Foundation
					






					www.gnu.org
				




This does mention it came about from GPLv3. I actually don't know about earlier versions. I think they had exceptions too.

Considering Apple used GCC for a time, they must have had something in place so that they could still take their source to the grave with them.


----------



## zirias@ (Oct 29, 2021)

astyle said:


> But I had no idea that FreeBSD had its own homegrown C compiler prior to adopting GCC as default C/C++ compiler.


Because it never had.


----------



## astyle (Oct 29, 2021)

Zirias said:


> Because it never had.


So, what did FreeBSD use prior to adopting GCC as system default?


----------



## zirias@ (Oct 29, 2021)

astyle said:


> So, what did FreeBSD use prior to adopting GCC as system default?


Uhm, I'll quote myself here from this very thread:


Zirias said:


> (btw, very first nonsensical take is the "own fast C compiler". Even 386BSD 1.0 – and of course FreeBSD 1.0 – shipped with GCC… and more gibberish follows. should really be obvious to anyone)


-> FreeBSD never "adopted" GCC.


----------



## astyle (Oct 29, 2021)

Zirias said:


> Uhm, I'll quote myself here from this very thread:
> 
> -> FreeBSD never "adopted" GCC.


Seems like I may need to learn to read in Git...


bakul said:


> People interested in such questions should visit or (if you have a couple of GB spare) download Prof. Diomidis Spinellis' excellent unix history repo @ https://github.com/dspinellis/unix-history-repo -- you can not only see what was shipped in 386BSD-0.1 but go all the way back to the beginning of unix and see how it evolved.


I appreciate bakul 's tip, would be nice if I had the expertise to properly take advantage of it.


----------



## zirias@ (Oct 29, 2021)

astyle said:


> Seems like I may need to learn to read in Git...
> 
> I appreciate bakul 's tip, would be nice if I had the expertise to properly take advantage of it.


Well, on PDP-11/VAX, there was probably a different compiler  if you're interested, that would be a way to find out…

But on x86, for a long time, GCC was the only sane opensource compiler. It wouldn't have made sense for 386BSD to reinvent the wheel here. Trolls just write nonsense and see who "bites".


----------



## astyle (Oct 29, 2021)

Zirias said:


> Trolls just write nonsense and see who "bites".


Yeah, that kind of behavior is better left to reddit.


----------



## Alain De Vos (Oct 29, 2021)

Which brings me to this related question. Are there interesting c compilers other than clang/llvm & gcc i should try on freebsd ?
I found : ucc,tcc,sdcc,pcc,nwcc,flatcc,bcc


----------



## zirias@ (Oct 29, 2021)

Alain De Vos said:


> Which brings me to this related question. Are there interesting c compilers other than clang/llvm & gcc i should try on freebsd ?


Maybe lang/pcc. Could be interesting because according to Wikipedia, it was used on BSD prior to 4.4BSD.


----------



## hardworkingnewbie (Oct 29, 2021)

Alain De Vos said:


> Which brings me to this related question. Are there interesting c compilers other than clang/llvm & gcc i should try on freebsd ?
> I found : ucc,tcc,sdcc,pcc,nwcc,flatcc,bcc


Question is: for what purpose? Just to have a look at them and play around with them, or to do real development stuff?


----------



## zirias@ (Oct 29, 2021)

There are of course quite some "special purpose" compilers, like e.g. devel/cc65 targeting machines like the C64  – I don't program the C64 in C, but use cc65's assembler (ca65).


----------



## astyle (Oct 29, 2021)

hardworkingnewbie said:


> Question is: for what purpose? Just to have a look at them and play around with them, or to do real development stuff?


Even playing around with special purpose compilers/assemblers has value. Learning the logic behind their design, and getting it down, and being able to compare the logic patterns - it's that kind of *skill* that would be valuable for projects like Russia's Elbrus 8C (Discussion right here on these forums) or China's Loongson. Politics aside, this looks like serious _brain gymnastics _(A term I credit Alain De Vos with inventing  ) to keep people busy


----------



## kpedersen (Oct 29, 2021)

Zirias said:


> There are of course quite some "special purpose" compilers, like e.g. devel/cc65 targeting machines like the C64  – I don't program the C64 in C, but use cc65's assembler (ca65).


I was playing with that the other day when testing out this processor emulator:
https://gitlab.com/limdingwen/6502js-but-c

I do like these simple C compilers (and very nice minimal emulators). Everything feels like it is in my grasp of understanding haha.


----------



## zirias@ (Oct 29, 2021)

kpedersen said:


> Everything feels like it is in my grasp of understanding haha.


That's why I still enjoy programming the C64, this machine can be understood as a whole by a human being  not that I know every single bit in every memory-mapped register by heart (this machine uses MMIO exclusively, there's an I/O area that can be mapped to `0xd000-0xdfff`, I love this simplicity), but that can be looked up quickly if needed.

It's also nice to know it _can_ be programmed in C, although I didn't do that so far.

BTW, sorry for the OT, but here's one of my more recent works:




_View: https://www.youtube.com/watch?v=EaeMbr6TuXQ_

The interesting thing about it might be that it was created with devel/cc65, especially using its linker (ld65) that's designed as a classic C linker, but works for assembly modules just as well


----------



## ralphbsz (Oct 29, 2021)

Alain De Vos said:


> Which brings me to this related question. Are there interesting c compilers other than clang/llvm & gcc i should try on freebsd ?
> I found : ucc,tcc,sdcc,pcc,nwcc,flatcc,bcc


I don't see the point of using older and less well-maintained "just for fun", that's probably a waste of time. Right now, among the free and commonly used compilers for x86 machines (32- and 64-bit), clang is the gold standard, when measured by the efficiency of the generated code. There are compilers that are "better" than gcc and clang in that respect. For example, the Portland Group makes a superb C++ and Fortran compiler. Their main focus is parallel programming, today mostly using GPUs. But even even on non-parallel codes on x86 it generates excellent code, which is typically faster than that from free compilers. But: The PG compilers cost money, I think big money. And buying them just for compiling regular programs for a single CPU would be silly; the small performance benefit has no relation to the large cost. If you have a few tenthousand CPUs and a million GPUs, then it matters greatly.


----------



## astyle (Oct 29, 2021)

ralphbsz said:


> If you have a few tenthousand CPUs and a million GPUs, then it matters greatly.


Like bitcoin mining farms? That's about the best case scenario I can think of.


----------



## jbo (Oct 29, 2021)

I deal with different non-GCC, non-Clang & non-MSVC compilers a lot (although definitely not as much as a couple of years ago given the "recent" efforts on "modularizing" existing compilers).
For example, TCC is something I work with a lot: https://bellard.org/tcc/


----------



## hardworkingnewbie (Oct 29, 2021)

Well Fabrice Bellard for sure is the closest thing to a human being with super programming powers we'll probably ever know. I mean, all the stuff he wrote - Qemu, TCC, FFMPEG, QuickJS, computing Pi quickly, BPG, creating a DVB-T emitter with a standard PC and VGA card and many others - wow. A resume to die for! 

Fun fact about the TCC is that it started life as entry for the IOCCC back in 2002. The TCC was then later derived from it. 

BTW reg. Portland Group: they've been sold to Nvidia. And it's new brand name is nowadays NVIDIA HPC SDK.


----------



## ralphbsz (Oct 29, 2021)

astyle said:


> Like bitcoin mining farms? That's about the best case scenario I can think of.


I thought crypto mining is today done with ASICs, since CPUs and GPUs can't keep up in energy efficiency. Someone told me that mining Bitcoin using commercial power and ASICs has negative efficiency in most parts of the world, since you pay more for the kilowatts required than the resulting bitcoin sells for, and with CPUs it's hopeless. For other (less commonly used) cryptocurrencies, that may not be true. But the answer to this is to move to areas where power is either extremely cheap (for example due to lack of environmental regulations on coal), or where one can use crime or political connections to get free power. Supposedly that's the case in parts of the former Soviet Union and North Korea, where state-sponsored crypto mining gets free electricity, and the state gets a share of the cryptocurrency.

Another form of mining is to be a criminal: Just don't pay for computer power, and steal it. Rumor has it that the hosting- and cloud providers are having big problems with "customers" using free trial accounts and fake credit cards to buy computer power, using it to mine, and not paying their bills. I have not heard whether hackers are breaking into everyday computers and using background cycles to mine, but that sounds like another approach.

In all these cases, a few percent improvement in efficiency of the generated code that runs on mainstream CPUs is not the big issue ... the big issue is arrangements with politicians and avoiding law enforcement.

Where efficient compilers matter is for example two areas. The obvious one is supercomputers: if a government agency, university or company pays dozens or hundreds of M$ for a computer, they are keenly interested in making it run a few percent faster, since that translates into significant $ savings. The second one is the big hyperscalers (FAANG + friends, in particular the cloud providers): they spend billions on compute power, and compete with each other with razor-thin margins, so a few percent improvement can be make or break.


----------



## hardworkingnewbie (Oct 29, 2021)

ralphbsz said:


> I thought crypto mining is today done with ASICs, since CPUs and GPUs can't keep up in energy efficiency. Someone told me that mining Bitcoin using commercial


Depends on the crypto currency. Nvidia themselves put Ethereum mining throttles into their Geforce 3XXX line.


----------



## astyle (Oct 29, 2021)

ralphbsz said:


> I thought crypto mining is today done with ASICs, since CPUs and GPUs can't keep up in energy efficiency. Someone told me that mining Bitcoin using commercial power and ASICs has negative efficiency in most parts of the world, since you pay more for the kilowatts required than the resulting bitcoin sells for, and with CPUs it's hopeless. For other (less commonly used) cryptocurrencies, that may not be true. But the answer to this is to move to areas where power is either extremely cheap (for example due to lack of environmental regulations on coal), or where one can use crime or political connections to get free power. Supposedly that's the case in parts of the former Soviet Union and North Korea, where state-sponsored crypto mining gets free electricity, and the state gets a share of the cryptocurrency.
> 
> Another form of mining is to be a criminal: Just don't pay for computer power, and steal it. Rumor has it that the hosting- and cloud providers are having big problems with "customers" using free trial accounts and fake credit cards to buy computer power, using it to mine, and not paying their bills. I have not heard whether hackers are breaking into everyday computers and using background cycles to mine, but that sounds like another approach.
> 
> ...


Unfortunately, Chinese bitcoin mining farms did contribute to the global GPU shortage crisis already. If the GPU's were actually useless for crypto, the crypto farmers would have caught on to that by now, and would be chasing after a different hot new miner to buy up. 

And yes, hackers are trying to use the everyday computers to mine: Just a few years ago, Piratebay tried that. I wouldn't put it past determined hackers to keep trying that even these days.


----------



## bakul (Oct 30, 2021)

Alain De Vos said:


> Which brings me to this related question. Are there interesting c compilers other than clang/llvm & gcc i should try on freebsd ?
> I found : ucc,tcc,sdcc,pcc,nwcc,flatcc,bcc


Probably not what you want but in case you want to learn more about recursive descent compilers, I’d recommend reading the code of Nils Holm’s subc compiler (for a major subset of C) & the book about it. The compiler code is about 5K lines of clear code & compiles itself in under 0.2 seconds on a Ryzen machine! The code is in public domain. The book you have to buy from lulu.com (but the code is readable on its own). The current version of subc has evolved from the book version (originally developed on FreeBSD) and now supports x86, x86-64 & arm backends on a number of platforms. It may also serve as a decent platform to try out your own ideas about extending/restricting C etc.


----------



## hardworkingnewbie (Oct 30, 2021)

astyle said:


> Unfortunately, Chinese bitcoin mining farms did contribute to the global GPU shortage crisis already. If the GPU's were actually useless for crypto, the crypto farmers would have caught on to that by now, and would be chasing after a different hot new miner to buy up.
> 
> And yes, hackers are trying to use the everyday computers to mine: Just a few years ago, Piratebay tried that. I wouldn't put it past determined hackers to keep trying that even these days.


Well since PRC banned crypto mining, the USA have taken over the helm as global mining heaven.


----------

