Re: Was just wondering when people started using C to write forth languages and not assembly?

From	anton@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups	comp.lang.forth
Subject	Re: Was just wondering when people started using C to write forth languages and not assembly?
Date	2016-05-19 15:07 +0000
Organization	Institut fuer Computersprachen, Technische Universitaet Wien
Message-ID	<2016May19.170745@mips.complang.tuwien.ac.at> (permalink)
References	<622db793-14c4-48e5-a732-686c0b759db5@googlegroups.com> <bab50d16-da18-4f2a-985a-ca6ba38655d0@googlegroups.com> <e8740f36-5269-4006-8a81-3a15bc816fbe@googlegroups.com> <slrnnjrl6f.c59.albert@cherry.spenarnc.xs4all.nl>

Show all headers | View raw

Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> writes:
>It is generally assumed that assembler causes portability problems.

So, how many (and which) targets do you maintain for your
assembly-based Forth systems.

>However that is offset by the greater effort needed to keep a huge
>system (gforth) based on an even larger system (the gnu compiler
>collection) afloat, versus the ultimate transparency of assembler
>language.  A defect in an obscure corner of gcc can cause problems
>for gforth. There can be doubt about whether a particular change
>is a defect or not. Also there are other changes that are considered
>an improvement by some, and a miscompilation by others.

Yes, the recent (actually, not that recent anymore, but more recent
than our decision to use GNU C) attitude problems of C compiler
maintainers are a problem, and that's why we plan to move away from C.
But these problems did not exist when we and most other people who
wrote Forth systems that use C for the primitives decided to use C.

>A defect in fasm directly contradicts Intel data sheets, there is no
>weasling out.

Yes, with the current attitude of C compiler maintainers, assembly
language is much more reliable and solid than C.  Also, the number of
relevant architectures is shrinking, so the additional portability
effort for assembly language is getting smaller.

>Complicated processors like the latest 64-bit Intel, need so many
>expert knowledge to get optimal code, that it is likely to be spent
>only once. In the case of gcc that is around C, with benefits
>spreading out to related languages like C++.

Except that the GCC maintainers don't have that expert knowledge (I
certainly have not seen any evidence of such knowledge, and have seen
evidence of lack of such knowledge). Instead, they (and their brethren
in mind from the LLVM/Clang camp) prefer to play around with enhancing
the intermediate representation with "knowledge" about undefined
behaviour and how they can use that for "optimizations" rather than
concentrating on real optimizations, where expert knowledge about
processors would be useful.

However, the thing about expert knowledge is not new.  E.g., when we
started with Gforth, we made a performance comparison with a Forth
system written in assembly language by Bernd Beuster, and Gforth was
faster.  Why?  Because Beuster's Forth used LODS (4 cycles on the 486)
in NEXT, while GCC used two simpler instructions (each 1 cycle on the
486) instead.  This was on the 486, a CPU introduced in 1989.  Bernd
Beuster fixed his system, but many systems continued to use LODS for a
long time, because once, on the 8086, it was a good idea.

Intel and AMD are publishing nice optimization manuals.  Read them!

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2016: http://www.euroforth.org/ef16/

Thread

csiph-web