Shop OBEX P1 Docs P2 Docs Learn Events
Questions about the P2 instrution set for anyone but Chip — Parallax Forums

Questions about the P2 instrution set for anyone but Chip

rjo__rjo__ Posts: 2,114
edited 2015-09-24 21:05 in Propeller 2
First, thanks to everyone for their responses to my last question about hubexec. It was particularly reassuring that Mike Green is following P2 development.

Initially, I didn't respond because I got sick. After that, I didn't want to gum up Chip's thread.

All of the questions I would like to ask will be answered in the next few weeks, when the initial documentation becomes available. But I just can't seem to find any patience at this point. Please feel free to post your own questions here or any other comments that don't deserve a new thread or fit into the main thread about the P2.

#
is this 9, 20 or 32 bit now?

SETXFRQ... is this the smart pin version of frqa?

Thanks Guys
«134

Comments

  • rjo__rjo__ Posts: 2,114
    edited 2015-09-24 23:56
    How do I search just Chip's master thread about P2?
  • cgraceycgracey Posts: 14,152
    Constant fields for D and S are still 9 bits, but if you use ## in the assembler, instead of just #, it will insert an AUGS/AUGD instruction to allow a 32 bit constant. You can do ## for both D and S, if the instruction allows it.

    SETXFRQ is the streamer's freq for its NCO. If the MSB is set, it will cause the streamer to fire every clock. So, it's like FRQA, but with an MSB that allows 100% firing. I need to document that, of course. In the FPGA files I just posted, there's a "sin_cos_dacs.spin" program that uses it to generate sine/cosine waves.
  • rjo__rjo__ Posts: 2,114
    edited 2015-09-28 15:45
    Chip,

    Thanks ... I am keeping up with the other threads.

    BUT...YOU ARE ABSOLUTELY BANNED from this thread. I want you working not talking to me!!!!! If you must talk... talk to someone else, who will chew it up and spit it into my brain. We have a bunch of guys in this category. If no-one knows the answer... it will sit for a while. That is how God wants it:)

    Rich

  • rjo__rjo__ Posts: 2,114
    In the latest loader there is this line:

    begin clkset #$FF 'switch to 80MHz (if pll, else 50MHz)

    So... if I have a pll... does this stay the same?



    together with these lines at the bottom:

    waita long 25+12-6 '40+20-6
    waitb long 25-6 '40-6

    And... I just use the commented value.

    thanks

  • cgraceycgracey Posts: 14,152
    rjo__ wrote: »
    In the latest loader there is this line:

    begin clkset #$FF 'switch to 80MHz (if pll, else 50MHz)

    So... if I have a pll... does this stay the same?



    together with these lines at the bottom:

    waita long 25+12-6 '40+20-6
    waitb long 25-6 '40-6

    And... I just use the commented value.

    thanks

    That MainLoader actually gets compiled into PNut.exe. The app patches in the correct values for each case. As of yet, I haven't made any compiles (FPGA included) which use the PLL. So, 50MHz is all we've got now.
  • rjo__rjo__ Posts: 2,114
    Thanks Chip,

    Was tired when I wrote that... figured it out later, but was occupied and couldn't get back soon enough.
    I keep finding things in the P2 that I had no idea were going to be there... So, to say I am excited is an understatement.

    Can't wait for the new P123 board:)

    Thanks

    Rich
  • evanhevanh Posts: 15,915
    edited 2015-10-01 04:43
    Hehe, couldn't keep Chip away with a title like that.

    Now seems to be a good time for firing questions at Chip anyway. The first FPGA images are out and he's into debugging and sorting out confusions/fix-ups and whatnot. Documentation will be improving on the fly.
  • rjo__rjo__ Posts: 2,114
    I think Chip is busy... so this seems like a good time to ask. Let's see if we can get this answered by the time he comes back:)

    Is this legal?

    setq whatever 'ignore my syntax
    waitx
  • SeairthSeairth Posts: 2,474
    edited 2015-10-04 14:10
    No?

    Edit: What are you hoping it would do?
  • rjo__rjo__ Posts: 2,114
    the waitx... simply represents continuing code. I wasn't very clear. So the idea is ... can we set up the transfer... and then do something else before we use it. If "no," I'm happy.
  • SeairthSeairth Posts: 2,474
    rjo__ wrote: »
    the waitx... simply represents continuing code. I wasn't very clear. So the idea is ... can we set up the transfer... and then do something else before we use it. If "no," I'm happy.

    SETQ/SETQ2 must immediately precede the instruction it's augmenting. Just like AUGx and ALTx.
  • jmgjmg Posts: 15,173
    Seairth wrote: »

    SETQ/SETQ2 must immediately precede the instruction it's augmenting. Just like AUGx and ALTx.

    These must immediately precede the instruction it's augmenting opcodes scream for an Assembler support that takes all operands in one mnemonic.

    That makes code clearer, more edit-safe and guarantees the must immediately precede condition is always met.

    They work as they are now, so that ASM support can come later... (but not too much later ;) )
  • TorTor Posts: 2,010
    edited 2015-10-07 01:43
    jmg wrote: »
    Seairth wrote: »

    SETQ/SETQ2 must immediately precede the instruction it's augmenting. Just like AUGx and ALTx.

    These must immediately precede the instruction it's augmenting opcodes scream for an Assembler support that takes all operands in one mnemonic.
    Yes. I was thinking the same. Some other CPUs "extend" their single-opcode instruction space by introducing a prefix opcode followed by another opcode. Naturally they must stay together, and all assemblers I've seen will use a single mnemonic for that. So even though it's not exactly the same case I would say there's definitely precedence.

    Edit: Although, having seen SETQ used in example programs, it's not that bad. Not comparable to my single- vs. multi-opcode case.


  • rjo__rjo__ Posts: 2,114
    Thanks... that's what I thought, but wasn't sure.
  • rjo__rjo__ Posts: 2,114
    edited 2015-10-06 13:38
    let's say that we have cog2 and cog3 doing nothing but waiting for a positive edge to occur on the same pin. When that occurs, the counter is recorded by each cog.

    Whle the two cogs are in WAITEDG, we send a single positive transition to that pin. What will the difference be in the recorded counter values?
  • SeairthSeairth Posts: 2,474
    rjo__ wrote: »
    let's say that we have cog2 and cog3 doing nothing but waiting for a positive edge to occur on the same pin. When that occurs, the counter is recorded by each cog.

    Whle the two cogs are in WAITEDG, we send a single positive transition to that pin. What will the difference be in the recorded counter values?

    They should be the same value. The same signal is routed to every cog simultaneously, each of which maintain their own interrupt flags.
  • SeairthSeairth Posts: 2,474
    edited 2015-10-06 15:41
    jmg wrote: »
    Seairth wrote: »

    SETQ/SETQ2 must immediately precede the instruction it's augmenting. Just like AUGx and ALTx.

    These must immediately precede the instruction it's augmenting opcodes scream for an Assembler support that takes all operands in one mnemonic.

    That makes code clearer, more edit-safe and guarantees the must immediately precede condition is always met.

    They work as they are now, so that ASM support can come later... (but not too much later ;) )

    Agreed! Something like:

    AUGD/S: ##value
    ALTDS : [value]
    SETQ : handle as a third parameter variant for all supported instructions (error if ## or [] encountered)
    SETQ2 : same as SETQ, but value is wrapped like ALTDS above.

    Edit: changed {} to [], as @Electrodude pointed out the conflict with block comments.
  • ElectrodudeElectrodude Posts: 1,657
    edited 2015-10-06 15:28
    Why {value}? That means block comment. How about [value] instead?

    The raw AUGD/S, ALTDS, SETQ, and SETQ2 instructions should definitely still remain, even with them usually being implicit.
  • SeairthSeairth Posts: 2,474
    Electrodude wrote: »
    Why {value}? That means block comment. How about [value] instead?

    The raw AUGD/S, ALTDS, SETQ, and SETQ2 instructions should definitely still remain, even with them usually being implicit.

    You are correct. I updated my prior comment accordingly. Also, I agree that the actual instructions still need to be available.

    As an aside, I do find it weird when using AUGD/S that you provide the full 32-bit value, not just the 23-bit part that is actually encoded. I understand why it's done this way, but I don't like it. :) If the shorthand version is implemented, I suggest changing AUGD/S instruction to take an actual 23-bit value.
  • rjo__rjo__ Posts: 2,114
    Seiairth

    Thank you very much. That is just fabulous... in my mind, that reduces bandwidth problems so much it is practically ridiculous.

    I knew how to test it, just no fing time to actually test these days:)

    My dream ticket?

    Ken for President... Chip for Secretary of Defense.

    Unbelievable work.
  • rjo__rjo__ Posts: 2,114
    In Chip's sin/cos example. He writes 8 bit sin values to byte1 and cos values into byte0 of the 512 LUT longs.

    From this, I expected to see bytes 3 and 4 with either a variety of values or zero...

    but I get all zeroes in bytres 2 and 3 for the LUT #0->lut#127...

    and then $FF in the upper two bytes of LUT#128->LUT#382...

    and then zeroes again for the upper two bytes of LUT#383->LUT#511.

    I can write values to those locations and they show up as expected when I read them back. So, I think it is just a matter of me not understanding how those values got there in the first place.





  • rjo__rjo__ Posts: 2,114
    While I am at it. I know that we are still in a deterministic period of Propeller development... and I should be able to figure this out for myself, but for efficiency sake... If you happen to know how many clocks it takes to rotate a 2D point... just off the top of your head:)
  • cgraceycgracey Posts: 14,152
    Those values returned from QROTATE are -127 to +127, in longs. There are sign-extended by 24 bits. That's where all those $00 and $FF bytes come from.
  • rjo__rjo__ Posts: 2,114
    thanks
  • rjo__rjo__ Posts: 2,114


    I am the best programmer on my block because there are no other programmers on my block. As soon as another one moves in, I will be in second place.

    I am working on a programming stub for pipelined processes... where each cog gets assigned to a process... cog 1 does something... sends the results back to hub... Cog2 takes that result does something with it and sends the results back to the hub and so on... I know how to do all of this, using my own special style... but I would actually like to do it in the way that the P2 is built to do it.

    So, here is my question... are either the mail boxes or the semaphores intended for inter-cog signaling in this kind of context?

    If not, I can use a long or two of hub ram and do it.
  • rjo__rjo__ Posts: 2,114
    edited 2015-10-23 23:49
    That doesn't read very well... the issue is a cog signaling the next cog that the data is ready.. a trivial issue really... but is that what either the mailboxes or semaphores are intended to do?

  • SeairthSeairth Posts: 2,474
    Yes. :)
  • evanhevanh Posts: 15,915
    Yes, but you're not using it to any great effect. Shared RAM is all you are after, and you have the whole of HubRAM for this.

    Double-buffering (Circular-buffering) is the formal term for what you are doing. This is an entirely private mechanism so you have no need to use any special hardware nor formal sharing scheme. Just make up start and end pointers and Bob's your uncle.
  • rjo__rjo__ Posts: 2,114
    That was going to be my next question...you ruined it!!!
    just kidding.


    thanks guys.
  • evanhevanh Posts: 15,915
    Only time there might be conflict is if both tasks write the pointers. But it should be one writing and one reading so no issue there.
Sign In or Register to comment.