On Thursday, March 4, 1999 at 2:00:00 AM UTC-6, Alex Bilyk wrote:
> Great article. Good points.
> I have got a book on Forth dated by 1988: 153 pages. Everything is in
> there: language, internals future ideas and examples. Simple and easy to
> understand. And now I have been looking at the ANS documents -- what a
> disappointment.
> Although, I find ANS as an excellent scripting language specification. It is
> rather resembling a language I got to know back in 1988 -- it was called
> FORTH.
> AB
> he...@albany.net wrote in message <7bje9c$k7$1...@nnrp1.dejanews.com>...
> >Jeff's article contrasts ANS Forth with what Jeff
> >and Chuck call Machine Forth, "27 easy to learn
> >and understand Forth opcodes that take 2ns. We
> >took people who never learned ANSI Forth and taught
> >them Machine Forth in an hour and had them programming
> >an embedded wireless ethernet controller in it the
> >next day."
> >
> >Most of us could spare an hour. Is there a teacher
> >in the house?
> >
> >Anti Ansi Forth:
> >
> ><http://www.UltraTechnology.com/antiansi.htm>
> >
> >Leo Wong
> >he...@albany.net
> >http://www.albany.net/~hello/
> >
> >-----------== Posted via Deja News, The Discussion Network ==----------
> >http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Is that Mcabe's book, Forth Fundamentals v1? I have that book, and love it. It's been the basis of all of my Forth work, along with Jeff's numerous writings.

Kip Ingram
kip.ingram@gmail.com

On Monday, 4 April 2022 at 02:45:42 UTC+1, Kip Ingram wrote:
> On Thursday, March 4, 1999 at 2:00:00 AM UTC-6, Alex Bilyk wrote:
> > Great article. Good points.
> > I have got a book on Forth dated by 1988: 153 pages. Everything is in
> > there: language, internals future ideas and examples. Simple and easy to
> > understand. And now I have been looking at the ANS documents -- what a
> > disappointment.
> > Although, I find ANS as an excellent scripting language specification. It is
> > rather resembling a language I got to know back in 1988 -- it was called
> > FORTH.
> > AB
> > he...@albany.net wrote in message <7bje9c$k7$1...@nnrp1.dejanews.com>...
> > >Jeff's article contrasts ANS Forth with what Jeff
> > >and Chuck call Machine Forth, "27 easy to learn
> > >and understand Forth opcodes that take 2ns. We
> > >took people who never learned ANSI Forth and taught
> > >them Machine Forth in an hour and had them programming
> > >an embedded wireless ethernet controller in it the
> > >next day."
> > >
> > >Most of us could spare an hour. Is there a teacher
> > >in the house?
> > >
> > >Anti Ansi Forth:
> > >
> > ><http://www.UltraTechnology.com/antiansi.htm>
> > >
> > >Leo Wong
> > >he...@albany.net
> > >http://www.albany.net/~hello/
> > >
> > >-----------== Posted via Deja News, The Discussion Network ==----------
> > >http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
> Is that Mcabe's book, Forth Fundamentals v1? I have that book, and love it. It's been the basis of all of my Forth work, along with Jeff's numerous writings.
>
> Kip Ingram
> kip.i...@gmail.com

Unfortunately the link to Leo Wong has changed, see http://www.murphywong.net/hello/simple.htm
When I found it years ago,
we started communicating and he agreed that I can use to as a basis - and out came the

Forth Lite Tutorial

- then with lots of example code that I used to get into Forth.
It helped me a lot at the time to understand Forth better, and the book seems to be quite popular for beginners
You can see Leo with the Forth Mug I had sent him at the time on the cover
http://www.murphywong.net/hello/simple.htm

It was a very nice addition to my Forth Bookshelf
https://www.amazon.co.uk/Juergen-Pintaske/e/B00N8HVEZM

eForth as Arduino Sketch seems to be quite popular to try out Forth.
Just get an Arduino nano or Uno
load the sketch
and start programming.
More info is here
https://wiki.forth-ev.de/doku.php/projects:430eforth:start

> eForth as Arduino Sketch seems to be quite popular to try out Forth.
> Just get an Arduino nano or Uno
> load the sketch
> and start programming.
> More info is here
> https://wiki.forth-ev.de/doku.php/projects:430eforth:start

I'm glad to see any simple to use Forth boards come to life. There is no better way than Forth to introduce a novice to the fundamentals of computer programming and hardware interface IMHO. Arranging a meeting between said novices and boards is the difficulty because reasons...

I'm a fan of native Forth instruction sets vs VMs and inner interpreters (oops, not to forget inline native code generators). I'm amused to read serious debate concerning whether DUP >R beats >R R@ or not.

Since the turn of the millenia, low-cost FPGA development kits have been available for anyone to design their own notion of a (e.g. Forth) CPU, RAM, and IO SoC. I'm an embedded guy, so ANS compliance has never been an objective in my projects. If I were obsessed with ANS compliance, I would never have completed any of these projects, and learned nothing.

To my mind, ANS implementations are valuable for desktop boxes that must deal with the *nix notion that all IO is through files (except for IOCTLs...and...er...um). So a keystroke plops a fresh char (whatever that is) into the stdin stream. Long ago, when I looked into how gforth implemented key? a dependency on the venerable ncurses library was discovered. "Huh", I thought.

Having said that, a board that boots *nix in order to run gforth on platformX is a great idea especially if floating-point is required. Perhaps in the future widespread adoptance of ferromagnetic RAM will solve the flash write endurance problem for non-volatile memory.

- Myron

Myron Plichota <myronplichota@gmail.com> writes:
>I'm a fan of native Forth instruction sets vs VMs and inner interpreters (o=
>ops, not to forget inline native code generators). I'm amused to read serio=
>us debate concerning whether DUP >R beats >R R@ or not.

That's just as relevant for native code as for threaded code. In
either case, optimization can eliminate the difference (and for
SwiftForth and VFX, it does by default). However, when I say, in VFX
4.72:

unoptimised
defer foo
: bar1 dup >r foo r> ;
: bar2 >r r@ foo r> ;
see bar1 see bar2

I get:

BAR1
( 080C0AA0 8D6DFC ) LEA EBP, [EBP+-04]
( 080C0AA3 895D00 ) MOV [EBP], EBX
( 080C0AA6 53 ) PUSH EBX
( 080C0AA7 8B5D00 ) MOV EBX, [EBP]
( 080C0AAA 8D6D04 ) LEA EBP, [EBP+04]
( 080C0AAD FF15800A0C08 ) CALL [080C0A80] FOO
( 080C0AB3 5A ) POP EDX
( 080C0AB4 8D6DFC ) LEA EBP, [EBP+-04]
( 080C0AB7 895D00 ) MOV [EBP], EBX
( 080C0ABA 8BDA ) MOV EBX, EDX
( 080C0ABC C3 ) NEXT,
( 29 bytes, 11 instructions )

BAR2
( 080C0AE0 53 ) PUSH EBX
( 080C0AE1 8B5D00 ) MOV EBX, [EBP]
( 080C0AE4 8D6D04 ) LEA EBP, [EBP+04]
( 080C0AE7 8B1424 ) MOV EDX, [ESP]
( 080C0AEA 8D6DFC ) LEA EBP, [EBP+-04]
( 080C0AED 895D00 ) MOV [EBP], EBX
( 080C0AF0 8BDA ) MOV EBX, EDX
( 080C0AF2 FF15800A0C08 ) CALL [080C0A80] FOO
( 080C0AF8 5A ) POP EDX
( 080C0AF9 8D6DFC ) LEA EBP, [EBP+-04]
( 080C0AFC 895D00 ) MOV [EBP], EBX
( 080C0AFF 8BDA ) MOV EBX, EDX
( 080C0B01 C3 ) NEXT,
( 34 bytes, 13 instructions )

So DUP >R beats >R R@ on an unoptimized native-code system.

>To my mind, ANS implementations are valuable for desktop boxes that must de=
>al with the *nix notion that all IO is through files (except for IOCTLs...a=
>nd...er...um). So a keystroke plops a fresh char (whatever that is) into th=
>e stdin stream. Long ago, when I looked into how gforth implemented key? a =
>dependency on the venerable ncurses library was discovered. "Huh", I though=
>t.

I have not found "curses" in the C parts of Gforth 0.3.0, 0.4.0,
0.5.0, 0.6.2, 0.7.3, or the current development version.

But sure, you certainly find a lot of legacy interfaces there, having
to do with the fact that Unix started on machines with terminals
attached though serial interfaces, and these days we have layers upon
layers of software that still work with these interfaces, even though
serial terminals are long gone.

> Perhaps in the=
> future widespread adoptance of ferromagnetic RAM will solve the flash writ=
>e endurance problem for non-volatile memory.

Persistent memory (whatever implementation technology) has been
promised to be around the corner for close to a decade, but has not
been widely competetive with the current combo of DRAM and flash yet,
so I would not hold my breath.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

Dear Anton,

Far be it from me to belittle the efforts of the ANS/gforth maintainers. I have used 32 and 64 bit versions of gforth with gratitude in desktop environments. As you read on, you may perceive why the desktop and embedded environments are so different.

[snip]
> So DUP >R beats >R R@ on an unoptimized native-code system.

A valid comparison for x86 inline code implementations. A non-issue for a competently-designed stack machine that is free of industry standards.

[snip]
> I have not found "curses" in the C parts of Gforth 0.3.0, 0.4.0,
> 0.5.0, 0.6.2, 0.7.3, or the current development version.

I cited ncurses, but perhaps the situation has changed in the years gone by. Please inform us on the current solution of key? in C-land.

> But sure, you certainly find a lot of legacy interfaces there, having
> to do with the fact that Unix started on machines with terminals
> attached though serial interfaces, and these days we have layers upon
> layers of software that still work with these interfaces, even though
> serial terminals are long gone.

But USB/UART interfaces are alive and well for embedded developers no matter which language they craft their work in.

> Persistent memory (whatever implementation technology) has been
> promised to be around the corner for close to a decade, but has not
> been widely competetive with the current combo of DRAM and flash yet,
> so I would not hold my breath.

And I'm not. My current realization doesn't require any future technology.

Jimbo is not James Bond.

- Myron

Myron Plichota <myronplichota@gmail.com> writes:
[someone:]
>> So DUP >R beats >R R@ on an unoptimized native-code system.
>
>A valid comparison for x86 inline code implementations.

Let's see for other architectures (on gforth-fast):

Aarch64:
dup >r >r r@ superinstr.
mov x21, x27 sub x22, x22, #0x8 sub x22, x22, #0x8
add x26, x26, #0x8 add x26, x26, #0x8 add x26, x26, #0x10
sub x22, x22, #0x8 str x27, [x22,#0x0] str x27, [x22,#0x0]
add x26, x26, #0x8 ldr x27, [x22,#0x0]
str x21, [x22,#0x0] add x26, x26, #0x8

RISC-V
dup >r >r r@
mv s1,s7 addi s2,s2,-8
addi s10,s10,8 addi s10,s10,8
addi s2,s2,-8 sd s7,$0(s2)
addi s10,s10,8 ld s7,$0(s2)
sd s1,$0(s2) addi s10,s10,8

The same number of instructions, but >R R@ has a store followed by a
load of the same value, while DUP >R has only a store; however, a
reason for that is that gforth-fast has stack caching for the data
stack, but not for the return stack.

> A non-issue for a competently-designed stack machine that is free of industry standards.

Let's take a look at b16 and b16-small <https://bernd-paysan.de/b16.html>:

On b16 you can use DUP and >R in every slot, but R@ only in slot 1
(instruction $12 is R@ in slot 1, but R@+ in other slots).

On b16-small there is DUP and >R, but no R@.

Do you think they are not competently designed?

If you have enough encoding space (i.e., many bits per instruction),
it's just as easy to implement a single DUP-R> instruction as R@, and
that is faster on such an architecture than either DUP >R or >R R@.

>[snip]
>> I have not found "curses" in the C parts of Gforth 0.3.0, 0.4.0,
>> 0.5.0, 0.6.2, 0.7.3, or the current development version.
>
>I cited ncurses,

If a file contains "ncurses", and I search for "curses", I will find
that file.

>but perhaps the situation has changed in the years gone by.

As you should see from the long list of versions starting from 0.3.0
in 1996.

>Please inform us on the current solution of key? in C-land.

I don't think there is one. That's why we have OS-specific solutions
in Gforth.

>> But sure, you certainly find a lot of legacy interfaces there, having
>> to do with the fact that Unix started on machines with terminals
>> attached though serial interfaces, and these days we have layers upon
>> layers of software that still work with these interfaces, even though
>> serial terminals are long gone.
>
>But USB/UART interfaces are alive and well for embedded developers no matter which language they craft their work in.

Yes, so we also have layers of hardware.

And these layers work once you get the code right (which is not easy;
e.g., lxf and vfx have problems when pasting code into them). Jeff
Fox would have lamented all these layers, but it seems that the basic
implementation in Gforth has not changed much since 1994.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> Perhaps in the future widespread adoptance of ferromagnetic RAM will
>> solve the flash write endurance problem for non-volatile memory.
>
> Persistent memory ... has not been widely competetive with the current
> combo of DRAM and flash yet

FRAM seems almost perfect for embedded Forth on a small scale. It's not
cost effective at the gigabyte scale but a 64KB FRAM chip costs a few
dollars. The MSP430FR5969 which has 64K of FRAM built in (plus 2K of
SRAM) seemed like a great choice as a Forth processor, with its 16 bit
cells, FRAM, and stack-friendly addressing cells. It used to be
available on a low cost Launchpad board but I think they have
discontinued that, as 16 bit cpus have gone out of style.

There are some SPI FRAM breakout boards on Adafruit that could be used
with ARM processors or whatever. I think that for development though,
conventional flash write wear isn't that big an issue. You can use You
can use <BUILDS DOES> instead of CREATE DOES> or various other tricks to
avoid rewriting flash, and wearing out flash just from debugging doesn't
seem that likely. Finally, many of today's MCU's have enough ram that
compiling direct to flash isn't important. You can compile to ram, and
freeze to flash once you want to save a working version.

On 4/12/22 7:36 PM, Paul Rubin wrote:

> FRAM seems almost perfect for embedded Forth on a small scale.
http://davesrocketworks.com/electronics/msp430/eforth/index.html

https://www.ti.com/tool/MSP-EXP430FR5969

--
http://davesrocketworks.com
David Schultz

Paul Rubin <no.email@nospam.invalid> writes:
>FRAM seems almost perfect for embedded Forth on a small scale. It's not
>cost effective at the gigabyte scale but a 64KB FRAM chip costs a few
>dollars. The MSP430FR5969 which has 64K of FRAM built in (plus 2K of
>SRAM) seemed like a great choice as a Forth processor, with its 16 bit
>cells, FRAM, and stack-friendly addressing cells. It used to be
>available on a low cost Launchpad board but I think they have
>discontinued that, as 16 bit cpus have gone out of style.

It still seems to be available:
<https://www.mouser.de/ProductDetail/Texas-Instruments/MSP-EXP430FR5969?qs=FBI%252BX3tnPf0g8H7ws5NtfA%3D%3D>

23 immediately available (but you can only buy up to 3), and more from
the manufacturer. It's not cheap, though.

Anyway, most of the MSP430 chips did not use FRAM, and AFAIK none of
the MSP432 chips do, nor any of the competition AFAIK, so this does
not look like FRAM has a future even in the specific niche that the
MSP430FR5969 is occupying. That niche seems to be embedded systems
with fluctuating power supply.

So the chip would get a little power for an unpredictable amount of
time, do some computations, store them in FRAM, and when the power
goes away, it would just stop. On the next wakeup it would get the
last checkpoint from the FRAM and compute some more.

I don't know if that niche is too small, or if that mode of operation
would require major changes to the ARM cores that the MSP432 chips are
based on, if the ARM cores cannot be produced on the process that TI
uses for chips that contain FRAM, or if it's something else, but the
bottom line is that we are not seeing new FRAM designs, so FRAM can
certainly not be seen as an example of a coming wave of persistent
memory technologies.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

In article <2022Apr13.083811@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>Paul Rubin <no.email@nospam.invalid> writes:
>>FRAM seems almost perfect for embedded Forth on a small scale. It's not
>>cost effective at the gigabyte scale but a 64KB FRAM chip costs a few
>>dollars. The MSP430FR5969 which has 64K of FRAM built in (plus 2K of
>>SRAM) seemed like a great choice as a Forth processor, with its 16 bit
>>cells, FRAM, and stack-friendly addressing cells. It used to be
>>available on a low cost Launchpad board but I think they have
>>discontinued that, as 16 bit cpus have gone out of style.
>
>It still seems to be available:
><https://www.mouser.de/ProductDetail/Texas-Instruments/MSP-EXP430FR5969?qs=FBI%252BX3tnPf0g8H7ws5NtfA%3D%3D>
>
>23 immediately available (but you can only buy up to 3), and more from
>the manufacturer. It's not cheap, though.
>
>Anyway, most of the MSP430 chips did not use FRAM, and AFAIK none of
>the MSP432 chips do, nor any of the competition AFAIK, so this does
>not look like FRAM has a future even in the specific niche that the
>MSP430FR5969 is occupying. That niche seems to be embedded systems
>with fluctuating power supply.
>
>So the chip would get a little power for an unpredictable amount of
>time, do some computations, store them in FRAM, and when the power
>goes away, it would just stop. On the next wakeup it would get the
>last checkpoint from the FRAM and compute some more.
>
>I don't know if that niche is too small, or if that mode of operation
>would require major changes to the ARM cores that the MSP432 chips are
>based on, if the ARM cores cannot be produced on the process that TI
>uses for chips that contain FRAM, or if it's something else, but the
>bottom line is that we are not seeing new FRAM designs, so FRAM can
>certainly not be seen as an example of a coming wave of persistent
>memory technologies.

FRAM also doesn't fit in the hierarchy of L1 cache, L2 cache,
L3 cache, main memory, swap space on disk.

>
>- anton

--
"in our communism country Viet Nam, people are forced to be
alive and in the western country like US, people are free to
die from Covid 19 lol" duc ha
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

On 13/04/2022 10:36, Paul Rubin wrote:
>
> FRAM seems almost perfect for embedded Forth on a small scale. It's not
> cost effective at the gigabyte scale but a 64KB FRAM chip costs a few
> dollars. The MSP430FR5969 which has 64K of FRAM built in (plus 2K of
> SRAM) seemed like a great choice as a Forth processor, with its 16 bit
> cells, FRAM, and stack-friendly addressing cells.

If the MSP430 is anything like Atmel's 8-bit in the way the latter eat
program memory then 64K starts to look underwhelming.

albert@cherry.(none) (albert) writes:
>FRAM also doesn't fit in the hierarchy of L1 cache, L2 cache,
>L3 cache, main memory, swap space on disk.

All persistent memory technologies promise to combine the advantages
of DRAM (main memory) and SSDs. However, a lot of the attractiveness
of this combination is based on the misconception that we then can
avoid the software complications of dealing with files, persistent
data bases, etc.

Caches would continue to be used where applicable (possibly with more
write-through guarantees), and "swap space on disk" is an anachronism.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

> >A valid comparison for x86 inline code implementations.
> Let's see for other architectures (on gforth-fast):
>
> Aarch64:
> dup >r >r r@ superinstr.
> mov x21, x27 sub x22, x22, #0x8 sub x22, x22, #0x8
> add x26, x26, #0x8 add x26, x26, #0x8 add x26, x26, #0x10
> sub x22, x22, #0x8 str x27, [x22,#0x0] str x27, [x22,#0x0]
> add x26, x26, #0x8 ldr x27, [x22,#0x0]
> str x21, [x22,#0x0] add x26, x26, #0x8
>
> RISC-V
> dup >r >r r@
> mv s1,s7 addi s2,s2,-8
> addi s10,s10,8 addi s10,s10,8
> addi s2,s2,-8 sd s7,$0(s2)
> addi s10,s10,8 ld s7,$0(s2)
> sd s1,$0(s2) addi s10,s10,8
>
> The same number of instructions, but >R R@ has a store followed by a
> load of the same value, while DUP >R has only a store; however, a
> reason for that is that gforth-fast has stack caching for the data
> stack, but not for the return stack.

Due to the implementation, not an inherent characteristic of Forth.

> > A non-issue for a competently-designed stack machine that is free of industry standards.
> Let's take a look at b16 and b16-small <https://bernd-paysan.de/b16.html>:
>
> On b16 you can use DUP and >R in every slot, but R@ only in slot 1
> (instruction $12 is R@ in slot 1, but R@+ in other slots).
>
> On b16-small there is DUP and >R, but no R@.
>
> Do you think they are not competently designed?

I apologize for a poor choice of words. I wasn't looking for a fight, and I did not mean to disparage any other stack machine designs or designers. It just so happens that my design encodes both >R R@ and DUP >R as a pair of 4-bit instructions, and both sequences execute in a total of 2 clock cycles no matter which slots they occur in.

> >but perhaps the situation has changed in the years gone by.
> As you should see from the long list of versions starting from 0.3.0
> in 1996.

I stand corrected. I can't explain how I came to believe the ncurses fallacy. Perhaps years ago, I read something somewhere and accepted it because it made sense to me.

- Myron

I carelessly stated "Long ago, when I looked into how gforth implemented key? a dependency on the venerable ncurses library was discovered.".

The truth of the matter is that I never studied gforth source with due diligence. Perhaps a search engine result landed me in a forum, and the blind led the blind.

I have nothing but respect for the ANS and gforth developers. You are doing what I can't.

I can only claim a clear understanding of my own embedded designs.

- Myron

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> It still seems to be available:
> <https://www.mouser.de/ProductDetail/Texas-Instruments/MSP-EXP430FR5969?qs=FBI%252BX3tnPf0g8H7ws5NtfA%3D%3D>
>
> 23 immediately available (but you can only buy up to 3), and more from
> the manufacturer. It's not cheap, though.

That is a pretty fancy board with 128K of FRAM, and it says 19.36 euro
which includes an alphanumeric LCD display iirc. IIRC There was a less
expensive board (10 or so euro?) with 64K of FRAM and without the LCD.
And of course you can buy the cpu chip by itself: I think that fancy one
is around 7 euro. Idk about the lower models.

Yes TI said something about the MSP430 FRAM parts using a special fab
process that wouldn't work with ARM cores. I think the MSP430 itself is
now something of a legacy architecture. It was nice in many ways, but
nobody wants 16 bit cpus any more. A pity. Maybe they can make a
RISC-V series using the FRAM-friendly fab process.

Here is an Adafruit SPI FRAM breakout board, on the expensive side at 10
USD for 64KB: https://www.adafruit.com/product/1895

They also have larger and smaller ones. I expect that the bare chips
are somewhat less expensive than those boards, since the boards are
retail products.

dxforth <dxforth@gmail.com> writes:
> If the MSP430 is anything like Atmel's 8-bit in the way the latter eat
> program memory then 64K starts to look underwhelming.

MSP430 code density is actually pretty good. It is a 16 bit cpu with
architecture reminiscent of the PDP-11, with autoincrement and
autodecrement addressing modes and all that, but with 16 registers
instead of 8. The addressing modes are quite handy for implementing
stacks, threaded code interpreters, buffer pointers, and the like. It
is very nice for Forth with 16 bit cells. It has lost popularity
though, as people have moved on to 32 bit cpus.

The 4e4th board used a small MSP430 as an attempt to make a popular, low
cost embedded Forth device. These days though, ARM and RISC-V devices
are probably more attractive.

Paul Rubin <no.email@nospam.invalid> writes:
> Here is an Adafruit SPI FRAM breakout board, on the expensive side at 10
> USD for 64KB: https://www.adafruit.com/product/1895

Oops, that one is 32KB not 64KB. They also have 8KB (
https://www.adafruit.com/product/1897 , $6), 256KB (
https://www.adafruit.com/product/4718 , $13), and 512KB (
https://www.adafruit.com/product/4719 , $18).

I guess these are useful for some purposes, though today's cpus often
have some very low powered backup SRAM, that can retain data in the
lowest powered sleep modes, that consume a tiny amount of battery power.

David Schultz <david.schultz@earthlink.net> writes:
>> FRAM seems almost perfect for embedded Forth on a small scale.
> http://davesrocketworks.com/electronics/msp430/eforth/index.html

Hey, that is nice. Any update about the Teensy version? The Raspberry
Pi Pico would also be a nice host for this Forth. I've been wanting
more of a "luxury" Forth for such devices though, along the lines of
Gforth-EC instead of eForth. There is plenty of code space and flash on
those boards for a bigger Forth.

On 4/13/22 3:22 PM, Paul Rubin wrote:
> David Schultz <david.schultz@earthlink.net> writes:
>>> FRAM seems almost perfect for embedded Forth on a small scale.
>> http://davesrocketworks.com/electronics/msp430/eforth/index.html
>
> Hey, that is nice. Any update about the Teensy version? The Raspberry
> Pi Pico would also be a nice host for this Forth.

http://davesrocketworks.com/electronics/logger/eforth.html

--
http://davesrocketworks.com
David Schultz

On 14/04/2022 05:53, Paul Rubin wrote:
> dxforth <dxforth@gmail.com> writes:
>> If the MSP430 is anything like Atmel's 8-bit in the way the latter eat
>> program memory then 64K starts to look underwhelming.
>
> MSP430 code density is actually pretty good. It is a 16 bit cpu with
> architecture reminiscent of the PDP-11, with autoincrement and
> autodecrement addressing modes and all that, but with 16 registers
> instead of 8. The addressing modes are quite handy for implementing
> stacks, threaded code interpreters, buffer pointers, and the like. It
> is very nice for Forth with 16 bit cells. It has lost popularity
> though, as people have moved on to 32 bit cpus.

A pity it didn't get chosen for the Arduino. Currently modifying
FlashForth such that it look/feels a bit more like DX-Forth...

On 14/04/2022 01:25, Myron Plichota wrote:
> ...
> It just so happens that my design encodes both >R R@ and DUP >R as a pair of 4-bit instructions, and both sequences execute in a total of 2 clock cycles no matter which slots they occur in.

While I expect an optimizer to handle DUP >R and >R R@ equivalently, folks tend
to write DUP >R because they're not changing TOS - just copying it. AFAIK Forth
has had an DUP>R but never an >RR@ .

I just confirmed that PFE uses ncurses. I used PFE years ago on an OpenBSD box. I'm sorry that I got it confused with gforth, but at least I now know why.

- Myron

Myron Plichota <myronplichota@gmail.com> writes:
>I'm sorry that I got it confused with gforth, but at least I now know why.

No problem, I just wondered myself what we are using. curses or
ncurses seemed unlikely, though, because we are not even using termcap
or terminfo (which are used by (n)curses); I looked at termcap and
terminfo for implementing the K-... words, but eventually decided that
they are too complicated, and that these days VT100/ANSI has won, and
we would just implement that; in the end I implemented the sequences
that come out of xterm and out of the Linux console.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

On Monday, April 4, 2022 at 11:45:42 AM UTC+10, Kip Ingram wrote:
> On Thursday, March 4, 1999 at 2:00:00 AM UTC-6, Alex Bilyk wrote:
> > Great article. Good points.
> > I have got a book on Forth dated by 1988: 153 pages. Everything is in
> > there: language, internals future ideas and examples. Simple and easy to
> > understand. And now I have been looking at the ANS documents -- what a
> > disappointment.
> > Although, I find ANS as an excellent scripting language specification. It is
> > rather resembling a language I got to know back in 1988 -- it was called
> > FORTH.
> > AB
> > he...@albany.net wrote in message <7bje9c$k7$1...@nnrp1.dejanews.com>....
> > >Jeff's article contrasts ANS Forth with what Jeff
> > >and Chuck call Machine Forth, "27 easy to learn
> > >and understand Forth opcodes that take 2ns. We
> > >took people who never learned ANSI Forth and taught
> > >them Machine Forth in an hour and had them programming
> > >an embedded wireless ethernet controller in it the
> > >next day."
> > >
> > >Most of us could spare an hour. Is there a teacher
> > >in the house?
> > >
> > >Anti Ansi Forth:
> > >
> > ><http://www.UltraTechnology.com/antiansi.htm>
> > >
> > >Leo Wong

Looks like me and Jeff are playing from the same play book, except I'm coming from the usability end as well.

In my OS design, one of the big features, was figuring out how to do everything in the best way, and concentrate on that, demoting other ways, to maximise performance and efficiency, by curbing how programmers programmed, with a bit of compromise to maintain a functional level of usability (part of this was to farm off worse programmers to lower grade work where the performance hit from them would be less, than if they did the architecture and main apps. Which are multiple levels before you get to the App level. While most code might be internet scripting these days, every internet script runs on the infrastructure code, which if bad, will make everything worse, but if good all scripts will run as well as they are written, making the grade of programmer prominent, and a target to improve programming quality which administration can see). I'm glad I didn't take up the self funded job offer from Jeff. Being in that sort of environment would have driven me around the bend (either ITV, or the one before. Though but was me who suggested the internet appliance originally on the original mailing list, which was meant to take an advantage of a weakness at that time, to establish a low resource internet usage base to develop pages before. Instead of the bat. Crazy way the internet is now. But, the period only lasted 2-4 years before co.petotion and PC's etc, took over, where you then had to maintain comparability with them, which is difficult on a low resource device. ITV only just started mid way, or till the end, of this period, making delivery years late, so never was going work out on something less than the webpad like concept level). It's a shame there was too much foolishness in the bucket in the time of forth hardware, from the beginning when the money was taken. It has been one ... After anothey, with big gaps inbeywern. Harris bid one 9f the only companies who did us well. If the novix had been a f20 like chip, with the graphics and interfaces (but still 16 bit bids with bank switching), it could have been a great choice for CE devices, an extension of the 8 bit home computer and games console market, at an undercutting price
(which is what Jack Tramiel used to best all half ass on commers), even a basic computer capable of emulating CP/M and maybe even dos. Which would have given money to further expand it to a proper security level computer architecture by the time of the 386/486. People are very short sighted (insisting they see everything they don't clearly).

I had been suggesting before, that colorforth (machine forth) could be made a subset of ANSI, to keep it alive, along with a embedded version, and simple and complex additions (I forget exactly what then was, but basically extensions to handle extra stuff on the job I think). All subsets of ANSI, so ANSI lite color, embedded, as seperate word sets). It's in the ANN: colorforth cf2022 thread.