Path: csiph.com!weretis.net!feeder6.news.weretis.net!news.misty.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end From: Hans-Peter Diettrich Newsgroups: comp.compilers Subject: Portable Software (was: fledgling assembler programmer) Date: Tue, 28 Mar 2023 09:21:50 +0200 Organization: Compilers Central Sender: johnl@iecc.com Approved: comp.compilers@iecc.com Message-ID: <23-03-029@comp.compilers> References: <23-03-001@comp.compilers> <23-03-002@comp.compilers> <23-03-003@comp.compilers> <23-03-007@comp.compilers> <23-03-008@comp.compilers> <23-03-012@comp.compilers> <23-03-017@comp.compilers> <23-03-022@comp.compilers> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="22583"; mail-complaints-to="abuse@iecc.com" Keywords: interpreter Posted-Date: 28 Mar 2023 04:14:25 EDT X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com In-Reply-To: <23-03-022@comp.compilers> Xref: csiph.com comp.compilers:3431 On 3/26/23 1:54 AM, George Neuner wrote: > On Sat, 25 Mar 2023 13:07:57 +0100, Hans-Peter Diettrich > wrote: > >> After a look at "open software" I was astonished by the number of >> languages and steps involved in writing portable C code. Also updates of >> popular programs (Firefox...) are delayed by months on some platforms, >> IMO due to missing manpower on the target systems for checks and the >> adaptation of "configure". Now I understand why many people prefer >> interpreted languages (Java, JavaScript, Python, .NET...) for a >> simplification of their software products and spreading. > > Actually Python is the /only/ one of those that normally is > interpreted. And the interpreter is so slow the language would be > unusable were it not for the fact that all of its standard library > functions and most of its useful extensions are written in C. My impression of "interpretation" was aimed at the back-end, where tokenized (virtual machine...) code has to be brought to a physical machine, with a specific firmware (OS). Then the real back-end has to reside on the target machine and OS, fully detached from the preceding compiler stages. Then, from the compiler writer viewpoint, it's not sufficient to define a new language and a compiler for it, instead it must placed on top of some popular "firmware" like Java VM, CLR or C/C++ standard libraries, or else a dedicated back-end and libraries have to be implemented on each supported platform. My impression was that the FSF favors C and ./configure for "portable" code. That's why I understand that any other way is easier for the implementation of really portable software, that deserves no extra tweaks for each supported target platform, for every single program. Can somebody shed some light on the current practice of writing portable C/C++ software, or any other compiled language, that (hopefully) does not require additional human work before or after compilation for a specific target platform? DoDi