Shop OBEX P1 Docs P2 Docs Learn Events
Prop2 FPGA files!!! - Updated 2 June 2018 - Final Version 32i - Page 22 — Parallax Forums

Prop2 FPGA files!!! - Updated 2 June 2018 - Final Version 32i

11920222425160

Comments

  • jmgjmg Posts: 15,140
    edited 2015-11-05 00:31
    Dave Hein wrote: »
    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.
  • I second a return to the colon. One less thing for a person coming from P1 to worry about.
  • ElectrodudeElectrodude Posts: 1,608
    edited 2015-11-05 01:18
    jmg wrote: »
    Dave Hein wrote: »
    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.
  • jmgjmg Posts: 15,140
    edited 2015-11-05 01:59
    jmg wrote: »
    Dave Hein wrote: »
    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.
  • potatoheadpotatohead Posts: 10,253
    edited 2015-11-05 04:39
    As has an inferior syntax.

    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.



  • AribaAriba Posts: 2,679
    Rayman wrote: »
    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.

    Andy
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2015-11-05 05:44
    You can copy and paste all you like with a P1 if that's what you like doing. P2 is different and better, it is not a P1. Amen to that.
  • jmgjmg Posts: 15,140
    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.
  • RaymanRayman Posts: 13,721
    edited 2015-11-05 12:05
    Ariba wrote: »
    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 ?

    Very true :) Maybe I should have used the divide example...

    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...

  • Dave HeinDave Hein Posts: 6,347
    edited 2015-11-05 13:49
    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.
  • jmgjmg Posts: 15,140
    edited 2015-11-05 18:34
    Dave Hein wrote: »
    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.

    Indeed. Me too.
  • Cluso99Cluso99 Posts: 18,066
    All these semantics can be addressed by the P2 Compiler once P2 has settled.
    The pnut compiler is only an interim to get the P2 testing done.
  • RaymanRayman Posts: 13,721
    Would be nice if somebody would compile of list of ways to optimize P1 asm code for P2...

    Multiply is a good one. RDFAST is good and REP.
  • cgraceycgracey Posts: 14,124
    edited 2015-11-08 10:06
    I just posted a new .zip at the top of this thread with updated FPGA files.

    There's a video demo for NTSC TV's in there.
  • Thanks Chip! :)
  • Sweet :D
  • Cluso99Cluso99 Posts: 18,066
    That's great news Chip. Maybe it doesn't need to be in every cog?
  • evanhevanh Posts: 15,049
    Cluso! We've had this talk already, The streamer is tied to the LUT. Would you want to lose the LUT out of the Cogs now?
  • Cluso99Cluso99 Posts: 18,066
    evanh wrote: »
    Cluso! We've had this talk already, The streamer is tied to the LUT. Would you want to lose the LUT out of the Cogs now?
    But isn't this extra section Chip has added in every cog? If so, then is it required in every cog (just the added pieces)?
  • evanhevanh Posts: 15,049
    Yes, correct me if I'm wrong, it's effectively all part of the per Cog Streamer feature. What to do?
  • evanhevanh Posts: 15,049
    edited 2015-11-08 14:02
    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.
  • My thought too. He's done a lot that we all asked for. His turn to have a little play.

    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.

    :p
  • 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!
  • Thank you. Agreed.
  • jmgjmg Posts: 15,140
    edited 2015-11-08 20:29
    Roy Eltham wrote: »
    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.

    evanh wrote: »
    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.
    Yes, this can be reality-checked later.

  • Cluso99Cluso99 Posts: 18,066
    Roy Eltham wrote: »
    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.
  • Cluso, it was GetPix of the Prop 2 HOT that was the resource heavy heating generator.
  • Cluso99Cluso99 Posts: 18,066
    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.
Sign In or Register to comment.