Re: Forth Implementations advantages and disadvantages.

From	Cecil Bayona <cbayona@cbayona.com>
Newsgroups	comp.lang.forth
Subject	Re: Forth Implementations advantages and disadvantages.
Date	2017-05-28 21:07 -0500
Organization	A noiseless patient Spider
Message-ID	<ogfvje$bma$1@dont-email.me> (permalink)
References	(4 earlier) <62e10459-9520-4e7b-b378-cff16e351fa7@googlegroups.com> <ogdg19$6tj$1@dont-email.me> <76d52560-abac-4a83-a208-f63355f8852e@googlegroups.com> <ogetaf$3jc$1@dont-email.me> <f29ebb3b-e12c-4338-81ec-0039204ad3e3@googlegroups.com>

Show all headers | View raw

On 5/28/2017 4:45 PM, hughaguilar96@gmail.com wrote:
> On Sunday, May 28, 2017 at 9:22:57 AM UTC-7, Cecil - k5nwa wrote:
>> On 5/28/2017 12:10 AM, hughaguilar96@gmail.com wrote:

>>
>> The  J1 is a stack CPU so why would one pass data in global variables?
>> One would use the Data Stack with Forth.
> 
> The data-stack is pretty cumbersome when you have more than three items. You end up with a lot of stack-juggling words --- also, you use >R R> to get data off the data-stack and out of the way temporarily --- the result is horrendously complicated code, even for simple functions, and Forth becomes a nightmare to maintain (even by the original programmer himself).
> 
> There are three methods available to prevent Forth from becoming a brain-buster, and turning Forth into an elegant language:
> 
> 1.) Use local variables. Any function that has more than three parameters is a candidate for local variables. You should never use ROLL but should always use local variables instead.
> 
> 2.) Pack your data into a struct, then pass the pointer to the struct into the function as a parameter. Oftentimes when you have a function with a lot of parameters, the parameters are related to each other. For example, the X Y and Z coordinates of a point should not be passed in as separate parameters (if you have two points, that's 6 parameters), but should be packed into a struct of type PT and the pointer to the struct passed in (if you have two points, that's 2 parameters).
> 
> 3.) Create a separate stack dedicated to a common data-type. In my STRING-STACK.4TH package, I provide a stack for strings.
> 
> Your typical ANS-Forth programmer is not smart enough to understand the three methods mentioned above. Your typical ANS-Forth programmer will pass data between functions in global variables. This is why PAD was put in the ANS-Forth standard. This is why most ANS-Forth programs are littered with VARIABLE and VALUE words that are used for holding data temporarily, and the functions have various assumptions about which global variables they need set and which global variables they will set (even if these assumptions are documented, the program is still confusing and unreliable).
> 

>> Having a Doubles Stack is very odd so it would create a lot of software
>> compatibility issues but then Forthers are not famous for sharing
>> software. What is the justification for such an odd item, does it really
>> improve Forth?
> 
> I am assuming that you want a good Forth system --- not ANS-Forth, which looks like something from the 1970s.
> 

I wish it did then it would be a decent Forth but as it is they tried to 
please everyone and ended with a lot of ambiguity.

> One of the major flaws of ANS-Forth was that it has single-cell and double-cell data intermixed on the data-stack (it even allows floats on the data-stack, although everybody ignores that and uses a separate float-stack). This is one of the reasons why ANS-Forth code is so badly infected with stack-juggling words and >R R> etc.. For example, if you have two doubles and a single on the data-stack, this is not three items (three would be manageable, as I said before) --- this is five items --- this is going to result in a hard-to-read mess.
> 
> The mixed-precision arithmetic words will access both stacks. For example:
> S>D ( n -- )  \double: -- n
> M* ( a b -- )  \double: -- n
> FM/MOD ( divisor -- remainder quotient )  \double: numerator --
> 

The data shuffling is a royal pain and a killer of efficiency, you end 
up running a lot of code that does not solve your application because 
data needs to be accessed. That is one reason wy people like Algol like 
languages because this is handled for you.

> It is also possible to store strings on the double-stack as address/count pairs. Note that if you do this, then you can't have COW (copy-on-write) such as I have in STRING-STACK.4TH --- you have to copy the string to a new heap struct when you do DUP$ or OVER$ etc. --- in a micro-controller, you aren't likely working with strings very much though, so this inefficiency isn't a major problem.
> 
> All in all, I think that a double-stack greatly improves Forth. There is no point in developing a new Forth unless it is going to be an improvement over ANS-Forth --- improving on ANS-Forth is easy and obvious --- this should always be done.
> 

If you have registers capable of implementing a stack the why stop at two?

>> I would think if one is going to be odd and add an extra stack it might
>> be more useful as a DO LOOP stack so the Data Stack and the Return Stack
>> has no extra garbage making the code simpler.
> 
> I wouldn't have DO LOOP at all. That is just cruft from the 1970s.
> 
> You have local variables, so you should do iteration using BEGIN WHILE REPEAT and hold the index or whatever in local variables. The DO LOOP constructs use I and J as a crude kind of local variable --- this is not necessary if you have actual local variables available.
> 

OK but I like the DO LOOP because its easy to use and the I local is 
very handy at times and helps you avoid doing unnecessary math.

> Also, the application programmer shouldn't normally use BEGIN WHILE REPEAT at all. Code that does iteration using BEGIN WHILE REPEAT should be buried inside of HOFs, which are typically written by code-library writers or "systems programmers" or whatever. The application programmer would do iteration by writing a quotation and giving the quotation to a HOF that does the iteration internally and executes the quotation. I would expect that most programs would not have any explicit iteration with BEGIN WHILE REPEAT but would rely entirely on HOFs.
> 

I'm not familiar with these techniques as I mostly have used older Forth 
where these are not available. Maybe I have used something similar in 
Delphi but they would be called something else, I do recall writing code 
where a function defined inside another function can access the data of 
the parent and change that data, but I forget what it was called. I used 
it to eliminate the passing of a whole lot of data to a function.

>> Thanks for reminding me about PAC (Portab le Assembler Code), it changes
>> the whole trajectory of the project, if PAC  can generate efficient code
>> then it would be an ideal setup for this and other projects. In any case
>> it is bound to be faster than using C.
> 
> The PDP11 is the grandfather of all register-based processors (MC68000, PIC24, MSP430, etc.). If your assembler is for the PDP11, it can easily be retargeted to to any of these other processors, as all of them are supersets of the PDP11.

All those processors are nice to work with, add to that the dsPIC as it 
is an enhanced PIC24, very nice and is also available in DIP packaging 
so its easy to experiment with. Somewhere I have a PDF file which is a 
copy of the PDP11 programmers manual, I'll look at it, but the MSP430 is 
also a good choice. Somewhere filed away is a MSP430 IP for FPGA, the 
one advantage it has is it uses a 200MHz clock so it really flies.

> 
> You can also retarget it to processors such as the 6812 that have a shortage of registers (are a subset of the PDP11), but in this case some of the PDP11 registers will have to be implemented as pseudo-registers in memory --- this is going to be pretty inefficient, but at least you get portability --- these processors are obsolete nowadays, so nobody is likely to want to use them anyway.
> 

There are a couple of old CPUs that eventually I want to build either a 
board or a FPGA version, the Z80, MC6809, 6502 or its modern version the 
W65C816.

> The MSP430 has 16 registers total. I would still use the PDP11 as your assembly-language as I described above. You can, however, have the main-program use some of the registers, and ISRs use the other registers. This means that ISRs don't have to save and restore registers (assuming that ISRs can't be interrupted). This should boost the speed of your system considerably, as a lot of micro-controller programs spend up to 50% of their time servicing interrupts. You will have to write your compiler in such a way that it is able to use the correct set of registers as R0..R7 depending upon whether it is compiling a colon word to be used in the main-program or is compiling an ISR. This should be easy. Put the functions that can be used by the main-program in one vocabulary and the functions that can be used by ISRs in another vocabulary, so there is no confusion if they have the same names.
> 
> I think you are totally messing up the efficiency of your Forth system by assuming that you have 16 registers and your Forth should use them all. As I said, an optimizing compiler can make use of extra registers to hold values temporarily, but writing such an optimizing compiler is very difficult (I've never done it, and I wouldn't know how to even begin such a project). A much better use of 16 registers is to have two banks of 8 registers, which are used by the main-program and the ISRs. This is a micro-controller, after all --- most micro-controllers spend significant amounts of time saving and restoring registers as they enter and exit ISRs --- making ISRs efficient is the obvious way to boost the speed, and a lot easier than writing an optimizing compiler.

There are so many ways to optimize code, many books have been written on 
the subject and it is an interesting subject. The times I have written 
optimizing code generators which is for about 12 different CPUs I been 
off the beaten path and done it my way which generally not how it is 
found in compiler books. It may not be the most optimum way of doing it 
but I don't care to be a lemming, it works good enough and it's simple 
enough. I feel the same way about Forth I like what I like and too bad 
if the rest of the world does not agree. But I'm always willing to learn 
something new or a better way to do things.

One day you need to try it it's a lot of fun watching simply generated 
code turn into an object of beauty and efficiency.

> 
> Anyway --- my way of thinking about Forth is totally alien to that of the ANS-Forth and Forth-200x folks --- they are going to continue to use gForth (written in C) on the ARM under Linux (also written in C) and describe this as a "Forth micro-controller."
> 

Really, I could not tell. I've heard rumors that you are not a happy 
camper when it comes to ANS Forth is there anything to that rumor?

-- 
Cecil - k5nwa

Thread

Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-26 14:49 -0500
  Re: Forth Implementations advantages and disadvantages. minforth@arcor.de - 2017-05-26 13:17 -0700
    Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-26 17:53 -0500
      Re: Forth Implementations advantages and disadvantages. Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-26 22:31 -0700
        Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-27 00:57 -0500
  Re: Forth Implementations advantages and disadvantages. rickman <gnuarm@gmail.com> - 2017-05-27 01:09 -0400
    Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-27 00:59 -0500
      Re: Forth Implementations advantages and disadvantages. rickman <gnuarm@gmail.com> - 2017-05-27 02:09 -0400
        Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-27 09:35 -0500
          Re: Forth Implementations advantages and disadvantages. rickman <gnuarm@gmail.com> - 2017-05-27 12:22 -0400
            Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-27 11:53 -0500
              Re: Forth Implementations advantages and disadvantages. rickman <gnuarm@gmail.com> - 2017-05-27 13:13 -0400
              Re: Forth Implementations advantages and disadvantages. David Schultz <abuse@127.0.0.1> - 2017-05-27 12:24 -0500
                Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-27 13:13 -0500
                Re: Forth Implementations advantages and disadvantages. David Schultz <abuse@127.0.0.1> - 2017-05-27 13:33 -0500
                Re: Forth Implementations advantages and disadvantages. rickman <gnuarm@gmail.com> - 2017-05-27 14:53 -0400
                Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-27 14:44 -0500
                Re: Forth Implementations advantages and disadvantages. albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-28 10:09 +0200
                Re: Forth Implementations advantages and disadvantages. rickman <gnuarm@gmail.com> - 2017-05-28 12:57 -0400
                Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-28 12:14 -0500
                Re: Forth Implementations advantages and disadvantages. Paul Rubin <no.email@nospam.invalid> - 2017-05-28 16:11 -0700
                Re: Forth Implementations advantages and disadvantages. rickman <gnuarm@gmail.com> - 2017-05-29 02:11 -0400
                Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-29 01:54 -0500
                Re: Forth Implementations advantages and disadvantages. rickman <gnuarm@gmail.com> - 2017-05-29 03:22 -0400
    Re: Forth Implementations advantages and disadvantages. Joel Rees <joel.rees@gmail.com> - 2017-05-28 15:46 -0700
  Re: Forth Implementations advantages and disadvantages. Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-27 01:23 -0500
    Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-27 09:29 -0500
      Re: Forth Implementations advantages and disadvantages. Paul Rubin <no.email@nospam.invalid> - 2017-05-27 11:36 -0700
        Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-27 14:25 -0500
      Re: Forth Implementations advantages and disadvantages. Rod Pemberton <NeedNotReplyHere@xrsevnneqk.cem> - 2017-05-27 21:58 -0400
    Re: Forth Implementations advantages and disadvantages. hughaguilar96@gmail.com - 2017-05-27 11:20 -0700
      Re: Forth Implementations advantages and disadvantages. rickman <gnuarm@gmail.com> - 2017-05-27 15:20 -0400
      Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-27 14:20 -0500
        Re: Forth Implementations advantages and disadvantages. rickman <gnuarm@gmail.com> - 2017-05-27 18:33 -0400
          Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-27 18:50 -0500
            Re: Forth Implementations advantages and disadvantages. rickman <gnuarm@gmail.com> - 2017-05-27 20:13 -0400
          Re: Forth Implementations advantages and disadvantages. albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-28 10:23 +0200
            Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-28 12:26 -0500
              Re: Forth Implementations advantages and disadvantages. Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-30 04:22 -0500
                Re: Forth Implementations advantages and disadvantages. albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-30 11:49 +0200
                Re: Forth Implementations advantages and disadvantages. Andrew Haley <andrew29@littlepinkcloud.invalid> - 2017-05-30 05:07 -0500
                Re: Forth Implementations advantages and disadvantages. Lars Brinkhoff <lars.spam@nocrew.org> - 2017-05-30 18:58 +0200
            Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-28 12:28 -0500
              Re: Forth Implementations advantages and disadvantages. albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-28 20:14 +0200
                Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-28 14:08 -0500
                Re: Forth Implementations advantages and disadvantages. albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-29 10:52 +0200
                Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-29 12:50 -0500
                Re: Forth Implementations advantages and disadvantages. Alex <alex@rivadpm.com> - 2017-05-29 19:06 +0100
        Re: Forth Implementations advantages and disadvantages. hughaguilar96@gmail.com - 2017-05-27 20:00 -0700
          Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-27 22:29 -0500
            Re: Forth Implementations advantages and disadvantages. hughaguilar96@gmail.com - 2017-05-27 22:10 -0700
              Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-28 11:22 -0500
                Re: Forth Implementations advantages and disadvantages. hughaguilar96@gmail.com - 2017-05-28 14:45 -0700
                Re: Forth Implementations advantages and disadvantages. hughaguilar96@gmail.com - 2017-05-28 18:25 -0700
                Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-28 21:43 -0500
                Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-06-01 11:27 -0500
                Re: Forth Implementations advantages and disadvantages. rickman <gnuarm@gmail.com> - 2017-06-01 12:50 -0400
                Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-06-01 12:47 -0500
                Re: Forth Implementations advantages and disadvantages. rickman <gnuarm@gmail.com> - 2017-06-01 16:23 -0400
                Re: Forth Implementations advantages and disadvantages. rickman <gnuarm@gmail.com> - 2017-06-01 16:32 -0400
                Re: Forth Implementations advantages and disadvantages. hughaguilar96@gmail.com - 2017-06-01 12:08 -0700
                Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-06-01 21:47 -0500
                Re: Forth Implementations advantages and disadvantages. hughaguilar96@gmail.com - 2017-06-02 06:34 -0700
                Re: Forth Implementations advantages and disadvantages. foxaudioresearch@gmail.com - 2017-06-02 07:13 -0700
                Re: Forth Implementations advantages and disadvantages. hughaguilar96@gmail.com - 2017-06-02 07:57 -0700
                Re: Forth Implementations advantages and disadvantages. albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-06-03 02:17 +0200
                Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-28 21:07 -0500
                Re: Forth Implementations advantages and disadvantages. hughaguilar96@gmail.com - 2017-05-28 21:48 -0700
                Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-29 00:52 -0500
                Re: Forth Implementations advantages and disadvantages. hughaguilar96@gmail.com - 2017-05-29 09:17 -0700
                Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-29 12:16 -0500
                Re: Forth Implementations advantages and disadvantages. hughaguilar96@gmail.com - 2017-05-29 19:21 -0700
                Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-29 23:13 -0500
                Re: Forth Implementations advantages and disadvantages. Paul Rubin <no.email@nospam.invalid> - 2017-05-30 01:07 -0700
                Re: Forth Implementations advantages and disadvantages. Alex <alex@rivadpm.com> - 2017-05-30 15:54 +0100
                Re: Forth Implementations advantages and disadvantages. Alex <alex@rivadpm.com> - 2017-05-29 19:02 +0100
                Re: Forth Implementations advantages and disadvantages. Raimond Dragomir <raimond.dragomir@gmail.com> - 2017-05-29 11:06 -0700
                Re: Forth Implementations advantages and disadvantages. hughaguilar96@gmail.com - 2017-05-29 19:29 -0700
                Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-29 23:01 -0500
                Re: Forth Implementations advantages and disadvantages. hughaguilar96@gmail.com - 2017-05-30 14:53 -0700
                Re: Forth Implementations advantages and disadvantages. Paul Rubin <no.email@nospam.invalid> - 2017-05-29 13:59 -0700
                Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-29 17:03 -0500
                Re: Forth Implementations advantages and disadvantages. hughaguilar96@gmail.com - 2017-05-29 19:37 -0700
                Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-29 22:52 -0500
            Re: Forth Implementations advantages and disadvantages. Mark Wills <markwills1970@gmail.com> - 2017-05-28 11:49 -0700
              Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-28 14:12 -0500
              Re: Forth Implementations advantages and disadvantages. rickman <gnuarm@gmail.com> - 2017-05-29 02:35 -0400
          Re: Forth Implementations advantages and disadvantages. jim.brakefield@ieee.org - 2017-05-27 21:04 -0700
            Re: Forth Implementations advantages and disadvantages. hughaguilar96@gmail.com - 2017-05-27 21:56 -0700
              Re: Forth Implementations advantages and disadvantages. jim.brakefield@ieee.org - 2017-05-28 01:10 -0700
                Re: Forth Implementations advantages and disadvantages. rickman <gnuarm@gmail.com> - 2017-05-28 13:21 -0400
                Re: Forth Implementations advantages and disadvantages. jim.brakefield@ieee.org - 2017-05-28 11:53 -0700
                Re: Forth Implementations advantages and disadvantages. hughaguilar96@gmail.com - 2017-05-28 15:09 -0700
                Re: Forth Implementations advantages and disadvantages. rickman <gnuarm@gmail.com> - 2017-05-29 02:40 -0400
                Re: Forth Implementations advantages and disadvantages. jim.brakefield@ieee.org - 2017-05-29 13:10 -0700
                Re: Forth Implementations advantages and disadvantages. rickman <gnuarm@gmail.com> - 2017-05-30 00:57 -0400
          Re: Forth Implementations advantages and disadvantages. rickman <gnuarm@gmail.com> - 2017-05-28 02:17 -0400
            Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-28 11:50 -0500
              Re: Forth Implementations advantages and disadvantages. rickman <gnuarm@gmail.com> - 2017-05-28 13:52 -0400
                Re: Forth Implementations advantages and disadvantages. Cecil Bayona <cbayona@cbayona.com> - 2017-05-28 13:47 -0500
                Re: Forth Implementations advantages and disadvantages. rickman <gnuarm@gmail.com> - 2017-05-29 03:19 -0400
              Re: Forth Implementations advantages and disadvantages. hughaguilar96@gmail.com - 2017-05-28 15:40 -0700
  Re: Forth Implementations advantages and disadvantages. Joel Rees <joel.rees@gmail.com> - 2017-05-28 16:31 -0700
    Re: Forth Implementations advantages and disadvantages. Joel Rees <joel.rees@gmail.com> - 2017-05-28 20:17 -0700
      Opinions on a C language header for words? Joel Rees <joel.rees@gmail.com> - 2017-05-28 21:38 -0700

csiph-web