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

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

If Emscripten can translate C/C++ via LLVM into JavaScript, could it be possible to use Forth as a compiler target?

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

Contents

  If Emscripten can translate C/C++ via LLVM into JavaScript, could it be possible to use Forth as a compiler target? nachtmann@gmail.com - 2014-05-26 14:44 -0700
    Re: If Emscripten can translate C/C++ via LLVM into JavaScript, could it be possible to use Forth as a compiler target? Paul Rubin <no.email@nospam.invalid> - 2014-05-26 14:51 -0700
      Re: If Emscripten can translate C/C++ via LLVM into JavaScript, could it be possible to use Forth as a compiler target? nachtmann@gmail.com - 2014-05-27 11:25 -0700
        Re: If Emscripten can translate C/C++ via LLVM into JavaScript, could it be possible to use Forth as a compiler target? Paul Rubin <no.email@nospam.invalid> - 2014-05-27 18:43 -0700
          Re: If Emscripten can translate C/C++ via LLVM into JavaScript, could it be possible to use Forth as a compiler target? Mark Wills <markwills1970@gmail.com> - 2014-05-28 01:41 -0700
            Re: If Emscripten can translate C/C++ via LLVM into JavaScript, could it be possible to use Forth as a compiler target? Paul Rubin <no.email@nospam.invalid> - 2014-05-28 01:56 -0700
              Re: If Emscripten can translate C/C++ via LLVM into JavaScript, could it be possible to use Forth as a compiler target? Lars Brinkhoff <lars.spam@nocrew.org> - 2014-05-28 14:56 +0200
                Re: If Emscripten can translate C/C++ via LLVM into JavaScript, could it be possible to use Forth as a compiler target? Paul Rubin <no.email@nospam.invalid> - 2014-05-28 09:19 -0700
                  Re: If Emscripten can translate C/C++ via LLVM into JavaScript, could it be possible to use Forth as a compiler target? Lars Brinkhoff <lars.spam@nocrew.org> - 2014-05-28 18:56 +0200
                    Re: If Emscripten can translate C/C++ via LLVM into JavaScript, could it be possible to use Forth as a compiler target? Paul Rubin <no.email@nospam.invalid> - 2014-05-28 10:14 -0700
                      Re: If Emscripten can translate C/C++ via LLVM into JavaScript, could it be possible to use Forth as a compiler target? Lars Brinkhoff <lars.spam@nocrew.org> - 2014-05-28 19:33 +0200
                        Re: If Emscripten can translate C/C++ via LLVM into JavaScript, could it be possible to use Forth as a compiler target? Paul Rubin <no.email@nospam.invalid> - 2014-05-28 11:00 -0700
                          Re: If Emscripten can translate C/C++ via LLVM into JavaScript, could it be possible to use Forth as a compiler target? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-05-29 12:45 +0000
                            Re: If Emscripten can translate C/C++ via LLVM into JavaScript, could it be possible to use Forth as a compiler target? Paul Rubin <no.email@nospam.invalid> - 2014-05-29 12:02 -0700
                              Re: If Emscripten can translate C/C++ via LLVM into JavaScript, could it be possible to use Forth as a compiler target? nachtmann@gmail.com - 2014-05-29 18:50 -0700
    Re: If Emscripten can translate C/C++ via LLVM into JavaScript, could it be possible to use Forth as a compiler target? stephenXXX@mpeforth.com (Stephen Pelc) - 2014-05-28 09:55 +0000
    Re: If Emscripten can translate C/C++ via LLVM into JavaScript, could it be possible to use Forth as a compiler target? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-05-31 15:06 +0000

#30786 — If Emscripten can translate C/C++ via LLVM into JavaScript, could it be possible to use Forth as a compiler target?

If Emscripten can translate C/C++ via LLVM into JavaScript, could it be possible to use Forth as a compiler target?

[toc] | [next] | [standalone]

#30789

nachtmann@gmail.com writes:
> If Emscripten can translate C/C++ via LLVM into JavaScript, could it
> be possible to use Forth as a compiler target?

You mean you want to compile C to Forth?  It's been done but the example
I know of requires the ability to read (PICK) and maybe write cells in
the interior of the data stack.  That kind of breaks Forth's stack
abstraction.

Why would you want to do that anyway?  C maps pretty well to register
hardware.  Do you have stack hardware that you want to run C code on?

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

#30847

> You mean you want to compile C to Forth?  It's been done but the example
> I know of requires the ability to read (PICK) and maybe write cells in

Can you tell me more about that?

Sure, PICK is a must.

> the interior of the data stack.  That kind of breaks Forth's stack
> abstraction.
> 
> Why would you want to do that anyway?  C maps pretty well to register
> hardware.  Do you have stack hardware that you want to run C code on?

There are some interesting stack processors available, but there are virtually no Forth developers available.

On the other hand, there are a lot of C developers and a lot of C libraries for doing things like handling UTF-8 properly

And LLVM is available for other languages now.

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

#30858

nachtmann@gmail.com writes:
>> You mean you want to compile C to Forth?  It's been done
> Can you tell me more about that?

The obvious web searches like "C to Forth" find some pointers.

> Sure, PICK is a must.

Once you have PICK it's no longer really a stack machine.

> There are some interesting stack processors available, but there are
> virtually no Forth developers available.

I don't think much is happening in the world of stack processors these
days, that are of much interest for running C code.  There was an
attempt at an HLL compiler for the GA144 but it used much different
techniques than a C compiler uses.

http://www.eecs.berkeley.edu/~nishant/papers/Chlorophyll.pdf

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

#30874

On Wednesday, 28 May 2014 02:43:30 UTC+1, Paul Rubin  wrote:
> Once you have PICK it's no longer really a stack machine.

Why not? When you PICK a value, where does it go? It goes on the..... stack!

That said, if the value you want is buried down deep in the stack, you should probably change the code and arrange to carry that value in a variable or (even better) a local variable and save yourself the pain. 

I admit to having used PICK a few times, though. It's convenient enough.

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

#30879

Mark Wills <markwills1970@gmail.com> writes:
>> Once you have PICK it's no longer really a stack machine.
> Why not? When you PICK a value, where does it go? It goes on
> the..... stack!

The concept of a stack machine is that `you can only access the top of
the stack, not the interior.  For example, Chuck's F18 series.  If there
is PICK (other than through some looping hack) then it's really a RAM
machine.

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

#30886

Paul Rubin <no.email@nospam.invalid> writes:
> The concept of a stack machine is that `you can only access the top
> of the stack, not the interior.  For example, Chuck's F18 series.
> If there is PICK (other than through some looping hack) then it's
> really a RAM machine.

This seems to be saying that a stack machine may well have PICK - but
only if it's implemented with a "hack".  Which is quite different from
"Once you have PICK it's no longer really a stack machine."

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

#30899

Lars Brinkhoff <lars.spam@nocrew.org> writes:
> This seems to be saying that a stack machine may well have PICK - but
> only if it's implemented with a "hack".  Which is quite different from
> "Once you have PICK it's no longer really a stack machine."

The "hack" implementation is BECAUSE the stack machine doesn't have
PICK, so you simulate it in software.  We would similarly say the AVR8
doesn't have IEEE floating point arithmetic.  That means the hardware
doesn't implement it.  It doesn't mean you can't simulate it.

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

#30902

Paul Rubin wrote:
> The "hack" implementation is BECAUSE the stack machine doesn't have
> PICK, so you simulate it in software.  We would similarly say the
> AVR8 doesn't have IEEE floating point arithmetic.  That means the
> hardware doesn't implement it.  It doesn't mean you can't simulate
> it.

The claim further up the thread was that requiring PICK when compiling
C to Forth would break the stack abstraction.  I don't see that it does.

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

#30903

Lars Brinkhoff <lars.spam@nocrew.org> writes:
> The claim further up the thread was that requiring PICK when compiling
> C to Forth would break the stack abstraction.  I don't see that it does.

I'd be interested in your explanation of "the stack abstraction".

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

#30907

Paul Rubin wrote:
>> The claim further up the thread was that requiring PICK when
>> compiling C to Forth would break the stack abstraction.  I don't
>> see that it does.
>
> I'd be interested in your explanation of "the stack abstraction".

I didn't introduce the concept to this discussion, but I assume
something like this:

>>>> The concept of a stack machine is that `you can only access the
>>>> top of the stack, not the interior.

PICK can be simulated in software on a stack machine.  Thus no breakage.

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

#30914

Lars Brinkhoff <lars.spam@nocrew.org> writes:
> PICK can be simulated in software on a stack machine.  Thus no breakage.

If you're going to simulate PICK in software, I have to question why
you're using the stack machine in the first place.  Perhaps the OP could
explain more specifically what he's trying to do and which stack-based
CPU's he's interested in.

Philip Koopman in "Stack computers, the new wave" advises using a
software stack instead of PICK for C locals:

  ... the best choice for a stack machine is to maintain the
  conventional language stack frames in program memory, with a Frame
  Pointer register available as a hardware pointer for stack frame
  accesses. If chip space is plentiful, a stack machine might provide
  on-chip RAM as part of the program memory space to speed up access to
  the stack frames. ...

  Normally, one would think that keeping local variables on the hardware
  data stack would be faster than placing them in memory. The reason
  this is not so is because stack machines are relatively inefficient at
  accessing deeply buried elements, especially if they may have been
  spilled out of the stack buffer and into program memory. Much of the
  time in the all-on-hardware-stack approach is spent thrashing elements
  about on the stack. While access to memory-resident frame elements is
  somewhat slower than access to data on the hardware stack, in the end
  the savings on stack manipulations make up the difference.[1]
  
Another issue he points out is that a C compiler has to support taking
the addresses of local variables.

[1] http://users.ece.cmu.edu/~koopman/stack_computers/sec9_1.html

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

#30945

In article <7xoayheqcb.fsf@ruckus.brouhaha.com>,
Paul Rubin  <no.email@nospam.invalid> wrote:
>Lars Brinkhoff <lars.spam@nocrew.org> writes:
>> PICK can be simulated in software on a stack machine.  Thus no breakage.
>
>If you're going to simulate PICK in software, I have to question why
>you're using the stack machine in the first place.  Perhaps the OP could
>explain more specifically what he's trying to do and which stack-based
>CPU's he's interested in.

OTOH. PICK presupposes a stack machine. The term doesn't make sense
outside of stack machines.

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]

#30956

albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
> OTOH. PICK presupposes a stack machine. The term doesn't make sense
> outside of stack machines.

By "stack machine" I mean cpus like the the F18A or b16, which have
hardware stacks with inaccessible interiors.  Phil Koopman wrote a book
"Stack Computers" which you've probably seen.  Historically before the
development of such processors (which have always been very niche),
Forth ran on conventional computers where the stack was in RAM and PICK
simply reached into the middle of the stack using normal memory
instructions.

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

#30978

> By "stack machine" I mean cpus like the the F18A or b16, which have
> hardware stacks with inaccessible interiors.  Phil Koopman wrote a book
> "Stack Computers" which you've probably seen.  Historically before the
> development of such processors (which have always been very niche),
> Forth ran on conventional computers where the stack was in RAM and PICK
> simply reached into the middle of the stack using normal memory
> instructions.

But PICK can be easily implemented in hardware, too

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

#30882

On Mon, 26 May 2014 14:44:29 -0700 (PDT), nachtmann@gmail.com wrote:

>If Emscripten can translate C/C++ via LLVM into JavaScript, could
>it be possible to use Forth as a compiler target?

See:
  http://www.mpeforth.com/arena.htm
near the bottom of the page.

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]

#31074

nachtmann@gmail.com writes:
>If Emscripten can translate C/C++ via LLVM into JavaScript, could it be possible to use Forth as a compiler target?

Certainly, but standard Forth is not a very good intermediate
representation.  Some features are missing and have to be emulated,
others are there and have an implementation cost, but are not useful
for most programming languages.  I recently designed a dialect of
Forth exactly for this purpose:

@InProceedings{ertl13-paf,
  author =       {M. Anton Ertl},
  title =        {{PAF}: A Portable Assembly Language},
  crossref =     {euroforth13},
  pages =        {30--38},
  url =          {http://www.complang.tuwien.ac.at/anton/euroforth/ef13/papers/ertl-paf.pdf},
  OPTnote =      {not refereed},
  abstract =     {A portable assembly language provides access to
                  machine-level features like memory addresses,
                  machine words, code addresses, and modulo
                  arithmetics, like assembly language, but abstracts
                  away differences between architectures like the
                  assembly language syntax, instruction encoding,
                  register set size, and addressing modes.  Forth
                  already satisfies a number of the characteristics of
                  a portable assembly language, and is therefore a
                  good basis.  This paper presents PAF, a portable
                  assembly language based on Forth, and specifically
                  discusses language features that other portable
                  assembly languages do not have, and their benefits;
                  it also discusses the differences from Forth.  The
                  main innovations of PAF are: tags indicate the
                  control flow for indirect branches and calls; and
                  PAF has two kinds of calls and definitions: the ABI
                  ones follow the platform's calling convention and
                  are useful for interfacing to the outside world,
                  while the PAF ones allow tail-call elimination and
                  are useful for implementing general control
                  structures.}
}
@Proceedings{euroforth13,
  title = 	 {29th EuroForth Conference},
  booktitle = 	 {29th EuroForth Conference},
  year = 	 {2013},
  key =		 {EuroForth'13},
  url =          {http://www.complang.tuwien.ac.at/anton/euroforth/ef13/papers/proceedings.pdf}
}

- 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 2014: http://www.euroforth.org/ef14/

[toc] | [prev] | [standalone]

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

csiph-web