As far as I recall the VxWorks OS things were relatively simple. Your compiled C application gets loaded to the target along with a symbol table. The command line shell can then take your command and find that function in memory. Any parameters get taken from the command line and pushed on the stack. The call is then made.
As Eric says, things will be a bit tricky on the Prop. One "engine" runs Forth, say, and another runs the LMM kernel for C. All that command and parameter passing will have to go through a mail box in memory.
C++ makes things even harder. Calling methods on objects is going to need not only the name of the method but a pointer to the object the method is being called on. How does one know where that is in memory?
Then there is the issue of name mangling. The C++ compiler renames everything for it's own purposes, so a simple method name might end up looking like "_ZN9wikipedia7article8print_toERSo".
you could just have a space in HUB for
a 32-bit 'Function Pointer'
and some space - for parameters (could be accesseed in bytes, words, 32-bit longs might be simplest - depends on the C++ side ...)
Tachyon populates the parameters from it's stack,
then writes the FunctionPointer (
the C++ COG sees FunctionPointer <>0 and does it's job, puts the results in the same area and when done clears FunctionPointer to 0.
Tachyon recognizes this and since the memory position is known,
you can inspect those values directly without any copying if you like.
Or do what you want with them.
You can inspect the whole RAM / SD memory anyhow ;-)
In the end we should implement a message based system. Functions are loaded to processors and those communicate via a messaging system, like signals and slots in Qt. Or like channels in Occam. or, or, or. And we should forget about the limited resources. If one propeller is not enough, a second will jump in and so forth. And that is the moment, were forth enters the play. Everything is very natural.
And that is the moment, were forth enters the play.
this is not correct ...
while others still discuss ifs and hows
Tachyon is there in the play for quite some time now,
getting stronger almost every day.
And the network of Propellers might be a nice idea,
but in reality one is enough for most of the problems around,
if we just use resources reasonably -
e.g. integer/scaled int vs. floating point etc.
and yes I heard about Peter's 40+ Props/installation exception ;-)
"so forth. And that is the moment, " I didn't refer to Tachyon, just realized, in the sentence I wrote, forth came into usage. And: when I will have finished my home automation project, there will be at least 100 Propellers doing their work. I now for example control a window shutter where one prop sits into the switch panel and one controls relays. In the end all propellers in the world (what conincides with the universe) will be connected! One precontition: I will receive some IoT5500.
"so forth. And that is the moment, " I didn't refer to Tachyon, just realized, in the sentence I wrote, forth came into usage. And: when I will have finished my home automation project, there will be at least 100 Propellers doing their work. I now for example control a window shutter where one prop sits into the switch panel and one controls relays. In the end all propellers in the world (what conincides with the universe) will be connected! One precontition: I will receive some IoT5500.
"so forth. And that is the moment, " I didn't refer to Tachyon, just realized, in the sentence I wrote, forth came into usage. And: when I will have finished my home automation project, there will be at least 100 Propellers doing their work. I now for example control a window shutter where one prop sits into the switch panel and one controls relays. In the end all propellers in the world (what conincides with the universe) will be connected! One precontition: I will receive some IoT5500.
you could negotiate a special deal with Ken then ;-)
edit: faster writing than thinking - with Peter of course :-)
If speed is less important than ease of calling from C/C++, you might try a custom interpreter rather than Tachyon.
I've written a very simple interpreter called tinyscript that takes up about 3K and a similar amount of RAM, and is pretty easy to interface with C.
You won't be able to call all the C functions in your program (that's probably not feasible on the Propeller!) but you can
easily select a few to export. There isn't a REPL provided by the interpreter, but it's very easy to provide one in the
app if you want. A complete app with a REPL using C stdio (so not nearly as compact as it could be) is 10K in CMM mode.
tinyscript is a pretty simple language. Here's a program to blink that I just typed in to my propeller (the greater
than sign is just the prompt from my dumb REPL):
> proc pause { waitcnt(getcnt()+40000000) }
> proc blink { pinout(pin,1); pause; pinout(pin,0); pause }
> var pin=20
> blink
> var i=10; while (i>0) { blink; i=i-1 }
You can even write fibonacci in it:
# calculate fibo(n)
# parameter in n, returns result in r
var n=0
var r=0
proc fibo {
if (n<2) {
r=n
} else {
var saven=n # save our parameter for recursive call
var a=0
n=n-1; fibo; a=r
n=saven-2; fibo; r=a+r
n=saven
}
}
var i=1
while i<=12 {
n=i; fibo
print "fibo(",i,") = ",r
i=i+1
}
Now the caveats: I just wrote this interpreter over the weekend, so it's probably pretty buggy. Error handling is up to
the application: the interpreter just returns an error number when something goes wrong. If something goes badly
wrong it calls abort(). The provided REPL uses fgets() to read the line; there's no real way to save scripts or edit
them. That's not really a flaw in the interpreter per se, though, it's up to the application to do that.
If speed is less important than ease of calling from C/C++, you might try a custom interpreter rather than Tachyon.
I've written a very simple interpreter called tinyscript that takes up about 3K and a similar amount of RAM, and is pretty easy to interface with C.
You won't be able to call all the C functions in your program (that's probably not feasible on the Propeller!) but you can
easily select a few to export. There isn't a REPL provided by the interpreter, but it's very easy to provide one in the
app if you want. A complete app with a REPL using C stdio (so not nearly as compact as it could be) is 10K in CMM mode.
tinyscript is a pretty simple language. Here's a program to blink that I just typed in to my propeller (the greater
than sign is just the prompt from my dumb REPL):
> proc pause { waitcnt(getcnt()+40000000) }
> proc blink { pinout(pin,1); pause; pinout(pin,0); pause }
> var pin=20
> blink
> var i=10; while (i>0) { blink; i=i-1 }
You can even write fibonacci in it:
# calculate fibo(n)
# parameter in n, returns result in r
var n=0
var r=0
proc fibo {
if (n<2) {
r=n
} else {
var saven=n # save our parameter for recursive call
var a=0
n=n-1; fibo; a=r
n=saven-2; fibo; r=a+r
n=saven
}
}
var i=1
while i<=12 {
n=i; fibo
print "fibo(",i,") = ",r
i=i+1
}
Now the caveats: I just wrote this interpreter over the weekend, so it's probably pretty buggy. Error handling is up to
the application: the interpreter just returns an error number when something goes wrong. If something goes badly
wrong it calls abort(). The provided REPL uses fgets() to read the line; there's no real way to save scripts or edit
them. That's not really a flaw in the interpreter per se, though, it's up to the application to do that.
Eric, you rock.
I'm sorry Peter, I think my trial of Tachyon just got pushed off for another couple years.
Of course, the first thing I'll have to do with tinyscript is fork it and convert the serial routines to PropWare. But this looks really fun! It might make it into the v3.0 release of PropWare.
If speed is less important than ease of calling from C/C++, you might try a custom interpreter rather than Tachyon.
I've written a very simple interpreter called tinyscript that takes up about 3K and a similar amount of RAM, and is pretty easy to interface with C.
You won't be able to call all the C functions in your program (that's probably not feasible on the Propeller!) but you can
easily select a few to export. There isn't a REPL provided by the interpreter, but it's very easy to provide one in the
app if you want. A complete app with a REPL using C stdio (so not nearly as compact as it could be) is 10K in CMM mode.
tinyscript is a pretty simple language. Here's a program to blink that I just typed in to my propeller (the greater
than sign is just the prompt from my dumb REPL):
> proc pause { waitcnt(getcnt()+40000000) }
> proc blink { pinout(pin,1); pause; pinout(pin,0); pause }
> var pin=20
> blink
> var i=10; while (i>0) { blink; i=i-1 }
You can even write fibonacci in it:
# calculate fibo(n)
# parameter in n, returns result in r
var n=0
var r=0
proc fibo {
if (n<2) {
r=n
} else {
var saven=n # save our parameter for recursive call
var a=0
n=n-1; fibo; a=r
n=saven-2; fibo; r=a+r
n=saven
}
}
var i=1
while i<=12 {
n=i; fibo
print "fibo(",i,") = ",r
i=i+1
}
Now the caveats: I just wrote this interpreter over the weekend, so it's probably pretty buggy. Error handling is up to
the application: the interpreter just returns an error number when something goes wrong. If something goes badly
wrong it calls abort(). The provided REPL uses fgets() to read the line; there's no real way to save scripts or edit
them. That's not really a flaw in the interpreter per se, though, it's up to the application to do that.
Hi Eric. This is really cool. I particularly like your ParseExprLevel function. It always bothered me that all of my bytecode compilers and a zillion functions named things like parse_expr1, parse_expr2, etc. that were all identical except for the operators they handle. I think I'm going to steal your idea if you don't mind! :-)
I'm sorry Peter, I think my trial of Tachyon just got pushed off for another couple years.
You are missing out on a lot of great features,
but I understand that you live in an other world ;-)
and it is probably best to stay in one of it instead of trying to merge
so different cultures.
On the other hand intercultural marriages can be for mutual benefit.
So things you miss out on:
- Tachyon Dump/Debug/Inspect for RAM/EEPROM/SD-Card
- very easy to write debug functions / tests / loops
- full Tachyon system is part of the 'debugger' and REPL accessible
- fast & compact code
- dictionary in EEPROM or SD for small runtime footprint
Drawbacks:
- other thinking
- other language
- NIH - but full source available
- more difficult to integrate
- Users need to learn a bit of FORTH to use full power ...
that said ...
this could have been REALLY interresting ...
I spent some time recently reading through the Tachyon glossary and the "Thinking Forth" book and after looking at the examples I remember what made Forth difficult for me. It's perfectly obvious and not a new observation but I miss being able to name local variables and function parameters. I think naming is one of the most powerful features in programming languages and it seems to be missing from Forth except for globals. I suspect this may just be a failing of mine because I can see that others can do great things with Forth but it is something I will have to learn to overcome if I'm going to join those ranks.
I'm sorry Peter, I think my trial of Tachyon just got pushed off for another couple years.
You are missing out on a lot of great features,
but I understand that you live in an other world ;-)
and it is probably best to stay in one of it instead of trying to merge
so different cultures.
On the other hand intercultural marriages can be for mutual benefit.
So things you miss out on:
- Tachyon Dump/Debug/Inspect for RAM/EEPROM/SD-Card
- very easy to write debug functions / tests / loops
- full Tachyon system is part of the 'debugger' and REPL accessible
- fast & compact code
- dictionary in EEPROM or SD for small runtime footprint
Drawbacks:
- other thinking
- other language
- NIH - but full source available
- more difficult to integrate
- Users need to learn a bit of FORTH to use full power ...
that said ...
this could have been REALLY interresting ...
Those are indeed all very great things that I'm "missing out on" but none of them are what I was looking for in the original post. Henceforth why I would much rather take Eric's solution.
I spent some time recently reading through the Tachyon glossary and the "Thinking Forth" book and after looking at the examples I remember what made Forth difficult for me. It's perfectly obvious and not a new observation but I miss being able to name local variables and function parameters. I think naming is one of the most powerful features in programming languages and it seems to be missing from Forth except for globals. I suspect this may just be a failing of mine because I can see that others can do great things with Forth but it is something I will have to learn to overcome if I'm going to join those ranks.
Hi David,
I started with Forth, when I started with Tachyon. Never been in contact with it before.
This missing of names I agree, but I think it's just a consequence of the language and system design.
- for function parameters
there is no formal way to define the function parameters - just the stack
comment which tells how many items the word/function consumes and what
they mean - but this is even optional :-( and some genial programmers
like Peter ... ommit them at times which makes it difficult for others/me ;-).
- locals
there are none - all happens on the stack
but there is nothing like a stack-frame or scope like LET in LISP
this is all too complicated just a very simple stack for everything.
In a stack-frame you could assign names to the elements and the
compiler handles everything for you.
For me the learning was to just only have tiny words no half or full page function definitions with 3 dozen locals etc ...
You take up to 2 or max 4 elements from the stack and return 1 or 2.
And a word is no more than 10 lines of code, often just one .
And after this time still I sometimes struggle with the stack handling,
which tells me to go step by step and write much more comments :-) ..
But is not a big deal, because I can just try it out interactively, check the stack any time with .S and qickly see what I didn't see ...
Because this missing of locals Peter introduced a way to do it (still no dynamic naming), but helpful.
( LOCAL VARIABLES )
{ Saving stack parameters to local variables can simplify the stack manipulation required
A specified number of parameters are removed and copied to the local variables area but first the
existing local variables are pushed up so that they are saved and can be restored with a RELEASE
To simplify the use of these variables any direct reference to them will automatically fetch the contents
rather than cluttering the code with @ after each instance.
Example of using LOCALs:
\ Draw a rectangle
pub RECT ( x1 y1 width height -- )
( X4 X3 X2 X1 )
4 LOCAL
X4 X3 X2 HLINE
X4 X3 X1 1- + X2 1- HLINE
X4 X2 + 1- X3 X1 VLINE
X4 X3 X1 VLINE
4 RELEASE
}
I think from my limited perspective, leaving all this special stuff out is what makes a Forth system so small. Because you have to put it either in the compiler (big) to be run to prepare the code to run... or you do it in an interpreter (big) at runtime (slow).
So yes, at times it requires a bit more thinking.
But the dynamic, expressiveness and compactness like having
the full interpreter, SD, Filesystem, Webserver, FTP, Telnet, and application in 32k RAM is just fantastic. And having the full source, which, with a little time, even I can understand and modify a bit ;-) ... is the freedom I like.
viva TACHYON :-)
On the PC I am happy with VisualBasic/EXCEL, LUA, Smalltalk, LISP ;-)
no need for Forth or C
Hi Eric. This is really cool. I particularly like your ParseExprLevel function. It always bothered me that all of my bytecode compilers and a zillion functions named things like parse_expr1, parse_expr2, etc. that were all identical except for the operators they handle. I think I'm going to steal your idea if you don't mind! :-)
Thanks David, and of course I don't mind :-). I was trying to squeeze the parser code down as much as possible. On a PC it doesn't really matter if there are many functions (and it's probably clearer that way) but boy the Propeller is a constrained environment!
I spent some time recently reading through the Tachyon glossary and the "Thinking Forth" book and after looking at the examples I remember what made Forth difficult for me. It's perfectly obvious and not a new observation but I miss being able to name local variables and function parameters. I think naming is one of the most powerful features in programming languages and it seems to be missing from Forth except for globals. I suspect this may just be a failing of mine because I can see that others can do great things with Forth but it is something I will have to learn to overcome if I'm going to join those ranks.
Hi David,
I started with Forth, when I started with Tachyon. Never been in contact with it before.
This missing of names I agree, but I think it's just a consequence of the language and system design.
- for function parameters
there is no formal way to define the function parameters - just the stack
comment which tells how many items the word/function consumes and what
they mean - but this is even optional :-( and some genial programmers
like Peter ... ommit them at times which makes it difficult for others/me ;-).
- locals
there are none - all happens on the stack
but there is nothing like a stack-frame or scope like LET in LISP
this is all too complicated just a very simple stack for everything.
In a stack-frame you could assign names to the elements and the
compiler handles everything for you.
For me the learning was to just only have tiny words no half or full page function definitions with 3 dozen locals etc ...
You take up to 2 or max 4 elements from the stack and return 1 or 2.
And a word is no more than 10 lines of code, often just one .
And after this time still I sometimes struggle with the stack handling,
which tells me to go step by step and write much more comments :-) ..
But is not a big deal, because I can just try it out interactively, check the stack any time with .S and qickly see what I didn't see ...
Because this missing of locals Peter introduced a way to do it (still no dynamic naming), but helpful.
( LOCAL VARIABLES )
{ Saving stack parameters to local variables can simplify the stack manipulation required
A specified number of parameters are removed and copied to the local variables area but first the
existing local variables are pushed up so that they are saved and can be restored with a RELEASE
To simplify the use of these variables any direct reference to them will automatically fetch the contents
rather than cluttering the code with @ after each instance.
Example of using LOCALs:
\ Draw a rectangle
pub RECT ( x1 y1 width height -- )
( X4 X3 X2 X1 )
4 LOCAL
X4 X3 X2 HLINE
X4 X3 X1 1- + X2 1- HLINE
X4 X2 + 1- X3 X1 VLINE
X4 X3 X1 VLINE
4 RELEASE
}
I think from my limited perspective, leaving all this special stuff out is what makes a Forth system so small. Because you have to put it either in the compiler (big) to be run to prepare the code to run... or you do it in an interpreter (big) at runtime (slow).
So yes, at times it requires a bit more thinking.
But the dynamic, expressiveness and compactness like having
the full interpreter, SD, Filesystem, Webserver, FTP, Telnet, and application in 32k RAM is just fantastic. And having the full source, which, with a little time, even I can understand and modify a bit ;-) ... is the freedom I like.
viva TACHYON :-)
On the PC I am happy with VisualBasic/EXCEL, LUA, Smalltalk, LISP ;-)
no need for Forth or C
I didn't know that Peter had added a way to have named parameters and locals. I'll have to look into that. And I certainly agree that Tachyon crams a lot into the limited resources of a Propeller. I haven't been able to touch that with any other language. Quite impressive indeed.
Because this missing of locals Peter introduced a way to do it (still no dynamic naming), but helpful.
( LOCAL VARIABLES )
{ Saving stack parameters to local variables can simplify the stack manipulation required
A specified number of parameters are removed and copied to the local variables area but first the
existing local variables are pushed up so that they are saved and can be restored with a RELEASE
To simplify the use of these variables any direct reference to them will automatically fetch the contents
rather than cluttering the code with @ after each instance.
Example of using LOCALs:
\ Draw a rectangle
pub RECT ( x1 y1 width height -- )
( X4 X3 X2 X1 )
4 LOCAL
X4 X3 X2 HLINE
X4 X3 X1 1- + X2 1- HLINE
X4 X2 + 1- X3 X1 VLINE
X4 X3 X1 VLINE
4 RELEASE
}
I think from my limited perspective, leaving all this special stuff out is what makes a Forth system so small. Because you have to put it either in the compiler (big) to be run to prepare the code to run... or you do it in an interpreter (big) at runtime (slow).
So yes, at times it requires a bit more thinking.
But the dynamic, expressiveness and compactness like having
the full interpreter, SD, Filesystem, Webserver, FTP, Telnet, and application in 32k RAM is just fantastic. And having the full source, which, with a little time, even I can understand and modify a bit ;-) ... is the freedom I like.
viva TACHYON :-)
On the PC I am happy with VisualBasic/EXCEL, LUA, Smalltalk, LISP ;-)
no need for Forth or C
I didn't know that Peter had added a way to have named parameters and locals. I'll have to look into that. And I certainly agree that Tachyon crams a lot into the limited resources of a Propeller. I haven't been able to touch that with any other language. Quite impressive indeed.
not exactly
- the named parameters is just the stack COMMENT and optional - this could be handled by the language in some way, but would bloat the system and slow it down.
- the locals have fixed names X1 .. X4 as shown in the example to keep it simple and efficient.
the 4 LOCAL just puts the 4 topmost stack items in those variables with fixed name X1..X4 to make them accesable
until the 4 RELEASE is executed. There is a little extra stack, so you can do this for a max of 16 elements (longs) in multiple nested invocations.
but actually this one example is the only case I have seen it used (just searched the Tachyon files from PEter'S dropbox) or used it myself.
But found this ;-)
\ Tachyon Stack Frame Handler by Markus Baer MJB 2013
where I started to create something semi-automated ...
So if space gets low I'd rather remove this feature from Tachyon.
Markus
Comments
As Eric says, things will be a bit tricky on the Prop. One "engine" runs Forth, say, and another runs the LMM kernel for C. All that command and parameter passing will have to go through a mail box in memory.
C++ makes things even harder. Calling methods on objects is going to need not only the name of the method but a pointer to the object the method is being called on. How does one know where that is in memory?
Then there is the issue of name mangling. The C++ compiler renames everything for it's own purposes, so a simple method name might end up looking like "_ZN9wikipedia7article8print_toERSo".
It's all to much. Impossible I'd say
a 32-bit 'Function Pointer'
and some space - for parameters (could be accesseed in bytes, words, 32-bit longs might be simplest - depends on the C++ side ...)
Tachyon populates the parameters from it's stack,
then writes the FunctionPointer (
the C++ COG sees FunctionPointer <>0 and does it's job, puts the results in the same area and when done clears FunctionPointer to 0.
Tachyon recognizes this and since the memory position is known,
you can inspect those values directly without any copying if you like.
Or do what you want with them.
You can inspect the whole RAM / SD memory anyhow ;-)
while others still discuss ifs and hows
Tachyon is there in the play for quite some time now,
getting stronger almost every day.
And the network of Propellers might be a nice idea,
but in reality one is enough for most of the problems around,
if we just use resources reasonably -
e.g. integer/scaled int vs. floating point etc.
and yes I heard about Peter's 40+ Props/installation exception ;-)
Yes, you will have them during the week
you could negotiate a special deal with Ken then ;-)
edit: faster writing than thinking - with Peter of course :-)
I've written a very simple interpreter called tinyscript that takes up about 3K and a similar amount of RAM, and is pretty easy to interface with C.
You won't be able to call all the C functions in your program (that's probably not feasible on the Propeller!) but you can
easily select a few to export. There isn't a REPL provided by the interpreter, but it's very easy to provide one in the
app if you want. A complete app with a REPL using C stdio (so not nearly as compact as it could be) is 10K in CMM mode.
The URL is: https://github.com/totalspectrum/tinyscript.
tinyscript is a pretty simple language. Here's a program to blink that I just typed in to my propeller (the greater
than sign is just the prompt from my dumb REPL):
> proc pause { waitcnt(getcnt()+40000000) } > proc blink { pinout(pin,1); pause; pinout(pin,0); pause } > var pin=20 > blink > var i=10; while (i>0) { blink; i=i-1 }You can even write fibonacci in it:
# calculate fibo(n) # parameter in n, returns result in r var n=0 var r=0 proc fibo { if (n<2) { r=n } else { var saven=n # save our parameter for recursive call var a=0 n=n-1; fibo; a=r n=saven-2; fibo; r=a+r n=saven } } var i=1 while i<=12 { n=i; fibo print "fibo(",i,") = ",r i=i+1 }Now the caveats: I just wrote this interpreter over the weekend, so it's probably pretty buggy. Error handling is up to
the application: the interpreter just returns an error number when something goes wrong. If something goes badly
wrong it calls abort(). The provided REPL uses fgets() to read the line; there's no real way to save scripts or edit
them. That's not really a flaw in the interpreter per se, though, it's up to the application to do that.
Eric, you rock.
I'm sorry Peter, I think my trial of Tachyon just got pushed off for another couple years.
Of course, the first thing I'll have to do with tinyscript is fork it and convert the serial routines to PropWare. But this looks really fun! It might make it into the v3.0 release of PropWare.
You are missing out on a lot of great features,
but I understand that you live in an other world ;-)
and it is probably best to stay in one of it instead of trying to merge
so different cultures.
On the other hand intercultural marriages can be for mutual benefit.
So things you miss out on:
- Tachyon Dump/Debug/Inspect for RAM/EEPROM/SD-Card
- very easy to write debug functions / tests / loops
- full Tachyon system is part of the 'debugger' and REPL accessible
- fast & compact code
- dictionary in EEPROM or SD for small runtime footprint
Drawbacks:
- other thinking
- other language
- NIH - but full source available
- more difficult to integrate
- Users need to learn a bit of FORTH to use full power ...
that said ...
this could have been REALLY interresting ...
Those are indeed all very great things that I'm "missing out on" but none of them are what I was looking for in the original post. Henceforth why I would much rather take Eric's solution.
I started with Forth, when I started with Tachyon. Never been in contact with it before.
This missing of names I agree, but I think it's just a consequence of the language and system design.
- for function parameters
there is no formal way to define the function parameters - just the stack
comment which tells how many items the word/function consumes and what
they mean - but this is even optional :-( and some genial programmers
like Peter ... ommit them at times which makes it difficult for others/me ;-).
- locals
there are none - all happens on the stack
but there is nothing like a stack-frame or scope like LET in LISP
this is all too complicated just a very simple stack for everything.
In a stack-frame you could assign names to the elements and the
compiler handles everything for you.
For me the learning was to just only have tiny words no half or full page function definitions with 3 dozen locals etc ...
You take up to 2 or max 4 elements from the stack and return 1 or 2.
And a word is no more than 10 lines of code, often just one .
And after this time still I sometimes struggle with the stack handling,
which tells me to go step by step and write much more comments :-) ..
But is not a big deal, because I can just try it out interactively, check the stack any time with .S and qickly see what I didn't see ...
Because this missing of locals Peter introduced a way to do it (still no dynamic naming), but helpful.
( LOCAL VARIABLES ) { Saving stack parameters to local variables can simplify the stack manipulation required A specified number of parameters are removed and copied to the local variables area but first the existing local variables are pushed up so that they are saved and can be restored with a RELEASE To simplify the use of these variables any direct reference to them will automatically fetch the contents rather than cluttering the code with @ after each instance. Example of using LOCALs: \ Draw a rectangle pub RECT ( x1 y1 width height -- ) ( X4 X3 X2 X1 ) 4 LOCAL X4 X3 X2 HLINE X4 X3 X1 1- + X2 1- HLINE X4 X2 + 1- X3 X1 VLINE X4 X3 X1 VLINE 4 RELEASE }I think from my limited perspective, leaving all this special stuff out is what makes a Forth system so small. Because you have to put it either in the compiler (big) to be run to prepare the code to run... or you do it in an interpreter (big) at runtime (slow).
So yes, at times it requires a bit more thinking.
But the dynamic, expressiveness and compactness like having
the full interpreter, SD, Filesystem, Webserver, FTP, Telnet, and application in 32k RAM is just fantastic. And having the full source, which, with a little time, even I can understand and modify a bit ;-) ... is the freedom I like.
viva TACHYON :-)
On the PC I am happy with VisualBasic/EXCEL, LUA, Smalltalk, LISP ;-)
no need for Forth or C
Thanks David, and of course I don't mind :-). I was trying to squeeze the parser code down as much as possible. On a PC it doesn't really matter if there are many functions (and it's probably clearer that way) but boy the Propeller is a constrained environment!
- the named parameters is just the stack COMMENT and optional - this could be handled by the language in some way, but would bloat the system and slow it down.
- the locals have fixed names X1 .. X4 as shown in the example to keep it simple and efficient.
the 4 LOCAL just puts the 4 topmost stack items in those variables with fixed name X1..X4 to make them accesable
until the 4 RELEASE is executed. There is a little extra stack, so you can do this for a max of 16 elements (longs) in multiple nested invocations.
but actually this one example is the only case I have seen it used (just searched the Tachyon files from PEter'S dropbox) or used it myself.
But found this ;-)
\ Tachyon Stack Frame Handler by Markus Baer MJB 2013
where I started to create something semi-automated ...
So if space gets low I'd rather remove this feature from Tachyon.
Markus