advantages of RPN

[Don Shepherd]

(05-23-2014 05:08 AM)Matt Agajanian Wrote:  Thanks for the linkup. That brochure is a top five favourite of mine. Extra thanks that you found the colour version!!

I have no idea where I got it, but it must have been from a previous forum post by someone else. This topic has been discussed before!

[Matt Agajanian]

(05-23-2014 08:49 AM)Don Shepherd Wrote:  

(05-23-2014 05:08 AM)Matt Agajanian Wrote:  Thanks for the linkup. That brochure is a top five favourite of mine. Extra thanks that you found the colour version!!

I have no idea where I got it, but it must have been from a previous forum post by someone else. This topic has been discussed before!

In any event, thanks again!

[Matt Agajanian]

While we're on the subject, (RPN of course), I found a very helpful iPhone app that makes for quite a good tutorial and understanding of RPN if one was ever to teach others about RPN. It's called 'Active RPN.'

What makes this app so helpful;

T, Z, Y and X are always visible and in top-to-botttom order so users can see stack behaviour
Last X is also visible and, unique to this app, Last Y is shown, retained and can be recalled.
An ongoing trace mode and page are available.

Here's the webage link:

http://www.math3g.com/Site/RPN_Progs.html

Here's the iPhone app link:

https://itunes.apple.com/us/app/active-r...47341?mt=8

[Alvaro]

(05-23-2014 04:35 PM)Matt Agajanian Wrote:  While we're on the subject, (RPN of course), I found a very helpful iPhone app that makes for quite a good tutorial and understanding of RPN if one was ever to teach others about RPN. It's called 'Active RPN.'

What makes this app so helpful;

T, Z, Y and X are always visible and in top-to-botttom order so users can see stack behaviour
Last X is also visible and, unique to this app, Last Y is shown, retained and can be recalled.
An ongoing trace mode and page are available.

Here's the webage link:

http://www.math3g.com/Site/RPN_Progs.html

Here's the iPhone app link:

https://itunes.apple.com/us/app/active-r...47341?mt=8

That with the "Stack" and Variables is one thing that I never could understand, it sounds to me as "joke".
The usage of a Variable on a Program is that it can be used many times. That is the sense of Variables. And NOT only at a Stage of program but ANYTIME you need.
I realy don´t understand the sense of that "Stack operations" DROP, DUP .

[Thomas Klemm]

(05-23-2014 05:00 PM)Alvaro Wrote:  I really don´t understand the sense of that "Stack operations" DROP, DUP .

We don't get the impression you want to know.

Cheers
Thomas

[Alvaro]

(05-23-2014 05:17 PM)Thomas Klemm Wrote:  

(05-23-2014 05:00 PM)Alvaro Wrote:  I really don´t understand the sense of that "Stack operations" DROP, DUP .

We don't get the impression you want to know.

Cheers
Thomas

I only spend time with things that appears useful and consistent to me

[rprosperi]

(05-23-2014 05:17 PM)Thomas Klemm Wrote:  We don't get the impression you want to know...

LOL! I sense you too have no diplomatic career plans. That said, I would certainly vote for you if you did!

[Thomas Klemm]

(05-23-2014 05:34 PM)Alvaro Wrote:  I only spend time with things that appears useful and consistent to me

Then tell us more about that. It's definitely more interesting than talking about stuff you don't like.

[Garth Wilson]

(05-23-2014 05:00 PM)Alvaro Wrote:  That with the "Stack" and Variables is one thing that I never could understand, it sounds to me as "joke".
The usage of a Variable on a Program is that it can be used many times. That is the sense of Variables. And NOT only at a Stage of program but ANYTIME you need.

This goes beyond the four-level stack HP put on calculators before they were programmable, so I'll address it outside that context.

Here's an example. I'm finishing up another work project with a low-cost PIC16F microcontroller for a commercial product, with 5,500 lines of code. Its processor has only one register to hold values you're working with, and no direct access to the return stack. Although you can synthesize a data stack in software, the processor's instruction set does not give an efficient way to access bytes other than the one at the top of the stack (or at the bottom in the case of HP calculators' upside-down stacks), limiting its usefulness.

So then, I have a lot of temporary variables-- TEMP_W, TEMP_1, TEMP_2, TEMP_3, TEMP_4, and TEMP_5, LOOP_CNT (loop counter), LOOP_CNT_2, LOOP_CNT_3, and LOOP_CNT_4. These hold values needed temporarily, unlike ones that are long-term. If you were to create a single-purpose variable everywhere you need a temporary variable, the microcontroller would need more RAM. I've used it all up as it is.

Now I can use temporary variables to pass parameters to and from subroutines, and as loop counters for nested loops; but I have to be extremely careful to make sure that one nested subroutine does not overwrite data that is still needed by another one it's nested with, even six subroutine levels deep. Sometimes it is hard to anticipate which subroutines will get used at the same time, so later debugging may include changing which temporary varialbes a particular routine uses, after doing a search in the source code to find out if such a change will cause other problems.

It goes even further. To get enough variable space in RAM, other variables that are not general-purpose temporary ones get re-used for something else in the brief times they're not needed for their normal purpose. Again, the programmer must be extremely careful.

Now let's say you have RAM to burn-- ie, more than you could ever need. Doing things this way, you still cannot save environments and have re-entrant routines. Even without that, having such a load of variables may require care choosing unique names, and having so many variables makes it more difficult to keep a project from getting out of control.

These problems could all be avoided if I could use stacks (like Forth's return stack and data stack).

[Claudio L.]

(05-23-2014 06:44 PM)Garth Wilson Wrote:  These problems could all be avoided if I could use stacks (like Forth's return stack and data stack).

Besides your specific case, in general, scoped local variables have been in most programming languages since I was a kid.
99.9% of the compilers use a stack to store your local variables (ok, they use microprocessor registers when they are available, then fall back to the stack when they run out). That's how they avoid 'all these problems', so the 'problems' aren't really there for the user, they are solved by the compiler/interpreter at a lower layer.

So the stack is always there, you like it or not, and it takes about the same amount of RAM and processing power whether you are the one driving it or a compiler/interpreter. It really goes to what the user wants/needs:

Direct access to the stack? or use readable names and let a compiler/interpreter handle the stack for you?

A lot of people prefer engines with carburators because they can understand how it works, they love to open the hood, take it apart and fiddle with it all they want. Some other people prefer modern injection engines, where you have to plug a laptop to fiddle with it and you never actually get dirty, and there's others that don't even know that there's an engine in the car and don't really care as long as the car moves.

For calculations it's exactly the same: There's people that want to see and control every step of their analysis. There's people that want their analysis done for them but like to see automatic step-by-step solutions, and then there's people that just want the final answer and don't care how you get there.

There's a place for everything, for high level languages with variables, for lower level languages with stacks, and even for senseless flame wars of RPN vs algebraic.

Claudio

PS: I wrote a firmware for a PIC16F for my Masters thesis. A pain to code in assembler but lots of fun. In that microcontroller, you'll have a hard time guaranteed, RPN or algebraic. For those interested:
http://www.microchip.com/wwwproducts/Dev...=PIC16F876
And yes, it is BYTES of ram, there's no K, no M, no G before bytes.

[Alvaro]

(05-23-2014 08:37 PM)Claudio L. Wrote:  Besides your specific case, in general, scoped local variables have been in most programming languages since I was a kid.
99.9% of the compilers use a stack to store your local variables (ok, they use microprocessor registers when they are available, then fall back to the stack when they run out). That's how they avoid 'all these problems', so the 'problems' aren't really there for the user, they are solved by the compiler/interpreter at a lower layer.

So the stack is always there, you like it or not, and it takes about the same amount of RAM and processing power whether you are the one driving it or a compiler/interpreter. It really goes to what the user wants/needs:

Direct access to the stack? or use readable names and let a compiler/interpreter handle the stack for you?

A lot of people prefer engines with carburators because they can understand how it works, they love to open the hood, take it apart and fiddle with it all they want. Some other people prefer modern injection engines, where you have to plug a laptop to fiddle with it and you never actually get dirty, and there's others that don't even know that there's an engine in the car and don't really care as long as the car moves.

For calculations it's exactly the same: There's people that want to see and control every step of their analysis. There's people that want their analysis done for them but like to see automatic step-by-step solutions, and then there's people that just want the final answer and don't care how you get there.

There's a place for everything, for high level languages with variables, for lower level languages with stacks, and even for senseless flame wars of RPN vs algebraic.

Claudio

PS: I wrote a firmware for a PIC16F for my Masters thesis. A pain to code in assembler but lots of fun. In that microcontroller, you'll have a hard time guaranteed, RPN or algebraic. For those interested:
http://www.microchip.com/wwwproducts/Dev...=PIC16F876
And yes, it is BYTES of ram, there's no K, no M, no G before bytes.

Hi Claudio,
Today I real learned something. Thank you very much. Very well explained and very informativ.
Now I understand where to "place" the need of the "Stack".

I am a "End-User" and I need a computer to help me to work and not prevent me from work.
Yes, I do not care how the Hardware/Software do "its" job to help me. It is a matter of fact, indeed.
Now, about flaming, I have the feeling that there are people that "interpret" any "against" opinion as some sort of provocation. Well, I can very well deal with "against" opinios while I mainting my serenty and clearity about the main problem.

Regards
Alvaro

[Paul Dale]

(05-23-2014 06:44 PM)Garth Wilson Wrote:  Here's an example. I'm finishing up another work project with a low-cost PIC16F microcontroller for a commercial product, with 5,500 lines of code....

Why would anyone use a PIC in a commercial product?
There are other processors that are as cheap and far more capable...


- Pauli

[Garth Wilson]

(05-24-2014 09:22 AM)Paul Dale Wrote:  

(05-23-2014 06:44 PM)Garth Wilson Wrote:  Here's an example. I'm finishing up another work project with a low-cost PIC16F microcontroller for a commercial product, with 5,500 lines of code....

Why would anyone use a PIC in a commercial product?
There are other processors that are as cheap and far more capable...

It was a suitable fit for early work projects going back 18 years, but the last project has had me taking it far beyond what it was designed to do, and future projects may go further; so yes, I will be looking into a new µC family for the next 10-20 years' work. I have a lot invested in this one, in terms of learning its traps, its I/O, having a lot of code I can re-use (including my structure macros and other macros), knowing the MPASM assembler really well, having a production-worthy programmer, etc.; so I do not take lightly the matter of switching families. That even goes for things like op amps, where there are subtleties that don't come through in the data sheets, only through experience, so I don't carelessly hop from one to another. That's rather O.T., so if I can solicit your input, I'll link to this forum topic, or this one (the same thing on two different low-traffic forums).

[Alvaro]

(05-24-2014 10:09 AM)Garth Wilson Wrote:  

(05-24-2014 09:22 AM)Paul Dale Wrote:  Why would anyone use a PIC in a commercial product?
There are other processors that are as cheap and far more capable...

It was a suitable fit for early work projects going back 18 years, but the last project has had me taking it far beyond what it was designed to do, and future projects may go further; so yes, I will be looking into a new µC family for the next 10-20 years' work. I have a lot invested in this one, in terms of learning its traps, its I/O, having a lot of code I can re-use (including my structure macros and other macros), knowing the MPASM assembler really well, having a production-worthy programmer, etc.; so I do not take lightly the matter of switching families. That even goes for things like op amps, where there are subtleties that don't come through in the data sheets, only through experience, so I don't carelessly hop from one to another. That's rather O.T., so if I can solicit your input, I'll link to this forum topic, or this one (the same thing on two different low-traffic forums).

Hi Garth,
I do quite understand your point.
COMPATIBILTY was and is a major problem on Computing world.
There is always apearing "new" things, more capable, BUT you have to forgett and throw away all the work , all the knowledge of many years of learning and effort.
Since many years I am aware of that problem and I am avoiding very consequently not to get tied to something people want to tie me.

[Les Bell]

(05-24-2014 10:09 AM)Garth Wilson Wrote:  I have a lot invested in this one, in terms of learning its traps, its I/O, having a lot of code I can re-use (including my structure macros and other macros), knowing the MPASM assembler really well, having a production-worthy programmer, etc.; so I do not take lightly the matter of switching families.

Amen! And, of course, that relates to why so many of us happily soldier on with RPN calculators - we have a lot invested in terms of time spent learning our way around the machine, libraries of code we can reuse, manuals and books, peripherals, etc.

I've often joked that just when a programming language or other major subsystem becomes mature, stable, well-documented, bug-free and highly productive, it will be taken off the market and replaced with a new one that is none of these things. Only, it's not really a joke, is it?

[Garth Wilson]

Where's the "Like" button?

[Joe Horn]

(05-25-2014 03:18 AM)Garth Wilson Wrote:  Where's the "Like" button?

[Garth Wilson]

Related: Low Fat Computing: A politically incorrect essay by Jeff Fox 12/6/98. He, working with Chuck Moore, the inventor of Forth, used Forth hardware and software to improve the compactness and speed of code by anywhere from 100 to 1000 times. (Forth uses RPN, by the way.) Toward the end, he says,

Quote:The computer industry is basically a shell game of marketing fat. [...] For many years I was a consultant to Bank of America and Pacific Bell and published articles in PC World and ComputerWorld. [...] I just object to the ethics of an entire industry that adds fat to products and markets fat to increase profit margins.

[Jake Schwartz]

(05-22-2014 12:09 AM)Dale Reed Wrote:  

(05-21-2014 09:34 PM)Don Shepherd Wrote:  Enter versus Equals

I had a t-shirt back in college that had:

ENTER^ > =

... with the ENTER^ and = drawn like calculator keys. IIRC, it was gray with blue keys and white legends screen printed. Wore it with pride. I wish I had kept the remnants, but alas... Maybe some day I'll see one on TAS.

Dale

Did you mean this one?

[Don Shepherd]

(05-26-2014 09:32 PM)Jake Schwartz Wrote:  

(05-22-2014 12:09 AM)Dale Reed Wrote:  I had a t-shirt back in college that had:

ENTER^ > =

... with the ENTER^ and = drawn like calculator keys. IIRC, it was gray with blue keys and white legends screen printed. Wore it with pride. I wish I had kept the remnants, but alas... Maybe some day I'll see one on TAS.

Dale

Did you mean this one?

In the posted article, Gary Tenzer mentions the Chinese interest in the game "Bagels." I notice that Joseph Armstrong and (our own) Richard Nelson wrote versions of this program for the HP-65 in the HP-65 User's library.