However, I think it is best to avoid arbitrary changes that don't really provide any benefit. I think the change from ":" to "." was an arbitrary change that wasn't necessary.
If you totally ignore AS, and all the other assembler experience new P2 users will bring, that may be true.
However, it makes sense to support both Assemblers that P2 will be using, surely ?
An alternative way to manage this, would be an Assembler directive that allows AS, or P1-Paste support in the parser.
P1-Paste would be deprecated, as it is the least portable.
However, I think it is best to avoid arbitrary changes that don't really provide any benefit. I think the change from ":" to "." was an arbitrary change that wasn't necessary.
If you totally ignore AS, and all the other assembler experience new P2 users will bring, that may be true.
However, it makes sense to support both Assemblers that P2 will be using, surely ?
An alternative way to manage this, would be an Assembler directive that allows AS, or P1-Paste support in the parser.
P1-Paste would be deprecated, as it is the least portable.
It should be fairly trivial to write a program to convert between PASM and GAS syntax. I'll bet I could write one in a week if I had a reason to. Basic syntax incompatibilities like this therefore seem like a trivial inconvenience.
However, I think it is best to avoid arbitrary changes that don't really provide any benefit. I think the change from ":" to "." was an arbitrary change that wasn't necessary.
If you totally ignore AS, and all the other assembler experience new P2 users will bring, that may be true.
However, it makes sense to support both Assemblers that P2 will be using, surely ?
An alternative way to manage this, would be an Assembler directive that allows AS, or P1-Paste support in the parser.
P1-Paste would be deprecated, as it is the least portable.
It should be fairly trivial to write a program to convert between PASM and GAS syntax. I'll bet I could write one in a week if I had a reason to. Basic syntax incompatibilities like this therefore seem like a trivial inconvenience.
This does not make sense - that fact you need such a program at all (which does not yet exist), proves it is a lot more than "a trivial inconvenience".
( note also that as well as the PASM2GAS mentioned, you would also need to have GAS2PASM )
Your Basic syntax incompatibilities pretty much means what it says
P2 is going to be complex enough already, without adding long term gotcha's into the mix.
Smarter to avoid those Basic syntax incompatibilities in the first place.
By that, I mean the overall presentation of PASM as we know it today is really sweet. Two things are very important to me personally, and that is the flexible data representations and how readable and useful they are, and the other is the overall lean nature of the syntax itself. It's not wordy in any real way.
Expressions are largely unified too. Those can go into operands,contribute to the origin, can appear in data statements, tables, etc...
All of that maps right to SPIN too.
As, gas, etc... are more generalized things and there is a clear place for that, but no requirement to be the only way to express PASM.
I really want the sweet SPIN and PASM package as it exists today on P1 to continue to exist, and I suspect there are enough people who feel the same way as to make that happen no matter what too.
Finally, a lot of this gets driven by the simple and expressive nature of pnut. It is simple and that makes the overall result simple, and that is why a bunch of us are here.
We can translate this stuff, and doing so has already been done on P1, which works nicely to leave SPIN and PASM the nice thing it has always been.
I don't know, I think the basics are still the same...
To me, it looks like just the fancy instructions are different.
I just copied and pasted the multiply routine from the P1 manual and it worked, except for the this ":" business.
I think a lot of my P1 code would work nearly as is too.
So you copy a 16x16 multiply routine from the P1 manual, which can be replaced by a single P2-PASM instruction, which executes 1157 times faster ?
Maybe this is the best example to show how inefficient copy and paste of P1 code is. It's not only inefficient, it's also dangerous because many instruction that look the same work a bit different, mainly in how they set the Carry flag. This can result in code that seems to work at first, but not in all situations which makes it very hard to find the errors.
The P2 gives us so much more possibilities, that it would be a shame to have a lot of 1:1 ported P1 code.
You can copy and paste all you like with a P1 if that's what you like doing.
Of course you can, but the point Chip and Ariba make, is that can be largely the illusion of progress, if the pasted code does not actually work as hoped.
Longer term, I see more user demand for cross-over between the two assemblers that do support P2.
I think the point is that it doesn't make sense to use "." on the P2 when ":" works perfectly fine. Why fix things that aren't broken?
However, with that said I'm happy to use whatever Chip produces. If he wants to use "." instead of ":" I'm OK with it if that helps to make the P2 a reality.
I think the point is that it doesn't make sense to use "." on the P2 when ":" works perfectly fine. Why fix things that aren't broken?
If is was a random change, I would agree, however it does actually fix something that was broken
You can more easily paste between two assemblers where you do expect code to work.
If PNUT2.PASM can also tolerate P1 syntax, that is fine,
many tool offer this feature.
Some use names like relaxed or legacy, others have an explicit mode directive.
To me, P1-Paste (then play find-the-bug!) is a less important long term goal, and if code has the caveats & fish-hooks that Chip and Ariba mention, users are better off without the illusion of ease.
Instead, they should be directed to use a conversion checker program that will flag opcode differences.
However, with that said I'm happy to use whatever Chip produces. If he wants to use "." instead of ":" I'm OK with it if that helps to make the P2 a reality.
Cluso,
I was reading your query as meaning move the Streamer out of the Cogs altogether. If I'm remembering correctly you are partial to having just one Cog with the full Streamer feature set. And the remaining 15 Cogs have only a partial feature set, right? The downer here is the loss of equality, the design so far is completely equal resources all round.
I'm gonna guess this sort of pruning adjustment could be injected to the design pretty easily at a late stage. We can let the ball roll for the moment. If space gets tight then start listing what to prune. I'm pretty certain Chip has already resigned to exceeding the 300k gate limit, so that leaves only die size considerations.
All cogs should be equal, anything else will lead to a nightmare of resource conflicts.
If some cogs have features that others don't, then users will have to deal with figuring out if an object (from obex or wherever) can work for them or not based on what cog features the object requires. You won't be able to just use any combination of objects you want. It's a terrible nightmare of horribleness, and it will lead to less people using the P2.
PLEASE STOP SUGGESTING THINGS THAT WOULD MAKE SOME COGS DIFFERENT FROM OTHERS!
I'm gonna guess this sort of pruning adjustment could be injected to the design pretty easily at a late stage. We can let the ball roll for the moment. If space gets tight then start listing what to prune. I'm pretty certain Chip has already resigned to exceeding the 300k gate limit, so that leaves only die size considerations.
All cogs should be equal, anything else will lead to a nightmare of resource conflicts.
If some cogs have features that others don't, then users will have to deal with figuring out if an object (from obex or wherever) can work for them or not based on what cog features the object requires. You won't be able to just use any combination of objects you want. It's a terrible nightmare of horribleness, and it will lead to less people using the P2.
PLEASE STOP SUGGESTING THINGS THAT WOULD MAKE SOME COGS DIFFERENT FROM OTHERS!
NO!
It's a waste for some resources that could mean in the end that something doesn't fit that would otherwise do so. We are not going to have 16 cogs outputting video so its a waste if the silicon could be used for some better purpose.
What if someone has a brilliant suggestion for a Cog Widget - it uses a large number of gates so it will not fit in every cog. You would say we leave it out, I say put it in. Your users will NEVER have it, mine will have to specifically code a cog to use it, but it will be there to use! No argument really!!!
Cluso, it seems like you believe that the streamer takes up a large percentage of a cog. I doubt if that's the case, and I tend to think that it takes a very small portion of a cog. The streamer just consists of a 16-long FIFO and the logic needed to make it work with the rest of the cog. This must be just a small fraction of the gates required to implement the rest of the cog.
Baggers,
There were a lot of things that made the P2-Hot.
Too many complex instructions.
Quad Port Cog RAM.
Hub access was enabling all RAM (so Chip divided it into 16 blocks - now each cog can access a block every clock and if every cog accesses hub every clock then no savings achieved here - in fact more muxes so could even be worse).
Multi-tasking and the resulting ALU parallel pipeline.
And others I have forgotten.
GetPix would only be in one cog, so I don't that was a biggie.
Dave,
Chip said the extras he put in the other day just for NTSC took IIRC 250+ blocks and a couple of multipliers which will need to be converted to gates. And if I understand correctly, this is duplicated in every cog. This is not the streamer which was already in the done.
Comments
However, it makes sense to support both Assemblers that P2 will be using, surely ?
An alternative way to manage this, would be an Assembler directive that allows AS, or P1-Paste support in the parser.
P1-Paste would be deprecated, as it is the least portable.
It should be fairly trivial to write a program to convert between PASM and GAS syntax. I'll bet I could write one in a week if I had a reason to. Basic syntax incompatibilities like this therefore seem like a trivial inconvenience.
This does not make sense - that fact you need such a program at all (which does not yet exist), proves it is a lot more than "a trivial inconvenience".
( note also that as well as the PASM2GAS mentioned, you would also need to have GAS2PASM )
Your Basic syntax incompatibilities pretty much means what it says
P2 is going to be complex enough already, without adding long term gotcha's into the mix.
Smarter to avoid those Basic syntax incompatibilities in the first place.
By that, I mean the overall presentation of PASM as we know it today is really sweet. Two things are very important to me personally, and that is the flexible data representations and how readable and useful they are, and the other is the overall lean nature of the syntax itself. It's not wordy in any real way.
Expressions are largely unified too. Those can go into operands,contribute to the origin, can appear in data statements, tables, etc...
All of that maps right to SPIN too.
As, gas, etc... are more generalized things and there is a clear place for that, but no requirement to be the only way to express PASM.
I really want the sweet SPIN and PASM package as it exists today on P1 to continue to exist, and I suspect there are enough people who feel the same way as to make that happen no matter what too.
Finally, a lot of this gets driven by the simple and expressive nature of pnut. It is simple and that makes the overall result simple, and that is why a bunch of us are here.
We can translate this stuff, and doing so has already been done on P1, which works nicely to leave SPIN and PASM the nice thing it has always been.
So you copy a 16x16 multiply routine from the P1 manual, which can be replaced by a single P2-PASM instruction, which executes 1157 times faster ?
Maybe this is the best example to show how inefficient copy and paste of P1 code is. It's not only inefficient, it's also dangerous because many instruction that look the same work a bit different, mainly in how they set the Carry flag. This can result in code that seems to work at first, but not in all situations which makes it very hard to find the errors.
The P2 gives us so much more possibilities, that it would be a shame to have a lot of 1:1 ported P1 code.
Andy
Of course you can, but the point Chip and Ariba make, is that can be largely the illusion of progress, if the pasted code does not actually work as hoped.
Longer term, I see more user demand for cross-over between the two assemblers that do support P2.
Very true
Still, sometimes the first step is to get code working and then next make it optimized.
If somebody wants to quickly get something working, copying from P1 assembly should be the best path.
A great feature of P2 should be that you don't have to start from scratch for simple drivers that P1 already has...
However, with that said I'm happy to use whatever Chip produces. If he wants to use "." instead of ":" I'm OK with it if that helps to make the P2 a reality.
You can more easily paste between two assemblers where you do expect code to work.
If PNUT2.PASM can also tolerate P1 syntax, that is fine,
many tool offer this feature.
Some use names like relaxed or legacy, others have an explicit mode directive.
To me, P1-Paste (then play find-the-bug!) is a less important long term goal, and if code has the caveats & fish-hooks that Chip and Ariba mention, users are better off without the illusion of ease.
Instead, they should be directed to use a conversion checker program that will flag opcode differences.
Indeed. Me too.
The pnut compiler is only an interim to get the P2 testing done.
Multiply is a good one. RDFAST is good and REP.
There's a video demo for NTSC TV's in there.
I was reading your query as meaning move the Streamer out of the Cogs altogether. If I'm remembering correctly you are partial to having just one Cog with the full Streamer feature set. And the remaining 15 Cogs have only a partial feature set, right? The downer here is the loss of equality, the design so far is completely equal resources all round.
I'm gonna guess this sort of pruning adjustment could be injected to the design pretty easily at a late stage. We can let the ball roll for the moment. If space gets tight then start listing what to prune. I'm pretty certain Chip has already resigned to exceeding the 300k gate limit, so that leaves only die size considerations.
I'll bet we can move on after this next round, and we all write some programs to be sure.
Evanh, your insistence we resolve cordic and other lock points is case in point.
Write some PASM people! That's how we get to smart pins.
If some cogs have features that others don't, then users will have to deal with figuring out if an object (from obex or wherever) can work for them or not based on what cog features the object requires. You won't be able to just use any combination of objects you want. It's a terrible nightmare of horribleness, and it will lead to less people using the P2.
PLEASE STOP SUGGESTING THINGS THAT WOULD MAKE SOME COGS DIFFERENT FROM OTHERS!
Agreed , that's a great aspiration.
However, the real world intrudes, and die area is finite.
As mentioned above, this should be resource quantified for later sanity-checking, should this not all fit into the fixed and finite space available.
Yes, this can be reality-checked later.
NO!
It's a waste for some resources that could mean in the end that something doesn't fit that would otherwise do so. We are not going to have 16 cogs outputting video so its a waste if the silicon could be used for some better purpose.
What if someone has a brilliant suggestion for a Cog Widget - it uses a large number of gates so it will not fit in every cog. You would say we leave it out, I say put it in. Your users will NEVER have it, mine will have to specifically code a cog to use it, but it will be there to use! No argument really!!!
There were a lot of things that made the P2-Hot.
Too many complex instructions.
Quad Port Cog RAM.
Hub access was enabling all RAM (so Chip divided it into 16 blocks - now each cog can access a block every clock and if every cog accesses hub every clock then no savings achieved here - in fact more muxes so could even be worse).
Multi-tasking and the resulting ALU parallel pipeline.
And others I have forgotten.
GetPix would only be in one cog, so I don't that was a biggie.
Dave,
Chip said the extras he put in the other day just for NTSC took IIRC 250+ blocks and a couple of multipliers which will need to be converted to gates. And if I understand correctly, this is duplicated in every cog. This is not the streamer which was already in the done.