Groups > comp.lang.forth > #47282 > unrolled thread

Was just wondering when people started using C to write forth languages and not assembly?

Started by	Darin Murphy <murphy.darin@gmail.com>
First post	2016-05-18 11:31 -0700
Last post	2016-05-20 22:27 -0400
Articles	20 on this page of 75 — 20 participants

Back to article view | Back to comp.lang.forth

Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →

#47485

From	hughaguilar96@gmail.com
Date	2016-05-24 10:09 -0700
Message-ID	<bae2499a-8eb5-4f95-b931-e7ca603ea396@googlegroups.com>
In reply to	#47472

On Tuesday, May 24, 2016 at 2:36:49 AM UTC-7, Stephen Pelc wrote:
> On Mon, 23 May 2016 23:21:40 -0700 (PDT), hughaguilar96@gmail.com
> wrote:
> 
> >This is pure fantasy --- there is no TCP/IP stack in anybody's back pocket.
> 
> http://www.mpeforth.com/powernet.htm
> 
> It's been available for over 15 years.
> 
> Stephen

This is not ANS-Forth.

[toc] | [prev] | [next] | [standalone]

#47487

From	stephen@mpeforth.com (Stephen Pelc)
Date	2016-05-24 20:24 +0000
Message-ID	<5744b876.523720144@news.eternal-september.org>
In reply to	#47485

On Tue, 24 May 2016 10:09:14 -0700 (PDT), hughaguilar96@gmail.com
wrote:

>On Tuesday, May 24, 2016 at 2:36:49 AM UTC-7, Stephen Pelc wrote:
>> On Mon, 23 May 2016 23:21:40 -0700 (PDT), hughaguilar96@gmail.com
>> wrote:
>> 
>> >This is pure fantasy --- there is no TCP/IP stack in anybody's back pocket.
>> 
>> http://www.mpeforth.com/powernet.htm
>> 
>> It's been available for over 15 years.
>> 
>> Stephen
>
>This is not ANS-Forth.

How do you know?

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

[toc] | [prev] | [next] | [standalone]

#47488

From	hughaguilar96@gmail.com
Date	2016-05-24 14:32 -0700
Message-ID	<d4d9771c-c42a-431e-8a08-1631a68eec30@googlegroups.com>
In reply to	#47487

On Tuesday, May 24, 2016 at 1:24:42 PM UTC-7, Stephen Pelc wrote:
> On Tue, 24 May 2016 10:09:14 -0700 (PDT), hughaguilar96@gmail.com
> wrote:
> 
> >On Tuesday, May 24, 2016 at 2:36:49 AM UTC-7, Stephen Pelc wrote:
> >> On Mon, 23 May 2016 23:21:40 -0700 (PDT), hughaguilar96@gmail.com
> >> wrote:
> >> 
> >> >This is pure fantasy --- there is no TCP/IP stack in anybody's back pocket.
> >> 
> >> http://www.mpeforth.com/powernet.htm
> >> 
> >> It's been available for over 15 years.
> >> 
> >> Stephen
> >
> >This is not ANS-Forth.
> 
> How do you know?

Prove that it is!

You have a long history of writing code that is not ANS-Forth. A good example is your SYNONYM --- you told me to RTFM, but then when you finally presented your code it was not ANS-Forth --- by comparison, my own SYNONYM and ALIAS are ANS-Forth.

You failed to write SYNONYM or ALIAS in ANS-Forth because you didn't have the disambiguifiers. Why do you refuse to accept the disambiguifiers? Obviously, it is because you know that the disambiguifiers make FIND work correctly and this allows the Forth programmer to write his own outer-interpreter for use in a cross-compiler. Also, why do you refuse to make LITERAL vectored? Obviously, it is because you know that this would allow the built-in outer-interpreter to be used in a cross-compiler that supports literal numbers. You are doing everything in your power as a committee member to prevent Forth programmers from writing cross-compilers in competition with MPE.

You also post code that you claim is ANS-Forth, but it isn't. As an example, consider your BNF code which was discussed here:
https://groups.google.com/forum/#!topic/comp.lang.forth/CYR7FhjYMkg
> I was reading about Stephen Pelc's BNF interpreter that is in VFX. It looks pretty interesting. I notice that his code is not ANS-Forth however.
> 
> : || IF R> DROP 1 THEN ;
> 
> This is obviously illegal in ANS-Forth. Section 3.2.3.3. says: 
> A program shall not access values on the return stack (using R@, R>, 2R@ or 2R>) that it did not place there using >R or 2>R;
> 
> Pelc should have written this:
> 
> macro: ||  if 1 exit then ;
> 
> Or, for improved readability:
> 
> macro: ||  ( flag -- true | )  \ exits the parent function on a true flag
>     dup if  exit then          \ if the flag is true, exit and return the flag
>     drop ;                     \ if the flag is false, drop the flag and keep going
> 
> MACRO: is in the novice-package and, like everything in the novice-package, it is ANS-Forth. 
> 
> Also, I don't know why he is using 1 rather than -1 for true, but that doesn't matter very much.
> 
> My string-stack is a stack, so it supports recursive functions. I think my string-stack.4th can do everything that Pelc's BNF interpreter can do, although I don't have the BNF-like appearance which might be useful to somebody who is working from a language-specification that is in BNF.
> 
> The most important point is that my string-stack.4th is written in ANS-Forth whereas Pelc's BNF interpreter is written in VFX-specific code that will trap the user in vendor lock-in. Also, my string-stack.4th is available for free. Pelc's BNF interpreter is described in the manual, but doesn't seem to be available in the evaluation version of VFX, so you have to spend money to get it --- and I doubt that you get the source-code even if you do spend the money.

In both of these case you gratuitously broke with ANS-Forth compatibility --- it is easy to write this stuff in ANS-Forth --- you break with ANS-Forth compatibility for the purpose of trapping your customers in vendor lock-in. I doubt that any of the code in VFX is written in ANS-Forth! Show us any code in VFX that is ANS-Forth --- you can't do this because none of it is ANS-Forth --- for example, if you use FIND then your code won't run on gForth that has its own unique interpretation of what FIND does (for some words it returns different xt values depending upon what STATE is at the time that FIND executes). ANS-Forth is full of ambiguity, so no matter what interpretation you choose, it is possible that some ANS-Forth compiler-writer somewhere has chosen a different interpretation, and so your code won't work on his compiler, but if your code doesn't work on an ANS-Forth compliant compiler then your code is not ANS-Forth.

I'm not actually opposed to you making money though, and vendor lock-in is the key to making money, so I'm not opposed to you doing this. My complaint is that you are a hypocrite to do this, and to also be on the Forth-200x committee setting the Standard that all Forth programmers are supposed to adhere to, when you don't adhere to it yourself --- it is abundantly obvious that the only reason why you agreed to be on the committee was so you could sabotage the Standard to prevent common Forth programmers (me) from writing Forth code in competition with MPE --- if anybody does write code in competition with MPE, and they break with the ANS-Forth standard, then you use your position as a committee member to denounce them for being non-standard. My novice-package is totally ANS-Forth compatible, but you denounce it too --- the whole purpose of the committee is to denounce everybody else who programs in Forth.

I have said many times that what is needed for cross-compilation is a way to take an xt and determine the attributes of the word (what vocabulary it is in, immediate or non-immediate, smudge flag set or not, smudge-ready flag set or not), and also to be able to change these attributes. Also, it is necessary to have some way to conveniently determine the xt of the last definition compiled. All of this is trivial to implement and could be done in one day. Why do you refuse to do this? Obviously, because you want to cripple the Standard to prevent common Forth programmers from writing cross-compilers in competition with MPE.

Here is a quote about hypocrisy:
--------------------------------------------------------------------
A hypocrite is the kind of politician who would cut down a redwood tree, then mount the stump and make a speech for conservation. 
--- 
Adlai E. Stevenson
--------------------------------------------------------------------

This is you! You know perfectly well that ANS-Forth was crippled --- yet you are on the Forth-200x committee which is mandated to be 100% compatible with ANS-Forth, implying that ANS-Forth had some kind of value (I mean, value to the Forth programmers, not value as a marketing gimmick from Forth Inc. to make Forth Inc. appear more important than it is) --- Forth is the redwood tree, ANS-Forth is the chainsaw, and you are the politician!

ANS-Forth is corrupt to the core --- anybody who embraces ANS-Forth does so because they hate Forth and want to prevent Forth programming --- the only way to prove that you care about Forth is to abandon ANS-Forth!

I can easily write a standards document that defines a Forth language for desktop-computers that is suitable for cross-compilation of Forth. I discussed this here:
https://groups.google.com/forum/#!topic/comp.lang.forth/D0PmblPgthM
I said: "These are the 5 principles of Straight-Forth. Who disagrees with any of these principles? Which ones? Why?"
The silence from the ANS-Forth cult (including yourself) was deafening!

[toc] | [prev] | [next] | [standalone]

#47505

From	stephen@mpeforth.com (Stephen Pelc)
Date	2016-05-25 09:34 +0000
Message-ID	<57456b2c.569470043@news.eternal-september.org>
In reply to	#47488

On Tue, 24 May 2016 14:32:46 -0700 (PDT), hughaguilar96@gmail.com
wrote:

>> >This is not ANS-Forth.
>>=20
>> How do you know?
>
>Prove that it is!

As usual, you feel yourself qualified to pontificate on code that
you have never seen.

>You have a long history of writing code that is not ANS-Forth. A good examp=
>le is your SYNONYM --- you told me to RTFM, but then when you finally prese=
>nted your code it was not ANS-Forth --- by comparison, my own SYNONYM and A=
>LIAS are ANS-Forth.

The point about SYNONYM is that systems exist in which implementation
of SYNONYM requires carnal knowledge of the implementation. Obsessing
about whether or not system words are themselves written in ANS-Forth
is just ridiculous.

>You are doing everything in your power as a committee member to prevent =
>Forth programmers from writing cross-compilers in competition with MPE.

Sitting over a coffee this morning, I realised that if I wanted to
write a portable cross-compiler in Forth-2012, I would write a 
text interpreter for it so that it becomes more portable.

As others have already pointe out, writing a text interreter is a
trivial part of writing a cross compiler.

>> I was reading about Stephen Pelc's BNF interpreter that is in VFX. It loo=
>ks pretty interesting. I notice that his code is not ANS-Forth however.
>>=20
>> : || IF R> DROP 1 THEN ;
>>=20
>> This is obviously illegal in ANS-Forth. Section 3.2.3.3. says:=20
>> A program shall not access values on the return stack (using R@, R>, 2R@ =
>or 2R>) that it did not place there using >R or 2>R;

This is a classic delusion about what standards say. In ANS, depending
on the return stack holding a return address makes the program
non-standard. This does not make the technique invalid or mean that
the standards police will fine me. ANS simply says that the program
is non-standard and may be difficult to port.

As a matter of courtesy, you should at least acknowledge that the
code for the BNF parser originates with Brad Rodriguez in about 1990
and precedes ANS-Forth.

>Pelc's BNF interpreter is described in the manual, but doesn't see=
>m to be available in the evaluation version of VFX,

Wrong. Look for ::= and BNF-VOC. 

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

[toc] | [prev] | [next] | [standalone]

#47517

From	hughaguilar96@gmail.com
Date	2016-05-25 09:52 -0700
Message-ID	<46c2c6ed-f68e-4358-94e2-1b197b9f38a3@googlegroups.com>
In reply to	#47505

On Wednesday, May 25, 2016 at 2:34:45 AM UTC-7, Stephen Pelc wrote:
> On Tue, 24 May 2016 14:32:46 -0700 (PDT), hughaguilar96@gmail.com
> wrote:
> 
> >> >This is not ANS-Forth.
> >>=20
> >> How do you know?
> >
> >Prove that it is!
> 
> As usual, you feel yourself qualified to pontificate on code that
> you have never seen.

I'm not going to pay for it.

> >You have a long history of writing code that is not ANS-Forth. A good examp=
> >le is your SYNONYM --- you told me to RTFM, but then when you finally prese=
> >nted your code it was not ANS-Forth --- by comparison, my own SYNONYM and A=
> >LIAS are ANS-Forth.
> 
> The point about SYNONYM is that systems exist in which implementation
> of SYNONYM requires carnal knowledge of the implementation. Obsessing
> about whether or not system words are themselves written in ANS-Forth
> is just ridiculous.

This is totally untrue. My disambiguifiers make *ALL* ANS-Forth systems behave the same in regard to FIND. Your VFX has the words that were traditionally immediate (such as IF etc.) being non-immediate and being special-cased by COMPILE, so they execute at compile-time like immediate words. GFORTH has FIND return different xt values for these words depending upon the value of STATE at the time that FIND is executed. Using FIND or tick on these words is an ambiguous condition, so pretty much anything can be done (including reformatting the hard-disk) and that would be ANS-Forth compliant. POSTPONE is not an ambiguous condition however. This is the loophole in the sabotage that I make use of:

: if  state @ 0= abort" *** no interpretation semantics for: IF ***"          
    postpone if ; immediate

This is a disambiguifier. Given these disambiguifiers, FIND will work correctly on all of these words. They are now immediate, and FIND returns an xt that works (only inside of a colon definition, otherwise they abort with meaningful error message). 

Because my SYNONYM and ALIAS use the disambiguifiers, my SYNONYM and ALIAS work correctly on every ANS-Forth system with no need for carnal knowledge --- if you say otherwise, then you are lying.

Also, I am not: "Obsessing about whether or not system words are themselves written in ANS-Forth." That would be ridiculous! I am saying that your software, such as the BNF interpreter and the TCP/IP stack that you claim are written in ANS-Forth, are not written in ANS-Forth. I don't think that any of the software that you provide with VFX is written in ANS-Forth. My point is that anybody who uses this software in a program is trapped in vendor lock-in --- they can't port their programs to other ANS-Forth systems because the software you provide (when you provide source-code) won't work on those systems because it is not ANS-Forth.

Saying that I care whether the ANS-Forth system words are themselves written in ANS-Forth is a straw-man argument --- I never said any such thing --- the use of straw-man arguments such as this is the hallmark of a cult!

> >You are doing everything in your power as a committee member to prevent =
> >Forth programmers from writing cross-compilers in competition with MPE.
> 
> Sitting over a coffee this morning, I realised that if I wanted to
> write a portable cross-compiler in Forth-2012, I would write a 
> text interpreter for it so that it becomes more portable.
> 
> As others have already pointe out, writing a text interreter is a
> trivial part of writing a cross compiler.

Well, there are two approaches to this "trivial" exercise:
1.) Use the built-in outer-interpreter. This won't work in ANS-Forth because LITERAL is not vectored so you can't have literal numbers. Code such as this won't work:
: test 8 * ;
You have to do something like this instead:
: test [ 8 ] literal * ;
If you explicitly use LITERAL then you get the new version of LITERAL that compiles into the target system. The first version doesn't work because it uses the old version of LITERAL that is called internally by the built-in outer-interpreter and compiles into the host system.
2.) Write your own outer-interpreter. This won't work in raw ANS-Forth because the behavior of FIND is ambiguous on most of the words in ANS-Forth (these are IF etc. mentioned above). This problem can be fixed with the disambiguifiers however, so that FIND will work. You still need a STR>NUM function to get literal numbers, but this can be written in ANS-Forth. You still have the problem of QUIT calling the built-in outer-interpreter rather than your new and improved outer-interpreter when the system aborts, but this can be fixed with CATCH and THROW (theoretically; I haven't actually tried this yet).

So your "trivial" exercise requires my novice-package to work --- I have the disambiguifiers, and I have STR>NUM --- but without my novice-package, you would have to write this yourself which is not trivial (it took me about five years to figure out how to write the disambiguifiers to work-around the sabotage in ANS-Forth in which the behavior of FIND is ambiguous).

Also, the ONLY ALSO scheme used in ANS-Forth is screwed up. I fix this in the novice-package --- I have PUSH-CONTEXT POP-CONTEXT DROP-CONTEXT GET-CONTEXT SET-CONTEXT etc. --- I don't think you can write a cross-compiler without this or something similar.

Another good point here is that you had a bug in VFX that I had to work around. Here is a comment in the code discussing this:
\ VFX pushes a wid called LOCALVARS onto the search order in colon words that have locals, then pops it off again at the semicolon.
\ It is in the way. If you set the 1st value to a replacement wid, you will replace LOCALVARS rather than the wid you thought you were replacing (which is now 2nd).
\ This is a gross violation of the ANS-Forth standard (13.3.3-1):
\ "...if the Search-Order word set is present, local identifiers shall always be searched before any of the word lists in any definable search order,
\  and none of the Search-Order words shall change the locals’ privileged position in the search order."

\ Note: Stephan Pelc fixed the bug mentioned above in version 4.71.3523 of Oct.8,2014.

All of this was discussed here:
https://groups.google.com/forum/#!topic/comp.lang.forth/olO-VHXJa1Q%5B1-25%5D

The fact that you had this bug up through 10/8/2014 implies that you never wrote a cross-compiler prior to this time that used local variables, otherwise you would have discovered the bug yourself years ago. So you never accomplished this "trivial" exercise until the late data of 2014.

You have been selling cross-compilers for at least 20 years however. So, how do you write a cross-compiler, and yet not be aware of all of these problems in ANS-Forth? Here is a clue:
https://groups.google.com/forum/#!searchin/comp.lang.forth/lc53/comp.lang.forth/wP5nw1ClzsM/E-TV9v2y9RoJ 
On Tuesday, December 8, 2009 at 3:18:13 PM UTC-7, Stephen Pelc wrote: 
> On Tue, 8 Dec 2009 14:32:02 -0500, Jonah Thomas <jethomas5@gmail.com> 
> wrote: 
> 
> >Suppose you extended the cross-compiler so that the TARGET could be the 
> >HOST . Then you'd have a clear distinction between COMPILER words and 
> >regular words, but the distinction between HOST and TARGET would have 
> >disappeared. 
> 
> There are three types of compilation involved 
> 1) Host compilation 
> 2) Clone compilation (target CPU same as host and memory matches) 
> 3) Cross compilation (target CPU is not host CPU) 
> 
> In the third case you have to simulate *everything* when dealing 
> with both the definition and execution of defining words. It's not 
> easy. You also have to extend the normal Forth compiler by at least 
> two time frames. Forth cross compilers are much more complicated 
> and much more subtle than they appear to be. 
> 
> That's one reason why the cross compiler proposal is the way it is. 
> The big downside of the proposal is that the original was written in 
> a hurry to satisfy EuroPay. It also reflects the state of Forth cross 
> compiler design of about 15 years ago. I have prototyped a design 
> for which the current proposal is inappropriate. 
> 
> Stephen 

This is totally not true! There is no need to simulate the target processor on the host machine at compile-time. I think Stephen is referring to a technique that was used way back in the early 1980s. At that time people had a 6502 Forth system running, but compilation took too long. Their solution was to simulate the 6502 on a PDP-11 and run their Forth system in the simulator for improved speed. In a way this was cross-compilation, because the compiler was running on a PDP-11, but it wasn't really cross-compilation because it was just the traditional Forth system running the same way that it would have run on a 6502, just somewhat faster. 

All of this has already been said here:
https://groups.google.com/forum/#!topic/comp.lang.forth/vUYZ1IYPJug%5B1-25%5D

> >> I was reading about Stephen Pelc's BNF interpreter that is in VFX. It loo=
> >ks pretty interesting. I notice that his code is not ANS-Forth however.
> >>=20
> >> : || IF R> DROP 1 THEN ;
> >>=20
> >> This is obviously illegal in ANS-Forth. Section 3.2.3.3. says:=20
> >> A program shall not access values on the return stack (using R@, R>, 2R@ =
> >or 2R>) that it did not place there using >R or 2>R;
> 
> This is a classic delusion about what standards say. In ANS, depending
> on the return stack holding a return address makes the program
> non-standard. This does not make the technique invalid or mean that
> the standards police will fine me. ANS simply says that the program
> is non-standard and may be difficult to port.

So, you admit that your code is: "non-standard and may be difficult to port." But you also say: "This does not make the technique invalid." 

The purpose of a standard is to allow standard programs to be ported between standard-compliant compilers. Do you disagree? You are a member of the Forth-200x Standard committee --- you should certainly know what the purpose of a standard is --- if you don't (you don't), then Forth-200x is in big trouble!

> As a matter of courtesy, you should at least acknowledge that the
> code for the BNF parser originates with Brad Rodriguez in about 1990
> and precedes ANS-Forth.

You sell it for money --- you don't provide the source-code unless your customers pay you --- actually, I haven't seen any guarantee from you that you do provide the source-code even if your customers buy VFX.

> >Pelc's BNF interpreter is described in the manual, but doesn't see=
> >m to be available in the evaluation version of VFX,
> 
> Wrong. Look for ::= and BNF-VOC. 

All of this discussion of your BNF package was in this thread:
https://groups.google.com/forum/#!topic/comp.lang.forth/CYR7FhjYMkg
This is what I said:
On Monday, April 11, 2016 at 8:00:09 PM UTC-7, hughag...@gmail.com wrote:
> On Monday, April 11, 2016 at 2:45:16 AM UTC-7, Stephen Pelc wrote:
> > The world's greatest and only Forth programmer appears not be able to
> > read. Try
> >   whereis ::=
> > in the console of the Eval version. The resource compiler supplied
> > with VFX Forths for Windows makes heavy use of the BNF parser.
> 
> I did this:
> whereis <BNF
> 
> I was told that it wasn't there, so I didn't bother looking any further
> 
> Now, reading your post, I did this:
> whereis ::= 
> File: %VFXPATH%\VFXBase\BNF.fth, line 747  ok
> 
> Unfortunately, there is no BNF.fth file provided with the evaluation version. Maybe if I paid you for the pro version I would get the BNF.fth file, but maybe not as there is no guarantee made on this anywhere.
> 
> I'm not realistically going to use your BNF stuff if I don't have the source-code. You documented <BNF and BNF> but they aren't available, so that was misleading. Also, your documentation is very vague. Here is an example:
> ------------------------------------------------------------------------
> ::= name starts the definition of the BNF production name.
> ;; ends a BNF definition.
> ------------------------------------------------------------------------
> 
> That doesn't really tell me anything about what they do. You aren't providing a stack-picture for your words or really giving me any information at all.
> 
> You are assuming that I am a "user" who is going to use this code without understanding how it works. You are also assuming that I am a "client" who is okay with vendor lock-in to VFX.
> 
> If you aren't going to provide the BNF.fth file and/or if it is not written in ANS-Forth (I'll bet it is not!), then I have no interest in using your BNF stuff --- I already said that my string-stack.4th can do everything that is needed --- so I recommend that everybody just ignore your BNF stuff and use string-stack.4th to get "commercial level string handling."

[toc] | [prev] | [next] | [standalone]

#47536

From	anton@mips.complang.tuwien.ac.at (Anton Ertl)
Date	2016-05-26 10:02 +0000
Message-ID	<2016May26.120218@mips.complang.tuwien.ac.at>
In reply to	#47517

hughaguilar96@gmail.com writes:
>This is totally untrue. My disambiguifiers make *ALL* ANS-Forth systems beh=
>ave the same in regard to FIND. Your VFX has the words that were traditiona=
>lly immediate (such as IF etc.) being non-immediate and being special-cased=
> by COMPILE, so they execute at compile-time like immediate words. GFORTH h=
>as FIND return different xt values for these words depending upon the value=
> of STATE at the time that FIND is executed. Using FIND or tick on these wo=
>rds is an ambiguous condition, so pretty much anything can be done (includi=
>ng reformatting the hard-disk) and that would be ANS-Forth compliant.

There is no ambiguous condition specified for FIND.  And if you do BL
WORD FIND, or apply FIND to any other kind of counted string, the
results are as specified in the specification of FIND:
<http://forth-standard.org/standard/core/FIND>:

|FIND ( c-addr -- c-addr 0 | xt 1 | xt -1 )
|
|Find the definition named in the counted string at c-addr. If the
|definition is not found, return c-addr and zero. If the definition is
|found, return its execution token xt. If the definition is immediate,
|also return one (1), otherwise also return minus-one (-1). For a given
|string, the values returned by FIND while compiling may differ from
|those returned while not compiling.

So it does not specify the xt or immediacy exactly, but formatting the
hard disk is not in the book.  Admittedly, if you point c-addr to some
memory-mapped I/O registers that perform some action on reading the
registers, you may get interesting results, but that's the same as
with any other memory access to memory not provided by the Forth
system.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2016: http://www.euroforth.org/ef16/

[toc] | [prev] | [next] | [standalone]

#47545

From	hughaguilar96@gmail.com
Date	2016-05-26 10:19 -0700
Message-ID	<42179977-3f41-4d96-ad6d-077a5306e0fa@googlegroups.com>
In reply to	#47536

On Thursday, May 26, 2016 at 3:13:34 AM UTC-7, Anton Ertl wrote:
> There is no ambiguous condition specified for FIND.  
> ...
> |FIND ( c-addr -- c-addr 0 | xt 1 | xt -1 )
> |
> |For a given
> |string, the values returned by FIND while compiling may differ from
> |those returned while not compiling.

LOL!

Also, from the ANS-Forth document's section (4.1.2) with the ominous heading: "Ambiguous Conditions." One of the many ambiguous conditions is: "attempting to obtain the execution token, (e.g., with 6.1.0070 ', 6.1.1550 FIND, etc.) of a definition with undefined interpretation semantics."

Another hallmark of a cult is that their belief-system involves koan-like questions such as: "What is the execution token of a word that has no execution semantics?"

Here is one of my disambiguifiers (soon in this post we will get a sense of deja-vu when we see Anton Ertl write a disambiguifier in 2009 for ; which he now claims is not ambiguous):

: ;  state @ 0= abort" *** no interpretation semantics for: ; ***"           
     postpone ;  ; immediate

You said: "There is no ambiguous condition specified for FIND." You are a liar! You are trying to cover up for Elizabeth Rather's incompetence with blatant lies --- this is cult behavior --- the hallmark of a cult is that the members blatantly lie in an effort to cover up the idiocy of their cult leader, and even when their lies are obvious they just continue to lie anyway because they can't face any aspect of the truth as that would cause their entire belief-system to fall like a house-of-cards.

What is really pathetic about this, is that you yourself invented the disambiguifiers for FIND so you obviously know that FIND is ambiguous, but now you refuse to accept the disambiguifiers (because Elizabeth Rather has told you that she will kick you out of the Forth-200x committee if you do).

https://groups.google.com/forum/#!searchin/comp.lang.forth/lc53/comp.lang.forth/wP5nw1ClzsM/E-TV9v2y9RoJ 

On Thursday, November 26, 2009 at 3:24:06 AM UTC-7, Anton Ertl wrote: 
> Hugh Aguilar <hugoaguilar@rosycrew.com> writes: 
> >On Nov 25, 4:14=A0am, an...@mips.complang.tuwien.ac.at (Anton Ertl) 
> >wrote: 
> >> >On Nov 25, 8:57=3DA0am, Hugh Aguilar <hugoagui...@rosycrew.com> wrote: 
> >> >> I don't use gforth. What does that error message mean? What is a 
> >> >> "compile-only word?" 
> >> 
> >> A word without interpretation semantics. 
> >> 
> >> >It doesn't like you taking the address of ";" , though I don't 
> >> >understand why. 
> >> 
> >> Because ";" has no execution or interpretation semantics. =A0The 
> >> execution token returned by ['] represents the execution semantics, 
> >> but since ";" does not have that ... 
> > 
> >I don't understand how a word can not have execution semantics. 
> 
> That's quite simple: By not defining execution semantics in the 
> definition of the word in the standard document.  Look up the 
> definition of ";" in the standard, and you will see that there is no 
> "Execution:" section there; and there are other labeled sections 
> there, so the "omitted label" sentence of 3.4.3.1 does not apply. 
> 
> >For immediate words (IF, ;, etc.) 
> 
> IF and ";" are not immediate words in the standard.  A system can 
> implement them as immediate words, but a program cannot rely on their 
> immediacy. 
> 
> >I looked up ['] in the ANS-Forth document and it says: 
> > 
> >"Place name's execution token xt on the stack." 
> 
> What's the execution token of a word that has no execution semantics. 
> 
> Hmm, since you think that ";" is immediate, I guess you want an 
> execution token that, when executed, performs the compilation 
> semantics.  You can get that as follows.  Before the rest of the 
> program, define: 
> 
> : ; postpone ; ; immediate 
> 
> Now you have an immediate ";" with an execution semantics that's the 
> same as the compilation semantics, and you can tick it. 
> 
> >What I am saying is that I didn't have any warning that what I was 
> >doing in MACRO: was going to be a problem. 
> 
> A system that would tell us all non-standard usages would be nice, but 
> we don't have that.  For now the solution is to test on as many 
> systems as possible. 
> 
> - anton

[toc] | [prev] | [next] | [standalone]

#47493

From	"WJ" <w_a_x_man@yahoo.com>
Date	2016-05-25 01:18 +0000
Message-ID	<ni2ugv$h8p$1@dont-email.me>
In reply to	#47487

Stephen Pelc wrote:

> > This is not ANS-Forth.
> 
> How do you know?

It's significant that he didn't say, "It is ANS Forth."

-- 
[T]he number of Jews killed there was 800,000,000.... [T]he Talmud makes it all
clear by informing us that the blood of the holocausted Jews ran to the sea in
a huge tidal wave that swept boulders in its path and was so deep that it
reached the nostrils of the Romans' horses.
nationalvanguard.org/2014/09/disillusioned-part-1/

[toc] | [prev] | [next] | [standalone]

#47436

From	"Elizabeth D. Rather" <erather@forth.com>
Date	2016-05-22 21:15 -1000
Message-ID	<na2dnXSqxYyQM9_KnZ2dnUU7-LHNnZ2d@supernews.com>
In reply to	#47430

On 5/22/16 5:38 PM, Paul Rubin wrote:
> Raimond Dragomir <raimond.dragomir@gmail.com> writes:
>> For mid-end embedded systems C is the only way. Don't tell me you will
>> implement file systems, tcp/ip stacks, USB stacks, Wireless stacks in
>> assembly...
>
> Until not that long ago, an embedded system with that much stuff would
> have been considered high end.  Mid-end would be something capable of
> running interactive Forth, e.g. Atmega128 or so.  Low end would be a
> tiny PIC with a 0.5k of code space and few dozen bytes of ram.
>
> I wonder if Forth was even ever intended to write systems of that
> complexity.  Remember Chuck's adage that 1000 instructions is enough to
> write any program.  I doubt that the NRAO system had tcp/ip stacks, USB
> stacks, wireless, etc.
>
> Elizabeth if you're here: this may have come up before, but do you
> remember about how much total Forth code went into the Saudi airport
> system?

Not sure how to measure that. There were 8 pdp-11 computers (4 sets of 
twins) and almost 400 8086-based computers, all running essentially the 
same basic application with several options, one of which was a fairly 
extensive (for the time) graphics capability, all in Forth. There were 
two basic systems, the overall control and database running on the 
pdp-11's, and then the basic 8086 system with various add-ons for the 
different kinds. There was a standard communications protocol that all 
of them used. There is an article about it here:
http://dl.forth.com/jfar/vol3/no2/article4.pdf

I do not know how many lines of code there were at the end, but I know 
that they scrapped ~100 man-years of work (30 programmers, 3.5 years, 
Fortran, PLM, Assembler, with the project <25% complete, over budget, 
and not meeting performance requirements), in about 18 calendar months 
with a team whose max size was 15 (and smaller towards the end).

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."
==================================================

[toc] | [prev] | [next] | [standalone]

#47347

From	Andrew Haley <andrew29@littlepinkcloud.invalid>
Date	2016-05-20 09:47 -0500
Message-ID	<75mdnU18NrINvqLKnZ2dnUU7-N_NnZ2d@supernews.com>
In reply to	#47341

Ron Aaron <rambamist@gmail.com> wrote:
> 
> On 20/05/2016 15:44, Anton Ertl wrote:
> 
>> Yes, although 32-bit Intel is superfluous these days.  Might also
>> happen to 32-bit ARM before we are done with the switch to assembly.
> 
> Don't be so sure.
> 
> I've got people who use 8th on 32-bit Linux systems (and 32-bit
> Windows), and can't or won't switch.  Not to mention that most Android
> devices are 32-bit.

It wasn't obvious to me at first, but ARMv8 is a very clever design
which is just as happy being a 32-bit processor as a 64-bit one.  You
can put ARMv8 into "A64 mode" but use 32-bit words for addresses and
integers, etc.  You get the benefit of more registers and a nicer ISA
to program, but on a 32-bit system.  I wonder if this is worth doing
for something like Android on small systems.

There are still legacy systems and all technologies have a long tail.
I'm sure the 32-bit ARM ISA will be in use for decades.

Andrew.

[toc] | [prev] | [next] | [standalone]

#47348

From	anton@mips.complang.tuwien.ac.at (Anton Ertl)
Date	2016-05-20 15:02 +0000
Message-ID	<2016May20.170203@mips.complang.tuwien.ac.at>
In reply to	#47347

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Ron Aaron <rambamist@gmail.com> wrote:
>It wasn't obvious to me at first, but ARMv8 is a very clever design
>which is just as happy being a 32-bit processor as a 64-bit one.  You
>can put ARMv8 into "A64 mode" but use 32-bit words for addresses and
>integers, etc.  You get the benefit of more registers and a nicer ISA
>to program, but on a 32-bit system.  I wonder if this is worth doing
>for something like Android on small systems.

Very doubtful.  There was an effort to do such a thing for AMD64
<https://en.wikipedia.org/wiki/X32_ABI>, but while the necessary
foundation seems to be there, nobody seems to use it.  My guess is
that if somebody does the comparable thing to ARM, the result will be
the same.

There was also support for something similar on Alpha, and it was used
for building programs that were not 64-bit clean, and some SPEC
benchmarks, but it was not used for anything else.  Overall, the
benefits of limiting yourself to 32 bits on 64-bit platforms seem to
be too small to make people go there.

>I'm sure the 32-bit ARM ISA will be in use for decades.

In the embedded space, yes.  But for smartphones and such, it will be
gone in a decade; not just in the shops, but given the short lifetimes
of these devices, also in the hands of the users.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2016: http://www.euroforth.org/ef16/

[toc] | [prev] | [next] | [standalone]

#47350

From	Andrew Haley <andrew29@littlepinkcloud.invalid>
Date	2016-05-20 11:42 -0500
Message-ID	<I_Sdnf4iYvEXo6LKnZ2dnUU7-bWdnZ2d@supernews.com>
In reply to	#47348

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Ron Aaron <rambamist@gmail.com> wrote:
>>It wasn't obvious to me at first, but ARMv8 is a very clever design
>>which is just as happy being a 32-bit processor as a 64-bit one.  You
>>can put ARMv8 into "A64 mode" but use 32-bit words for addresses and
>>integers, etc.  You get the benefit of more registers and a nicer ISA
>>to program, but on a 32-bit system.  I wonder if this is worth doing
>>for something like Android on small systems.
> 
> Very doubtful.  There was an effort to do such a thing for AMD64
> <https://en.wikipedia.org/wiki/X32_ABI>, but while the necessary
> foundation seems to be there, nobody seems to use it.  My guess is
> that if somebody does the comparable thing to ARM, the result will be
> the same.

There is a significant difference: the x32 ABI was much too late.  By
the time it came along about a decade after AMD64 no-one cared any
more.

But you're probably right anyway.

Andrew.

[toc] | [prev] | [next] | [standalone]

#47352

From	anton@mips.complang.tuwien.ac.at (Anton Ertl)
Date	2016-05-20 16:52 +0000
Message-ID	<2016May20.185250@mips.complang.tuwien.ac.at>
In reply to	#47350

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>There is a significant difference: the x32 ABI was much too late.  By
>the time it came along about a decade after AMD64 no-one cared any
>more.

Too late for what?

There would have been little point in it at the start of AMD64, when
everybody had a CPU with IA-32 support and few had a CPU with AMD64
support.  Nobody would have compiled software for a 32-bit AMD64-only
ABI.  At the time when they introduced it (in 2011), AMD64 was widely
available, so an AMD64-specific 32-bit ABI made much more sense.  It
still did not catch on.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2016: http://www.euroforth.org/ef16/

[toc] | [prev] | [next] | [standalone]

#47353

From	Paul Rubin <no.email@nospam.invalid>
Date	2016-05-20 10:07 -0700
Message-ID	<87k2ioejz5.fsf@jester.gateway.pace.com>
In reply to	#47352

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> At the time when they introduced it (in 2011), AMD64 was widely
> available, so an AMD64-specific 32-bit ABI made much more sense.  It
> still did not catch on.

I'm a little bit confused by this terminology and may be thinking of the
wrong thing.  But I can say for sure there are millions of 32-bit x86
Linux systems in use today and I run a dozen or so of them myself.  The
underlying hardware is generally amd64, but 32-bit Linux is less memory
hungry, so I use it in smaller systems where there is no need to address
more than 2GB of ram, and the speed benefits of 64-bit arithmetic aren't
important.

[toc] | [prev] | [next] | [standalone]

#47354

From	anton@mips.complang.tuwien.ac.at (Anton Ertl)
Date	2016-05-20 17:12 +0000
Message-ID	<2016May20.191240@mips.complang.tuwien.ac.at>
In reply to	#47353

Paul Rubin <no.email@nospam.invalid> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> At the time when they introduced it (in 2011), AMD64 was widely
>> available, so an AMD64-specific 32-bit ABI made much more sense.  It
>> still did not catch on.
>
>I'm a little bit confused by this terminology and may be thinking of the
>wrong thing.  But I can say for sure there are millions of 32-bit x86
>Linux systems in use today and I run a dozen or so of them myself.  The
>underlying hardware is generally amd64, but 32-bit Linux is less memory
>hungry, so I use it in smaller systems where there is no need to address
>more than 2GB of ram, and the speed benefits of 64-bit arithmetic aren't
>important.

x32 was made exactly for people in your situation, but you and others
in that situation continue to use IA-32 or 64-bit AMD64 instead of
x32.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2016: http://www.euroforth.org/ef16/

[toc] | [prev] | [next] | [standalone]

#47355

From	Paul Rubin <no.email@nospam.invalid>
Date	2016-05-20 10:25 -0700
Message-ID	<87futcej5e.fsf@jester.gateway.pace.com>
In reply to	#47354

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> x32 was made exactly for people in your situation, but you and others
> in that situation continue to use IA-32 or 64-bit AMD64 instead of x32.

I'm still confused: are you saying that when I install 32-bit Debian
(i686) on an amd64 machine these days, it's using a 64-bit ABI?  I
really should know, but I don't.  I know that the actual "i686" and
several generations after it were 32-bit machines.

[toc] | [prev] | [next] | [standalone]

#47356

From	anton@mips.complang.tuwien.ac.at (Anton Ertl)
Date	2016-05-20 17:41 +0000
Message-ID	<2016May20.194133@mips.complang.tuwien.ac.at>
In reply to	#47355

Paul Rubin <no.email@nospam.invalid> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> x32 was made exactly for people in your situation, but you and others
>> in that situation continue to use IA-32 or 64-bit AMD64 instead of x32.
>
>I'm still confused: are you saying that when I install 32-bit Debian
>(i686) on an amd64 machine these days, it's using a 64-bit ABI?

No.  It's a plain old IA-32 installation.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2016: http://www.euroforth.org/ef16/

[toc] | [prev] | [next] | [standalone]

#47359

From	Paul Rubin <no.email@nospam.invalid>
Date	2016-05-20 11:12 -0700
Message-ID	<87bn40egzl.fsf@jester.gateway.pace.com>
In reply to	#47356

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> No.  It's a plain old IA-32 installation.

I thought that meant i386, which is being eliminated from Debian.  I
guess that only affects instruction selection rather than the ABI
though.  Ok, thanks.

[toc] | [prev] | [next] | [standalone]

#47394

From	anton@mips.complang.tuwien.ac.at (Anton Ertl)
Date	2016-05-21 05:33 +0000
Message-ID	<2016May21.073328@mips.complang.tuwien.ac.at>
In reply to	#47359

Paul Rubin <no.email@nospam.invalid> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> No.  It's a plain old IA-32 installation.
>
>I thought that meant i386, which is being eliminated from Debian.

Yes, the 386 was the first IA-32 processor.  Later they added a few
more instructions (IIRC BSWAP in the 486, CMOVcc in the P6 (Pentium
Pro, Pentium II ff.)), and some other features such as PAE (P6), but
if we contrast it with AMD64 and the AMD64 ABI x32, it's still in the
IA-32 category.  To differentiate between the minor variants, the
Linux kernel and Linux distributions use i386, i586, i686.  My guess
is that the differences they care about is mainly kernel-mode features
like page table capabilities, but googling for that did not bring up
anything enlightening.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2016: http://www.euroforth.org/ef16/

[toc] | [prev] | [next] | [standalone]

#47361

From	Lars Brinkhoff <lars.spam@nocrew.org>
Date	2016-05-20 21:13 +0200
Message-ID	<86mvnkk0fk.fsf@molnjunk.nocrew.org>
In reply to	#47353

Paul Rubin <no.email@nospam.invalid> writes:
> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> At the time when they introduced it (in 2011), AMD64 was widely
>> available, so an AMD64-specific 32-bit ABI made much more sense.  It
>> still did not catch on.
> I'm a little bit confused by this terminology and may be thinking of the
> wrong thing.

Maybe read this?
https://en.wikipedia.org/wiki/X32_ABI

[toc] | [prev] | [next] | [standalone]

Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →

csiph-web

Was just wondering when people started using C to write forth languages and not assembly?

Contents

#47485

#47487

#47488

#47505

#47517

#47536

#47545

#47493

#47436

#47347

#47348

#47350

#47352

#47353

#47354

#47355

#47356

#47359

#47394

#47361