Hi Peter,
I was always facinated by forth. But I seem to be too simple minded to read the source code easily. :-(
Some time ago I dicovered, that there is the feature of local named variables in forth, which improve the readability very much. You could as well say, it makes documentation very much more easy.
Yes, I know, a real forth crack does not need local variables.
Is there support or will there be support for local variables in Tachyon?
Regards, Christof
Peter had a simple mechanism for local variables in Tachyon.
Here automatically putting stack to locals for easy access without stack juggling.
\ space for up to 16 locals
TABLE locals $40 ALLOT
pri @X ( index -- ) 2* 2* locals + ;
pub X1 ( -- local1 \ push local 1 on the stack ) locals @ ;
pub X2 ( -- local2 \ push local 2 on the stack ) 1 @X @ ;
pub X3 ( -- local3 \ push local 3 on the stack ) 2 @X @ ;
pub X4 ( -- local4 \ push local 4 on the stack ) 3 @X @ ;
pub LOCAL ( n -- \ pop the n top stack elements to the local space, TOS => X1, TOS+1 => X2 .. )
locals OVER @X 3RD 2* 2* $40 SWAP - <CMOVE 0 DO I @X ! LOOP ;
pub RELEASE ( n -- \ remove n elements from locals, of no longer used )
DUP @X locals ROT 2* 2* $40 SWAP - CMOVE ;
locals $40 ERASE \ Clean out the locals (easier for debugging)
}
But likely when you feel the need for local variables you have not
sufficiently decomposed / factored your problem at hand.
Of course in conventional language we use locals all the time.
If you provide a concrete example we can have a look at it ...
"But likely when you feel the need for local variables you have not sufficiently decomposed / factored your problem at hand."
Forthers alway seem to try to teach the others about the better ways?
For me it is simple: If I want to make a new project, I make a table. With what controller and what environment/language with its libraries can I do the project fastest? Readable documentation is also very important, because I have to be able to adjust a project after a few months when I have forgotten a lot.
And yes, I will even use floating point math to achieve my goals. :-)
I have used Tachyon on P1 as an interface between a raspi and a P1, which is really great, because the whole communication is already done. So I have not used forth, because it is the best language ever, but because it provides the special benefit of natural interactivity over a serial line. The raspi sends a forth word and gets back answers. The P1 controls 3 stepper motors of a mill.
"But likely when you feel the need for local variables you have not sufficiently decomposed / factored your problem at hand."
Forthers alway seem to try to teach the others about the better ways?
For me it is simple: If I want to make a new project, I make a table. With what controller and what environment/language with its libraries can I do the project fastest? Readable documentation is also very important, because I have to be able to adjust a project after a few months when I have forgotten a lot.
And yes, I will even use floating point math to achieve my goals. :-)
one of the things I like most about FORTH/Tachyon which most other systems/languages do not provide for
is that the system/compiler/language can be easily extended as you like.
I know how i could implement what your link shows. And it would be fun too.
It would cost some compile-time performance which usually is uncritical, but also some run-time performance.
But I never really encountered the need to have it.
This is an embedded system with the development tools (compiler/interpreter/..) residing on the system/MCU itself
so focus is small, fast and INTERACTIVE
usually a bit different than PC based systems which have unlimited memory can afford big optimizing compilers etc.
I have used Tachyon on P1 as an interface between a raspi and a P1, which is really great, because the whole communication is already done. So I have not used forth, because it is the best language ever, but because it provides the special benefit of natural interactivity over a serial line. The raspi sends a forth word and gets back answers. The P1 controls 3 stepper motors of a mill.
yes - this is one of the things Tachyon is really good at
Is the following code to be found:
--- common receive buffer check
pri RX? ( chan -- offset diff ) 1- comsz * rxwr1 OVER + W@ rxrd1 3RD + W@ - rxszm AND ;
Question: What is the percentage of Parallax customers, who can read this and directly understand what is going on?
"Customer orientation" would be to try to make it more easy for them.
(I am well aware, that I am no customer for Tachyon and that this is therefore no customer request and can be only some begging. It is nevertheless somewhat of a pity, that forth is dying. Forthers seem just to be happy, that they are the only ones, who understand their code. I have not yet found a second project, that uses Tachyon to do something. Of course Peter is using it.)
Is the following code to be found:
--- common receive buffer check
pri RX? ( chan -- offset diff ) 1- comsz * rxwr1 OVER + W@ rxrd1 3RD + W@ - rxszm AND ;
Question: What is the percentage of Parallax customers, who can read this and directly understand what is going on?
"Customer orientation" would be to try to make it more easy for them.
(I am well aware, that I am no customer for Tachyon and that this is therefore no customer request and can be only some begging. It is nevertheless somewhat of a pity, that forth is dying. Forthers seem just to be happy, that they are the only ones, who understand their code. I have not yet found a second project, that uses Tachyon to do something. Of course Peter is using it.)
I accept this is how the master @"Peter Jakacki" codes and not necessarily a very easily readable code example.
Also this line is taken out of context and you would not expect people to understand it without context.
When you would write such code you could use longer names or a few more comments
and things would be very obvious.
I agree it is not easy to read
- The full code also is an example of code which could have very well been factored a bit more
which would get rid of some stack juggling like (3RD) and
also been documented a bit more if it is written to be understood by a customer.
@"Peter Jakacki" obviously can do this in his head ;-)
But if the code is time critical the factoring will slow it down a bit - but commenting will definitely help.
btw - How would you write it with local variables?
pri RX? ( chan -- offset diff )
there is a private routine: is the receiver ready RX?
at call the stack needs to hold the channel number
at return the stack holds an offset value and a difference, whatever it is.
1: place a 1 on the stack
- substract first stack value from next stack value: the "1" is consumed, the stack holds chan# minus 1
ecomsz places ecomsz on the stack: ecomsz: ecom size, ecommunication size? I suppose, ecomsz is the size of a structure holding the communication channel paramaters
* multiplies structure size times channel#: the offset to the parameter block of the channel wanted
rxwr1 whatever it is...
OVER ( a b -- a b a ) C Copy 2nd stack location to first (push) Stack: rxwr1, offset, rxwr1
+ adds offset to parameterblock to rxwr1: rxwr1 should be the start address of the structure array, now pointer to actual parameter of selected channel
W@ ( adr -- word ) C Fetch a word from hub memory
rxrd1 obviously another base pointer
3RD ( a b c d -- a b c d b ) C Copy third stack item (push) third value in the structure is needed
+ add this third value to the base pointer
W@ fetch the addressed value
- substract the value from the previously calculated pointer
rxszm sounds like receive buffer size maximum (minimun makes no sense, we are not in politics here)
AND modulo, this value must be the diff
the next value on the stack is the offset.
So the code is understandable, but the meaning has to be determined
Ok, last try:
< snip > I have not yet found a second project, that uses Tachyon to do something. Of course Peter is using it.)
I struggle with thinking in forth, but once I get back to it, it is reasonable.
As for a 'second project', we use Tachyon v3 on a P1 to provide an interface to our electron beam controllers. There are 8 ADC and 8 DACs at work, and the P1 allows the beam to be programmed easily and the various data channels to be sampled without interrupting (so to speak!) the other tasks. An easily extended ... we improved our S/N by about an order of magnitude today with some easy code additions that offloaded tasks from the PC down to the P1.
Writing what is essentially low-level code that accesses a virtual peripheral is never self-explanatory as you need to know the arrangement and operation of the registers and memory of that "peripheral". But once you have that understanding then it starts to make sense. Because it is a low-level driver it is normally coded for run-time efficiency and not necessarily for verbose readable code.
However if you look at a high level function such as drawing a rectangle which normally requires four parameters plus color, you find that you can avoid all that additional stack manipulation by not passing those parameters directly to that function. Imagine that we have a function that might be expressed in a more traditional way as "rect(100,240,200,50,red)" to draw a rectangle whose top left corner would be at 100 x and 240 y with a width of 200 and a height of 50. In Forth we might write that as "100 240 200 50 red rect" but that requires awkward stack manipulation or you could use a less efficient but more readable local variable form internally. Step outside of that thinking and create words for x y width height and pen color and all of a sudden you no longer need to pass any stack parameters to the rect word. In TAQOZ it is done this way:
100 x 240 y 200 w 50 h red pen rect
Any or all of those operations can be skipped if you are not changing the last setting or bearing in mind that there is no strict "syntax" you could just as easily say:
red pen 50 h 200 w 100 x 240 y rect
The lower levels of the rectangle routine
--- top left to-right right reset-xy to-bottom bottom & reset-xy
pub RECT HLINE VLINE width W@ 1- X+! VLINE !XY height W@ 1- Y+! HLINE !XY ;
Note: Lowercase can be used for any upper or mixed case words as long as there is no other conflict.
(I'm travelling and have been too busy to do much the past couple of weeks but I do have a little time at the moment)
Thanks for the answers!
I am glad to read, that the usage of variables is recommended. And that the existance of the problem of readability is seen. (makes me feel a little bit less stupid, thank you :-) )
Well, it seems to be widely known, that LOCAL variables have their advantages versus global variables. This must be the reason, that all newer languages have got them. So I was happy to descover, that this exists as a possibility too in forth 2012.
P2 is quite fast and has a lot of memory, so it seems reasonable to sacrify a little speed and space for the sake of other advantages. (My personal opinion is, that it should be done for P1 too.)
So the suggestion is and was just to implement local variables with speaking names in Tachyon.
pri RX? ( chan -- offset diff )
there is a private routine: is the receiver ready RX?
at call the stack needs to hold the channel number
at return the stack holds an offset value and a difference, whatever it is.
1: place a 1 on the stack
- substract first stack value from next stack value: the "1" is consumed, the stack holds chan# minus 1
ecomsz places ecomsz on the stack: ecomsz: ecom size, ecommunication size? I suppose, ecomsz is the size of a structure holding the communication channel paramaters
* multiplies structure size times channel#: the offset to the parameter block of the channel wanted
rxwr1 whatever it is...
OVER ( a b -- a b a ) C Copy 2nd stack location to first (push) Stack: rxwr1, offset, rxwr1
+ adds offset to parameterblock to rxwr1: rxwr1 should be the start address of the structure array, now pointer to actual parameter of selected channel
W@ ( adr -- word ) C Fetch a word from hub memory
rxrd1 obviously another base pointer
3RD ( a b c d -- a b c d b ) C Copy third stack item (push) third value in the structure is needed
+ add this third value to the base pointer
W@ fetch the addressed value
- substract the value from the previously calculated pointer
rxszm sounds like receive buffer size maximum (minimun makes no sense, we are not in politics here)
AND modulo, this value must be the diff
the next value on the stack is the offset.
So the code is understandable, but the meaning has to be determined
Thanks for the answers!
I am glad to read, that the usage of variables is recommended. And that the existance of the problem of readability is seen. (makes me feel a little bit less stupid, thank you :-) )
Well, it seems to be widely known, that LOCAL variables have their advantages versus global variables. This must be the reason, that all newer languages have got them. So I was happy to descover, that this exists as a possibility too in forth 2012.
P2 is quite fast and has a lot of memory, so it seems reasonable to sacrify a little speed and space for the sake of other advantages. (My personal opinion is, that it should be done for P1 too.)
So the suggestion is and was just to implement local variables with speaking names in Tachyon.
Hi MJB,
The sense of local variables vs global ones is to reduce complexity.
Of course local variables are only a step in the direction to achieve better readability.
I will no longer try to argue the sense of local variables here as I think everything is said from my side.
Best regards Christof
There are pros and cons for having local variables. Local variables are linked to a context : the function using the variables. So house keeping variable usage is not a must. Having global variables results in more flexibility. This is an advantage in multi processing environments, where one process can watch another process's activities. So, if one process iterates a loop and another process does an arbitrary job, but has to react on completion of the iteration, this process can schedule own activites to use the iterations results. For example, I don't tweet, as I'm busy, but on the other side, I can watch another process's tweets and so determine, when I will come back to normal live, no longer doubting that there is AI, but not I. Moreover, as a supervisory process I can terminate the iteration befor completion.
Hands up all those who didn't struggle when they were first introduced to any kind of programming? Hands up!? Ok, I don't see any hands.
Hands up all those who didn't struggle when they first started to learn a different spoken language? Same.
If Forth was your first language then I'm also certain that learning another language would seem back-to-front.
So it is really a matter of thinking in the language that you are trying to use in which case I recommend reading "Thinking Forth" . It's a great read in the same style as Starting Forth and the "thinking" is also applicable for programming in general.
Moving from COBOL to MS net framework with VB and C# really was a struggle for me, and after 20 years I am honestly thinking about moving the whole shebang back to COBOL and some TCL or Java front end.
Since YEARS I spend more time on keeping this project (sort of huge one) updated to new net versions as I have time to integrate new features. Currently I am still behind, starting with VB4 in 1992 it now has grown to a monster using C# and Visual Studio 2010, and YES I am already 3 VS-Versions behind.
My other customers stayed on COBOL and - well - survived moving from one mainframe to a different one, survived to move to PC Hardware (well with some slower I/O) and quite less source changes as moving from one net version to the other.
Most of the COBOL code is unchanged since 30+ years and simply runs on newer Hardware and different Os-es.
And then there is FORTH. A beautiful concept. But not really a language you can read 20 years later, written by somebody else. Heck I do have problems reading stuff I wrote by myself not even 3 weeks ago.
I do think FORTH is quite valuable on a micro-controller, Basically you can use the P2 as serial I/O extender out of the box, if someone would take the time to document this properly for non FORTH user.
And, Peter might hate me for this, but I personally think that one can not build a serious complete Application in Forth and maintain it over decades.
It is not the reverse polish notation, I can handle that one. The main problem I do have with FORTH is what Peter and MJB think of as the most positive thing about FORTH, and it is that you basically need to invent a own project-defined-language for each project. No reusability, no common parts one can reuse and well - I do long time projects and I have already a hard time with conventional programming languages understanding what some programmer was thinking a decade ago.
Doable with COBOL, doable with FORTRAN, doable with BASIC, doable with C. not so doable with C++ and not at all with FORTH.
I am working with large projects. sometimes hundreds of man years of code. Banks, Insurances, IRS, Post Office. That is where COBOL still runs and does well. COBOL is the opposite of FORTH, the most verbose language you can imagine. But quite clear for even a non programmer.
COBOL:
multiply SINGLE-PRICE by COUNT-UNITS giving TOTAL-AMOUNT
the need to comment anything quite vanishes - you can show that to your tax-accountant and he can say yes/no
C/algol-like languages:
TOTAL_AMOUNT = SINGLE_PRICE * COUNT_UNITS
already backwards, one can not really read it to some non-programmer but some tax-accountant would still understand it and say yes/no.
SINGLE_PRICE R? COUNT_UNITS R? * TOTAL_AMOUNT W!
well - might not be FORTH, but could be.
the readability is low on this one.
And that is the reason that FORTH never made it into a main-stream used language. Forth is not a computer language at all it is a generator for a project specific language.
Once done with your project-specific language you can write stuff like
LEDPOWERSWITCH ON 500 MS LEDPOWERSWITCH OFF
might be
ON LEDPOWERSWITCH 500 MS OFF LEDPOWERSWITCH
which is quite readable as long as you are aware and in the known about the definitions of LEDPOWERSWITCH, ON, OFF and MS.
But if you look them up you find weird code like shown above with TOTAL_AMOUNT
The Basic Idea of a Domain Specific Language is not wrong, even MS tried to push that to us programmers, but it never stuck on the wall independent on how often they were throwing it at it.
It is about reusability and readability and that is why I think FORTH is not a main-stream language.
TAQOZ in ROM could have been a nice Language for a I/O controller, right out of the box, but Peter never developed it like that, he just wanted a complete FORTH in ROM, but then advised me to NOT use the ROM but load the newer versions into RAM.
Well - sorry when I come over rude -, but WHY is it in ROM when one should not use it?
That is essentially what I did with POS terminals decades ago, nice and simple. Just imagine the digits being entered by the keypad and the PRICE, QTY, and TOTAL words as well as the decimal point being tied to a key on the keyboard, and basically that is how it worked and also the sequence that you would expect the operator to punch it all in by. Forth just soaked it up without any fuss.
As for "ON LEDPOWERSWITCH 500 MS OFF LEDPOWERSWITCH" I would never have such long verbose COBOL type names
If you have had a look at some of my code you will probably find stuff like "ON LED" or "ON STAT LED" or "RED STAT LED" etc. I think that form is easy to read but the trick is to know which word goes with which, which can be a bit hard if it is jammed onto a single line with everything else. That's where I like to use extra spaces if I do or else leave leave it on its own line.
I think Domain Specific Language does exist in many languages, it's just that they call it a library function, but the problem with the library besides the learning curve for each one, is that it either does what you want or doesn't, and you don't have the source.
But you are certainly being a bit harsh about TAQOZ in ROM because if you were in my position you would have been aware that you are working with memory limitations, time limitations, and documentation (lack of) limitations. Whatever I did the first time had to work but it was really awkward to test the reset sequence in FPGA since everything was lost when it was reset. Even Chip took time to appreciate that we really needed a special FPGA version that could emulate a mask ROM so that we could reset the P2 and not lose the ROM. Of course a power-up test was impossible. But that was all last minute stuff and we worked through many nights testing and squeezing. The revision was mainly to fix and test any small bugs and I made up special hardware for my CVA9 to plug into so I could check it, in fact I was the only one who could check it since Cluso99 lost his FPGA and Chip didn't have an external SD card setup etc.
...
TAQOZ in ROM could have been a nice Language for a I/O controller, right out of the box, but Peter never developed it like that, he just wanted a complete FORTH in ROM, but then advised me to NOT use the ROM but load the newer versions into RAM.
Well - sorry when I come over rude -, but WHY is it in ROM when one should not use it?
TAQOZ is in ROM because the ROM was there, and the ROM is very limited in size. The ROM is an OnSemi IP block, and the primary focus is to support bootloading.
Once that task is done, why not use the spare ROM for something else useful ? Many more would complain if there was ROM left unused !
End result is you get something very useful and flexible, and you can do rapid tests using TAQOZ, but if you want full horsepower, of course you load a version larger than would fit in ROM.
That's engineering.
That is essentially what I did with POS terminals decades ago, nice and simple. Just imagine the digits being entered by the keypad and the PRICE, QTY, and TOTAL words as well as the decimal point being tied to a key on the keyboard, and basically that is how it worked and also the sequence that you would expect the operator to punch it all in by. Forth just soaked it up without any fuss.
As for "ON LEDPOWERSWITCH 500 MS OFF LEDPOWERSWITCH" I would never have such long verbose COBOL type names
If you have had a look at some of my code you will probably find stuff like "ON LED" or "ON STAT LED" or "RED STAT LED" etc. I think that form is easy to read but the trick is to know which word goes with which, which can be a bit hard if it is jammed onto a single line with everything else. That's where I like to use extra spaces if I do or else leave leave it on its own line.
I think Domain Specific Language does exist in many languages, it's just that they call it a library function, but the problem with the library besides the learning curve for each one, is that it either does what you want or doesn't, and you don't have the source.
But you are certainly being a bit harsh about TAQOZ in ROM because if you were in my position you would have been aware that you are working with memory limitations, time limitations, and documentation (lack of) limitations. Whatever I did the first time had to work but it was really awkward to test the reset sequence in FPGA since everything was lost when it was reset. Even Chip took time to appreciate that we really needed a special FPGA version that could emulate a mask ROM so that we could reset the P2 and not lose the ROM. Of course a power-up test was impossible. But that was all last minute stuff and we worked through many nights testing and squeezing. The revision was mainly to fix and test any small bugs and I made up special hardware for my CVA9 to plug into so I could check it, in fact I was the only one who could check it since Cluso99 lost his FPGA and Chip didn't have an external SD card setup etc.
I do agree that the end result of a FORTH based Domain Specific Language is perfect to use. And I do also understand that you had not enough time and space (!) to fit into the ROM.
And absolutely sure TAQOZ is your creation and you are changing it constantly to adapt to new challenges. But that is exactly the problem. I just build those two images - hmm- maybe 2-3 weeks ago?
Now they are pretty obsolete, since kernel changed, .FTH's changed, how to put something in the OBEX when the words are changing constantly?
That is why I wanted to use the existing (or new) Rom, but - hmm - it is more easy to compile from source then patching the ROM. With above mentioned problems of hundreds of different versions after 10 years, but I want to go back to the ROM version as soon as we can get new chips.
The Rom stays the same.
I was able to mend TAQOZ and FastSpin Binaries together connected to a mailbox. This basically does allow a FastSpin compiled program to use TAQOZ on its own P2 Chip like a TAQOZ controlled second P2 Chip over serial. If you need more pins add a second P2D2 or whatever, the interface is the same, TAQOZ ROM + your loaded extensions or as it is.
Does the current new TAQOZ in ROM read any autoexec.fth if found on SD?
well - I do look forward to have one P2 connected to a second one serial, reset, send autobaud and esc sequence and end up in a TAQOZ prompt over serial. I can do this now on the same P2 but not with the ROM TAQOZ.
I think this is the best use of TAQOZ in ROM. Can be described. Can have samples that will work as long as the ROM stays the same.
One can attach any MC or PC to the P2-extender and send TAQOZ definitions and commands over after reset.
Those TAQOZ-Scripts-For-Rom can be shared as Text and send via serial after bootup and autobaud.
And that is the only way TAQOZ in ROM makes sense to me.
Mike,
You wanted to do things with ROM TAQOZ that it was never designed to do for a few reasons, mainly time and space.
Therefore Peter (and I) suggested since you needed to load your own code from somewhere, you would be better off loading a more thorough version of TAQOZ too. If you don’t want extra features, then you can use a stable and frozen TAQOZ - you just dont change TAQOZ. IMHO you are overthinking you own problem.
Now TAQOZ in ROM was, and still is, designed to just test the P2 chip before any code is loaded. It does this nicely. Peter gave a number of 1 liners such as “lsio”.
When we received the first boards (Peter assembled the first few after Parallax assembled their first board on Peters P2D2 pcb) the first thing I did was boot up into my debugger/monitor because I knew that better than TAQOZ. Once i has that running, rather than load any code next, I jumped into TAQOZ and ran some of Peters one liners.
This gave me confidence that the P2 was alive. Then i tested downloading programs, and then the SD.
Those of you who received the P2-EVAL were a few weeks behind those with P2D2 (about 5 of us). We has verified that the P2 basics were running by then, so TAQOZ was perhaps not quite so relevant. But TAQOZ provides the minimum basis to test a non-functioning board.
Mike,
You wanted to do things with ROM TAQOZ that it was never designed to do for a few reasons, mainly time and space.
Therefore Peter (and I) suggested since you needed to load your own code from somewhere, you would be better off loading a more thorough version of TAQOZ too. If you don’t want extra features, then you can use a stable and frozen TAQOZ - you just dont change TAQOZ. IMHO you are overthinking you own problem.
Now TAQOZ in ROM was, and still is, designed to just test the P2 chip before any code is loaded. It does this nicely. Peter gave a number of 1 liners such as “lsio”.
When we received the first boards (Peter assembled the first few after Parallax assembled their first board on Peters P2D2 pcb) the first thing I did was boot up into my debugger/monitor because I knew that better than TAQOZ. Once i has that running, rather than load any code next, I jumped into TAQOZ and ran some of Peters one liners.
This gave me confidence that the P2 was alive. Then i tested downloading programs, and then the SD.
Those of you who received the P2-EVAL were a few weeks behind those with P2D2 (about 5 of us). We has verified that the P2 basics were running by then, so TAQOZ was perhaps not quite so relevant. But TAQOZ provides the minimum basis to test a non-functioning board.
Yes - hacking the ROM was my only chance to use TAQOZ in ROM as extender. I just have one P2. Sadly.
When they go out all this trouble is not needed.
Once connected serial to a P2 with booted ROM TAQOZ you are fine. Basically no need for SD or FLASH. Reset, autobaud, send definitions of new words if needed and then just talk to it.
One main P2 to do the HMI and lots of others running TAQOZ scriptlets which can be shared since based on the words in ROM. TAQOZ itself is very fast. I am sure that we will soon have some examples to say run servos, run peters RS434 network, Midi extender or whatever.
And there a Domain Specific Language really makes sense. Once written in TAQOZ it can be used from any other Board/MC/PC. Reset P2, send autobaud, escape to TAQOZ send definitions and go.
Its just serial text to send at reset and you are done. That extender P2 would not need flash or SD, it just boots serial into TAQOZ and gets spoon-fed after reset.
And that is what is possible if you have multiple P2s.
If only I had more ROM I would have been able to have a complete standalone system and mailboxes etc. If only I had more time I would have been able to test it properly and stabilise the kernel. If only I had more people using it at the time it would have those little extras that might be needed. Alas, this is not so.
Besides all these things I also design and build the hardware and write high level software etc. There's even a FAT32 formatter that works with any size card. So many many things, but always it is that one little thing that someone else sees.
being young, you get bad grades for not understanding what you are taught, being old you get bad grades if they don't understand, what you teach. In the first case, the teacher is paid, in the second, the teacher pays the bill. So it is hard to teach original work, always! But it makes perfect sense. On one side, a perfectly constructed sentence is critisized, on the other side, an excited crowd applaudes enthusiastically the high level gobbledygook. On the same side ...
If only I had more ROM I would have been able to have a complete standalone system and mailboxes etc. If only I had more time I would have been able to test it properly and stabilise the kernel. If only I had more people using it at the time it would have those little extras that might be needed. Alas, this is not so.
Besides all these things I also design and build the hardware and write high level software etc. There's even a FAT32 formatter that works with any size card. So many many things, but always it is that one little thing that someone else sees.
So it seems, because of some power issues with VIO, we are going to see another run (P2v3). Does that mean there is a chance that your newer/better TAQOZ will have a chance to be updated in v3?
I wasn't thinking of expanding the ROM, but just putting as much as possible of the newer TAQOZ into rom (prioritized, of course, by likely need) and load the lesser needed from SD, I2C, SPI, or whatever.
This semiconductor fabrication is a bit out of my league, but I would think that updating ROM for a new batch of chips would be pretty trivial.
Comments
Peter had a simple mechanism for local variables in Tachyon.
Here automatically putting stack to locals for easy access without stack juggling.
pri (RECT) X4 X3 X2 HLINE X4 X3 X1 1- + X2 1- HLINE X4 X2 + 1- X3 X1 VLINE X4 X3 X1 VLINE ; \ Draw a rectangle pub RECT ( x1 y1 width height -- ) ( X4 X3 X2 X1 ) 4 LOCAL (RECT) 4 RELEASE ;Implementation of LOCAL
\ space for up to 16 locals TABLE locals $40 ALLOT pri @X ( index -- ) 2* 2* locals + ; pub X1 ( -- local1 \ push local 1 on the stack ) locals @ ; pub X2 ( -- local2 \ push local 2 on the stack ) 1 @X @ ; pub X3 ( -- local3 \ push local 3 on the stack ) 2 @X @ ; pub X4 ( -- local4 \ push local 4 on the stack ) 3 @X @ ; pub LOCAL ( n -- \ pop the n top stack elements to the local space, TOS => X1, TOS+1 => X2 .. ) locals OVER @X 3RD 2* 2* $40 SWAP - <CMOVE 0 DO I @X ! LOOP ; pub RELEASE ( n -- \ remove n elements from locals, of no longer used ) DUP @X locals ROT 2* 2* $40 SWAP - CMOVE ; locals $40 ERASE \ Clean out the locals (easier for debugging) }But likely when you feel the need for local variables you have not
sufficiently decomposed / factored your problem at hand.
Of course in conventional language we use locals all the time.
If you provide a concrete example we can have a look at it ...
No, the question is about "speaking names".
https://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Local-Variables-Tutorial.html
I think it is in the actual ansi forth standard.
"But likely when you feel the need for local variables you have not sufficiently decomposed / factored your problem at hand."
Forthers alway seem to try to teach the others about the better ways?
For me it is simple: If I want to make a new project, I make a table. With what controller and what environment/language with its libraries can I do the project fastest? Readable documentation is also very important, because I have to be able to adjust a project after a few months when I have forgotten a lot.
And yes, I will even use floating point math to achieve my goals. :-)
I have used Tachyon on P1 as an interface between a raspi and a P1, which is really great, because the whole communication is already done. So I have not used forth, because it is the best language ever, but because it provides the special benefit of natural interactivity over a serial line. The raspi sends a forth word and gets back answers. The P1 controls 3 stepper motors of a mill.
one of the things I like most about FORTH/Tachyon which most other systems/languages do not provide for
is that the system/compiler/language can be easily extended as you like.
I know how i could implement what your link shows. And it would be fun too.
It would cost some compile-time performance which usually is uncritical, but also some run-time performance.
But I never really encountered the need to have it.
This is an embedded system with the development tools (compiler/interpreter/..) residing on the system/MCU itself
so focus is small, fast and INTERACTIVE
usually a bit different than PC based systems which have unlimited memory can afford big optimizing compilers etc.
yes - this is one of the things Tachyon is really good at
and I agree does not exist ...
That is the problem. A forth Crack will not see the problem. :-)
I am happy if you can give an example so I can understand it as well ...
The only 'forth Crack' I know is @"Peter Jakacki" ;-)
Here: https://forums.parallax.com/discussion/168052/rs485-router-a-propeller-tachyon-application
Is the following code to be found:
--- common receive buffer check
pri RX? ( chan -- offset diff ) 1- comsz * rxwr1 OVER + W@ rxrd1 3RD + W@ - rxszm AND ;
Question: What is the percentage of Parallax customers, who can read this and directly understand what is going on?
"Customer orientation" would be to try to make it more easy for them.
(I am well aware, that I am no customer for Tachyon and that this is therefore no customer request and can be only some begging. It is nevertheless somewhat of a pity, that forth is dying. Forthers seem just to be happy, that they are the only ones, who understand their code. I have not yet found a second project, that uses Tachyon to do something. Of course Peter is using it.)
I accept this is how the master @"Peter Jakacki" codes and not necessarily a very easily readable code example.
Also this line is taken out of context and you would not expect people to understand it without context.
When you would write such code you could use longer names or a few more comments
and things would be very obvious.
I agree it is not easy to read
- The full code also is an example of code which could have very well been factored a bit more
which would get rid of some stack juggling like (3RD) and
also been documented a bit more if it is written to be understood by a customer.
@"Peter Jakacki" obviously can do this in his head ;-)
But if the code is time critical the factoring will slow it down a bit - but commenting will definitely help.
btw - How would you write it with local variables?
I struggle with thinking in forth, but once I get back to it, it is reasonable.
As for a 'second project', we use Tachyon v3 on a P1 to provide an interface to our electron beam controllers. There are 8 ADC and 8 DACs at work, and the P1 allows the beam to be programmed easily and the various data channels to be sampled without interrupting (so to speak!) the other tasks. An easily extended ... we improved our S/N by about an order of magnitude today with some easy code additions that offloaded tasks from the PC down to the P1.
My $0.02 worth from the peanut gallery ...
However if you look at a high level function such as drawing a rectangle which normally requires four parameters plus color, you find that you can avoid all that additional stack manipulation by not passing those parameters directly to that function. Imagine that we have a function that might be expressed in a more traditional way as "rect(100,240,200,50,red)" to draw a rectangle whose top left corner would be at 100 x and 240 y with a width of 200 and a height of 50. In Forth we might write that as "100 240 200 50 red rect" but that requires awkward stack manipulation or you could use a less efficient but more readable local variable form internally. Step outside of that thinking and create words for x y width height and pen color and all of a sudden you no longer need to pass any stack parameters to the rect word. In TAQOZ it is done this way: Any or all of those operations can be skipped if you are not changing the last setting or bearing in mind that there is no strict "syntax" you could just as easily say:
The lower levels of the rectangle routine
Note: Lowercase can be used for any upper or mixed case words as long as there is no other conflict.
(I'm travelling and have been too busy to do much the past couple of weeks but I do have a little time at the moment)
I am glad to read, that the usage of variables is recommended. And that the existance of the problem of readability is seen. (makes me feel a little bit less stupid, thank you :-) )
Well, it seems to be widely known, that LOCAL variables have their advantages versus global variables. This must be the reason, that all newer languages have got them. So I was happy to descover, that this exists as a possibility too in forth 2012.
P2 is quite fast and has a lot of memory, so it seems reasonable to sacrify a little speed and space for the sake of other advantages. (My personal opinion is, that it should be done for P1 too.)
So the suggestion is and was just to implement local variables with speaking names in Tachyon.
http://www.forth200x.org/locals.html
The Tachyon implementation for this is in my head ... but...
I am still waiting for a real example where it would help ...
The sense of local variables vs global ones is to reduce complexity.
Of course local variables are only a step in the direction to achieve better readability.
I will no longer try to argue the sense of local variables here as I think everything is said from my side.
Best regards Christof
https://www.forth.com/starting-forth/0-starting-forth/
Jim
Hands up all those who didn't struggle when they were first introduced to any kind of programming? Hands up!? Ok, I don't see any hands.
Hands up all those who didn't struggle when they first started to learn a different spoken language? Same.
If Forth was your first language then I'm also certain that learning another language would seem back-to-front.
So it is really a matter of thinking in the language that you are trying to use in which case I recommend reading "Thinking Forth" . It's a great read in the same style as Starting Forth and the "thinking" is also applicable for programming in general.
Since YEARS I spend more time on keeping this project (sort of huge one) updated to new net versions as I have time to integrate new features. Currently I am still behind, starting with VB4 in 1992 it now has grown to a monster using C# and Visual Studio 2010, and YES I am already 3 VS-Versions behind.
My other customers stayed on COBOL and - well - survived moving from one mainframe to a different one, survived to move to PC Hardware (well with some slower I/O) and quite less source changes as moving from one net version to the other.
Most of the COBOL code is unchanged since 30+ years and simply runs on newer Hardware and different Os-es.
And then there is FORTH. A beautiful concept. But not really a language you can read 20 years later, written by somebody else. Heck I do have problems reading stuff I wrote by myself not even 3 weeks ago.
I do think FORTH is quite valuable on a micro-controller, Basically you can use the P2 as serial I/O extender out of the box, if someone would take the time to document this properly for non FORTH user.
And, Peter might hate me for this, but I personally think that one can not build a serious complete Application in Forth and maintain it over decades.
It is not the reverse polish notation, I can handle that one. The main problem I do have with FORTH is what Peter and MJB think of as the most positive thing about FORTH, and it is that you basically need to invent a own project-defined-language for each project. No reusability, no common parts one can reuse and well - I do long time projects and I have already a hard time with conventional programming languages understanding what some programmer was thinking a decade ago.
Doable with COBOL, doable with FORTRAN, doable with BASIC, doable with C. not so doable with C++ and not at all with FORTH.
I am working with large projects. sometimes hundreds of man years of code. Banks, Insurances, IRS, Post Office. That is where COBOL still runs and does well. COBOL is the opposite of FORTH, the most verbose language you can imagine. But quite clear for even a non programmer.
COBOL:
multiply SINGLE-PRICE by COUNT-UNITS giving TOTAL-AMOUNT
the need to comment anything quite vanishes - you can show that to your tax-accountant and he can say yes/no
C/algol-like languages:
TOTAL_AMOUNT = SINGLE_PRICE * COUNT_UNITS
already backwards, one can not really read it to some non-programmer but some tax-accountant would still understand it and say yes/no.
SINGLE_PRICE R? COUNT_UNITS R? * TOTAL_AMOUNT W!
well - might not be FORTH, but could be.
the readability is low on this one.
And that is the reason that FORTH never made it into a main-stream used language. Forth is not a computer language at all it is a generator for a project specific language.
Once done with your project-specific language you can write stuff like
LEDPOWERSWITCH ON 500 MS LEDPOWERSWITCH OFF
might be
ON LEDPOWERSWITCH 500 MS OFF LEDPOWERSWITCH
which is quite readable as long as you are aware and in the known about the definitions of LEDPOWERSWITCH, ON, OFF and MS.
But if you look them up you find weird code like shown above with TOTAL_AMOUNT
The Basic Idea of a Domain Specific Language is not wrong, even MS tried to push that to us programmers, but it never stuck on the wall independent on how often they were throwing it at it.
It is about reusability and readability and that is why I think FORTH is not a main-stream language.
TAQOZ in ROM could have been a nice Language for a I/O controller, right out of the box, but Peter never developed it like that, he just wanted a complete FORTH in ROM, but then advised me to NOT use the ROM but load the newer versions into RAM.
Well - sorry when I come over rude -, but WHY is it in ROM when one should not use it?
Mike
That is essentially what I did with POS terminals decades ago, nice and simple. Just imagine the digits being entered by the keypad and the PRICE, QTY, and TOTAL words as well as the decimal point being tied to a key on the keyboard, and basically that is how it worked and also the sequence that you would expect the operator to punch it all in by. Forth just soaked it up without any fuss.
As for "ON LEDPOWERSWITCH 500 MS OFF LEDPOWERSWITCH" I would never have such long verbose COBOL type names
If you have had a look at some of my code you will probably find stuff like "ON LED" or "ON STAT LED" or "RED STAT LED" etc. I think that form is easy to read but the trick is to know which word goes with which, which can be a bit hard if it is jammed onto a single line with everything else. That's where I like to use extra spaces if I do or else leave leave it on its own line.
I think Domain Specific Language does exist in many languages, it's just that they call it a library function, but the problem with the library besides the learning curve for each one, is that it either does what you want or doesn't, and you don't have the source.
But you are certainly being a bit harsh about TAQOZ in ROM because if you were in my position you would have been aware that you are working with memory limitations, time limitations, and documentation (lack of) limitations. Whatever I did the first time had to work but it was really awkward to test the reset sequence in FPGA since everything was lost when it was reset. Even Chip took time to appreciate that we really needed a special FPGA version that could emulate a mask ROM so that we could reset the P2 and not lose the ROM. Of course a power-up test was impossible. But that was all last minute stuff and we worked through many nights testing and squeezing. The revision was mainly to fix and test any small bugs and I made up special hardware for my CVA9 to plug into so I could check it, in fact I was the only one who could check it since Cluso99 lost his FPGA and Chip didn't have an external SD card setup etc.
Once that task is done, why not use the spare ROM for something else useful ? Many more would complain if there was ROM left unused !
End result is you get something very useful and flexible, and you can do rapid tests using TAQOZ, but if you want full horsepower, of course you load a version larger than would fit in ROM.
That's engineering.
I do agree that the end result of a FORTH based Domain Specific Language is perfect to use. And I do also understand that you had not enough time and space (!) to fit into the ROM.
And absolutely sure TAQOZ is your creation and you are changing it constantly to adapt to new challenges. But that is exactly the problem. I just build those two images - hmm- maybe 2-3 weeks ago?
Now they are pretty obsolete, since kernel changed, .FTH's changed, how to put something in the OBEX when the words are changing constantly?
That is why I wanted to use the existing (or new) Rom, but - hmm - it is more easy to compile from source then patching the ROM. With above mentioned problems of hundreds of different versions after 10 years, but I want to go back to the ROM version as soon as we can get new chips.
The Rom stays the same.
I was able to mend TAQOZ and FastSpin Binaries together connected to a mailbox. This basically does allow a FastSpin compiled program to use TAQOZ on its own P2 Chip like a TAQOZ controlled second P2 Chip over serial. If you need more pins add a second P2D2 or whatever, the interface is the same, TAQOZ ROM + your loaded extensions or as it is.
Does the current new TAQOZ in ROM read any autoexec.fth if found on SD?
Mike
Mike
I think this is the best use of TAQOZ in ROM. Can be described. Can have samples that will work as long as the ROM stays the same.
One can attach any MC or PC to the P2-extender and send TAQOZ definitions and commands over after reset.
Those TAQOZ-Scripts-For-Rom can be shared as Text and send via serial after bootup and autobaud.
And that is the only way TAQOZ in ROM makes sense to me.
Mike
You wanted to do things with ROM TAQOZ that it was never designed to do for a few reasons, mainly time and space.
Therefore Peter (and I) suggested since you needed to load your own code from somewhere, you would be better off loading a more thorough version of TAQOZ too. If you don’t want extra features, then you can use a stable and frozen TAQOZ - you just dont change TAQOZ. IMHO you are overthinking you own problem.
Now TAQOZ in ROM was, and still is, designed to just test the P2 chip before any code is loaded. It does this nicely. Peter gave a number of 1 liners such as “lsio”.
When we received the first boards (Peter assembled the first few after Parallax assembled their first board on Peters P2D2 pcb) the first thing I did was boot up into my debugger/monitor because I knew that better than TAQOZ. Once i has that running, rather than load any code next, I jumped into TAQOZ and ran some of Peters one liners.
This gave me confidence that the P2 was alive. Then i tested downloading programs, and then the SD.
Those of you who received the P2-EVAL were a few weeks behind those with P2D2 (about 5 of us). We has verified that the P2 basics were running by then, so TAQOZ was perhaps not quite so relevant. But TAQOZ provides the minimum basis to test a non-functioning board.
Yes - hacking the ROM was my only chance to use TAQOZ in ROM as extender. I just have one P2. Sadly.
When they go out all this trouble is not needed.
Once connected serial to a P2 with booted ROM TAQOZ you are fine. Basically no need for SD or FLASH. Reset, autobaud, send definitions of new words if needed and then just talk to it.
One main P2 to do the HMI and lots of others running TAQOZ scriptlets which can be shared since based on the words in ROM. TAQOZ itself is very fast. I am sure that we will soon have some examples to say run servos, run peters RS434 network, Midi extender or whatever.
And there a Domain Specific Language really makes sense. Once written in TAQOZ it can be used from any other Board/MC/PC. Reset P2, send autobaud, escape to TAQOZ send definitions and go.
Its just serial text to send at reset and you are done. That extender P2 would not need flash or SD, it just boots serial into TAQOZ and gets spoon-fed after reset.
And that is what is possible if you have multiple P2s.
I am just fighting to test this with one P2.
Mike
Besides all these things I also design and build the hardware and write high level software etc. There's even a FAT32 formatter that works with any size card. So many many things, but always it is that one little thing that someone else sees.
So it seems, because of some power issues with VIO, we are going to see another run (P2v3). Does that mean there is a chance that your newer/better TAQOZ will have a chance to be updated in v3?
This semiconductor fabrication is a bit out of my league, but I would think that updating ROM for a new batch of chips would be pretty trivial.