HDTenEightyP/NetNews huggingface dataset:
From: ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: Help for F-PC and TCOM
Date: 6 Oct 92 11:46:35 GMT
Organization: EIEI-U

Category 7,  Topic 35
Message 26        Mon Oct 05, 1992
ELLIOTT.C                    at 14:17 EDT
 
 -----via CRS Premium Bulletin Board - USR Dual Standard 16.8K
 (416) 629-7000 Date: 10-01-92 (23:27)
   To: ALL
 From: TIMOTHY TRUSSELL
 Subj: INT 21H Function 48H Help

 I am presently attempting to do some windowing functions using
 the FPC system.  Due to the necessity of keeping the data
 segment free for the application program to be written, I find
 it advantageous to try to allocate an additional segment from
 the DOS memory pool by using the Allocate Memory function (48H)
 of DOS interrupt 21H.

 I have, however, run into problems with multiple compilations of
 the code.  The Allocate/De-Allocate routines work fine the FIRST
 time, but after that, the system locks up (for no reason I can
 at present find).

 I am hoping that someone out there has had some experience with
 this operation, and could spread the wisdom.  Thanks in advance.

 Tim.

 If the new system allows, please route to ECTECH.

 PCRelay:ECTECH -> #687 RelayNet (tm) 4.11              *ECTECH
 BBS*WILDCAT! PRO ALPHA*(714)780-5672*  

-----
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: dwp@willett.pgh.pa.us
Newsgroups: comp.lang.forth
From: jmeri@cs.joensuu.fi (Juha Meriluoto)
Subject: Re: TCJ ( The Computer Journal)
Organization: University of Joensuu
Date: Wed, 30 Sep 1992 10:51:52 GMT

mentink@wronz.org.nz writes:
>	
>	Can anyone tell me an address for TCJ ( The Computer Journal).
>	I would like to subsribe to it, but need address and info on
>	costing etc ...

I'd like very much to have their address, too.

******************************************************************************
Juha Meriluoto    e-mail:   jmeri@cs.joensuu.fi
                  letters:  Nuottaniementie 16 A 9  80140 JOENSUU  FINLAND
                  phone:    +358-49-379040 
  --------
"Well, I mean, yes idealism, yes the dignity of pure research, yes the 
pursuit of truth in all its forms, but there comes a point I'm afraid where 
you begin to suspect that if there's any real truth, it's that the entire 
multidimensional infinity of the Universe is almost certainly being run by 
a bunch of maniacs..." 
                       - Douglas Adams:  The Hitch Hiker's Guide to the Galaxy
******************************************************************************
-- 
******************************************************************************
Juha Meriluoto    e-mail:   jmeri@cs.joensuu.fi
                  letters:  Nuottaniementie 16 A 9  80140 JOENSUU  FINLAND
                  phone:    +358-49-379040 
Newsgroups: comp.lang.forth
From: mikeh@starnine.com (Mike Haas)
Subject: Optimizing Forth
Date: Tue, 29 Sep 1992 22:34:09 GMT
Organization: StarNine Technologies, Inc.

Damn!  I was saving a post where someone was asking about
"can you optimize a Forth compiler?", and finally brought this
data in to where I could post it, and that message seems to have
expired in my database.

Oh, well... here it is... the kind of stuff that compiler hacks
should get a real kick out of.  Next time someone asks if a Forth
compiler can be optimized, show 'em this...

----------------------------------------------------
I loaded JForth's optional optimizing compiler and
logged EMIT to a file, then typed in the
following illustrative definitions.

Right after the definition, I used JForth's DEF command to
disassemble the code that was created.  It all showed up
in the log-file.

JForth output...

  ok
: 1+1+1+  ( n1 n2 n3 -- n1+1 n2+1 n3+1 ) 
  rot 1+ rot 1+ rot 1+ ;  ok
  ok
  ok
def 1+1+1+ 
 2D78C  move.l  (dsp)+,d1                   221E            ""."
 2D78E  move.l  (dsp)+,d2                   241E            "$."
 2D790  addq.l  #$1,d2                      5282            "R."
 2D792  addq.l  #$1,d1                      5281            "R."
 2D794  addq.l  #$1,tos                     5287            "R."
 2D796  move.l  d2,-(dsp)                   2D02            "-."
 2D798  move.l  d1,-(dsp)                   2D01            "-."
 2D79A  rts                                 4E75            "Nu"

1+1+1+ is 16 bytes long (4 cells), defined as 'called'

  ok
: foo  rot swap over 2* + + + ;  ok
  ok
def foo 
 2D752  move.l  (dsp)+,d1                   221E            ""."
 2D754  move.l  (dsp)+,d2                   241E            "$."
 2D756  move.l  d2,d3                       2602            "&."
 2D758  add.l   d3,d3                       D683            "V."
 2D75A  add.l   tos,d3                      D687            "V."
 2D75C  add.l   d2,d3                       D682            "V."
 2D75E  add.l   d1,d3                       D681            "V."
 2D760  move.l  d3,tos                      2E03            ".."
 2D762  rts                                 4E75            "Nu"

FOO is 18 bytes long (4 cells), defined as 'called'

  ok
logend 


To make sense of JForth disassembly, you need to know 2 things:

1. the Top-Of-Stack is cached in D7 (labeled 'tos' by the
   disassembler).
   
2. the rest of the stack's out in memory,  pointed to by A6, or
   'dsp'  (short for data-stack-ptr).  'dsp' actually points to
   the second item, due to the cached top-of-stack.
From: mikeh@kralizec.zeta.org.au (Michael Hore)
Newsgroups: comp.lang.forth
Subject: Re: An Open ANSI Forth Implementation
Date: 30 Sep 92 11:19:43 GMT
Organization: Kralizec Dialup Unix Sydney: +61-2-837-1183 V.32


Anton Martin Ertl writes:

>We have also a lot of ideas about the system architecture. One of them
>is the question of whether to have indirect threaded code or allow
>both direct or indirect threaded systems. What do you think ... ?

Also consider native code.  You'll get a very useful speed gain.
The disadvantage is that it makes the compiler more complicated, in
that you need a non-trivial code generator, which furthermore needs
to be customized to each host machine.

I should qualify that remark by saying that the amount of extra work
really depends on how much you want to optimize.  A straight subroutine 
threaded system is just as simple as ITC or DTC, so I guess you could
start that way and progressively add optimization.  But to really get
the speed payoff you would need some optimization.

But at least consider this option.  It's just as easy to comply with
dpANS with a NC system as with ITC or DTC -- this was obviously given
a lot of thought by the TC.

BTW -- have you got dpANS-3 yet?  It would be better for you to be
using this rather than BASIS 15.

Cheers,  Mike.     
------------------------------------------------------------------------
Mike Hore      internet:    mikeh@kralizec.zeta.org.au
"Wisdom has never been known to enter the head through an open mouth"
-- overheard somewhere.
Newsgroups: comp.lang.forth
From: mikeh@starnine.com (Mike Haas)
Subject: Re: Cross Compilers
Date: Thu, 1 Oct 1992 22:41:42 GMT
Organization: StarNine Technologies, Inc.

In article <4082.UUL1.3#5129@willett.pgh.pa.us> ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) writes:
>Category 3,  Topic 39
>Message 4         Sun Sep 27, 1992
>B.RODRIGUEZ2 [Brad]          at 09:04 EDT
> 
>Mike, I also thank you for your fine explanation of CLONE.  This is quite an
>elegant concept.  BTW, I believe that in addition to you and Mitch Bradley,
>Sergei Baranoff has developed such a facility.

This is super.  Which Forth does that run under?

>Let me point out, however, that CLONE serves the function I have been calling
>"recompiler," and is not a true cross-compiler.  Your CLONE cannot produce
>code for a different CPU.  This is not a criticism -- 9 out of 10 Forth
>programmers need nothing more! -- but simply an observation that the problems
>of cross-compilers are still with us.

Yes, it is native code only.  The problems with cross-compilers are still
with us.
>
>I recall reading some comments by Mitch on the subject of addresses vs. data,
>and I quite agree that this is an architectural weaknesss. I've run into this
>one myself.  I wish someone would propose a clean and complete solution to
>this problem, so that I could try it out. (I think Mitch did so, but, alas,
>I've lost the original posting.)

I remember Mitch and I doing very similar things.  I implemented
ALITERAL, which works like LITERAL, but 'marks' the compiled entity
in host-specific fashion so that CLONE can later tell it is an address
and not data.  Of course, words like ' are designed to build
an ALITERAL.

About the only other requirement is that data areas which DO hold
addresses (like vector arrays, or pointers to data structures, etc)
MUST BE RUN-TIME INITIALIZED by the program when it starts up.

>
>> Is there such a cross-compiler that does not require some
> > 'tweaking' of the code?  I've never seen one.
>
>Depends on what you mean by 'tweaking.'  Stephen Pelc is either too modest, or
>inhibited by Internet restrictions, so let me mention that his MPE cross-
>compiler let me move Forth definitions from resident compilation to cross-
>compilation with NO changes.  None. Zero.

That's what I mean by no tweaking!

>This includes defining words and
>CODE words.  I can also directly fiddle areas in the compiled image with @ and
>! .
>
>(Caveats: some care is necessary in the use of defining words; this is well
>documented in the manual, and so far has not resulted in my having to change
>any code.  I believe new IMMEDIATE words may require some special treatment,
>but so far I haven't used any. There was an artifact in creating assembler
>subroutines -- not CODE words -- that required a slightly different syntax
>between the two environments, but I'm told this has been fixed in the latest
>release.)

This is all excellent stuff, indicative of the hi-quality tools that
Forth needs to demand in in's function-set for success.

This sounds like a great job, Stephen Pelc.

>
>It _can_ be done.

Well, sure.  It IS Forth, no?  It just takes folks that want to
take the time to do it right.
From: ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: polyFORTH and other Forth Inc. products
Date: 6 Oct 92 11:46:32 GMT
Organization: EIEI-U

Category 7,  Topic 7
Message 18        Mon Oct 05, 1992
ELLIOTT.C                    at 14:18 EDT
 
 -----via CRS Premium Bulletin Board - USR Dual Standard 16.8K
 (416) 629-7000
 Date: 10-03-92 (18:00)
   To: B.RODRIGUEZ2 [BRAD]
 From: RAY DUNCAN
 Subj: WHAT SHOULD THE STANDARD

 I was not aware that "target compiler" is a trademark of Forth
 Inc.  I have been seeing this used as a generic term in the
 Forth literature for years.  I wonder if Elizabeth would care to
 comment on whether FORTH Inc. still regards this as a protected
 term?
 ---
  * The GrapeVine/Ferret Face BBS * NLR,ARK * 501-753-8121 DS *
  * PostLink(tm) v1.02  GRAPEVINE (#318) : RelayNet(tm) Hub

 PCRelay:RUNNINGA -> #2 RelayNet (tm)
 4.11                The Running Board * 301 229-5342 * MD


-----
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: dwp@willett.pgh.pa.us
From: ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: An Open ANSI Forth Implementation
Date: 6 Oct 92 11:46:37 GMT
Organization: EIEI-U

Category 10,  Topic 41
Message 93        Mon Oct 05, 1992
ELLIOTT.C                    at 14:17 EDT
 
 -----via CRS Premium Bulletin Board - USR Dual Standard 16.8K
 (416) 629-7000
 Date: 10-03-92 (10:00)
   To: ELIZABETH RATHER
 From: MARCEL HENDRIX
 Subj: AN OPEN ANSI FORTH IMPLEM

 er> Anton Ertl writes... >Well, I have implemented most of the
 er> primitives of BASIS 15....

 er> AARRRGGGHHH!!! Almost two calendar years and probably that
 many
 er> person-years of work beyond BASIS15.
 er> (...)  Watch out...there are some significant
 er> differences between BASIS15 and dpANS3.

 Please cool down Elizabeth :-) There really ARE people tracking
 ANS with their implementations. We finally succeeded ordering
 dpANS3 last week (Of course, we received the changed sections a
 few months ago).  For the prices Global Engineering asks (about
 $150, all costs added), I hope not too many revisions follow...

 Did you change anything in the latest (August) session? I'd
 appreciate a summary of the public comments and intended
 actions.


 Marcel Hendrix

 Dutch Forth Workshop   |  "It never affected ANY of my

 (Tx,ix86,TMS,68K)      |  applications"  C.M.Moore

 NET/Mail : FS FORTH Systeme BBS West Germany ++49 7667 556
 ---
  * The GrapeVine/Ferret Face BBS * NLR,ARK * 501-753-8121 DS *
  * PostLink(tm) v1.02  GRAPEVINE (#318) : RelayNet(tm) Hub

 PCRelay:RUNNINGA -> #2 RelayNet (tm)
 4.11                The Running Board * 301 229-5342 * MD


-----
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: dwp@willett.pgh.pa.us
From: ahaley@eoe.co.uk (Andrew Haley)
Newsgroups: comp.lang.forth
Subject: Re: Floating Point
Date: 28 Sep 92 09:35:25 GMT
Organization: EO Europe Limited, Cambridge, UK
X-Newsreader: TIN [version 1.1 PL6]

I don't think that there is any real possibility of myself and Mike
Haas coming to any agreement about the use of locals in floating
point, and I certainly don't want to participate in a flame war.

However, I find it easier to understand code which doesn't use lots of
named temporaries.  I would rather avoid them when possible, and
mixing floats and ints on the stack makes it hard to do this.  Most
existing FP implementations use a separate stack because it makes life
easier.  I am not opposed to a standard syntax for locals; if there
was one, I might use them from time to time.

I only want to have the choice, and I don't want to see a standard
adopted which breaks _my_ existing practice any more than I want
someone else's code broken.  Some people seem to think that various
features such as locals are more "modern" than the usual Forth
features.  These features were common in other languages when Forth
was designed, and it was decided not to include them.

Andrew.
Newsgroups: comp.lang.forth
From: spelk@cix.compulink.co.uk (MPE Ltd)
Subject: Forth engines / Harris
Reply-To: spelk@cix.compulink.co.uk
Date: Fri, 2 Oct 1992 23:36:02 +0000

>E.RATHER [Elizabeth] writes
>Harris discontinued active promotion of the RTX due to high-level
>corporate indigestion following acquisition of a GE subsidiary the
>previous year.  That is, the decision didn't involve the project
>itself, but a need to discontinue most cash-intensive operations
>which that promised to be for another year or two. At the time
>of its death it was ahead of most of its projections. Harris did
>promise its high-volume customers to continue to make parts so long
>as orders came in (I think >10,000), and have kept the cell in its
>library for custom deals and rad-hard applications.

Let me expand this a little. Harris acquired GE, RCA, and Intersil;
and the merger required more effort and cash than Harris had. A
consequence of this was that Harris retrenched to core business -
analogue, power, and military/aerospace products.

Harris have not cut production of the RTX. They cut DEVELOPMENT of
ALL NEW DIGITAL PRODUCTS. In fact the RTX development survived longer
than other digital lines.

After the development team was cut, Harris issued a statement that
they would produce the chips as long as they are profitable, and that
there will be six months notice if production is to be stopped. This
will give time for cutomers to make a one-time purchase of their
future needs. After my experiences with TI and Motorola, the Harris
position is no different to that that of any other semiconductor
manufacturer, they are just admitting it.

You can purchase RTX parts in small quantities or large. Since Harris
are not revealing the sales volume of the RTX chips, it is difficult
to predict its actual lifetime. For a chip with no publicity and
no marketing effort, it is surviving better than expected. The
rad-hard version, the RTX-2010RH, seems to be doing quite well. This
having been said, the performance of the parts is unlikely to be
improved over time.

I didn't intend this to sound like a party political broadcast, it is
just that Harris have not been well reported here, and I would hate
to see RTX sales damaged by misrepresentation. This is one of those
classic scenarios where a rumour causes collective panic (hysteria)
that produces the effect of the initial rumour.

(exits making remarks about currency speculators ...)

Stephen Pelc
Newsgroups: comp.lang.forth
From: spelk@cix.compulink.co.uk (MPE Ltd)
Subject: Forth in the marketplace
Reply-To: spelk@cix.compulink.co.uk
Date: Fri, 2 Oct 1992 23:36:10 +0000

Elizabeth Rather writes:
>But it is a serious mistake to focus, as so many do, on comparative
>speeds of languages, and quote Sieves, etc.  In the real world, what
>makes an _application_ run fast or slow has very little to do with
>the language its written in and much more to do with issues like OS
>I/O performance and overall program design.

Oh so true. But in my world there are two common objections to
Forth from experienced high level language programmers. The first is
that Forth is interpreted so it must be slow. The second is that
there is no symbolic debugger.

Fighting these objections may actually take more effort than
implementing the required tools to overcome the objections! A
consequence of not providing these tools is that Forth then
restricts its commercial market to users who do not have much
experience of high level languages. I don't believe that there
are many sales to be had by telling potential customers that they
have been doing it all wrong in the past.

Before someone accuses me of tailoring the language to fit the
market, I confess. Yes it's true! I believe that glitz and ease
of use are really important! But Elizabeth's original point is
absolutely right.

Stephen Pelc
From: ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: Who's here
Date: 2 Oct 92 12:14:59 GMT
Organization: EIEI-U

Category 1,  Topic 8
Message 48        Thu Oct 01, 1992
ELLIOTT.C                    at 12:59 EDT
 
 -----via CRS Premium Bulletin Board
 Date: 09-29-92 (09:34)
   To: B-LEE [B0B]
 From: GREG VIGNEAULT
 Subj: PROGRAMMER JOKES

  In a message to All... MH> A Forth is a Forth, of course, of
 course,
   > But no one can talk to a Forth of course,
   > That is, of course, unless the Forth,
   > Is the same identical kind...

  As a multi-language programmer (Assembly, C, Modula-2, Pascal) who is
  interested in Forth, I was going to post a note here asking why this
  (Forth) conference was so unlike others - ie.  virtually no snippets of
  source, or coding tips, etc.

  I was wondering if this was for a lack of a common ground, or if there
  was some severe "politics" between Forth users.

  Greg_

  Sep.29.1992.Toronto.Canada.
 greg.vigneault@bville.gts.org

 PCRelay:BVILLE -> #1412 RelayNet (tm) 4.11
 Baudeville BBS-Toronto  416-283-0114 (v32bis)
   CRS Premium Bulletin Board

 Date: 10-01-92 (07:20)
   To: GREG VIGNEAULT
 From: ELLIOTT CHAPIN
 Subj: PROGRAMMER JOKES

 GV> In a message to All... MH> A Forth is a Forth, of course, of
 course,
   > But no one can talk to a Forth of course,
   > That is, of course, unless the Forth,
   > Is the same identical kind...

 Pretty facetious, although there are significant differences ...

 GV> As a multi-language programmer (Assembly, C, Modula-2,
 Pascal) GV> who is interested in Forth, I was going to post a
 note here asking GV> why this (Forth) conference was so unlike
 others - ie. virtually GV> no snippets of source, or coding
 tips, etc.

 Just wait; and when you write code that hangs your machine
 inexplicably, post it for help.

 GV> I was wondering if this was for a lack of a common ground,
 or if GV> there was some severe "politics" between Forth users.

 There's more agreement about what the problems are than about
 solutions.

 Elliott Chapin ---
    DeLuxe  1.12 #4315   elliott.chapin@canrem.com  

-----
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: dwp@willett.pgh.pa.us
From: Jason.Goga@mailbox.bison.mb.ca (Jason Goga)
Newsgroups: comp.lang.forth
Subject: Forth will Replace C
Date: 02 Oct 92  12:35:15 CST

 >    Forth is in a sorry state. We constantly hear that programmers are
 > not allowed to use Forth at work because not even the author of Forth
 > code
 > can read it after a short time. Since assembly language and C programs
 > are perfectly acceptable, you can get around this by by writing a
 > Forth system in assembly or C. Such an approach will work since managers
 > can tell when assembly or C code is properly commented but they have
 > no idea what a commented Forth program should look like.
How heavily an author comments his code is (in my opinion) totally up to him, my approach, not being the fastest way, and not having modern tools, is to write the code in a nicely layed out format (similar to the appearance of 'C' and Pascow) then strip off the commenting to shrink the code down into the 16lines / screen L&P F83 will tolerate, but keeping the original around. This I feel is silly for me to be doing, as a serious forth should have a better system for source code. There are of course advanta









ges and such, so it's more a personal / financial matter that restricts one. Forth would be in a really sad state once MicroSoft or Borland become interested, then we can buy 10M libraries containing several replications of the same definition. :-)

 >    I don't read CACM (but I'll look for it in the future), and I don't
 > know what is written in the above columns. But anything that will
 > improve the readability of Forth code will go a long way to make Forth
 > popular. We should get readable Forth code published where prospective
 > Forth programmers and technical managers can see it.

I try and write code so that OTHER people will understand it, seeing that I have a very poor memory, and will also forget from day to day what I was working on.

-Jason

---
 * Origin: C.A. - FrontDoor (1:348/207)
From: hosken@spss.com (Bill Hosken)
Subject: Re: An Open ANSI Forth Implementation
Organization: SPSS, Inc.
Date: Tue, 6 Oct 1992 16:45:48 GMT

>  ANS with their implementations. We finally succeeded ordering
>  dpANS3 last week (Of course, we received the changed sections a
>  few months ago).  For the prices Global Engineering asks (about
>  $150, all costs added), I hope not too many revisions follow...
> 

Could you post how to obtain this?

Thanks,
Bill
From: dwp@willett.pgh.pa.us (Doug Philips)
Newsgroups: comp.lang.forth
Subject: FAQ messages will be late this time.
Date: 1 Oct 92 14:12:08 GMT
Organization: EIEI-U

The regularly schedule biweekly FAQ messages for comp.lang.forth are
going to be late.  With the advent of an FTP site, the FAQ messages will
be totally restructured.
-Doug
---
Preferred:  dwp@willett.pgh.pa.us	Ok:  {pitt,sei}!willett!dwp
Newsgroups: comp.lang.forth