Files on-line
ForthNet articles from GEnie
Message 120 Sat Jan 18, 1992
GARY-S at 05:59 EST
[ If you would like a copy of any of these files, drop me a note at
one of the addresses at the end of this message. Binary files are
UUencoded. In order for me to answer your request, you MUST:
Include the line containing the file name. (so I know what you want.)
Include your email address in the _body_ of the message.
You _must_ include an address *relative to* the InterNet.
-Doug Philips]
Number: 2569 Name: BAILEY.TXT
Address: GARY-S Date: 920117
Approximate # of bytes: 19968
Number of Accesses: 1 Library: 1
Description:
Transcript (text) of a GEnie Forth RoundTable Conference 16 January 1992
with Greg Bailey of Athena programming and member of the X3J14 ANS Forth
Technical Committee.
Greg's topic: " The Costs and Benefits of Adopting ANS Forth"
This is a MUST read for any Forth futurist.
Keywords:
CONFERENCE,GUEST,FIGGY,TEXT,GREG,BAILEY,COST,BENEFIT,ADOPTING,ANS,FORTH
---------
-----
This message came from GEnie via willett. You *cannot* reply to the author
using e-mail. Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, etc.).
Report problems to: d...@willett.pgh.pa.us _or_ {pitt,sei}!willett!dwp
ForthNet articles from GEnie
Message 121 Sun Jan 19, 1992
GARY-S at 06:02 EST
[ If you would like a copy of any of these files, drop me a note at
one of the addresses at the end of this message. Binary files are
UUencoded. In order for me to answer your request, you MUST:
Include the line containing the file name. (so I know what you want.)
Include your email address in the _body_ of the message.
You _must_ include an address *relative to* the InterNet.
-Doug Philips]
Number: 2571 Name: BESTOF02.92
Address: GARY-S Date: 920118
Approximate # of bytes: 20736
Number of Accesses: 1 Library: 1
Description:
Best of GEnie column for 'Forth Dimensions' targeted for the month of
Febraury 1992. It is primarily a capture of Category 3, Topic 26, Minimal
Forths (with performance).
Keywords: BEST,OF,GENIE,FORTH,DIMENSIONS,MINIMAL,FORTHS,WITH,PERFORMANCE
ForthNet articles from GEnie
Message 122 Thu Jan 23, 1992
GARY-S at 06:00 EST
[ If you would like a copy of any of these files via email, send email
to 'fn...@willett.pgh.pa.us'. Binary files are UUencoded and split
before mailing. In the body of your message, include the lines:
send NAME-of-file-you-want
path your-Internet-relative-email-path
Note: each file you want must have its own 'send' command.
the path in the path command _MUST_ be Internet-relative.
Despite appearances, us...@host.uucp and us...@host.bitnet are
_not_ Internet relative paths. See your sysadmin if you need help.
]
[This file was recently posted to comp.lang.forth. Please check old
articles for it before requesting an email copy. -Doug Philips]
Number: 2572 Name: EFI386.ARC
Address: GARY-S Date: 920122
Approximate # of bytes: 26112
Number of Accesses: 1 Library: 4
Description:
32 bit eForth for dos as posted to UseNet comp.lang.forth by
author. Created using a djp port of Gnu C to the i386.
Keywords: 32,bit,eForth,djp,Gnu,C,i386
ForthNet articles from GEnie
Message 123 Fri Jan 24, 1992
D.RUFFER [Dennis] at 23:14 EST
>>> New File <<<
No. File Name Type Address YYMMDD Bytes Accesses Lib
2573 NASTG.EXE X V.LYONS 920123 79104 1 6
Desc: It's Not another Star Trek Game
This game was written by a friend who has limited resources in hardware and
unlimedted resources in imagination. ( On a laptop in Central America). It is
written in forth, It's NOT another Star Trek Game, well it's something of a
pseudo adventure not another Star Trek Game. Uploaded here at the request of
the author.
Keywords: Game, forth, adventure, CGA, LCD
[ If you would like a copy of any of these files via email, send email
to 'fn...@willett.pgh.pa.us'. Binary files are UUencoded and split
before mailing. In the body of your message, include the lines:
send Name-of-file-you-want
path Your-Internet-relative-email-path
Note: each file you want must have its own 'send' command.
the path in the path command _MUST_ be Internet-relative.
Despite appearances, us...@host.uucp and us...@host.bitnet are
_not_ Internet relative paths. See your sysadmin if you need help.
]
ForthNet articles from GEnie
Message 124 Sat Jan 25, 1992
D.RUFFER [Dennis] at 02:20 EST
>>> New File <<<
No. File Name Type Address YYMMDD Bytes Accesses Lib
2574 ALADDBF.ARC X D.RUFFER 920125 74240 1 1
Desc: File directory in Aladdin format
This is the latest file directory in PC Aladdin format. For those
of you who are using Aladdin for the PC, this file can be
substituted for your existing database files and you will then have
an up to date list with accurate download counts (as of the time
this was taken) and no missing or deleted files. Extract these
files to your Aladdin directory and your existing DBF and IDX files
will be updated. You will need to delete and FMK file that may
already exist and change these file names if you changed Aladdin's
defaults.
Keywords: ALADDIN, DBF, DATA BASE, FILES, DIRECTORY, LIST
Mitch Bradley
> assignments'', it seems to me some clarification is needed.
I was the culprit who came up with the list of THROW codes, so I'll
try to explain this. First of all, the way that I came up with the
list was by reading through the document and writing down everything
it said about ambiguities and errors.
> Let us take code -25 : return stack imbalance.
> My main question is: which ANS Forth words will set up a CATCH
> with the defined codes? (compiler? interpreter? LOOP ?)
There is no requirement that an ANS Forth system must check for such
error conditions and perform the THROW . One legal system response
to an ambiguous condition is to ignore it and continue.
The intention is that ANS Forth words do not set up a "preemptive CATCH".
By "preemptive CATCH", I mean a CATCH without a following THROW of the
same error code. I believe this is implied by the document because
words do not say anything about CATCHing.
The exception to this is QUIT ; the description of THROW says that, in
the absence of explicitly-installed CATCH handlers, the behavior is
like ABORT which eventually does the function of QUIT . An implementation
of QUIT could do a "preemptive CATCH" and still be within the standard.
This isn't surprising; a program that calls QUIT cannot expect to ever
regain control anyway.
A valid "non-preemptive CATCH" would be, for example, INCLUDE-FILE .
It could set up a CATCH , and if a THROW occurred, it would close the
open file and re-THROW the error code. From an external point of view,
you would have know way of knowing that the THROW was intercepted.
"Return stack imbalance" was intended to mean explicit imbalanced use of
>R and R> . That's the ambiguous condition that I was looking at when
I wrote the phrase "return stack imbalance".
> A related question is best put as an example. Assume a very
> safe system has run-time checking for DO LOOP's. What happens with:
>
> : test 10 0 DO CR I . UNLOOP ( no EXIT ) I . LOOP ; test
>
> (Note we also have code -26 : loop parameters unavailable)
I would call that "loop parameters unavailable".
I think it would be overkill to specify precisely exactly which error
codes are thrown in exactly which circumstances. Forth implementations
are just too varied for that. The main use for these codes will probably
be to print out (presumably informative) messages, or in some very
specific cases, to "bulletproof" applications. However, many of these
conditions (e.g. loop parameters unavailable) are indicative of serious
programming errors that may have compromised the system integrity, so
full "bulletproofing" is probably not possible in most likely Forth
implementations.
Mitch
Bernd Paysan
In article <3898.UUL1.3#51...@willett.pgh.pa.us>, Fort...@willett.pgh.pa.us (ForthNet articles from GEnie) writes:
|> Category 3, Topic 16
|> Message 84 Fri Jul 17, 1992
|> E.RATHER [Elizabeth] at 00:01 EDT
|>
|> In our experience w/ "funny chips" the way to really get performance out of a
|> strange architecture is to design the Forth machine to take as much advantage
|> of the architecture as possible internally. For example, on the i860 we use a
|> modified dtc in which the 1st instruction of the "jumped to" code actually
|> follows the jump in the calling def, because the pipelining enables that
|> instruction to be executed "for free" during the jump. It's unclear whether
|> writing the code in C as Ertl has done can facilitate that type of
|> optimization.
At least the code for HP-PA doesn't, but it doesn't run, either :-(. It compiles
NEXT DTC as
ldws,ma 4(0,%r20),%r19
bv 0(%r19)
nop
and adds a nop to the pipeline. The SPARC code added the increment of the pointer
in the branch delay, but I don't have it here now, so I can't post it. The
ldws,ma increments the pointer, so nothing was found to fit into the pipeline
(and I can't find anything by hand, too). The NEXT ITC is quite the same:
ldws,ma 4(0,%r20),%r19
ldw 0(0,%r19),%r19
bv 0(%r19)
nop
The reason, why the code doesn't run is not the code, it seems that the linker
has problems with calculating the addresses.
--
Bernd Paysan
"Keep it stupid simple!"
Anton Martin Ertl
What you don't see is the delay slots between the load and the use of
the loaded value in the next instruction. However, in a real forth
primitive these delay slots will be filled (and the nop after the
branch will be replaced) with other instructions (for computing and
stack manipulation). This is done automatically by the C compiler.
There is one possible optimization that I don't know how to express in
GNU C. You can draw the load of the next execution token into the
previous primitive, where it can fill the branch delay slot, i.e.:
NEXT DTC
bv 0(%r19)
ldws,ma 4(0,%r20),%r19
This would reduce cache miss sensitivity and may reduce delay slots in
some primitives. On the other hand, loading the next instruction
will be wasted effort in at least 25% of the executed instructions
(CALL and EXIT), so this "optimization" may backfire. It probably will
pay off in processors of the next generation, which have many delay
slots. So perhaps GNU C will give us another extension for expressing
such things.
- anton
--
M. Anton Ertl Some things have to be seen to be believed
an...@mips.complang.tuwien.ac.at Most things have to be believed to be seen