ForthNet@willett.UUCP (ForthNet articles from GEnie) (01/15/90)
Category 3, Topic 5
Message 27 Sun Jan 14, 1990
P.SNYDER1 at 04:27 PST
Subject: DSQRT > I need to take the square root of a number ranging from 0 -
>1,596,801,600. This isn't fast, but it's simple and it works: Single
precision:
: isqrt ( n--sqrt.of.n) \ integer square root
0 1 ( n r d) \ number, root, decrementor
begin rot over - dup 0>= ( r d n' flg)
while rot 1+ rot 2+ ( n' r' d')
repeat 2drop
; This works by subtracting consecutive odd numbers from n till n<0. Since
sums of consecutive odds equal consecutive squares, the number of
subtractions equals the square root. Here's the double precision version: :
dsqrt ( dn--root) \ dn is double, root is a single
0 0 1 0
begin 2rot 2over d- 2dup 0 0 d< not
while 2rot 1 0 d+ 2rot 2 0 d+
repeat 2drop 2drop ;
......paul
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'ForthNet@willett.UUCP (ForthNet articles from GEnie) (07/23/90)
Category 3, Topic 5
Message 32 Sat Jul 21, 1990
F.SERGEANT [Frank] at 11:36 CDT
re polyForth
DR>Its best feature is that it is about the purest Forth you can buy.
Dennis, you & I were discussing that very subject some time ago; your
(above) reply to Cindy reminded me of it.
Maybe enough time has passed that I could ask again what is it about pF
that makes it so pure? What are the 'rightest' things about it, etc?
There is no urgency about an answer. It is just an ongoing interesting
topic to me.
-- Frank
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.eduForthNet@willett.UUCP (ForthNet articles from GEnie) (07/24/90)
Category 3, Topic 5 Message 33 Mon Jul 23, 1990 D.RUFFER [Dennis] at 01:29 EDT Re: F.SERGEANT [Frank] What's so "pure" about polyFORTH? Indirect threading. Parameter fields contain definition tokens which point to code field addresses which point to code. Certainly not the most efficient, but the most universal technique across various hardware platforms. Block files. Our linear block arrangement is portable across all our platforms (with or without OS support) and our Least Recently Used buffer manager makes for very efficient use of the disk I/O path. Line editor. Our line editor follows the pattern desribed in Starting Forth and is used identically on all platforms. When we are able to add scroll locking and function key support, it is easier to use and more efficient than any other method. Threaded vocabularies. Traditionally using 8 threads, each of the 8 vocabularies are linked in a unique sequence. The vocabulary search order is implicitly defined by name making the locating of words highly deterministic. Round-robin multi-tasker. A very simple method of task support which requires minimal task switch overhead. By using a self modifying approach, a sleeping task can be passed over with a simple jump. That is all I can think of right off hand. Over the years, all Forth programmers have "improved" on these techniques with varying degrees of success. I think every Forth has roots in these techniques, and many have developed more efficient approaches. Some systems have found better ways of doing various parts, but polyFORTH is the only one I know of that contains all of these techniques in their pure form. We have also experimented with various alternatives, but we seem to always come back to the simplicity of these methods. Maybe there is a reason. DaR ----- This message came from GEnie via willett through a semi-automated process. Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu
ForthNet@willett.UUCP (ForthNet articles from GEnie) (07/28/90)
Category 3, Topic 5 Message 34 Thu Jul 26, 1990 F.SERGEANT [Frank] at 22:39 CDT Dennis, thanks for the pF info. I'd like to hear even more about it from any polyFORTH enthusiasts. Indirect threading: well, gee, I've hardly thought about it in some time, having become convinced that direct threading is best way to implement Forth on the 8088. But, maybe speed isn't everything; I'll keep it in mind. Block files: I'm pretty well in sync with you here. Line editor: Here's where I have my most doubts and questions. You really think a line editor can be efficient and pleasant? If I'm ever in Manhattan Beach I'd love to have you show me. What I'm comparing it to is my memory of the line editor in L&P's F83. However, I do have some pleasant memories of line editors: SPF on IBM mainframes and the editor on big UNIVACs. These were surprising useful. Since the editor is a major contact point between a person and the Forth, I've been of the opinion that it colors one's view of other factors. For example, some people may hate BLOCKs because of a lousy editor, but blame BLOCKs rather than properly blaming the editor. Threaded vocabularies: If I understand, the search order is determined by what the vocabularies are named - for example, they might be searched in alphabetical order, but that you don't "dynamically" change the search order. I'm happy with this idea. I've been living with (more or less) no vocabularies and it hasn't bothered me (twitch, twitch). With my control key type screen editor I don't have the problem of editor words conflicting with Forth words. Appending commas to assembler words distinguishes them from similar Forth words. I've failed to see much attraction to the idea of having hundreds (or even tens) of vocabularies. Search time? Nah - I'm using a fully hashed search. Multi-tasker: Yeah, I like that idea too. "It's so simple it has to work" as Rob Chapman might say. You can use it instead of interrupts, in many cases. It's on my list of things to add sometime. 3 Character Names: I noticed this wasn't on your list. Is it that pF is now using 31 or that you are so used to it you don't even notice it any more or ...? Now that the whole world (even cmFORTH) has gone to 31 char names, I'm still considering trying out the 3 char names one of these days. As an aside (as if all this weren't an aside!), I saw a demonstration of an Allen Test Products big thing-a-ma-jig. Maybe that was the type of thing you programmed. It was impressive. I think the price I heard was $28,000. (I think I'll build one.) It seemed to be a big tool box with florescent lighting, a light pen activated monitor, an oscilloscope type monitor, an exhaust pipe probe, manifold vacuum connection, #1 spark-plug pickup, clamp over a battery cable (ammeter I suppose), connection to the car's on-board computer, and remote thumb switch to say "continue." -- And a lot of info inside it about various car models and their specs and troubleshooting - that might be the hardest part to build! Anymore ideas on why pF is best or on what makes the perfect Forth? This is more a FORML inquiry rather than a STANDARD inquiry. -- Frank ----- This message came from GEnie via willett through a semi-automated process. Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu
ForthNet@willett.UUCP (ForthNet articles from GEnie) (07/29/90)
Category 3, Topic 5 Message 35 Sat Jul 28, 1990 D.RUFFER [Dennis] at 00:01 EDT Re: F.SERGEANT [Frank] Not to dominate this polyFORTH discussion, but I'll try to keep it short this time. Ok, maybe I can't do that either. :-) > maybe speed isn't everything It is high on the list, but other factors such as memory and robustness can sometimes be more important. I've usually found that my time is better spent on opimizing the time critical portions of the application than worrying about optimizing the overall system. > Line editors. You really have to see one done right before condeming them outright. They have their drawbacks, and I certainly don't recommend them for novices, but if you are counting keystrokes you can't beat them. Just think about it the next time you are moving the cursor down to the bottom of the screen in your favorite screen editor. Count how many times the arrow key repeats and compare that to the job of typing F followed by the string you moved the cursor to, or T to the line number. The efficiency is irrefutable, but the ergonomics leave a little to be desired. BTW do you also prefer a mouse to the keyboard? Just another efficiency compromise. :-) No offense to L&P, but their line editor s..ks! That was the first thing I re- wrote when I started using F83. I guess I am just spoiled. The editor certainly does have a big influence on the useability of a system, but no matter how good a job you do on one, people will still prefer what they are currently using. I would say that poor editors have contributed to the bad rap the block files have gotten, but screen editors can do just as bad of a job as line editors can. Wil Baden has some thoughts on this that he might be kind enough to share with us. > Threaded vocabularies. In polyFORTH, the search order is determined when you define the vocabulary name, not by the vocabulary name. I.e. HEX 0315 VOCABULARY ASSEMBLER DECIMAL defines the assembler vocabulary that searches thread 5 (assembler definitions), then thread 1 (forth defs) and finally 3 (editor). The threads are not specifically defined, but DEFINITIONS uses the first thread to put new definitions in. If you need to dynamically change the order, you need to define another vocabulary name. In other words, VOCABULARY does not define new threads, but search orders into the existing threads. In 16 bit polyFORTH, you typically can have 8 threads (only odd 4 bit numbers are used), but I've rarely had need for more. > 3 Character Names. I did not mention it because I do not consider it a "feature", but an annoyance I must deal with. IMHO they cause more problems than they are worth. However, if you only have a 64K address space then they are almost essential. If you can address more than that, I think other alternatives can be found that are much more appealing. Our polyFORTH product for MSDOS still only uses 64K, but we are experimenting with other alternatives for our large model systems. > Allen Test Product's big thing-a-ma-jig Your description could either be the Smart Scope that I wrote, or the "son of Smart Scope" the Smart Engine Analyzer (SEA). You got most of the connections right, and doing that part is relatively easy. Of course you need to worry about the 50,000 volt spikes coming out of the spark plugs, and how to store and display the signals, but that's easy compared to problem of getting the knowledge that is in their expert system. I wrote the knowledge system, but their automotive technicians supplied the knowledge. If you want to build your own, go out and buy all the service manuals you can get your hands on and start typing. When you've got it all entered, then try to debug it. :-) > what makes the perfect Forth? When anyone can redefine the language at will, can it ever be perfect? For that matter, will it ever be finished? I think not on both counts. DaR ----- This message came from GEnie via willett through a semi-automated process. Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu
dwp@willett.UUCP (Doug Philips) (07/29/90)
In <1417.UUL1.3#5129@willett.UUCP>, D.RUFFER [Dennis] writes: > > 3 Character Names. > > I did not mention it because I do not consider it a "feature", but an > annoyance I must deal with. IMHO they cause more problems than they are > worth. However, if you only have a 64K address space then they are almost > essential. If you can address more than that, I think other alternatives can > be found that are much more appealing. Our polyFORTH product for MSDOS still > only uses 64K, but we are experimenting with other alternatives for our large > model systems. Aha! So just because it was that way in the old days doesn't mean that it should be that way now? (If it was good enough for Classic Forth, its good enough for me :-) ) In another article you list some of the old methods/techniques as still being "right" today. I think I probably agree that many of Forth's ideas were/are innovations. However, I do not think that the experience gained from over 10 years of usage would fail to show any improvements. Grace Hopper likes to say: "Because it has always been done that way" is not an acceptable answer. Forth is powerful in part because it is simple. That doesn't mean that every simplicity in Forth dictated by twistedly scarce resources is powerful. Three character + length names are twisted, appropriate to certain particular circumstances, buyt are not a generally powerful idea. > > what makes the perfect Forth? > > When anyone can redefine the language at will, can it ever be perfect? For > that matter, will it ever be finished? > > I think not on both counts. DaR Is there not a perfection to adaptability? Is not Forth more flexible and more powerful than most (all?) other languages, allowing a seamless integration that spans Assembly Language and intimate control of the hardware up through the currently traditional High Level Languages' constructs? What other language will be able to accommodate so easily any new hardware and new software ideas more easily than Forth? [I could ask more questions, but I don't want to get rhetorical.] -Doug --- Preferred: willett!dwp@hobbes.cert.sei.cmu.edu OR ...!sei!willett!dwp Daily: ...!{uunet,nfsun}!willett!dwp [in a pinch: dwp@vega.fac.cs.cmu.edu]
ForthNet@willett.UUCP (ForthNet articles from GEnie) (07/31/90)
Category 3, Topic 5 Message 36 Mon Jul 30, 1990 F.SERGEANT [Frank] at 00:48 CDT THANKS to Bob Berkey, Dennis Ruffer, & Gene Lefave for your recent comments regarding polyFORTH and what's right about it and what makes a "perfect" Forth. Please, everyone, keep the comments coming. > And round-robin scheduling is a key. Robert, I assume you mean that the task accessing the block doesn't issue a PAUSE until it is safe to do so. I like (& have always liked) the round- robin, co-operative multi-tasking approach, although I haven't done much with it. Once in F83 I set up a buffered serial-input as a separate task. It worked very nicely. I've thought one of CM's ideas on multi-tasking was that instead of having a single task requiring complicated co-ordination, you have a number of simple tasks, each of which can be tested alone. So, in (this) theory, multi-tasking should make the debugging easier, but it sounds like you have experience to the contrary. > Line editors. No, no - I'm not condemning them outright - just saying I have my doubts and questions. As I said, I've had some good experiences with line editors. You can get real clever figuring out just how much to specify in a find command so you get where you want to with a minimum of typing. On the other hand, sitting on an arrow key until the cursor is on the correct line can't fairly be compared (I think) on a character-by-character-transmitted-to-the- computer basis with typing out a multi-character find command. I didn't understand what you meant about a mouse. Did you mean it was an efficiency compromise to use one or not to use one? I don't use one. I recently bought a cheap one and haven't been able to make myself connect it up. I have generally been against them (but without having used one). And, yet, they are similar (especially if they have 3 buttons on them) to the idea of a 3- key keyboard, which still intrigues me. I think a mouse requires an unnatural environment: just as vacuum is unnatural, an empty place on a desk is unnatural. I don't have one and never seem to have had one for more than a few minutes at a time. So, so far, I prefer a keyboard. Yes, the L&P line editor I disliked. I had assumed it was modeled on polyFORTH. > Threaded vocabularies. I see how they work in pF more clearly now. You have 8 (what I would call) fixed vocabularies. Then your word VOCABULARY creates a specialized & named search order for those (what you call) threads. I understand better a comment Wil made in a figgy bar. > Allen Test Product's big thing-a-ma-jig I don't mean I'm going to build one right away! That was part of my point, that the troubleshooting info, specs, etc was probably something I would never want to gather on my own. Any more thoughts? Anyone else? -- Frank ----- This message came from GEnie via willett through a semi-automated process. Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu
dwp@willett.UUCP (Doug Philips) (07/31/90)
In <1433.UUL1.3#5129@willett.UUCP>, F.SERGEANT [Frank] writes: > > > And round-robin scheduling is a key. > Robert, I assume you mean that the task accessing the block doesn't issue > a PAUSE until it is safe to do so. I like (& have always liked) the round- > robin, co-operative multi-tasking approach, although I haven't done much with > it. Once in F83 I set up a buffered serial-input as a separate task. It > worked very nicely. I've thought one of CM's ideas on multi-tasking was that > instead of having a single task requiring complicated co-ordination, you have > a number of simple tasks, each of which can be tested alone. So, in (this) > theory, multi-tasking should make the debugging easier, but it sounds like > you have experience to the contrary. This is a point which seems to go back and Forth. One looks at, say, Windows with its wimpy cooperative multitasking (one run-away process and wham, U R SCREWED) and says: YUCKO! Preemptive process swaps are much nicer, you don't have to worry about "relinquishing in enough places". Especially much much nicer where processes/tasks have their own separate address spaces so that they don't accidently interfere with each other or have to worry about preemption in bad places (external data consistency is not the point here). Of course, lightweight processes (threads as they are sometimes called) also have their uses. Either round-robin-cooperative or preemptive. Sharing address space is occasionally useful. Esp. if the OS is thread-aware, then you can do non-blocking-I/O with parallel threads (even if the kernel doesn't "really" support non-blocking-I/O) and other such interesting stuff. I suspect that the heavy-weight/light-weight debate will never be resolved simply because there are different needs that aren't easily subsumable under one or the other. I'm not suprised that Forth takes the lightweight approach, since that is easier and requires less hardware support too. One might "fake" preemptive by modifying NEXT, and adding primitives for critical sections. I'm not sure what the analogy for subroutine-threaded code is, perhaps changes to : ? -Doug --- Preferred: willett!dwp@hobbes.cert.sei.cmu.edu OR ...!sei!willett!dwp Daily: ...!{uunet,nfsun}!willett!dwp [in a pinch: dwp@vega.fac.cs.cmu.edu]
ForthNet@willett.UUCP (ForthNet articles from GEnie) (08/01/90)
Category 3, Topic 5 Message 37 Mon Jul 30, 1990 D.RUFFER [Dennis] at 22:59 EDT Re: F.SERGEANT [Frank] >> And round-robin scheduling is a key. > Robert, I assume you mean that the task accessing the block > doesn't issue a PAUSE until it is safe to do so. I guess I forgot to mention an indispensible tool that goes along with muti- tasking in polyFORTH, the words GET and RELEASE. For those who do not know what they do, GET waits until a facility is available and then "gets" it, and RELEASE lets others use the facility. Without these words, the round-robin multi-tasker becomes unworkable. No putting PAUSEs into your code is not good enough, because by definition, all I/O words force a PAUSE by default. With GET and RELEASE, you can lock a facility until you are done with it. Without these tools, a round-robin multi-tasker is just about useless. > I didn't understand what you meant about a mouse. Did you mean > it was an efficiency compromise to use one or not to use one? Mice have been subjected to many studies, but it all comes down to personal preference. I think they are just another reason to make my fingures move off their home positions on the keyboard. For selecting "bottons" they are nice, but I they are definitely inefficient in a word processor. I run under Microsoft's Windows almost all the time, but I rarely need to resort to digging out the mouse to get something done. Luckely, I'm on a PC. If I was using a Mac, I would have no choice. I can see the inefficency very clearly if I set my 386 laptop next to the Mac laptop and marvel about how much of my desk is not taken up by that added peripheral. > Yes, the L&P line editor I disliked. I had assumed it was > modeled on polyFORTH. It may have been modeled on it, to be consistent with Starting Forth, but its implementation left a lot to be desired. DaR ----- This message came from GEnie via willett through a semi-automated process. Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu
ForthNet@willett.UUCP (ForthNet articles from GEnie) (08/06/90)
Date: 08-01-90 (08:13) Number: 3596 (Echo) To: FRANK SERGEANT Refer#: 3582 From: ZAFAR ESSAK Read: NO Subj: EXPERIMENTAL IDEAS Status: PUBLIC MESSAGE Actually this message is not directed at you specifically but just an entry point to this interesting ongoing discussion. For starters, your interest in the Allen Test Products "big thing-a-ma-jig" ... is this approach a thing of the past with many newer cars having computer chips on board responsible for a number of operating characteristics? Is it possible to hook your PC to the car's computer and interogate it on its performance, maybe even tweek it a little, interactively even, without worrying about a 50,000 volt spike. What kind of port is it anyway? Serial or parallel? Robert Berkey's comments: " I still find the block and buffer structure of polyFORTH combined with it's round-robin multi-tasking environment to be somewhat amazing. With the right programming touch, it's simply not necessary to do record and file locking. I've heard database designers agonize over the enormous task of permitting large files to span disk devices. With polyFORTH that capability comes with the design, and therefore already bug free, speed optimized, etc." Now if there was a Stream I/O module on top of this efficient Block system it might attract even more interest. Letting the Stream Layer converse with the block layer to manage all the required house-keeping and giving the User the ability to view the data as multiple streams as required by their application, while still minimizing operating system calls that slow things down. As for line editors and block editors, no thanks! My thoughts never come out as chunks of fixed size, requiring physical stamina to insert a thought where it belongs, beside a related thought, with an aside if I'm in the mood. And when I need to zoom through a document the page up and down keys work fine where searching isn't appropriate. And an added bonus is all that saved space on disk so I can write more code and still do it on a portable with a disk that always too small. Zafar Essak. BC-Forth Board, Vancouver. --- * Via Qwikmail 2.01 NET/Mail : British Columbia Forth Board - Burnaby BC - (604)434-5886 ----- This message came from GEnie via willett through a semi-automated process. Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu
ForthNet@willett.UUCP (ForthNet articles from GEnie) (08/06/90)
Date: 08-01-90 (08:13) Number: 3597 (Echo) To: GARY SMITH Refer#: 3584 From: ZAFAR ESSAK Read: NO Subj: THOUGHTS ON FORTH Status: PUBLIC MESSAGE This reminds me of a conversation the other night with a chap who was talking about the extensions they have added to their Forth development environment. Some I can recall where: Parent and child definitions, allowing large procedures to be coded as a series of smaller definitions that compile as one large routine saving on resources such as code space taken up by each definition's call. Local variables with the added provision that child definitions can call on locals belonging to the parent definition and maybe other siblings. Definitions that execute a jump-through-address-with-offset, utilizing assembly opcodes native to the machine. These are some ideas borrowed from other languages or the architecture of the machine. He felt Forth was stagnating with so much effort on the primitives and so little effort on future advances. Zafar. --- * Via Qwikmail 2.01 NET/Mail : British Columbia Forth Board - Burnaby BC - (604)434-5886 ----- This message came from GEnie via willett through a semi-automated process. Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu
ForthNet@willett.UUCP (ForthNet articles from GEnie) (08/06/90)
Category 3, Topic 5 Message 40 Sat Aug 04, 1990 D.RUFFER [Dennis] at 16:03 EDT Re: ZAFAR ESSAK > the Allen Test Products "big thing-a-ma-jig" ... Yes, many of the car manufacturers are including much of the diagnostic capabilities right in the car now days. However, these "diagnostic computers" end up just making the problem of fixing the problem even more complex. The original ATP diagnostics that I developed are now only used in a last resort when the manufacturer's "fault trees" do not find the problem. Basically, what happens is that the on-board computers monitor some built-in sensors like oxygen in the tail-pipe, exhaust temp, primary voltage, battery amps/volts, etc. Then they produce codes that can direct the mechanic down a fault tree to some more specific measurements that the mechanic can take. Those measurements take him further down the fault tree until he ends up determining what part to replace (very few adjustments are made any more). The most common diagnostic, "replace the diagnostic computer". :-) > Is it possible to hook your PC to the car's computer and > interogate it on its performance, maybe even tweek it a little, > interactively even, without worrying about a 50,000 volt spike. > What kind of port is it anyway? Serial or parallel? Yes, you can! If I remember right, the connection typically is a 12 volt serial bit stream. There is usually a connector under the dash that you connect to and typically you have to short two pins together before it starts spitting data out at you. Some systems dump just codes, others include their measurements with the codes. Some of the most complex systems even accept input from the connector to modify their parameters. On the Cadalac, you have a polled system where you have to tell it which one of the 6 (or more) onboard computers you want to talk to. All in all, you have enough variations on the connection schemes that you still need a sophistocated computer to figure out how to talk to the on-board computers. The manufacturer's sell a "black box" that will talk to their systems, but ATP's machines handle almost all of them. Then, there is also the problem of all the fault trees. They have replaced the old fashoned repair manuals with fault tree proceedures. ATP has programmed them into their machines so that they can walk the tree automatically for the mechanic, telling him when to take measurements (if needed) and reporting the conclusions on a form that they can present to the customer (to justify the $1000 replacement of the diagnostic computer :-). IMHO on-board computers have just made the problem worse. DaR ----- This message came from GEnie via willett through a semi-automated process. Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (11/08/90)
Date: 10-19-90 (12:42) Number: 140 of 157 (Echo)
To: ALL Refer#: NONE
From: RON TOLER Read: HAS REPLIES
Subj: CODE & PROC 3.2+ Status: PUBLIC MESSAGE
Conf: FORTH (58) Read Type: GENERAL (+)
I'm attempting to figure out some of the details involved with
3.2 + assembler codeing using CODE and PROC statements. All I seem
to be able to do so far is to lock up my PC. I've used 3.1 assembler
previously but only for short task CODE statements with all data on
the stack and available to the CODE procedure. I could use some
pointers on two things in the 3.2+ assembler.
First: Calling PROC
.
PROC +TEST
AX, # 0001 ADD
BX, # 0000 ADC
RETF
END-PROC
.
VARIABLE TEST+ +TEST TEST+ !
.
CODE ++TEST
AX POP BX POP
TEST+ CALLFI
BX PUSH AX PUSH
NEXT,
END-CODE
.
This is my basic trial code in which I have been using as described
in a comment form 9-12-89 in using CALLFI and RETF via a variable. Is
there something majorly wrong or is there some syntax incorrect.
Debugging is impossible when all variations on a theme lock up the PC.
.
The other thing is VARIABLE access via the CODE statements.
Examples that I have also seem to access strange locations. Any help
would be greatly appreciated.
NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530
<<<>>>
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwpForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (11/08/90)
Date: 10-19-90 (18:27) Number: 143 of 157 (Echo) To: RON TOLER Refer#: 1782 From: RAY DUNCAN Read: NO Subj: CODE & PROC 3.2+ Status: PUBLIC MESSAGE Conf: FORTH (58) Read Type: GENERAL (+) Major things wrong here. The address of the variable you are using is a Forth logical address, but you really need a segment and offset for JMPFI. Use ADDR>S&O to convert the logical address to a segment and offset, put the latter in the variable, then use JMPFI. There are many other subtle features of CODE and PROC definitions related to the contents of the segment registers, the mapping of logical to physical addresses, and so on. NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530 <<<>>> ----- This message came from GEnie via willett through a semi-automated process. Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (11/22/90)
Date: 11-19-90 (13:00) Number: 241 of 242 To: ALL Refer#: NONE From: ELLIOTT CHAPIN Read: (N/A) Subj: relocatable code Status: PUBLIC MESSAGE Conf: FORTH (58) Read Type: GENERAL (+) Are there any single-segment 8086 Forths with relocatable compiled code? I've started to write one and will post to GEnie if there's call for it. 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
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (11/25/90)
Category 3, Topic 5 Message 50 Fri Nov 23, 1990 D.RUFFER [Dennis] at 01:50 EST Re: ELLIOTT CHAPIN > Are there any single-segment 8086 Forths with relocatable compiled > code? I've started to write one and will post to GEnie if there's > call for it. Elliott, how do you mean "relocatable"? If you are only in one segment, and you do something at powerup to adjust this segment pointer to where you are currently (as every Forth must do), isn't that relocatable? I think almost all of the 64K Forth's we have in the library do at least this much. Am I missing something or are you working on doing something more? Perhaps making the code relocatable within the 64K. That would be a good trick if you can do it without too much overhead. I think LMI has something like that in their binary overlay support. If I remember right, they do the re-linking when the module is loaded in, but I never did investigate it much. Tell us more about what you are doing. DaR ----- This message came from GEnie via willett through a semi-automated process. Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (11/29/90)
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
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (11/29/90)
Category 3, Topic 5 Message 52 Thu Nov 29, 1990 D.RUFFER [Dennis] at 00:50 EST Re: ELLIOTT CHAPIN Ah, you are making a "Token Threaded" Forth. You have a "token" table where every execution address can be relocated without changing the actual object code. I've played with the concept myself, in a previous job. It does add a level of overhead, but opens up a whole new world of flexibility. I used the technique to bank switch PROMed overlays in and out of an application that I put together. They are still using it today (I think). With the CREATE/DOES> words, just think about the DOES> as a completely new definition. Give it its own token table entry. The ;CODE version (if you have them) is pretty much just like your normal primative. Your DOES> versions can be treated just like any other high level definition (it just doesn't really have a head and is not executed until the defined word is executed). Basically, the CREATE/DOES> word creates a new class of CFA for your table. I'd love to see what you come up with, whenever you decide you happy enough with it to let someone else look at it. DaR ----- This message came from GEnie via willett through a semi-automated process. Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (12/03/90)
Date: 11-30-90 (17:16) Number: 331 of 331 To: DENNIS RUFFER Refer#: 316 From: ELLIOTT CHAPIN Read: NO Subj: EXPERIMENTAL IDEAS Status: PUBLIC MESSAGE Conf: FORTH (58) Read Type: GENERAL (+) Token Threaded Forth, eh? Thanks for the encouragement. I was on the verge a solution for CREATE/DOES> similar to the one you mentioned when I got your message. I am likely to do the same kind of thing with branching. 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