P1 is here to stay, or so I'm told, and unless sales figures drop dramatically thus forcing Parallax to cease production, I think it will continue to be used in many projects. I don't do fancy stuff like others here (games, video, sound) and for my current needs what P1 offers is fine.
I see a SD card addition useful mainly for the development purposes and for the actual device not so much, if at all. It'll be ages before my forth programs need more than 15 kilobytes of space. The P2, while highly desirable, would be an overkill in most cases, feature wise, not to mention the cost.
That said, I agree with you when you say "Given Peter's commitments with P2D2, we shouldn't expect him to do much on tachyon for some time, either." but I also think, when the time is right, some overhaul of Tachyon is needed and will happen.
And I am waiting for that P2D2 impatiently and then, even more impatiently, for the alike P1 module Peter mentioned some time ago.
When you consider that the P1 has 32k of memory total, and that while each cog has 2k which sounds like something extra, it has to use and be loaded from that 32k etc, then it is even more amazing that we can get so much in there as we do. From the early days we just wanted a P1 with more memory, a P1B, perhaps with few basic enhancements. Now we have the P2 but it's not a small chip, nor is it a single-chip, hence the reason for other small chips that do have the memory. But Tachyon P1 does have a future if the P1V implementation of it into a small and low-cost FPGA is successful. Then again I'd like to experiment and have a minicog in each pin or group of pins etc.
If all goes well my P2D2 boards and sundries will be here in a few days and I will be busy building up a tester. If I'm happy with the design and how the boards go together I will make up all I can with the stock I have but rather than ordering more parts at the moment I will get quotes on A&T from JLCPCB as they can also supply most of the parts from their LCSC division.
As you have seen, my designs are based on practical and commercial use, not educational nor hobbyist. Neither are they necessarily plug-in breadboard friendly although one can created a special breadboard JM style. My software is not purely for software purposes, but to run the hardware. My hardware is not ignorant of the software that runs on it either and even the layout reflects how I envisage the software will use it. P2D2 is a holistic design and while it may also look "pretty", it is entirely practical and versatile. At 2.4sq" including connectors it is a very compact design especially considering it is not a "bare-bones" design, but is fully fleshed out, and even more so with the P2PAL "layer" added. But this thread is about Tachyon
(I might repost some of the P2D2 info in its own thread)
More thinking aloud on the memory constraint thing - the 32k of ram in the case of P1. Tachyon development has always been about squeezing more into that space. An astonishing amount of complex functionality has been made to fit.
A product designed using tachyon consists of the application code and the 'runtime' code. Ideally, all of the runtime code is called by the application, and no code is left uncalled. This is efficient, in the sense that the most memory is made available for application data. In nearly all forth systems, it's also unachievable.
I notice that Charles Moore was very keen on the principles of 'less is more' and 'write it yourself'. This was reflected in the small size of the dictionaries in his forths. He minimised the size of the 'runtime' - with good reason - he often had much less than 32k of memory to work with. He also had a drive to reduce problems to the simplest level, which never left him.
If 'runtime' minimisation is a useful goal - and some might not agree - it begs the question: Just what tachyon words are essential to be able to write and deploy a product? If we look top-down, there would seem to be a small number of essential features necessary: Backup sticks out as an example. Without the word Backup or it's equivalent, you don't save the final application to EEPROM. So, given those essential words, what if we determined what words are essential versus what are not? We might use the machine to help, maybe with a 'dictionary crawler' that drilled down the words to determine all the dependencies.
Thus the tachyon dictionary might shrink to that which just produces a product and no more. On the other hand, the library folder would expand with various files of words that were taken out. Here, the designer could choose whether some of those words were needed for the product and put them in. At the moment, the system isn't so easy to prune back without inadvertently breaking stuff, as I've commented on in a previous post.
Disadvantages? Tachyon consists of 3 main files, the kernel, extend.fth and easyfile.fth. They would shrink + you'd have all the new files of 'extras'. Not quite so easy to find that 'must have' word.
Extending dictionary word search to an sd card, with auto-dependency is one way of fixing the issue. You can have as large lexicon as you like given the space there. It isn't as fast to compile as the all ram resident system that exists now, it just has to be fast enough?
I think that's the bucket we need to fill first before we need to find a bigger bucket. I did a lot of squeezing in various forms in V3 and it became counter-productive. I've always had the ability to have the SD card searched for a file that matched any words not found anyway, although I should probably check again how I did that. Once we have an SD card in the system it requires EASYFILE and that uses up more memory but at the same time we can leverage the huge storage capabilities of the card itself. Certainly the help files would be useful but the dictionary even completely reside in SD if need be. This makes more of the 32k available as code space which is obviously much more important. However tools and other debug functions could be loaded in as necessary.
As for Chuck I think he spends too much time polishing the Forth brass trying to making it as beautiful as possible but that doesn't always make it more usable or practical. The latest forays into Forth chips especially GA144, although much dated now, are so impractical. Sounds good, looks good, but I haven't seen one useful thing that can be done with it.
Tachyon is about being practical and useful. We can always do a small Tachyon with the same brevity as TAQOZ ROM if there is some advantage in that.
Please don't let me stop you though Bob, really. Discussion and arguments for and against stimulate lateral thinking. We are thereby forced to look at things through someone else's eyes and that adds a new angle. I'm not always convinced by my own arguments and I use them like questions too. So don't stop.
Hi, after some years I have now begun to work with Tachyon 5.7. (Several years ago I did use a previous version.)
In the last months I also did use Forth on other microcontrollers.
As I use other controllers too, I do value Forth-83 or Forth-94 standardisation. It is very nice to be able to have a look into some existing documentation and can rely, that a code snippet will work. We already had this discussion some time ago...
I think, that 5.7 has grown into a very good system!
I think, 16 bit wordcode is straight forward.
That you provide 5.7 as a binary for 80MHz with the extras, which you can FORGET, is a good way!
For future plans, my wishlist so far:
1. It should be able to be run without SD card.
2. Due to the memory constrains a reduced optional File System seems to be right. I think, a Forth block file system is a good compact compromise. See my other post.
3. A signed version of >> would be very good for fast scaling without a hardware divider. Already there: SAR
4. A version of W@ that preserves the sign of the word, would be very nice. Word variables are sufficient for many (most?!) things and conserve space.
5. I like and normally use value type variables with "to".
6. While many Forthers do rank them as not necessary, I really like local variables. They can improve readability very much. And if you code such things as string comparison $= , where you need several counters and pointers, local variables make this very much more easy and readable. However I don't think, that full blown ANSI-94 local variables are a way to go for P1. Instead I think, that there must be a way to declare them before a modified : , so that the dictionary can be used for their implementation. Even unnamed locals like a> and >a are helpful in my opinion.
7. An Assembler. I don't know, if this might be possible.
8. Dreaming: Some way to have a overlay memory range, where you can load and unload ( compile into that memory from eeprom or from SD-card ) utilities like a block editor or the assembler or ... So that you can use the assembler and unload it afterwards.
@"Christof Eb." said:
Hi, after some years I have now begun to work with Tachyon 5.7. (Several years ago I did use a previous version.)
In the last months I also did use Forth on other microcontrollers.
As I use other controllers too, I do value Forth-83 or Forth-94 standardisation. It is very nice to be able to have a look into some existing documentation and can rely, that a code snippet will work. We already had this discussion some time ago...
I think, that 5.7 has grown into a very good system!
I think, 16 bit wordcode is straight forward.
That you provide 5.7 as a binary for 80MHz with the extras, which you can FORGET, is a good way!
For future plans, my wishlist so far:
1. It should be able to be run without SD card.
already possible
Due to the memory constrains a reduced optional File System seems to be right. I think, a Forth block file system is a good compact compromise. See my other post.
great, so just don't load EASYFILE
and use your own
A signed version of >> would be very good for fast scaling without a hardware divider.
if you can write the PASM for it we can easily run it as LMM from HUB without disturbing the Kernel
A version of W@ that preserves the sign of the word, would be very nice. Word variables are sufficient for many (most?!) things and conserve space.
if you can write the PASM for it we can easily run it as LMM from HUB without disturbing the Kernel
I like and normally use value type variables with "to".
really constant constants ;-)
While many Forthers do rank them as not necessary, I really like local variables.
They can improve readability very much. And if you code such things as string comparison $= ,
where you need several counters and pointers, local variables make this very much more easy and readable.
However I don't think, that full blown ANSI-94 local variables are a way to go for P1.
Instead I think, that there must be a way to declare them before a modified : ,
so that the dictionary can be used for their implementation.
Even unnamed locals like a> and >a are helpful in my opinion.
there is a simple local variable module as comment in EXTEND
--- pop the n top stack elements to the local space, TOS => X1, TOS+1 => X2 ..
pub LOCAL ( n -- )
DUP 4* ( n bytes )
locals 2DUP + ROT <CMOVE
FOR I @X ! NEXT
;
--- pop and release emove n elements from locals, of no longer used )
pub RELEASE ( n -- ) DUP @X locals ROT 4* $40 SWAP - CMOVE ;
\ locals $40 ERASE \ Clean out the locals (easier for debugging)
}
An Assembler. I don't know, if this might be possible.
Peter wrote one long time ago
you find it in modules/PASM.fth
Dreaming: Some way to have a overlay memory range, where you can load and unload ( compile into that memory from eeprom or from SD-card ) utilities like a block editor or the assembler or ... So that you can use the assembler and unload it afterwards.
you can load source files that get compiled on load, and you can FORGET them after use.
loading precompiled source would require
1. saving definitions with references / dictionary ...
2. a kind of linker to put the loaded definitions in the right place in the dictionary and fix the internal references ...
There is a link to Peter Jakacki's drop box here and PASM.FTH can be found in \P1\V5\Forth, having downloaded the dropbox and unzipped to a working folder.
It doesn't seem to compile under Tachyon 5v7 though - MJB, can you say more? Do you have a working version of the assembler for Tachyon?
@bob_g4bby said:
There is a link to Peter Jakacki's drop box here and PASM.FTH can be found in \P1\V5\Forth, having downloaded the dropbox and unzipped to a working folder.
It doesn't seem to compile under Tachyon 5v7 though - MJB, can you say more? Do you have a working version of the assembler for Tachyon?
Cheers, Bob
Thanks, Bob, I wasn't aware, that the was a second source in addition to the sourceforge page.
I will have a look at it.
Christof
Dreaming: Some way to have a overlay memory range, where you can load and unload ( compile into that memory from eeprom or from SD-card ) utilities like a block editor or the assembler or ... So that you can use the assembler and unload it afterwards.
you can load source files that get compiled on load, and you can FORGET them after use.
loading precompiled source would require
1. saving definitions with references / dictionary ...
2. a kind of linker to put the loaded definitions in the right place in the dictionary and fix the internal references ...
not sure it would be worth it
unless you REALLY used all the resources ...
I am not sure, if I explained good enough, what I meant.
Normally, if you 1. load the assembler, 2. assemble for example the new word WS@ ( for signed word read ) and 3. forget the assembler, the new word would be lost. So the idea was to have some kind of 2nd parallel structure to the normal dictionary in an overlay buffer. Into this you could load the assembler ( or another tool ) and work with the normal dictionary. So if you FORGET the contents of the overlay buffer, you would still have the assembled word.
You would need A) a different interpreter/compiler, which scans both dictionaries and an additional :OL "compile into overlay buffer" instead of : . C) declare this overlay buffer somehow. It would be good, if the user could define its size.
I don't think, that this concept is a really new idea, as Moores multiuser Forths had to have multiple dictionaries for them together with a common one.
unless you REALLY used all the resources ...
Well, I can see RAM melting away in my Kucksuhr project. This is an ugly feeling because it can develop into a showstopper . Some words like the assembler are only needed during development. ( I miss SEE too)
Bobs idea to split extended.fth into smaller independent files would be helpful, I think.
The part in my post about not to need SD-card I only wrote because Peter thought about having parts of the dictionary in SD, which would make SD-card mandatory, as far as I understood this. I only wanted to say, that the strength of forth is its simplicity and that it works with very poor resources.
I will have a look at the assembler now....
Have fun, Christof
I can confirm that Tachyon loads fine from the Flash memory, with no need for SD card. The tachyon modules I currently have loaded are EXTEND, TOOLS and EXTRAS only - no SD card driver at present. On switch on that leaves 8348 bytes free. If your application doesn't use a lot of data, then that's room for a pretty big forth application, much more than with other languages. Of course there is always P2 and Taqoz, where much more space becomes free. My current Taqoz (which can also run from Flash alone) has 80 kbytes free at switch on. A little more could be added if SPI ram and a few other modules were omitted.
Before developing complex new tools out of fear space could be getting limited.
I would go the simple way.
Add your WS@ to the kernel ... as a LMM
Just a few lines
And delete from EXTEND what you don't need (IF and WHEN you really need more spacex )
Oh .... watching too much STARSHIP :-)
And if you just add a cheap SD your Kuckuck can sing as long as you want .....
Way cheaper than developing the tools you talk about
Hi, Markus,
this thread is about what could be of benefit for a further Tachyon V6. Peter asked about suggestions. So I suggested 2 very concrete words to be added and an idea of overlays, that was only something like a sketch. I don't know whether Peter will read this posts, whether he will continue with Tachyon for P1 and whether he will find the ideas good or or bad or "expensive". It is totally up to him.
Traditionally an assembler was one of the very basic features of Forth.
In my actual case I could use it for a better update frequency (I think, it is about 14kHz now in Forth) of my sound generator too. I am sure, that the cog could do the generation of the envelope too.
So I was thinking how could an assembler be included without the cost of so much RAM?
Do you have any thoughts about new features of V6?
Christof
Comments
I see a SD card addition useful mainly for the development purposes and for the actual device not so much, if at all. It'll be ages before my forth programs need more than 15 kilobytes of space. The P2, while highly desirable, would be an overkill in most cases, feature wise, not to mention the cost.
That said, I agree with you when you say "Given Peter's commitments with P2D2, we shouldn't expect him to do much on tachyon for some time, either." but I also think, when the time is right, some overhaul of Tachyon is needed and will happen.
And I am waiting for that P2D2 impatiently and then, even more impatiently, for the alike P1 module Peter mentioned some time ago.
If all goes well my P2D2 boards and sundries will be here in a few days and I will be busy building up a tester. If I'm happy with the design and how the boards go together I will make up all I can with the stock I have but rather than ordering more parts at the moment I will get quotes on A&T from JLCPCB as they can also supply most of the parts from their LCSC division.
As you have seen, my designs are based on practical and commercial use, not educational nor hobbyist. Neither are they necessarily plug-in breadboard friendly although one can created a special breadboard JM style. My software is not purely for software purposes, but to run the hardware. My hardware is not ignorant of the software that runs on it either and even the layout reflects how I envisage the software will use it. P2D2 is a holistic design and while it may also look "pretty", it is entirely practical and versatile. At 2.4sq" including connectors it is a very compact design especially considering it is not a "bare-bones" design, but is fully fleshed out, and even more so with the P2PAL "layer" added. But this thread is about Tachyon
(I might repost some of the P2D2 info in its own thread)
A product designed using tachyon consists of the application code and the 'runtime' code. Ideally, all of the runtime code is called by the application, and no code is left uncalled. This is efficient, in the sense that the most memory is made available for application data. In nearly all forth systems, it's also unachievable.
I notice that Charles Moore was very keen on the principles of 'less is more' and 'write it yourself'. This was reflected in the small size of the dictionaries in his forths. He minimised the size of the 'runtime' - with good reason - he often had much less than 32k of memory to work with. He also had a drive to reduce problems to the simplest level, which never left him.
If 'runtime' minimisation is a useful goal - and some might not agree - it begs the question: Just what tachyon words are essential to be able to write and deploy a product? If we look top-down, there would seem to be a small number of essential features necessary: Backup sticks out as an example. Without the word Backup or it's equivalent, you don't save the final application to EEPROM. So, given those essential words, what if we determined what words are essential versus what are not? We might use the machine to help, maybe with a 'dictionary crawler' that drilled down the words to determine all the dependencies.
Thus the tachyon dictionary might shrink to that which just produces a product and no more. On the other hand, the library folder would expand with various files of words that were taken out. Here, the designer could choose whether some of those words were needed for the product and put them in. At the moment, the system isn't so easy to prune back without inadvertently breaking stuff, as I've commented on in a previous post.
Disadvantages? Tachyon consists of 3 main files, the kernel, extend.fth and easyfile.fth. They would shrink + you'd have all the new files of 'extras'. Not quite so easy to find that 'must have' word.
Extending dictionary word search to an sd card, with auto-dependency is one way of fixing the issue. You can have as large lexicon as you like given the space there. It isn't as fast to compile as the all ram resident system that exists now, it just has to be fast enough?
As for Chuck I think he spends too much time polishing the Forth brass trying to making it as beautiful as possible but that doesn't always make it more usable or practical. The latest forays into Forth chips especially GA144, although much dated now, are so impractical. Sounds good, looks good, but I haven't seen one useful thing that can be done with it.
Tachyon is about being practical and useful. We can always do a small Tachyon with the same brevity as TAQOZ ROM if there is some advantage in that.
Please don't let me stop you though Bob, really. Discussion and arguments for and against stimulate lateral thinking. We are thereby forced to look at things through someone else's eyes and that adds a new angle. I'm not always convinced by my own arguments and I use them like questions too. So don't stop.
Hi, after some years I have now begun to work with Tachyon 5.7. (Several years ago I did use a previous version.)
In the last months I also did use Forth on other microcontrollers.
As I use other controllers too, I do value Forth-83 or Forth-94 standardisation. It is very nice to be able to have a look into some existing documentation and can rely, that a code snippet will work. We already had this discussion some time ago...
I think, that 5.7 has grown into a very good system!
I think, 16 bit wordcode is straight forward.
That you provide 5.7 as a binary for 80MHz with the extras, which you can FORGET, is a good way!
For future plans, my wishlist so far:
1. It should be able to be run without SD card.
2. Due to the memory constrains a reduced optional File System seems to be right. I think, a Forth block file system is a good compact compromise. See my other post.
3. A signed version of >> would be very good for fast scaling without a hardware divider. Already there: SAR
4. A version of W@ that preserves the sign of the word, would be very nice. Word variables are sufficient for many (most?!) things and conserve space.
5. I like and normally use value type variables with "to".
6. While many Forthers do rank them as not necessary, I really like local variables. They can improve readability very much. And if you code such things as string comparison $= , where you need several counters and pointers, local variables make this very much more easy and readable. However I don't think, that full blown ANSI-94 local variables are a way to go for P1. Instead I think, that there must be a way to declare them before a modified : , so that the dictionary can be used for their implementation. Even unnamed locals like a> and >a are helpful in my opinion.
7. An Assembler. I don't know, if this might be possible.
8. Dreaming: Some way to have a overlay memory range, where you can load and unload ( compile into that memory from eeprom or from SD-card ) utilities like a block editor or the assembler or ... So that you can use the assembler and unload it afterwards.
Christof
already possible
great, so just don't load EASYFILE
and use your own
if you can write the PASM for it we can easily run it as LMM from HUB without disturbing the Kernel
if you can write the PASM for it we can easily run it as LMM from HUB without disturbing the Kernel
really constant constants ;-)
there is a simple local variable module as comment in EXTEND
{
PRIVATE
16 longs locals
locals 4 + := @x2
locals 8 + := @x3
locals 12 + := @x4
pri @X 4* locals + ;
pub X1 locals @ ;
pub X2 @x2 @ ;
pub X3 @x3 @ ;
pub X4 @x4 @ ;
--- pop the n top stack elements to the local space, TOS => X1, TOS+1 => X2 ..
pub LOCAL ( n -- )
DUP 4* ( n bytes )
locals 2DUP + ROT <CMOVE
FOR I @X ! NEXT
;
--- pop and release emove n elements from locals, of no longer used )
pub RELEASE ( n -- ) DUP @X locals ROT 4* $40 SWAP - CMOVE ;
\ locals $40 ERASE \ Clean out the locals (easier for debugging)
}
Peter wrote one long time ago
you find it in modules/PASM.fth
you can load source files that get compiled on load, and you can FORGET them after use.
loading precompiled source would require
1. saving definitions with references / dictionary ...
2. a kind of linker to put the loaded definitions in the right place in the dictionary and fix the internal references ...
not sure it would be worth it
unless you REALLY used all the resources ...
Hi,
where do I find "modules/PASM.fth"?
Thank you!
Christof
There is a link to Peter Jakacki's drop box here and PASM.FTH can be found in \P1\V5\Forth, having downloaded the dropbox and unzipped to a working folder.
It doesn't seem to compile under Tachyon 5v7 though - MJB, can you say more? Do you have a working version of the assembler for Tachyon?
Cheers, Bob
Right, there is also one PASM.FTH in \V6 ZOOM\Forth but seems to be the same version so some investigative work is needed here.
Thanks, Bob, I wasn't aware, that the was a second source in addition to the sourceforge page.
I will have a look at it.
Christof
....
I am not sure, if I explained good enough, what I meant.
an additional :OL "compile into overlay buffer" instead of : . C) declare this overlay buffer somehow. It would be good, if the user could define its size.
Normally, if you 1. load the assembler, 2. assemble for example the new word WS@ ( for signed word read ) and 3. forget the assembler, the new word would be lost. So the idea was to have some kind of 2nd parallel structure to the normal dictionary in an overlay buffer. Into this you could load the assembler ( or another tool ) and work with the normal dictionary. So if you FORGET the contents of the overlay buffer, you would still have the assembled word.
You would need A) a different interpreter/compiler, which scans both dictionaries and
I don't think, that this concept is a really new idea, as Moores multiuser Forths had to have multiple dictionaries for them together with a common one.
Well, I can see RAM melting away in my Kucksuhr project. This is an ugly feeling because it can develop into a showstopper . Some words like the assembler are only needed during development. ( I miss SEE too)
Bobs idea to split extended.fth into smaller independent files would be helpful, I think.
The part in my post about not to need SD-card I only wrote because Peter thought about having parts of the dictionary in SD, which would make SD-card mandatory, as far as I understood this. I only wanted to say, that the strength of forth is its simplicity and that it works with very poor resources.
I will have a look at the assembler now....
Have fun, Christof
Hi Christof,
I can confirm that Tachyon loads fine from the Flash memory, with no need for SD card. The tachyon modules I currently have loaded are EXTEND, TOOLS and EXTRAS only - no SD card driver at present. On switch on that leaves 8348 bytes free. If your application doesn't use a lot of data, then that's room for a pretty big forth application, much more than with other languages. Of course there is always P2 and Taqoz, where much more space becomes free. My current Taqoz (which can also run from Flash alone) has 80 kbytes free at switch on. A little more could be added if SPI ram and a few other modules were omitted.
Christofor
Before developing complex new tools out of fear space could be getting limited.
I would go the simple way.
Add your WS@ to the kernel ... as a LMM
Just a few lines
And delete from EXTEND what you don't need (IF and WHEN you really need more spacex )
Oh .... watching too much STARSHIP :-)
And if you just add a cheap SD your Kuckuck can sing as long as you want .....
Way cheaper than developing the tools you talk about
Hi, Markus,
this thread is about what could be of benefit for a further Tachyon V6. Peter asked about suggestions. So I suggested 2 very concrete words to be added and an idea of overlays, that was only something like a sketch. I don't know whether Peter will read this posts, whether he will continue with Tachyon for P1 and whether he will find the ideas good or or bad or "expensive". It is totally up to him.
Traditionally an assembler was one of the very basic features of Forth.
In my actual case I could use it for a better update frequency (I think, it is about 14kHz now in Forth) of my sound generator too. I am sure, that the cog could do the generation of the envelope too.
So I was thinking how could an assembler be included without the cost of so much RAM?
Do you have any thoughts about new features of V6?
Christof
Hidden gem: I just found out, that shift right signed is already there. It is called SAR.