UNBCIC@BRFAPESP.BITNET (05/06/91)
The PFA cannot be changed. For example, if we create a set of words to implement STRUCTs (RECORDs), they should leave the address of the field, an address inside PFA (maybe PFA). This address would be used for ! or @. But in the mean time, an garbage collection could ocurr, changing the PFA address, scrambling with the program. Alas, you couldn't use the PFA in any case, if PFA could change. This mean that HEAP systems, with garbage collection, couldn't be used? No. But the PFA should then be implemented as a virtual address, not a physical one. (8-DCS) Daniel C. Sobral UNBCIC@BRFAPESP.BITNET
UNBCIC@BRFAPESP.BITNET (05/08/91)
From: Jan Stout <wsbusup4@urc.tue.nl> => I think you missed the point. The point is DOES> does the >BODY at => 'compiletime', whereas it should be done at 'runtime'. => I.e.: => => : ARRAY ( n -- ) => CREATE DUP 1- , 1+ CELLS ALLOT => DOES ( -- execution token) => ; => : A@ ( ex token of an array\index -- value at index ) => SWAP >BODY TUCK @ MIN ( simple overflow check ) => 1+ CELLS + @ ; => => ( May contain typos, just hacked this together:) Sorry, but I didn't understand wether DOES> doing >BODY compile time instead of at run time should cause any problem. => => As to your suggestion of using virtual addresses, => this seems breaking code to me. PFA's have always => been @d & !d like regular addresses, so your proposal => would mean that I'd have to use VIRTUAL@ / VIRTUAL! => to obtain the extra level of indirection, not normally => needed in the @ / ! case. No. It's just like the @ / ! of Forth-83 in a computer with data alignment restrictions. If the memory is alocated dynamically, then @, instead of searching the physical address, would search and address that corresponds to the token (address) on the stack. The user just don't know that it's working this way (if he's really using the Standard). It's slower, but the implementation where DOES> have problems (and I think DOES have problems in this implementations too) is slow by default. => Jan Stout, (8-DCS) Daniel C. Sobral UNBCIC@BRFAPESP.BITNET