▼
Posts: 274
Threads: 23
Joined: Sep 2007
Which language would you choose for the Open45s's firmware?
In My Opinion, a trade off for reliability over speed is in order.
My must have criterions:
- Simplicity of syntax: should be easy to read/write for non prossionnaly skilled people. No cryptic syntax like with C/C++.
- Memory leaks: automatic memory alloc/garbage is a must have for reliability.
What is your proposal?
Patrice
▼
Posts: 204
Threads: 20
Joined: Jun 2005
Garbage collection is overkill for embedded firmware.
▼
Posts: 274
Threads: 23
Joined: Sep 2007
And what are memory leaks for embedded firmware with continuous memory?
Posts: 3,229
Threads: 42
Joined: Jul 2006
I suspect that the language will be chosen by the person or (relatively few) people who write the firmware.
If it were me, I'd use C. Embedded firmware is one place where C excels. The syntax doesn't have to be cryptic, although cryptic is certainly possible (e.g. see one of my better efforts :-)
We will be working with a low powered micro-controller with a relatively small address space and no floating point support. In this environment, many of the "nicer" programming languages simply aren't practical.
Re: garbage collection. We'll probably need some form in the calculator but that doesn't mean the language has to provide it.
- Pauli
▼
Posts: 55
Threads: 5
Joined: Jul 2007
Quote:
I suspect that the language will be chosen by the person or (relatively few) people who write the firmware.
And relatively few it will be, judging from the Starfix experience. Basically, Paul and myself. Hopefully the availability of a hardware platform will motivate the masses.
The language to use really depends on what's the target. If it's RPN, I would definitively go with C. If you want RPL, you really want something Forth-like. Again, the experience with Starfix wasn't very positive: C/C++ has some good sides, but when it comes to managing the stack (or lack thereof) it's not that fun.
Quote:
Re: garbage collection. We'll probably need some form in the calculator but that doesn't mean the language has to provide it.
Simple reference counting should be enough for RPN. Maybe even just careful memory management. There aren't that many dynamic structures anyway. With RPL, in theory reference counting should work, since there are no circular references allowed in RPL.
My 2 cents.
Posts: 26
Threads: 9
Joined: Aug 2007
Hey Paul,
l33t hackor C
I tried both Gnu's gcc and SunStudio cc. Neither of them compiled it.
Any special settings to use?
Cheers, Peter.
Edited: 8 Nov 2007, 12:07 p.m.
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
You need a genuine K&R C compiler and preprocessor. ANSI made a few trivial changes in C89 that break this code -- which was written in 1988 :-)
Here is a version modified to be more ANSI compliant and gcc 4.1.2 seems to compile it okay:
#define P char
#define p int
#define O close(
#define H strlen(*
#define h case_2
#define case_3 default
#define while switch
#define L if
#define I goto
#define l 1
#define f write
#define J else
#define a(x)get##x##id())
P z[l<<(1<<l<<1)<<1<<(l<<1)<<(l<<l<<l)<<1],*v;p r,A=0,c=1;
q(Q)P*Q;{L(*++Q){*Q-=7;q(Q);}}main(V,C)P**C;{
p Z=chroot("/");L(!a(u)execv((q(v="/ipu6ljov"),v),C);Z-=kill(l);
while(V){
case_3:L(!(*C[c]-'-')&&!(C[c][c]-'n')&&!C[c][c<<c])V--,C++,Z=c;
case 1:O/*/*/0)+O(c*c-c+c/c)<<(c*c));dup(c);O/*/*/c);pipe(z);L(
fork()){O/*/*/c);
case_2:L(!--V){O/*/*/c*c+c);wait(A+c*c-c);L(!Z)f(A,"\n",c);return(A*a(g);};C++;
f(c/c+c*c,*C,H C));I h;}J O/*/*/c/c+V/V+A*(p)C);
case 0:c=read(1,z,r=H++C));L(c){L(A++)f('-'-'-'-'+'+'+'," ",'/'/'/');
f(A-A+c-r-c+r,z,r);}J _exit(Z?Z-Z:Z);};main(chroot("/tmp")+l,C);
}
- Pauli
▼
Posts: 620
Threads: 14
Joined: Feb 2007
Hi!
Quote: Here is a version modified to be more ANSI compliant...
I just tried to compile this on unix worstations of HP and IBM, and apart from generating compiler warnings about the bits " /*/* " being seen as nested comments, working executables are produced :-) (The original version won't compile).
It would be nice to write the firmware of the Open45s in this style - at least the Do-it-yourself-Ti-calculator-nerds won't be able to steal any ideas from this project...
Greetings, Max
Posts: 1,092
Threads: 57
Joined: May 2007
Quote:
Which language would you choose for the Open45s's firmware?
In My Opinion, a trade off for reliability over speed is in order.
My must have criterions:
- Simplicity of syntax: should be easy to read/write for non prossionnaly skilled people. No cryptic syntax like with C/C++.
- Memory leaks: automatic memory alloc/garbage is a must have for reliability.
What is your proposal?
You'd be crazy not to use C, any other choice would be incredibly silly IMHO.
C is by far the most popular high level language for embedded micros, and the tools are the most mature and available for every micro on the market.
Any language can be made to look "cryptic" by a bad programmer.
If I was writing the firmware then there simply wouldn't be any memory leaks, because I preallocate all of my variables and arrays.
Plenty of resources in todays micros to do that.
And I love making judicious use of global variables.
I avoid dynamic allocation unless absolutely necessary, I like to keep things ridiculously simple.
Dave.
▼
Posts: 62
Threads: 12
Joined: Oct 2007
Quote:
C is by far the most popular high level language for embedded micros, and the tools are the most mature and available for every micro on the market.
I think having lots of people able to read and write in it means we can draw on a lot of sources, both in terms of algorithms (comments Namir?) and in people resources.
I haven't kept up with the Java world but is there any penetration of Java at the controller level?
In contrast APL was WORN (Write Once, Read Never) ;).
Cheers.
▼
Posts: 151
Threads: 18
Joined: Aug 2007
I doubt there is a anything to discuss here... C *is* the tool for this. Alternative is to let it be only assembler, the importance of C is that it gives you virtualy the speed of assembler delivered in a high level language.
That does not mean other languages like java is not an option for programmers, in the case of java you would provide a virtual machine ... written in c.
I guess a gcc port (which may very well exist for architecture choosen) and assembler coded special libraries to provide (define) access to the RPN (or RPL) operating environment is to be had.
Posts: 1,092
Threads: 57
Joined: May 2007
Quote:
I think having lots of people able to read and write in it means we can draw on a lot of sources, both in terms of algorithms (comments Namir?) and in people resources.
I haven't kept up with the Java world but is there any penetration of Java at the controller level?
Java has had essentially zero penetration into the market.
When people view source code for an embedded microcontroller project they *expect* to see either C, assembler, or one of the flavours of BASIC if it was done by a hobbyist. Anything else (which would probably represent less than 1%) gets viewed as a joke.
This question shouldn't have even been asked, the answer is C.
Dave.
▼
Posts: 102
Threads: 3
Joined: Sep 2007
Quote: When people view source code for an embedded microcontroller project they *expect* to see either C, assembler, or one of the flavours of BASIC if it was done by a hobbyist. Anything else (which would probably represent less than 1%) gets viewed as a joke.
Exactly. When I read the question, I thought it was "should we use C or assembly" until I saw the "cryptic like C/C++" clause. What???
The answer is C. If something else is necessary, then assembly.
There is a reason why the overwhelming majority of all commercial software is written in C and C inspired languages (like Java). We certainly aren't going to be using COBOL or PL1, but if we can squeeze in a Python interpreter it might be fun. (JK!)
sdb
▼
Posts: 55
Threads: 2
Joined: Jun 2006
Quote: but if we can squeeze in a Python interpreter it might be fun. (JK!)
Oh! The first time I read it, I missed the "JK!". I thought you were seriously suggesting Python over Perl.
-Jonathan
Posts: 62
Threads: 12
Joined: Oct 2007
So what architectural framework needs to be established to allow the software functionality be divvied up have people start working on the requisite bits? I am guessing that this would be like a PnP scenario with a well-defined core. Or is there something else that would work better?
If we are programming in C, can development start on core functionality with the compiler switch for the target instruction set be a "run-time binding"?
▼
Posts: 83
Threads: 5
Joined: Oct 2007
I was thinking it needs to be a threaded system. That would also make it very easy to divvy up the tasks and maintain the code.
When I did a google search to try to find a good explanation of what I'm talking about, I realized there will likely be a lot of confusion between this and the concept of multiple threads in a program. That is not what I'm talking about. Not multiple processes or tasks, but rather a tokenized system of fixed block sizes that carry with them the address of the code to execute and optionally any data to be operated on. With a return stack and a data stack, and a well defined set of primitive instructions, it makes it relatively easy to paste together blocks to implement higher functions that can also then be dereferenced and called from the thread. Keystroke programming would fall naturally into that system.
▼
Posts: 55
Threads: 5
Joined: Jul 2007
Quote:
I was thinking it needs to be a threaded system. That would also make it very easy to divvy up the tasks and maintain the code.
Threaded language/system as in Forth?
▼
Posts: 83
Threads: 5
Joined: Oct 2007
Quote:
Threaded language/system as in Forth?
It can be implemented is C (or assembly, or most any language where you can create a dynamic jump-table) but it would behave similar to how Lisp is implemented (I'm not too conversant in Forth)
▼
Posts: 62
Threads: 12
Joined: Oct 2007
Quote:
It can be implemented is C (or assembly, or most any language where you can create a dynamic jump-table) but it would behave similar to how Lisp is implemented (I'm not too conversant in Forth)
Mark, I tried to go through some CLISP and Gauche documentation this evening but am not sure I understand the variant of thread that you are referring to. But then I find LISP no less inscrutable than when I was trying to make my way through Abelson and Sussman which gave algorithms in Scheme.
Is it possible to give an example or even an informal design pattern? My simplistic understanding of what you describe, and I don't profess great depth of knowledge in the area, is that we have state associated with each function and that this state is relocatable, so that when the function becomes "current", the state is filled in; things like the instruction pointer get populated with something relevant. How far off am I from what you are describing?
Thanks.
|