> 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 isnt 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 dont know if theyre 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. Its a brilliant thing that Bill Gates has done in selling the world on the notion of operating systems. Its 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 doesnt do anything else. In fact, Windows spends a lot of time with overlays and disk management all stuff like that which are irrelevant. Youve got gigabyte disks; youve 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. Thats 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.
> > 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.
> 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.
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." ==================================================
In article <97ea7f26-11c5-4c65-8d75-c26f9d010...@y11g2000yqm.googlegroups.com>, Standish P <stnd...@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, 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
In article <f9e02b23-c1b7-466d-9f58-0d4303f62...@v8g2000yqe.googlegroups.com>, Standish P <stnd...@gmail.com> wrote: <SNIP>
>They want you to worship the so called "CHUCK" and keep on buying >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, 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
>On 8/21/10 5:45 AM, Paul N wrote: >> 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).
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.]
-- -- 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
Elizabeth D Rather wrote: > 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.
On Aug 21, 1:12 pm, Standish P <stnd...@gmail.com> wrote:
> [BEGIN QUOTE] > I sort of said, Well, if they can do it, I can do it, and I just > did. It isnt 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.
On Aug 21, 5:28 pm, toby <t...@telegraphics.com.au> wrote:
> > 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.
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.
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.
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).
In comp.lang.forth John Passaniti <john.passan...@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.
"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.
On Mon, 23 Aug 2010 09:46:32 -0700 (PDT), John Passaniti
<john.passan...@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.
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.
> On Mon, 23 Aug 2010 09:46:32 -0700 (PDT), John Passaniti
> <john.passan...@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.
> 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
Reminds me of the activation records in IBM S/360/370. I can't remember ever calling them deep-access stacks...
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. -- Online waterways route planner | http://canalplan.eu Plan trips, see photos, check facilities | http://canalplan.org.uk
On Aug 23, 2:05 pm, 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.
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).
John Passaniti <john.passan...@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.
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.
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.
In comp.lang.forth John Passaniti <john.passan...@gmail.com> wrote:
> On Aug 23, 2:05?pm, 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.
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.
Paul Rubin <no.em...@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]...
-Rob
----- Rob Warnock <r...@rpw3.org> 627 26th Avenue <URL:http://rpw3.org/> San Mateo, CA 94403 (650)572-2607
In comp.lang.forth Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
> John Passaniti <john.passan...@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.
r...@rpw3.org (Rob Warnock) writes: >Paul Rubin <no.em...@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.
On Aug 23, 1:19 pm, Nick <3-nos...@temporary-address.org.uk> wrote:
> 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.
<b...@rivadpm.com> wrote: >On 23 Aug, 19:21, George Neuner <gneun...@comcast.net> wrote: >> On Mon, 23 Aug 2010 09:46:32 -0700 (PDT), John Passaniti
>> <john.passan...@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.
>> 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
>Reminds me of the activation records in IBM S/360/370.
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-).
