C translator for calculator project

[Dan]

I'm close to finishing my keystroke programming language for my calculator project, and am starting to think about implementing a high level language similar to C.

The idea is to type programs in C in an editor on the calculator, making the programs far more readable than keystroke spaghetti code. When exiting the editor the text file is used to translate the C program to the keystroke language. The program is then executed as usual.

I'm playing around with some ideas and have jotted down some code for the translator on paper - if anyone knows of any resources that may be of help please let me know.

[Garth Wilson]

I have a hard time associating the word "readable" with C. How about making your calculator language able to take multiple instructions from each line, with white space, and with comments that don't get compiled, and add structure words. I write my HP-41 programs in a text editor this way before entering them on the 41, with the exception of the structure words. I do use the structure words in assembly language though, using macros. I modeled them mostly (but not completely) after Forth structures; so you have for example BEGIN...WHILE...REPEAT, IF...ELSE...END_IF, FOR...NEXT (actually that one is from BASIC), the CASE structure (called switch...case in C), etc.. They're nestable too. Most labels are eliminated, and most branch instructions are hidden. In most cases, there's no penalty, either in run speed or in memory taken, because the macros are assembling the same things you would write out by hand if you had to, only now you don't have to look at the ugly internal details anymore. You still can jump or do other unstructured things if you want to, for those few situations where you don't have the perfect program flow control structure and don't want to take the time to form one you'll only use once. I have examples in the last 40% of my page on simple multitasking methods, at http://wilsonminesco.com/multitask/ , more discussion of the structures at http://wilsonminesco.com/StructureMacros/ , and more on the internal details of how to work a stack in the assembler itself to accomplish all this, at http://wilsonminesco.com/stacks/pgmstruc.html . (These articles are 6502-oriented, but can be applied more widely.)

[Druzyek]

A good place to start might be the shunting yard algorithm or something similar. You can convert algebraic notation to a stack based format that matches what your calculator uses internally. Out of curiosity, why C? I think a lot of calculators use a BASIC-like language so you don't have to worry about types and usually don't need pointers. It's probably not the case that you would write a lot of lower level code in the on board language, right?

[KeithB]

https://github.com/SilverScar/C-Language-Parser

First you will have to create a yacc/lexx clone.

https://clang.llvm.org/get_started.html

Parsing is not for the faint of heart. I created a c-expression parser on the Amiga for a programming "language" for an image processing program. Even just the expression parser was a major task.

An interpreter is much easier.

K and R have a grammar.

[David Hayden]

I agree with Garth Wilson: C might not be the best source language here. I suspect there are things you can do in C that would be cumbersome on a keystroke programmable.

You're better off thinking of this as structured keystroke programs (call it SKIP?). It would add the control structures that Garth mentioned, named variables, etc. Heck, if done right, it might even lend itself to multiple backends for different calculators.

Dave

[grsbanks]

I'm probably going to get roasted for this, but here goes anyway. Why not just use a subset of RPL?

[Don Williams]

(05-06-2019 05:09 PM)grsbanks Wrote:  I'm probably going to get roasted for this, but here goes anyway. Why not just use a subset of RPL?

Pass me the matches.

[Massimo Gnerucci]

(05-06-2019 05:09 PM)grsbanks Wrote:  I'm probably going to get roasted for this, but here goes anyway. Why not just use a subset of RPL?

[Maximilian Hohmann]

Hello!

(05-06-2019 03:58 PM)David Hayden Wrote:  You're better off thinking of this as structured keystroke programs (call it SKIP?). It would add the control structures that Garth mentioned, named variables, etc. Heck, if done right, it might even lend itself to multiple backends for different calculators.

SKIP sounds good to me. After all, what are programmable calculators used for in the year 2019 (if at all)?

I have programmed a lot in C over the years, but for me it only works if I add as many comments as possible. Otherwise already a month or so after writing the program it will cost me ten times as much time to figure out what it is supposed to to than writing it in the first place. But enter all those comments on a calculator keyboard? Certainly not. So a programming language which mainly explains itself (like BASIC or SKIP) seems much more appropriate to me.

Unless someone can come up with a FORTRAN interpreter/compiler on a pocket calculator. That would really change the foundations of my world :-)

Regards
Max

[John Keith]

(05-06-2019 07:15 PM)Maximilian Hohmann Wrote:  Hello!



But enter all those comments on a calculator keyboard? Certainly not. So a programming language which mainly explains itself (like BASIC or SKIP) seems much more appropriate to me.

Python seems to be the most "self-explanatory" language currently. Casio and HP are both moving in that direction but it would probably not be an easy task to shoehorn Python into a homemade calculator.

I also think Haskell would be a great language for a calculator but I'm sure many folks here would strongly disagree.

[Thomas Okken]

(05-06-2019 05:09 PM)grsbanks Wrote:  I'm probably going to get roasted for this, but here goes anyway. Why not just use a subset of RPL?

Seems like a very legitimate observation to me. If you add structured programming constructs to HP keystroke programming, you're halfway there to RPL. Add the unlimited stack, and an editor that dispenses with line numbers and shows multiple instructions per line, and you're pretty much all the way there.

[KeithB]

How about micropython?
https://www.sparkfun.com/products/14412

[KeithB]

Sounds like you want "B", not C, i.e., BCPL.

[Maximilian Hohmann]

Hello!

(05-06-2019 09:43 PM)KeithB Wrote:  How about micropython?
https://www.sparkfun.com/products/14412

An interesting board (especially for the price you can get it for when you buy it from China). But if you want to use that to implement a programmable calculator that itself is using Python, then you will have to write your own Python interpreter using Python... I wouldn't know where to start to be honest.

Regards
Max

[KeithB]

I am making some assumptions:
A. There is source for micro-Python somewhere
B. That you can use the source to cross compile micro-Python for the calculator project.

[Claudio L.]

I agree with a lot of the opinions given above, and here are my own observations:

* I read above that Keystroke + some structure = RPL, that's true (and there's no shame in that!), and it's not a bad start, translating to keystroke should be quite straightforward.

* C is not the best choice for calculator (typed variables, etc). Other languages work much better as command-line (scripting) languages than C.

* For simplicity (especially if you write your own parser), I'd take a look at BASIC, Lua or micro-python syntax.

* BASIC is easy to code yourself a parser/translator. This would be my first choice to try.

* Lua has a tiny parser that compiles to its own bytecode, and a separate VM that runs the code. You can either run its VM as-is or reimplement the bytecode opcodes in your own keystroke language (since you want a translator, rather than a canned language). I think there's less than 30 different opcodes so it's not too far fetched to implement those opcodes in your own keystroke language. I don't know, however, how the features in your language will play with the features in the parsed language (especially memory management). Both the parser and VM are designed to be easily embedded within applications, so it's quite easy to insert within your own projects (I've personally used it in a couple unfinished/unpublished projects so I can attest to that).

* micropython syntax is more widespread than Lua, but it's a complete environment to run on bare hardware. I'm not so sure how easy it is to extract the parser from there (I'm not too familiar with it other than reading some docs), and I believe it compiles directly to native machine code for various targets (judging from a quick look a the source code). This might make it harder for you to use it as a translator to your own keystroke code.

* A final idea: If you roll your own translator, you might want to also consider using PPL as the higher level language. At least it will make your calcs able to share existing code with the Prime (or at least more easily port).

EDIT: Another "final idea": Take a look at Xerxes calculator benchmark for a nice example of how the same code looks in many, many languages including the ones cited above.

[Dan]

1) Keypad shortcuts will enable variables and commands to be entered quickly to minimise typing

2) From Wikipedia "BCPL is no longer in common use" - that kills it for me

3) BASIC, not bad but done to death on calculators, and not as popular as C for embedded systems development

4) PPL, only used on the Prime

5) Lua and micropython, not familiar with them, seems like more trouble than it's worth

6) I did a bit of systemRPL programming on the 50g back in the day. Nice language, but I'm not convinced it's better than C

7) FORTRAN. No comment

[Massimo Gnerucci]

(05-09-2019 04:05 AM)Dan Wrote:  1) Keypad shortcuts will enable variables and commands to be entered quickly to minimise typing

2) From Wikipedia "BCPL is no longer in common use" - that kills it for me

3) BASIC, not bad but done to death on calculators, and not as popular as C for embedded systems development

4) PPL, only used on the Prime

5) Lua and micropython, not familiar with them, seems like more trouble than it's worth

6) I did a bit of systemRPL programming on the 50g back in the day. Nice language, but I'm not convinced it's better than C

7) FORTRAN. No comment

Nobody pointed out what we do really need: COBOL.
:D

[Maximilian Hohmann]

Hello!

(05-09-2019 04:05 AM)Dan Wrote:  7) FORTRAN. No comment

Why? I really didn't mean that as a joke. FORTRAN means "FORmula TRANslator" and that is exactly what it does. And that is exactly what a programmable calculator is (usually) used for. Programs are easy to read and understand (an important feature for engineers like myself) and all the "exotic" data types are already there. Like double precision complex, which I used a lot many years back.
So much that most of my FORTRAN routines would have "IMPLICIT DOUBLE PRECISION COMPLEX (A-H,O-Z)" as their first line. I would have given an arm and a leg in those days for a FORTRAN capable pocket calculator!

Cheers
Max

[Claudio L.]

(05-06-2019 05:18 AM)Dan Wrote:  ... and am starting to think about implementing a high level language similar to C.

I think your original post was a bit misleading. We all believed you were looking for a language, but you are dead-set on C, you should've stated that clearly and we would've provided you with better info rather than going on and on about different languages.

If C has been already decided, then the Tiny C Compiler from no other than Fabrice Bellard would be the first place I'd look for a parser that fits on an embedded environment.