Hacker News Reader

Comment by cjfd | Hacker News Reader

The main problem with such a stack based language for 'serious' programming would, I think, be the lack of dynamic allocations. The stack is all nice and fine if pieces of memory only need to be preserved inside functions and their children but if memory is to be allocated for an amount of time that is determined at run time there basically does not seem to be anything to do that. Any kind of solution to this would probably be pretty convoluted.

View on HN

I wrote malloc.fth for Mitch Bradley's ForthMacs, which ended up in OpenFirmware:

https://github.com/openbios/openfirmware/blob/d5cc657ce81c0f...

    \ Forth dynamic storage managment.
    \
    \ By Don Hopkins, University of Maryland
    \ Modified by Mitch Bradley, Bradley Forthware
    \ Public Domain
    \
    \ First fit storage allocation of blocks of varying size.
    \ Blocks are prefixed with a usage flag and a length count.
    \ Free blocks are collapsed downwards during free-memory and while
    \ searching during allocate-memory.  Based on the algorithm described
    \ in Knuth's _An_Introduction_To_Data_Structures_With_Applications_,
    \ sections 5-6.2 and 5-6.3, pp. 501-511.

Forth systems running on C libraries can also call back to the native malloc/free implementation, but it's nice to have a pure FORTH implementation for embedded applications.

Fair enough, sounds like a workable solution.

GForth has a word ALLOCATE exactly for that purpose. Allocates a block on heap, returns address. Works on Windows, Linux, Android, embedded

I'm not sure I follow. The Forth stack is not like the C stack.

This can be trivially achieved by moving the dictionary pointer and reserving some space on the heap.

Reply on news.ycombinator.com