Re: 41->71 Translator and the FTH41ROM LEX file
Message #5 Posted by Ex-PPC member on 27 Feb 2003, 4:59 a.m.,
in response to message #3 by Gene
Gene wrote:
"You say that it would take "assembly" techniques. Do you have any ideas or have you been able to do this?"
Nothing is impossible using the right techniques and given sufficient time and effort, but regrettably I think making the Forth ROM run in RAM in exceedingly difficult.
The problem is this: the Forth ROM consists actually of two parts, a soft-configured ROM, that holds the Text Editor, the supporting LEX keywords for the editor and other ancillary LEX files, and a hard-configured ROM that holds the FORTH system and the Assembler.
For efficiency sake, FORTH needs to have its basic dictionary words at fixed addresses, while simultaneously
trying to coexist with the native 71B operating system, that uses to configure everything at variable addresses. The FORTH development team solved the problem by convincing the BASIC developers to include some extra coding to help them achive their goals, namely that whenever the system starts, if it detects a hard-configured ROM at E0000, it reserves 64 Kbytes (from E0000 to EFFFF) for its use, avoiding configuring anything else in that address range.
FORTH is thus written and configured to always run from E0000 onwards. Further, it must ensure that the user words also start at fixed addresses, and it does this by forcing the FORTHRAM file to be the first one in the file chain, and intercepting the configuration poll to compute the size of the variable-length system buffers which precede it, in order to pad them with enough bytes to always make FORTHRAM start at a fixed address as well.
What are we to do then, in order to run FORTH from RAM ? Well, for once we would need to place it exactly at E0000. This is next to impossible to do, as you would need to have so much RAM allocated, and you would need to 'soft-configure' that address space yourself, because the operating system will be done with the configuration by the time your LEX file can take control, and may have allocated those addresses for RAM, ROM, or other purposes.
The other remaining possibility would be to write a 'relocator' LEX file or program that would change all addresses in the FORTH system to their new values, based on
where in the address space resides the FORTH ROM file. But this is unworkable, because you would need a listing of the many hundreds or thousands of fixed addresses that need retouching, plus many of them might be calculated on the fly, so you would need to change the code to recompute them as well. This would be extremely hard work, would require a very detailed, commented listing of the whole FORTH system, and a single mistake or omission would mean disaster.
Also, even if you would do it, the FORTH ROM file would not be the first file in RAM (that will always be the FORTHRAM file), so as the FORTHRAM file grows or shrinks, the FORTH ROM file is bound to move in memory, and the 'relocator' LEX file would need to answer the appropriate POLL to relocate everything again 'on the fly'. Needless to say, this would slow the system to the point of absolute unusability, thus negating the main advantage of FORTH over BASIC, i.e.: speed. The only way to solve this would be for the FORTH system to reside in some suitable IRAM, so that its address would be more easily computable.
There may be other ways, but the mere fact that any LEX file or procedure you could write will only get control after the main system configuration has run and allocated everything makes the task next to insurmountable.
|
Go back to the main exhibit hall