why forth over lisp?
Brad Cantrell
"Starting Forth" and a few other Forth tutorials and they all mention
how Forth has very low level access to hardware that other languages
dont have and how it is a operating system unto itself, but Im having
trouble seeing this. To me Forth does the the exact same thing as
Lisp, its a heirarchy of functions that nest within function and
further into functions below that till you hit the lowest level
functions which are machine instructions. But doesnt Lisp do the exact
same thing? Lisp is made up of functions and these functions are
themselves written in Lisp functions until they bottom out to
barebones primitive functions that are part of the compiler. And Lisp
compiles to machine language just like Forth so it can be quite fast.
And also I dont see how Forth has any lower access than any other
language like C. All these languages simply make OS system calls or
interface with system libraries. Im sorry for asking this, but could
anyone tell me what Im missing here?
Paul Rubin
> And also I dont see how Forth has any lower access than any other
> language like C. All these languages simply make OS system calls or
> interface with system libraries. Im sorry for asking this, but could
> anyone tell me what Im missing here?
Lisp and Forth have some philosophical similarities but are completely
different at the implementation level. Lisp relies on dynamic memory
allocation and garbage collection at a fundamental, making
implementation more complex, and real-time implementation quite
difficult. Forth is basically an instruction set for a very simple
stack-oriented abstract machine, plus a minimalistic symbolic
interpreter/translator running on top of that instruction set. Lisp
normally can't directly access and manipulate machine addresses, while
Forth and C both expose them and programs use them. Lisp is a higher
level language than Forth but considerably more costly to execute,
especially in memory footprint. It's quite practical to write Forth
programs for machines with just a few dozen bytes of ram, and to run
complete Forth programming environments (interactive interpreter like a
Lisp read/eval/print loop) with just a few kilobytes. Lisp needs a lot
more.
C and Forth are philosophically very different from each other but both
are mid-level languages that are approximately comparable in that
regard.
Andrew Haley
> Brad Cantrell <cant...@gmail.com> writes:
>> To me Forth does the the exact same thing as
>> Lisp,...
>> And also I dont see how Forth has any lower access than any other
>> language like C. All these languages simply make OS system calls or
>> interface with system libraries. Im sorry for asking this, but
>> could anyone tell me what Im missing here?
>
> Lisp and Forth have some philosophical similarities but are completely
> different at the implementation level. Lisp relies on dynamic memory
> allocation and garbage collection at a fundamental, making
> implementation more complex, and real-time implementation quite
> difficult. Forth is basically an instruction set for a very simple
> stack-oriented abstract machine, plus a minimalistic symbolic
> interpreter/translator running on top of that instruction set.
Perhaps, but that's not really the core point. Forth implementations,
at the time Starting FORTH was written, often didn't bother with an
underlying operating system at all. Such implementations still exist
in embbedded systems.
Andrew.
Krishna Myneni
Most Forth systems provide an assembler, which is usually written in
Forth. The Forth specification provides standard words, CODE and END-
CODE, which allow defining a word in assembly language, and which is
accessible from the Forth interpreter. One can pass arguments to and
obtain return values to the word defined as assembler instructions.
Furthermore, the assembler has access to the Forth-level data
structures (VARIABLEs, CONSTANTs, arrays, etc). Such features make
code which operates at the machine-level easy to write, test, and use.
Of course, one can also use assembly level procedures from within
other languages such as C, Fortran, etc. However, the assembler source
is typically in a separate file, and has to be linked to the higher
level code, making it more difficult to use. The assembly level
procedures also cannot be used interactively, except for maybe within
a debugger.
As an example, the following file, crc-32-x86.4th, is an example of
source which mixes assembly and Forth code. The assembly code is
particular to the asm-x86 assembler. Other examples include calling
system-specific interrupts to access system calls.
Krishna
\ crc-32-x86.4th
\
\ Based on crc-32.f for SwiftForth by
\ Petrus Prawirodidjojo Thu 2001-10-18
\
\ Modified for asm-x86 under kForth by K. Myneni
\
\ Revisions:
\ 2001-10-18 -- initial port (non-functional)
\ 2007-01-07 -- working version; required fixes to asm-x86 for
\ proper assembly of byte and word register
operands km
\
\ Requires: asm-x86.4th
\
base @
hex
EDB88320 constant CRC-POLYNOMIAL
CODE crc32 ( n1 char -- n2 )
0 [ebx] eax mov,
TCELL # ebx add,
0 [ebx] edx mov, \ crc to edx
ebx push,
eax ebx mov,
8 # ecx mov, \ loop count
DO,
1 # edx shr, \ shift crc
1 # bh rcr,
1 # bl ror, \ shift character
bx ax mov, \ save character
bh bl xor, \ xor
0<, IF, \ skip if equal
CRC-POLYNOMIAL # edx xor, \ crc-32 polymial 1 04C1 1DB7
THEN,
ax bx mov, \ restore character
LOOP, \ next bit
ebx pop,
edx 0 [ebx] mov, \ crc to tos
0 # eax mov,
END-CODE
base !
\ calculate crc-32 for several strings
: crc-32 ( n1 c-addr u -- n2 )
0 do \ n c-addr
dup >r c@ crc32 r> 1+ loop drop ;
\ calculate crc-32 of a string
: crc32s ( c-addr u -- n )
-1 -rot crc-32 invert ;
\ test
: test
cr cr ." crc-32" cr
s" An Arbitrary String" 2dup type cr
." crc-32: " crc32s hex u. decimal ." should be 6FBEAAE7" cr
s" ZYXWVUTSRQPONMLKJIHGFEDBCA" 2dup type cr
." crc-32: " crc32s hex u. decimal ." should be 99CDFDB2" cr ;
test
\ end of application, - do not delete -
Brad Cantrell
difference between Lisp and Forth was that you manually handle the
stack in Forth whereas Lisp does that for you which requires garbage
collection. But with your explanations I see just how far Forth can
access and intermix with machine language. Thanks for your
explanations.
Elizabeth D Rather
In addition to their excellent explanations and examples, let me add
that on the early standalone (no OS) Forths as well as current
interactive cross-compilers the developer has direct command line access
to the underlying hardware. You can directly read and write I/O
registers, examine and modify memory (whose allocation and use is almost
entirely under your control), and type in definitions in either Forth or
assembler. These definitions are immediately executable from the
command line without linking or any other procedure.
These capabilities are invaluable when you're developing programs to run
with custom hardware, including embedded systems of all kinds, which is
the environment in which Forth was first developed and is still widely used.
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."
==================================================
ken...@cix.compulink.co.uk
(Paul Rubin) wrote:
> and real-time implementation quite
> difficult.
That applies to all languages with garbage collection. Real time
operation requires the system to be predictable and not go off to clear
the garbage at random intervals.
Ken Young
P.M.Lawrence
Actually, you can intermix them even more than that example showed
(though you usually wouldn't, as good coding practice). There, there
were distinct words in higher level Forth and in machine code, but you
can mix both within one higher level word if you bracket the machine
code with constructs like <CODE and CODE> or similar, e.g. to access a
specific port. P.M.Lawrence.
Coos Haak
I've done that. But what profit does it bring with it, other than not
needing to give a piece of code a name? And the implementation of <CODE and
CODE> it nearly impossible to port.
I would recomment to use code definitions sparingly and stay with colon
definitions. Modern compilers may generate better native code than the
average programmer, and consuming very much less time.
--
Coos
CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html
Krishna Myneni
> ...
> I would recomment to use code definitions sparingly and stay with colon
> definitions. Modern compilers may generate better native code than the
> average programmer, and consuming very much less time.
>
> --
> Coos
>
For the benefit of the OP, we should point out the disadvantage of
using CODE definitions is that they are usually not portable between
Forth systems, even when using the same assembler, since register
allocation may be different. However, there is also functionality
which requires machine level access, which cannot be provided by
*standard* Forth level words. Examples include:
1) Determining CPU information:
see CODE definitions for CPU_VENDOR_ID and CPU_PROCESSOR_INFO in
ftp://ccreweb.org/software/kforth/examples/asm-x86-examples.4th
2) Configuring the floating point unit (FPU):
ftp://ccreweb.org/software/kforth/examples/fpu-x86.4th
3) Implementing mutual exclusion mechanisms such as spin-lock:
ftp://ccreweb.org/software/kforth/examples/spinlock-ex.4th
4) Operating system specific software interrupts (e.g. syscalls under
Linux):
ftp://ccreweb.org/software/kforth/examples/obsolete/syscalls386-20051107.4th
5) Calling external C library code from Forth:
ftp://ccreweb.org/software/kforth/examples/fcalls-x86.4th
And, of course, sometimes speed is actually necessary even in Forth-
level code may be written:
6) Fast data processing:
ftp://ccreweb.org/software/kforth/examples/fft-x86.4th
Krishna
arc
It sounds to me as though you are supposing that some kind of overall
similarity in implementation strategy results in similarity in access
to hardware. i.e. both FORTHs and LISPs are often 'implemented in
terms of themselves' in some sense, and they both result in machine
code and syscalls, so they both offer the same access to hardware.
(I'll pause here to note that all programming languages, if they're
ever to run on a computer (which isn't necessary, but often
desirable), must result in machine code running on a processor at some
point, and if they're running on a computer with a host operating
system, then usually at some point some syscalls will need to be made
- it's just that the route taken to make this happen is different with
different languages)
However, this isn't the case. If two languages compile directly to
machine code, then the language implementation has the same access to
the hardware, but it needn't expose this access to the end
programmer. Forth usually does expose access to the underlying
hardware to a large extent, as has been excellently demonstrated in
this thread. LISP can't and won't expose this access because of the
design of the language - allowing programmers to allocate and access
their own memory by memory addresses as bytes of undifferentiated
binary would break the garbage collection and type system [1], which
was also discussed by a previous poster.
In this sense, LISP and Forth have very different philosophies. Forth
very much does encourage you to think 'close to the metal' as it were,
whereas LISP is designed to present you with a much higher level of
abstraction: Scheme is even explicitly designed around the lambda
calculus, which is an abstract formalism for reasoning about
computation that doesn't even mention machines (this is not to
disagree with an earlier poster who said that Forth and LISP do have
some philosophies in common).
To see the difference in approaches, you just need to look at how they
treat strings. In Forth, they're usually an address and a count on the
stack, which you can use to access a contiguous array of memory as an
array of ascii characters *if you want to*: it's just a whole lot of
binary which you could just as well treat as numbers if you wanted.
In LISP, you have (say) a variable, the value of which is a string,
which you manipulate by means of string procedures. You have no idea
how the string is encoded or stored: it could be a count string of
ascii, much like Forth, or it could be a null terminated array of
UTF8, or maybe it is stored how the LISP in question stores lists
(which, again, you don't necessarily know or care about) or it could
be something more outré, like a rope[2] of EDBIC. If you want to
treat it as something else -- a list of characters, or some numbers,
maybe -- you have to explictly convert it using other procedures,
otherwise an error is generated, and again, you have no idea what the
end representation is or how the conversion happens.
(Of course, you _could_ find out these things if you wanted to, often,
but the point is that LISP doesn't require or particularly encourage
you to know about the exact implementation of data, and you can't
manipulate it directly anyway).
So it's possible for something to be implemented as machine code yet
not expose memory addresses or allow assembly routines to easily be
built to the end programmer - and in fact this is common with any
compiled, high-level language. It's also in principle possible for a
language environment that doesn't run directly on the hardware (either
it's interpreted, or it's running on a virtual machine like the JVM)
to expose these hardware details, so long as the environment it's
running on can provide such access.
(In fact, wouldn't it be fair to say that's pretty much what classic,
threaded Forth does?)
Anyway, my overall point is that the hardware access granted to an end
programmer has more to do with the wider design and philosophy of the
language, and not so much to do with the exact details of how that
language finally ends up being executed (although obviously some
choices here rule out direct hardware access).
__
-A.
[1] having said that, perhaps it would be possible for a LISP to
provide such access, with suitable interchange systems to the
standard, gc'd and typed LISP environment, and maybe some even do
this.
Thomas Pornin
> In article <7xeie1w...@ruckus.brouhaha.com>, no.e...@nospam.invalid
> (Paul Rubin) wrote:
>
> > and real-time implementation quite
> > difficult.
>
> That applies to all languages with garbage collection.
Actually that applies to all languages with dynamic memory allocation
but without garbage collection.
Dynamic memory allocation (with deallocation) means that you have to
handle fragmentation and related issues, which imply that you may have a
hard time providing guarantees on response time. It so happens that
there are some GC algorithms which can provide such guarantees, through
a number of algorithmic feats which imply moving objects around in
memory (hence a strongly-typed language at some level, since pointers
must be accurately updated).
So if you want true real-time operation, then either:
1. you use a strongly-typed language with an advanced GC, or
2. you do not allocate memory dynamically with generic deallocation.
Lisp can do 1 (of course, very few Lisp implementations come with a
real-time GC, but it is doable). Forth can do 2 (just do not call
ALLOCATE). The most real-time impaired language is, in fact, C.
--Thomas Pornin
william...
one difference was that there was much effort to create a lisp
"machine", and after much
time and money, all efforts failed...
chuck moore has created a silicon forth machine ( machine instructions
are colorforth33 )...
a lisp to forth transform is not beyond code practice today...
it all comes down to cost/function...
if it is more cost effective to express problem solution in lisp, then
do so...
william...
william...
i shall turn the computing world upside down...
i wish to do so within my rules...
do the least harm, do the most help, live as happy as possible...
i have worked since 1985 trying to uhderstand, and to recreate what i
assisted in creating in 1981...
what took a cray in 1981 you can buy for less than $1000us today...
anybody wanna join with such as i and do something big...?
the word is "agent", but the "overloaded" meaning of today...
in 20+ years, i have found NO agent like we created...
i now know, the agent system was written in lisp...
but forth can do anything lisp can do, and more...
especially if the machine instructions are forth itself...
anybody want to work with me...?
check out openblocks, colorforth(GA144), AppInventor...
http://colorforth.com
http://greenarrays.com
http://appinventor.googlelabs.com/learn/index.html
william...
Paul Rubin
> one difference was that there was much effort to create a lisp
> "machine", and after much
> time and money, all efforts failed...
>
> chuck moore has created a silicon forth machine ( machine instructions
> are colorforth33 )...
What are you talking about? At least 3 different companies and one
university made lisp machines. They were expensive but their users
loved them. They were far more successful than Forth machines ever
were.
foxchip
> > chuck moore has created a silicon forth machine ( machine instructions
> > are colorforth33 )...
Chuck and other people created quite a few Forth machines
over the years. Novix 4016, Harris RTX-2000, RTX-2001,
RTX-2010, Sh-Boom, mup20, mup21, p8, p32, v21, i21, f21,
SEAforth24, SEA40, GA32, GA40, GA4, and GA144 are a few that
I worked on or worked with. Dozens of other companies,
research institutions, and government agencies have produced a
number of other designs and variations. A number of people
have created soft-core versions as well.
> What are you talking about? At least 3 different companies and one
> university made lisp machines. They were expensive but their users
> loved them. They were far more successful than Forth machines ever
> were.
Many millions of Forth machines have been made and deployed
in the real word. Many generations of machines have been
made over a nearly thirty year period. I think Lisp machines
died out because they were just too expensive. After all, how
many $80k Lisp computers did you actually ever purchase?
Millions of Forth machines have been made because some can be
made for pennies. Some were used in a various space and
miltary projects, some in consumer items. You may have
owned some and not known it as they tend to be embedded
and not programmed by end users.
Forth is unusual in that it exists as an OS and platform for
large and complex applications on desktop and supercomputer
platforms and at the same time exists on very tiny machines
that can be made for about a penny. Sometimes Forth competes
with Lisp on high-end projects but Lisp doesn't compete on
the low end because it doesn't fit on penny-machines.
If you ask someone who likes to program in Lisp about
success they may say Lisp machines were successful even
if most people never touched them and they died out
because they were too expensive. If you ask someone who
likes to program in Forth or who has made millions
programming Forth machines or selling Forth machines
they may say Forth machines were successful even if
most people never learned anything about them.
Success can be measured in many ways so you are free to
define it as you see fit.
Best Wishes
John Passaniti
> Many millions of Forth machines have been made and deployed
> in the real word. Many generations of machines have been
> made over a nearly thirty year period. I think Lisp machines
> died out because they were just too expensive. After all, how
> many $80k Lisp computers did you actually ever purchase?
Lisp machines died out after creating a heck of a lot of commercial
invention and innovation in both computer hardware and software
engineering. And during their time, they out-performed non-dedicated
hardware. Or put another way, while they were expensive, they were
cheap relative to the performance they offered. What killed them off
was really two things-- research into generating efficient native code
from Lisp and that such code on PCs was actually running faster than
the dedicated hardware.
> Success can be measured in many ways so you are free to
> define it as you see fit.
Oh come on girls, you're *both* pretty.
Albert van der Horst
william... <william...@gmail.com> wrote:
>
>one difference was that there was much effort to create a lisp
>"machine", and after much
>time and money, all efforts failed...
>
>chuck moore has created a silicon forth machine ( machine instructions
>are colorforth33 )...
>
>a lisp to forth transform is not beyond code practice today...
>
Technically these were not failures. We are not alt.business.get.rich.
>it all comes down to cost/function...
>
>if it is more cost effective to express problem solution in lisp, then
>do so...
There is a lot more to it than that.
After all c is the state church.
>
>william...
Groetjes Albert
--
--
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
dwight
Hi
This reminds me of the GE diesel engine expert system.
They developed it in LISP and then used a Forth based
inference engine for the implementation.
It was done this way to reduce the size of the machine
to be used in the field.
Dwight
Elizabeth D Rather
I doubt if the algorithm was machine-translated, though. The style and
economics of Forth and Lisp are so different that the implementation
really needs to be re-thought. If a builder is accustomed to building
with brick and is given aluminum, steel, and concrete (or vice-versa) he
needs a redesign.
Anton Ertl
>Lisp machines died out after creating a heck of a lot of commercial
>invention and innovation in both computer hardware and software
>engineering. And during their time, they out-performed non-dedicated
>hardware. Or put another way, while they were expensive, they were
>cheap relative to the performance they offered. What killed them off
>was really two things-- research into generating efficient native code
>from Lisp and that such code on PCs was actually running faster than
>the dedicated hardware.
I think they were killed by fast Lisps on RISC workstations (ups and
downs in the AI market may also have played a role).
I think that the hardware tradeoffs may also have played a role.
AFAIK the Lisp machine CPUs were build using (bipolar) bit-slice
technology. That technology was being squeezed out of the market by
higher integration of CMOS, giving a clock speed and (with volume)
cost advantage over discrete solutions.
But Lisp machines probably could not fit on a single chip in the times
of the early RISCs. Instead, people worked on RISCs with features
helpful for dynamically-typed languages such a Smalltalk and LISP
(recommended reading: David Ungar's Ph.D. thesis on SOAR, published by
MIT books), and on how to compile these languages to these chips
effectively. And they found that they did not need that many special
hardware features (there has been a very informative article on
comp.arch by one of the Franz Lisp people on why they don't use the
SPARC features specifically designed for Lisp).
So, essentially, the market window for Lisp machines opened when
DEC-10 was killed, and it closed when RISCs came out.
- 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 2010: http://www.euroforth.org/ef10/
Standish P
You would never reach a fair understanding unless you hear from all
the sides by cross-posting to cll, cls and clc. I am interested in
hearing all sides so I am xposting it.
For the readers there, there are already 21 messages.
My take on this is as follows:
Forth is nothing but structured assembly.
One can write all the programming paradigms in assembly.
Forth inventor was at stanford and McCarthy was there, and most likely
in touch with the department since his graduation. He says that he
wrote algol compiler there.
All virtual machines, lisp, java etc use stack, so forth has no
monopoly over that. Only that they chose not to implement low level
access beyond, say print a character. Postscript, which is Forth, does
not have low level access to other devices except good access of
graphics.
Lisp and Forth are isomorphic in major concepts if not always in
implementations. People like Elizabeth consistently emphasize
differences in implementation without explaining clearly what they
actually are and how they do their thing in forth even if they dont
know about Lisp and Postscript.
Standish P
>
> - Show quoted text -
access beyond, say print a character [in Lisp].
John Passaniti
> My take on this is as follows:
Wow, you've packed a whole lot of wrong in one message. Allow me to
fix:
> Forth is nothing but structured assembly.
No, that's not a useful way to view Forth. Forth's interpreter allows
arbitrary extension and the process of extending Forth can allow
arbitrary semantics.
> One can write all the programming paradigms in assembly.
Eventually, yes. You can also write all programming paradigms on a
Turing machine, but you wouldn't want to. Your absurd reductionism
discounts the ease that languages bring to those paradigms. You can
for example write object oriented code in any language, but languages
that directly support object orientation are more pleasant,
productive, and expressive than languages that don't have such
features.
> Forth inventor was at stanford and McCarthy was there, and most likely
> in touch with the department since his graduation. He says that he
> wrote algol compiler there.
I am unaware of Charles Moore claiming to have written an Algol
compiler. His biography page on his web site does claim to have
written a Fortran-to-Algol converter, but it doesn't appear to have
been at Stanford.
> All virtual machines, lisp, java etc use stack, so forth has no
> monopoly over that.
False. The virtual machines in Lua, Python, Perl 6, and others are
not stack-based. Maybe using words like "all" isn't a good idea when
your knowledge clearly doesn't extend to "all". It might be said that
many or even most virtual machine architectures are stack-based, but
all are certainly not.
> Only that they chose not to implement low level
> access beyond, say print a character. Postscript, which is Forth, does
> not have low level access to other devices except good access of
> graphics.
Postscript is not Forth. It shares some concepts and flavor with
Forth, but is not Forth.
> Lisp and Forth are isomorphic in major concepts if not always in
> implementations. People like Elizabeth consistently emphasize
> differences in implementation without explaining clearly what they
> actually are and how they do their thing in forth even if they dont
> know about Lisp and Postscript.
This is vague. What specific "major concepts" are they "isomorphic
in"? Based on your previous messages, my guess is that in your zeal
to abstract away the important differences, you see "isomorphic"
commonality.
Paul N
> On Aug 14, 9:31 am, Brad Cantrell <cantre...@gmail.com> wrote:
> > I hate asking this question, but so far Ive read Leo Brodie's
> > "Starting Forth" and a few other Forth tutorials and they all mention
> > how Forth has very low level access to hardware that other languages
> > dont have and how it is a operating system unto itself, but Im having
> > trouble seeing this.
> > And also I dont see how Forth has any lower access than any other
> > language like C. All these languages simply make OS system calls or
> > interface with system libraries. Im sorry for asking this, but could
> > anyone tell me what Im missing here?
> Forth is nothing but structured assembly.
>
> One can write all the programming paradigms in assembly.
As I understand it, C has no equivalent of the "in" and "out"
instructions of the Z80 processor, so on a Z80 system it could
directly access any memory-mapped peripherals but not any of the (more
common) I/O mapped peripherals. The ZX Spectrum had IN and OUT
commands that could do this. I don't know whether Forth offers such
features or not.
> All virtual machines, lisp, java etc use stack, so forth has no
> monopoly over that.
I thought that a normal implementation of Forth required two stacks -
one for the programmer to keep values on and one for the computer to
keep track of where it had got to. C, by contrast, manages (in most
implementations) to use a single stack for both.
Standish P
> On Aug 21, 3:17 am, Standish P <stnd...@gmail.com> wrote:
>
> > My take on this is as follows:
>
> Wow, you've packed a whole lot of wrong in one message. Allow me to
> fix:
>
> > Forth is nothing but structured assembly.
>
> No, that's not a useful way to view Forth. Forth's interpreter allows
> arbitrary extension and the process of extending Forth can allow
> arbitrary semantics.
>
> > One can write all the programming paradigms in assembly.
>
> Eventually, yes. You can also write all programming paradigms on a
> Turing machine, but you wouldn't want to. Your absurd reductionism
> discounts the ease that languages bring to those paradigms. You can
> for example write object oriented code in any language, but languages
> that directly support object orientation are more pleasant,
> productive, and expressive than languages that don't have such
> features.
>
> > Forth inventor was at stanford and McCarthy was there, and most likely
> > in touch with the department since his graduation. He says that he
> > wrote algol compiler there.
>
> I am unaware of Charles Moore claiming to have written an Algol
> compiler. His biography page on his web site does claim to have
> written a Fortran-to-Algol converter, but it doesn't appear to have
> been at Stanford.
[BEGIN QUOTE]
Interviewer: Where did you learn to write compilers? Was this
something everybody at the time had to do?
Chuck: Well, I went to Stanford around ‘60, and there was a group of
grad students writing
an ALGOL compiler — a version for the Burroughs 5500. It was only
three or four of
them, I think, but I was impressed out of my mind that three or four
guys could sit down
and write a compiler.
I sort of said, “Well, if they can do it, I can do it,” and I just
did. It isn’t that hard.
There was a mystique about compilers at the time.
Interviewer: There still is.
Chuck: Yeah, but less so. You get these new languages that pop up from
time to time, and
I don’t know if they’re interpreted or compiled, but well, hacker-type
people are willing to
do it anyway.
The operating system is another concept that is curious. Operating
systems are dauntingly
complex and totally unnecessary. It’s a brilliant thing that Bill
Gates has done in selling
the world on the notion of operating systems. It’s probably the
greatest con game the
world has ever seen.
An operating system does absolutely nothing for you. As long as you
had something — a
subroutine called disk driver, a subroutine called some kind of
communication support, in
the modern world, it doesn’t do anything else. In fact, Windows spends
a lot of time with
overlays and disk management all stuff like that which are irrelevant.
You’ve got gigabyte
disks; you’ve got megabyte RAMs. The world has changed in a way that
renders the operating
system unnecessary.
Interviewer: What about device support?
Chuck: You have a subroutine for each device. That’s a library, not an
operating system.
Call the ones you need or load the ones you need.
[END QUOTE]
> > All virtual machines, lisp, java etc use stack, so forth has no
> > monopoly over that.
>
> False. The virtual machines in Lua, Python, Perl 6, and others are
> not stack-based. Maybe using words like "all" isn't a good idea when
> your knowledge clearly doesn't extend to "all". It might be said that
> many or even most virtual machine architectures are stack-based, but
> all are certainly not.
I said "use stack" and you talk of "stack-based".
>
> > Only that they chose not to implement low level
> > access beyond, say print a character. Postscript, which is Forth, does
> > not have low level access to other devices except good access of
> > graphics.
>
> Postscript is not Forth. It shares some concepts and flavor with
> Forth, but is not Forth.
>
> > Lisp and Forth are isomorphic in major concepts if not always in
> > implementations. People like Elizabeth consistently emphasize
> > differences in implementation without explaining clearly what they
> > actually are and how they do their thing in forth even if they dont
> > know about Lisp and Postscript.
>
> This is vague. What specific "major concepts" are they "isomorphic
> in"? Based on your previous messages, my guess is that in your zeal
> to abstract away the important differences, you see "isomorphic"
> commonality.
This is vague because corporatists wont bring in crisp explanations.
You gotta run after them and if they give you personally to keep less
circulation, still come and share.
They want you to worship the so called "CHUCK" and keep on buying
their scrap out of ignorance.
Elizabeth D Rather
> On 21 Aug, 08:17, Standish P<stnd...@gmail.com> wrote:
>> On Aug 14, 9:31 am, Brad Cantrell<cantre...@gmail.com> wrote:
>>> I hate asking this question, but so far Ive read Leo Brodie's
>>> "Starting Forth" and a few other Forth tutorials and they all mention
>>> how Forth has very low level access to hardware that other languages
>>> dont have and how it is a operating system unto itself, but Im having
>>> trouble seeing this.
>
>>> And also I dont see how Forth has any lower access than any other
>>> language like C. All these languages simply make OS system calls or
>>> interface with system libraries. Im sorry for asking this, but could
>>> anyone tell me what Im missing here?
>
>> Forth is nothing but structured assembly.
>>
>> One can write all the programming paradigms in assembly.
>
> As I understand it, C has no equivalent of the "in" and "out"
> instructions of the Z80 processor, so on a Z80 system it could
> directly access any memory-mapped peripherals but not any of the (more
> common) I/O mapped peripherals. The ZX Spectrum had IN and OUT
> commands that could do this. I don't know whether Forth offers such
> features or not.
Yes, Forth's @ ("fetch") and ! ("store") instructions can read and write
memory-mapped I/O ports. There are variants of @ and ! for the most
common sizes of data or port (8-bit, 16-bit, etc.). For platforms
without naturally memory-mapped I/O it's common to find P@ and P! (Port
fetch and store) commands, and for portability they are often available
as alternative names to their standard equivalents (most commonly C@ and
C! for 8-bit access).
>> All virtual machines, lisp, java etc use stack, so forth has no
>> monopoly over that.
>
> I thought that a normal implementation of Forth required two stacks -
> one for the programmer to keep values on and one for the computer to
> keep track of where it had got to. C, by contrast, manages (in most
> implementations) to use a single stack for both.
Yes. And both are directly visible and usable to the programmer,
provided the rules regarding them (especially the return stack) are
respected. The actual implementation and use of stacks in Forth and C
differ significantly.
toby
> On Aug 21, 3:17 am, Standish P <stnd...@gmail.com> wrote:
>
> > All virtual machines, lisp, java etc use stack, so forth has no
> > monopoly over that.
>
> False. The virtual machines in Lua, Python, Perl 6, and others are
> not stack-based.
Actually Lua's VM is heavily stack oriented, if I recall correctly
from experiences embedding it in C/C++.
Alex McDonald
The LUA version 5 VM has 250 "registers" which are indices into the
current stack frame. None of the 38 opcodes has any stack-like
operations; http://luaforge.net/docman/view.php/83/98/ANoFrillsIntroToLua51VMInstructions.pdf
Albert van der Horst
Standish P <stn...@gmail.com> wrote:
<SNIP>
>
>One can write all the programming paradigms in assembly.
Is that can as in:
if there is a path, I can walk to the moon.
It's just one step behind the other, isn't it?
Have you actually tried writing a program?
It is tedious enough as it is.
<SNIP>
Groetjes Albert
P.S. I've written some non-trivial all-assembler stuff.
See my web site below.
Albert van der Horst
>their scrap out of ignorance.
>
Mr. Standish and others, could you please sign your message.
Google is just a miniscule part of Usenet.
[I need to mess with the headers to find the poster, and even
some posters have no sender in the header that I can find.]
Groetjes Albert
Albert van der Horst
It is interesting what happens if they are not there.
A Forther will type (or start his program with)
"
CODE P! POP|X, DX| POP|X, AX| OUT|D, X'| NEXT, END-CODE
"
and get it over with.
More than anything this sets Forth programmers apart :
they actually have the confidence to do this
they actually have the expertise to do this
they actually do this
>Cheers,
>Elizabeth
Groetjes Albert
[Disclaimer: code shown is ciforth's postit-fixup assembler.
Actual code differs among Forth compilers.]
P.M.Lawrence
> On 8/21/10 5:45 AM, Paul N wrote:
.
.
> > I thought that a normal implementation of Forth required two stacks -
> > one for the programmer to keep values on and one for the computer to
> > keep track of where it had got to. C, by contrast, manages (in most
> > implementations) to use a single stack for both.
>
> Yes. And both are directly visible and usable to the programmer,
> provided the rules regarding them (especially the return stack) are
> respected. The actual implementation and use of stacks in Forth and C
> differ significantly.
The way I would describe it is that the data stack is directly visible/
accessible but the return stack is indirectly visible/accessible,
since to get at the latter you work through keywords that go via the
former. P.M.Lawrence.
John Passaniti
> [BEGIN QUOTE]
> I sort of said, “Well, if they can do it, I can do it,” and I just
> did. It isn’t that hard.
The quote is about Forth, not Algol. He's saying it wasn't hard to
create a Forth compiler. Your claim was that he wrote an Algol
compiler. You're wrong.
> > > All virtual machines, lisp, java etc use stack, so forth has no
> > > monopoly over that.
>
> > False. The virtual machines in Lua, Python, Perl 6, and others are
> > not stack-based. Maybe using words like "all" isn't a good idea when
> > your knowledge clearly doesn't extend to "all". It might be said that
> > many or even most virtual machine architectures are stack-based, but
> > all are certainly not.
>
> I said "use stack" and you talk of "stack-based".
And for some reason the semantic distance between "use stack" and
"stack-based" in some way validates your claim? Your statement was
that "all virtual machines [...] use stack." One presumes you're
talking about the fundamental execution model, and not something
completely trivial like "somewhere in the code, they use a stack."
So, you're either wrong or you're making a distinction that is so
trivial as to be useless.
> > This is vague. What specific "major concepts" are they "isomorphic
> > in"? Based on your previous messages, my guess is that in your zeal
> > to abstract away the important differences, you see "isomorphic"
> > commonality.
>
> This is vague because corporatists wont bring in crisp explanations.
> You gotta run after them and if they give you personally to keep less
> circulation, still come and share.
>
> They want you to worship the so called "CHUCK" and keep on buying
> their scrap out of ignorance.
I have no idea what you're talking about. And based on this thread, I
doubt you do.
John Passaniti
> > False. The virtual machines in Lua, Python, Perl 6, and others are
> > not stack-based.
>
> Actually Lua's VM is heavily stack oriented, if I recall correctly
> from experiences embedding it in C/C++.
Older versions of Lua (4.x and prior) did indeed use a stack-based
virtual machine. Version 5.0 was the first that switched to a
register-based virtual machine.
George Neuner
Lua 5 still is basically a stack machine - it's a variant of what's
generally called a "deep access" stack, in which the machine can
access "deep" stack elements directly. Lua's variation does away with
push/pop/etc. top-of-stack instructions.
George
John Passaniti
> Lua 5 still is basically a stack machine - it's a variant of what's
> generally called a "deep access" stack, in which the machine can
> access "deep" stack elements directly. Lua's variation does away with
> push/pop/etc. top-of-stack instructions.
That's not how the authors characterize it: http://www.lua.org/doc/jucs05.pdf
I think there may be some confusion here between the C interface to
Lua (which does use a stack) and the execution model for the Lua VM
(which is a register-based VM).
Andrew Haley
In comp.lang.forth John Passaniti <john.pa...@gmail.com> wrote:
> On Aug 23, 12:18?pm, George Neuner <gneun...@comcast.net> wrote:
>> Lua 5 still is basically a stack machine - it's a variant of what's
>> generally called a "deep access" stack, in which the machine can
>> access "deep" stack elements directly. ?Lua's variation does away with
>> push/pop/etc. top-of-stack instructions.
>
> That's not how the authors characterize it:
> http://www.lua.org/doc/jucs05.pdf
George is right, though:
"Since 2003, with the release of Lua 5.0, Lua uses a register-based
virtual machine. This register-based machine also uses a stack, for
allocating activation records, wherein the registers live. When Lua
enters a function, it preallocates from the stack an activation record
large enough to hold all the function registers."
So, these "registers" are in fact stack-allocated locals.
Andrew.
George Neuner
<john.pa...@gmail.com> wrote:
>On Aug 23, 12:18 pm, George Neuner <gneun...@comcast.net> wrote:
>> Lua 5 still is basically a stack machine - it's a variant of what's
>> generally called a "deep access" stack, in which the machine can
>> access "deep" stack elements directly. Lua's variation does away with
>> push/pop/etc. top-of-stack instructions.
>
>That's not how the authors characterize it: http://www.lua.org/doc/jucs05.pdf
Actually, that's exactly how they characterize it. See page 11:
"... This register-based machine also uses a stack, for allocating
activation records, wherein the registers live. When Lua enters a
function, it preallocates from the stack an activation record
large enough to hold all the function registers. All local variables
are allocated in registers. ..."
Lua 5 "registers" are slots in the function's stack frame and the VM
instructions index them directly. Deep-access stack.
George
Alex McDonald
> On Mon, 23 Aug 2010 09:46:32 -0700 (PDT), John Passaniti
>
Reminds me of the activation records in IBM S/360/370. I can't
remember ever calling them deep-access stacks...
Nick
> Lua 5 still is basically a stack machine - it's a variant of what's
> generally called a "deep access" stack, in which the machine can
> access "deep" stack elements directly. Lua's variation does away with
> push/pop/etc. top-of-stack instructions.
I find it hard to attach the term "stack" to something that doesn't have
"push/pop/etc". That is, to me, what makes it a stack rather than some
other sort of data structure.
--
Online waterways route planner | http://canalplan.eu
Plan trips, see photos, check facilities | http://canalplan.org.uk
John Passaniti
wrote:
> So, these "registers" are in fact stack-allocated locals.
I have a hard time characterizing the Lua virtual machine as anything
but register-based given the instruction set. The fact that the
virtual machine *uses* a stack is kind of like saying the Z-80 is a
stack-based microprocessor because it has an uses a stack pointer.
The Lua authors characterize the virtual machine as register-based.
During the beta period prior to the release of 5.0, there was much
talk in the mailing list about this change. Nobody saw it as anything
but a fundamental change from the stack-based architecture in prior
releases. And unless I fundamentally misunderstand some of the
upcoming changes, that stack is also going away in the next release,
to better support the ability to call Lua from C and vice versa,
especially in contexts which are not stack-like (like yielding in
coroutines).
Anton Ertl
>On Aug 23, 2:05=A0pm, Andrew Haley <andre...@littlepinkcloud.invalid>
>wrote:
>> So, these "registers" are in fact stack-allocated locals.
>
>I have a hard time characterizing the Lua virtual machine as anything
>but register-based given the instruction set. The fact that the
>virtual machine *uses* a stack is kind of like saying the Z-80 is a
>stack-based microprocessor because it has an uses a stack pointer.
No. On the Z80 the registers don't live on the stack. There are few
real-machine equivalents to this common VM architecture style. Maybe
the TMS9900 or a subset of the VAX where you only use SP-relative
addressing for everything.
This VM architecture style is usually called "register machine",
apparently because in most VM instructions it behaves like a register
machine, as you note. But when you look at what happens when a frame
is allocated, you see that it is not like common hardware register
machines.
>The Lua authors characterize the virtual machine as register-based.
>During the beta period prior to the release of 5.0, there was much
>talk in the mailing list about this change. Nobody saw it as anything
>but a fundamental change from the stack-based architecture in prior
>releases.
Certainly going from a zero-address instruction for, e.g., addition to
a three-address instruction is a big change, especially in the
opportunities for the VM-code generator.
Paul Rubin
> No. On the Z80 the registers don't live on the stack. There are few
> real-machine equivalents to this common VM architecture style. Maybe
> the TMS9900 or a subset of the VAX where you only use SP-relative
> addressing for everything.
Sparc?
Andrew Haley
> wrote:
>> So, these "registers" are in fact stack-allocated locals.
>
> I have a hard time characterizing the Lua virtual machine as anything
> but register-based given the instruction set.
I don't think it's possible to make any clear test to distingish
between a stack-allocated virtual register and a temporary that
resides in a stack slot. You say tomaydoh, I say tomato.
> The fact that the virtual machine *uses* a stack is kind of like
> saying the Z-80 is a stack-based microprocessor because it has an
> uses a stack pointer.
>
> The Lua authors characterize the virtual machine as register-based.
> During the beta period prior to the release of 5.0, there was much
> talk in the mailing list about this change. Nobody saw it as
> anything but a fundamental change from the stack-based architecture
> in prior releases. And unless I fundamentally misunderstand some of
> the upcoming changes, that stack is also going away in the next
> release, to better support the ability to call Lua from C and vice
> versa, especially in contexts which are not stack-like (like
> yielding in coroutines).
Sure, but we're now just arguing about the meaning of the word
"register". Fair enough, call them registers if you like, but they're
still stack-allocated locals.
Andrew.
Rob Warnock
+---------------
Or the AMD Am29000 series [*variable*-sized register windows]...
-Rob
-----
Rob Warnock <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Andrew Haley
> John Passaniti <john.pa...@gmail.com> writes:
>>On Aug 23, 2:05=A0pm, Andrew Haley <andre...@littlepinkcloud.invalid>
>>wrote:
>>> So, these "registers" are in fact stack-allocated locals.
>>
>>I have a hard time characterizing the Lua virtual machine as anything
>>but register-based given the instruction set. The fact that the
>>virtual machine *uses* a stack is kind of like saying the Z-80 is a
>>stack-based microprocessor because it has an uses a stack pointer.
>
> No. On the Z80 the registers don't live on the stack. There are few
> real-machine equivalents to this common VM architecture style. Maybe
> the TMS9900 or a subset of the VAX where you only use SP-relative
> addressing for everything.
The CRISP (C-language Reduced Instruction Set Processor) [1] from AT&T
did that: its registers really were just offsets in the stack. This
had the rather nice effect that you could pass the address of a
register, and so you never had to spill register contents to the
stack. One interesting conclusion for me was that, compared with how
well it worked on this machine, C is pretty badly suited to many
computer architectures.
Andrew.
Anton Ertl
>Paul Rubin <no.e...@nospam.invalid> wrote:
>+---------------
>| an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>| > No. On the Z80 the registers don't live on the stack. There are few
>| > real-machine equivalents to this common VM architecture style. Maybe
>| > the TMS9900 or a subset of the VAX where you only use SP-relative
>| > addressing for everything.
>|
>| Sparc?
>+---------------
>
>Or the AMD Am29000 series [*variable*-sized register windows]...
And its successor, the IA64 register stack engine.
The implementation is different in these cases, though, because these
real-machine architectures have the registers in real registers, and
only push them out to memory when they are not directly accessible.
You cannot access a register through a memory address. In contrast,
this is possible in principle with these VM implementations (although
it's not necessarily possible in the VM architecture; e.g., in the JVM
you cannot get the address of a or a reference to a local, even though
it would have been easily possible in the early interpreted
implementations).
The CRISP architecture mentioned by Andrew Haley is a better fit.
Duane Rettig
> George Neuner <gneun...@comcast.net> writes:
> > Lua 5 still is basically a stack machine - it's a variant of what's
> > generally called a "deep access" stack, in which the machine can
> > access "deep" stack elements directly. Lua's variation does away with
> > push/pop/etc. top-of-stack instructions.
>
> I find it hard to attach the term "stack" to something that doesn't have
> "push/pop/etc". That is, to me, what makes it a stack rather than some
> other sort of data structure.
Think of a stack as a LIFO (Last In, First Out) queue. The question
is: what is going in and out? In this day and age of cache
management, a push/pop of a single natural word (4 or 8 bytes) is
ludicrous for performance, especially when the movement of the stack
pointer is sometimes accompanied by extra checks and/or guard page
faults. So think of a higher level program which uses activation
frames as a cached stack, which beef up performance in the area of
stack access. The frames are still layed into memory in LIFO fashion
(with exceptions, of course, like non-local exits and, in some
languages, Continuation Passing Style, but this does not remove the
importance of the stack at the lower level.
Duane
George Neuner
It is an example of a stack activation record.
>I can't remember ever calling them deep-access stacks...
The term "deep access" comes from stack machine literature. In their
pure form stack machines only address the "top" of the stack with
push/pull/peek instructions. "deep access" variant stack ISAs allow
more generalized stack relative addressing.
Most everybody here knows this following, but for the sake of
exposition:
Virtually all CPUs allow stack relative addressing ... but as the
stack grows and shrinks the offset to any particular stack resident
datum keeps changing. This is why the function call sequence for most
CPUs reserves a "framing" register so that stack elements can be
addressed using fixed offsets even as the stack top changes.
By using fixed size activation records and disallowing code to use the
stack for temporary dynamic storage (alloca et al), stack relative
addressing is just as easy as frame relative. This somewhat
simplifies ISA by removing a required register and makes it easier to
map a virtual machine onto real hardware.
Most decent C compilers have the option to not use explicit framing.
It places some minor limitations on the code but for that you gain a
general index register which can be helpful on register starved
architectures like x86. (And even on 68K ... sometimes you really
need that 7th address register 8-).
George
George Neuner
<3-no...@temporary-address.org.uk> wrote:
>George Neuner <gneu...@comcast.net> writes:
>
>> Lua 5 still is basically a stack machine - it's a variant of what's
>> generally called a "deep access" stack, in which the machine can
>> access "deep" stack elements directly. Lua's variation does away with
>> push/pop/etc. top-of-stack instructions.
>
>I find it hard to attach the term "stack" to something that doesn't have
>"push/pop/etc". That is, to me, what makes it a stack rather than some
>other sort of data structure.
Well, its a stack of activation records rather than a stack of
individual elements.
George
Antony
I was wondering if it is at all possible to have anything to be stack
less and be a mechanism of general purpose computation ( and control)
(be it a programming language or a hardware or a VM).
Doesn't every control mechanism end up being either a state machine or a
push down automata with the former being striclty less powerful and good
for regex kind of problems (whether it's pattern match or process control).
Is there a way to have push down automata without using a stack or is
there a substitute for push down automata?
Maybe the debate is about how much stuff beyond the stack and stack
based operations does something need to provide for it to be called
something other than a stack based language/machine/VM
I don't have much formal grasp of these things. Would love some not so
mathematical feedback.
-Antony
Pascal J. Bourguignon
> Not at any specific message.
>
> I was wondering if it is at all possible to have anything to be stack
> less and be a mechanism of general purpose computation ( and control)
> (be it a programming language or a hardware or a VM).
Yes. A turing machine has no stack. However, it's possible to
implement a stack on a turing machine. In some early processors,
there were no automatic stack managing instruction. At most, to jump
to a subroutine, there was an instruction that saved the current PC to
a specific memory address, so that you could know where to return to.
But even without this help, you could still implement stacks on
stackless machines.
> Doesn't every control mechanism end up being either a state machine or
> a push down automata with the former being striclty less powerful and
> good for regex kind of problems (whether it's pattern match or process
> control).
In practice, we don't have infinite memory, so all our computers are
indeed state machines (with a lot of state).
But it is not interesting to see them this way, because for our little
brains, it's easier to understand what they do and how they're built,
using the concept of stack and other higher level concepts such as
those of lambda calculus, or OO programming.
> Is there a way to have push down automata without using a stack or is
> there a substitute for push down automata?
By definition, a push down automata has a stack.
> Maybe the debate is about how much stuff beyond the stack and stack
> based operations does something need to provide for it to be called
> something other than a stack based language/machine/VM
>
> I don't have much formal grasp of these things. Would love some not so
> mathematical feedback.
Soon enough you need to define definitions and check formally. So
get up to speed to the mathematical definitions of these concepts,
otherwise you will kill talking to say nothing.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Nick
I've got absolutely no problem with that - but I'd say you push and pop
activation records on and off the stack.
I often push records onto stacks in C - linked lists of structures.
It's still a stack and it's still pushing and popping to me.
George Neuner
<spam+lisp...@gmail.com> wrote:
>Not at any specific message.
>
>I was wondering if it is at all possible to have anything to be stack
>less and be a mechanism of general purpose computation ( and control)
>(be it a programming language or a hardware or a VM).
Certainly. GOTO programming, including continuation passing style
(aka GOTO with arguments), doesn't inherently need a stack.
A state machine can model general recursion to a fixed depth without a
stack by implicitly tracking the winding in the machine states. Tail
recursion can be modeled to any depth.
>Doesn't every control mechanism end up being either a state machine or a
>push down automata with the former being striclty less powerful and good
>for regex kind of problems (whether it's pattern match or process control).
PDA is a state machine. Every known control mechanism is isomorphic
to some form of state machine.
>Is there a way to have push down automata without using a stack
No ... the existence of the stack is implied by the definition.
> or is there a substitute for push down automata?
There's no general substitute. You can get a lot done with GOTO (CPS,
etc.), but general recursion absolutely requires some kind of LIFO
storage mechanism. The stack may be implicit in the control mechanism
or maintained explicitly as a separate data structure, but in one form
or another it is always there.
>Maybe the debate is about how much stuff beyond the stack and stack
>based operations does something need to provide for it to be called
>something other than a stack based language/machine/VM
To my thinking, a "stack machine" must have a full set of zero-address
arithmetic and logic instructions and must use the stack as its
primary evaluation mechanism.
George
m_l_g3
is that Lisp is based on the typeless lambda-calculus notion of a
function,
while Forth is based on the computer notion of a function.
If you know Forth, you may start writing in Lisp as if it is
the same language with a different syntax. And, of course,
you find out that Lisp's lists are very convenient.
When I read the title of the thread, I thought that you
wrote a Forth in Lisp, that indeed would be meaningful:
a Forth system with infinite cell size and garbage-collected
data structures that may be placed on the stack.
On Aug 14, 8:31 pm, Brad Cantrell <cantre...@gmail.com> wrote:
> And also I dont see how Forth has any lower access than any other
> language like C.
: ENTER >R ;
: GIVE> R> ;
: a ." aaa " GIVE> ." AAA " ;
: b ." bbb " ENTER ." BBB " ;
a b
prints:
aaa bbb AAA BBB ok
Enough low-level?
Albert van der Horst
m_l_g3 <m_l...@yahoo.com> wrote:
>Forth and Lisp are both functional languages; the difference
>is that Lisp is based on the typeless lambda-calculus notion of a
>function,
>while Forth is based on the computer notion of a function.
>
>If you know Forth, you may start writing in Lisp as if it is
>the same language with a different syntax. And, of course,
>you find out that Lisp's lists are very convenient.
>
>When I read the title of the thread, I thought that you
>wrote a Forth in Lisp, that indeed would be meaningful:
>a Forth system with infinite cell size and garbage-collected
>data structures that may be placed on the stack.
>
>> And also I dont see how Forth has any lower access than any other
>> language like C.
>
>: ENTER >R ;
>: GIVE> R> ;
>
>
Is this low level? Or just flow control missing from most languages?
It is better to use words supplied by a Forth and whose use is
documented. A coroutine call is called CO in ciforth , ;: in
Seaforth. It so to say swap the program counter with the return
address on the stack.
What you do is extending the Forth with those words, but it
depends on how the return stack is used whether it works.
(In real life you must put it in a separate module, with a test.)
With CO :
: a ." aaa " CO ." AAA " ;
: b ." bbb " CO ." BBB " ;
a b
prints:
aaa bbb AAA BBB ok
This usage of the coroutine call is new to me, and
it definitely looks more "co".
I would have done:
: b ." bbb " CO ." BBB " ;
: a ." aaa " b ." AAA " ;
with the same effect, but a is in charge.
In your code a and b are on equal footing and a is just first in time.
Thanks Albert
--
--
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
m_l_g3
wrote:
> In article <29e55e0e-3ab8-4750-810a-7d6563141...@i13g2000yqe.googlegroups.com>,
> m_l_g3 <m_l...@yahoo.com> wrote:
>
> >On Aug 14, 8:31=A0pm, Brad Cantrell <cantre...@gmail.com> wrote:
> >> And also I dont see how Forth has any lower access than any other
> >> language like C.
>
> >: ENTER >R ;
> >: GIVE> R> ;
>
> >Enough low-level?
>
> Is this low level? Or just flow control missing from most languages?
The point was to show that return address manipulations exist in
Forth,
not to explain what to do with them.
The second language that allows this stuff is Assembler.
Aaron W. Hsu
>Not at any specific message.
>I was wondering if it is at all possible to have anything to be stack
>less and be a mechanism of general purpose computation ( and control)
>(be it a programming language or a hardware or a VM).
>Doesn't every control mechanism end up being either a state machine or a
>push down automata with the former being striclty less powerful and good
>for regex kind of problems (whether it's pattern match or process control).
So, what you are calling a state machine is actually termed a Finite State
Machine. It is equivalent to Regular Expressions. A PDA is equivalent
to context-free languages. These however, are not equivalent to the
class of languages decideable or recognizable by a Turing machine or
the Lambda calculus.
Turing machines are one way to model computation where you have an
infinite random access memory. It is the random-access which makes it more
powerful than the push-down automaton method. In a PDA, you can't get at
elements further down in the stack without first popping off the ones that
are higher on the stack. This LIFO model has restrictions. Turing machines
and other equivalent computation models, such as the Lambda calculus
and an arbitrary-size register machine (where the machine has a fixed
number of infinitely large registers), work without having an explicit
stack and don't rely on the stack model for thinking about computation.
Aaron W. Hsu
Albert van der Horst
m_l_g3 <m_l...@yahoo.com> wrote:
>On Aug 30, 4:58=A0pm, Albert van der Horst <alb...@spenarnc.xs4all.nl>
>wrote:
>> In article <29e55e0e-3ab8-4750-810a-7d6563141...@i13g2000yqe.googlegroups=
>.com>,
>> m_l_g3 =A0<m_l...@yahoo.com> wrote:
>>
>> >On Aug 14, 8:31=3DA0pm, Brad Cantrell <cantre...@gmail.com> wrote:
>> >> And also I dont see how Forth has any lower access than any other
>> >> language like C.
>>
>> >: ENTER >R ;
>> >: GIVE> R> ;
>>
>> >Enough low-level?
>>
>> Is this low level? Or just flow control missing from most languages?
>
>The point was to show that return address manipulations exist in
>Forth,
>not to explain what to do with them.
>
>The second language that allows this stuff is Assembler.
Those manipulations are possible in Forth, but not endorsed
by the standard, so strictly speaking they are not allowed.
You are effectively programming in assembler.
You can do the same with a C that has an assembler directive
if you know as much about the C you used as about the Forth
you used.
Groetjes Albert
Bernd Paysan
> Those manipulations are possible in Forth, but not endorsed
> by the standard, so strictly speaking they are not allowed.
> You are effectively programming in assembler.
I wouldn't say it that way. The standard does not endorse this, but
usually, language implementations go beyond a certain standard, and
guarantee things beyond the standard. You may access libraries that are not
part of the standard, and of course you may access the return stack if the
implementation allows it. This is then portable across platforms and
between different implementations - when they all allow return stack access.
This is quite different from programming in assembler. It's closer to
program C and using GCC extensions - portable across platforms and even
several other C compiler support GCC extensions.
--
Bernd Paysan
"If you want it done right, you have to do it yourself!"
http://www.jwdt.com/~paysan/