Re: Embedding assembler in a language

On 19 Nov., 12:03, Marco van de Voort <mar...@xxxxxxxx> wrote:
On 2009-11-19, tm <thomas.mer...@xxxxxx> wrote:

Yes, I deagree.
I don't think it is a good idea to offer backdoors like inline

- Programs with inline assembler are not portable. In the internet
you can find "Pascal" programs which are 99% assembler with
additional 1% Pascal function/procedure headers. If you are
looking for a high level algorithm you are probably not happy with
such crap.

As any tool, it can be abused. Just like people can use Duff's device to
manually unroll loops in C. You will also find that on the net.

Premature optimization is premature optimization, in HLL or assembler. But
it is not a reason to ban all tools or constructs that could be abused for

Ok. But one line of assembler makes a program unportable. Inline
assembler forces you to rewrite parts of your program when it is

- Language implementations which advertise inline assembler often
try to cover shortcomings (e.g. performance or access to external
resources) of the language or implementation. So instead of
improving language or implementation they offer a backdoor.


IIRC UCSD Pascal supported assembler functions/procedures to
compensate for the slow interpretation of p-code. Providing some
support for assembler (or C) is a common strategy to improve the
performance of interpreted languages. I don't want to accuse
languages or implementations. I just want to point out that inline
assembler is also used for performance reasons and that some effort
could be used to improve the performance of the main language

It can also simply be because the runtime is entirely written in
the language. If your lowlevel runtime is in a different language, you need
much less assembler.

Also it is a bit unfair to point to TP code for your point. It on average
two decades old and frozen code.

Actually it is not TP code it is assembler which pretends to be
Pascal. If it would be real (portable) Pascal code it would be
usable today without problems. This is also the reason why I see
portable code as much more valuable than unportable code.

- What once was a good idea to improve performance can now be the
stupiest thing to do. Inline assembler that once offered a
performance improvement over high level language code can be
slower on newer processors and newer compilers where compiled
high language language code uses additional registers and modern
machine instructions.

In general yes, but the assembler is there for the specific cases. I'm a
fulltime Delphi devel, and _all_ of my inline code on the job is SSE2.

Currently your SSE2 code improves performance. In the future it can
happen that equivalent compiled Pascal/Delphi code uses the SSE8
units that provide much better performance. Then your SSE2 inline
code would actually be slower.

- There are other processor architectures beside x86 which are
probably excluded with x86 inline assembler programs.

That's why we also sport an x86_64,ppc,ppc64,arm (several flavours),sparc
and sparc64 assembler. Because the lowlevel parts of the program and RTL
must also be done in assembler for those parts.

So portable programs need to provide code for all this assemblers?

It is really not a good idea when a language encourages writing
unportable programs. Instead of providing backdoors the language
implementers should find out where programmers would consider using
such backdoors and improve this areas.

Encourage and enable are two entirely different things.

Yes, but my view is different.
I want to find out exactly for which problems people consider
backdoors such as inline assembler. Then I want to examine this
problems one by one to see if it is possible to provide a
portable way to solve the problem. This way a language and its
library can be improved.

A historical portability problem not related to assembler:
In the old days positioning the cursor at a position in a terminal
was a highly unportable task. Some languages supported gotoxy and
similar functions, but different implementations supported
different flavours of this feature (E.g. Meaning of the two
parameters reversed or counting the lines form 0 or 1). Other
implementations did not support that feature at all. The operating
systems had also different solutions for this problem. Unix like
operating systms used termcap, terminfo or curses for this task
while dos/windows used bios, access to video memory, console module
or gdi. You can find whole books written about that problem.
Some with deep detail (to avoid flicker when you write into the
video memory you have to wait for a vertical retrace) (how to deal
with a terminal device to get it in a mode such that keys pressed
are not echoed in the terminal). For a long time such things were
considered low level and almost impossible to do in a portable
way. Driver librarys available on several operating systems and
language implementations solved the problem but it is still not
trivial: Try to write a portable program with cursor positioning
which works in a windows console and in an linux xterm (when
compiled on this two platforms from the same source code). The
Seed7 driver librarys make this possible. Instead of asking the
programmer to use operating system dependend features or external
librarys I decided to provide a solution in the Seed7 runtime

Another areas where I tried to avoid unportable programs:

The strings are UTF-32 but when dealing with the operating system
they are automatically converted to the character encoding used
by the system calls (which is UTF-16 on windows and UTF-8 on

So I am asking:
For which areas programmers consider backdoors and how could
this things be done in a portable way.

Greetings Thomas Mertes

Seed7 Homepage:
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.