So I guess this effort is to create the ideal successor to P1 no matter how long it takes. I guess that shows that my idea of waiting until there is silicon to do any tools work is a good one. No telling what might change and how much in the process of perfecting P2.
I hope you are just kidding, but I didn't see any emoticons. My understanding is that as soon as we get the first FPGA image we can start testing it out with lots of code. With enough people hammering on it we should uncover any bugs that are in the design, and people can suggest fixes and enhancements. That's why I think it's important to get the FGPA image ASAP. All this tweaking on interrupts and locks can be done in the future FPGA images.
So I think it's important that the PropGCC work begin as soon as the FPGA image is available. In theory, it could be done based on the instruction doc that Chip posted even though that is lacking in a lot of details.
Can you guarantee that the instruction set won't be revamped yet again to make room for new features that get added after the FPGA image is released? I originally asked for the instruction set to be posted to begin propgcc work but lost interest when it became clear that this was going to be another long drawn out design evolution discussion that could very well redefine the instruction set again. It's not worth targeting an instruction set that is itself a moving target.
Of course, there are no guarantees. However, I don't believe any of the existing instructions that he posted have changed. He has only added new ones. I think.
Heater, I was confused by the phrase "Making an ask backed by...". It's not an American thing as far as I know. Maybe it's a regional thing.
I think it is some hideous MBA/business speak thing. A former employee of mine that is now at a very large insurance company has mentioned it before. He mentioned it going as far as being requested to "Prepare you asks" prior to the meeting. I recall him calling it "nounification"...
C.W.
Of course, there are no guarantees. However, I don't believe any of the existing instructions that he posted have changed. He has only added new ones. I think.
The core compiler-facing opcodes would be quite stable.
What has been added, is opcodes to control the flags around interrupts, which do not really affect compiler design.
I call it a gross ignorance of the English language, a lack of vocabulary.
Of course if you are inventing your own language then why not?
It is a bit of a surprise when I can understand English speakers, for whom it is a second or third language, from all over Europe and Asia better than American speakers
I shall postpone any asks regarding a cog's support for any volutary feature drop until after a current FPGA image will have been posted, for belief that such an add should be simple enough to be done at any time. Interesting language discussion you have woven in here, by the way.
Like David Betz though, I'd like to know, whether a BeMicro CV A9 would be a worthwhile acquisition at this point.
Of course, there are no guarantees. However, I don't believe any of the existing instructions that he posted have changed. He has only added new ones. I think.
The core compiler-facing opcodes would be quite stable.
What has been added, is opcodes to control the flags around interrupts, which do not really affect compiler design.
During the P2-hot development, the opcodes were all changed to make space for new opcodes. That could happen again.
I call it a gross ignorance of the English language, a lack of vocabulary.
Of course if you are inventing your own language then why not?
It is a bit of a surprise when I can understand English speakers, for whom it is a second or third language, from all over Europe and Asia better than American speakers
It no longer surprises me. This being a forum with participants from around the globe I was not surprised to see a lot of spelling and grammar errors. What did surprise me was that the worst errors came from participants living in countries where English was the primary language.
And Chip has more to do before we worry about any of it.
Re: mangling english
Bust me if you see it. I am going to purge that Smile.
From what I can tell so far, the odd use is fast, young startup lingo. MBA like, but ultra lean, and text message culture friendly. I use SMS a ton right now, and it has an impact.
I also suspect it can be found in Twitter and it's 140 character limit.
My own tolerance for odd use or foreign expression is high. Never had much trouble. Context comes easy, and that makes me susceptible to this garbage.
And as I said, I am not easily offended. Thanks for the interesting responses.
wonder if a 32 bit long dual port register mapped into lower hub would work as lock bits with a special atomic hub lock instruction.
This way you could just read or write normally, or using the special LOCK instruction set/clear a lock bit with WC returning the original but setting. Because of the dual port nature of this register, in the one clock we would read the bit of the register as well as writing the desired value.
Interrupts could possibly be added to this although I am unsure how this would be applied. Note you could have more than 32 bits.
It probably would not require any extra hub buss bits if implemented this way.
Hey guys, can we stay on topic and forget the English discussion. Remember, we have to sift through these errant posts!
I'd like to point out that off-topic conversations mean we aren't asking for more changes. But, if you'd rather we get back to delaying the FPGA release...
The interrupt system got mostly sorted, and prior to that, he was working on optimizing the COG, timing, etc... and doing that in prep to get an image done.
The last feature discussion was similar. Different context tasks, but same dynamic.
We don't need a repeat of the "Hot" P2 where most of the peanut gallery stuffed everything but the kitchen sink into the design which then killed it.
Personally I think Chip should have initially went for the incremental refinement of the Prop the way ALE suggested.
Hey guys, can we stay on topic and forget the English discussion. Remember, we have to sift through these errant posts!
I'd like to point out that off-topic conversations mean we aren't asking for more changes. But, if you'd rather we get back to delaying the FPGA release...
Can some of you explain why it would be good to have a LOCKGET D/# instruction that just reads a LOCK state? These 16 signals come into every cog now and could be easily read without needing any hub interaction.
The problem with just reading them is that they could change abruptly. Simultaneous reading and writing via LOCKSET/LOCKCLR in the hub is where the meaningful action occurs.
We could add an instruction to do this, but I just need to be convinced that it would be useful.
Seairth was making a case for reading lock state as a more efficient means to facilitate comms and state sharing between cogs than the memory read / write first HUB long interrupts are. (mailbox method with interrupts associated with it now)
And it may be more than that, but he should speak to it.
Heater- "
It is a bit of a surprise when I can understand English speakers,
for whom it is a second or third language, from all over Europe and Asia
better than American speakers "
-EDIT- Whoops, off topic. And, all I did was paste in the URL and it put an embed in....
I've got the new event scheme implemented with separate sets of GETxxx and WAITxxx instructions. The only thing that needs attention now is the interrupt generator, which will be greatly simplified since all the event circuits are now independent of it. This new setup is way better than before.
I've got the new event scheme implemented with separate sets of GETxxx and WAITxxx instructions. The only thing that needs attention now is the interrupt generator, which will be greatly simplified since all the event circuits are now independent of it. This new setup is way better than before.
I will post a new instruction set tomorrow.
Thanks Chip! Is there any chance you could post an interim FPGA image before you start work on the smart pins? This might allow those of us who are working on tools to get a start on the stuff that is stable. The compilers won't care about interacting with the pins anyway. Or is that too big a diversion for you? If that is possible, I'd be happy to use whatever FPGA is easiest for you to target even if I end up having to buy a 1-2-3 board.
Comments
I hope you are just kidding, but I didn't see any emoticons. My understanding is that as soon as we get the first FPGA image we can start testing it out with lots of code. With enough people hammering on it we should uncover any bugs that are in the design, and people can suggest fixes and enhancements. That's why I think it's important to get the FGPA image ASAP. All this tweaking on interrupts and locks can be done in the future FPGA images.
So I think it's important that the PropGCC work begin as soon as the FPGA image is available. In theory, it could be done based on the instruction doc that Chip posted even though that is lacking in a lot of details.
Can you guarantee that the instruction set won't be revamped yet again to make room for new features that get added after the FPGA image is released? I originally asked for the instruction set to be posted to begin propgcc work but lost interest when it became clear that this was going to be another long drawn out design evolution discussion that could very well redefine the instruction set again. It's not worth targeting an instruction set that is itself a moving target.
Of course, there are no guarantees. However, I don't believe any of the existing instructions that he posted have changed. He has only added new ones. I think.
I think it is some hideous MBA/business speak thing. A former employee of mine that is now at a very large insurance company has mentioned it before. He mentioned it going as far as being requested to "Prepare you asks" prior to the meeting. I recall him calling it "nounification"...
C.W.
This sentence requires a verb.
It is correctly verbed, the "I'll" is a contraction on "I will"; will being the verb.
It was scribed as it would have been spake, contrary to the preference of many more formal writers.
Of course, there are no guarantees. However, I don't believe any of the existing instructions that he posted have changed. He has only added new ones. I think.
The core compiler-facing opcodes would be quite stable.
What has been added, is opcodes to control the flags around interrupts, which do not really affect compiler design.
'I recall him calling it "nounification"'
I call it a gross ignorance of the English language, a lack of vocabulary.
Of course if you are inventing your own language then why not?
It is a bit of a surprise when I can understand English speakers, for whom it is a second or third language, from all over Europe and Asia better than American speakers
Like David Betz though, I'd like to know, whether a BeMicro CV A9 would be a worthwhile acquisition at this point.
Of course, there are no guarantees. However, I don't believe any of the existing instructions that he posted have changed. He has only added new ones. I think.
The core compiler-facing opcodes would be quite stable.
What has been added, is opcodes to control the flags around interrupts, which do not really affect compiler design.
During the P2-hot development, the opcodes were all changed to make space for new opcodes. That could happen again.
'I recall him calling it "nounification"'
I call it a gross ignorance of the English language, a lack of vocabulary.
Of course if you are inventing your own language then why not?
It is a bit of a surprise when I can understand English speakers, for whom it is a second or third language, from all over Europe and Asia better than American speakers
It no longer surprises me. This being a forum with participants from around the globe I was not surprised to see a lot of spelling and grammar errors. What did surprise me was that the worst errors came from participants living in countries where English was the primary language.
Maybe. Anyway, I have to finish the loader for the Parallax ActivityBoard WX before I can work on PropGCC anyway. :-)
Re: mangling english
Bust me if you see it. I am going to purge that Smile.
From what I can tell so far, the odd use is fast, young startup lingo. MBA like, but ultra lean, and text message culture friendly. I use SMS a ton right now, and it has an impact.
I also suspect it can be found in Twitter and it's 140 character limit.
My own tolerance for odd use or foreign expression is high. Never had much trouble. Context comes easy, and that makes me susceptible to this garbage.
And as I said, I am not easily offended. Thanks for the interesting responses.
wonder if a 32 bit long dual port register mapped into lower hub would work as lock bits with a special atomic hub lock instruction.
This way you could just read or write normally, or using the special LOCK instruction set/clear a lock bit with WC returning the original but setting. Because of the dual port nature of this register, in the one clock we would read the bit of the register as well as writing the desired value.
Interrupts could possibly be added to this although I am unsure how this would be applied. Note you could have more than 32 bits.
It probably would not require any extra hub buss bits if implemented this way.
I'd like to point out that off-topic conversations mean we aren't asking for more changes. But, if you'd rather we get back to delaying the FPGA release...
How is it that you know what Chip is doing? Do you have an inside track?
The interrupt system got mostly sorted, and prior to that, he was working on optimizing the COG, timing, etc... and doing that in prep to get an image done.
The last feature discussion was similar. Different context tasks, but same dynamic.
Personally I think Chip should have initially went for the incremental refinement of the Prop the way ALE suggested.
Hey guys, can we stay on topic and forget the English discussion. Remember, we have to sift through these errant posts!
I'd like to point out that off-topic conversations mean we aren't asking for more changes. But, if you'd rather we get back to delaying the FPGA release...
I am looking over the Hyundai Car Plant and Shipyard in the distance. Where am I?
Or did you spend for the nearby and taller Hotel Hyundai?
The problem with just reading them is that they could change abruptly. Simultaneous reading and writing via LOCKSET/LOCKCLR in the hub is where the meaningful action occurs.
We could add an instruction to do this, but I just need to be convinced that it would be useful.
We could add an instruction to do this, but I just need to be convinced that it would be useful.
Bill made comments herehttp://forums.parallax.com/discussion/comment/1338255/#Comment_1338255
And it may be more than that, but he should speak to it.
Or did you spend for the nearby and taller Hotel Hyundai?
Close...
Skyrex
303 Samsan-ro
Ulsan Nam-gu
It is a bit of a surprise when I can understand English speakers,
for whom it is a second or third language, from all over Europe and Asia
better than American speakers "
-EDIT- Whoops, off topic. And, all I did was paste in the URL and it put an embed in....
LOL,
I will post a new instruction set tomorrow.
I've got the new event scheme implemented with separate sets of GETxxx and WAITxxx instructions. The only thing that needs attention now is the interrupt generator, which will be greatly simplified since all the event circuits are now independent of it. This new setup is way better than before.
I will post a new instruction set tomorrow.
Thanks Chip! Is there any chance you could post an interim FPGA image before you start work on the smart pins? This might allow those of us who are working on tools to get a start on the stuff that is stable. The compilers won't care about interacting with the pins anyway. Or is that too big a diversion for you? If that is possible, I'd be happy to use whatever FPGA is easiest for you to target even if I end up having to buy a 1-2-3 board.
David Betz said:
Thanks Chip! Is there any chance you could post an interim FPGA image before you start work on the smart pins? ...
http://forums.parallax.com/discussion/comment/1338112/#Comment_1338112