Hi Tristan, There were changes made to macros.s, that include assembler directives to make the interfacing to higher level languages more transparent. These changes don't affect the structure of the dictionary words themselves. These would also work with ARM macros as well. Not sure how you want to manage these changes. These are related more to the ability to building the amForth mixed language image than affecting the amForth itself.
Best Regards, John S On Mon, Jan 12, 2026 at 10:26 AM John Sarabacha <[email protected]> wrote: > Hi amForth-ers, > Any platform that can be targeted by a cross-platform tool chain > supporting C (or other high level language) can host amForth. An example is > given below: > 1) Define a container array for amForth's volatile storage (eg variables, > stack ...) > unsigned long xu4amForth[1024]; // size storage accordingly > 2)Depends on your target platform - below is an example for CH32 - check > assembly listing > to verify where the storage was allocated > # > ----------------------------------------------------------------------------- > # Memory map for Flash and RAM > # > ----------------------------------------------------------------------------- > > .equ RamStart, 0x20000100 # Start of RAM Porting: Change this ! > .equ RamEnd, 0x20001100 # End of RAM. 20 kb. Porting: Change this ! > > .equ FlashStart, 0x00000000 # Start of Flash Porting: Change > this ! > .equ FlashEnd, 0x0000F230 # End of Flash. 62 kb. Porting: Change > this ! > 3) So far I haven't seen any register conflicts between amForth and C > routines/host assembler routines. > 4) amForth's dictionary core words, shared and platform words reside in > flash, the user defined words/variables are > being stored in the ram container in 1) above. > 5)Core (foundation) words depends on your target platform for build: use > risc-v/words for RISCV (amForth), arm/words for ARM32 (amForth) and > i386/words for > i386 (these can be borrowed from seedForth-GitHub - may have some > incompatibility here - based on deviation from > the 2012 forth standard words). On a PC there is no flash memory so the > assembler built dictionary words (core/shared) > sits in the executable image and the PC C compiler can be used to build > the executable. > 6) Platform words would need to be modified appl/.../words (amForth) - > there are not too many of them > 7) It is easier and less time consuming to let the C do the heavy lifting > (startup, initialization of peripherals, drivers, > interrupt handling, networking, file handling ...) > 8) As an example C applications can work with amForth using: > register long * x2_Reg asm ("sp"); // x2/SP RSP Return Stack Pointer > (sp is same as x2) > register long * x3_Reg asm ("gp"); // TOS Top Of Stack (gp is same > as x3) > register long * x4_Reg asm ("tp"); // tp DSP Data Stack Pointer (tp > is same as x4) > register long * x8_Reg asm ("s0"); // x8 loop index (s0 is same as > x8) > register long * x9_Reg asm ("s1"); // x9 loop limit (s1 is same as > x9) > register long * x16_Reg asm ("a6"); // x16 IP Forth VM IP register > (ITC Instruction Pointer) (a6 is same as x16)) > register long * x17_Reg asm ("a7"); // x17 W Forth VM W register > (a7 is same as x17) > x17_Reg = XT_addressArray[xt_code]; // copy xt address into amForth > VM W register > asm("Call DO_EXECUTE"); > > Appears to work but is still experimental. > > Regards, > John S > _______________________________________________ Amforth-devel mailing list for http://amforth.sf.net/ [email protected] https://lists.sourceforge.net/lists/listinfo/amforth-devel
