Welcome, Guest. Please login or register.


Author Topic: FORTH (Read 63835 times)

Offline BruceTanner

  • EP lover
  • *
  • Posts: 609
  • Country: gb
Re: FORTH
« Reply #30 on: 2013.March.02. 21:58:39 »
Quote from: Zozosoft
How is possible character <-> character code conversion in FORTH?
Example in BASIC: CHR$(65) or ORD("A")
(For only printing the EMIT do the code->chr conversion.)
For converting from a character to a number, ASCII is what you want - it reads the very next character and leaves its ASCII value on the stack. Thus:

ASCII A . 65 ok

For going the other way, look at Starting Forth, Chapter 7 "A Number of Kinds of Numbers", about half way through, for <# # #s #> etc - basically EMIT into a buffer.

Is that what you meant?

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: FORTH
« Reply #31 on: 2013.March.04. 11:34:00 »
How can I "print" (well, dump) the (output of) vlist into a file (eg using FILEIO with ep128emu), so I can examine it later outside of IS-FORTH too?

Btw, did you know, that an about Sinclair ZX81 class of machine - the Jupiter ACE, released in 1982 - used forth as the "default language" (unlike most of other 8 bit computers using BASIC)?

Offline BruceTanner

  • EP lover
  • *
  • Posts: 609
  • Country: gb
Re: FORTH
« Reply #32 on: 2013.March.04. 12:22:18 »
Quote from: lgb
How can I "print" (well, dump) the (output of) vlist into a file (eg using FILEIO with ep128emu), so I can examine it later outside of IS-FORTH too?

Btw, did you know, that an about Sinclair ZX81 class of machine - the Jupiter ACE, released in 1982 - used forth as the "default language" (unlike most of other 8 bit computers using BASIC)?
Probably the easiest way is with EXOS channels:

" A:\VLIST" 10 OPENOUT   10 #EDITOR   VLIST   100 #EDITOR   10 CLOSE

You will have to type this on one line because the editor channel is redirected in the middle.

Bit by bit:

" A:\VLIST" 10 OPENOUTcreates the file on channel 10
10 #EDITORsets the channel used for the editor (ie. VLIST's output) to the file on channel 10
VLISTlists all the words to the editor channel, ie your new file
100 #EDITORsets the editor channel back to the default of 100
10 CLOSEcloses the new channel and your file

I notice in modern FORTHs VLIST has been renamed as WORDS, which is a much cleaner name.

Yes I remember seeing the Jupiter ACE being advertised but I never got to "have a go" on it. There seems to have been a surge in popularity in FORTH in the early 1980s which then declined. :(

Offline BruceTanner

  • EP lover
  • *
  • Posts: 609
  • Country: gb
Re: FORTH
« Reply #33 on: 2013.March.04. 12:31:28 »
Quote from: BruceTanner
I have written a version of the zzzip speed test in FORTH. It does exactly the same thing - gets a screen memory pointer from EXOS and fills the screen with As, then Bs, ... Z.

...

: GET_SCREEN_MEM ( -- addr )
 0 0 3 102 SPFUNC          ( Special func Get Video Memory on chan 102 )
 0 <> ABORT" SPFUNC ERROR" ( EXOS error )
 SWAP DROP                 ( Do not need value returned in C )
;
Quote
zozosoft

(And the FORTH have support for the EXOS Special Function call, no machine code needed for ask the video address.)

I have just noticed in the IS-FORTH manual there is an even easier way of doing this. VADDR gives you a pointer to the video memory!

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14775
  • Country: hu
    • http://enterprise.iko.hu/
Re: FORTH
« Reply #34 on: 2013.March.07. 23:00:00 »
Is recursion possible in Forth?

Offline BruceTanner

  • EP lover
  • *
  • Posts: 609
  • Country: gb
Re: FORTH
« Reply #35 on: 2013.March.07. 23:39:56 »
Quote from: Zozosoft
Is recursion possible in Forth?
Yes, being stack based anyway it is quite natural. There is a ‘normal‘ infix (not reverse polish) expression evaluater example in the IS-FORTH manual. [When evaluating eg 3*2+(6-4), when ( is encountered you recurse to evaluate the expression between ( and ).]

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: FORTH
« Reply #36 on: 2013.March.08. 09:02:08 »
forth looks like a very interesting piece of language ... I am using gforth now (on Linux) to understand the basics, however I don't know how to figure out the differences: I guess gforth is a more modern dialect of forth than is-forth (which is pre-forth-83 afaik, eg it uses VLIST, which is words in later forth'es as you've written too some msgs earlier in this thread), so things can be different. Eg: I can use "see" to view the definition of a word. It's really interesting with gforth, either I can see the forth definition or even assembly fragment used to implement that word. Is it possible to use something like "see" in IS-FORTH? It does not seem to understand this word at least. Also, how is it possible to define something in assembly? Hmm, maybe I should read the manual (RTFM) and not asking these? :) And btw, thanks for the "save the output of vlist" help, I did the usual beginner's fault at first: forgetting the space after " :)

Offline BruceTanner

  • EP lover
  • *
  • Posts: 609
  • Country: gb
Re: FORTH
« Reply #37 on: 2013.March.08. 09:44:54 »
Yes I find FORTH a fascinating language & operating system, completely different from anything else. Very simple yet very powerful and without the bloat and fat that comes with modern OSs.

As far as I know IS-FORTH is forth-83 (it was supposed to be!) but it is possible I missed something. I am not sure about WORDS - I thought that came later but I might be wrong. Of course you can always enter

: WORDS   VLIST ; :)

There is no SEE in IS-FORTH. I have often wondered if it would be possible to "disassemble" a forth word but I didn't realise someone had actually done it! I will think about that one and see if I can come up with anything. Yes it has a built-in assembler but that too is reverse polish eg DE PUSH - RTFM! - but I acknowledge TFM is not always as clear or in deapth as it could be :oops:

I have not used gforth or indeed any other modern forth - I expect there have been some advances over the last 30 years!

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: FORTH
« Reply #38 on: 2013.March.08. 10:09:28 »
Quote from: BruceTanner
Yes I find FORTH a fascinating language & operating system, completely different from anything else. Very simple yet very powerful and without the bloat and fat that comes with modern OSs.
I must agree with these, even with the fact that I know _some_ forth only since a day or so :)

Quote
As far as I know IS-FORTH is forth-83 (it was supposed to be!) but it is possible I missed something. I am not sure about WORDS - I thought that came later but I might be wrong. Of course you can always enter

: WORDS   VLIST ; :)

There is no SEE in IS-FORTH. I have often wondered if it would be possible to "disassemble" a forth word but I didn't realise someone had actually done it! I will think about that one and see if I can come up with anything. Yes it has a built-in assembler but that too is reverse polish eg DE PUSH - RTFM! - but I acknowledge TFM is not always as clear or in deapth as it could be :oops:
Hehe, cool, WORDS defined as VLIST :)

Afaik forth of Jupiter ACE can do it. As far as I can see, it really shows the strength of forth, as ACE only has 8K ROM which includes the forth, basic word definitions, character set definition and also the elementary (tape oriented) I/O routines:

"The ACE had an 8 KB ROM containing the Forth kernel and operating system, and the predefined dictionary of Forth words in about 5KB. The remaining 3KB of ROM were used for tape control, floating point numbers library and character definitions table. Some of the ROM was written in Z80 machine code, but some was also coded in Forth."

What I've found:

"The ACE's Forth could decompile its programs, unlike usual Forth systems. This decompiling ability had several advantages as a solution to the absence of the more flexible disk system used by Forth. It did not store the text of a Forth program, instead it compiled the code after editing and stored it in ready-to-run format. While this saved computer memory it also saved time in reading and writing programs from cassette tape. This tape-friendly and RAM-saving solution was unique to the Jupiter ACE Forth."

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: FORTH
« Reply #39 on: 2013.March.08. 11:37:28 »
Bruce, if you have some time/mood to bother with my madnesses, I would be happy to recieve some help :)

I'm working on a general Enteprise EXOS file analyzer/lister/disassembler, now it supports IS-FORTH too (type-1 EXOS header).


Now, only about the IS-FORTH part of the functionality ...

If you examine example for IS-FORTH listing output, you can see, that almost  every words are red.  This is because I use the "default" vlist to colourize words in that list as red.  That was also the reason I've asked the "save the output of VLIST" so I could include it in my program :) Later, user defined words are tracked too (you can see at words after : and the usage of those words are converted into HTML links).  Anyway, what is interesting: you can see number 0 or 3 as red, while eg 91 or 65 are blue (numeric constants used to be pushed onto the stack).  Now that's interesting for me: what's the purpose to have forth word 3 defined?  Afaik forth's default rule is to try to interpret word as a number and push on the stack if it's not in the vlist.  Was it a performance reason?  Eg, was it faster to implement common numbers like 0 or 3 as forth words, and leaving other numbers as-is?

Another questions are about the on-disk file format (the basics told by Zozo btw): before every 1024 buffer there are two bytes.  The first - it seems - is the "buffer sequence number" starting to be counted from 1.  Is it always true to have these sequences as 1, 2, 3, ...  etc (always from number 1,  always a strict sequence of numbers without gaps, repeats, etc), or there can be cases when it is not true?  Currently, my program requires this, that's why I am asking.  I would be also interested in the other byte before each buffer, according to Zozo it's the "type".  It seems to be always zero, and I have no idea what it's used for ...

Thanks a lot in advance!
« Last Edit: 2013.March.08. 13:45:31 by lgb »

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14775
  • Country: hu
    • http://enterprise.iko.hu/
Re: FORTH
« Reply #40 on: 2013.March.08. 11:53:03 »
Quote from: lgb
Another questions are about the on-disk file format (the basics told by Zozo btw): before every 1024 buffer there are two bytes.
You ask the type-1 EXOS module? I think the right name for this "on-tape" format.


Quote
 The first - it seems - is the "buffer sequence number" starting to be counted from
Later I found: the buffer number is on 16 bits! Valid from 1 to 32767.
The sequence is "random", last edited first, see this example:

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: FORTH
« Reply #41 on: 2013.March.08. 12:14:31 »
Quote from: Zozosoft
Later I found: the buffer number is on 16 bits! Valid from 1 to 32767.
The sequence is "random", last edited first, see this example:
Nice spot, I had some feeling before it can be the case somehow :) Btw, then in the EXOS header too, the byte after type type byte telling the number of buffers should be interpreted as word, eg the next byte then is the high-byte of the buffer counter? If it's not true, the format would be limited to have max of 255 buffers only ... However as every buffer is 1K, I guess it can be enough, as files with more buffers would be longer than 255K which is not so practical on an averge Enteprise system (unless IS-FORTH can load only a given buffer, and not the whole file, of course).

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14775
  • Country: hu
    • http://enterprise.iko.hu/
Re: FORTH
« Reply #42 on: 2013.March.08. 12:30:32 »
Quote from: lgb
If it's not true, the format would be limited to have max of 255 buffers only ... However as every buffer is 1K, I guess it can be enough, as files with more buffers would be longer than 255K which is not so practical on an averge Enteprise system
From the manual: at the start 8 buffers used. Can be added more with the CREATE-BUFFERS which is allocating full segment for more 16 buffers. It is can be used 16 times, then the total buffers is 8+16*16=264.
But now I tried and after 13 CREATEs it is frozen :oops:
« Last Edit: 2013.March.08. 12:35:57 by Zozosoft »

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: FORTH
« Reply #43 on: 2013.March.08. 16:29:51 »
Quote from: Zozosoft
From the manual: at the start 8 buffers used. Can be added more with the CREATE-BUFFERS which is allocating full segment for more 16 buffers. It is can be used 16 times, then the total buffers is 8+16*16=264.
Ok, but 264 cannot fit within a single byte, so the EXOS header should contain not only a byte for describing the number of forth buffers, if I am correct. That's why I thought the byte in the EXOS header after the type byte is not enough, and maybe the byte after it (which is usually zero) is the high byte of the word sized buffer counter for real. But I should create a file with more than 255 (and less than 264, if you are right?) buffers in it :) Honestly, I feel lost a bit with forth, especially with the storage methods. As far as I can understand the "difficulties" is because forth is old and run on systems without "real" OS (other than forth) having only block I/O without real filesystem etc ...

Offline BruceTanner

  • EP lover
  • *
  • Posts: 609
  • Country: gb
Re: FORTH
« Reply #44 on: 2013.March.08. 22:14:26 »
Quote from: lgb
Was it a performance reason?  Eg, was it faster to implement common numbers like 0 or 3 as forth words, and leaving other numbers as-is?

Yes, spot on - you have discovered a little secret! (Actually, not so secret - they are in the manual). Not a major performance increase but slightly quicker nonetheless. I think it's worth it for 0 and 1 which occur in programs very commonly; I'm not so convinced by 2 and 3!

Quote
Honestly, I feel lost a bit with forth, especially with the storage methods. As far as I can understand the "difficulties" is because forth is old and run on systems without "real" OS (other than forth) having only block I/O without real filesystem etc ...

Yes, FORTH can sit rather uncomfortably on other OSs, particularly with file I/O, and especially with tape storage! I was reading the word list of a modern FORTH the other day and it included a set of words very similar to C's fopen(), fread() etc.. Of course of the Enterprise you can use EXOS :)

Quote
From the manual: at the start 8 buffers used. Can be added more with the CREATE-BUFFERS which is allocating full segment for more 16 buffers. It is can be used 16 times, then the total buffers is 8+16*16=264.
But now I tried and after 13 CREATEs it is frozen 
Trust you to try that zozo!! ;-) :oops: I was not able to test that 30 years ago - that much memory was just a distant dream! This system of saving the buffers to a file was really a way of getting around the lack of disks which standard FORTH relies on (it is my invention, not standard). In my defence nobody would want to save 264k to a tape file :smt015 If you were writing a serious program on a real Enterprise with disks you would not use this method at all - you would use the random access .4th files to hold your FORTH blocks.

lgb I think you and zozo now have more information than my memory about the file format! In FORTH You can create whatever block numbers you like, eg 10 EDIT followed by 10000 EDIT so when they are written to the file there is no way they could be sequential. I expect the order is whatever the order in internal memory.

One point I have just noticed is that trailing spaces are not removed; thus even the smallest program takes up 1k :oops: and if you have 16 small program fragments each in their own block it will take up 16k :oops::oops::oops::oops::oops::oops::oops::oops::oops::oops::oops::oops::oops::oops::oops::oops: which is not good on tape systems that this is aimed at!