Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!rutgers!uwm.edu!wuarchive!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!pitt!willett!ForthNet From: ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) Newsgroups: comp.lang.forth Subject: Experimental Ideas Message-ID: <2024.UUL1.3#5129@willett.pgh.pa.us> Date: 29 Nov 90 13:00:38 GMT Organization: String, Scotch tape, and Paperclips. (in Pgh, PA) Lines: 38 Date: 11-26-90 (09:09) Number: 303 of 303 To: DENNIS RUFFER Refer#: NONE From: ELLIOTT CHAPIN Read: NO Subj: EXPERIMENTAL IDEAS Status: PUBLIC MESSAGE Conf: FORTH (58) Read Type: GENERAL (+) DR>missing something or are you working on doing something more? Perhaps DR>making the code relocatable within the 64K. That would be a good trick DR>if you can do it without too much overhead. I think LMI has something DR>like that in their As often, I am too terse - yes, within the 64K; via a location table containing the current values of CFAs. Headers live with bodies. Bodies contain location table positions where one expects CFAs of other words. This forces some execution overhead, but if the application turns out not to need the possibilities which the above construction provides the code can be converted to the normal type. The location table and some core code stay put. I'm wondering right now how to keep implementation of the creates/does process from generating non-relocatable code; I do expect to solve that problem somehow. I'm far from wizard level, and we are living on money we don't have (I'd rather be programming. Anybody want a resume?). So my system will take a while to finish, and will probably contain evidence of my comparative ignorance of the literature. Elliott Chapin --- ~ DeLuxe} #4315 ~ PCRelay:CRS -> RelayNet (tm) 4.10a14 Canada Remote Systems * Toronto, Ontario <<<>>> ----- This message came from GEnie via willett through a semi-automated process. Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp Brought to you by Super Global Mega Corp .com