Re: Embedding assembler in a language
- From: "bartc" <bartc@xxxxxxxxxx>
- Date: Thu, 19 Nov 2009 11:35:21 GMT
"tm" <thomas.mertes@xxxxxx> wrote in message
news:79019631-359d-4cae-9e05-b71c6f7a7b9e@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On 18 Nov., 20:07, James Harris <james.harri...@xxxxxxxxxxxxxx> wrote:It is generally desirable for a high level language to be independent
of any target hardware but ISTM that sometimes it is useful to write
system-specific modules. For example, these could be specific to a CPU
or to a hardware device. Any disagreement on this?
Yes, I deagree.
I don't think it is a good idea to offer backdoors like inline
assembler.
- 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.
If there is a genuine need for assembler, isn't it much better to make it
available within the discipline of a high-level language? So you can make
full use of function blocks, scoping, declarations, control structures,...
It's possible to give some 'shape' to a program instead of it being just a
linear sequence of instructions.
(Anyway I've seen plenty of code, especially C, which is pretty much
impossible to compile anywhere else even when there is no assembler
involved.)
- 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.
What's wrong with improving performance? I use inline assembler to write
fast interpreters. Once done, I can then write all my code at a higher level
than the language used to implement the interpreter. But that assembler code
is a one-off. It means I can get, say, double the speed, of my higher level
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.
- There are other processor architectures beside x86 which are
probably excluded with x86 inline assembler programs.
I don't think they are excluded at all. It is possible to take a specific
function, and code both in high-level language, and assembler, and use
mechanisms (eg. commenting) to make either available. In a similar way, you
can add more than one assembler version. Using a dedicated assembler makes
this more awkward.
When the assembler code causes problems, you switch to the high-level code,
at a cost perhaps of performance. Or, if what you say about newer processors is correct, you will get better performance. But usually there was a good reason to use the assembler in the first place (since it is such a PITA to write -- and maintain -- you don't use it unless you have to).
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.
That said, I would like to know which areas are considered
weaknesses of Seed7.
No 'goto' and (I'm guessing) no inline assembler..?
--
Bartc
.
- Follow-Ups:
- Re: Embedding assembler in a language
- From: Rod Pemberton
- Re: Embedding assembler in a language
- From: tm
- Re: Embedding assembler in a language
- References:
- Embedding assembler in a language
- From: James Harris
- Re: Embedding assembler in a language
- From: tm
- Embedding assembler in a language
- Prev by Date: Re: Embedding assembler in a language
- Next by Date: Re: Embedding assembler in a language
- Previous by thread: Re: Embedding assembler in a language
- Next by thread: Re: Embedding assembler in a language
- Index(es):
Relevant Pages
|
