Path: csiph.com!weretis.net!feeder6.news.weretis.net!news.misty.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end From: George Neuner Newsgroups: comp.compilers Subject: Re: Portable Software (was: fledgling assembler programmer) Date: Tue, 28 Mar 2023 17:26:45 -0400 Organization: A noiseless patient Spider Sender: johnl@iecc.com Approved: comp.compilers@iecc.com Message-ID: <23-03-034@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> <23-03-029@comp.compilers> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="74440"; mail-complaints-to="abuse@iecc.com" Keywords: interpreter, comment Posted-Date: 29 Mar 2023 04:52:37 EDT X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Xref: csiph.com comp.compilers:3435 On Tue, 28 Mar 2023 09:21:50 +0200, Hans-Peter Diettrich wrote: >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. That is exactly as I meant it. Python and Java both initially are compiled to bytecode. But at runtime Python bytecode is interpreted: the Python VM examines each bytecode instruction, one by one, and executes an associated native code subroutine that implements that operation. In contrast, at runtime Java bytecode is JIT compiled to equivalent native code - which include calls to native subroutines to implement complex operations like "new", etc. The JVM JIT compiles function by function as the program executes ... so it takes some time before the whole program exists as native code ... but once a whole load module has been JIT compiled, the JVM can completely ignore and even unload the bytecode from memory. >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. Actually it simplifies the compiler writer's job because the instruction set for the platform VM tends not to change much over time. A compiler targeting the VM doesn't have to scramble to support features of every new CPU - in many cases that can be left to the platform's JIT compiler. >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? Right. When you work on a popular "managed" platform (e.g., JVM or CLR), then its JIT compiler and CPU specific libraries gain you any CPU specific optimizations that may be available, essentially for free. OTOH, when you work in C (or other independent language), to gain CPU specific optimizations you have to write model specific code and/or obtain model specific libraries, you have to maintain different versions of your compiled executables (and maybe also your sources), and you need to be able to identify the CPU so as to install or use model specific code. For most developers, targeting a managed platform tends to reduce the effort needed to achieve an equivalent result. >DoDi George [The usual python implementation interprets bytecodes, but there are also versions for .NET, the Java VM, and a JIT compiler. -John]