MJB - You mentioned a long time back that you had a tachyon 'language definition' for Notepad++
Any chance of a copy please?
Regards, Bob
yes please!
yes - really long ago.
I will have a look when I am at the other computer tomorrow
@"Shawn Lowe" , @bob_g4bby
OK - this is from 2014-08-10
--- just testet it with EXTEND and looks ok.
Tachyon has changed a bit since then.
So you might want to go through the keywords lists and update them.
This can easily be done directly from Notepad++ menu Language/user defined language/Define your language
after putting this file as NPP Tachyon Style File.xml in the \Notepad++\userDefineLangs folder.
CORRECTION: you need to use IMPORT for the XML, that was created with EXPORT
I you make a better / newer version please repost here for everyone.
p.s.: if you want to change it - it is good to have a large forth file open - I recommend EXTEND. Then you can immediately see the changes you make.
actually I am just at it ;-)
I have a highlighter for VS Code that I modified from a general Forth grammar if you want it. I keep it in my Tachyon Dropbox but I will move it to a more easily accessed folder in the root under utilities.
I'm looking to get started with Tachyon with my QuickStart board while I am waiting for my RetroBlade2 and P2D2 to come in. Do you have a binary I could load up?
Alternatively, I have:
DemoBoard
PropDongle
ProtoBoard USB
Initially I just want something that I can play with over usb/serial without dependence on a SDcard.
I downloaded the 500+MB of Peter's "The LOT" link above, but that is a bit of bewildering overkill to figure out a simple way to get started. I looked at sourceforge, and was similarly confused as to where to start.
I'm looking to get started with Tachyon with my QuickStart board while I am waiting for my RetroBlade2 and P2D2 to come in. Do you have a binary I could load up?
Alternatively, I have:
DemoBoard
PropDongle
ProtoBoard USB
Initially I just want something that I can play with over usb/serial without dependence on a SDcard.
I downloaded the 500+MB of Peter's "The LOT" link above, but that is a bit of bewildering overkill to figure out a simple way to get started. I looked at sourceforge, and was similarly confused as to where to start.
Any help appreciated.
There are a lot of links in my sig but you can use this copy here.
There are a lot of links in my sig but you can use this copy here.
Yes, there are. That is the problem, information overload and not a clear place to start for someone with no experience with it.
Thanks for the binary, but proploader won't load it. It just gives "internal error". I'm guessing it is too big to fit in ram so proploader just dies with a poor error description. Is that a .eeprom file instead?
I would like to dump the contents of the eeprom that are there first so I can put it back later, and was going to use your message on ROM dumping to do it https://forums.parallax.com/discussion/171064/rom-dumping. Do you have a binary to get me up and running in ram so I can dump the eeprom with that?
I just tried this binary with BST and also Proptool, so I'm not sure what loader you are using. However if the loader has some kind of limitation then maybe this 32k version of the binary might work.
I just tried this binary with BST and also Proptool, so I'm not sure what loader you are using. However if the loader has some kind of limitation then maybe this 32k version of the binary might work.
Yes, thanks! That worked great. Now I just need to learn Tachyon. Seems pretty cool! The stack looks upside down compared to my HP calculator.
If you are using an ANSI terminal then Tachyon will detect this at reset and switch to ANSI mode for bold and colors.
Use WORDS for a plain text listing of the dictionary or use WWORDS for a formatted colored listing.
Unlike other Forth's, whatever you type in interactively is compiled word by word in a temporary area, so you can't backspace to the previous word (hit esc to cancel the whole line), and once you hit the enter key it will execute the compiled code. Because it is compiled it means that you can use all the stuff that you normally would inside a definition such as DO LOOP IF THEN etc. Try this:
$7F $20 DO I EMIT LOOP
Check the wiki and blogs on my Source Forge page as well as the other links for some more intro stuff.
Use number prefix to force hex $F000 or binary %1011 otherwise the default is decimal.
If you are not sure what is going on it is a good idea to do some debugging.
Make the loop run shorter so you are not overwhelmed.
Then put some .S print stack in there
As far as I recall Tachyon has different stacks for program, loops, and something else. When you remember the HP45 calculator, the stack depth was only 4 levels, but you could do a lot with those four places. The same is true for Tachyon, I think, 3 to 4 levels can be accessed extremely fast and more space is available to grow the stack, but then the speed will go down as the addressing mechanism is more complicated.
Anyway it is a good practice to make heavy use of the stack but limit the actual stack depth to the minimum.
If much stack is needed, the programming style should be revised.
@hinv
While there are limits to all things in life, they are not the same thing as limitations.
Same too with the stack in that you could fill the largest stack just as easily with a simple loop, yet the Tachyon stack is large enough if you are not trying to fill it. Don't misuse it, just use it and it will be fine.
From a technical angle though the top of the stack is implemented partly as 4 fixed cog registers since the Prop does not have instructions that efficiently index into cog or hub memory, nor does it have any stack instructions. This allows fast and direct operation to fixed registers without having to calculate the address of each item for every access. As data is pushed onto the stack the 4th register is pushed onto a software stack implemented in cog memory, the same cog memory that must hold working registers and the Tachyon kernel. All kernel operations are limited to these 4 registers which is more than sufficient, plus code should be factored anyway into smaller bite size pieces with minimal and clearly defined stack usage.
This is the code to push a value onto the data stack.
PUSHX movd _stkpsh_,stkptr ' update push index from pop index
add stkptr,#1 ' update pop index
_stkpsh_ mov datastk,d ' save last fixed stack reg - stack grows in cog memory
mov d,c ' ripple push the cog stack registers (4)
mov c,b
mov b,a
mov a,X ' replace tos
mov acc,#0
Note that the first three instructions implement a software stack but need self-modifying code to achieve indexing which most CPUs achieve with a single instruction, as does the P2. The next four instructions are a brute force register ripple push and finally I maintain an accumulator that is cleared after every instruction that simplifies a number of operations, and this is a good place to clear it.
Not having to work out where the data is makes most operation very simple and fast. Have a look at fetching from memory:
' @ ( addr -- long ) Fetch a long from hub memory
FETCH rdlong a,a
jmp unext
But in view of the cost of actually pushing and popping I try to avoid that as much as possible which is why there are a lot of instructions that do not push/pop.
then search on and you will find interesting comments
if you want to run the Tachyon interpreter in a second COG you can specify the stack size. I never tried to extend the stack in the main COG.
EDIT: no stack is fixed - but you have to specify space for the task registers
@hinv
While there are limits to all things in life, they are not the same thing as limitations.
Same too with the stack in that you could fill the largest stack just as easily with a simple loop, yet the Tachyon stack is large enough if you are not trying to fill it. Don't misuse it, just use it and it will be fine.
From a technical angle though the top of the stack is implemented partly as 4 fixed cog registers since the Prop does not have instructions that efficiently index into cog or hub memory, nor does it have any stack instructions. This allows fast and direct operation to fixed registers without having to calculate the address of each item for every access. As data is pushed onto the stack the 4th register is pushed onto a software stack implemented in cog memory, the same cog memory that must hold working registers and the Tachyon kernel. All kernel operations are limited to these 4 registers which is more than sufficient, plus code should be factored anyway into smaller bite size pieces with minimal and clearly defined stack usage.
This is the code to push a value onto the data stack.
PUSHX movd _stkpsh_,stkptr ' update push index from pop index
add stkptr,#1 ' update pop index
_stkpsh_ mov datastk,d ' save last fixed stack reg - stack grows in cog memory
mov d,c ' ripple push the cog stack registers (4)
mov c,b
mov b,a
mov a,X ' replace tos
mov acc,#0
Note that the first three instructions implement a software stack but need self-modifying code to achieve indexing which most CPUs achieve with a single instruction, as does the P2. The next four instructions are a brute force register ripple push and finally I maintain an accumulator that is cleared after every instruction that simplifies a number of operations, and this is a good place to clear it.
Not having to work out where the data is makes most operation very simple and fast. Have a look at fetching from memory:
' @ ( addr -- long ) Fetch a long from hub memory
FETCH rdlong a,a
jmp unext
But in view of the cost of actually pushing and popping I try to avoid that as much as possible which is why there are a lot of instructions that do not push/pop.
as so many times before - while I compose my answer message researching and relearning about the Tachyon internals you write an essay :-).
EDIT: I should sleep now instead of writing wrong things ... but here HUB is probably what you wanted to say
As data is pushed onto the stack the 4th cog register is pushed onto a software stack implemented in cogHUB memory, the same cogHUB memory that must hold working registers for the Tachyon kernel.
wasn't the datastack in hub in one earlier version of Tachyon ???
Each cog had its own memory and there is no delay accessing it so therefore the tachyon stack is implemented in cog memory. When you run another tachyon cog there is therefore no need to allocate some chunk of slow hub ram. To index into cog memory requires the use of self modifying code as in the first three instructions of the PUSHX code.
@mjb - Yes, V3 saved to hub RAM if the depth went beyond the 4 internal registers. This was ok but made it a pain when other Tachyon cogs were started up as separate stack space had to be allocated in hub RAM. Now the data and return stacks are in cog ram although my special loop/branch stack overflows into hub RAM whereas TAQOZ has plenty of room in LUT ram for all these stacks.
Think of tachyon as the construction set with which you make your own application-specific language. That includes any special data or code types you need, including larger stacks if that be essential. See CREATE ... DOES> in the book 'Starting Forth', maybe after some experience has been gained with forth programming.
Also - a 20 element stack might seem tiny, but that has to be re-assessed after writing a few applications. Spreading the application across cogs also reduces the reqt. on any one stack.
Comments
Sounds great! Did you forward these files to Bob?
Jim
Any chance of a copy please?
Regards, Bob
yes please!
yes - really long ago.
I will have a look when I am at the other computer tomorrow
@"Shawn Lowe" , @bob_g4bby
OK - this is from 2014-08-10
--- just testet it with EXTEND and looks ok.
Tachyon has changed a bit since then.
So you might want to go through the keywords lists and update them.
This can easily be done directly from Notepad++ menu Language/user defined language/Define your language
after putting this file as NPP Tachyon Style File.xml in the \Notepad++\userDefineLangs folder.
CORRECTION: you need to use IMPORT for the XML, that was created with EXPORT
I you make a better / newer version please repost here for everyone.
can'T see how to attach a file here ... strange
so I put it inside a CODE block
p.s.: if you want to change it - it is good to have a large forth file open - I recommend EXTEND. Then you can immediately see the changes you make.
actually I am just at it ;-)
Alternatively, I have:
DemoBoard
PropDongle
ProtoBoard USB
Initially I just want something that I can play with over usb/serial without dependence on a SDcard.
I downloaded the 500+MB of Peter's "The LOT" link above, but that is a bit of bewildering overkill to figure out a simple way to get started. I looked at sourceforge, and was similarly confused as to where to start.
Any help appreciated.
Yes, there are. That is the problem, information overload and not a clear place to start for someone with no experience with it.
Thanks for the binary, but proploader won't load it. It just gives "internal error". I'm guessing it is too big to fit in ram so proploader just dies with a poor error description. Is that a .eeprom file instead?
I would like to dump the contents of the eeprom that are there first so I can put it back later, and was going to use your message on ROM dumping to do it https://forums.parallax.com/discussion/171064/rom-dumping. Do you have a binary to get me up and running in ram so I can dump the eeprom with that?
Yes, thanks! That worked great. Now I just need to learn Tachyon. Seems pretty cool! The stack looks upside down compared to my HP calculator.
The top of the stack is the top and the bottom is the bottom.
If you are using an ANSI terminal then Tachyon will detect this at reset and switch to ANSI mode for bold and colors.
Use WORDS for a plain text listing of the dictionary or use WWORDS for a formatted colored listing.
Unlike other Forth's, whatever you type in interactively is compiled word by word in a temporary area, so you can't backspace to the previous word (hit esc to cancel the whole line), and once you hit the enter key it will execute the compiled code. Because it is compiled it means that you can use all the stuff that you normally would inside a definition such as DO LOOP IF THEN etc. Try this: Check the wiki and blogs on my Source Forge page as well as the other links for some more intro stuff.
Use number prefix to force hex $F000 or binary %1011 otherwise the default is decimal.
Anyway it is a good practice to make heavy use of the stack but limit the actual stack depth to the minimum.
If much stack is needed, the programming style should be revised.
While there are limits to all things in life, they are not the same thing as limitations.
Same too with the stack in that you could fill the largest stack just as easily with a simple loop, yet the Tachyon stack is large enough if you are not trying to fill it. Don't misuse it, just use it and it will be fine.
From a technical angle though the top of the stack is implemented partly as 4 fixed cog registers since the Prop does not have instructions that efficiently index into cog or hub memory, nor does it have any stack instructions. This allows fast and direct operation to fixed registers without having to calculate the address of each item for every access. As data is pushed onto the stack the 4th register is pushed onto a software stack implemented in cog memory, the same cog memory that must hold working registers and the Tachyon kernel. All kernel operations are limited to these 4 registers which is more than sufficient, plus code should be factored anyway into smaller bite size pieces with minimal and clearly defined stack usage.
This is the code to push a value onto the data stack. Note that the first three instructions implement a software stack but need self-modifying code to achieve indexing which most CPUs achieve with a single instruction, as does the P2. The next four instructions are a brute force register ripple push and finally I maintain an accumulator that is cleared after every instruction that simplifies a number of operations, and this is a good place to clear it.
Not having to work out where the data is makes most operation very simple and fast. Have a look at fetching from memory:
But in view of the cost of actually pushing and popping I try to avoid that as much as possible which is why there are a lot of instructions that do not push/pop.
just open Tachyon.spin and search for STACK
CON { *** STACK DEFINITIONS etc *** }
' Stack sizes
datsz = 32-4
retsz = 28
then search on and you will find interesting comments
if you want to run the Tachyon interpreter in a second COG you can specify the stack size. I never tried to extend the stack in the main COG.
EDIT: no stack is fixed - but you have to specify space for the task registers
as so many times before - while I compose my answer message researching and relearning about the Tachyon internals you write an essay :-).
EDIT: I should sleep now instead of writing wrong things ...
but here HUB is probably what you wanted to say
As data is pushed onto the stack the 4th cog register is pushed onto a software stack implemented in cog HUB memory, the same cog HUB memory that must hold working registers for the Tachyon kernel.
wasn't the datastack in hub in one earlier version of Tachyon ???
Don't you mean, "forth the you with be" ?
-Phil
Too verbose for Forth, it's almost Cobol. Now this is more Forth-like: where the ! is the store word, so store "Forth" in "you"