newbie trying to build F83

[Roger Hanscom]

I'm trying to build a copy of F83 from the master file on github, but I'm lost. The command "F83 META68.BLK" doesn't work. I can "OPEN" that file and manually cut and paste the FORTH from screen #1. That gets me dialog as described in the github .MD, but only to a point:

ONLY FORTH ALSO DEFINITIONS ok
DOS ' NOOP IS HEADER ok
FENCE OFF FORGET OUT ok
WARNING OFF ok
: NLOAD CR .S (LOAD) ; ' NLOAD IS LOAD ok
3 21 THRU ( The Meta Compiler )
3
4
...
20
21 ok
ONLY FORTH DEFINITIONS ALSO ok
CR .( Meta Compiler Loaded )
Meta Compiler Loaded ok
FROM KERNEL68.BLK 1 LOAD
1
2
...
91
92
Unresolved references:

Statistics:
Last Host Address: 9596
First Target Code Address: AD00
Last Target Code Address: DC14


Now return to CP/M and type:
KERNEL EXTEND68.BLK <CR>
OK <CR> ok
bye
150 Pages
C>dir
C: F83 68K : F83 BIN : META68 BLK : BASIC BLK : CLOCK BLK
C: CPU68000 BLK : EXPAND68 BLK : EXTEND68 BLK : HUFFMAN BLK : KERNEL68 BLK
C: UTILITY BLK
C>kernel extend68.blk
KERNEL?
C>

There is no "kernel" in the directory! So, what am I doing wrong? The part in the instructions that leaves me scratching my head is "( your input )". What input? Sorry, but as I said, I'm a FORTH newbie, but I'd really like to build an F83 version that I can run on my 68000 SBC that will load somewhere above $7B00. The version that I'm using (above) loads at $500 (on a different SBC) and that would collide with the 68K CP/M kernel on my target SBC.

I'd greatly appreciate some pointers!

Roger

[dxforth]

On 22/02/2023 12:39 pm, Roger Hanscom wrote:
> C>dir
> C: F83 68K : F83 BIN : META68 BLK : BASIC BLK : CLOCK BLK
> C: CPU68000 BLK : EXPAND68 BLK : EXTEND68 BLK : HUFFMAN BLK : KERNEL68 BLK
> C: UTILITY BLK
> C>kernel extend68.blk
> KERNEL?
> C>
>
> There is no "kernel" in the directory! So, what am I doing wrong?

Did you try compiling from drive A ? That's where it's coded to save the kernel.

\ Target System Setup 19Apr84map
ONLY FORTH META ALSO FORTH
HEX A800 ' TARGET-ORIGIN >BODY ! IN-META DECIMAL
2 92 THRU ( System Source Screens ) HEX
CR .( Unresolved references: ) CR .UNRESOLVED
CR .( Statistics: ) CR .( Last Host Address: )
[FORTH] HERE U. CR .( First Target Code Address: )
META 500 THERE U. CR .( Last Target Code Address: )
META HERE-T THERE U. CR CR
DOS HERE-T 4E8 !-T
META 500 1C - THERE HERE-T 100 +
ONLY FORTH ALSO DOS SAVE A:KERNEL.68K FORTH
CR .( Now return to CP/M and type: )
CR .( KERNEL EXTEND68.BLK <CR> ) CR .( OK <CR> ) DECIMAL

[Roger Hanscom]

On Tuesday, February 21, 2023 at 6:29:21 PM UTC-8, dxforth wrote:

> Did you try compiling from drive A ? That's where it's coded to save the kernel.

......

> ONLY FORTH ALSO DOS SAVE A:KERNEL.68K FORTH

......

No, I haven't tried that. Running out of room on A: . I might have to copy a bunch of files around to be able to use A: .

Would it be easier to edit the code? Don't know how to do that.

Also, would you tell me how to "execute" a .BLK file once it is opened?

Roger

[Roger Hanscom]

On Wednesday, February 22, 2023 at 9:37:40 AM UTC-8, Roger Hanscom wrote:
> On Tuesday, February 21, 2023 at 6:29:21 PM UTC-8, dxforth wrote:
>
> > Did you try compiling from drive A ? That's where it's coded to save the kernel.
> ......
> > ONLY FORTH ALSO DOS SAVE A:KERNEL.68K FORTH
> ......

I looked in the A: drive and found a kernel.68k. So, as an alternative approach, I copied it to the C: drive, and tried to run it:

C>a:pip kernel.68k=a:kernel.68k

C>dir
C: BILL83 68K : F83 BIN : META68 BLK : BASIC BLK : CLOCK BLK

C: CPU68000 BLK : EXPAND68 BLK : EXTEND68 BLK : HUFFMAN BLK : KERNEL68 BLK

C: UTILITY BLK : KERNEL 68K
C>kernel extend68.blk
Insufficient memory or bad file header
C>

Now what??

Roger

[Roger Hanscom]

On Wednesday, February 22, 2023 at 9:53:47 AM UTC-8, Roger Hanscom wrote:
....
> I looked in the A: drive and found a kernel.68k. So, as an alternative approach, I copied it to the C: drive, and tried to run it:

.....

> Insufficient memory or bad file header
> C>

Through some DDT68000 trickery, I got the KERNEL.68K to run, but I don't know how to pass the EXTEND68.BLK argument to it. There are a number of words that I'm familiar with that might help, but they are unknown. Some of the few base level operations that I'm familiar with do work:

ok
open extend68.blk OPEN ?
OPEN EXTEND68.BLK OPEN ?
words WORDS ?
WORDS WORDS ?
ok
1 triad TRIAD ?
1 TRIAD TRIAD ?
vlist VLIST ?
VLIST VLIST ?
1 2 + . 3 ok
: XYZ CR 11 0 DO CR I . LOOP ; ok
XYZ

0
1
2
3
4
5
6
7
8
9
10 ok

Roger

[David Schultz]

On 2/21/23 7:39 PM, Roger Hanscom wrote:

> There is no "kernel" in the directory! So, what am I doing wrong? The part in the instructions that leaves me scratching my head is "( your input )". What input? Sorry, but as I said, I'm a FORTH newbie, but I'd really like to build an F83 version that I can run on my 68000 SBC that will load somewhere above $7B00. The version that I'm using (above) loads at $500 (on a different SBC) and that would collide with the 68K CP/M kernel on my target SBC.

Getting it to work at a different address is tricky.

This version uses 16 bit addresses. The straight forward way of doing
that results in the address being sign extended when moved to an address
register. This gives a memory map of 32KB at the bottom of the address
space and 32KB at the top. ($8000 is actually $FF8000)

Looking at KERNEL68.BLK I see they went a different (slower) route.
Addresses get loaded (as 16 bits) into D7 and then there is a 32 bit
move from D7 to the address register. So the upper sixteen bits of D7
are critical to determining where it runs. If that is zero then you have
to be within the first 64KB of memory.

The cold entry point includes:
LONG D7 CLR WORD

Change that for whichever 64K chunk of memory you want to use.

--
http://davesrocketworks.com
David Schultz

[dxforth]

On 23/02/2023 7:12 am, David Schultz wrote:
> On 2/21/23 7:39 PM, Roger Hanscom wrote:
>
>> There is no "kernel" in the directory!  So, what am I doing wrong?  The part in the instructions that leaves me scratching my head is "( your input )".  What input?  Sorry, but as I said, I'm a FORTH newbie, but I'd really like to build an F83 version that I can run on my 68000 SBC that will load somewhere above $7B00.  The version that I'm using (above) loads at $500 (on a different SBC) and that would collide with the 68K CP/M kernel on my target SBC.
>
> Getting it to work at a different address is tricky.

Vaguely recalled reading something about that. Chased it down:

'Relocatable F83 for the 68000' R.Eager, Forth Dimensions V9N6

[Roger Hanscom]

On Wednesday, February 22, 2023 at 6:31:59 PM UTC-8, dxforth wrote:

> Vaguely recalled reading something about that. Chased it down:
>
> 'Relocatable F83 for the 68000' R.Eager, Forth Dimensions V9N6

Thanks! I grabbed the .pdf, and will be studying it.

Roger

[David Schultz]

On 2/22/23 11:37 AM, Roger Hanscom wrote:
> Would it be easier to edit the code? Don't know how to do that.

F83 has a built in editor. Clearly described in places like:
http://forth.org/OffeteStore/1003_InsideF83.pdf

[Paul Rubin]

David Schultz <david....@earthlink.net> writes:
> F83 has a built in editor. Clearly described in places like:
> http://forth.org/OffeteStore/1003_InsideF83.pdf

There is also a great book called Inside F83, by C. H. Ting, in case OP
hasn't already seen it. I think there is a copy on forth.org somewhere.

For some reason I thought that F83 only ran on Z80 systems, but I see
mention here of a 68K version. Were there other ports as well? Is it
interesting to think about porting it to modern MCU's?

[dxforth]

On 24/02/2023 7:54 am, Paul Rubin wrote:
> David Schultz <david....@earthlink.net> writes:
>> F83 has a built in editor. Clearly described in places like:
>> http://forth.org/OffeteStore/1003_InsideF83.pdf
>
> There is also a great book called Inside F83, by C. H. Ting, in case OP
> hasn't already seen it. I think there is a copy on forth.org somewhere.
>
> For some reason I thought that F83 only ran on Z80 systems, but I see
> mention here of a 68K version. Were there other ports as well?

Original authors Laxen & Perry produced versions for CP/M-80, CP/M-68K
and CP/M-86/MS-DOS. Others then ported it to other CPU's and OS.

> Is it
> interesting to think about porting it to modern MCU's?

Folks loved F83 because it was everything Fig-Forth was not. However
it too succumbed to things like F-PC - which in turn succumbed to ANS.

[Paul Rubin]

dxforth <dxf...@gmail.com> writes:
> Folks loved F83 because it was everything Fig-Forth was not. However
> it too succumbed to things like F-PC - which in turn succumbed to ANS.

I thought that F83 had a bunch of utilities and features (editor,
multi-tasking, etc.) and F-PC had even more, while ANS is purely a
language standard. I use gforth which is ANS, but runs mainly on big
machines. And while it is a very complete language implementation, it
doesn't have stuff like multitasking. That's why I was wondering about
porting F83 to modern MCU's.

I think what I really want though is something like Chipforth, if it
works the way I think it does based on mentions of it here on CLF. I
sometimes think of trying to write such a thing, but it is likely a
rabbit hole of not much benefit.

[David Schultz]

On 2/23/23 9:02 PM, Paul Rubin wrote:
> I thought that F83 had a bunch of utilities and features (editor,
> multi-tasking, etc.) and F-PC had even more, while ANS is purely a
> language standard. I use gforth which is ANS, but runs mainly on big
> machines. And while it is a very complete language implementation, it
> doesn't have stuff like multitasking. That's why I was wondering about
> porting F83 to modern MCU's.
>

It took me a while to wrap my brain around mult-tasking using old issues
of Forth Dimensions but once I did, I added it to my eForth
implementations. (MSP430 and ARM)

[Paul Rubin]

David Schultz <david....@earthlink.net> writes:
> It took me a while to wrap my brain around mult-tasking using old
> issues of Forth Dimensions but once I did, I added it to my eForth
> implementations. (MSP430 and ARM)

Cool. Brad Rodriguez has a few decent articles about it, but some
details are missing. Also, eForth has a minimal implementation, but
again I think stuff is missing. If you have any Forth Dimensions
articles to recommend, that would be nice.

[Anton Ertl]

Paul Rubin <no.e...@nospam.invalid> writes:
>I use gforth which is ANS, but runs mainly on big
>machines. And while it is a very complete language implementation, it
>doesn't have stuff like multitasking.

https://gforth.org/manual/Multitasker.html

Note that this documents the development version.

- 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: https://forth-standard.org/
EuroForth 2022: https://euro.theforth.net

[dxforth]

Take your pick

05 2 A Simple Multi-Tasker - Duncan R.
05 2 Simple Forth Multi-Tasking Environment - Petri M.
05 4 Techniques Tutorial: Multi-Tasking 1 - Laxen H.
05 5 Techniques Tutorial: Multi-Tasking 2 - Laxen H.
07 4 Extending The Multi-Tasker: Mailboxes - Dobbins R.
09 6 Multi-Tasking Modem Package - Teza J.
11 5 Multitasking And Controlling Regular Events - Hendtlass T.
18 5 Can POSIX Threads Be Used As A Standard Forth Multi-Tasker? - Carter E.
20 4 How and Why to Use Multitasking - Sergeant F.

What do you feel was missing from the stuff you read? Implementations can
be consulted if explanations are unclear. The only trickery I noted in the
F83 tasker was the use of INT or RST instructions to effect task switch.
AFAIK that's not necessary and a loop would work equally well.

[none albert]

In article <2023Feb2...@mips.complang.tuwien.ac.at>,

Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>Paul Rubin <no.e...@nospam.invalid> writes:
>>I use gforth which is ANS, but runs mainly on big
>>machines. And while it is a very complete language implementation, it
>>doesn't have stuff like multitasking.
>
>https://gforth.org/manual/Multitasker.html
>
>Note that this documents the development version.

The FIG tradition of easily modifiable Forth's is not dead!

All versions of ciforth have a multi tasker since time immemorial
after WANT THREAD-COT .
The pre-emptive multi-tasker was demonstrated with a parallel
prime counting program.
The cooperative multi tasking runs portably in all the versions
of ciforth including the 16 bit version. All task have separate
i/o thanks to user variables, and even a private dictionary
space to compile definitions known only with the thread.
The 16 bit version mina.com (MSDOS, windows with Dos Protected
Mode Interface) has 40 Kbyte to spare so I guess it is
possible to do something useful with it.

ciforth is in the FIG tradition of small Forth's, easily extensible.
Also it comes with an assembler source, that can be changed easily
by changing EQU's.

; -------------------
; MEMORY LAYOUT.
; Normally this is specified at the m4 configuration level.
; For a configured system these values can be changed at this single place.
NBUF EQU 8 ; No. of buffers, or screens
KBBUF EQU 1024 ; Data bytes per disk buffer
US EQU 0x40*CW ; User variable space, eats into next data stack, if any.
EM EQU 0x10000 ; Where the memory ends w.r.t. ORIG. 1)
EMP EQU (EM-1)/0x1000+1 ; Number of pages.
TAS EQU 0x0100 ;Size of unitialised area per task.
STACKSIZE EQU TAS/4 ;For both stacks.
TIBSIZE EQU TAS/4 ;TIB size.
;
; -------------------

Examples of changes :
EM can be changed to 0x8000 for a 32 kbyte system.
NBUF can be diminished to 4 (not advisable to go lower than that).

; This version can be assembled on a Linux system in behalf of a
; MS-DOS version by
; nasm -fbin ciforth.asm -o ciforth.com

And of course it builds on a true MSDOS system or a DOSBOX.
The computer factory (running on linux) can generate a version for
other assemblers, e.g. masm if wanted.

Groetjes Albert





>
>- anton
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

[dxforth]

On 24/02/2023 9:06 pm, dxforth wrote:
>
> The only trickery I noted in the
> F83 tasker was the use of INT or RST instructions to effect task switch.

I forgot. F83 didn't have classic USER variables - it had a USER vocabulary.
Just to be different :)

[Zbig]

> Folks loved F83 because it was everything Fig-Forth was not.

What you mean, in particular?

BTW I acquired a taste for that „outdated” fig-Forth because of its
simplicity. :) It may even be perhaps slowest of them all, but nowadays
(contrary to the 70s/80s) it's not that serious disadvantage on modern
CPUs, unless one „really really” needs the speed (like 3D-graphics?).

[Andy Valencia]

dxforth <dxf...@gmail.com> writes:
> If you have any Forth Dimensions
> > articles to recommend, that would be nice.

> Take your pick
> ...

FWIW, I added a source viewer for my ForthOS (it uses blocks with shadows
for all source):

https://vsta.org/cgi-bin/fview.py?path=/kernel/tasking.txt

Source plus comments on the shadow might be of interest.

Andy Valencia
Home page: https://www.vsta.org/andy/
To contact me: https://www.vsta.org/contact/andy.html

[Paul Rubin]

an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> https://gforth.org/manual/Multitasker.html
> Note that this documents the development version.

Oh, neat! But the doc doesn't seem to describe the cooperative
multitasker. It mentions the possibility of multitasking being
standardized. That is interesting too. Is it actually likely, in the
sense of progress being made? Are there any proposed standardization
specs around?

[Paul Rubin]

dxforth <dxf...@gmail.com> writes:
> Take your pick ... What do you feel was missing from the stuff you

> read? Implementations can be consulted if explanations are unclear.

Thanks, I will look at those. I previously mostly looked at Brad
Rodriguez's article and the eForth multitasker that was on Bill Muench's
old site. IIRC, Brad Rodriguez's article described single slot
mailboxes for task-to-task communication but said some implementations
were fancier. I don't remember if the eForth one had mailboxes at all.
So I wanted to know what facilities the fancier implementations offered,
and also a bit about usage techniques.

E.g. does a task PAUSE if the mailbox it wants to write to is already
full? Were there frequent problems with deadlock during development
because of this?

The new gforth multitasking docs look helpful and are more complete than
other stuff I've seen.

[Paul Rubin]

Paul Rubin <no.e...@nospam.invalid> writes:
> Oh, neat! But the doc doesn't seem to describe the cooperative
> multitasker.

On reading the doc, it looks like the same words can control both
multitaskers, though some of them are only important for the preemptive
case.

The "Special User Variables" section has the confusing paragraph

Define a per-thread deferred word wait for all spawned tasks to
complete wait for a worker to become free, and spawn xt there wait
for a worker to become free, and spawn xt there, with one argument
wait for a worker to become free, and spawn xt there, with two
arguments

It looks there are some word headings missing from the middle of that by
accident. They seem to be for dealing with worker thread pools. Should
those really be primitives?

Are there parameters for the size of the event queue per task? What
happens if a queue fills up? Is the event queue system as described in
the doc part of a standardization proposal?

I find the event queue doc a bit confusing. Does event: let you give
arbitrary Forth code that is supposed to be executed in the receiving
task, i.e. something like an xt gets passed through the queue? If yes,
the doc should say so, and say how to pass an xt. Or is the definition
just supposed to be the events like elit, and friends? Do you use elit,
if you want to send an xt?

I expect it is the latter, and a typical event sequence would pass some
args and an event type. The receiving task would CASE on the event type
where each branch of the CASE would use the args for that type of event.
Does that sound right? But in that case why does EVENT: exist, instead
of using an ordinary colon definition? Why is there a maximum of 256
named events?

And if it is the former, how does one send a named event to another
task?

There are various defining words like event: which take names and create
objects with those names. Do they have factors that let you create the
objects anonymously?

It sounds like the event queue stuff might be gforth-specific, rather
than proposed or contemplated for standardization. That's fine, but it
would be nice if the doc identified words whose semantics might become
part of the standard.

I'm still interested in using this stuff on small MCU's (16KB program
flash, 1KB or 2KB ram), so I'm trying to figure out the resource
requirements of this multitasking scheme.

[dxforth]

It's a rare person that turns down 'more' especially when it's free.
Both F83 and Fig-Forth were ITC. Their speeds would have been comparable.

[dxforth]

On 25/02/2023 6:39 am, Paul Rubin wrote:
> dxforth <dxf...@gmail.com> writes:
>> Take your pick ... What do you feel was missing from the stuff you
>> read? Implementations can be consulted if explanations are unclear.
>
> Thanks, I will look at those. I previously mostly looked at Brad
> Rodriguez's article and the eForth multitasker that was on Bill Muench's
> old site. IIRC, Brad Rodriguez's article described single slot
> mailboxes for task-to-task communication but said some implementations
> were fancier. I don't remember if the eForth one had mailboxes at all.
> So I wanted to know what facilities the fancier implementations offered,
> and also a bit about usage techniques.
>
> E.g. does a task PAUSE if the mailbox it wants to write to is already
> full? Were there frequent problems with deadlock during development
> because of this?

Presumably not otherwise folks wouldn't have used it. That the topic
rarely comes up suggests users were able to organize what they needed.
I'm not aware of any forth multitaskers that come with mailboxes
included. Someone with experience using multitaskers would be better
able to your answer questions (my interest stopped after I researched
and implemented them). I do recommend checking out the manual that
comes with the free version of SwiftX as it has a lengthy section on
multitaskers.

[Anton Ertl]

dxforth <dxf...@gmail.com> writes:
>Both F83 and Fig-Forth were ITC. Their speeds would have been comparable.

IIRC we looked at the NEXT for the 8086 versions some time ago.
fig-Forth's 8086 NEXT used 8080-based register assignments, whereas
F83's NEXT made much better use of the 8086 instruction set.

[Anton Ertl]

Paul Rubin <no.e...@nospam.invalid> writes:
[feedback on the Gforth multi-tasking docs]

Thanks for the feedback. I have forwarded it to Bernd Paysan, who
hopefully will improve the documentation.

[dxforth]

On 25/02/2023 10:11 am, Anton Ertl wrote:
> dxforth <dxf...@gmail.com> writes:
>> Both F83 and Fig-Forth were ITC. Their speeds would have been comparable.
>
> IIRC we looked at the NEXT for the 8086 versions some time ago.
> fig-Forth's 8086 NEXT used 8080-based register assignments, whereas
> F83's NEXT made much better use of the 8086 instruction set.

True. ISTR Zbig was going to fix that :)

[Zbig]

> It's a rare person that turns down 'more' especially when it's free.
> Both F83 and Fig-Forth were ITC. Their speeds would have been comparable.

Oh, not really — example: FPC. I recall how overwhelming it seemed I tried
it first time…
It all depends on what one needs.

[none albert]

In article <878rgmu...@nightsong.com>,

The most sensible approach is :
A defining word that creates a data structure e.g. THREAD-something
It takes a size upon creation.

<size> THREAD-something my-music

Then you may run an xt in this space
' score my-music

If score exits, my-music becomes free again.
There can be communication using semaphores to signal score to terminate.

This is almost identical to MPE-Forth I think, but it is parallel
development and the names are not standardised of course.

Groetjes Albert

[none albert]

In article <87zg92s...@nightsong.com>,

It seems a monumental design error to conflate threads and queues.
They are separate issues and can be designed separately.

In the manx program I have separate queues for each instrument.
I have separate tasks for each part of a score, conceptually,
and a higher priority task that inspect instruments queues in real time.
Actually I handle the score sequentially, generating events for the
first bar of the first part, then the first part of the second part,
and so on , then continuing with the second bar of the first part.

I have a cooperative multitasking in ciforth but I don't use it.

On the subject of multi-tasking on a flash based CPU.
There are c-based soc's intended for smart devices.
2 K flash and 16 K ram is more Forth-like.
They are ram starved. A task will have separate tib, data stack
and return stack. You probably could bastle something together,
but forget about general tools gforth can provide.
There is no reward in this except the challenge.

[none albert]

In article <3ce3a9d3-3776-497e...@googlegroups.com>,

Probably you would like ciforth. There is an MSDOS version ...

[dxforth]

Sure, but how many didn't need a ready-to-run forth with editor, assembler,
OS file-system support etc comparable in quality to systems LMI was selling?
The Forth world including FIG had moved on with Forth-79 and then Forth-83.
If there were vendors still offering systems based on Fig-Forth, it was
because Laxen & Perry had threatened to go after anyone profiteering from
their work. FWIW I thought F83 was over-bloated too.

[Zbig]

> Sure, but how many didn't need a ready-to-run forth with editor, assembler,
> OS file-system support etc comparable in quality to systems LMI was selling?
> The Forth world including FIG had moved on with Forth-79 and then Forth-83.
> If there were vendors still offering systems based on Fig-Forth, it was
> because Laxen & Perry had threatened to go after anyone profiteering from
> their work. FWIW I thought F83 was over-bloated too.

Maybe indeed I look at this from today's perspective, when everything I need
(including tips, tricks and other kind of help/support) I can have „on a click”…
it wasn't that easy accessible in „diskette-based” times back in the day.

[Zbig]

> If there were vendors still offering systems based on Fig-Forth, it was
> because Laxen & Perry had threatened to go after anyone profiteering from
> their work.

On a second thought: wouldn't it be actually better solution for both them and
the Forth world simply to offer kind of agreement in case anyone would like to
use their work commercially?
They would have additional income — and their Forth would gain even more users.

[Brian Fox]

On Friday, February 24, 2023 at 5:07:08 PM UTC-5, dxforth wrote:

> Both F83 and Fig-Forth were ITC. Their speeds would have been comparable.

F83 compile times were much faster due to the hashed dictionary.

[Anton Ertl]

Paul Rubin <no.e...@nospam.invalid> writes:
>It mentions the possibility of multitasking being
>standardized. That is interesting too. Is it actually likely, in the
>sense of progress being made? Are there any proposed standardization
>specs around?

Andrew Haley worked on it before he dropped out of the standardization
effort. Now we have tasked Bernd Paysan with that, but I think he
wants to wrap up recognizers before taking this task on.

IIRC Andrew Haley produced some slides, not sure if there is something
available online.

I guess the documentation you are seeing is what we have from Bernd
Paysan, but he will propose only a part of that for standardization.

[Paul Rubin]

albert@cherry.(none) (albert) writes:
> On the subject of multi-tasking on a flash based CPU.
> There are c-based soc's intended for smart devices.
> 2 K flash and 16 K ram is more Forth-like.
> They are ram starved. A task will have separate tib, data stack
> and return stack.

The 16k flash and 2k ram seemed ok to me, since the flash would in both
cases be mostly used for code. With 16 bit cells if you have 16 cells
for each stack, that's 64 bytes of stack per task. Plus you'd have a
few user variables and a TCB. There wouldn't be a TIB in an embedded
application, but even if there was, why have a separate one per task?

A Forth version of the Anduril app (flashlight controller written in C)
might have about 5 or so tasks, so a few hundred bytes of ram would
suffice. It originally ran on the ATTiny85 which iirc has 8KB of flash
and 512B of ram, but it has reached the limit of code space on that
part, and new lights have been using the ATTiny1616 (16KB flash, 2KB
ram) which is nicer in other ways too.

I guess the ram requirement would increase if the app migrated to a 32
bit cpu and the Forth had 32 bit cells. Also, 16 cells per stack might
sometimes be too few. I guess that could be controlled at task
creation. Some tasks are more complicated than others.

I also wonder how interrupt handlers would fit into this.

[David Schultz]

On 2/25/23 1:33 PM, Paul Rubin wrote:> I guess the ram requirement would

increase if the app migrated to a 32
> bit cpu and the Forth had 32 bit cells. Also, 16 cells per stack might
> sometimes be too few. I guess that could be controlled at task
> creation. Some tasks are more complicated than others.
>
> I also wonder how interrupt handlers would fit into this.

Digging out my ARM eForth code I see:

; FORK ( u r s -- tid )
; Create and start a new task
; Parameters are the size of the user area, return stack, and
; parameter stack in cells. Return value to the parent is
; the task ID of the child.
; Minimum size for the user area is 7 which is added to the
; value on the stack.

This is based on the old Forth Dimensions article by Laxen but with the
task creation combined into a single word.

And an example of its use:

: BUFFER-TASK ( -- tid )
DMAC-INIT
0 16 24 FORK DBUFFER BEGIN CHECK-BUFFER AGAIN ;

( Begin task to write full buffers to the SD card )


Interrupts fit into the ARM system pretty easily so ISRs were high level
Forth rather than assembly. The ARM stack is used to save state and that
is a separate stack distinct from the Forth data and parameter stacks.
It is nice having plenty of memory. And registers.



--
http://davesrocketworks.com
David Schultz

[Zbig]

> The Forth world including FIG had moved on with Forth-79 and then Forth-83.

One more: are you sure really many „moved on with Forth-79”? Longer time
I was searching for any Forth-79 for DOS — actually just out of curiosity, to
take a look at it — it can nowhere be found, not present even on forth.org pages
(neither at Taygeta).

If I'm correct even for my C-64 I haven't got any Forth-79; several fig-s, two F83
(Blazin' Forth and UltraForth/VolksForth), one MVP Forth (Super Forth), one trying
to be ANS-compliant (Durex Forth, but this of course rather recent implementation)
— and that's about it. I've found that C64-Forth from Performance Micro has
79-STANDARD word present in its vocabulary, but anyway it uses, for example,
fig-Forth's VARIABLE.

So even if I find one (or maybe, who knows, even two) in the future, it doesn't seem
that Forth-79 was that popular in the past. No trace!

[dxforth]

I'd forgotten F83 had that. Can't say I ever measured or noticed
the difference even back in the day (of floppies).

[dxforth]

Perhaps they did. I once came across some utilities bundled with (IIRC) a
Paradise EGA/VGA card. It included what appeared to be an updated version
of F83. I believe Laxen worked for the company that produced the card.
I can understand the restriction on profiteering if one was in the business
of making a living from the product but in all other circumstances all it
does is restrict development.

[dxforth]

I believe MVP updated to Forth-79. I found a Micromotion Forth-79 system
for CP/M dated 1982. Forth Dimensions had adverts for Forth-79 systems.
Commercial support for Forth-79 was there, it's just that there was little
available in the public domain. The second factor was it was short-lived.
Almost immediately after Forth-79 hit the streets, implementers found
problems with the spec. That gave FIG the impetus/excuse to start working
on a new Standard.

[Zbig]

> I believe MVP updated to Forth-79.

MVP is actually a „mix” of fig and F79, trying to get the best of both worlds.

[none albert]

In article <87r0uds...@nightsong.com>,

I can't wait to see a sensible application of multi-tasking on
a 2k RAM sbc. So I suspend disbelief till then.

[Zbig]

> I can't wait to see a sensible application of multi-tasking on
> a 2k RAM sbc. So I suspend disbelief till then.

If the code of the application is going to reside in flash, and to use
the RAM just for its data — why not?

[none albert]

In article <1bf203c1-1937-4d7b...@googlegroups.com>,

I can't wait to see it.

[Paul Rubin]

albert@cherry.(none) (albert) writes:
> I can't wait to see a sensible application of multi-tasking on
> a 2k RAM sbc. So I suspend disbelief till then.

I thought it had already been done in 8051 class mcu's, e.g. with
Chipforth. Maybe I'm wrong though.

I know that eForth on the STM8 (1k of ram) supports multitasking because
I played with it, but it only handles two tasks iirc.

I wonder if it is feasible to standardize a coroutine switch operation,
or at least add it to gforth. So that gives very minimal multitasking,
i.e. without separate stacks per task. Tiny processors like the GA144
nodes implement it it in hardware. C++20 has something like it now, and
there are some C header libraries like protothreads that implement it
through preprocessor hacks. But it's not so easy to do in traditional
Forth.

[Anton Ertl]

Paul Rubin <no.e...@nospam.invalid> writes:
>I wonder if it is feasible to standardize a coroutine switch operation,
>or at least add it to gforth. So that gives very minimal multitasking,
>i.e. without separate stacks per task.

If it does not have separate stacks, it's not coroutining. But in the
Forth tradition of selling some deficient solution as the genuine
article (and sometimes the deficient solution is good enough, and the
additional cost of the genuine article too expensive), you can look at
Albert van der Horst's CO.

>Tiny processors like the GA144
>nodes implement it it in hardware.

The cores of the GA144 have separate stacks, and they actually
genuinely run in parallel, unlike coroutines.

[Paul Rubin]

an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> If it does not have separate stacks, it's not coroutining.

I thought so too, but the C++20 has taken issue with that, saying that
if C++20 coroutines had separate stacks, they would be called fibers.
That is apparently Microsoft-speak though.

> Albert van der Horst's CO.

I'll see if I can find that. I have a copy of 4th downloaded, if that's
the right place.

>>Tiny processors like the GA144 nodes implement it it in hardware.
> The cores of the GA144 have separate stacks, and they actually
> genuinely run in parallel, unlike coroutines.

I mean the F18A (individual core of the GA144) has its own coroutine
jump instruction. It swaps the top of the R stack with the current PC.
CO is probably similar. In a threaded Forth, it can be done with
R-stack manipulation, I suppose.

[dxforth]

On 27/02/2023 5:40 am, Paul Rubin wrote:
> albert@cherry.(none) (albert) writes:
>> I can't wait to see a sensible application of multi-tasking on
>> a 2k RAM sbc. So I suspend disbelief till then.
>
> I thought it had already been done in 8051 class mcu's, e.g. with
> Chipforth. Maybe I'm wrong though.
>
> I know that eForth on the STM8 (1k of ram) supports multitasking because
> I played with it, but it only handles two tasks iirc.

There's a SwiftX for the Arduino. That's 32K flash and 2K ram.
SwiftX has an application stripper that weeds out unused code.
That should be enough flash for a serious application?

[Paul Rubin]

dxforth <dxf...@gmail.com> writes:
> There's a SwiftX for the Arduino. That's 32K flash and 2K ram.
> SwiftX has an application stripper that weeds out unused code.
> That should be enough flash for a serious application?

16K flash is enough, really. That's what newer lights that run this app
are using. I don't pick the cpus. But, I think the ATMega parts with
32K flash only come in larger packages. The 1616 is chosen because it
is available in a 3x3mm QFN if I have the terminology right.

[dxforth]

SwiftX-AVR supports a bunch of parts out of the box. Each comes with
its own config files and folder. I think (but not sure) users can
create a custom config for their particular part.

Elsewhere you mention ChipForth. Can't say I know anything about it.
Wasn't it a precursor to SwiftX ?

[Anton Ertl]

Paul Rubin <no.e...@nospam.invalid> writes:
>an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> If it does not have separate stacks, it's not coroutining.
>
>I thought so too, but the C++20 has taken issue with that, saying that
>if C++20 coroutines had separate stacks, they would be called fibers.
>That is apparently Microsoft-speak though.

C++20 is not the first programming-language standard that deviates
from established terminology and won't be the last. I have read
"fiber" rarely, IIRC with the meaning of user-level (aka green)
threads, and indeed,
<https://en.wikipedia.org/wiki/Fiber_(computer_science)> confirms my
memory.

The difference between user-level threads and coroutines is that
coroutines cooperate intimately, passing data from one to the other,
and calling each other directly (I see that
<https://en.wikipedia.org/wiki/Coroutine#Definition_and_Types> calls
this "symmetric coroutine"), while threads work mostly independently.

>> Albert van der Horst's CO.
>
>I'll see if I can find that. I have a copy of 4th downloaded, if that's
>the right place.

Unlikely. 4th is from Hans Bezemer.

>I mean the F18A (individual core of the GA144) has its own coroutine
>jump instruction. It swaps the top of the R stack with the current PC.
>CO is probably similar. In a threaded Forth, it can be done with
>R-stack manipulation, I suppose.

Yes, IIRC that's what CO does. So it would be something like

: CO 2r> swap 2>r ;

[Paul Rubin]

an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> C++20 is not the first programming-language standard that deviates
> from established terminology and won't be the last.

There is a good paper about coroutines in Lua that classifies different
versions of coroutines and includes the stackless type under the
umbrella, but reserves the term "full" coroutines for stackful
coroutines that can be passed around as first class objects:

http://www.inf.puc-rio.br/~roberto/docs/MCC15-04.pdf

> Unlikely. 4th is from Hans Bezemer.

Oops, I got 4th confused with another implementation.

> Yes, IIRC that's what CO does. So it would be something like
> : CO 2r> swap 2>r ;

Yes that looks right, or pretty close.

[Paul Rubin]

dxforth <dxf...@gmail.com> writes:
> Elsewhere you mention ChipForth. Can't say I know anything about it.
> Wasn't it a precursor to SwiftX ?

I have also been looking for info but it looks like most is gone from
the web. Forth Inc. sold it for a while but I don't think it was
related to SwiftX. It was a tethered Forth for 8051 and comparable
MCU's whether the text interpreter was entirely on a host PC.

It came from this company in England, which is now closed down. Its web
site is partly online but much of the interesting stuff is 404:

https://www.computer-solutions.co.uk/chipdev/cf-space.htm

If anyone else has info I'd be interested to see it.

[none albert]

In article <871qmcs...@nightsong.com>,

Coroutine words abound. I have dubbed it CO. Chuck Moore uses ;: .
In noforth (Ouwerkerk & Nijhof) it is called DIVE .

It is as simple as exchanging the current interpreter pointer
with the address to return to.

CODE CO
XCHG ESI,[EBP] ; xchg HIP,[RSP]
NEXT

This is useful (e.g. to use in combination with decorators) but
it doesn't amount to multi-tasking.

[none albert]

In article <87o7pgq...@nightsong.com>,

Paul Rubin <no.e...@nospam.invalid> wrote:
>an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> If it does not have separate stacks, it's not coroutining.
>
>I thought so too, but the C++20 has taken issue with that, saying that
>if C++20 coroutines had separate stacks, they would be called fibers.
>That is apparently Microsoft-speak though.

Anton Ertl has the tendency to accept only meanings of terms
customary in his environment. I tend to accept the interpretation
of Microsoft, of Knuth.

>
>> Albert van der Horst's CO.
>
>I'll see if I can find that. I have a copy of 4th downloaded, if that's
>the right place.

The right place to look is
https://forth.hcc.nl/producten/ciforth.html
It makes no difference what you download. Each archive comes with full
assembler source (and documentation of the kernel, and a source
library.) CO is defined in assembly, so pick a processor where you're
familiar with.

>
>>>Tiny processors like the GA144 nodes implement it it in hardware.
>> The cores of the GA144 have separate stacks, and they actually
>> genuinely run in parallel, unlike coroutines.
>
>I mean the F18A (individual core of the GA144) has its own coroutine
>jump instruction. It swaps the top of the R stack with the current PC.
>CO is probably similar. In a threaded Forth, it can be done with
>R-stack manipulation, I suppose.

You're so right. It is R-stack manipulation.
You can look at another article of this thread to find the code
of CO (spoiler alert, it is one instruction.)

Groetjes Albert

P.S.
I have had it with the GA144.
Leon and I had to change the tools in order to run a non-trivial
program. Then with the next release the tools had to changed
in the same fashion, but we had to gave up.
I have 10 GA144 chips. I keep one of them, the rest is available
to the highest bidder.

[Jan Coombs]

On Mon, 27 Feb 2023 17:53:10 +1100
dxforth <dxf...@gmail.com> wrote:

> Elsewhere you mention ChipForth. Can't say I know anything about it.
> Wasn't it a precursor to SwiftX ?

chipFORTH networks 7,000 micros
https://www.computer-solutions.co.uk/chipdev/lighting.htm

Jan Coombs
--

[Hans Bezemer]

On Monday, February 27, 2023 at 9:47:11 AM UTC+1, Paul Rubin wrote:
> > Unlikely. 4th is from Hans Bezemer.
> Oops, I got 4th confused with another implementation.

That's unfair! I have some simple co-routines as well:

: yield r> r> swap >r >r ;
synonym grab rdrop

As is shown here:

: payload 10000000 0 do loop dup 1+ swap 100 < ;
\ dummy task
: test
." Wait for it.. " spinner 0 \ start coroutine
begin payload while yield repeat \ show spinner while doing it
drop grab bl spin cr \ grab control, finish spinner
." Done!" cr \ all done
;

test

True, it can't do much, but it works. ;-)

Hans Bezemer

[dxforth]

Thanks for that. A COMSOL product that appears to have targetted older chips.

Links to missing pages
https://web.archive.org/web/20151103000711/https://www.computer-solutions.co.uk/chipdev/cf.htm#cF%20Intro
https://web.archive.org/web/20151103000848/http://www.computer-solutions.co.uk/chipdev/cfworks.htm

[Paul Rubin]

dxforth <dxf...@gmail.com> writes:
> Links to missing pages

> https://web.archive.org...

Thanks for finding those, they help. They explain that ChipForth is a
Polyforth derivative, and supports multitasking on the target with
overhead of 48 bytes of ram per task. That sounds like two 16-level
stacks plus a few registers and a TCB. It also mentions that the host
communication module is < 256 bytes of code and doesn't have to be
included in a final build.

It would be great to have an actual manual, as I don't see one there,
but it's ok.

[dxforth]

On 28/02/2023 7:53 am, Paul Rubin wrote:
> dxforth <dxf...@gmail.com> writes:
>> Links to missing pages
>> https://web.archive.org...
>
> Thanks for finding those, they help. They explain that ChipForth is a
> Polyforth derivative, and supports multitasking on the target with
> overhead of 48 bytes of ram per task. That sounds like two 16-level
> stacks plus a few registers and a TCB. It also mentions that the host
> communication module is < 256 bytes of code and doesn't have to be
> included in a final build.

The SwiftX doc describes a multitasking example as having:

"32 bytes of user area, 128 bytes of data stack, and 64 bytes of return stack"

These aren't necessarily minimums. In Forth the programmer is very much
in charge. Since everything is exposed he can calculate resources used
down to the last byte. That's in contrast to black box systems that supply
an API and specs because there's stuff going on underneath the programmer
'need not be concerned with'. I note the team behind Arduino is looking
into multitasking and asking for input...

https://blog.arduino.cc/2022/08/02/introducing-multitasking-to-arduino/

[Andy Valencia]

albert@cherry.(none) (albert) writes:
> I can't wait to see a sensible application of multi-tasking on
> a 2k RAM sbc. So I suspend disbelief till then.

You could allocate a task to each HW source (button, touch screen, timer, ...)
and just have them cooperatively take turns checking their hardware. Or you
could have a service loop that checked each sequentially. With lightweight
Forth tasks, it's really a "I saw poe-tay-toe, you say poe-tah-toe" kind of
thing. In 2k I _might_ use tasks, in 8k I'd _probably_ use them.

I find that if you can avoid interrupts (poll instead), it streamlines the
software considerably. At least SMALL software; you get to a megabyte and
the infrastructure for interrupts is in the noise.

Andy Valencia
Home page: https://www.vsta.org/andy/
To contact me: https://www.vsta.org/contact/andy.html

[dxforth]

On 26/02/2023 4:23 am, Anton Ertl wrote:
> Paul Rubin <no.e...@nospam.invalid> writes:
>> It mentions the possibility of multitasking being
>> standardized. That is interesting too. Is it actually likely, in the
>> sense of progress being made? Are there any proposed standardization
>> specs around?
>
> Andrew Haley worked on it before he dropped out of the standardization
> effort. Now we have tasked Bernd Paysan with that, but I think he
> wants to wrap up recognizers before taking this task on.
>
> IIRC Andrew Haley produced some slides, not sure if there is something
> available online.
> ...

Googling forth multitaskers turned up this reference:

https://theforth.net/package/multi-tasking

[dxforth]

On 27/02/2023 7:50 pm, Paul Rubin wrote:
> dxforth <dxf...@gmail.com> writes:
>> Elsewhere you mention ChipForth. Can't say I know anything about it.
>> Wasn't it a precursor to SwiftX ?
>
> I have also been looking for info but it looks like most is gone from
> the web. Forth Inc. sold it for a while but I don't think it was
> related to SwiftX. It was a tethered Forth for 8051 and comparable
> MCU's whether the text interpreter was entirely on a host PC.

I just noticed this tethered forth for Arduino:

https://github.com/CharleyShattuck/myforth-arduino

In true forth style, docs are minimal to non-existent. However there's
an intro here:

http://www.forth.org/svfig/kk/02-2011-Shattuck.pdf