lbForth Internals

[Phi-Ho]

Greetings,

It is much appreciated if someone would kindly explain the internal workings of lbForth (any documentation available?).

How many stacks does lbForth have (data, return, control, floating...)? How are the dictionaries and word lists organized? For x86 and RISC-V, which registers have special purposes and need be saved/restored before/after interaction with external system function calls? Can lbForth be changed from indirect threaded to direct threaded by simply switching from itc.fth to dtc.fth as threading.fth What do the pushcomma ( push, ) and popcomma ( pop, ) do?

Many thanks for your help.

Best regards,

phiho

[larsbrinkhoff]

Sorry, there is no documentation beyond the short descriptions in the toplevel README.md file. It would be a good idea to add some more.

Number of stacks: two; data and return stacks. There is no floating-point words. There is no separate control stack; items are placed on the regular data stack.

Dictionary: Headers, code, and data is interleaved. A header consists of a name count, name string, and link to the previous definition.

Wordlist: A wordlist is a nameless word. The body has a link to the most recent definition in that wordlist.

Register allocation: Targets usually have registers called I, S, R, and W, for instruction pointer, data stack pointer, return stack pointer, and working register. For x86, those are eax, esp, esi, and edx. For RISC-V, they are x20, x21, x22, x23, and x24 for an additional T/temporary register. These all have to be preserved for any kind of context change. All other registers are free to use.

lbForth can not yet be reconfigured between different threading methods. As you found out from itc.fth and dtc.fth, I have taken steps in that direction, but this has not been finished.

All assembler words use a naming convention with a , suffix. push, and pop, assemble a push and pop instruction or sequence.

[Phi-Ho]

Hi,

Thank you for your reply.

Register allocation:

• Would you please elaborate on register I, the instruction pointer.
• What are TOS, NOS (and 3OS, 4OS ?) for lbForth?

push, and pop, : Is it true that they manipulate the hardware stack, not lbForth data stack. Are there any macros to manipulate the data stack?

Thanks, again.

phiho

[larsbrinkhoff]

I is the pointer to the current Forth instruction in a compiled word. It points to a addresses as appropriate for a direct or indirect threaded Forth. It's distinct from the machine PC, program counter, which points to machine instructions.

The x86 and RISC-V targets have no TOS or other stack cache registers.

push, and pop, refers to the Forth data stack. There may also be rpush, and rpop, for the Forth return stack.

[Phi-Ho]

Thank you very much for the clarification.

I hope you don't mind if I come back to the internals of lbForth later on.

Do you happen to have noted the minimum set of words needed to support the assembler and meta compiling process.

Regards,

phiho

[larsbrinkhoff]

The kernel is built on top of 16 primitive words:

\ Definitions:          dodoes exit
\ Control flow:         0branch
\ Literals:             (literal)
\ Memory access:        ! @ c! c@
\ Arithmetic/logic:     + nand
\ Return stack:         >r r>
\ I/O:                  emit open-file read-file close-file

[Phi-Ho]

Hi,

So, with these 16 primitive words, lbForth is almost ready to read in a file with the kernel and outer interpreter? You seem to be a big fan of refactoring. What words are needed before this could happen?

Regards,

phiho

[larsbrinkhoff]

The primitives are used to build up the kernel with an outer interpreter. This is in kernel.fth, which you should read to see how it's done. The kernel is enough to start interpreting code from files, of which core.fth is the most fundamental.

[Phi-Ho]

Hi,

Thanks a lot. I will read kernel.fth and will also try to locate "words" elsewhere. It's good to have this word available to see what is in the system when we are able to load other files for other needs. Is this the minimal system that need be meta compiled? Maybe, the users can load other files from wherever they choose ?

Regards,

phiho

[larsbrinkhoff]

Yes, the minimal metacompiled Forth image comprises mainly kernel.fth. Some other target-specific files are included in the process. See src/compile.fth for details.

[Phi-Ho]

Hi,

Please find appended below some information after I just did another meta compilation.

Is it possible to trim down the target words in exchange for a few word to read files and to do colon compilation?

BTW, would you please give me the invocation to see the words in each word list (?) in the dictionaries (?), something like:

only forth also meta also t-words

Is it true that 487 is the total number of words in lbForth when it starts up or there are still more words in some word lists, dictionaries that are not displayed by 'words'

Your help is greatly appreciated.

Regards,

phiho

echo "include targets/x86/build.fth" | ./4 > words.meta

Target size: 16000 Target used: 11636 Host unused: 10832 Target words: cold turnkey warm quit dummy-catch searched included remember-file +name current> >current search-file ?error ?open ?include pathname +string include-file file-input alloc-file file> +file file, source, 0source interpreting interpret ?stack (parsed) parsed latest0 image0 limit dp0 rp0 sp0 sigint backtrace restore-input save-input file-source file-refill /file source-id ?prompt refill ; ?csp !csp ?bad .latest csp ] [ interpret-xt ?exception interpreters catch previous also (previous) parse-name skip blank? <source source? source find-name search-context r@+ context included-files search-paths compiler-words forth /input-source source> 'prompt 'refill source# #source 'source input@ input >in (number) number ?literal literal ?undef undef (abort") abort (find) ?nt>xt traverse-wordlist immediate? nt= name= c<> upcase lowercase? sysdir r/w w/o r/o cr io-init noheader, >name >nfa header, name, offset, >xt #name dodef, docon, dovar, docol, stdin (does>) code, cells reveal link, latest! chain, current compile, ?code, does, does! code! >nextxt >body >code >lfa call, call! jump! rel! ", move, c, , align allot here dp latestxt latest cabs cmove < state perform type cr i aligned count bounds min unloop (+loop) 3dup 2r> rot 3drop temp cell+ cell noop and xor or invert um/mod cells cell+ 1- 1+ <> = - negate 2dup 2drop tuck over swap nip ?dup dup drop 0< 0<> 0= r@ execute branch c@ c! nand 2rdrop (loop) 2>r r> >r +! + @ ! (sliteral) (literal) 0branch dodoes dodef docon dovar docol exit rp! rp@ sp! sp@ close-file write-file2 write-file read-file open-file bye emit get-std-handle ok

After trimming words.meta to leave only the list of words in the target image:

PS F:\fun\lbforth\wsl.w4\TEST\meta> wc words.meta 1 236 3190 words.meta

So, there are 236 words in the target image after the meta compilation

Then:

echo words bye | ./4 > words.lb4

After trimming:

PS F:\fun\lbforth\wsl.w4> wc words.lb4 1 487 6438 words.lb4

There are 251 more words:

(additional 251 lb4 words, total 487 words) require include required included? create-file !+ ( [defined] [undefined] synonym state! next-name [find [alias imm def com ]alias c-o [then] [if] [else] >[then] name<> next-word must-refill forget #body see see' see-line .addr disassemble wid-xt? xt? xt?? .bt .' ?.offset .offset body? words .nt >end ?nt>end traverse-order execute-xt -rot id. cdump c? dump dump-line dump-cells dump-chars ?dot #digits ? .s search compare /string move cmove> blank -trailing holds +is action-of is defer@ defer! defer alias buffer: within unused u> .r u.r (.r) marker marker! vocs! voc! voc-link! latestxt! context! current! here! marker, vocs, voc-link, latestxt, context, current, voc-link @+ +to to value query roll pick hex false true expect span erase convert ,c" string, (c") string+ (?do) :noname 2r@ 0> 0<> .( (number) 4drop @str !str str >number u>number c>number 1/string base+ find word skip uncount accept (quit) rp\ terminal-input terminal-source ok terminal-refill key tib evaluate nr> n>r string-input string-source string-refill / /mod fm/mod sm/rem dabs dnegate m um d+- d+ u+d u< spaces #> sign #s # hold <# hld base/mod pad s>d max fill environment environment? env-query env-words search-wordlist j r+ >resolve@ leaves variable depth decimal char+ chars 2swap 2over 2! 2@ 2/ mod / postpone-number ." . u. (.) digit ?.- space bl constant header base /mod abs +- u/mod > lshift rshift bits/cell under 2 ?: ((abort")) (abort) ," s" ,s" s, parse" squote ( parse 1- resolving unresolved postpone-name finders postpone, create "create dodoes_code compile-only relink link hide ' char <resolve resolve >mark \ immediate :

(meta target image, 236 words) cold turnkey warm quit dummy-catch searched included remember-file +name current> >current search-file ?error ?open ?include pathname +string include-file file-input alloc-file file> +file file, source, 0source interpreting interpret ?stack (parsed) parsed latest0 image0 limit dp0 rp0 sp0 sigint backtrace restore-input save-input file-source file-refill /file source-id ?prompt refill ; ?csp !csp ?bad .latest csp ] [ interpret-xt ?exception interpreters catch previous also (previous) parse-name skip blank? <source source? source find-name search-context r@+ context included-files search-paths compiler-words forth /input-source source> 'prompt 'refill source# #source 'source input@ input >in (number) number ?literal literal ?undef undef (abort") abort (find) ?nt>xt traverse-wordlist immediate? nt= name= c<> upcase lowercase? sysdir r/w w/o r/o cr io-init noheader, >name >nfa header, name, offset, >xt #name dodef, docon, dovar, docol, stdin (does>) code, cells reveal link, latest! chain, current compile, ?code, does, does! code! >nextxt >body >code >lfa call, call! jump! rel! ", move, c, , align allot here dp latestxt latest cabs cmove < state perform type cr i aligned count bounds min unloop (+loop) 3dup 2r> rot 3drop temp cell+ cell noop and xor or invert um/mod cells cell+ 1- 1+ <> = - negate 2dup 2drop tuck over swap nip ?dup dup drop 0< 0<> 0= r@ execute branch c@ c! nand 2rdrop (loop) 2>r r> >r +! + @ ! (sliteral) (literal) 0branch dodoes dodef docon dovar docol exit rp! rp@ sp! sp@ close-file write-file read-file open-file bye emit get-std-handle ok

[larsbrinkhoff]

It might be possible to trim down the number of words. I'm not sure.

I think words only shows the words in one wordlist. If you include search.fth, vocs will tell you which wordlists there are.

The four hundred words you see are just the forth wordlist. However, when lbForth has just started there are not a lot of other wordlists. env-words, included-files, and search-paths are just for internal bookkeeping.

The additional words in a fully started Forth, over just the target words, are from core.fth etc.

There is only one dictionary. The dictionary is the data structure that stores words and data.

[larsbrinkhoff]

I recommend reading Brad Rodriguez' Moving Forth series to learn more about how Forth works internally. lbForth mostly implements the traditional Forth model.

https://www.bradrodriguez.com/papers/moving1.htm

[Phi-Ho]

Hi,

Thank you so much for your help. It is greatly appreciated.

I will explore more deeply.

Cheers,

phiho

On Tue, Nov 17, 2020 at 6:40 AM Lars Brinkhoff notifications@github.com wrote:

It might be possible to trim down the number of words. I'm not sure.

I think words only shows the words in one wordlist. If you include search.fth, vocs will tell you which wordlists there are.

The four hundred words you see are just the forth wordlist. However, when lbForth has just started there are not a lot of other wordlists. env-words, included-files, and search-paths are just for internal bookkeeping.

The additional words in a fully started Forth, over just the target words, are from core.fth etc.

There is only one dictionary. The dictionary is the data structure that stores words and data.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/larsbrinkhoff/lbForth/issues/89#issuecomment-728871954, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABDAWSXQSHR7QQY7EC2X4VDSQJOLHANCNFSM4TWBM2SA .

[Phi-Ho]

Hi,

I agree, that would be a great companion to 'Starting Forth' which started my Forth journey. After reading that series I came to 'Thinking Forth', I loved that for the emphasis on refactoring.

Cheers,

phiho

On Tue, Nov 17, 2020 at 6:46 AM Lars Brinkhoff notifications@github.com wrote:

I recommend reading Brad Rodriguez' Moving Forth series to learn more about how Forth works internally. lbForth mostly implements the traditional Forth model.

https://www.bradrodriguez.com/papers/moving1.htm

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/larsbrinkhoff/lbForth/issues/89#issuecomment-728874483, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABDAWSSN2J3PEWOXVAVSKPDSQJPALANCNFSM4TWBM2SA .

[Phi-Ho]

Hi,

I tried to include search.fth from load.fth:

parse-name core.fth included parse-name core-ext.fth included parse-name string.fth included parse-name tools.fth included parse-name file.fth included \ parse-name search.fth included include search.fth

then "words" is not defined:

$ ./i2 lbForth ok words Undefined: words

It is OK with "include src/search.fth"

Any ideas?

Regards,

phiho

[larsbrinkhoff]

Sorry, no idea. Both include search.fth and parse-name search.fth included works for me.

[Phi-Ho]

Hi,

Thank you for your clarification.

I am trying to manually include the files and words from 'compile.fth' (and its included files and words) to learn the working of metacompilation.

Is it OK to do this and the result would be the same the other way?

Regards,

phiho

On Wed, Nov 18, 2020 at 7:11 AM Lars Brinkhoff notifications@github.com wrote:

Sorry, no idea. Both include search.fth and parse-name search.fth included works for me.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/larsbrinkhoff/lbForth/issues/89#issuecomment-729638125, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABDAWSXMOBLEXJBBQNGGLVDSQO2X7ANCNFSM4TWBM2SA .

[larsbrinkhoff]

The metacompiler uses normal include files, so in theory it should be possible to repeat the process manually. If you copy what the code does exactly, it should work. But if you miss one tiny detail, it could fail.

The compiler uses different wordlists for host, metacompiling, and target words. It's very important at all times to know what the wordlist search order is. Words with the same name may exist in all three wordlists, and at times it can be confusing to remember which is which. For example, there is the host if, a metacompiling if, and the target if. The host words run in the host Forth and accesses the host image. The metacompiling words run in the host Forth but access the target image. The target words exist only in the target image.

[Phi-Ho]

Hi,

Thank you so much for the information.

It is much appreciated if you could share the process that you used to implement your cross and meta compilation, if you still remember after so many years.

Is it possible to port this to another simpler forth, like eForth?

Best regards,

phiho

On Wed, Nov 18, 2020 at 8:48 AM Lars Brinkhoff notifications@github.com wrote:

The metacompiler uses normal include files, so in theory it should be possible to repeat the process manually. If you copy what the code does exactly, it should work. But if you miss one tiny detail, it could fail.

The compiler uses different wordlists for host, metacompiling, and target words. It's very important at all times to know what the wordlist search order is. Words with the same name may exist in all three wordlists, and at times it can be confusing to remember which is which. For example, there is the host if, a metacompiling if, and the target if. The host words run in the host Forth and accesses the host image. The metacompiling words run in the host Forth but access the target image. The target words exist only in the target image.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/larsbrinkhoff/lbForth/issues/89#issuecomment-729687238, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABDAWSQALUISMPHR7F6RCEDSQPGBDANCNFSM4TWBM2SA .

[larsbrinkhoff]

Sorry, I don't remember much. I tried and failed two times to make a metacompiler, and succeeded on the third try.

It should be possible to port it. I'm sure I have used some words and techniques specific to lbForth, but the broad strokes should be applicable to any traditional Forth as long as it has wordlists.

[phillipeaton]

Hello,

I've been watching this thread. I've been working with the Camel Forth 6809 cross compiler and had to modify it in several areas to make it do what I wanted.

As far as I know, there are no documents that describe how cross compilation works, you have to analyse the code for yourself.

It will twist your brain inside out and at a bare minimum you need to have a strong understanding of vocabularies and/or word lists and associated words to understand cross compilation - it's challenging!

In addition to lbforth, you might want to have a look at the Camel Forth 6809 cross compiler, the code is nicely laid out, the supporting documentation is quite good and the author, Brad Rodriguez, has a number of excellent related publications available to read.

Warning, it took me a couple of years on-and-off to really work out what was going on with cross compilation.

Good luck! Phil

On Wed, 18 Nov 2020, 14:48 Lars Brinkhoff, notifications@github.com wrote:

The metacompiler uses normal include files, so in theory it should be possible to repeat the process manually. If you copy what the code does exactly, it should work. But if you miss one tiny detail, it could fail.

The compiler uses different wordlists for host, metacompiling, and target words. It's very important at all times to know what the wordlist search order is. Words with the same name may exist in all three wordlists, and at times it can be confusing to remember which is which. For example, there is the host if, a metacompiling if, and the target if. The host words run in the host Forth and accesses the host image. The metacompiling words run in the host Forth but access the target image. The target words exist only in the target image.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/larsbrinkhoff/lbForth/issues/89#issuecomment-729687238, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKRZ2LUFJ3U7QYBZX4LZECTSQPGBFANCNFSM4TWBM2SA .

[larsbrinkhoff]

Hey @phillipeaton, thanks for chiming in. I'd love to hear more about your Vectrex project.

I agree it's challenging. It's also took me a large chunk of time to understand the details of metacompilation. Part of it is using Forth, vocabularies, search order, and the built in interpreter to implement the metacompiler. It's easy to get confused. If you implement the metacompiler in another language it's always very clear what is the host language (not Forth) and target language (Forth).

I can also add that the search order is different depending on mode: interpreting or compiling. For example, when interpreting target code the search order would be "metainterpreting" words (for example, :) first, and then host words. When compiling target code, you search metacompiling words (e.g. if) first, then target words.

[Phi-Ho]

Hi,

Thank you very much for the info. Would you please give a link. Does it cross compile to x86_64 target. I do not have a 6809 machine. I need an image to run on my PC.

Regards,

phiho

On Wed, Nov 18, 2020 at 11:38 AM Phillip Eaton notifications@github.com wrote:

Hello,

I've been watching this thread. I've been working with the Camel Forth 6809 cross compiler and had to modify it in several areas to make it do what I wanted.

As far as I know, there are no documents that describe how cross compilation works, you have to analyse the code for yourself.

It will twist your brain inside out and at a bare minimum you need to have a strong understanding of vocabularies and/or word lists and associated words to understand cross compilation - it's challenging!

In addition to lbforth, you might want to have a look at the Camel Forth 6809 cross compiler, the code is nicely laid out, the supporting documentation is quite good and the author, Brad Rodriguez, has a number of excellent related publications available to read.

Warning, it took me a couple of years on-and-off to really work out what was going on with cross compilation.

Good luck! Phil

On Wed, 18 Nov 2020, 14:48 Lars Brinkhoff, notifications@github.com wrote:

The metacompiler uses normal include files, so in theory it should be possible to repeat the process manually. If you copy what the code does exactly, it should work. But if you miss one tiny detail, it could fail.

The compiler uses different wordlists for host, metacompiling, and target words. It's very important at all times to know what the wordlist search order is. Words with the same name may exist in all three wordlists, and at times it can be confusing to remember which is which. For example, there is the host if, a metacompiling if, and the target if. The host words run in the host Forth and accesses the host image. The metacompiling words run in the host Forth but access the target image. The target words exist only in the target image.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub < https://github.com/larsbrinkhoff/lbForth/issues/89#issuecomment-729687238 , or unsubscribe < https://github.com/notifications/unsubscribe-auth/AKRZ2LUFJ3U7QYBZX4LZECTSQPGBFANCNFSM4TWBM2SA

.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/larsbrinkhoff/lbForth/issues/89#issuecomment-729800586, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABDAWSQ6EALQS3X3RLDW4JLSQPZ7NANCNFSM4TWBM2SA .

[larsbrinkhoff]

I recall Forth Dimensions has some articles about metacompilation. Search this index for "meta", "compile", or "taret": http://www.forth.org/fd/index.pdf

Then find the articles here: http://www.forth.org/fd/contents.html

[Phi-Ho]

Hi,

Thanks a lot for the reference. I will browse through the list. I still think lbForth is the best live source for learning hand on.

I guess lbForth would be able to compile an image for another simple Forth fit in 5K binaries?

It is much appreciated if you would give a hint on the lbForth specific words that are needed for the assembler.

I will try to learn the assembler first then the DPANS optional Search-Order word set, together with lbForth would be enough to start with.

Cheers,

phiho

On Wed, Nov 18, 2020 at 3:28 PM Lars Brinkhoff notifications@github.com wrote:

I recall Forth Dimensions has some articles about metacompilation. Search this index for "meta", "compile", or "taret": http://www.forth.org/fd/index.pdf

Then find the articles here: http://www.forth.org/fd/contents.html

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/larsbrinkhoff/lbForth/issues/89#issuecomment-729934512, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABDAWSSPF4BEHYPXI4OG6YLSQQU5RANCNFSM4TWBM2SA .

[phillipeaton]

Hi, Thank you very much for the info. Would you please give a link. Does it cross compile to x86_64 target. I do not have a 6809 machine. I need an image to run on my PC. Regards, phiho

www.camelforth.com is the original. No it does not compile to x86_64, only to 6809. The reason I mentioned it that you could have a look at it, if you wanted to understand how cross-compilation works, in this instance to a different CPU, and compare/contrast with lbforth.

[phillipeaton]

Hey @phillipeaton, thanks for chiming in. I'd love to hear more about your Vectrex project.

It's on GitHub, it's my VecForth repository, have a look at the readme. I'm using it now for some hardware hacking on the Vectrex, when I get the time. I have some more ideas for it that will keep me going for a while yet! I still remember your PDP presentation in Zurich, I wish I had a video for that, the more I go back in time with my own computer archaeology, the more I see references to the PDPs! I'm currently looking at the mid-late 70s, with the introduction of the SWTPC 6800 & 6809, with their early ROM based xxBUG loaders, very interesting.

I agree it's challenging. It's also took me a large chunk of time to understand the details of metacompilation. Part of it is using Forth, vocabularies, search order, and the built in interpreter to implement the metacompiler. It's easy to get confused. If you implement the metacompiler in another language it's always very clear what is the host language (not Forth) and target language (Forth).

Yes, I wondered if it was better to build the cross compiler in a different language, so it was clearer what was going on, but once you've worked out how the vocabularies work, building it in Forth I think can be quite code efficient.

[larsbrinkhoff]

I guess lbForth would be able to compile an image for another simple Forth fit in 5K binaries?

Yes it should be. And larger too. The file lib/image.fth defines the data structures and access to a target image, and it should be easy to make it larger by adjusting t-size. But first you would need to rebuild lbForth with a larger dictionary space. To do that, edit targets/x86/cold.fth.

It is much appreciated if you would give a hint on the lbForth specific words that are needed for the assembler.

Sorry, I don't remember. Consider it an exercise for the reader! :-)

[larsbrinkhoff]

Thanks @phillipeaton. I'm watching your YouTube video series now, very enjoyable!

I still remember your PDP presentation in Zurich, I wish I had a video for that

Here is a slightly updated version from a few weeks ago. Recorded from an online conference.
https://www.youtube.com/watch?v=sbbwpui9AgE

Veering off topic here, but speaking of vectors and computer history. I have recently made a simulator for Marvin Minsky's 2500 computer. It was a custom TTL design with dual displays: one raster scan for text, and another random scan for turtle graphics. It's kind of a Vectrex-class machine.

[Phi-Ho]

Hello @phillipeaton https://github.com/phillipeaton,

I found Camel for x86 at http://www.camelforth.com/page.php?7 , this doesn't seem to have any documentation on metacompilation. It needs tasm and tlink

I also downloaded Chromium 2 metacompiler for F83. I am wondering if there is a way to read "chromium.scr", is it the source file for F83?

Again, thanks for your help.

Regards,

phiho

On Wed, Nov 18, 2020 at 7:13 PM Phillip Eaton notifications@github.com wrote:

Hi, Thank you very much for the info. Would you please give a link. Does it cross compile to x86_64 target. I do not have a 6809 machine. I need an image to run on my PC. Regards, phiho

www.camelforth.com is the original. No it does not compile to x86_64, only to 6809. The reason I mentioned it that you could have a look at it, if you wanted to understand how cross-compilation works, in this instance to a different CPU, and compare/contrast with lbforth.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/larsbrinkhoff/lbForth/issues/89#issuecomment-730038001, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABDAWSWBNDPEDMN7LG43W3TSQRPLVANCNFSM4TWBM2SA .

[phillipeaton]

Hello @phillipeaton https://github.com/phillipeaton,

I found Camel for x86 at http://www.camelforth.com/page.php?7 , this doesn't seem to have any documentation on metacompilation. It needs tasm and tlink

I also downloaded Chromium 2 metacompiler for F83. I am wondering if there is a way to read "chromium.scr", is it the source file for F83?

Again, thanks for your help.

Regards,

phiho

On Wed, Nov 18, 2020 at 7:13 PM Phillip Eaton notifications@github.com wrote:

Hi, Thank you very much for the info. Would you please give a link. Does it cross compile to x86_64 target. I do not have a 6809 machine. I need an image to run on my PC. Regards, phiho

www.camelforth.com is the original. No it does not compile to x86_64, only to 6809. The reason I mentioned it that you could have a look at it, if you wanted to understand how cross-compilation works, in this instance to a different CPU, and compare/contrast with lbforth.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/larsbrinkhoff/lbForth/issues/89#issuecomment-730038001, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABDAWSWBNDPEDMN7LG43W3TSQRPLVANCNFSM4TWBM2SA .

@Phi-Ho the scr file is a Forth block file format.

It can viewed in f83, but if you're only viewing, you can use the ASCII view of a hex editor set to 64 column mode. I use HxD for Windows.

Or, you can convert it to an ASCII text file and view it a standard text editor using a Unix command: dd if=foo.scr of=foo.fs cbs=64 conv=unblock

[phillipeaton]

@larsbrinkhoff thanks for your interest in my videos, I was surprised how many people have viewed them. I need to do some more, there has been lots of progress since I made them!

Another video I did at EuroForth 2018 might also be of interest. One day I'll also migrate it to YouTube and make some edits: https://wiki.forth-ev.de/doku.php/events:ef2018:vectrex

I'll check out the Minsky machine, I've not come across it before and it sounds interesting, thanks again for the link.

[larsbrinkhoff]

You will hardly find any information about the 2500 online, since very little was published about it. I have collected some notes here: https://github.com/PDP-10/its/issues/1962

Your videos have spurred my interest in getting a Vectrex. Possibly for use as an emulator of 70s vector displays like the 2500 or Imlac (another rarely heard of machine). How fast is the Vectrex at drawing lines and repositioning the beam? (Assuming reasonable values for all parameters involved.)

[Phi-Ho]

Hello @phillipeaton,

Thank you for your help. I got them all.

I also just found an eForth for PC in 32-bit mode, by Rick VanNorman:

http://www.forth.org/library/eforth_SOC/eforth_SOC_source/eForth1 /eforth32.zip

This comes with a meta compiler, many tools including an editor. It is modular , the kernel and meta compiler are well documented. I need a DOS box to run it.

Regards,

phiho

On Thu, Nov 19, 2020 at 5:20 AM Phillip Eaton notifications@github.com wrote:

Hello @phillipeaton https://github.com/phillipeaton https://github.com/phillipeaton,

I found Camel for x86 at http://www.camelforth.com/page.php?7 , this doesn't seem to have any documentation on metacompilation. It needs tasm and tlink

I also downloaded Chromium 2 metacompiler for F83. I am wondering if there is a way to read "chromium.scr", is it the source file for F83?

Again, thanks for your help.

Regards,

phiho

On Wed, Nov 18, 2020 at 7:13 PM Phillip Eaton notifications@github.com wrote:

Hi, Thank you very much for the info. Would you please give a link. Does it cross compile to x86_64 target. I do not have a 6809 machine. I need an image to run on my PC. Regards, phiho

www.camelforth.com is the original. No it does not compile to x86_64, only to 6809. The reason I mentioned it that you could have a look at it, if you wanted to understand how cross-compilation works, in this instance to a different CPU, and compare/contrast with lbforth.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub

89 (comment)

https://github.com/larsbrinkhoff/lbForth/issues/89#issuecomment-730038001 , or unsubscribe

https://github.com/notifications/unsubscribe-auth/ABDAWSWBNDPEDMN7LG43W3TSQRPLVANCNFSM4TWBM2SA .

@Phi-Ho https://github.com/Phi-Ho the scr file is a Forth block file format.

It can viewed in f83, but if you're only viewing, you can use the ASCII view of a hex editor set to 64 column mode. I use HxD for Windows.

Or, you can convert it to an ASCII text file and view it a standard text editor using a Unix command: dd if=foo.scr of=foo.fs cbs=64 conv=unblock

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/larsbrinkhoff/lbForth/issues/89#issuecomment-730274596, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABDAWST42TRKEXC6UKTYBL3SQTWOXANCNFSM4TWBM2SA .

[phillipeaton]

You will hardly find any information about the 2500 online, since very little was published about it. I have collected some notes here: PDP-10/its#1962

Your videos have spurred my interest in getting a Vectrex. Possibly for use as an emulator of 70s vector displays like the 2500 or Imlac (another rarely heard of machine). How fast is the Vectrex at drawing lines and repositioning the beam? (Assuming reasonable values for all parameters involved.)

@larsbrinkhoff Almost certainly yes. There is a development cartridge for the Vectrex containing an ARM CPU that can receive vector data received via a USB serial cable and display them on the Vectrex monitor. It can receive at 921,600 Baud, which is a lot of Vectors. The main use case so far has been to play classic 80's vector arcade games using a modified version of MAME. It's an amazing piece of hardware. Check out these videos:

https://youtu.be/YUh07TRDlls https://youtu.be/eH0U52qbvcg

Let me know if you want to take it further, there are some special circumstances to consider.

[larsbrinkhoff]

@phillipeaton, the VecFever seems perfect for my purposes. Yes, I would like to take it further! I'll see about getting a Vectrex.

[Phi-Ho]

Hello @Lars Brinkhoff

Thank you so much for the guidance. It is a worthwhile exercise.

Would you please advise how one would get started to learn lbForth on ARM and RISC-V platform.

Best regards,

phiho

On Thu, Nov 19, 2020 at 1:30 AM Lars Brinkhoff notifications@github.com wrote:

I guess lbForth would be able to compile an image for another simple Forth fit in 5K binaries?

Yes it should be. And larger too. The file lib/image.fth defines the data structures and access to a target image, and it should be easy to make it larger by adjusting t-size. But first you would need to rebuild lbForth with a larger dictionary space. To do that, edit targets/x86/cold.fth.

It is much appreciated if you would give a hint on the lbForth specific words that are needed for the assembler.

Sorry, I don't remember. Consider it an exercise for the reader! :-)

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/larsbrinkhoff/lbForth/issues/89#issuecomment-730160357, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABDAWSU3DCOBOCLVY5OQKPDSQS3R5ANCNFSM4TWBM2SA .

[larsbrinkhoff]

I have developed and tested the ARM and RISC-V targets using emulators.

For ARM I used the stock QEMU "qemu-user" emulator.
For RISC-V I used http://github.com/riscv/riscv-qemu

The Travis CI scripts can be a quide for how to install and run the emulators:
test/install-deps.sh
targets/arm/run.sh
targets/riscv/run.sh

[Phi-Ho]

Hi,

For RISC-V I used http://github.com/riscv/riscv-qemu https://github.com/riscv/riscv-qemu

Thank you for the link, but there is not much to download there:

The RISC-V QEMU Port is UpstreamThe RISC-V QEMU port is developed in the upstream QEMU repository https://git.qemu.org/?p=qemu.git;a=summary. You may be more interested in the official releases https://www.qemu.org/download/.

Not much for download at the upstream QEMU repository https://git.qemu.org/?p=qemu.git;a=summary

At official releases, https://www.qemu.org/download/, what should I get for RISC-V QEMU port?

The Travis CI scripts can be a guide for how to install and run the emulators: Are these scripts in the RISC-V QEMU port?

Thank you for your help.

Regards,

phiho

On Sat, Nov 21, 2020 at 8:31 AM Lars Brinkhoff notifications@github.com wrote:

I have developed and tested the ARM and RISC-V targets using emulators.

For ARM I used the stock QEMU "qemu-user" emulator. For RISC-V I used http://github.com/riscv/riscv-qemu https://github.com/riscv/riscv-qemu

The Travis CI scripts can be a quide for how to install and run the emulators: test/install-deps.sh targets/arm/run.sh targets/riscv/run.sh

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/larsbrinkhoff/lbForth/issues/89#issuecomment-731579980, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABDAWSVKWOAFYEXZEVC4GCLSQ66J7ANCNFSM4TWBM2SA .

[Phi-Ho]

Hi,

The Travis CI scripts can be a guide for how to install and run the emulators: Are these scripts in the RISC-V QEMU port?

Sorry, the name Travis CI threw me off. These scripts are actually in lbForth.

Regards,

phiho

On Sat, Nov 21, 2020 at 9:03 AM ph h hohoangphi@gmail.com wrote:

Hi,

For RISC-V I used http://github.com/riscv/riscv-qemu https://github.com/riscv/riscv-qemu

Thank you for the link, but there is not much to download there:

The RISC-V QEMU Port is UpstreamThe RISC-V QEMU port is developed in the upstream QEMU repository https://git.qemu.org/?p=qemu.git;a=summary. You may be more interested in the official releases https://www.qemu.org/download/.

Not much for download at the upstream QEMU repository https://git.qemu.org/?p=qemu.git;a=summary

At official releases, https://www.qemu.org/download/, what should I get for RISC-V QEMU port?

The Travis CI scripts can be a guide for how to install and run the emulators: Are these scripts in the RISC-V QEMU port?

Thank you for your help.

Regards,

phiho

On Sat, Nov 21, 2020 at 8:31 AM Lars Brinkhoff notifications@github.com wrote:

I have developed and tested the ARM and RISC-V targets using emulators.

For ARM I used the stock QEMU "qemu-user" emulator. For RISC-V I used http://github.com/riscv/riscv-qemu https://github.com/riscv/riscv-qemu

The Travis CI scripts can be a quide for how to install and run the emulators: test/install-deps.sh targets/arm/run.sh targets/riscv/run.sh

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/larsbrinkhoff/lbForth/issues/89#issuecomment-731579980, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABDAWSVKWOAFYEXZEVC4GCLSQ66J7ANCNFSM4TWBM2SA .

[larsbrinkhoff]

It looks like stock QEMU now supports RISC-V, so my scripts are now outdated.

[Phi-Ho]

Hi @ larsbrinkhoff,

lbForth is very cool. It is invaluable for learners like me

It would be great if lbForth can be made available in a self-sufficient container with all dependencies installed.

Thank you for your consideration.

Regards,

phiho

On Sun, Nov 22, 2020 at 3:34 AM Lars Brinkhoff notifications@github.com wrote:

It looks like stock QEMU now supports RISC-V, so my scripts are now outdated.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/larsbrinkhoff/lbForth/issues/89#issuecomment-731715700, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABDAWSQHHRV4Y6RJSVHNJO3SRDEJJANCNFSM4TWBM2SA .

[larsbrinkhoff]

A Docker image or similar would be a good idea, but I'm not actively developing lbForth at this time.