I hang up my hat. I'm not nerdy enough for that Forth thing.
You can just think of it as a monitor with backwards syntax. If you only type simple commands it should be quite easy to use. You don't *have* to use it to write code but you *can* use it that way. The old monitor didn't have that ability.
I hang up my hat. I'm not nerdy enough for that Forth thing.
Oh, c'mon, Heater. Come over to the dark side: it's addicting.
Truth be known, I'm a reformed Forth addict. It took a 12-step program and several counseling sessions to get me unhooked so I could learn Perl. But, like smelling a cigarette first being lit (another addiction I gave up), seeing Tachyon code gives me pangs of yearning for that instant gratification known as "ok[CR]".
Agreed! Gonna preach to the choir for a moment here:
FORTH and I don't get along very well, but I also think some well chosen words, and I know he's working on that, would go a long way toward getting the low hanging fruit into people's hands. And that's me. FORTH type thinking is just hard. I suspect, like anything else, putting some time into it will help a lot. This implementation will be a great reason to do just that. Great! Looking forward to it.
In any case, making the low hanging fruit easy is all anyone needs. From there, throw a dictionary at the FORTH, or call into it, or use it to load something else.
Or, just ignore it. That's gonna all be fine too.
On a similar note, parallel if you will, I just got done with a pretty intense conference / expo. Was showing an industrial 3D printing product. It's open, checks most of the boxes many want checked,
But...
I mentioned being able to modify on the fly, in real time. BOOM! Most everyone involved downplays that feature. They've got reasons, mostly "pro" type reasons. And those are all valid too. I've no complaint or argument.
But, where I went with that was figuring stuff out for the first time, troubleshooting, or exploring new materials, and other related things.
Because the thing has a "real time" adjustment capability (takes effect on next g-code, close enough for most scenarios), doing things like grabbing some random material for printing can make a lot of sense quickly. I've done just that for a demo. Was some odd polymer, a bit difficult to get printing well. I ran a standard calibration part, one I know well, and proceeded to just dial feeds, speeds, temps, until it looked like it was going to proceed. Managed to get the very first part printed reasonably. Learned a ton in about 20 minutes too.
The standard, guess, set parameters, slice, print, observe, analyze, repeat cycle would have taken hours.
Interactive can make a mess, but it can also show one the dynamics, "lay of the land" rather quickly too. Troubleshooting is an obvious case as well.
The downside is it's not something that can scale, or maybe repeat in a practical way. All fair calls, but people have very different goals too. @Phil just trashed on a "buzzword" I use often, "use case", and I've seen others frame it as, "user story" too. OK, fine. I get all of that, but will also say, "use cases" detailed out, users identified, archetypes derived from that can all combined, tell us an awful lot about why people might do what they do, and what value it may have for them.
In the case of research, "skunkworks", development, prototype users, and "their cases / stories", having an interactive type environment makes a TON of sense. More than I thought. Was at an expo just showing spiffy stuff, doing the usual things people do. Dropped that capability in answer to a question I got, and showed it off. They went and told people, and soon we had a few others there, interested. Bet a couple deals get done, which is a big part of why I was there.
After that response, some minds opened up some. We talked about what the prospects told us, why they found that attractive, and what drives their needs. Was some odd bits in there nobody really thought about. And, they know that, being at the event to talk it all up, and see who might have what. All ordinary, but maybe something we lack in this context as we've been kind of a small group working hard to maximize this thing.
The greater point being, this kind of feature really doesn't detract from the other important ones. The "pro" and or "standard" uses / workflows / stories we all know well are well covered now. We did a robust debug, after what? Years of discussion?
We did interrupts too, after what? Years of discussion?
A protected memory region ended up in there too. Just under the wire. (Whew! I really wanted that one, for this use case.) Couple years discussion on that one. Largely because ROM copy to RAM made the most sense this time around.
Interactive just has it's place. So does native development tools. Simple, robust, lean. More and better will be had off chip, as it should be too. Not an issue.
One thing I find compelling and interesting is how choices and complexity, feature sets work. Where there are fewer features, but they are sufficient to get the need to do, done, the number of choices tends to go down, and that tends to make "right" or "better" or even "effective" choices somewhat easier to make happen. There just aren't as many options. The trade-off on all that is more work, or copy paste, or limits on practical project size and scope.
Interactive is sort of like this. It's impractical to do big things. Not that many of them can't be done. They can. Maybe a few odd ducks will too. But, it's very practical to do smaller things. Fast, often simple, and very easy to iterate on.
And Peter has shown us how he works and what he gets out of working that way. I find it compelling and potent. Not sure anyone else has packed so much into a P1, for example. Kind of amazing really.
Sure hope it gets in there. It won't change the world, but I suspect a few people will really benefit, and maybe one or some of them do something that takes off too. Who knows? I sure don't think it hurts at all, given we've got the more or less empty box here at the end to fill up. I'm not sure anyone benefits by shipping zeros, or a font, or other trivial thing.
More generally, I feel very strongly that we've somehow arrived in a very good place overall. When Chip thought about the COGS, potential for there to only be 8 of them, and what we saw with the HOT chip, adding interrupts made a lot of sense. Most of us were anti. I know I was, and to some degree still am. Prefer to avoid them where possible, and P1 has totally spoiled me there.
But, making all that local to the COG, just like Heater observed that the COG is the basic, re-use unit --the "object", so to speak, suddenly made a huge amount of sense! We did end up with 8 COGS too. Very good call in hindsight.
Debug ended up a very similar thing. Some of us have kept focus on it the whole time. Glad they did too.
I see this in exactly the same way.
Put generally, the cost in terms of complexity and resource allocation is lower than the potential gain, in terms of people working the way they want or need to work, overall capability and ability to more fully exploit what does ship.
It's an exciting time. Hope all goes well, and we are building stuff for real test chips very soon!
Remember, code does not get executed from ROM on the P2. It's a serial ROM that gets copied into RAM at boot time. It is quite possible that TAQOS will be extensible but I'll let Peter answer that.
To me, the hardest part about Forth is stack management. You really have to keep track of how much stuff is there so you can pop the right amount when you're done with it. Postscript, a Forth-like language that I've also programmed a lot, solves this with its mark and cleartomark operators. Push a mark onto the stack, push a bunch of other stuff, then cleartomark to get rid of it. Simple.
Totally. IMHO, that's a good feature now that we have a write inhibited region. Given it's a FORTH, I find it very hard to imagine it won't be extensible. All it will take is a provision to support a dictionary that lies in general RAM.
Back in the late 1970's when the company worked for had me writing a debug monitor for the new Motorola 6809, with no assembler support all done by hand and entered as HEX to a PROM programmer, I got the idea that it would be easier to implement if everything was backwards. "100 G" instead of "G 100". My mind rebelled, no I am going to do it the hard way, I am going to do it the way users might understand.
In simple cases this does not make much difference to the user.
Comments
Truth be known, I'm a reformed Forth addict. It took a 12-step program and several counseling sessions to get me unhooked so I could learn Perl. But, like smelling a cigarette first being lit (another addiction I gave up), seeing Tachyon code gives me pangs of yearning for that instant gratification known as "ok[CR]".
-Phil
FORTH and I don't get along very well, but I also think some well chosen words, and I know he's working on that, would go a long way toward getting the low hanging fruit into people's hands. And that's me. FORTH type thinking is just hard. I suspect, like anything else, putting some time into it will help a lot. This implementation will be a great reason to do just that. Great! Looking forward to it.
In any case, making the low hanging fruit easy is all anyone needs. From there, throw a dictionary at the FORTH, or call into it, or use it to load something else.
Or, just ignore it. That's gonna all be fine too.
On a similar note, parallel if you will, I just got done with a pretty intense conference / expo. Was showing an industrial 3D printing product. It's open, checks most of the boxes many want checked,
But...
I mentioned being able to modify on the fly, in real time. BOOM! Most everyone involved downplays that feature. They've got reasons, mostly "pro" type reasons. And those are all valid too. I've no complaint or argument.
But, where I went with that was figuring stuff out for the first time, troubleshooting, or exploring new materials, and other related things.
Because the thing has a "real time" adjustment capability (takes effect on next g-code, close enough for most scenarios), doing things like grabbing some random material for printing can make a lot of sense quickly. I've done just that for a demo. Was some odd polymer, a bit difficult to get printing well. I ran a standard calibration part, one I know well, and proceeded to just dial feeds, speeds, temps, until it looked like it was going to proceed. Managed to get the very first part printed reasonably. Learned a ton in about 20 minutes too.
The standard, guess, set parameters, slice, print, observe, analyze, repeat cycle would have taken hours.
Interactive can make a mess, but it can also show one the dynamics, "lay of the land" rather quickly too. Troubleshooting is an obvious case as well.
The downside is it's not something that can scale, or maybe repeat in a practical way. All fair calls, but people have very different goals too. @Phil just trashed on a "buzzword" I use often, "use case", and I've seen others frame it as, "user story" too. OK, fine. I get all of that, but will also say, "use cases" detailed out, users identified, archetypes derived from that can all combined, tell us an awful lot about why people might do what they do, and what value it may have for them.
In the case of research, "skunkworks", development, prototype users, and "their cases / stories", having an interactive type environment makes a TON of sense. More than I thought. Was at an expo just showing spiffy stuff, doing the usual things people do. Dropped that capability in answer to a question I got, and showed it off. They went and told people, and soon we had a few others there, interested. Bet a couple deals get done, which is a big part of why I was there.
After that response, some minds opened up some. We talked about what the prospects told us, why they found that attractive, and what drives their needs. Was some odd bits in there nobody really thought about. And, they know that, being at the event to talk it all up, and see who might have what. All ordinary, but maybe something we lack in this context as we've been kind of a small group working hard to maximize this thing.
The greater point being, this kind of feature really doesn't detract from the other important ones. The "pro" and or "standard" uses / workflows / stories we all know well are well covered now. We did a robust debug, after what? Years of discussion?
We did interrupts too, after what? Years of discussion?
A protected memory region ended up in there too. Just under the wire. (Whew! I really wanted that one, for this use case.) Couple years discussion on that one. Largely because ROM copy to RAM made the most sense this time around.
Interactive just has it's place. So does native development tools. Simple, robust, lean. More and better will be had off chip, as it should be too. Not an issue.
One thing I find compelling and interesting is how choices and complexity, feature sets work. Where there are fewer features, but they are sufficient to get the need to do, done, the number of choices tends to go down, and that tends to make "right" or "better" or even "effective" choices somewhat easier to make happen. There just aren't as many options. The trade-off on all that is more work, or copy paste, or limits on practical project size and scope.
Interactive is sort of like this. It's impractical to do big things. Not that many of them can't be done. They can. Maybe a few odd ducks will too. But, it's very practical to do smaller things. Fast, often simple, and very easy to iterate on.
And Peter has shown us how he works and what he gets out of working that way. I find it compelling and potent. Not sure anyone else has packed so much into a P1, for example.
Sure hope it gets in there. It won't change the world, but I suspect a few people will really benefit, and maybe one or some of them do something that takes off too. Who knows? I sure don't think it hurts at all, given we've got the more or less empty box here at the end to fill up. I'm not sure anyone benefits by shipping zeros, or a font, or other trivial thing.
More generally, I feel very strongly that we've somehow arrived in a very good place overall. When Chip thought about the COGS, potential for there to only be 8 of them, and what we saw with the HOT chip, adding interrupts made a lot of sense. Most of us were anti. I know I was, and to some degree still am. Prefer to avoid them where possible, and P1 has totally spoiled me there.
But, making all that local to the COG, just like Heater observed that the COG is the basic, re-use unit --the "object", so to speak, suddenly made a huge amount of sense! We did end up with 8 COGS too. Very good call in hindsight.
Debug ended up a very similar thing. Some of us have kept focus on it the whole time. Glad they did too.
I see this in exactly the same way.
Put generally, the cost in terms of complexity and resource allocation is lower than the potential gain, in terms of people working the way they want or need to work, overall capability and ability to more fully exploit what does ship.
It's an exciting time. Hope all goes well, and we are building stuff for real test chips very soon!
-Phil
Back in the late 1970's when the company worked for had me writing a debug monitor for the new Motorola 6809, with no assembler support all done by hand and entered as HEX to a PROM programmer, I got the idea that it would be easier to implement if everything was backwards. "100 G" instead of "G 100". My mind rebelled, no I am going to do it the hard way, I am going to do it the way users might understand.
In simple cases this does not make much difference to the user.
1 2 3 4 5 6 7 8 9 10 + - / somefunc
What is this likely to do?
What is left on the stack when it is done?
I don't know what somefunc does, so I can't say what's left on the stack after somefunc executes.
If it were written as something like:
somefunc (1, 2, 3, 4, 5, 6, (7 / (8 - (9 + 10))))
You would know where you are.