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 1 of 4  [1] 2 3 4  Next page →

#919 — Renaissance of Forth

In 1984 I started with RSC-Forth with the R65F11 microprocessor and
used Forth ever since.

Recently I had a project with a MSP430F2012 and I had to deal with C
because program memory of this micro is to small to hold Forth. Even
if it would have been possible to use Forth with this new
microprocessor, it would have been impossible for me to write assembly
language parts when needed. So I decided to use C. I never used C
before, because I didn't like it - and I didn't need it, because I
knew the 65xx assembly language well enough for all other projects
where I had to write machine code.

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. That would not only give more
advantages to Forth programmers, but additionally it would give C
programmers the opportunity to use the blessings of Forth. That would
end the fight C versus Forth, showing that Forth is really superior
and prevailing. For those who love C and envy Forth it would give the
opportunity to add C libraries to Forth programs. And it would give
more power to Forth programmers, of course.

This may lead to a Renaissance of Forth.

This is a request hoping that somebody may pick up this idea and help
to realize it.
Yesterday I read a news article about Fabrice Bellard, thinking his
Tiny C compiler could be rewritten in Forth (a daunting task for me),
and today I found the GCC plugin Wiki (another daunting task for me to
adapt), and there may be other possibilities, too.

I know there is an animosity against C, and not only once the question
came up "Is Forth faster or smaller than C?". But C and Forth are not
comparable. These programming languages are different. And C may
increase the usability of Forth.

Adding a C compiler to Forth may lead to a Renaissance of Forth.
This may be the missing link for many.

Best Regards,
Dirk Bruehl

[toc] | [next] | [standalone]

#925

visualforth@rocketmail.com wrote:

> 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. That would not only give more
> advantages to Forth programmers, but additionally it would give C
> programmers the opportunity to use the blessings of Forth. That would
> end the fight C versus Forth, showing that Forth is really superior
> and prevailing. For those who love C and envy Forth it would give the
> opportunity to add C libraries to Forth programs. And it would give
> more power to Forth programmers, of course.
> 
> This may lead to a Renaissance of Forth.

Well, maybe, maybe not.  However, IME a Forth-in-Forth system is
easier to use than a C-based Forth because it's a lot easier to
understand.  All the system and its source is there in the same place.
You don't have to figure out a bunch of other tools and their
configuration languages.  It's all Forth, all the way down.

> I know there is an animosity against C, and not only once the question
> came up "Is Forth faster or smaller than C?". But C and Forth are not
> comparable. These programming languages are different. And C may
> increase the usability of Forth.

Speaking personally, I don't think animosity is quite the right word.
C has its uses, and I've done a fair bit of work on gcc, so it's not
as though there were some sort of ideological opposition.  However,
I'm not keen on anything that will make Forth less distinct from C.

Andrew.

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

#929

In article <6224e7e6-c367-4a01-baea-7532a2a164c1@e21g2000vbz.googlegroups.com>,
 <visualforth@rocketmail.com> wrote:
 <SNIP>
>
>I know there is an animosity against C, and not only once the question
>came up "Is Forth faster or smaller than C?". But C and Forth are not
>comparable. These programming languages are different. And C may
>increase the usability of Forth.
>
>Adding a C compiler to Forth may lead to a Renaissance of Forth.
>This may be the missing link for many.

I've been writing an assembler for Chuck Moore's new chip.
I had this thought of expressing the instructions in a way
as familiar to C-programmers as possible.
It doesn't look good.

OTOH. There are forth imports from DLL and .so libraries.
If the c-calling syntax of a particular (!) C-compiler
*and* the object file format (!) are
sufficiently transparent (!), one could imagine to import
code words from object files generated by this c-compiler
and embed them in assembly Forth words directly.

This looks doable, and can be beneficial in the cases
were tested code is present for c, not Forth.
Examples could be and FFT.

gforth could be a good candidate to experiment with this,
as it already contains code generated via c.

Don't call it "adding a c-compiler to Forth".
It gives the wrong impressions.

>
>Best Regards,
>Dirk Bruehl

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]

#932

On Apr 1, 5:46 am, Albert van der Horst <alb...@spenarnc.xs4all.nl>
wrote:
> In article <6224e7e6-c367-4a01-baea-7532a2a16...@e21g2000vbz.googlegroups.com>, <visualfo...@rocketmail.com> wrote:
> >Adding a C compiler to Forth may lead to a Renaissance of Forth.
> >This may be the missing link for many.
> Don't call it "adding a c-compiler to Forth".
> It gives the wrong impressions.

I have to admit that I nudged Dirk over here after a discussion on the
Win32Forth mail list yesterday.  My suggestion was toward the gcc
plugin approach and that Anton might have some thoughts on that
topic.  I wasn't thinking of suggesting that yet another C compiler
would gain any traction, even if a C compiler for Chuck's chip does
have some practical value.

I know we've discussed gcc integration from time to time, and I know
it is completely counter to the interactive nature of Forth.  However,
I also know that gcc is the default build environment for many, if not
most embedded systems.  It just seems to be the best place to find a
foothold.  We can't expect people to completely give up their existing
tool chains, but we could give them an alternative within that tool
chain.

DaR

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

#933

On Apr 1, 7:36 am, Dennis <daruf...@gmail.com> wrote:
> I know we've discussed gcc integration from time to time, and I know
> it is completely counter to the interactive nature of Forth.  However,
> I also know that gcc is the default build environment for many, if not
> most embedded systems.  It just seems to be the best place to find a
> foothold.  We can't expect people to completely give up their existing
> tool chains, but we could give them an alternative within that tool
> chain.

Do you mean a Forth front end for GCC?

I think a separate console could use GDB to access the target in a
Forth-like way. You might not be able to define stuff from the
console, but it would be good for test and debug.

-Brad

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

#947

On Apr 1, 10:36 am, Dennis <daruf...@gmail.com> wrote:
> I wasn't thinking of suggesting that yet another C compiler
> would gain any traction, even if a C compiler for Chuck's
> chip does have some practical value.

Oh, don't go there unless you're prepared for the Ideologically Pure
Patrol to whine.

> I know we've discussed gcc integration from time to time,
> and I know it is completely counter to the interactive
> nature of Forth.  However, I also know that gcc is the default
> build environment for many, if not most embedded systems.  
> It just seems to be the best place to find a foothold.  We
> can't expect people to completely give up their existing
> tool chains, but we could give them an alternative within
> that tool chain.

I thought the general idea here was to replace the use of assembly
language in Forth with C.  If so, the idea probably comes out of a
desire to treat C as a portable assembly language.  If so, I don't see
much value in the idea, especially because of the mental impedance
mismatch from C and Forth.  The biggest problem with these kinds of
ideas is that they are just thought of abstractly-- gosh, what if we
mixed Forth and C?  But missing from that idea is actual example code
that illustrates the supposed advantages.

How does the user switch the Forth into C?  Do definitions work at the
function, statement, or expression level?  What is the bridge between
Forth's unnamed values on the stack and C's named (and typed)
variables?  How does a C function return multiple values from a
function?  I'm not asking about mechanism, but about syntax and
semantics.

Nobody needs to have an actual interpreter or compiler for this
proposed hybrid language to write code in it.  We can run it on the
wetware between our ears.  So what I want to see are examples of code
in this hybrid language.  Because maybe I'm just not feeling creative
today, but what I come up with is an unreadable mess.  Simple cases
seem okay.  We might use a prefix like c: to identify C code:

    c: int square(int x) { return x; }

And yeah, I can imagine incorporating something like TCC (in it's
libtcc form) to compile that code, intern the symbol "square" in the
Forth dictionary, and use the function's prototype to set up the call
so this worked from Forth:

    3 square .

But that's easy and very doable.  But now what happens if we want to
have a C function that returns a string:

    c: const char* evenodd(int x) {
        return (x & 1) ? "odd" : "even";
    }

And now we've got the first impedance mismatch.  Forth strings are two
items on the stack, the address and length.  So how does C
interoperate with that?  The only way I see is to either come up with
a special type for strings, or add an extension to C's grammar.  Both
make the resulting C language both alien and incompatible.

What about going the other way-- C calling Forth words?  Some Forth
words look like a syntax error to C (like /MOD and @).  So the only
way I can see calling these words would be as strings:

    int x = "@"(&someVar);

But that's a syntax error to C.  So maybe we ugly it up a bit:

    int x = Forth("@", &someVar);

Ick.  More importantly, what do we do about Forth words that return
more than one value, such as FIND?  Maybe something like this:

    xt, flag = Forth("FIND", "foo");

But that's also an incompatible syntax error for C, and it assumes
that the language interoperability knows that FIND wants a counted
Forth string.

This is why I'd like to see someone who thinks this is a good idea
come up with what code in this hybrid language would look like.  I
certainly can't see any seamless interoperability, so the resulting
language is either going to be incompatible with C or it's going to be
larded down with functions to interface to the world of Forth.

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

#949

On Apr 1, 7:40 pm, John Passaniti <john.passan...@gmail.com> wrote:
> How does the user switch the Forth into C?  Do definitions work at the
> function, statement, or expression level?  What is the bridge between
> Forth's unnamed values on the stack and C's named (and typed)
> variables?  How does a C function return multiple values from a
> function?  I'm not asking about mechanism, but about syntax and
> semantics.

The most direct analogy to the tested embedded assembler language
approach would have to be along the lines of ...
CCODE: ( "name" x*i -- x*j) ... ;CCODE

... with the functional equivalent of the syntax for calling an
external library function to define the pseudo-function that is the
Forth word in the dictionary that bridges to the balance of the C code
in the . There also has to be a way to define structures of ints that
can be returned on the stack as a tuple of cells. Everything after the
pseduofunction specification and closure of the pseudofunction through
to ;CODE is C code.

Then CCODE-INCLUDE ( "name" -- ) to include C-files, to import the
source, and you have your system.

Don't see that it would lead to any Renaissance, though it'd make it
easier to incorporate existing C source (including, eg, from an open
source project) into a Forth project.

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

#937

Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
> I've been writing an assembler for Chuck Moore's new chip.
> I had this thought of expressing the instructions in a way
> as familiar to C-programmers as possible.
> It doesn't look good.

I don't see much point to trying to make asm code look like C.

Greg Bailey (see his talk on the recent Forth Day video) asked for
someone to target an actual C compiler to a VM running on the Green
Arrays chip (sort of the way they run Eforth on it), but that's a bit
different.

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

#942

In article <7x7hbdsr4i.fsf@ruckus.brouhaha.com>,
Paul Rubin  <no.email@nospam.invalid> wrote:
>Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
>> I've been writing an assembler for Chuck Moore's new chip.
>> I had this thought of expressing the instructions in a way
>> as familiar to C-programmers as possible.
>> It doesn't look good.
>
>I don't see much point to trying to make asm code look like C.

You realise that large parts of OSes/drivers is assembler
that looks like C? (Or to be precise syntactically it is C,
semantically it is assembler.)

volatile (char *)pape = 0x0fe;
       if (*pape & HOERA_BIT ) ....
>
>Greg Bailey (see his talk on the recent Forth Day video) asked for
>someone to target an actual C compiler to a VM running on the Green
>Arrays chip (sort of the way they run Eforth on it), but that's a bit
>different.

Not me. Writing a C-compiler for a GA144 is at least ten times as hard
as for the 6502. Then you have lots of processors to emulate a single
thread. Then you are going to defeat the c-syntax to add some
parallelism, uninspiring

What would inspire me is to map Haskel or some such on
multiple processors. Functional/declaritive programming
is a much better match for parallelism.

My short term target is making a postit fixup assembler
for the thing, such that I can use the chip to absolutely
full potential. With 32 instructions and no irregularities
and barocque stuff, it is easily mastered. I estimate that
the parpi project would have taken at most 10% more time,
if it had to be done in assembler,  or maybe it would have
made no difference.

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]

#946

Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
> You realise that large parts of OSes/drivers is assembler
> that looks like C? (Or to be precise syntactically it is C,
> semantically it is assembler.)
>
> volatile (char *)pape = 0x0fe;
>        if (*pape & HOERA_BIT ) ....

Sure, but if you want to compile syntax like that to stack code, it's
really not a assembler any more.  But you might look at qhasm:

   http://cr.yp.to/qhasm.html

> Not me. Writing a C-compiler for a GA144 is at least ten times as hard
> as for the 6502. Then you have lots of processors to emulate a single
> thread. Then you are going to defeat the c-syntax to add some
> parallelism, uninspiring

Well, I thought the idea was so that users could program high-level
control code in C, that would run on a VM implemented on a few GA nodes
without much concern for the interpretation overhead.  That sounds
pretty easy compared with trying to compile for a 6502, especially
compared to having to actually host the compiler on the same 6502 like
the old Commodore and Apple II compilers had to do.

> What would inspire me is to map Haskel or some such on multiple
> processors. Functional/declaritive programming is a much better match
> for parallelism.

I agree, ad I also put a little bit of thought into that, when I read
about the GA144 a while back.  JP's idea of compiling VHDL to the GA144
is also interesting.

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

#935

On Mar 31, 7:06 pm, visualfo...@rocketmail.com wrote:
....
> Recently I had a project with a MSP430F2012 and I had to deal with C
> because program memory of this micro is to small to hold Forth. Even
> if it would have been possible to use Forth with this new
> microprocessor, it would have been impossible for me to write assembly
> language parts when needed. So I decided to use C. I never used C
> before, because I didn't like it - and I didn't need it, because I
> knew the 65xx assembly language well enough for all other projects
> where I had to write machine code.
...

I've been writing in Forth on such small machines (including the
F2012) for some time now and I don't see the problem when you use a
modern Forth.  An optimizing compiler using a tethered host should
give you everything you need - although that particular cpu may not
lend itself to being tethered as it is quite pin and resource
limited.
And I don't typically write any code on the target in assembler
anymore - the Forth compiles to code that is quite close to what I'd
write in assembly.  I can concentrate on the application code rather
than the details that assembly code can require.  But there is always
the option to write in assembly if I want to.  I review the generated
code from time to time, but haven't felt the need to write in assembly
for some time.

Gary

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

#944

On 1 apr, 01:06, visualfo...@rocketmail.com wrote:
> That would not only give more advantages to Forth programmers,
> but additionally it would give C
> programmers the opportunity to use the blessings of Forth.
> For those who love C and envy Forth it would give the
> opportunity to add C libraries to Forth programs.
I married Forth an C, but not quite in the way you intend to do. In my
universe the C-paradigm rules, that means an ordinary compiler (never
had much love for the Forth architecture, I must admit - hey, it's a
free country), a preprocessor and standard MAKE and CC as the
toolchain. Forth is called from C, not the other way around. There are
more solutions to this equation.

> That would end the fight C versus Forth, showing that Forth is
> really superior and prevailing.
What I learned after almost 20 years of Forth/C development is that
both have their strengths. Parsing and interpreting is really a Forth
thing - I could never make that stuff as quickly with C. I wouldn't
know where to start and it's so obvious and simple with Forth. C (and
it's toolchain) shines with raw speed and enormous versatility (e.g.
mixed language development, huge amount of libraries). It's weakness
is IMHO a too pragmatic syntax - although it is not alone in that
respect. Yes, Forth is good - I love programming in it. But superior?

> Yesterday I read a news article about Fabrice Bellard, thinking his
> Tiny C compiler could be rewritten in Forth (a daunting task for me).
Marcel Hendrix made an even tinier C interpreter (more exactly: a
rewrite). I wrote a micro Basic interpreter (more exactly: a rewrite
with fixes and lots of enhancements). So it can be done and has been
done. I think Fabrice is right. Given the time I think even I could do
it (I hope..).

> I know there is an animosity against C, and not only once the question
> came up "Is Forth faster or smaller than C?". But C and Forth are not
> comparable. These programming languages are different.
That's why one cannot be superior to the other.

> And C may increase the usability of Forth.
True. But you're not the first one to think of it, I'm afraid. There
are many others here who love both languages.

Hans Bezemer

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

#952

"The Beez'" <hansoft@bigfoot.com> wrote Re: Renaissance of Forth
[..]
>> Yesterday I read a news article about Fabrice Bellard, thinking his
>> Tiny C compiler could be rewritten in Forth (a daunting task for me).
> Marcel Hendrix made an even tinier C interpreter (more exactly: a
> rewrite). 

It was on CLF in 2006. Here it is (a five-star posting): 

Message-ID: <29881021163561@frunobulax.edu>

-marcel

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

#967

On Apr 2, 4:40 am, m...@iae.nl (Marcel Hendrix) wrote:
> It was on CLF in 2006. Here it is (a five-star posting):
>
> Message-ID: <29881021163561@frunobulax.edu>

I'm unable to find that message with Google Groups (putting the
message ID into the appropriate place in the "advanced search" form).
I realize that's not your problem, but for those of us without a
different method to search for messages, how about either a link or a
subject line and date.  Thanks.

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

#972

"John Passaniti" on comp.lang.forth wrote:
> I'm unable to find that message with Google Groups (putting the
> message ID into the appropriate place in the "advanced search" form).
> I realize that's not your problem, but for those of us without a
> different method to search for messages, how about either a link or a
> subject line and date.  Thanks.

Here it is:

Tiny C compiler written in Forth
http://groups.google.com/group/comp.lang.forth/browse_frm/thread/9416057d5275aa17/

Regards.

--
Massimo Dentico

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

#980

On Apr 2, 6:34 pm, "Massimo A. Dentico" <massimo_dent...@hotmail.com>
wrote:
> Here it is:

Thanks.

As I suspected, it was a very small subset of C (it doesn't even have
functions!) with no meaningful interoperability between Forth and C.
Certainly not anything of the class the OP was interested in.  Still,
it's an interesting base for future work.

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

#984

John Passaniti <john.passaniti@gmail.com> writes Re: Renaissance of Forth

> On Apr 2, 6:34 pm, "Massimo A. Dentico" <massimo_dent...@hotmail.com>
> wrote:
>> Here it is:

> Thanks.

> As I suspected, it was a very small subset of C (it doesn't even have
> functions!) with no meaningful interoperability between Forth and C.
> Certainly not anything of the class the OP was interested in.  Still,
> it's an interesting base for future work.

The code implements what the original author of Tiny-C did. 

It is indeed not difficult to implement more features, but in that case
http://home.iae.nl/users/mhx/crenshaw/tiny.html is a much better place 
to start. The latest version of Crenshaw's TinyKiss on the website is 
able to compile the below program. It outputs Forth or assembly language.

-marcel

-- --------------------------------------
#include "tinykiss.lib"

{ ******************** }
{ Simple Start Program }
{ ******************** }

const SIZE = 3, PI = 3.14159265358979e, strnum = "413";

var 
  real alpha[SIZE], real m = 22e, n = -2e, 
  integer a = 1, b, c, 
  string  str = "foobar";

procedure foo(real ^x,real y)
var integer beta, real ^gamma;
begin
  m=x+y;
  str="abcdef"
end;

var integer d=111, string msg[2], char aap[4];

procedure naughty (string a)
var string b;
begin
   b = "aap";
   writeln("a printed by naughty -> ", a," ",b);
end;

program test; { a test { obviously } }
begin
  timerreset();
  if a&!b|!a&b
	foo(^m, m+n); 
	writeln( m*2+n:20:0," ",n+3/a:20:8," ",c," ",str," SIN(3) = ",sin(PI/2):10:3," constant ",strnum:8);
	msg[0] = "hello, "; msg[1] = "world!"; 
	writeln(msg[0],msg[1]);
	writeln("hello, " + "world" + "!");
	writeln(msg[0] + msg[1]);
	aap[0] = 3; aap[1] = 65; aap[2] = 66; aap[3] = 67; writeln(aap[1],aap[2]:3,aap[3])
	naughty(^aap);
	writeln("d + 3 = ",d+3); d =+ 3; write(", or d = ",d);
  endif
  writeln(elapsed()," ms elapsed.")
end.

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

#990

On Apr 3, 3:24 am, m...@iae.nl (Marcel Hendrix) wrote:
> It is indeed not difficult to implement more features, but in that
> case http://home.iae.nl/users/mhx/crenshaw/tiny.html is a much
> better place to start. The latest version of Crenshaw's TinyKiss
> on the website is able to compile the below program. It outputs
> Forth or assembly language.

But that's not what the OP wants.  The OP's ideal is some seamless
interoperability between C and Forth and more specifically a way to
replace machine-specific assembly language with C.  In the first
reference you provided, you had a way to invoke C statements, but the
code executed lived in it's own little world-- the C code had no
visibility of Forth's stack and the grammar didn't appear to have any
way to call Forth code.  Now in your second reference, you have a way
to compile a Pascal-like language down to Forth or assembly.  And then
what?  Can you seamlessly call the Pascal-like functions from Forth?
Can the Pascal-like language call Forth words?  Can you mix Forth and
this Pascal-like language together in the same file?  If so, what
rules or other restrictions are there?

It's easy to write a compiler or interpreter for a language
(especially a subset of a language) in Forth.  The sheer girth of a C
compiler like GCC doesn't come from complexity in parsing the language
and generating code, but from other functions (like optimization and
support for the eighty-billion options GCC has).  So toy
demonstrations of a C or Pascal-like language embedded in Forth aren't
particularly interesting or challenging.  And in fact, outside the
Forth world, it's very common to run into languages embedded inside
other languages, especially when talking about higher-level
languages.  What is interesting and challenging is to make those
languages seamlessly work with each other.  There are examples of this
in the real world-- Clojure/Java and C#/F# are two examples.  But in
those cases, things are greatly helped by having a common substrate.
When dealing with Forth and C, you have limitations and quirks in both
languages that make interoperability a pain.

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.

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

#991

John Passaniti <john.passaniti@gmail.com> writes:
> ou had a way to invoke C statements, but the
> code executed lived in it's own little world-- the C code had no
> visibility of Forth's stack and the grammar didn't appear to have any
> way to call Forth code. 

How is this usually handled if you replace the word "C" with "assembler"?

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

#992

On 4/3/11 1:45 PM, Paul Rubin wrote:
> John Passaniti<john.passaniti@gmail.com>  writes:
>> you had a way to invoke C statements, but the
>> code executed lived in it's own little world-- the C code had no
>> visibility of Forth's stack and the grammar didn't appear to have any
>> way to call Forth code.
>
> How is this usually handled if you replace the word "C" with "assembler"?

Many Forths (all that I've ever worked with) included an assembler 
written in Forth for the processor it's running on.  You can write CODE 
definitions whose bodies are expressed in that assembler, which generate 
actual machine code.  And you can drop into assembler for things like 
interrupt handlers.  The entire Forth VM (as well as the underlying 
processor) is available to such code, and there's nothing external to 
the Forth that has to be involved.

Nowadays, the approach is to minimize the requirement to write CODE 
words by using an optimizing compiler that generates good-quality 
machine code.

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]

Page 1 of 4  [1] 2 3 4  Next page →

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

csiph-web