Re: Portable Software (was: fledgling assembler programmer)

On Tue, 28 Mar 2023 09:21:50 +0200, Hans-Peter Diettrich
<DrDiettrich1@netscape.net> wrote:


>On 3/26/23 1:54 AM, George Neuner wrote:
>> On Sat, 25 Mar 2023 13:07:57 +0100, Hans-Peter Diettrich
>> <DrDiettrich1@netscape.net> 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]

Return to the comp.compilers page.
Search the comp.compilers archives again.