-
Notifications
You must be signed in to change notification settings - Fork 1
Updates for the StrongARM
The Acorn RISC PC had the option to use a StrongARM processor from DEC; these ran at over 200Mhz. The memory bus in a RISC PC ran at 16Mhz. So the reason the StrongARM was fast in a RISC PC was due to its fast cache.
To run on these and more modern systems the FORTH compiler has to update the cache every time a word is added. There is a RISC OS swi to synchronize the cache.
Originally I just used the option to synchronize the cache globally.
Recently with large memory sizes it has become important not to sync the whole of memory.
Remember that the function is called for every new word created.
Its not a problem interactively; but has a serious impact when recompiling the kernel.
The OS call takes a region of memory
\ sync the last few pages
code syncCode
ldr r0, dp
mov r1, # 0
begin
tst r0, # 3
0<> while
strb r1, [ r0 ], # 1
repeat
mov r2, r0
sub r1, r0, # 8192
mov r0, # 1
swi " OS_SynchroniseCodeAreas"
next c;
This function gets called whenever new words are added.
Remember that in FORTH every word; including variables and constants also contain executable code. So the FORTH dictionary classically contains both code and data; it is not segregated into sections as you would have with a C compiler.
Since FORTH words are small the function only needs to synch the code from the dictionary pointer backwards for around 8k to work without problems.
If you do need to use large data structures; it is recommended to keep them as data and allocate memory from the heap for them; rather than allot-ing them space in the dictionary.
RPCEmu is an emulator; and has no need to synch the cache at all. Neither do the classic Archimedes systems.
The change to select the small recent region results in a speed increase for fload meta. On the PI400 rebuilding the kernel went from 00.06.090 to 00.00.07 (from six seconds to essentially instant.)