Goodo Jim, that's encouraging! I'm partly doing it as a training thing to get to know many more words than I currently know. There's a lot tucked away in Tachyon.
Saw a Spyder just in the last week - very neat - and stable round corners in that configuration.
I used to ride bikes, but have a bad back these days. The Lomax is good for chatting enroute, you don't wear the bike clobber and there's good storage. It's happiest around 45 mph being low geared, but I occasionally take it up to the heady heights of 60 when I'm by myself. It does tend to skip around at higher speed if the road is uneven, so I don't push it like some do. Not bad for a 600cc flat twin of ancient design! What about a Blackjack Zero? They're rare, out of my price range and the designer has retired, so no more kits being produced - but quite a thrill I'm sure and a better design than the tiny Morgan three wheeler.
How does the word TRAP work, please? The syntax appears to be TRAP <name> <to> - is it's purpose to execute <name> in front of every call to <to> for debug purposes? I can crash tachyon, but not much else happens.
REVECTOR / REDEFINE works just fine.
How does the word TRAP work, please? The syntax appears to be TRAP <name> <to> - is it's purpose to execute <name> in front of every call to <to> for debug purposes? I can crash tachyon, but not much else happens.
REVECTOR / REDEFINE works just fine.
I can't remember
I had to look up my source and I can't seem to remember putting it in there and what Imay have used it for, would you believe?
Now looking at this code:
--- oldcode trapcode
pri trap NOP NOP ;
pre TRAP ( name to -- ) [C] ' [C] ' GRAB ' trap 2+ W! DUP W@ ' trap W! ' trap SWAP W! ;
The first two [C] ' simply force the compilation of the code address of a word in the stream (those two following) and then these values are GRABd back out of compilation and back onto the stack (just executes the compiled code up to this point).
Then we store the code address of the 'to' word into the second instruction of "trap". After that the DUP makes a copy of the old "name" address and reads its first instruction to back it up into the first instruction of "trap".
Finally the address of "trap" is stored into the first instruction of the target "name". When "name" executes then the first instruction will point to "trap" which will execute the backed up instruction that normally would have been executed, and then executes the "to".
So if I wanted to trap every time EC! was called which writes a byte to the EEPROM, and print the address and the byte on a new line before continuing, I could do this:
pub PRTEC! CR DUP .WORD SPACE OVER .BYTE ;
TRAP EC! PRTEC!
Now the first instruction in EC! points to PRTEC! which helps debug anything that gets written to the EEPROM using EC!, yet EC! continues as normal.
Thanks Peter, I see that working now with some test words. Must have been finger trouble or some corruption in my system. I'll add the syntax to the glossary overhaul.
One weakness in Forth is that (say) I want to write a word in assembly rather than forth. An assembler has to be loaded, then the new words can be written using it. However, we now have an unwanted asssembler taking up space, trapped in place by the new word(s). Have people devised fixes for this issue, where you want a section of code-producing code to run temporarily and then be forgotten again, leaving just the code they produced? I notice the work done with the outer interpreter, whereby if a dictionary search fail, then a further search is made on the SD card to run a file of the same name. That would seem to provide a basis for the above, where programs are loaded and then erased from memory after use.
With the P1 it doesn't make much sense trying to implement the assembler on top of all the other code, and all in less than 32k. Besides, you can't run code out of hub on the P1. But I do have RUNMODs which are short snippets of precompiled code that get loaded into part of the cog. There's also the ROMs which are precompiled cog images stored in upper EEPROM that can be loaded by name into a cog.
Anyway, my main aim with Tachyon was to avoid this whole coding in assembler at the application level and just make Tachyon fast in the first place with lots of low level support built-in. Now, the P2, that's another story.
The glossary for 5v7 is nearly done. Will post soon.
I've followed a fast autonomous 32 channel multitasked forth machine on an fpga for many years - the N.I.G.E. machine. The complete design is here https://github.com/Anding/N.I.G.E.-Machine. 'Resources' contains two very clear documents to get going. There are youtube videos introducing it too. It runs at close to 50 Mforth primitive instructions/s. Sadly, the development board it runs on is many hundreds of dollars. Why are the bigger fpgas so expensive - is the yield low or something, or is it just marketing policy? I have run the early version on a Nexys 2 board and programs ran very well and fast. The program editor that loads from sd card was good too. The aim was you could add your own custom logic as memory mapped periperals, very useful for high speed measurement and control. Noting its application field overlaps Propeller, anyone else tried this? - Also there maybe useful stuff to learn from.
Working out all the features of WWORDS for the glossary. I'm stumped by the following:-
What's the difference between the words shown cyan, versus those shown yellow, please?
What does the 3rd number show before each word name, please?
I've also figured out that:-
1. Immediate words are shown in BOLD
2. 'pri' words are coloured red
3. 'pub' words are coloured green
4. Words defined with 'module' are bold red
5. WWORDS G would show all words starting with G etc. WWORDS <cr> shows all words
As always Bob, I have to check to remind myself. Just as well somebody is documenting this
The 3rd number printed is the key as this represents the 3-bit attribute field in the count byte of dictionary entry.
Bit 7 is an immediate or preemptive attribute
Bit 6 is a private word
Bit 7&6 together represents this entry as a module header.
So the valid values for the 3-bit attribute field are:
0 public definition
1
2 private (can be removed by RECLAIM)
3
4 Preemptive immediate word executes - normally to read in more words from the stream
5
6 Module header
7
Obviously this means names are limited to 32 characters which is about twice as long as I'd recommend anyway, are bit 5 is not really used but may be in V6 where I may add vocabularies and link fields.
Thanks Peter, all included. Here's the glossary of Tachyon 5V7 words - a little rough still but much more current than it was. All corrections and alterations welcome. I will just replace these files after any upissue.
Version 1.4 - New column for pub,pri,pre and mod added + all the private words are now in a separate section at the back, so you can ignore 'em if you like
Many thanks @bob_g4bby. Great work. This is to become my main "go to" glossary for the coming weeks for sure, plus of course the source files. I didn't realize it's so much packed into Tachyon in its current state until this glossary of yours. Kudos to Peter for all the code.
If Easyfile is loaded, here's a little word to turn on automatic search for a 'batch file' on SD card if a word is not found in the dictionary:-
--- Extension to dictionary search to include finding and running files on SD card
pub BATCHFILE ( on/off -- ) --- Enable or disable SD card search for unknown dictionary words
IF
' FRUN undef W!
ELSE
0 undef W!
THEN ;
--- Usage:-
ON BATCHFILE --- Enables batch file search on the SD card
--- Now just type any forth file that you know compiles OK - don't forget the file extension if it has one. The file should load just like you've typed it in
OFF BATCHFILE --- Disables batch file search on SD card
Hi Maciek, good to hear you'll be using the glossary. I'm using it myself and will update it as I spot mistakes or need extra information. I've just spotted it would be useful to add examples of the CASE and SWITCH words. So check the version number in my original post against the version number at the back of your copy.
Hi Bob, the copy I downloaded has v1.0 stated on the last page. I did download the one from above again marked as v1.1 (pdf) but it is the same file (?) and also has v1.0 on the last page clearly stated. Have not checked word by word but chances for it to be different are slim. Maybe I missed something...Anyway, this is of a great value to me. Speeds things up and I am really late to the game so time matters.
I think it deserves a separate thread or to be posted at Peters sf Tachyon project site and not be buried here.
I've just uploaded v1.2 for both files, see if you can see those - may need to wait a while? - else I may need to check what the forum is really doing. It seems to allow me to delete the old files and upload new ones.
bob,
Thanks for taking on the updating of the Tachyon Glossary. I hope that we can get peter link this into his so there is a common location for all. I just downloaded v1.3 @ 5:30 AM Arizona time 9/29/20.
Jim
Thanks Bob, I've had a quick look at it earlier on but I've been busy organizing boards and parts and everything so we all can have a good play with the P2. Until I get them back and test it, I won't rest.
However looking at the glossary perhaps it is a bit too exhaustive since it also list private words that would normally be stripped and aren't meant to be accessed outside of those routines that access them. Perhaps when we get a chance that glossary could have the important words first, then followed by a list of lesser words that might never ever be used directly, and have those words in some subdued color or format. That way the glossary doesn't look so intimidating with 22 pages of words
In fact, if we only had the words that we would commonly use in the first few pages, then all the other words etc, then it would be a lot easier to look up a handful of file words for instance than two and a half pages of routines and variables.
Well, one day when you are not too busy being out and about cruising around the countryside in your Lomax, how about we have a quick chat and a catch-up. I know, I know, I'd prefer to do that over a pint myself too
Good suggestions - 'you can't see the wood for the trees' is an old saying. I definitely want to keep the private words in the glossary, (a) because WORDS and WWORDS list them and (b) because the user may want to extend a module. The public and private words do need to be sorted from one another. To kick that off, I'm adding a column that can be set 'pub', 'pri', 'pre' and 'mod' (module) to allow the word processor to do the sorting for me. I'll do some visual stuff to colour code the pub versus pri as well. Let me upload the result and see what you think. Shouldn't take long. After that, let's have a skype. I've been reading the mail on your many hardware designs - that audio codec idea caught my attention for software radio use + all the best with your P2D2 commissioning.
Version 1.4 of the Tachyon Glossary makes corrections + the private words (that aren't useful unless modifying the EXTEND or EASYFILE modules) have been placed at the back. There's a new column showing public, private, preemptive and module marker status of words.
Version 1.4 of the Tachyon Glossary makes corrections + the private words (that aren't useful unless modifying the EXTEND or EASYFILE modules) have been placed at the back. There's a new column showing public, private, preemptive and module marker status of words.
Thanks for getting this organized Bob. I was just thinking about how you updated the files a few posts back and maybe you might want to start a new thread just so you can update the first post with files. You don't have to but it certainly would make it a lot easier to find as well as having thread devoted to the glossary. Alternatively, maybe it could be uploaded to SF?
Got it. Great job. Many thanks for that.
It shouldn't be impossible to make this glossary somehow available from within Tachyon serial console provided the SD card is present on the system, no ?
Got it. Great job. Many thanks for that.
It shouldn't be impossible to make this glossary somehow available from within Tachyon serial console provided the SD card is present on the system, no ?
Good ideas, chaps. I'll start a new thread with the glossary files at the top, like you suggest - very little search needed then.
Having the glossary on the SD card had occurred to me. The tables import into Calc very easily, another column is needed to to take the section names (if needed) but that's very quick. Then Calc save a comma delimited file which would go on the card ...
I started a series of help files that were broken up into sections so that not only the word you were after but also those associated with it were listed. You can have help lookup the index which lists the word or the whole section. Of course this could be put all into one file but the sections made it easier to maintain and I think that it would be possible for source code to create help files as it is loaded in too. The help files were all .txt files so they were standard text but were all together in a HELP folder located in the root directly.
Comments
I am really looking forward to your updates.
Jim
Lomax looks like a more comfortable modern day Spyder:
https://can-am.brp.com/on-road/us/en/models.html
I used to ride bikes, but have a bad back these days. The Lomax is good for chatting enroute, you don't wear the bike clobber and there's good storage. It's happiest around 45 mph being low geared, but I occasionally take it up to the heady heights of 60 when I'm by myself. It does tend to skip around at higher speed if the road is uneven, so I don't push it like some do. Not bad for a 600cc flat twin of ancient design! What about a Blackjack Zero? They're rare, out of my price range and the designer has retired, so no more kits being produced - but quite a thrill I'm sure and a better design than the tiny Morgan three wheeler.
REVECTOR / REDEFINE works just fine.
I can't remember
I had to look up my source and I can't seem to remember putting it in there and what Imay have used it for, would you believe?
Now looking at this code:
The first two [C] ' simply force the compilation of the code address of a word in the stream (those two following) and then these values are GRABd back out of compilation and back onto the stack (just executes the compiled code up to this point).
Then we store the code address of the 'to' word into the second instruction of "trap". After that the DUP makes a copy of the old "name" address and reads its first instruction to back it up into the first instruction of "trap".
Finally the address of "trap" is stored into the first instruction of the target "name". When "name" executes then the first instruction will point to "trap" which will execute the backed up instruction that normally would have been executed, and then executes the "to".
So if I wanted to trap every time EC! was called which writes a byte to the EEPROM, and print the address and the byte on a new line before continuing, I could do this: Now the first instruction in EC! points to PRTEC! which helps debug anything that gets written to the EEPROM using EC!, yet EC! continues as normal.
Anyway, my main aim with Tachyon was to avoid this whole coding in assembler at the application level and just make Tachyon fast in the first place with lots of low level support built-in. Now, the P2, that's another story.
I've followed a fast autonomous 32 channel multitasked forth machine on an fpga for many years - the N.I.G.E. machine. The complete design is here https://github.com/Anding/N.I.G.E.-Machine. 'Resources' contains two very clear documents to get going. There are youtube videos introducing it too. It runs at close to 50 Mforth primitive instructions/s. Sadly, the development board it runs on is many hundreds of dollars. Why are the bigger fpgas so expensive - is the yield low or something, or is it just marketing policy? I have run the early version on a Nexys 2 board and programs ran very well and fast. The program editor that loads from sd card was good too. The aim was you could add your own custom logic as memory mapped periperals, very useful for high speed measurement and control. Noting its application field overlaps Propeller, anyone else tried this? - Also there maybe useful stuff to learn from.
What's the difference between the words shown cyan, versus those shown yellow, please?
What does the 3rd number show before each word name, please?
I've also figured out that:-
1. Immediate words are shown in BOLD
2. 'pri' words are coloured red
3. 'pub' words are coloured green
4. Words defined with 'module' are bold red
5. WWORDS G would show all words starting with G etc. WWORDS <cr> shows all words
The 3rd number printed is the key as this represents the 3-bit attribute field in the count byte of dictionary entry.
Bit 7 is an immediate or preemptive attribute
Bit 6 is a private word
Bit 7&6 together represents this entry as a module header.
So the valid values for the 3-bit attribute field are:
0 public definition
1
2 private (can be removed by RECLAIM)
3
4 Preemptive immediate word executes - normally to read in more words from the stream
5
6 Module header
7
Obviously this means names are limited to 32 characters which is about twice as long as I'd recommend anyway, are bit 5 is not really used but may be in V6 where I may add vocabularies and link fields.
Version 1.4 - New column for pub,pri,pre and mod added + all the private words are now in a separate section at the back, so you can ignore 'em if you like
I think it deserves a separate thread or to be posted at Peters sf Tachyon project site and not be buried here.
I've just uploaded v1.2 for both files, see if you can see those - may need to wait a while? - else I may need to check what the forum is really doing. It seems to allow me to delete the old files and upload new ones.
now's good.
Ver. 1.2 at the top of the versions. Will play with it tonight. Must've been some forum delay or something.
Thanks for taking on the updating of the Tachyon Glossary. I hope that we can get peter link this into his so there is a common location for all. I just downloaded v1.3 @ 5:30 AM Arizona time 9/29/20.
Jim
However looking at the glossary perhaps it is a bit too exhaustive since it also list private words that would normally be stripped and aren't meant to be accessed outside of those routines that access them. Perhaps when we get a chance that glossary could have the important words first, then followed by a list of lesser words that might never ever be used directly, and have those words in some subdued color or format. That way the glossary doesn't look so intimidating with 22 pages of words
In fact, if we only had the words that we would commonly use in the first few pages, then all the other words etc, then it would be a lot easier to look up a handful of file words for instance than two and a half pages of routines and variables.
Well, one day when you are not too busy being out and about cruising around the countryside in your Lomax, how about we have a quick chat and a catch-up. I know, I know, I'd prefer to do that over a pint myself too
Good suggestions - 'you can't see the wood for the trees' is an old saying. I definitely want to keep the private words in the glossary, (a) because WORDS and WWORDS list them and (b) because the user may want to extend a module. The public and private words do need to be sorted from one another. To kick that off, I'm adding a column that can be set 'pub', 'pri', 'pre' and 'mod' (module) to allow the word processor to do the sorting for me. I'll do some visual stuff to colour code the pub versus pri as well. Let me upload the result and see what you think. Shouldn't take long. After that, let's have a skype. I've been reading the mail on your many hardware designs - that audio codec idea caught my attention for software radio use + all the best with your P2D2 commissioning.
Thanks for getting this organized Bob. I was just thinking about how you updated the files a few posts back and maybe you might want to start a new thread just so you can update the first post with files. You don't have to but it certainly would make it a lot easier to find as well as having thread devoted to the glossary. Alternatively, maybe it could be uploaded to SF?
It shouldn't be impossible to make this glossary somehow available from within Tachyon serial console provided the SD card is present on the system, no ?
Absolutely! Now, that's an exercise for you Bob
Having the glossary on the SD card had occurred to me. The tables import into Calc very easily, another column is needed to to take the section names (if needed) but that's very quick. Then Calc save a comma delimited file which would go on the card ...