Standardisation

forth

    Next

  • 1. forth Insertion Sort
    I am writing a paper on FORTH and am looking for a simple insertion sort example. Does anyone know where I can find one? Thank you, bnhcomputing
  • 2. Anyone heard any funny stories about grid multiplexed forth chips?
    X-No-Archive <!-- START OF MESSAGES <!-- 11:17pm, May 5th, In the Year of Jesus Christ, Two Thousand Six, Anyone heard any funny stories about tiny forth chips, grid multiplexed, lately? Me neither :( just simply justice simplification justify simple IBM/INTEL/MICROSOFT <--> COPORATE COLLABORATIVE RACKETEERING RACKETBALL YOU WILL BE KILLED BY INVESTORS WRITE DOWN EVERY ONE OF MY JESUS CHRIST THEORIES WELL, HERE IS ONE INTEREST OF MINE, I AM UNABLE TO DISCERN, TO THE BEST OF MY WISDOM ( IN KNOWLEDGE, FROM READING), THE FELLOW WAS NOT A JERK, BUT I'M NOT SURE, THERFORE, UNTIL THE DAY I AM SATISIFIED IN MY ABILITY TO JUDGE HIS ERROR, IF ANY, I'M TOTALLY SCREWED BY A LIMIT TO BOTH WISDOM, MY ABILITY TO LIVE WITH MY FELLOW MAN, and maybe interestingly enough, my entire conceptual universe of life. Regards, maw 11:47pm
  • 3. [OT] Pinging 'rickman'
    <OT> "rickman", please contact me at XXXX@XXXXX.COM (temporary, short-lived email,) regarding: (a) Total Phase (b) Your post in comp.lang.forth about forth for board level debug. Thanks, Roberto Waltman </OT>

Re: Standardisation

Postby Andrew Haley » Mon, 15 Mar 2010 20:41:09 GMT



Once you've done that, you basically have a single implementation
standard, like fig-FORTH.  There's nothing wrong with that, but it's
a very different thing from an abstract virtual machine, which is the
approach that ANS tends to take for programming languages.

Andrew.

Re: Standardisation

Postby J Thomas » Mon, 15 Mar 2010 21:53:41 GMT




 
 

Well, no. What you'd have would be a standard that's tilted away from old 
optimizations.

DO was designed to be fast on some hardware. Programmers have to dea; 
with quirks but they get that speed advantage. Sometimes they might 
prefer not to have the quirks. (Particularly if there were new Forth 
programmers.)

Various things block the return stack that do not have to, getting in 
programmers' way. Of course good Forth programmers can work around that 
stuff. One of the most obvious ways to handle that would be to provide 
another scratch stack and leave the return stack alone. 

Keep the return stack commands for manipulating control flow. (Is it bad 
programming practice to manipulate the control flow that way? Maybe it's 
always bad. Maybe it's sometimes bad. If it can be done portably then we 
can decide about that.)

Perhaps # #S etc could leave their data on the data stack? Then you don't 
need a #> buffer that collides with other buffers, but you can easily C! 
the digits into any buffer you want. Or EMIT them. 

Etc.

We have a whole lot of limitations on programmers that were mostly put in 
so that implementers could do elegant tricks. But now the commercial 
Forths make optimised native code, and the programmers are still stuck 
with those crusty limitations. 

A separate standard that fixed that cruft would not be a single-
implementation standard if it got implemented for multiple systems.

It would probably need new words -- a new name for a changed DO , a new 
name for a changed IF , new pictured numeric words, etc. It could be 
added to many existing Forths, if there was reason to.

If an opportunity arose to market Forth to nonForth programmers, this 
would be the obvious version to market. Call it SuperForth? No, I think 
that name is copyrighted. Modern Forth? I tend to doubt it would be 
popular with existing Forth programmers because they have already put a 
whole lot of thought into getting around the limitations that it would 
remove. So they don't need it.

Re: Standardisation

Postby Andrew Haley » Mon, 15 Mar 2010 23:49:52 GMT

Thomas < XXXX@XXXXX.COM > wrote:

I don't think there's anything old about them. It still makes sense
to use the return stack for DO-loops, for example. The 2-stack
virtual machine still makes a lot of sense, especially if you have
many tasks.


I don't believe so. AFAIK DO was designed to be easy and convenient
to use, which it is.


"Keep the return stack commands for manipulating control flow." But
doing that has never been portable except with a single implementation
standard like fig-FORTH. For this really to work you have to nail
down a lot of details about what a system may do. It makes far more
sense IMO to keep the current rules that, for example, allow FOO ; to
be a jump to FOO, allow a return address to be more than one cell wide,
allow some other stack to be used for return addresses, and so on. As
soon as you start to allow R-stack manipulation for user control flow,
you lose a lot of possibilities.

So, this idea doesn't sound new to me but old, back to the way
fig-FORTH did things.

If you have a single implementation standard you can do this, of
course.


Heavens, no. cmFORTH did that, and it wasn't nice.


Sure it would. You could implement fig-FORTH on multiple systems, and
people did, but it was all basically the same virtual machine.


retroFORTH ? No, that name's taken.
classicFORTH?

Andrew.

Re: Standardisation

Postby J Thomas » Tue, 16 Mar 2010 04:45:47 GMT

ndrew Haley wrote:




Sure, the more tasks you have then the less resources you want to give
each task. And yet....


Tell that to somebody who's first learning it. Loops heading up and loops
heading down end at different spots. A zero-length loop actually executes
2^N times. This is for speed, not convenience. OK, it's convenient
particularly on 2's-complement 16-bit systems that negative and high-
unsigned numbers neither overflow but give the same result.


OK, I think you're right. Hmm. If a return address is more than one cell
wide R> etc will work just fine provided the return stack isn't used for
other things. But then you can't do DUP etc on return addresses. You
could do RSWAP with 2R> >R >R but it's all clumsy. OK, use the "return
stack" name and operations for a spare stack. And if it's worth doing,
develop new names for the actual return stack manipulations. Preferably
names that describe what happens to the flow of control.

I'm not sure how tail-jumping can be kept out of the way. I can't think
of a circumstance where you'd actually want to nest-sys to the end of the
word that calls FOO when all it will do is return again, but you
certainly want to know what you're nest-sysing to.


It could turn out a mix of fig-Forth and color-Forth etc. People who're
interested in programmer convenience more than in system elegance (with
still a lot of emphasis on the latter) might disagree about what they
wanted.


You didn't like it. The only problem I had with it was a student who
noticed that it didn't fit generic Forth documentation. Easy to fix it,
if you want it different. Something like,

: #>BUF ( i*n ... i*1 n addr -- )
OVER 1+ BOUNDS DO I C! LOOP ;

CREATE #>-BUFFER 34 CHARS ALLOT
: #> ( ... -- addr len )
#> #>-BUFFER #>BUF #>-BUFFER COUNT ;

That doesn't give you all the data-stack manipulation you can do inside
<# #> but at least it gives you the usual end results.


I think I see what you're saying. If you specify a single virtual machine
then programmers can take advantage of all the features of that virtual
machine. But it's only one virtual machine. If you partially-specify a
virtual machine then programmers have to be careful not to step into any
of the holes in the specification, but implementers get to do whatever
they like with everything that is not specified.

I was figuring that if you can implement a VM on multiple different Forth
systems then code for that VM will run on all of them. Are we in
disagreement about realities, or about how we label things, or is there
something else?

Re: Standardisation

Postby Gerry » Tue, 16 Mar 2010 06:02:56 GMT

n 14 Mar, 12:53, J Thomas < XXXX@XXXXX.COM > wrote:

I think this was basically where I was coming from. In the early days
with slow processors and limited memory, Forth implementations had to
work within those limitations and used various tricks etc which in
turn led to many of the restrictions we now live with in ANS (and
other) Forths. It also led to the set of words many of which are
unsatisfactory in some way. A major tidy up is needed. As has been
made clear in other discussions this will never happen in Forth 200X
because legacy code and common practice forbid it. As well as the
tidy-up it would be nice to get new features introduced e.g. the
ability to have a non-parsing CREATE or other defining word has
regularly been requested - the proposers of such things usually
get slapped down pretty quickly.

If such things can't be done via the Forth 200X process then there
has to be a break with the past. But this doesn't mean that
we have to start with a blank sheet, there are many good things
in ANS Forth and we could build on those. One way to achieve this
could be, as suggested in my previous post, to remove the
inherited restrictions e.g. DO LOOPS must not interfere with user
use of the R stack; <# # #> uses a buffer that is not in users
dataspace. This leads to the notion that the system leaves the
user's resources alone, it doesn't pollute the data stack; use
dataspace for its own purposes; the problem of transient regions
largely goes away because the system uses its own resources not
those allocated to the user.

There are other things that can be added that maintain
compatibility e.g. I've wanted to have hooks into the text
interpreter several times to define alternative actions.

The idea is to bear legacy stuff in mind, but to ignore it where
it gets in the way or is thought to be obsolete or unnecessary.
For instance some things could be omitted if they could easily
be added by a library module e.g. Forth blocks. If we had a
:name (caddr u -- ) we wouldn't need : because that can easily
be defined.

Removing restrictions while retaining the wordset, or being able
to easily define omitted words, would mean that existing
software would run - a desirable quality.

It is too soon IMO to say that things such as using the return
stack for control flow would be included - get the basics
thrashed out first.


I think it would have to be a single implementation initially, can
you imagine the arguments if we tried to do it via discussion.
It would probably best be done by a very small like-minded team
(possibly one person).


I would hope that new words would not be needed to replicate
existing functionality less the restrictions.


That would be a bonus if it reduces the learning barrier.


Its all a bit vague and woolly at present but possibly food for
thought.

Gerry

(A disclaimer: before suggesting this in my previous post
this topic was only a vague idea in the back of my mind, far from
thought through and, undoubtedly full of holes - so please bear
that in mind before {*filter*}ing me.)

Re: Standardisation

Postby Elizabeth D Rather » Tue, 16 Mar 2010 07:23:40 GMT

Thomas wrote:
...

Been there, taught thousands of students at this point. It's not
difficult; people understand immediately how these things work and why.


Wow, what a can of worms. As soon as you start encouraging programmers
to make arbitrary control flows by fiddling with the return stack you
have utterly unmaintainable, unstructured code coupled with a whole host
of restrictions on programmers and implementors alike.


You can't do a lot of things. The Return Stack was never intended as a
user resource. The Data Stack is a user resource, as is PAD and most of
memory, but the Return Stack is primarily (and appropriately) a system
resource that can be used by apps only in very limited, specific ways.

...

Don't know of any "generic Forth documentation" that doesn't explain the
# words fairly clearly. There are a lot of things that don't go on the
stack. The number conversion buffer is one of them.

Cheers,
Elizabeth

--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

Re: Standardisation

Postby Aleksej Saushev » Tue, 16 Mar 2010 12:05:24 GMT

Elizabeth D Rather < XXXX@XXXXX.COM > writes:




Nice illustration for this 1960s approach: make the human to serve the machine
rather than fix obvious bug in the software.


Are non-local exits or exceptions that hard to understand?
Sorry to disappoint you, but all the world around you thinks otherwise.


-- 
HE CE3OH...

Re: Standardisation

Postby Bruce McFarling » Tue, 16 Mar 2010 15:19:34 GMT




Yes, I'd do the opposite ... declare in the UserForth model that the
rack is *not* the return stack and you can access it any darn time you
like, including in the interpreter and in LOOPS ... and all the nested
recursion functions whether return or type checking of structures or
do-loop indices are performed out of sight on the SystemForth R-stack.

UserForth could declare that MixedCase is matched exactly and uniform
CASE is matched case-insensitive.

I don't think it'd be necessary to do a complete implementation ... a
bit threaded model with pointers to Forth xt's as its CodeXT's,
negated addresses as its ColonXT's, all addresses relative to the base
of the UserForth box and separated headers building down from the top
edge of the dictionary space, then a stack frame with datastack
growing up and auxillary rack growing down. A word to import visible
Forth words as primitives would get the xt and make the label, but of
course any SystemForth wordlist not in the search order when UserForth
launches is sealed, as the UserForth search order is on the UserForth
dictionary, not the SystemForth dictionary.

Like that.

Re: Standardisation

Postby Andrew Haley » Tue, 16 Mar 2010 18:43:17 GMT

Thomas < XXXX@XXXXX.COM > wrote:

Heh, fair enough. I *have* taught DO, I must point out.


I guess it's a bit like democracy, which is the worst political system
except for all the others! But AFAIK DO has never been particularly
fast on any hardware, which is why cmFORTH had the simpler FOR
... NEXT.

I suspect that if FORTH had locals back in the day, the DO ... LOOP
would never have taken the form that it did. It's easy enough in
Standard FORTH to write a loop structure that doesn't have the
features you don't like: FORTH is an extensible language.

There is, however, one very {*filter*} problem with using locals: an
ambiguous condition exists if POSTPONE is applied to a local name.
So, you can't create a looping structure with locals -- unless you use
EVALUATE on "to index", for example. This makes locals far less
useful than they might be.


My objection is basically that we were in a situation before (with
fig-FORTH, then FORTH-83) where these things were nailed down, but it
was a pretty major barrier to innovation. You couldn't even have a
32-bit system, for example.

Andrew.

Re: Standardisation

Postby J Thomas » Wed, 17 Mar 2010 01:06:53 GMT

ndrew Haley wrote:


Ah! Compared to FOR NEXT . Yes.
Compared to Basic FOR I = 1 to 10000 STEP 3 NEXT I it's blindingly
fast. ;)

I naturally thought that the point of using DO instead of ?DO was usually
to avoid the delay of the extra branch. It isn't real often that you care
about the case of precisely 2^N iterations.

But I don't want to be picky about this trivial point.


Yes. I never got interested enough in locals to find out what the
implementation problems are that make that restriction useful.

I like the idea of an orthogonal Forth that can be built on top of
standard Forths with some loss in efficiency. I'd like locals that
avoided some of the standard locals restrictions, but if it's too hard to
implement then the result is a one-implementation standard. So we
wouldn't want to ignore implementation issues even while we put more
emphasis on ease of use.


Traditionally, one of Forth's big strengths has been that it's easy to
improvise with it. Get something that works. Then try out different
algorithms. Find out which work better.

If we had a Forth that was easier to use, then that strength would be
enhanced. Try out algorithms and get a sense of which approach is better.
Then if you need to improve performance, handle the tweaks that let it
run more efficiently.

You could get some portability at either level -- at the user standard it
would be portable to whatever Forths can meet that standard after special
libraries are loaded. Or after you ansify the code then it will be
portable to more systems and probably be more efficient also.

Maybe everybody who feels standard Forth is too inconvenient will prefer
to use Python or Lua instead. But it would be easier to translate into
standard Forth from a standard convenient Forth than from Python or Lua.

Re: Standardisation

Postby Bruce McFarling » Wed, 17 Mar 2010 03:56:58 GMT




I think a bit-threaded model with underlying SystemForth xt's as
"CodeXT" and colon definitions compiled in the UserForth, a software R-
stack and a system-dependent return stack is a reasonable path there.
MAF shows that the alternative to a bit-threaded implementation for
this kind of thing is indirect threaded, and bit-threaded would be
faster.

Thinking out loud, something along the lines of (note that this is in
SystemForth):

: UserLoop ( uf-addr -- )
  FALSE TO UserFinish?   \ (1) Primitive may flag exit at end of
caller word
  FALSE >UserReturn      \ (2) if get back to this, EXIT
  >UserReturn BEGIN      \ (3) Initial UserForth routine
    UserReturn@++ ?DUP 0= IF EXIT THEN   \ Cf (2)
    @ DUP 0> IF
      User@ EXECUTE      \ Installed XT's referred to by uf-address
    ELSE
      ?DUP IF
        NEGATE >UserReturn
      ELSE
        UserFinish? IF EXIT ELSE UserReturn> DROP THEN \ Cf. (1)
      THEN
    THEN AGAIN ;

UserFinish is a VALUE that SystemForth level words could set for a
primitive that allows exit out of UserForth into SystemForth. The
system would also allows a single-stepping through a UserForth colon
definition.

This also allows a 32bit UserForth to be run on top of a 16bit
SystemForth, though a system like hForth's EXE model with seperate
SystemForth codespace and dataspace may be best for this. The
"ImportWord" routine will just place the 16-bit XT in the right
location so that the 16-bit User@ gets the correct value.


With an unbound UserRack, locals could be defined to be an offset from
a local base in the rack, and if the syntax restricts locals to a
frame established when the word is entered, it could well be possible
to lift many restrictions on how locals are used.

It would indeed be possible to have UserForth locals be organized
around a local frame definition independent of the use of the local
frame, with the local definitions residing in the dictionary as a
wordlist attached to the frame definition. When the frame definition
is invoked at the  start of the definition, its attached wordlist is
searched first before the search order. Then a compiler macro that is
defined into that attached wordlist would have the locals in scope
when it is being defined, and would itself be in scope when the
correct frame has been invoked for the locals that it postpones to
work

Similar Threads:

1.Standardisation of number length

I have a long list of numbers which I need to convert to a standard length of 8 characters. For example:

5 to 00000005
18 to 00000018
1471 to 00001471

Is there a quick way of doing this rather than manually editing each cell?
-- 
Many thanks
Robin

2.phase relationships in the standardisation process

3.Lifting standard restrictions (was: Standardisation)

4.POSTPONEing locals (was: Standardisation)

5.Standardisation (was: Testing portability to non-2s-complement machines)

6. Standardisation (was: Testing portability to non-2s-complement machines)

7. Sound control standardisation

8. Call for port standardisation



Return to forth

 

Who is online

Users browsing this forum: No registered users and 85 guest