Dan Sugalski <[EMAIL PROTECTED]> wrote: > On Sat, 25 Oct 2003, Leopold Toetsch wrote:
>> So during label fixup there are some hardwired "is this a set_addr" or >> such, and then when yes, fixup the second argument. > Ah, that makes sense. The assembler expects a real label since it can't > reasonably get an integer constant, and I'm providing an integer constant. > :) Yep, that's the problem. While we have flags stating what kind of branch operation an opcode might be, we don't have any hints, which operand might need what kind of fixup. > Sharing the constant table amongst segments seems straightforward, and I > can't think of a good reason to not do so, The main reason is eval(). Evaluating code with varying constant strings in a loop would fill up the main/global constant table and exhaust memory finally. OTOH your usage of compile is totally different, it needs a shared constant table. > ... though I can see potential > issues with safe mode code changing constants in shared segments, but > that's more an issue of preventing the change (or sharing) in a safe > environment. Changing constants? > It may be reasonable to have an appendable bytecode segment that can be > passed along to the compilation modules. As soon as you start executing code in that segment, it can't be expanded (which possibly moves it). WRT forth, the compiler could append all compiled code from C<colon>s, but before the first word is due to running, the fixups have to be done, if any, prederefed code may be produced or the segment might get JITted. > ... The compiler modules can create a > new segment if one's not passed in, or append to an existing one if it is, Not easily, as we have absolute branch addresses everywhere. Some time ago, I did propose relative addresses, which would allow appending easily, but this could slow down branches a bit. >> This also means, that there will be some restructuring of >> interpreter->code > :) If it doesn't lose us speed, I'm fine with things being rearranged. I'll try to not have another indirection and to have faster code segment switching. > Dan leo
