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

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

A New Forth

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

Contents

  A New Forth tabcomputing@gmail.com - 2016-10-07 17:56 -0700
    Re: A New Forth Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2016-10-07 23:05 -0400
      Re: A New Forth Walter Banks <walter@bytecraft.com> - 2016-10-08 10:07 -0400
    Re: A New Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-08 13:08 +0000
      Re: A New Forth trans <transfire@gmail.com> - 2016-10-08 10:54 -0700
        Re: A New Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-10-08 18:03 +0000
          Re: A New Forth trans <transfire@gmail.com> - 2016-10-08 11:13 -0700
      Re: A New Forth Paul Rubin <no.email@nospam.invalid> - 2016-10-08 11:17 -0700
      Re: A New Forth hughaguilar96@gmail.com - 2016-10-13 14:44 -0700
        Re: A New Forth hughaguilar96@gmail.com - 2016-10-13 14:53 -0700
          Re: A New Forth hughaguilar96@gmail.com - 2016-10-13 15:04 -0700
          Re: A New Forth rickman <gnuarm@gmail.com> - 2016-10-13 22:55 -0400
    Re: A New Forth trans <transfire@gmail.com> - 2016-10-08 12:11 -0700
      Re: A New Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-10-08 21:31 +0200
        Re: A New Forth trans <transfire@gmail.com> - 2016-10-08 17:07 -0700
      Re: A New Forth Paul Rubin <no.email@nospam.invalid> - 2016-10-08 12:33 -0700
        Re: A New Forth missycurl@gmail.com - 2016-10-08 12:54 -0700
          Re: A New Forth Paul Rubin <no.email@nospam.invalid> - 2016-10-08 13:29 -0700
        Re: A New Forth trans <transfire@gmail.com> - 2016-10-08 17:28 -0700
          Re: A New Forth Paul Rubin <no.email@nospam.invalid> - 2016-10-08 18:00 -0700
            Re: A New Forth trans <transfire@gmail.com> - 2016-10-09 09:00 -0700
              Re: A New Forth luser droog <mijoryx@yahoo.com> - 2016-10-09 11:19 -0700
              Re: A New Forth Paul Rubin <no.email@nospam.invalid> - 2016-10-10 01:09 -0700
                Re: A New Forth trans <transfire@gmail.com> - 2016-10-10 08:24 -0700
                  Re: A New Forth Paul Rubin <no.email@nospam.invalid> - 2016-10-10 13:28 -0700
                    Re: A New Forth "Elizabeth D. Rather" <erather@forth.com> - 2016-10-10 11:14 -1000
                      Re: A New Forth Paul Rubin <no.email@nospam.invalid> - 2016-10-10 15:11 -0700
                        Re: A New Forth Doug Hoffman <glidedog@gmail.com> - 2016-10-11 21:46 -0400
                    Re: A New Forth trans <transfire@gmail.com> - 2016-10-10 16:26 -0700
                      Re: A New Forth Paul Rubin <no.email@nospam.invalid> - 2016-10-10 18:58 -0700
                        Re: A New Forth trans <transfire@gmail.com> - 2016-10-10 20:15 -0700
                Re: A New Forth Ron Aaron <rambamist@gmail.com> - 2016-10-11 07:26 +0300
                  Re: A New Forth trans <transfire@gmail.com> - 2016-10-11 03:09 -0700
                    Re: A New Forth Ron Aaron <rambamist@gmail.com> - 2016-10-11 13:27 +0300
                  Re: A New Forth lawrencedo99@gmail.com - 2016-10-13 18:41 -0700
                    Re: A New Forth trans <transfire@gmail.com> - 2016-10-13 19:08 -0700
                    Re: A New Forth Ron Aaron <rambamist@gmail.com> - 2016-10-14 07:58 +0300
            Re: A New Forth franck.bensusan@gmail.com - 2016-10-09 11:09 -0700
            Re: A New Forth lawrencedo99@gmail.com - 2016-10-13 18:45 -0700
          Re: A New Forth albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-10-09 10:54 +0200
            Re: A New Forth missycurl@gmail.com - 2016-10-09 07:35 -0700
            Re: A New Forth Melzzzzz <mel@zzzzz.com> - 2016-10-11 06:23 +0200
            Re: A New Forth Paul Rubin <no.email@nospam.invalid> - 2016-10-10 21:31 -0700
            Re: A New Forth franck.bensusan@gmail.com - 2016-10-15 00:26 -0700
          Re: A New Forth Melzzzzz <mel@zzzzz.com> - 2016-10-13 19:16 +0200
            Re: A New Forth trans <transfire@gmail.com> - 2016-10-13 11:46 -0700
              Re: A New Forth Melzzzzz <Melzzzzz@zzzzz.com> - 2016-10-13 19:04 +0000
          Re: A New Forth "WJ" <w_a_x_man@yahoo.com> - 2016-10-15 20:07 +0000
      Re: A New Forth luser droog <mijoryx@yahoo.com> - 2016-10-08 13:56 -0700
    Re: A New Forth polymorph self <jackvanc3@gmail.com> - 2016-10-08 19:58 -0700
    Re: A New Forth Chris Curl <ccurl609@gmail.com> - 2016-10-10 19:22 -0700
      Re: A New Forth trans <transfire@gmail.com> - 2016-10-10 20:18 -0700
        Re: A New Forth Chris Curl <ccurl609@gmail.com> - 2016-10-11 11:14 -0700
          Re: A New Forth trans <transfire@gmail.com> - 2016-10-11 14:22 -0700
            Re: A New Forth jim.brakefield@ieee.org - 2016-10-11 15:11 -0700
              Re: A New Forth trans <transfire@gmail.com> - 2016-10-11 18:03 -0700
            Re: A New Forth Paul Rubin <no.email@nospam.invalid> - 2016-10-11 15:13 -0700
              Re: A New Forth Chris Curl <ccurl609@gmail.com> - 2016-10-11 17:52 -0700
                Re: A New Forth trans <transfire@gmail.com> - 2016-10-11 19:55 -0700
                Re: A New Forth hughaguilar96@gmail.com - 2016-10-13 14:21 -0700
                  Re: A New Forth hughaguilar96@gmail.com - 2016-10-13 14:36 -0700
              Re: A New Forth trans <transfire@gmail.com> - 2016-10-11 18:08 -0700
                Re: A New Forth Paul Rubin <no.email@nospam.invalid> - 2016-10-11 18:21 -0700
                  Re: A New Forth trans <transfire@gmail.com> - 2016-10-11 20:01 -0700
          Re: A New Forth trans <transfire@gmail.com> - 2016-10-11 20:33 -0700
            Re: A New Forth Doug Hoffman <glidedog@gmail.com> - 2016-10-12 01:15 -0400
              Re: A New Forth trans <transfire@gmail.com> - 2016-10-12 05:44 -0700
                Re: A New Forth Doug Hoffman <glidedog@gmail.com> - 2016-10-12 11:51 -0400
                  Re: A New Forth trans <transfire@gmail.com> - 2016-10-12 09:47 -0700
                    Re: A New Forth Paul Rubin <no.email@nospam.invalid> - 2016-10-12 10:08 -0700
                      Re: A New Forth trans <transfire@gmail.com> - 2016-10-12 11:48 -0700
                        Re: A New Forth Paul Rubin <no.email@nospam.invalid> - 2016-10-12 11:56 -0700
                    Re: A New Forth Doug Hoffman <glidedog@gmail.com> - 2016-10-12 13:41 -0400
                      Re: A New Forth trans <transfire@gmail.com> - 2016-10-12 11:57 -0700
                        Re: A New Forth trans <transfire@gmail.com> - 2016-10-12 12:02 -0700
                        Re: A New Forth Doug Hoffman <glidedog@gmail.com> - 2016-10-13 09:24 -0400
                          Re: A New Forth Doug Hoffman <glidedog@gmail.com> - 2016-10-13 10:33 -0400
                            Re: A New Forth trans <transfire@gmail.com> - 2016-10-13 10:05 -0700
                    Re: A New Forth jim <anon@example.com> - 2016-10-12 19:01 +0100
                      Re: A New Forth trans <transfire@gmail.com> - 2016-10-13 09:53 -0700
                        Re: A New Forth fred <anon@example.com> - 2016-10-14 12:37 +0100
                          Re: A New Forth jim <anon@example.com> - 2016-10-14 14:49 +0100
                          Re: A New Forth trans <transfire@gmail.com> - 2016-10-14 07:20 -0700
                            Re: A New Forth jim <anon@example.com> - 2016-10-15 11:58 +0100
                              Re: A New Forth tabcomputing@gmail.com - 2016-10-15 10:21 -0700
            Re: A New Forth Chris Curl <ccurl609@gmail.com> - 2016-10-12 04:33 -0700
    Re: A New Forth Whammo <sidciavic@gmail.com> - 2016-10-15 12:23 -0700

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

#51686 — A New Forth

I am planning to build a new variant of the Forth language. I plan to do so in Assembly, but I am wondering if I might be better off doing that in LLVM IR. Anyone have any recommendations as to why or why not I should use LLVM?

[toc] | [next] | [standalone]

#51688

On Fri, 7 Oct 2016 17:56:32 -0700 (PDT)
tabcomputing@gmail.com wrote:

> I am planning to build a new variant of the Forth language. I plan to
> do so in Assembly, but I am wondering if I might be better off doing
> that in LLVM IR. Anyone have any recommendations as to why or why not
> I should use LLVM?

Not I.

My guess is if someone can use assembly or C to implement Forth, then
LLVM's IR should work fine too, but then again, I've looked at LLVM's
IR only in a very cursory manner.


Rod Pemberton

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

#51696

On 2016-10-07 11:05 PM, Rod Pemberton wrote:
> On Fri, 7 Oct 2016 17:56:32 -0700 (PDT) tabcomputing@gmail.com
> wrote:
>
>> I am planning to build a new variant of the Forth language. I plan
>> to do so in Assembly, but I am wondering if I might be better off
>> doing that in LLVM IR. Anyone have any recommendations as to why or
>> why not I should use LLVM?
>
> Not I.
>
> My guess is if someone can use assembly or C to implement Forth,
> then LLVM's IR should work fine too, but then again, I've looked at
> LLVM's IR only in a very cursory manner.

The reason I wouldn't use LLVM is that it fundamentally hasn't moved the
technology of code generation used by most compilers with roots in the 3
or 4 decades old PPC. A relatively simple application centeric code
generator would likely outperform LLVM with less effort than porting
LLVM for the purpose.

w..

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

#51695

tabcomputing@gmail.com writes:
>I am planning to build a new variant of the Forth language. I plan to do so in Assembly, but I am wondering if I might be better off doing that in LLVM IR. Anyone have any recommendations as to why or why not I should use LLVM?

I would not use it, for the reasons outlined in my PAF paper
[ertl13-paf]:

|Unfortunately, [LLVM] shares many of the problems of C: In particular, you
|have to divide the code into functions that follow some calling
|convention, restricting the kind of control flow that is possible.  To
|work around this problem, it is possible to add your own calling
|convention, but that is not easy.\footnote{Usenet message
|  \url{<KYGdnTH8PMyMpM7MnZ2dnUVZ_j-dnZ2d@supernews.com>}}
|
|LLVM was also promised to be a useful intermediate representation for
|JIT compilers, but reportedly its code generation is too slow for most
|JIT compiler uses.
|
|LLVM supports fewer targets than C.  Given that it also seems to share
|many of the disadvantages of C, it does not appear to be an attractive
|portable assembly language to me, despite the buzz it has generated.

If you want portability, take a look at GNU Lightning; it has a lot of
targets now.

@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 2016: http://www.euroforth.org/ef16/

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

#51704

On Saturday, October 8, 2016 at 9:16:39 AM UTC-4, Anton Ertl wrote:
> I would not use it, for the reasons outlined in my PAF paper
> [ertl13-paf]:

Thanks Anton (and Rod and Walter) I am not going to use it then. Your arguments are convincing.

I actually plan to do something similar to PAF as the base of my language and build the rest of the language on top of that. Is PAF open source? It might be helpful in my endeavor as a reference.

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

#51705

trans <transfire@gmail.com> writes:
>Is PAF open source?

At the moment, PAF is vapourware.  It will continue to be for quite
some time.

- 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]

#51706

On Saturday, October 8, 2016 at 2:05:11 PM UTC-4, Anton Ertl wrote:
> trans <transfire@gmail.com> writes:
> >Is PAF open source?
> 
> At the moment, PAF is vapourware.  It will continue to be for quite
> some time.

Ah, okay. Guess that's why I could only find a .pdf :)

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

#51707

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> LLVM?
> I would not use it, for the reasons outlined in my PAF paper

I wonder if QBE might be of interest:  http://c9x.me/compile/

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

#51844

On Saturday, October 8, 2016 at 6:16:39 AM UTC-7, Anton Ertl wrote:
> tabcomputing@gmail.com writes:
> >I am planning to build a new variant of the Forth language. I plan to do so in Assembly, but I am wondering if I might be better off doing that in LLVM IR. Anyone have any recommendations as to why or why not I should use LLVM?

I looked into LLVM and found that it was not a good match for Forth. For Forth you need a VM that represents a hypothetical stack-processor.

> @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.}
> }

I was unimpressed with Anton Ertl's PAF --- I designed my hugh-niversal assembler as a response. 

My design is for 16-bit micro-controllers however --- if you are programming a desktop-computer however, then it would not be appropriate --- note however, that the only way to make money with Forth that I'm aware of is with 16-bit micro-controllers (desktop-computer software is always given away for free).

In my document I say this:
-------------------------------------------------------------------------

Anton Ertl's PAF (Portable Assembler for Forth) has major problems:

1.) His PAF is for 32-bit processors. This makes no sense, as the ARM is used in maybe 99% of all 32-bit micro-controllers (the MIPS, ColdFire, etc. make up the remainder) --- he should just write his Forth in ARM assembly-language if he wants portability in the 32-bit world.

2.) He believes that the register set size can be abstracted away. This is not true --- the number of registers is the one thing that has to be fixed --- a big part of designing any Forth system is dedicating the registers to specific uses, and the designer needs to know how many registers he has in order to do this.

3.) He considers abstracting away the register set size to be his primary goal --- to accomplish this, he is removing features from Forth that get in the way of this misguided goal --- when (if) he gets PAF to work, his Forth will be crippled.

4.) He still doesn't want lambda functions to be added to Forth --- so for all of his effort, the final result will still just be a typical lame Forth --- the lack of lambda functions has always been Forth's greatest weakness.

5.) He seems to have no concern at all for efficiency. Gforth was utterly useless for micro-controller programming --- his goal with Gforth was portability, but Gforth was so slow that it was never used in any commercial application, so there are no programs to port --- PAF will be more of the same.

The idea for HUGHasm came from PAF, but HUGHasm is different in every way --- HUGHasm is a design that makes sense in the real-world of commercial micro-controllers; it is not an academic exercise like PAF.

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

#51845

On Thursday, October 13, 2016 at 2:44:48 PM UTC-7, hughag...@gmail.com wrote:
> My design is for 16-bit micro-controllers however --- if you are programming a desktop-computer however, then it would not be appropriate --- note however, that the only way to make money with Forth that I'm aware of is with 16-bit micro-controllers (desktop-computer software is always given away for free).

My design is very similar to the 16-bit x86. This does not mean that I think the 80186 should be used (it was a bad idea 20 years ago and is totally obsolete now) --- all of those x86 processors have too much interrupt latency to be useful as micro-controllers. My design should be easy to implement in an FPGA, or emulate on any 16-bit processor.

I actually have two versions. The big version supports double-precision numbers and ratios --- this is for cases in which 16-bit integers lack adequate precision. The big version requires a few more registers (for the double-stack pointer and the top value of the double-stack) --- a processor such as the PIC24 or MSP-430 has enough registers to support this --- the PIC24 has good support for multiplication and division, so it should be fast enough to make this extra precision realistic (you get the low cost of a 16-bit processor with the high precision of a 32-bit processor).

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

#51846

On Thursday, October 13, 2016 at 2:53:08 PM UTC-7, hughag...@gmail.com wrote:
> My design is very similar to the 16-bit x86. This does not mean that I think the 80186 should be used (it was a bad idea 20 years ago and is totally obsolete now) --- all of those x86 processors have too much interrupt latency to be useful as micro-controllers. My design should be easy to implement in an FPGA, or emulate on any 16-bit processor.

The PIC24 has 20 registers, so it is possible to emulate two VMs (the small version that is similar to the 16-bit x86). You can have multi-tasking that only supports two tasks, but is fast because there is no need to save-and-restore registers (each task has its own set of registers). 

I'm not a fan of multi-tasking that supports a lot of tasks but which has such a slow task-switch as to make it unrealitic for hard-real-time programs --- the more tasks you have, the more complicated your program is, and the more likely there are to be problems (tasks not having enough time to complete their work, resulting in lost data and/or stuttering).

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

#51853

On 10/13/2016 5:53 PM, hughaguilar96@gmail.com wrote:
> On Thursday, October 13, 2016 at 2:44:48 PM UTC-7,
> hughag...@gmail.com wrote:
>> My design is for 16-bit micro-controllers however --- if you are
>> programming a desktop-computer however, then it would not be
>> appropriate --- note however, that the only way to make money with
>> Forth that I'm aware of is with 16-bit micro-controllers
>> (desktop-computer software is always given away for free).
>
> My design is very similar to the 16-bit x86. This does not mean that
> I think the 80186 should be used (it was a bad idea 20 years ago and
> is totally obsolete now) --- all of those x86 processors have too
> much interrupt latency to be useful as micro-controllers. My design
> should be easy to implement in an FPGA, or emulate on any 16-bit
> processor.
>
> I actually have two versions. The big version supports
> double-precision numbers and ratios --- this is for cases in which
> 16-bit integers lack adequate precision. The big version requires a
> few more registers (for the double-stack pointer and the top value of
> the double-stack) --- a processor such as the PIC24 or MSP-430 has
> enough registers to support this --- the PIC24 has good support for
> multiplication and division, so it should be fast enough to make this
> extra precision realistic (you get the low cost of a 16-bit processor
> with the high precision of a 32-bit processor).

In terms of design starts, the 16 bit MCUs are losing ground.  The 8 bit 
parts are really inexpensive these days and rather capable with a very 
wide assortment of peripherals (many times a design is about the 
peripherals rather than the CPU).  The 32 bit devices have come way down 
in price over the years and have been highly optimized for power leaving 
very little room between them and the 8 bit world.

I suppose your assembly language can be implemented on any processor, 
but you seem to feel it should match the actual hardware as much as 
possible.  If so, you should pick a hardware platform that is used as 
widely as possible.

Funny you mention the x86.  This is not a family that is very widely 
used for embedded or anything else other than laptops and desktops.  I 
don't get where this is going.

If you want to make money, I suggest you go for the 32 bit MCU market. 
Specializing in 16 bit MCUs will severely limit your work opportunities.

-- 

Rick C

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

#51711

On Friday, October 7, 2016 at 8:56:33 PM UTC-4, tabcom...@gmail.com wrote:
> I am planning to build a new variant of the Forth language. I plan to do so in Assembly, but I am wondering if I might be better off doing that in LLVM IR. Anyone have any recommendations as to why or why not I should use LLVM?

Okay since I am already talking about it, and the feedback has been really helpful so far, I'll go into it a bit further and see what you guys think.

Of course the first thing I have to decide is what assembler to use. It will probably be GAS, but I am open to other suggestions. (Note I looked at GNU Lightening but it has limitations too so I am just going to go all the way down and do it in Assembly.) From there I plan to build a core base that will abstract away some of the underlying architecture. I don't think I want to abstract it all away, in fact I want it to be possible to fallback on the underlying architecture where useful, but it should be able to abstract away enough to at least make the language much easier to port.

The next major decision I have to make is with regards to word lookup because the Forth I am working on will be typed. I am not doing that for type safety or execution performance reasons, although those are nice bonuses, rather I am doing it primarily for the multi-method dispatching it will allow, which will make this new Forth much more readable -- and that is a top priority for me. A problem that arises though, is ambiguity between type signatures. e.g. pseudo-code:

    : foo ( int int -- int ) ... ;
    : foo ( int int int -- int ) ... ;
 
When deciding which foo to use based on the type signature if there are three ints on the stack, does it use the first or the second definition? Or should it just use the one that shows up first in the definitions list. Or, I suppose, the compiler could just raise an error about the ambiguity?

Another feature I plan to have are recognizers, but I am pretty sure it will be character based, not word based. I don't think that will prove to be too difficult, but I still have to figure out how to make it as simple as possible to tap into.

The hardest thing I have to work out is probably how to handle types that can't be determined at compile time -- say if a word returns a float vs an integer based on some runtime condition. I really don't think I want to restrict return values to a single concrete signature. That would make compilation a lot easier, but I fear it would make programming in this Forth feel far too constrained. Am I right about that? 

I have so far come up with two possible ways to handle it, that would not slow things down too much. One is to use mini-jump tables. So if a word returns two different signatures, then it would also return a jump index (or put it on a special stack) and that would be used as an offset to find the correct xt. The other option is a large global jump table -- think of all the possible word names and type signatures in a multi-dimensional matrix (the dimensions correspond to arity). The xt could be looked up through a few redirections (one per argument). Of course, the downside is that the table could be pretty big and most of it would be empty. Also, the extra indirection would slow things down (though still far faster then something like a binary search). These are both nascent ideas, and I haven't worked through them completely yet. I've been trying to find out how other static compilers handle this situation but haven't found out yet.

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

#51712

In article <1f740c55-e4d9-4e0f-993c-346e55ff7438@googlegroups.com>,
trans  <transfire@gmail.com> wrote:
>On Friday, October 7, 2016 at 8:56:33 PM UTC-4, tabcom...@gmail.com wrote:
>> I am planning to build a new variant of the Forth language. I plan to do =
>so in Assembly, but I am wondering if I might be better off doing that in L=
>LVM IR. Anyone have any recommendations as to why or why not I should use L=
>LVM?
>
>Okay since I am already talking about it, and the feedback has been really =
>helpful so far, I'll go into it a bit further and see what you guys think.
>
>Of course the first thing I have to decide is what assembler to use. It wil=
>l probably be GAS, but I am open to other suggestions. (Note I looked at GN=
>U Lightening but it has limitations too so I am just going to go all the wa=
>y down and do it in Assembly.) From there I plan to build a core base that =
>will abstract away some of the underlying architecture. I don't think I wan=
>t to abstract it all away, in fact I want it to be possible to fallback on =
>the underlying architecture where useful, but it should be able to abstract=
> away enough to at least make the language much easier to port.

If you choose assembler as an implementation language, then you've
choosen a processor probably. If that is Intel/AMD 86 you're
far better off with fasm then gas. fasm is a true assembler with
all kind of assembler oriented features, like a powerful macro
facility. OTOH gas is still a mere back end for c-like languages.
In ciforth I never burned any ships, I prefer fasm but I'm
not married to it, e.g. I can switch to other assemblers at will.
If you can decide to lean heavily on fasm, commit to it,
really use it to full potiental, your life will be much easier.

<SNIP>

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]

#51718

On Saturday, October 8, 2016 at 3:23:13 PM UTC-4, Albert van der Horst wrote:
> 
> If you choose assembler as an implementation language, then you've
> choosen a processor probably. If that is Intel/AMD 86 you're
> far better off with fasm then gas. fasm is a true assembler with
> all kind of assembler oriented features, like a powerful macro
> facility. OTOH gas is still a mere back end for c-like languages.
> In ciforth I never burned any ships, I prefer fasm but I'm
> not married to it, e.g. I can switch to other assemblers at will.
> If you can decide to lean heavily on fasm, commit to it,
> really use it to full potiental, your life will be much easier.

Thanks. I will check it out.

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

#51713

trans <transfire@gmail.com> writes:
> the Forth I am working on will be typed. ... primarily for the
> multi-method dispatching it will allow...
>     : foo ( int int -- int ) ... ;
>     : foo ( int int int -- int ) ... ;
> When deciding which foo to use based on the type signature if there
> are three ints on the stack, does it use the first or the second
> definition?

Type based dispatching like C++'s sounds like a poor idea for a
Forth-like language.  The two basic choices are: 1) keeping with Forth's
interactive style, let the second definition overwrite the first one
while emitting a warning; or, 2) raise a compile-time error.

> say if a word returns a float vs an integer based on some runtime
> condition.  I really don't think I want to restrict return values to a
> single concrete signature.

Then you're not writing a typed language.

> That would make compilation a lot easier, but I fear it would make
> programming in this Forth feel far too constrained. Am I right about
> that?

No not really.  Forth makes what you're describing possible, but
preferred Forth style is to avoid it and stay with static signatures.

> I've been trying to find out how other static compilers handle this
> situation but haven't found out yet.

With variant types aka tagged unions.

Stepping back a little, can I ask what the purpose of this project is?
Do you have an application area and target where you want to use the
compiler you're writing?  Are you mostly just writing a compiler for fun
(and there's nothing wrong with that)?  Either way but especially if the
latter, why Forth?  Forth is the way it is partly because of its
traditional philosophy of keeping its implementation very simple.  There
are fancy implementations out there, but they were written mostly to
bring better performance to programs written with familiar Forth
techniques.

It sounds like you've been using C++.  If you want exposure to fancier
uses of type systems, you might give Haskell a try.
http://learnyouahaskell.com is a good place to start.

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

#51714

On Saturday, October 8, 2016 at 3:33:58 PM UTC-4, Paul Rubin wrote:
> trans <transfire@gmail.com> writes:
> > the Forth I am working on will be typed. ... primarily for the
> > multi-method dispatching it will allow...
> >     : foo ( int int -- int ) ... ;
> >     : foo ( int int int -- int ) ... ;
> > When deciding which foo to use based on the type signature if there
> > are three ints on the stack, does it use the first or the second
> > definition?
> 
> Type based dispatching like C++'s sounds like a poor idea for a
> Forth-like language.  The two basic choices are: 1) keeping with Forth's
> interactive style, let the second definition overwrite the first one
> while emitting a warning; or, 2) raise a compile-time error.
> 
> > say if a word returns a float vs an integer based on some runtime
> > condition.  I really don't think I want to restrict return values to a
> > single concrete signature.
> 
> Then you're not writing a typed language.
> 
> > That would make compilation a lot easier, but I fear it would make
> > programming in this Forth feel far too constrained. Am I right about
> > that?
> 
> No not really.  Forth makes what you're describing possible, but
> preferred Forth style is to avoid it and stay with static signatures.
> 
> > I've been trying to find out how other static compilers handle this
> > situation but haven't found out yet.
> 
> With variant types aka tagged unions.
> 
> Stepping back a little, can I ask what the purpose of this project is?
> Do you have an application area and target where you want to use the
> compiler you're writing?  Are you mostly just writing a compiler for fun
> (and there's nothing wrong with that)?  Either way but especially if the
> latter, why Forth?  Forth is the way it is partly because of its
> traditional philosophy of keeping its implementation very simple.  There
> are fancy implementations out there, but they were written mostly to
> bring better performance to programs written with familiar Forth
> techniques.
> 
> It sounds like you've been using C++.  If you want exposure to fancier
> uses of type systems, you might give Haskell a try.
> http://learnyouahaskell.com is a good place to start.

My first run at a Forth implementation was written in C++. It was not as fast 
as I expected. Then I wrote it again, this time in straight C ... that was 
MUCH faster than the C++ version.

I am currently re-doing it one more time in assembler. That may be a little
faster, but I doubt it will be as big a difference as the C/C++ was.

That is my insight. That plus the price of a cup of coffee will get you a
cup of coffee.

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

#51715

missycurl@gmail.com writes:
> My first run at a Forth implementation was written in C++. It was not
> as fast as I expected.

I think Trans is implementing something different than what we usually
think of as Forth (e.g. it Trans's language is statically typed).  So
the implementation techniques are likely to be different.

> I am currently re-doing it one more time in assembler. That may be a
> little faster

If you're after speed, you have to generate machine code, and if you do
that, it matters less how the compiler works.  But writing a Forth
compiler in anything but Forth imho doesn't seem in the Forth spirit.

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

#51719

On Saturday, October 8, 2016 at 3:33:58 PM UTC-4, Paul Rubin wrote:
> trans <transfire@gmail.com> writes:
> > the Forth I am working on will be typed. ... primarily for the
> > multi-method dispatching it will allow...
> >     : foo ( int int -- int ) ... ;
> >     : foo ( int int int -- int ) ... ;
> > When deciding which foo to use based on the type signature if there
> > are three ints on the stack, does it use the first or the second
> > definition?
> 
> Type based dispatching like C++'s sounds like a poor idea for a
> Forth-like language.  The two basic choices are: 1) keeping with Forth's
> interactive style, let the second definition overwrite the first one
> while emitting a warning; or, 2) raise a compile-time error.

I was leaning toward #1 too.

> > say if a word returns a float vs an integer based on some runtime
> > condition.  I really don't think I want to restrict return values to a
> > single concrete signature.
> 
> Then you're not writing a typed language.

Sort-of. I think you would call it "soft typing". It's static as much as possible and dynamic otherwise, but I plan to hand the dynamic part in a rather static way. In other words, it should still be possible to strip out all the type info from a fully compiled binary, the only remnants of types will be those jump tables. At least that's the idea.

> > That would make compilation a lot easier, but I fear it would make
> > programming in this Forth feel far too constrained. Am I right about
> > that?
> 
> No not really.  Forth makes what you're describing possible, but
> preferred Forth style is to avoid it and stay with static signatures.
> 

That just might make my life a lot easier. I can start with static signatures, see how it goes, and consider going beyond that at a later time. 

> > I've been trying to find out how other static compilers handle this
> > situation but haven't found out yet.
> 
> With variant types aka tagged unions.
> 
> Stepping back a little, can I ask what the purpose of this project is?
> Do you have an application area and target where you want to use the
> compiler you're writing?  Are you mostly just writing a compiler for fun
> (and there's nothing wrong with that)?  Either way but especially if the
> latter, why Forth?  Forth is the way it is partly because of its
> traditional philosophy of keeping its implementation very simple.  There
> are fancy implementations out there, but they were written mostly to
> bring better performance to programs written with familiar Forth
> techniques.

I think Forth has a lot more potential as a language than the usage it gets would indicate. And I think that has a lot to do with its almost myopic focus on the lower-levels of coding. I want to create something that people can use on the high-end to write modern end user applications -- a language that is very approachable. But that still holds to Forth principles, so one could still drop down to lower levels if they want/need to.

> It sounds like you've been using C++.  If you want exposure to fancier
> uses of type systems, you might give Haskell a try.
> http://learnyouahaskell.com is a good place to start.

Oh, I have explored Haskell. Lots of interesting ideas. A bit too "interesting" I think. On the surface Haskell seems great, but as I explored it more the extreme focus on types, pure functionality and heavy academics, starts to wear on code clarity, at least it seemed that way to me. Just look up how to generate a random number for instance.

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

#51720

trans <transfire@gmail.com> writes:
> It's static as much as possible and dynamic otherwise,

Normally I think of "dynamic" as meaning "runtime type tags".  Maybe
that's approximately what you plan to do with jump tables.

> I want to create something that people can use on the high-end to
> write modern end user applications -- a language that is very
> approachable. But that still holds to Forth principles, so one could
> still drop down to lower levels if they want/need to.

You might look at Oforth, 8th, Factor, and Postscript as someone
mentioned.  I myself haven't yet understood the attraction of Forth-like
syntax in those languages, at least for humans: once you're willing to
have that many moving parts in an implementation, you might as well
offer an automatic way to tell (e.g.) where the arg list for a function
begins and ends.  So you end up with something like Lisp instead of
Forth.  There's also Strongforth which may have already come up here.

> On the surface Haskell seems great, but as I explored it more the
> extreme focus on types, pure functionality and heavy academics, starts
> to wear on code clarity, at least it seemed that way to me. 

Yes, it was invented as a research testbed rather than a software
delivery mechanism.  It's still a good way to get exposed to
sophisticated type systems if you haven't seen them before.

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

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

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

csiph-web