Mince Interpreter for the Propeller -- Forth wins
David Betz
Posts: 14,516
I have just finished my first attempt ant providing an interactive infix language for the Propeller that has decent performance. I took a simple Basic interpreter that I wrote a while back and added a PASM VM to improve its runtime performance. I then added an interactive mode so it itsn't necessary to type "run" every time you want to test some code. My intent had been to replace the Basic-like syntax with C-like syntax mainly because it is more terse and easier to type interactively. I got all of this running on the Macintosh using Xcode and on the Propeller using PropGCC. Unfortunately, the resulting system is too large to fit in hub memory even compiled with the CMM memory model. It does fit comfortably on a board like the C3 that has a SPI flash chip and can use the XMMC memory model but not many people are willing to supply the extra chip to use the XMM modes.
The code is in GitHub if anyone is interested. I didn't do the conversion to C-like syntax yet because I figured that the requirement for external memory would probably mean there would be little interest in this. Also, the name "Mince" stands for "Mince Is Not C Exactly". It's one of those recursive acronyms that were popular a while back (like Gnu is Not Unix for GNU).
https://github.com/dbetz/mince
So, for now anyway Forth wins. It is the only interactive environment for the Propeller that can run without any external memory. Actually, there are others like FemtoBasic and the embedded Basic that Bean created but Mince is quite a bit faster than those and probably nearly as fast as Spin.
Here is a sample run. Toward the end you can see the interactive mode.
The code is in GitHub if anyone is interested. I didn't do the conversion to C-like syntax yet because I figured that the requirement for external memory would probably mean there would be little interest in this. Also, the name "Mince" stands for "Mince Is Not C Exactly". It's one of those recursive acronyms that were popular a while back (like Gnu is Not Unix for GNU).
https://github.com/dbetz/mince
So, for now anyway Forth wins. It is the only interactive environment for the Propeller that can run without any external memory. Actually, there are others like FemtoBasic and the embedded Basic that Bean created but Mince is quite a bit faster than those and probably nearly as fast as Spin.
Here is a sample run. Toward the end you can see the interactive mode.
ebasic 0.003 load test.bas Loading 'test.bas' OK list 10 def fact(n) 20 if n < 2 then 30 return n 40 else 50 return fact(n-1) * n 60 end if 70 end def 80 a = 2 90 b = 10 100 for x=a to b 110 print x, fact(x) 120 next x OK run 2 2 3 6 4 24 5 120 6 720 7 5040 8 40320 9 362880 10 3628800 OK print a 2 print fact(10) 3628800
Comments
Did you benchmark the runtime against Forth, C version in various LMM modes, and ebasic?
It might be nice to see the performance deltas for the various languages.
Sorry, I guess I was not clear... I was curious about the run times for benchmarks; it would be nice to start building a database for P1 / P2 languages.
I assume you're kidding about building a database of P1 / P2 languages. There's already that huge list of languages that mostly contains languages that run under CP/M. :-)
All languages will run way faster on the P2 than P1, it might help P2 sales.
Since the code runs in a VM, run-time performance would be the same as if Mince were running in HUB RAM. Compiling will be a little slower of course. There should also be lots of room left in the EEPROM for storing a user program.
Don't give up David. You have a viable solution started. All you need to do is finish with reasonable features.
The more languages for the prop, the likelier it is that every user will find something that fits them best!
If the Prop won't boot on a 24LC1024, there is another one that behaves like two 24LC512's in one package... I think 25LC1024?
Nice example.
Is it easy to add a time-stamp to each result line ?
? To me, time taken is always informative
Especially when I see the words "Interpreter", as then any code-speed becomes a much larger unknown.
I know it's an interesting endeavour but it really confuses the world.
@David Betz, Are you the same David Betz that created XLisp?
If so you have a lot to answer for:)
If not, I make my apologies.
I am no programming language designer, and I admire your efforts.
It just seemed to me for a long time that if you want a really small interpreted, interactive "high level" language then you have to engineer its syntax to be as simple as possible. Complex parsing costs code space. Never mind the semantics. As far as I can tell Forth like, backwards, syntaxes are the simplest and hence can be made in the least code space.
As I said above I admire your effort to prove this thesis wrong. I really hope that is true today. Having had to learn a new language for pretty much every project I have taken part in during my career I do wonder: ALGOL, BASIC, Coral, PL/M, C, C++, Python, JavaScript, PHP, Spin ...
It has not stopped. The young kids today have Ruby, Go, Dart....
Please make it stop! Sorry, I was a bit hard there.
I just happened to put 2 and 2 together the other day and start googling for David Betz the xlisp guy.
As far as I can tell from finding various forum posts and such xlisp attracted a lot of enthusiastic followers. They need you.
Having seen this, I really think a discussion about Forth and a postfix alternative would be of value, but start lower. Like what infix (do I have that right?) syntax can fit into a COG kernel and build out from there. We may be surprised at the result of that conversation. Something I have been thinking hard about since you started the discussion.
No, I am not suggesting you disappear from here. Please don't.
I don't mean to be hostile. Actually I'm fascinated by programming language design.
On the one hand it's an exercise in engineering, what can we actually do to make programming easier for "normal" humans who don't want to talk to their machines in binary op codes. A compiler/interpreter has to be buildable, it has to fit the machines resources, it has to be fast enough.
On the other hand it is seems to be very cultural. For example infix is good postfix is bad. Languages like VB gain traction, but Lisp and Scheme do not.
I have to have snooze and think about your other points.
Noun/object verb noun/object
than postfix languages:
Noun/object noun/object verb verb
??
It's also how little kids learn math - please don't confuse them.
def fibo(n) if n < 2 then return n else return fibo(n - 1) + fibo(n - 2) end if end def for n = 0 to 26 print "fibo("; n; ") = "; startTime = cnt result = fibo(n) endTime = cnt rawTime = endTime - startTime executionTime = rawTime / (clkfreq / 1000) print result; " ("; executionTime; "ms) ("; rawTime; " ticks)" next nI don't go in for benchmarks as I look at performance as a whole and there are a lot of things that benchmarks don't reveal or hide. Anyhows, I wrote a quick fibo and tried it out and it turns out it takes a whopping 192ms / loop. But when I compare that to an ARM Forth that had far more assembler code for the kernel and of course fast access to main memory, as well as a faster clock speed (15ns cycle time vs 50ns) the ARM Forth was still only just over 3 times faster.
Thought you might like the figure as a comparison.
EDIT: !!! Whoops, wrong benchmark, that was a sieve of eratosthenes.
I remember playing around with this a couple of decades ago ;-)