Use two separate stacks for data and control flow

(to be expanded later)

This is not just so it could run FORTH almost natively.

This is a HUGE safety and security feature.

Plus it also helps performance by separating accesses to different memory regions, while restricting access to the control flow structure (reducing the attack surface).

The call stack should be almost inaccessible to the lay program.

More than one data stack is welcome but not necessary. And another type of stack would be for error handling.

The data stacks should grow "up".

Discussions

Alvaro Barcellos wrote 02/12/2023 at 00:48

I like Forth, maybe you need know it

Are you sure? yes | no

Yann Guidon / YGDES wrote 02/12/2023 at 20:31

I don't need to know that you like it :-)

I was exposed to FORTH at age 16... 30 years ago already, though practising it was almost impossible back then. To the point I even tried to probram my own FORTH interpreter, which gave me a memorable headache. Today, even though I subscribe to several FORTH groups, even was on Zoom with Chuck, I don't think it is relevant to today's world. Still it concentrates a LOT of amazing concepts that should be revived. Just not how FORTers think or wish.

Are you sure? yes | no

Alvaro Barcellos wrote 01/13/2023 at 16:45

classics, heap grows up, stack grows down, free memory between,

HEAP ---> free memory <--- STACK

but in Forth DICTIONARY--> free memory <----DATA_STACK;<----RETURN_STACK EOM

more easy allocs

Are you sure? yes | no

Yann Guidon / YGDES wrote 01/13/2023 at 17:20

That was nice for the 16-bitters :-)

For 40 years (i286) we have much more capable and sophisticated machines with features meant to prevent certain bugs and flaws.

Somehow people still feel comfy in a glorified PDP-11...

Are you sure? yes | no

Alvaro Barcellos wrote 01/13/2023 at 16:24

and HEAP goes up !

Are you sure? yes | no

Yann Guidon / YGDES wrote 01/13/2023 at 16:31

but is accessed only by malloc().

did you notice that there is practically no code to check collision ?

Are you sure? yes | no

Alvaro Barcellos wrote 01/13/2023 at 02:15

sure not, direction is free choice. wherever, if you list many forth, almost are backwards, (fig-forth was), and GreenArray chips, by Moore, also, if i remember well.

Are you sure? yes | no

Yann Guidon / YGDES wrote 01/13/2023 at 02:41

down-going stacks are a relic of a technology dating back to half a century : in a unified memory map/space, you had the code starting at the bottom, data above it and the stack at the top of the space, going down and hopefully not overwriting the data.

Today this constraint is irrelevant. You can have as many segments or address spaces as you want.

Are you sure? yes | no

Yann Guidon / YGDES wrote 01/13/2023 at 01:27

https://hackaday.io/project/189156-a-software-stack

so there goes my attention now...

I really need this so I can make it easier to work with #Aligned Strings format !

Are you sure? yes | no

Alvaro Barcellos wrote 01/12/2023 at 15:59

Use the Forth, Lucky.

Two stacks is like two minds. And grows downwards (classics).

Are you sure? yes | no

Yann Guidon / YGDES wrote 01/13/2023 at 01:26

I don't think the direction of the stack is defined by the FORTH standard... After all there are HW implementations with the stack made with registers.

Also note that a general-purpose processor should not be tied to the idiosynchrasies of a specific language :-)

Are you sure? yes | no

Carry and borrow

Let the hardware do what it does best.

Discussions

Become a Hackaday.io Member