C translator for calculator project

[Druzyek]

Practically speaking, what will you do when the user makes a mistake in pointer arithmetic and crashes the system? Are you planning on checking the bounds any time a pointer is dereferenced? That will be majorly slow and you might as well go with array indexing in that case which is what BASIC does. These are things you wouldn't have to think about with a language like BASIC or Python.

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

I would say you need to figure out exactly what you want to accomplish. If you want an effective way for users to type in short to medium length programs to solve math problems, C is a bad choice. If you want to do embedded systems development then you can use C, but are you really suggesting that you plan to do embedded development by typing long C programs into a calculator? I briefly tried running a 68k C compiler on my TI-89 but quickly decided it wasn't worth it after a few hard resets.

I also agree that BASIC has been done to death, but the various TI and Casio dialects differ quite a lot and you would have a lot of room to be creative if you fixed the things you don't like about them or added things they are missing.

[KeithB]

Since he has already said he is going to bowdlerize the C (no types) then he will probably remove pointers, too.

In any case, I think we are really talking about a syntax for a calculator scripting language, not a full blown language with all the warts and preconceived notions.

[Dan]

Thank you to everyone for taking the time to share your thoughts, I'm really enjoying reading your posts. KeithB summed it up in the previous post, my aim is to make my programs easier to edit and understand. This would be for small to medium programs, for big projects I would recommend an industrial IDE like Code Composer Studio, which is what I've been using to write the firmware (in C).

For example, here is my keystroke program to generate the Mandelbrot set:

Code:


    CLEAR GLCD
    0
    XCOORD<-
    0
    YCOORD<-
A   DROP 1 LEVEL
    -1
    0.03149606299
    YCOORD->
    *
    +
    CIMAG<-
    ZIMAG<-
B   DROP 1 LEVEL
    -2
    0.03149606299
    XCOORD->
    *
    +
    ZREAL<-
    CREAL<-
    DROP 1 LEVEL
    0
    COUNT<-
C   DROP 1 LEVEL
    ZREAL->
    X^2
    ZREAL2<-
    ZIMAG->
    X^2
    ZIMAG2<-
    +
    4
    GOTOIF> LBL D
    DROP 1 LEVEL
    ZREAL->
    ZIMAG->
    2 
    *
    *
    CIMAG->
    +
    ZIMAG<-
    DROP 1 LEVEL
    ZREAL2->
    ZIMAG2->
    -
    CREAL->
    +
    ZREAL<-
    DROP 1 LEVEL
    COUNT+1
    20
    GOTOIF< LBL C
    DROP 1 LEVEL
    XCOORD->
    YCOORD->
    PIXEL ON
    DROP 1 LEVEL
D   DROP 1 LEVEL
    CIMAG->
    ZIMAG<-
    DROP 1 LEVEL
    XCOORD+1
    128
    GOTOIF< LBL B
    DROP 1 LEVEL
    0
    XCOORD<-
    DROP 1 LEVEL
    YCOORD+1
    64
    GOTOIF< LBL A
    HALT EXECUTION
    DROP 2 LEVELS
    END PROGRAM

Variable names can be up to 8 characters long and are entered via the command line, as are numbers. This makes the programs shorter and easier to understand. Here is the C version - I think it is much more readable:

Code:



#define pixelWidth 0.03149606299

unsigned char iterations = 20;
unsigned char n;
bool inside;

double XCOORD;
double YCOORD;
double CIMAG;
double CREAL;
double ZREAL;
double ZIMAG;
double ZREAL2;
double ZIMAG2;

for(YCOORD = 0; YCOORD < 64; YCOORD++) {
    CIMAG = -1.0 + pixelWidth * YCOORD;

    for(XCOORD = 0; XCOORD < 128; XCOORD++) {
        CREAL = -2.0 + pixelWidth * XCOORD; 
        ZREAL = CREAL;
        ZIMAG = CIMAG; 
        inside = true;
        
        for(n = 0; n < iterations; n++) {
            ZREAL2 = ZREAL * ZREAL;
            ZIMAG2 = ZIMAG * ZIMAG;
            if (ZREAL2 + ZIMAG2 > 4) {
                inside = false;
                break;
            }
            ZIMAG = 2.0 * ZREAL * ZIMAG + CIMAG;
            ZREAL = ZREAL2 - ZIMAG2 + CREAL;  
        }
        if (inside) pixelOn(XCOORD, YCOORD);
    }
}

Another reason I chose C is because this is the language the firmware is written in. From the outset my goal (pipe dream?) was to make a calculator that others would use and contribute software to, and I thought that if people are using C on the calculator then they may be interested in contributing to the development of the firmware (it really is a big job for one person).

However considering how opposed people are to C (whoever thought choosing a calculator programming language could be such a contentious issue!), perhaps I should reconsider. Anyway, I have only used 138K of Flash (out of 1000K) and 15K of RAM (out of 256K), so there is always room for more than language (actually two, I'll keep the keystroke language).

BTW, the keystroke programming language is working well, 13 seconds to generate the Mandelbrot set on a 128x64 display with 20 iterations per pixel using doubles, and 7 seconds using floats and the floating-point coprocessor. At some stage I'll try the N queens program to see how well it performs compared to other calcs. Some pics I took while entering the above program:

[EdS2]

Looks great! If one or two people speak out against an idea, that might be interesting but never take it as representative. There is no group mind, there is no consensus. Take heed of any constructive criticism, and feel free to ignore anything else. Keep your enthusiasm!

[Claudio L.]

(05-10-2019 08:47 AM)Dan Wrote:  However considering how opposed people are to C (whoever thought choosing a calculator programming language could be such a contentious issue!), perhaps I should reconsider.

I think "opposed" may not be the best word. I use C for almost everything, all the time, but thinking of a calculator it's probably better to have a language that looks closer to pseudocode and easy to pick up and understand for most people. Looking at Xerxes N-Queens various implementations, for example, a quick-scrolling look and to my eyes I see that Pascal, Lua, Micropython, TI-89, HP38 and HP Prime languages all look almost identical, and very easy to understand (I've never used a TI-89 for example but I can read it just fine). The C version comes close behind, readable to me but requires me to fix my sight to it and pay attention to each symbol (there's many more symbols and less words).

(05-10-2019 08:47 AM)Dan Wrote:  Another reason I chose C is because this is the language the firmware is written in. From the outset my goal (pipe dream?) was to make a calculator that others would use and contribute software to, and I thought that if people are using C on the calculator then they may be interested in contributing to the development of the firmware (it really is a big job for one person).

I know what you mean, it is a big job for one person but take your time and don't get discouraged.
Another aspect to consider is that you might get more contributions if you use an easier language. As a matter of fact, most professional applications work this way: They are coded in one language, then add an easy scripting or extension language for other people to contribute (Gimp (uses it's own script-fu), Wireshark (Lua), Blender (python), AutoCAD (Lisp, and later VisualBasic), etc.).
All you need to do is incorporate them in some pre-compiled form into your ROM and expose them the same as native commands.

[Dan]

(05-09-2019 10:54 AM)Maximilian Hohmann Wrote:  FORTRAN means "FORmula TRANslator" and that is exactly what it does. I would have given an arm and a leg in those days for a FORTRAN capable pocket calculator!

Please excuse my ignorance, I knew FORTRAN was widely used decades ago but had no idea it remains an important programming language.

From Wikipedia:

"It is the primary language for some of the most intensive super-computing tasks, such as in astronomy, climate modeling, computational chemistry...and weather prediction. It is a popular language for high-performance computing and is used for programs that benchmark and rank the world's fastest supercomputers".

Pretty cool, will check it out further. Do you know if there are any simulators available?

[Dan]

(05-10-2019 10:20 AM)EdS2 Wrote:  Looks great! If one or two people speak out against an idea, that might be interesting but never take it as representative. There is no group mind, there is no consensus. Take heed of any constructive criticism, and feel free to ignore anything else. Keep your enthusiasm!

Wise words, thanks for the encouragement and for putting things in perspective!

[Dan]

(05-09-2019 01:55 PM)Druzyek Wrote:  I would say you need to figure out exactly what you want to accomplish. If you want to do embedded systems development then you can use C, but are you really suggesting that you plan to do embedded development by typing long C programs into a calculator?

I teach maths and physics and my goal is to build a calculator/embedded systems development device that students can use to enter, run and debug programs and interface components to. A little like an Arduino but without having to connect to a computer.

[ijabbott]

(05-11-2019 11:20 AM)Dan Wrote:  Please excuse my ignorance, I knew FORTRAN was widely used decades ago but had no idea it remains an important programming language.

From Wikipedia:

"It is the primary language for some of the most intensive super-computing tasks, such as in astronomy, climate modeling, computational chemistry...and weather prediction. It is a popular language for high-performance computing and is used for programs that benchmark and rank the world's fastest supercomputers".

Pretty cool, will check it out further. Do you know if there are any simulators available?

I haven't used Fortran within the last decade or so, but I should think the easiest way to use it would be the gfortran compiler (GNU Fortran compiler), perhaps with an IDE such as Photran (based on Eclipse), the "Modern Fortran" extension for VS Code, or "CBFortran" - the "FortranProject" plug-in for Code::Blocks.

[Maximilian Hohmann]

Hello!

(05-12-2019 10:49 AM)Dan Wrote:  That makes a lot of sense, perhaps the following to start with:

1) Assignment operator e.g. count := count + 1, arithmetic, relational and logical operators
2) if-then, if-then-else and case
3) while do and for loops with exit
4) procedure, which can return values

Operators can then be added as the program develops.

Did I already mention FORTRAN ;-)

And answering a posting higher above: Fortran is long from dead or obsolete, even if Wikipedia thinks differently. I studied aerospace engineering in the 1980ies. In our field, everyting was written in Fortran then and a Fortran course was a mandatory part of our training combined with a course on numeric methods for solving differential equations.

As long as my generation of engineers is still busy (retirement is 10 years away) designing airliners, spacecraft, road vehicles, race cars, optimise trajectories of space probes, analyse the dynamic properties of large lighweight structures - on earth and in space, model the multiphase flow within steam turbines of powerplants, model the flow of air around buildings and bridges, etc. Fortran will remain a part of this world.

There is no need for an object oriented approach or pointer arithmetic or a smart user interface if one needs to compute the trajectory of an asteroid for the next 25 years. But this kind of task requires precision (as much of it as one can get - the Cray fortran compilers had an "AUTODBL" flag which would double the precision of the calculation once more, even if it had been written in double precisionin the first place) and a simple and efficient way of coding - and understanding other people's code - that can be done by the engineer/scientist himself. Without requiring an extra degree in IT.

No wonder many large program packages for computer aided design, computational fluid dynamics (CFD), computational structure analysis, global climate modeling, ocean modeling (both of which are special cases of CFD), orbital dynamics, computational quantum chemistry, or astronomy/astrometry (example: https://aa.usno.navy.mil/software/novas/..._intro.php) are still written in Fortran or at least around Fortran cores.

And as an example here is one of many very recent papers on the subject (this one from NASA): https://ntrs.nasa.gov/archive/nasa/casi....000413.pdf

Happy programming!
Max

[Dan]

(05-13-2019 11:18 AM)Maximilian Hohmann Wrote:  And answering a posting higher above: Fortran is long from dead or obsolete, even if Wikipedia thinks differently.

Oh but it doesn't think that, as a matter of fact it praises the language. I quoted the following in my post above:

"It is the primary language for some of the most intensive super-computing tasks, such as in astronomy, climate modeling, computational chemistry...and weather prediction. It is a popular language for high-performance computing and is used for programs that benchmark and rank the world's fastest supercomputers".

(05-13-2019 11:18 AM)Maximilian Hohmann Wrote:  I studied aerospace engineering in the 1980ies. In our field, everyting was written in Fortran...
here is one of many very recent papers on the subject (this one from NASA): https://ntrs.nasa.gov/archive/nasa/casi....000413.pdf

That was a very interesting read, thanks for sharing Max. You certainly make it sound tempting!

Today I modified my 8 row, 6 column keypad layout to include shortcuts for operands for the "pseudocode" translator, but I haven't started writing the translator so I can change this. Today I also finished a basic implementation of Dijkstra's shunting yard algorithm (which I will use in the translator, and which now enables algebraic entry on the calculator) so everything is ready to go.

The translator would translate the Fortran code to my keystroke programming language, not machine language, so no Cray and you would have to be content with only double precision but I'm pretty happy with it's performance.

However I know nothing about Fortran, I would need help to get started!

EDIT: page 19 of NASA's paper shows a "refactoring" of legacy code into modern Fortran. I would need some resources on the Fortran 2018 (the latest standard) language.

[Maximilian Hohmann]

Hello!

(05-14-2019 06:28 AM)Dan Wrote:  The translator would translate the Fortran code to my keystroke programming language, not machine language, so no Cray and you would have to be content with only double precision but I'm pretty happy with it's performance.

EDIT: page 19 of NASA's paper shows a "refactoring" of legacy code into modern Fortran. I would need some resources on the Fortran 2018 (the latest standard) language.

The translator approach seems very reasonable! And I doubt that anybody would use a handheld calculator to compute whether or not a certain asteroid will hit the Earth in 2156 or not. So all the extra precision is certainly not requrired.

The current standard (Fortran 2018) is defined in this lengthy document from ISO: isotc.iso.org/livelink/livelink?func=ll&objId=19442438&objAction=Open

Cheers
Max

[Druzyek]

Quote:And I doubt that anybody would use a handheld calculator to compute whether or not a certain asteroid will hit the Earth in 2156 or not. So all the extra precision is certainly not requrired.

You're probably right but on a homebrew project you can do whatever you like I went with 32 decimal places on my homebrew calculator because I had a massive amount of left over memory and . . . why not?

[rprosperi]

(05-15-2019 07:51 AM)Dan Wrote:  This book looks good, concepts are taught through plenty of example programs, which is my preferred way of learning.

These look even better. Not quite as new, but 1/8 the price.

[Dan]

(05-14-2019 01:37 PM)Druzyek Wrote:  

Quote:And I doubt that anybody would use a handheld calculator to compute whether or not a certain asteroid will hit the Earth in 2156 or not. So all the extra precision is certainly not requrired.

You're probably right but on a homebrew project you can do whatever you like I went with 32 decimal places on my homebrew calculator because I had a massive amount of left over memory and . . . why not?

There is Intel's Decimal Floating-Point library, which has support for 128-bit transcendental functions and which Thomas Okken used for Free42 (as well as Swiss Micro's DM42).

I wanted to incorporate it into my project but couldn't figure out how to do it. If anyone is able to help, please let me know. The calculator would then have support for floats, doubles and quadruples.

[Thomas Okken]

Building the Intel library can be a bit of a challenge if the included scripts (RUNLINUX, RUNWINDOWS, etc.) don't work for you. It doesn't use automake or anything like that, and there's no explicit ARM support. I was able to get it to work (*) on iOS and Android, so I may be able to help. I'd recommend taking a look at free42/android/jni/intel-lib-android-armv7.patch in the Free42 source code package to get an idea of what may need to be done; send me a PM or email if you have any specific questions.

(*) My iOS and Android builds do fail on some of the regression tests, but the problematic functions are all conversions that Free42 doesn't need, so I didn't have to fix those issues. The patches for Linux, Mac, and Windows are all very straightforward and consist mostly of changes to allow the regression test suite to run within Free42, rather than stand-alone.

[Dan]

Thanks Thomas for kindly offering to assist and for the information, you've inspired me to try again. I'll check out the Free42 source code and let you know how I go.

[Dan]

(05-18-2019 10:30 AM)Dan Wrote:  Thanks Thomas for kindly offering to assist and for the information, you've inspired me to try again. I'll check out the Free42 source code and let you know how I go.

I gave up. Instead I've started writing my own IEEE quadruple routines. A big job, but one of the reasons I wanted to write my own calculator firmware was to learn about computer arithmetic, so I'm getting what I wished for!

I've finished multiplication, which is one of the easier routines. The most time consuming part was learning the ARM assembly instructions.

[ijabbott]

(06-06-2019 06:24 AM)Dan Wrote:  

(05-18-2019 10:30 AM)Dan Wrote:  Thanks Thomas for kindly offering to assist and for the information, you've inspired me to try again. I'll check out the Free42 source code and let you know how I go.

I gave up. Instead I've started writing my own IEEE quadruple routines. A big job, but one of the reasons I wanted to write my own calculator firmware was to learn about computer arithmetic, so I'm getting what I wished for!

I've finished multiplication, which is one of the easier routines. The most time consuming part was learning the ARM assembly instructions.

The weird thing about the Intel Decimal library is the huge tables repeated verbatim in various source files. Maybe that makes the code slightly faster, but it uses up a lot of precious space on a small, embedded system like a calculator.

It may be worth checking out the IBM's Decimal Floating Point C Library (libdfp), some of which is used by the WP-34S and WP-43S projects.

[Michael Zinn]

My vote is on Lisp with some fancy AST editing buttons to move the cursor not only to the next or previous element, but also up or down the tree. Lisp64 on the Commodore64 comes with an editor that would work very well if it had dedicated buttons. Instead of compiling I'd go with interpreting and maybe even live editing, REPL style.

Having said that, my compiler for the HP15C currently only compiles CommodoreBASIC because it's the simplest to implement that also provides some sort of value: https://pastebin.com/svGJk9Mh