3 ms·
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 i
by cjfd 7y ago
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.
- _cx2w 7y agoI'm not sure I follow. The Forth stack is not like the C stack.
- DonHopkins 7y agoI wrote malloc.fth for Mitch Bradley's ForthMacs, which ended up in OpenFirmware: https://github.com/openbios/openfirmware/blob/d5cc657ce81c0f7d1857b4687766b64d75a4145d/ofw/core/ofwcore.fth#L3449 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.
- cjfd 7y agoFair enough, sounds like a workable solution.
- loa_in_ 7y agoGForth has a word ALLOCATE exactly for that purpose. Allocates a block on heap, returns address. Works on Windows, Linux, Android, embedded
- 9214 7y agoThis can be trivially achieved by moving the dictionary pointer and reserving some space on the heap.