Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

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

Renaissance of Forth

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

Contents

  Renaissance of Forth visualforth@rocketmail.com - 2011-03-31 16:06 -0700
    Re: Renaissance of Forth Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-04-01 02:29 -0500
    Re: Renaissance of Forth Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-04-01 12:46 +0000
      Re: Renaissance of Forth Dennis <daruffer@gmail.com> - 2011-04-01 07:36 -0700
        Re: Renaissance of Forth Brad <hwfwguy@gmail.com> - 2011-04-01 07:47 -0700
        Re: Renaissance of Forth John Passaniti <john.passaniti@gmail.com> - 2011-04-01 16:40 -0700
          Re: Renaissance of Forth BruceMcF <agila61@netscape.net> - 2011-04-01 18:20 -0700
      Re: Renaissance of Forth Paul Rubin <no.email@nospam.invalid> - 2011-04-01 12:34 -0700
        Re: Renaissance of Forth Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-04-02 00:23 +0000
          Re: Renaissance of Forth Paul Rubin <no.email@nospam.invalid> - 2011-04-01 16:24 -0700
    Re: Renaissance of Forth Gary Bergstrom <g.bergstrom@ieee.org> - 2011-04-01 08:36 -0700
    Re: Renaissance of Forth "The Beez'" <hansoft@bigfoot.com> - 2011-04-01 16:04 -0700
      Re: Renaissance of Forth mhx@iae.nl (Marcel Hendrix) - 2011-04-02 10:40 +0200
        Re: Renaissance of Forth John Passaniti <john.passaniti@gmail.com> - 2011-04-02 14:50 -0700
          Re: Renaissance of Forth "Massimo A. Dentico" <massimo_dentico@hotmail.com> - 2011-04-03 00:34 +0200
            Re: Renaissance of Forth John Passaniti <john.passaniti@gmail.com> - 2011-04-02 21:08 -0700
              Re: Renaissance of Forth mhx@iae.nl (Marcel Hendrix) - 2011-04-03 09:24 +0200
                Re: Renaissance of Forth John Passaniti <john.passaniti@gmail.com> - 2011-04-03 15:45 -0700
                  Re: Renaissance of Forth Paul Rubin <no.email@nospam.invalid> - 2011-04-03 16:45 -0700
                    Re: Renaissance of Forth Elizabeth D Rather <erather@forth.com> - 2011-04-03 14:01 -1000
                      Re: Renaissance of Forth Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-04-06 22:43 +0000
                    Re: Renaissance of Forth BruceMcF <agila61@netscape.net> - 2011-04-03 17:34 -0700
                      Re: Renaissance of Forth John Passaniti <john.passaniti@gmail.com> - 2011-04-04 10:55 -0700
                        Re: Renaissance of Forth pliz <s.m.plis@gmail.com> - 2011-04-04 13:11 -0700
                          Re: Renaissance of Forth John Passaniti <john.passaniti@gmail.com> - 2011-04-05 09:10 -0700
                        Re: Renaissance of Forth BruceMcF <agila61@netscape.net> - 2011-04-04 16:33 -0700
                          Re: Renaissance of Forth Elizabeth D Rather <erather@forth.com> - 2011-04-04 16:31 -1000
                            Re: Renaissance of Forth BruceMcF <agila61@netscape.net> - 2011-04-04 19:52 -0700
                              Re: Renaissance of Forth John Passaniti <john.passaniti@gmail.com> - 2011-04-05 09:58 -0700
                                Re: Renaissance of Forth BruceMcF <agila61@netscape.net> - 2011-04-05 18:36 -0700
                                  Re: Renaissance of Forth John Passaniti <john.passaniti@gmail.com> - 2011-04-06 13:53 -0700
                                    Re: Renaissance of Forth BruceMcF <agila61@netscape.net> - 2011-04-06 15:29 -0700
                                      Re: Renaissance of Forth John Passaniti <john.passaniti@gmail.com> - 2011-04-07 08:35 -0700
                                        Re: Renaissance of Forth BruceMcF <agila61@netscape.net> - 2011-04-07 16:20 -0700
                          Re: Renaissance of Forth Alex McDonald <blog@rivadpm.com> - 2011-04-05 08:56 -0700
                          Re: Renaissance of Forth John Passaniti <john.passaniti@gmail.com> - 2011-04-05 09:35 -0700
                        Re: Renaissance of Forth Bluebee <visualforth@rocketmail.com> - 2011-04-06 17:48 -0700
                        Re: Renaissance of Forth Bluebee <visualforth@rocketmail.com> - 2011-04-12 15:47 -0700
                          Re: Renaissance of Forth John Passaniti <john.passaniti@gmail.com> - 2011-04-13 09:27 -0700
                            Re: Renaissance of Forth Bluebee <visualforth@rocketmail.com> - 2011-04-13 09:55 -0700
                              Re: Renaissance of Forth Richard Owlett <rowlett@pcnetinc.com> - 2011-04-13 13:02 -0500
                              Re: Renaissance of Forth Elizabeth D Rather <erather@forth.com> - 2011-04-13 09:01 -1000
                              Re: Renaissance of Forth Micke <oh2aun@gmail.com> - 2011-04-13 13:23 -0700
                                Re: Renaissance of Forth Bluebee <visualforth@rocketmail.com> - 2011-04-13 20:32 -0700
                                  Re: Renaissance of Forth Micke <oh2aun@gmail.com> - 2011-04-13 20:52 -0700
                                    Re: Renaissance of Forth Bluebee <visualforth@rocketmail.com> - 2011-04-13 22:26 -0700
                                      Re: Renaissance of Forth Micke <oh2aun@gmail.com> - 2011-04-13 23:42 -0700
                                        Re: Renaissance of Forth Bluebee <visualforth@rocketmail.com> - 2011-04-14 10:42 -0700
                                          Re: Renaissance of Forth Micke <oh2aun@gmail.com> - 2011-04-14 13:06 -0700
                                            Re: Renaissance of Forth Bluebee <visualforth@rocketmail.com> - 2011-04-14 14:26 -0700
                                              Re: Renaissance of Forth Micke <oh2aun@gmail.com> - 2011-04-14 21:31 -0700
                                                Re: Renaissance of Forth Bluebee <visualforth@rocketmail.com> - 2011-04-14 23:42 -0700
                                                  Re: Renaissance of Forth Micke <oh2aun@gmail.com> - 2011-04-15 00:56 -0700
                                            Re: Renaissance of Forth John Passaniti <john.passaniti@gmail.com> - 2011-04-15 08:03 -0700
                                              Re: Renaissance of Forth Micke <oh2aun@gmail.com> - 2011-04-15 09:28 -0700
                                                Re: Renaissance of Forth John Passaniti <john.passaniti@gmail.com> - 2011-04-15 10:28 -0700
                              Re: Renaissance of Forth John Passaniti <john.passaniti@gmail.com> - 2011-04-13 20:40 -0700
                                Re: Renaissance of Forth Bluebee <visualforth@rocketmail.com> - 2011-04-13 22:57 -0700
                    Re: Renaissance of Forth John Passaniti <john.passaniti@gmail.com> - 2011-04-04 08:39 -0700
                      Re: Renaissance of Forth Paul Rubin <no.email@nospam.invalid> - 2011-04-04 09:41 -0700
                  Re: Renaissance of Forth Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-04-06 22:39 +0000
    Re: Renaissance of Forth Bluebee <visualforth@rocketmail.com> - 2011-04-02 20:32 -0700
      Re: Renaissance of Forth John Passaniti <john.passaniti@gmail.com> - 2011-04-02 22:06 -0700
        Re: Renaissance of Forth BruceMcF <agila61@netscape.net> - 2011-04-03 07:17 -0700
    Re: Renaissance of Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-04-04 17:09 +0000
      Re: Renaissance of Forth Bernd Paysan <bernd.paysan@gmx.de> - 2011-04-05 15:55 +0200
        Re: Renaissance of Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-04-07 16:25 +0000
          Re: Renaissance of Forth Bernd Paysan <bernd.paysan@gmx.de> - 2011-04-08 21:07 +0200
            Re: Renaissance of Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-04-09 17:29 +0000
              Re: Renaissance of Forth Bernd Paysan <bernd.paysan@gmx.de> - 2011-04-10 18:39 +0200
        redirecting TYPE to a string (was: Renaissance of Forth) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-04-09 16:54 +0000
          Re: redirecting TYPE to a string (was: Renaissance of Forth) BruceMcF <agila61@netscape.net> - 2011-04-09 13:07 -0700
          Re: redirecting TYPE to a string (was: Renaissance of Forth) Bernd Paysan <bernd.paysan@gmx.de> - 2011-04-10 18:07 +0200

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

#1026

In article <dbfb1c4d-8086-4973-b44c-a03f8d39cbef@j13g2000yqj.googlegroups.com>,
John Passaniti  <john.passaniti@gmail.com> wrote:
<SNIP>
>
>Again, people who find the idea presented by the OP interesting need
>to stop thinking about how you implement another language in Forth,
>because that is easy, largely uninteresting, and not terribly
>challenging.  Instead, actually write code in this proposed hybrid
>language and think about the mechanisms behind the scenes to allow
>both languages to work with each other.  That's where things get messy
>very quickly, and where creative solutions to the technical challenges
>are.

This is very true.

E.g. from a practical point of view, the most
valuable pieces of c-code are device drivers.
But here the unix paradigm rules:
everything-is-a-file, open-read-write-close and an occasional ioctl.
There is little difficulty in using those, e.g. a generic
OS call to linux from a Forth. You just must know the ioctl's
of your midi device etc.

Maybe the interface at the os boundary is what we must concentrate
on. Then it is equally easy to call device drivers in C
from Forth code, as it is to call Forth code from C.
(Assuming there is a brave soul who writes a linux device
driver in Forth. It must be tried. Maybe we'll discover that it
is has advantages.)

This easy talk about interfacing, still has it roots in the
time that a compiler was a thin layer to generate assembly
code. At the assembly code level there is no mismatch between
languages, only a massive pile of practical difficulties and
tedious work. For FORTH-C interfacing it is nonsensical because
Forth is not the type of compiler that passes assembly code
to a linker.

Groetjes Albert

--
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

#978

On Mar 31, 7:06 pm, visualfo...@rocketmail.com wrote:
> In 1984 I started with RSC-Forth with the R65F11 microprocessor and
> used Forth ever since.
>
> ... each Forth should have a C compiler to write machine
> code by using C instead of assembler.
> ...
> Adding a C compiler to Forth may lead to a Renaissance of Forth.
> This may be the missing link for many.
>

Thanks for all your comments. Being a newbee to comp.lang.forth, I now
did my homework which I should have done before, and I found a lot of
interesting messages.

Elizabeth D. Rather wrote on Aug 19, 1998, 3:00 am:
> If "any Forth" is of interest, both polyFORTH and SwiftForth are
> multitasking systems that have built-in facilities for calling C
> functions.
So, calling C functions should be possible. I didn't know that.

Jan 30 2002, 6:55 am  Albert van der Horst wrote:
> gcc produces assembly output
So gcc was a good guess!

And there even was some heavy fighting:
> lets face it, you either like K&R or you like Chuck Moore, and
> that's it. If you want something inbetween you're on your own....

I hope I am not on my own. I appreciate your support in this - not
only my - idea.

Meanwhile I see it will be some kind of a challenge, and may be I was
some kind of naive to believe that writing a C compiler is comparable
to writing an Assembler. But I am still sure, looking at both as a
black box between the words code: and ;code it will be feasible to get
it done, looking at a an inline C-compiler doing the same thing as the
inline Forth Assembler does: producing inline machine code. May be
this C-compiler should make an exception not using RPN to make it
possible to cut and paste snippets of C-code. So often I have heard
that nothing is impossible with Forth.
And my experience is that it is easier to learn C than to learn
Assembler - and more powerful to use Forth.

By the way, searching through hundreds of messages I dicovered that
there has been a Forth nearly like the one I thought it should be, and
there even is a code example to show how it looks like:

On Thu, Sep 3 1998, 3:00 am, dscha...@my-dejanews.com wrote:
I just dynamically compile a snippet of C code via calls
to gcc and as and just lay the code down just like code written is a
forth assembler would get laid down.
But of course I can't have access external C libraries, or anthing
else of the sort. That is not the intent of what I am trying to doing.
It gives me a facility to rapidly lay down new code primitives and
test small snippets of C code. The C code compiles fast, because their
are no massive include files to suck in (only a heavily macrofied
header file containing the forth dictionary and macros for such things
as PUSH and POP. And of course no linking. I just output assembly,
pass that to gnu as, and parse the listing. It works, as I guess gcc
is generating position independant code, even though I did not tell it
to.
So C can be a dynamic, when it lives inside of a Forth
enviornment ;-)
( Of course, you can't type in single C statement, you have to type in
a whole function)
I can type in following at the forth command line:

(0/0/31408/4096/10) ok
GCC_CODE: NEG4*7 start /* { n - (n-4)*7 } */ void start(void){
PUSH((POP()-4)*7); } ;GCC_CODE
Layed down code for NEG4*7 (11 CELLS)
(0/0/31360/4096/10) ok
8 NEG4*7 .
28 (0/0/31360/4096/10) ok

It is more or less instentaneous. I hear the computer hit the drive
momentarily and the prompt comes right back. I lay down a lot of
primitives in included forth files this way. Makes for very rapid
development and the assembly can be cleaned up by hand later if
it is too slow.
-.-

It's a pity that there is no link to further information.
The authors email address is not valid any more.
DB

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

#981

On Apr 2, 11:32 pm, Bluebee <visualfo...@rocketmail.com> wrote:
> And there even was some heavy fighting:
>
> > lets face it, you either like K&R or you like Chuck Moore,
> > and that's it. If you want something inbetween you're on
> > your own....

"Fighting" seems a little overly dramatic.  There are some people who
have strong views, often driven from some ideology.  And they like to
divide the world up into different factions because it's easier to
think in terms of "them" versus "us" if you don't have to consider the
majority who are somewhere in the middle.  That's not unique to
Forth.  It's fundamental to human nature and extends to practically
every endeavor.  And personally, as one of the people in the middle,
it's loads more fun being a thorn in the side of those who demand
ideological purity and who want to dress disagreement up with dramatic
war metaphors.

> Meanwhile I see it will be some kind of a challenge, and may
> be I was some kind of naive to believe that writing a C compiler
>  is comparable to writing an Assembler. But I am still sure,
> looking at both as a black box between the words code: and
> ;code it will be feasible to get it done, looking at a an
> inline C-compiler doing the same thing as the inline Forth
> Assembler does: producing inline machine code.

Again, my best suggestion if you want to explore this is to write code
in this hybrid language.  You don't need a functioning system to test
out your idea in your head and to think about syntax and semantics.
And by doing that, you'll very quickly see the problems.  Maybe you'll
come up with some creative solution.

> May be this C-compiler should make an exception not using RPN
> to make it possible to cut and paste snippets of C-code. So
> often I have heard that nothing is impossible with Forth.

Nothing is impossible with any language.  You could write an APL
interpreter in COBOL that you embedded in Forth if you want.  The
question is never if it is possible, but if it makes sense.

> By the way, searching through hundreds of messages I dicovered
> that there has been a Forth nearly like the one I thought it
> should be, and there even is a code example to show how it
> looks like:

There are far easier ways to do this.  On a x86 platform, you could
use TCC in library form (libtcc) and submit C code and get back a
pointer to the function.  And I can easily imagine taking a C compiler
like lcc and building a Forth shell in it.  Building your idea on a
virtual platform like LLVM might make even more sense.  It's all
possible.

But does it make sense?  You won't know that until you show us what
code in this proposed hybrid language looks like.  The mechanisms of
binding a C compiler and a Forth compiler together is conceptually
EASY.  The syntax and semantics of the result language is HARD, unless
you're willing to do one or more of the following:

1.  Break compatibility by extending C syntax to support things like
returning multiple values.

2.  Restrict C to a subset of the language.

3.  Restrict what Forth code can be called from C.

4.  Restrict what C code can be called from Forth.

5.  Write C functions and Forth words that handle the impedance
mismatch.

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

#988

On Apr 3, 1:06 am, John Passaniti <john.passan...@gmail.com> wrote:
> But does it make sense?  You won't know that until you show us what
> code in this proposed hybrid language looks like.  The mechanisms of
> binding a C compiler and a Forth compiler together is conceptually
> EASY.  The syntax and semantics of the result language is HARD, unless
> you're willing to do one or more of the following:
>
> 1.  Break compatibility by extending C syntax to support things like
> returning multiple values.
>
> 2.  Restrict C to a subset of the language.
>
> 3.  Restrict what Forth code can be called from C.
>
> 4.  Restrict what C code can be called from Forth.
>
> 5.  Write C functions and Forth words that handle the impedance
> mismatch.

Yes, a CCODE: ... ;CCODE approach relies on 3 and half of 5 ... the C
code is used to paste together functions in either an external C
library or copied and pasted from an existing C source into a form
that is conveniently called as a Forth word, and Forth words that
follow some already established syntax for calling external or
embedded C functions are used to specify the Forth word that acts as
the interface to the C code.

Indeed, an existing syntax for calling external library functions
could be copied verbatim, except CCODE: brings in an alternate wordset
that knows that the function being referred to will be defined in C
code in the balance of the CCODE: segment.

And, yes, compiling to the end of the main pseudofunction and then
handing the text from the end of the C function through to ;CCODE to
tcc as a library would seem to be a straightforward way to go about it.

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

#999

visualforth@rocketmail.com writes:
>My revelation with this project which urged me to use C - and getting
>the feeling to be back in "stone age" (that means back to thirty years
>ago) - is that each Forth should have a C compiler to write machine
>code by using C instead of assembler.

Bernd Paysan has done something like this in one of his
implementations of his "Wurstkessel" cryptographic algorithm.  He used
the libcc stuff in Gforth in an unusual way to merge C and Forth in an
interesting way.  Unfortunately, the material that I found about this
stuff don't show this implementation, only the plain Forth code.
Maybe he can post something about this work.

- 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 2010: http://www.euroforth.org/ef10/

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

#1010

Anton Ertl wrote:

> visualforth@rocketmail.com writes:
>>My revelation with this project which urged me to use C - and getting
>>the feeling to be back in "stone age" (that means back to thirty years
>>ago) - is that each Forth should have a C compiler to write machine
>>code by using C instead of assembler.
> 
> Bernd Paysan has done something like this in one of his
> implementations of his "Wurstkessel" cryptographic algorithm.  He used
> the libcc stuff in Gforth in an unusual way to merge C and Forth in an
> interesting way.  Unfortunately, the material that I found about this
> stuff don't show this implementation, only the plain Forth code.
> Maybe he can post something about this work.

The actual source is here:

http://www.forth-ev.de/repos/bigforth/wurstkessel.fs

I use the picture number output to create the C lines, but I'm not so 
happy with it.  E.g. that's what I think it should look like:

: mix2bytes_ind, ( index n k i -- index n ) >r
    >r over r@ 64 + swap
    %> a<% r@ 7 and 0 .r %> ^=ROL(rnds[states[<% 0 .r %> ]^(0xff&(t>><%
    $7 and 8 * 0 .r %> ))],<% r> 7 r@ - 0 .r %> );<% \c, ;

and that's how it actually looks like:

: mix2bytes_ind, ( index n k i -- index n ) >r
    >r over r@ 64 +
    <<#
    s" );" holds r> 7 r@ - 0 #s 2drop >r
    s" ))]," holds $7 and 8 * 0 #s 2drop
    s" ]^(0xff&(t>>" holds 0 #s 2drop
    s" ^=ROL(rnds[states[" holds r@ 7 and 0 #s 2drop
    s" a" holds 0. #> \c, #>>
    rdrop rdrop ;

I really should rewrite this using %>, which is defined as follows:

: %> ( -- )
    BEGIN  source >in @ /string s" <%" search  0= WHILE
        postpone sliteral postpone type
        refill  0= UNTIL  EXIT  THEN
    nip source >in @ /string rot - dup 2 + >in +!
    postpone sliteral postpone type ;  immediate

Then the C/Forth mixture code is in order, not reverse order.  Problem 
here: <% feeds to TYPE, and \c, expects a string on the stack.  This can 
be solved somehow by using redirection (TYPE is deferred).

With the current development version of Gforth, the pictured number 
output buffer is too small to let wurstkessel.fs run, so there has to be 
done something, anyways.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/

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

#1045

Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>
>> visualforth@rocketmail.com writes:
>>>My revelation with this project which urged me to use C - and getting
>>>the feeling to be back in "stone age" (that means back to thirty years
>>>ago) - is that each Forth should have a C compiler to write machine
>>>code by using C instead of assembler.
>> 
>> Bernd Paysan has done something like this in one of his
>> implementations of his "Wurstkessel" cryptographic algorithm.  He used
>> the libcc stuff in Gforth in an unusual way to merge C and Forth in an
>> interesting way.  Unfortunately, the material that I found about this
>> stuff don't show this implementation, only the plain Forth code.
>> Maybe he can post something about this work.
>
>The actual source is here:
>
>http://www.forth-ev.de/repos/bigforth/wurstkessel.fs

Cool, but probably not really useful for people who have not been
introduced to the idea.  Maybe you can post and explain a small
example of the technique here.

>Then the C/Forth mixture code is in order, not reverse order.  Problem 
>here: <% feeds to TYPE, and \c, expects a string on the stack.  This can 
>be solved somehow by using redirection (TYPE is deferred).

Yes, I have been thinking about how we could construct strings using
TYPE redirected to a buffer; stuff like this would be useful in, e.g.,
dis-gdb and libcc.  No concrete plans yet, though.

>With the current development version of Gforth, the pictured number 
>output buffer is too small to let wurstkessel.fs run, so there has to be 
>done something, anyways.

Well, if the pictured numeric output string buffer is too small, that
can be fixed.

- 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 2010: http://www.euroforth.org/ef10/

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

#1069

Anton Ertl wrote:

> Bernd Paysan <bernd.paysan@gmx.de> writes:
>>The actual source is here:
>>
>>http://www.forth-ev.de/repos/bigforth/wurstkessel.fs
> 
> Cool, but probably not really useful for people who have not been
> introduced to the idea.  Maybe you can post and explain a small
> example of the technique here.

Ok, let's start really trivial:

c-library foo
\c int add(int a, int b) { return a+b; }
c-function add add n n -- n
end-c-library

This creates a small C library, with a function "add" (adds two numbers) 
and a binding from Forth to call this add.  You can enter this just on 
the Gforth command line, it will take a little longer than a normal 
assembler code word, because it calls the C compiler, but it's fully 
interactive, and after the end-c-library and return, you can try it:

1 2 add . 3  ok

The more complex part are the macros; instead of writing "\c something", 
I generate the C code from Forth, as well.

>>With the current development version of Gforth, the pictured number
>>output buffer is too small to let wurstkessel.fs run, so there has to
>>be done something, anyways.
> 
> Well, if the pictured numeric output string buffer is too small, that
> can be fixed.

It wasn't too small, there was one nesting problem.  I still rewrote it 
to use the %> technique, though not through TYPE redirection.  It's a 
lot more readable that way.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/

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

#1086

Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>
>> Bernd Paysan <bernd.paysan@gmx.de> writes:
>>>With the current development version of Gforth, the pictured number
>>>output buffer is too small to let wurstkessel.fs run, so there has to
>>>be done something, anyways.
>> 
>> Well, if the pictured numeric output string buffer is too small, that
>> can be fixed.
>
>It wasn't too small, there was one nesting problem.

Hmm, given that the current pictured numeric output implementation was
specifically designed to be nestable, that's worrying.  Could you
provide a test case for this nesting problem?

- 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 2010: http://www.euroforth.org/ef10/

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

#1124

Anton Ertl wrote:
> Hmm, given that the current pictured numeric output implementation was
> specifically designed to be nestable, that's worrying.  Could you
> provide a test case for this nesting problem?

The problem was rather trivial - I didn't unnest in one case, which left 
part of the buffer allocated, and then the next string didn't fit into 
the remaining space.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/

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

#1085 — redirecting TYPE to a string (was: Renaissance of Forth)

Bernd Paysan <bernd.paysan@gmx.de> writes:
>I use the picture number output to create the C lines, but I'm not so 
>happy with it.  E.g. that's what I think it should look like:
>
>: mix2bytes_ind, ( index n k i -- index n ) >r
>    >r over r@ 64 + swap
>    %> a<% r@ 7 and 0 .r %> ^=ROL(rnds[states[<% 0 .r %> ]^(0xff&(t>><%
>    $7 and 8 * 0 .r %> ))],<% r> 7 r@ - 0 .r %> );<% \c, ;
>
>and that's how it actually looks like:
>
>: mix2bytes_ind, ( index n k i -- index n ) >r
>    >r over r@ 64 +
>    <<#
>    s" );" holds r> 7 r@ - 0 #s 2drop >r
>    s" ))]," holds $7 and 8 * 0 #s 2drop
>    s" ]^(0xff&(t>>" holds 0 #s 2drop
>    s" ^=ROL(rnds[states[" holds r@ 7 and 0 #s 2drop
>    s" a" holds 0. #> \c, #>>
>    rdrop rdrop ;
>
>I really should rewrite this using %>, which is defined as follows:
>
>: %> ( -- )
>    BEGIN  source >in @ /string s" <%" search  0= WHILE
>        postpone sliteral postpone type
>        refill  0= UNTIL  EXIT  THEN
>    nip source >in @ /string rot - dup 2 + >in +!
>    postpone sliteral postpone type ;  immediate

What does %> do that we cannot do with ." and .\", which are much more
familiar to Forth programmers.

>Then the C/Forth mixture code is in order, not reverse order.  Problem 
>here: <% feeds to TYPE, and \c, expects a string on the stack.  This can 
>be solved somehow by using redirection (TYPE is deferred).

Yes, redirecting TYPE to a string is a good way to construct strings
in Forth, so I have implemented it
<http://www.complang.tuwien.ac.at/viewcvs/cgi-bin/viewcvs.cgi/gforth/str-exec.fs?view=markup>.

I have implemented a word >STRING-EXECUTE:

: >string-execute ( ... xt -- ... addr u )
    \G execute xt while the standard output (TYPE, EMIT, and everything
    \G that uses them) is redirected to a string.  The resulting string
    \G is addr u, which is in ALLOCATEd memory; it is the
    \G responsibility of the caller of >STRING-EXECUTE to FREE this
    \G string.
  
A simple usage is:

5 ' . >string-execute 2dup dump drop free throw

For your example above you would write:

: .mix2bytes_ind ( index n k i -- index n ) >r
    >r over r@ 64 + swap
    ." a" r@ 7 and 0 .r ." ^=ROL(rnds[states[" 0 .r ." ]^(0xff&(t>>"
    $7 and 8 * 0 .r ." ))]," r> 7 r@ - 0 .r ." );" ;

: mix2bytes_ind, ( index n k i -- index n )
    ['] .mix2bytes_ind >string-execute 2dup \c, ;

I wonder how many of the use cases for which people would like a more
elaborate string library can be solved with this.

Of course, some people will object to >STRING-EXECUTE requiring the
memory allocation wordset, so I have also designed (but not
implemented) a word that stores into a buffer provided by the caller:

>buffer-execute ( ... c-addr u1 xt -- ... u2 ) 
\ execute xt while the standard output (TYPE, EMIT, and everything
\ that uses them) is redirected to the buffer c-addr u.  u2 is the
\ number of characters that were output with TYPE or EMIT.  If u2<=u1,
\ then the string c-addr u2 contains the output, otherwise c-addr u1
\ contains the first u1 characters of the output, and the other
\ characters are not stored.

You can emulate >STRING-EXECUTE with >BUFFER-EXECUTE like this:
Instead of

... ['] foo >string-execute ( c-addr u ) ...

where FOO has the stack effect ( x1 x2 -- x3 ), write

... 2dup 2>r (or whatever is necessary to save FOO's input operands)
pad 0 ['] foo >buffer-execute >r drop ( throw away result of FOO )
2r> ( restore FOO's input operands )
r@ allocate throw r> 2dup 2>r ['] foo >buffer-execute drop 2r>

Somewhat cumbersome, but I think that's unavoidable given the goals.


About the implementation of >STRING-EXECUTE:

The unavoidable non-standardness is that it assumes that TYPE and EMIT
are deferred words; in Gforth they are, and AFAIK at least TYPE in
most other Forth systems, so this should be relatively easy to port.

It also uses TRY...RESTORE...ENDTRY to safely restore various stuff
even if an exception occurs while performing the xt.  One can
approximate this with CATCH (although in some rare cases this will
skip the restoration).

Finally, it uses locals pretty extensively.  The problem and its
implementation should be small and easy enough to understand to lend
itself to a challenge: I challenge the people who believe that code
without locals is superior to show me such superior code.

With a little luch this challenge will result in implementation of
>STRING-EXECUTE on systems other than Gforth.

- 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 2010: http://www.euroforth.org/ef10/

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

#1093 — Re: redirecting TYPE to a string (was: Renaissance of Forth)

On Apr 9, 12:54 pm, an...@mips.complang.tuwien.ac.at (Anton Ertl)
wrote:
> Of course, some people will object to >STRING-EXECUTE requiring the
> memory allocation wordset, so I have also designed (but not
> implemented) a word that stores into a buffer provided by the caller:

> >buffer-execute ( ... c-addr u1 xt -- ... u2 )

> \ execute xt while the standard output (TYPE, EMIT, and everything
> \ that uses them) is redirected to the buffer c-addr u.  u2 is the
> \ number of characters that were output with TYPE or EMIT.  If u2<=u1,
> \ then the string c-addr u2 contains the output, otherwise c-addr u1
> \ contains the first u1 characters of the output, and the other
> \ characters are not stored.

Where a string stack or wraparound queue is in ALLOTted space or a
workpad BLOCK buffer, ``>buffer-execute'' offers a lot of power
without the double movement required with ``>string-execute''.

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

#1123 — Re: redirecting TYPE to a string (was: Renaissance of Forth)

Anton Ertl wrote:

> What does %> do that we cannot do with ." and .\", which are much more
> familiar to Forth programmers.

Scans over multiple lines, and has a two-character termination sequence.  
It's related to PHP's <?php ?>, and originally designed for similar 
purposes (take a text template and fill in some fields from a program).

> Yes, redirecting TYPE to a string is a good way to construct strings
> in Forth, so I have implemented it
> <http://www.complang.tuwien.ac.at/viewcvs/cgi-
bin/viewcvs.cgi/gforth/str-exec.fs?view=markup>.

> A simple usage is:
> 
> 5 ' . >string-execute 2dup dump drop free throw
> 
> For your example above you would write:
> 
> : .mix2bytes_ind ( index n k i -- index n ) >r
>     >r over r@ 64 + swap
>     ." a" r@ 7 and 0 .r ." ^=ROL(rnds[states[" 0 .r ." ]^(0xff&(t>>"
>     $7 and 8 * 0 .r ." ))]," r> 7 r@ - 0 .r ." );" ;
> 
> : mix2bytes_ind, ( index n k i -- index n )
>     ['] .mix2bytes_ind >string-execute 2dup \c, ;

Nice.

> I wonder how many of the use cases for which people would like a more
> elaborate string library can be solved with this.

For producing strings, this is certainly quite useful, but for 
manipulating strings it's not.

> Finally, it uses locals pretty extensively.  The problem and its
> implementation should be small and easy enough to understand to lend
> itself to a challenge: I challenge the people who believe that code
> without locals is superior to show me such superior code.

Good challenge. Workshop for Forth-Tagung?

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/

[toc] | [prev] | [standalone]

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

Back to top | Article view | comp.lang.forth

csiph-web