Go Forth And Prosper

[Teahive]

PN/RPN may have the benefit of not having to type parentheses, but the visual representation should still have a clear grouping of sub-expressions.

If you are used to reading RPN it is pretty clear. And there are things you can do to help clarity.

Of course there are things you can do to help clarity. Like actually displaying a tree of sorts, not a linear sequence. Then you wouldn't have to scan through the linear sequence to find where sub-expressions begin (which you have to do with RPN just as with infix/prefix notation).

[MSimon]

PN/RPN may have the benefit of not having to type parentheses, but the visual representation should still have a clear grouping of sub-expressions.

If you are used to reading RPN it is pretty clear. And there are things you can do to help clarity.

Of course there are things you can do to help clarity. Like actually displaying a tree of sorts, not a linear sequence. Then you wouldn't have to scan through the linear sequence to find where sub-expressions begin (which you have to do with RPN just as with infix/prefix notation).

Well OK you don't like RPN. HP sold quite a few calculators with that model.

In the computer you have to have the two arguments before you can do anything with them. Every single compiler is RPN. Forth just does you the favor of making that explicit. You don't like it? Don't use it. However you are then at the mercy of the compiler writer. I can't tell you how many times that has caused me problems in the real world.

It is one of the reasons I will only write C if paid for it.

In Forth we just write the sub expressions as another fragment. That is not encouraged in C because of the stack thrash every time you invoke a new routine.

Computer science tells you that small short easily tested routines is the way to go. Real time C encourages the opposite because the stack thrash is a time waster.

But as I said - don't like it - don't use it. I like competing against projects coded in C.

[hanelyp]

In Forth we just write the sub expressions as another fragment. That is not encouraged in C because of the stack thrash every time you invoke a new routine.

I've been following a CPU in development where that's not a problem, http://millcomputing.com/
Being a fan of stack based architectures you might start with http://millcomputing.com/docs/belt/

[MSimon]

In Forth we just write the sub expressions as another fragment. That is not encouraged in C because of the stack thrash every time you invoke a new routine.

I've been following a CPU in development where that's not a problem, http://millcomputing.com/
Being a fan of stack based architectures you might start with http://millcomputing.com/docs/belt/

http://millcomputing.com/docs/belt/
- typical misprediction penalty is five cycles - in Forth machines the pipeline penalty is zero or one cycle and there is no prediction. Prediction and long pipelines add significant silicon.

But I can see that as a way to improve "C".

[hanelyp]

http://millcomputing.com/docs/belt/
- typical misprediction penalty is five cycles - in Forth machines the pipeline penalty is zero or one cycle and there is no prediction. Prediction and long pipelines add significant silicon.

But I can see that as a way to improve "C".

You're comparing apples to oranges. That's cache access prediction miss penalty, which also applies to a FORTH machine running at clock speeds needing a modern cache. No prediction of branches would make the FORTH machine strictly a great deal slower as it has to access memory for the instruction =after= seeing the branch.

The pipeline described for the Mill is pretty short by modern standards. The prediction mechanism is very simple by modern standards, described elsewhere.

[MSimon]

http://millcomputing.com/docs/belt/
- typical misprediction penalty is five cycles - in Forth machines the pipeline penalty is zero or one cycle and there is no prediction. Prediction and long pipelines add significant silicon.

But I can see that as a way to improve "C".

You're comparing apples to oranges. That's cache access prediction miss penalty, which also applies to a FORTH machine running at clock speeds needing a modern cache. No prediction of branches would make the FORTH machine strictly a great deal slower as it has to access memory for the instruction =after= seeing the branch.

The pipeline described for the Mill is pretty short by modern standards. The prediction mechanism is very simple by modern standards, described elsewhere.

Us Forth guys get around all that by putting 144 cores on a chip. The cores are async so if they have nothing to do they do nothing. You only pay for power that is doing useful work. $20 a pop in lots of 10. 86.4GIPS peak. IIRC ~100ma @ 1.8 V when all the cores are computing. Nothing else even come close in MIPS/W. MIPS/$ or any other metric you like.

So why am I doing what I'm doing with ARM? I'm in the process of training up an Army so I can get a battalion capable of using the GA144.

And BTW you can buy the GA144. The Mill is vaporware.

[MSimon]

BTW the Forth machines don't use prediction. The pipeline is one deep. The penalty is 0 or 1 instruction depending on the last instruction.

You are trying to think of it as if it was a "normal" machine. It is not. The Mill is more normal than the GA144.

[Teahive]

Well OK you don't like RPN. HP sold quite a few calculators with that model.

In the computer you have to have the two arguments before you can do anything with them. Every single compiler is RPN. Forth just does you the favor of making that explicit. You don't like it? Don't use it. However you are then at the mercy of the compiler writer. I can't tell you how many times that has caused me problems in the real world.

Compilers don't use human readable notations internally. (And if you meant stack machine instead of RPN, it's still not true.)
You need both operation and operands at the same time. In fact, without operation you don't know how many operands to fetch.

I don't dislike RPN, I just think that it's at best a minor improvement over infix notation.

In Forth we just write the sub expressions as another fragment. That is not encouraged in C because of the stack thrash every time you invoke a new routine.

Computer science tells you that small short easily tested routines is the way to go. Real time C encourages the opposite because the stack thrash is a time waster.

I have no love for C, but the compiler can inline simple functions and you can use a calling convention that passes most arguments via registers. And the cost of a stack operation isn't a feature of the language.

[Teahive]

Us Forth guys get around all that by putting 144 cores on a chip. The cores are async so if they have nothing to do they do nothing. You only pay for power that is doing useful work. $20 a pop in lots of 10. 86.4GIPS peak. IIRC ~100ma @ 1.8 V when all the cores are computing. Nothing else even come close in MIPS/W. MIPS/$ or any other metric you like.

Any metric? I like FLOPS and memory bandwidth.

It's 650mW peak according to

http://www.greenarraychips.com/home/doc ... 4-1-10.pdf

[MSimon]

Well OK you don't like RPN. HP sold quite a few calculators with that model.

In the computer you have to have the two arguments before you can do anything with them. Every single compiler is RPN. Forth just does you the favor of making that explicit. You don't like it? Don't use it. However you are then at the mercy of the compiler writer. I can't tell you how many times that has caused me problems in the real world.

Compilers don't use human readable notations internally. (And if you meant stack machine instead of RPN, it's still not true.)
You need both operation and operands at the same time. In fact, without operation you don't know how many operands to fetch.

I don't dislike RPN, I just think that it's at best a minor improvement over infix notation.

In Forth we just write the sub expressions as another fragment. That is not encouraged in C because of the stack thrash every time you invoke a new routine.

Computer science tells you that small short easily tested routines is the way to go. Real time C encourages the opposite because the stack thrash is a time waster.

I have no love for C, but the compiler can inline simple functions and you can use a calling convention that passes most arguments via registers. And the cost of a stack operation isn't a feature of the language.

you can use a calling convention that passes most arguments via registers

And when you run out of registers? And then there are the "calling conventions". Usually clumsy and another thing to learn.

[MSimon]

Us Forth guys get around all that by putting 144 cores on a chip. The cores are async so if they have nothing to do they do nothing. You only pay for power that is doing useful work. $20 a pop in lots of 10. 86.4GIPS peak. IIRC ~100ma @ 1.8 V when all the cores are computing. Nothing else even come close in MIPS/W. MIPS/$ or any other metric you like.

Any metric? I like FLOPS and memory bandwidth. :D

It's 650mW peak according to

http://www.greenarraychips.com/home/doc ... 4-1-10.pdf

Thanks! It has been a while since I looked. So what would that make it? 132.9 GIPS/W not too shabby. And you only pay (in power) for the GIPS you are using. Automatically. No power control code required.

[MSimon]

http://spacetimepro.blogspot.com/2014/0 ... etter.html