Groups > comp.lang.forth > #47282 > unrolled thread

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

Started by	Darin Murphy <murphy.darin@gmail.com>
First post	2016-05-18 11:31 -0700
Last post	2016-05-20 22:27 -0400
Articles	15 on this page of 75 — 20 participants

Back to article view | Back to comp.lang.forth

Page 4 of 4 — ← Prev page 1 2 3 [4]

#47369

From	Paul Rubin <no.email@nospam.invalid>
Date	2016-05-20 15:24 -0700
Message-ID	<877feoe5af.fsf@jester.gateway.pace.com>
In reply to	#47361

Lars Brinkhoff <lars.spam@nocrew.org> writes:
> https://en.wikipedia.org/wiki/X32_ABI

Oh ok, thanks, this makes sense now.  I knew there was something like
that but wasn't sure if I was using it.  Yeah there's not terribly much
point.  The ratio of cpu cycles to ram is now small enough that if
you're doing anything performance intensive to care about x64
instructions, you probably also have enough memory to want a 64 bit OS.

[toc] | [prev] | [next] | [standalone]

#47351

From	Paul Rubin <no.email@nospam.invalid>
Date	2016-05-20 09:45 -0700
Message-ID	<87oa80el0x.fsf@jester.gateway.pace.com>
In reply to	#47348

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>I'm sure the 32-bit ARM ISA will be in use for decades.
> In the embedded space, yes. 

Seems to me that gforth (or at least gforth-ec) should keep supporting
it then.

[toc] | [prev] | [next] | [standalone]

#47706

From	Bernd Paysan <bernd.paysan@gmx.de>
Date	2016-06-02 01:01 +0000
Message-ID	<nio0hq$4mo$2@dont-email.me>
In reply to	#47348

Am Fri, 20 May 2016 15:02:03 +0000 schrieb Anton Ertl:
>>I'm sure the 32-bit ARM ISA will be in use for decades.
> 
> In the embedded space, yes.  But for smartphones and such, it will be
> gone in a decade; not just in the shops, but given the short lifetimes
> of these devices, also in the hands of the users.

I suppose that the Cortex M0/M3+ will last for quite some time in the low-
end embedded space, where a system like Mecrisp Stellaris makes more 
sense.

In the smartphone world, I'd give 32 bit only a few years, until the last 
SoC moved to 64 bits (Cortex A35 for the cheap devices, A72 and big/
little combinations for the higher end).  The problem with GUI software 
is that developers always have the newest and fastest machines, and don't 
care about how it performs on the old ones, so once your performance is 
too poor, you simply can't use your device anymore.

That's why the first two targets for Gforth with native code compilation 
will be arm64 and amd64, and then we can decide which other targets are 
also important enough, and how easy or difficult it actually is to create 
a backend for them.

The good thing is that a relatively small compiler already provides a 
significant improvement in performance compared to the GCC version, so 
even if we don't spend a lot of effort on the not-so-popular targets 
(MIPS, PowerPC, 32 bit ARMs in their various flavors), they would still 
run faster than the GCC-generated version.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#47719 — Native Gforth

From	Lars Brinkhoff <lars.spam@nocrew.org>
Date	2016-06-02 08:37 +0200
Subject	Native Gforth
Message-ID	<86fuswcd0v.fsf_-_@molnjunk.nocrew.org>
In reply to	#47706

Bernd Paysan wrote:
> That's why the first two targets for Gforth with native code
> compilation will be arm64 and amd64

So native code compilation on the official roadmap for Gforth?  Is it
actively being worked on?

> The good thing is that a relatively small compiler already provides a
> significant improvement in performance compared to the GCC version

Is this compiler available somewhere?

[toc] | [prev] | [next] | [standalone]

#47731 — Re: Native Gforth

From	anton@mips.complang.tuwien.ac.at (Anton Ertl)
Date	2016-06-02 12:54 +0000
Subject	Re: Native Gforth
Message-ID	<2016Jun2.145449@mips.complang.tuwien.ac.at>
In reply to	#47719

Lars Brinkhoff <lars.spam@nocrew.org> writes:
>Bernd Paysan wrote:
>> That's why the first two targets for Gforth with native code
>> compilation will be arm64 and amd64
>
>So native code compilation on the official roadmap for Gforth?

Official roadmap?  We are not a public company.

We have plans to do it, but don't hold your breath.

>Is it
>actively being worked on?

No code exists yet.  If you are interested in some of the ideas that
will go in there, see:

@InProceedings{ertl13-paf,
  author =       {M. Anton Ertl},
  title =        {{PAF}: A Portable Assembly Language},
  crossref =     {euroforth13},
  pages =        {30--38},
  url =          {http://www.complang.tuwien.ac.at/anton/euroforth/ef13/papers/ertl-paf.pdf},
  OPTnote =      {not refereed},
  abstract =     {A portable assembly language provides access to
                  machine-level features like memory addresses,
                  machine words, code addresses, and modulo
                  arithmetics, like assembly language, but abstracts
                  away differences between architectures like the
                  assembly language syntax, instruction encoding,
                  register set size, and addressing modes.  Forth
                  already satisfies a number of the characteristics of
                  a portable assembly language, and is therefore a
                  good basis.  This paper presents PAF, a portable
                  assembly language based on Forth, and specifically
                  discusses language features that other portable
                  assembly languages do not have, and their benefits;
                  it also discusses the differences from Forth.  The
                  main innovations of PAF are: tags indicate the
                  control flow for indirect branches and calls; and
                  PAF has two kinds of calls and definitions: the ABI
                  ones follow the platform's calling convention and
                  are useful for interfacing to the outside world,
                  while the PAF ones allow tail-call elimination and
                  are useful for implementing general control
                  structures.}
}
@Proceedings{euroforth13,
  title = 	 {29th EuroForth Conference},
  booktitle = 	 {29th EuroForth Conference},
  year = 	 {2013},
  key =		 {EuroForth'13},
  url =          {http://www.complang.tuwien.ac.at/anton/euroforth/ef13/papers/proceedings.pdf}
}

@InProceedings{ertl14-c,
  author =       {M. Anton Ertl},
  title =        {How to get rid of {C}},
  crossref =     {euroforth14},
  pages =        {63--65},
  url =          {http://www.complang.tuwien.ac.at/anton/euroforth/ef14/papers/ertl-c.pdf},
  video =        {http://www.forth-ev.de/wiki/doku.php/events:euroforth-2014:ridofc},
  OPTnote =      {Presentation slides}
}
@Proceedings{euroforth14,
  title = 	 {30th EuroForth Conference},
  booktitle = 	 {30th EuroForth Conference},
  year = 	 {2014},
  key =		 {EuroForth'14},
  url =          {http://www.complang.tuwien.ac.at/anton/euroforth/ef14/papers/proceedings.pdf}
}

- 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/

[toc] | [prev] | [next] | [standalone]

#47730

From	anton@mips.complang.tuwien.ac.at (Anton Ertl)
Date	2016-06-02 12:34 +0000
Message-ID	<2016Jun2.143430@mips.complang.tuwien.ac.at>
In reply to	#47706

Bernd Paysan <bernd.paysan@gmx.de> writes:
>The good thing is that a relatively small compiler already provides a 
>significant improvement in performance compared to the GCC version, so 
>even if we don't spend a lot of effort on the not-so-popular targets 
>(MIPS, PowerPC, 32 bit ARMs in their various flavors), they would still 
>run faster than the GCC-generated version.

My idea is to have a pretty sophisticated compiler (that tries to keep
stack items in registers as much as possible), but the sophistication
is mostly machine-independent (it depends on the architecture being a
register architecture).  So the first target will take quite a bit of
effort.

Additional targets should take much less effort for the basic
compilation and still get most of the benefits.  E.g., it would be
sufficient to map each of a few dozen primitives to one instruction or
a sequence of instructions, plus having register-to-register moves and
loads from and stores to stacks.  Better instruction selection (e.g.,
combining "<n> + @" into one instruction) will take more effort, but
also not that much.

However, the biggest effort in a new target is probably not in the
core compiler, but in implementing ABI calls and ABI-callable words.

- 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/

[toc] | [prev] | [next] | [standalone]

#47316

From	Albert van der Horst <albert@cherry.spenarnc.xs4all.nl>
Date	2016-05-19 18:35 +0000
Message-ID	<slrnnjs5dk.e8b.albert@cherry.spenarnc.xs4all.nl>
In reply to	#47311

On 2016-05-19, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> 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.

Maintenance is a term that suggest that software detoriates over
time. That is not true.
lina 32 bit 4.0.6 is rock solid since 2005-2-18 and till this very
day the base of ciasdis. No known defects, no changes.
(Yes it took 6 versions to get there. There is a release 4.0.7 but
that is about typos in the manual.)

Maintained versions at this moment:
- wina32 bit,
- OSX 32 bit,
- linux 32 bits,
- linux 64 bits
- ARM 32 bit (not released yet).
Improvements apply mainly to the library.
There is little maintenance needed, because linux system calls are
not moving targets, neither are the entrypoints in kernel32.dll.

Reasons for a new release were:
    addition of OSX
    move from DPMI to DLL in windows
    move from 32 bit calls to 64 bit calls in lina64

In those cases some changes that were in my own beta for years
became part of the release, like getting rid of >IN WORD and FIND

- MS-windows dpmi,
- booting binary 32 bits,
- MSDOS
probably function but need generating, which is a 1 minute job.
But I release them only after extensive testing, which would cost
a day each if not more.

- renesas 16 bits,
- 6809,
-Dec Alpha.
Stable versions, bug reports accepted, but no innovations added:

- linux not-native (using c for system calls)
- booting 16 bit Forth
Probably don't build anymore, there may be stable versions that
work on old 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.

I was shocked the other day about reading comment in an include file
about ioctl constants. He was under the impression that he as a
maintainer could change these at will, and didn't seem to realise that
if you update your kernel that all your programs must be recompiled,
including those bought from a vendor who keeps the source proprietary.

Is this a good time to launch the idea to take over the back end,
where the assembly is handled? I'm pretty sure that
ciasdis would become very fast by adding only a hash table.
My dream is that slowly Forth would take over the central place
of C in the gnu compiler collection. ciasdis is about 100%
error detection, which could be left out for a backend, and would
be marvellous for debugging. This idea is based on the speed we
Forthers can generate assemblers for new instructionsets. As soon as
Intel comes up with something, we would have it added in days.

>
> 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!

I will not. Even if ciforth is slow, I couldn't bother about the difference
between waiting one or three days for the solution of an Euler problem.
(Now they pissed me off by taking an award away that I was the most
proud off, I didn't solve a problem since.)

I'm currently bit-banging a 9600 baud signal to flash the msp430.
That works well enough even if I sometimes have to stop the
Great Internet Mersenne Prime search blasting away on all 8 processors.
And on a 1 Ghz Celeron it works, but with many soft errors.

>
> - anton

--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#47319

From	Darin Murphy <murphy.darin@gmail.com>
Date	2016-05-19 12:07 -0700
Message-ID	<c4598cbe-1d3a-4857-8f79-a096a87820e8@googlegroups.com>
In reply to	#47316

Wow! Thanks everyone for giving me a great overview for why some people wrote forth using C.
I am just glad I don't have too, though because assembly is much easier for me to understand.
LOL  Anyway, thanks again for all of the help, explainations, reasonings. They really helped
me see and understand better. Take care now.

[toc] | [prev] | [next] | [standalone]

#47340

From	anton@mips.complang.tuwien.ac.at (Anton Ertl)
Date	2016-05-20 12:48 +0000
Message-ID	<2016May20.144807@mips.complang.tuwien.ac.at>
In reply to	#47316

Albert van der Horst <albert@cherry.spenarnc.xs4all.nl> writes:
>On 2016-05-19, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> 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.
>
>Maintenance is a term that suggest that software detoriates over
>time. That is not true.

Yet, somehow most Forth systems are updated over the years, and those
that are not are often perceived as orphaned or called "dead".

>Maintained versions at this moment:
>- wina32 bit,
>- OSX 32 bit,
>- linux 32 bits,
>- linux 64 bits
>- ARM 32 bit (not released yet).

I.e., three architectures.

>- renesas 16 bits,
>- 6809,
>-Dec Alpha.

And three more.  Compared to >=8 for Gforth 0.7.0.

- 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/

[toc] | [prev] | [next] | [standalone]

#47324

From	"Elizabeth D. Rather" <erather@forth.com>
Date	2016-05-19 10:33 -1000
Message-ID	<UPKdnfPKPeivvqPKnZ2dnUU7-YXNnZ2d@supernews.com>
In reply to	#47311

On 5/19/16 5:07 AM, Anton Ertl wrote:
> 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.

Two for SwiftForth, Windows and Linux/OSX. For our SwiftX interactive 
cross-compilers, eleven targets: ARM, Coldfire, MSP430, AVR, 68HCS08, 
68K, 68HC12, 68HC11, 8051, 69R000 (a rad-hard processor used in space 
and defense applications), and RTX2010. Some of these are old 
architectures, but we have customers with extensive products in the 
field using them that we can support.

We strictly segregate files into three groups: the largest group 
includes features that are common to all targets, with no dependencies. 
Then we have two much smaller groups, with processor dependencies and 
specific board dependencies. This makes maintenance quite easy, and also 
helps us know where to focus when doing a new port.

You can see the organization and look at all of the target source files 
by downloading one of the free evaluation versions from forth.com.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#47294

From	Ron Aaron <rambamist@gmail.com>
Date	2016-05-19 07:04 +0300
Message-ID	<nhjdpf$i4q$1@dont-email.me>
In reply to	#47282

On 18/05/2016 21:31, Darin Murphy wrote:
> One thing that had repeatedly popped up was that forth and C where
> not very compatable with each other. The strange thing though was
> that everywhere I researched ansi-forth implementations I found that
> they were written in forth (i.e., gforth)

I think you mean, "written in C and Forth".  The Forths I'm familiar
with (including my non-ANS derivative, "8th") are written in a
combination of C and Forth, with perhaps some assembly-language thrown
in.

I can answer easily enough as to why 8th is written using C.  My
previous Forth, "Reva Forth", was written in assembly-language.  It
was therefore tied tightly to the 32-bit x86 CPU which was its target.
Since 8th's goal was to offer a cross-platform solution -- and by
that, I mean mobile and desktop, x86 and ARM, 32 and 64-bit -- writing
it in ASM would mean writing at least six different assembly-language
kernels (with variants to match different OS requirements).

This would have been a maintenance nightmare.

So the decision was made early on to use C.  An added benefit of that
decision is that 8th can easily incorporate support libraries (written
in C or C++), of which there are many.  This has had the secondary
benefit of allowing us to add a lot of functionality to 8th which we
otherwise would have had to write from scratch.

That would have been a time-to-market nightmare.

Hope this helps you understand why I, at least, chose C as my kernel
language.

[toc] | [prev] | [next] | [standalone]

#47296

From	Roelf Toxopeus <rt4all@notthis.hetnet.nl>
Date	2016-05-19 08:09 +0200
Message-ID	<573d58a7$0$4259$e4fe514c@textnews.kpn.nl>
In reply to	#47294

On 19/05/16 06:04, Ron Aaron wrote:
> On 18/05/2016 21:31, Darin Murphy wrote:
>> One thing that had repeatedly popped up was that forth and C where
>> not very compatable with each other. The strange thing though was
>> that everywhere I researched ansi-forth implementations I found that
>> they were written in forth (i.e., gforth)

[...]

> So the decision was made early on to use C.  An added benefit of that
> decision is that 8th can easily incorporate support libraries (written
> in C or C++), of which there are many.  This has had the secondary
> benefit of allowing us to add a lot of functionality to 8th which we
> otherwise would have had to write from scratch.

FYI, incorporating support libraries written in C, ObjC, Pascal, 
take-your-pick, is done by Forth systems _not_ written in C as well.

All (commercial) Forth systems I've used since the 1980's on Atari's and 
Macs, have access to the OS exposed API's and can incorporate support 
libraries. The majority of used Forth systems is written in assembler 
and Forth. All claiming to be compliant with the standard of the day.

Calling and being called is quite essential when using a Forth under an 
OS. Regardless of the languages used for Forth system and OS. For sure, 
it also opens doors to a lot of extra functionality. Accessing those 
from within Forth works like a dream :-)

[toc] | [prev] | [next] | [standalone]

#47299

From	anton@mips.complang.tuwien.ac.at (Anton Ertl)
Date	2016-05-19 07:43 +0000
Message-ID	<2016May19.094342@mips.complang.tuwien.ac.at>
In reply to	#47282

Darin Murphy <murphy.darin@gmail.com> writes:
>One thing that had=
> repeatedly popped up was that forth and C where not very compatable with e=
>ach other. The strange thing though was that everywhere I researched ansi-f=
>orth implementations I found that they were written in forth (i.e., gforth)=
>, but could not find out when this switch was made in the history of forth =
>and more importantly why.

No switch was made.  Some systems were developed with primitives in
assembly language from the start, others were developed with
primitives in some C variant from the start, and there are even
systems like PFE that do the primitives in C and then do what are
colon definitions in other Forth systems in Forth-like C code.

When was the C route taken the first time?  Sometimes in the 80s, when
Forth systems were first developed on systems where C was available
and which had enough memory to make the C overhead acceptable.

Why was it taken?  In Gforth we do it for portability, and I guess
that's also the motivation in most other systems with C primitives.
E.g., we tested Gforth 0.7.0 on 8 different architectures, and Gforth
0.6.2 has been successfully built on architectures (AMD64 and IA-64)
that we had never tested on before its release, and, which in case of
AMD64 were not available before its release.  Compare this with Forth
systems based on (Forth) assembly language like SwiftForth or VFX,
that still do not have an AMD64 port to this day, 13 years after AMD64
CPUs became available?  Or iForth, which has an AMD64 version (since
several years after Gforth), but no longer an IA-32 version
(admittedly, no big loss these days, but still, Gforth supports
IA-32).

- 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/

[toc] | [prev] | [next] | [standalone]

#47301

From	anton@mips.complang.tuwien.ac.at (Anton Ertl)
Date	2016-05-19 08:13 +0000
Message-ID	<2016May19.101336@mips.complang.tuwien.ac.at>
In reply to	#47299

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>Why was it taken?  In Gforth we do it for portability

If you want to know more about our original motivations and the
techniques and tradeoffs we used first, read

@InProceedings{ertl93,
  author = 	 "M. Anton Ertl",
  title = 	 "A Portable {Forth} Engine",
  booktitle =	 "EuroFORTH '93 conference proceedings",
  year =	 "1993",
  address =	 "Mari\'ansk\'e L\'azn\`e (Marienbad)",
  url =		 "http://www.complang.tuwien.ac.at/papers/ertl93.ps.gz",
  abstract = 	 "The Forth engine discussed in this paper is written
		  in GNU C, which provides several extensions that are
		  important for Forth implementation. The indirect
		  threaded Forth engine is completely
		  machine-independent, direct threading requires a few
		  machine-specific lines for each machine. Using
		  a portable language like GNU C encourages producing
		  an engine with many primitives. In order to make the
		  development of primitives easier and less
		  error-prone, an automatic tool generates most of the
		  code for a Forth primitive from the stack effect
		  notation, even if the TOS is kept in a register. The
		  engine is combined with the parts of the system
		  written in Forth by loading a machine-independent
		  image file that contains the executable Forth code
		  in relocatable form."
}

- 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/

[toc] | [prev] | [next] | [standalone]

#47383

From	Darin Murphy <murphy.darin@gmail.com>
Date	2016-05-20 22:27 -0400
Message-ID	<nhoh31$1g7h$1@gioia.aioe.org>
In reply to	#47301

anton@mips.complang.tuwien.ac.at (Anton Ertl) Wrote in message:
> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>Why was it taken?  In Gforth we do it for portability
> 
> If you want to know more about our original motivations and the
> techniques and tradeoffs we used first, read
> 
> @InProceedings{ertl93,
>   author = 	 "M. Anton Ertl",
>   title = 	 "A Portable {Forth} Engine",
>   booktitle =	 "EuroFORTH '93 conference proceedings",
>   year =	 "1993",
>   address =	 "Mari\'ansk\'e L\'azn\`e (Marienbad)",
>   url =		 "http://www.complang.tuwien.ac.at/papers/ertl93.ps.gz",
>   abstract = 	 "The Forth engine discussed in this paper is written
> 		  in GNU C, which provides several extensions that are
> 		  important for Forth implementation. The indirect
> 		  threaded Forth engine is completely
> 		  machine-independent, direct threading requires a few
> 		  machine-specific lines for each machine. Using
> 		  a portable language like GNU C encourages producing
> 		  an engine with many primitives. In order to make the
> 		  development of primitives easier and less
> 		  error-prone, an automatic tool generates most of the
> 		  code for a Forth primitive from the stack effect
> 		  notation, even if the TOS is kept in a register. The
> 		  engine is combined with the parts of the system
> 		  written in Forth by loading a machine-independent
> 		  image file that contains the executable Forth code
> 		  in relocatable form."
> }
> 
> - 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/
> 

Thanks for such an enlightning walk through forth's history, as
 well as the reasoning for how and why gforth was created using
 the C language. It was very helpful!

Take care now, 
-- 
Darin Murphy


----Android NewsGroup Reader----
http://usenet.sinaapp.com/

[toc] | [prev] | [standalone]

Page 4 of 4 — ← Prev page 1 2 3 [4]

csiph-web

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

Contents

#47369

#47351

#47706

#47719 — Native Gforth

#47731 — Re: Native Gforth

#47730

#47316

#47319

#47340

#47324

#47294

#47296

#47299

#47301

#47383