home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.lang.forth
- Path: sparky!uunet!news.univie.ac.at!email!mips.complang.tuwien.ac.at!anton
- From: anton@mips.complang.tuwien.ac.at (Anton Ertl)
- Subject: Re: Recent FORTHs' guts (was: Documenting)
- Message-ID: <1993Jan25.145539.13494@email.tuwien.ac.at>
- Sender: news@email.tuwien.ac.at
- Nntp-Posting-Host: mips.complang.tuwien.ac.at
- Organization: Institut fuer Computersprachen, Technische Universitaet Wien
- References: <1993Jan22.232144.8420@murdoch.acc.Virginia.EDU> <1993Jan23.122739.24899@sol.ctr.columbia.edu>
- Date: Mon, 25 Jan 1993 14:55:39 GMT
- Lines: 15
-
- In article <1993Jan23.122739.24899@sol.ctr.columbia.edu>, penev@venezia (Penio Penev) writes:
- |> I think, that when one designes a FORTH for a machine with a lot of
- |> memory, native code is the better way. It's faster, while not wasting
- |> much. On a i386 one have 4-byte 'address' and a 5 byte 'call address'.
- |> Well, it's not like having 15 bit 'address' and 16 bit 'call address'
- |> like in RTX, but it's still tolerable.
-
- Note that just doing subroutine threading usually makes your system
- slower (than direct threading). You have to go native code, i.e., add
- inlining and optimization, to reap the benefits.
-
- - anton
- --
- M. Anton Ertl Some things have to be seen to be believed
- anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen
-