Shop OBEX P1 Docs P2 Docs Learn Events
New DIR/OUT bit-level instructions — Parallax Forums

New DIR/OUT bit-level instructions

cgraceycgracey Posts: 14,152
edited 2016-08-13 11:55 in Propeller 2
While writing the ROM code, it was quite frustrating to keep track of which port various pins were on, as operations to a pin's DIR/OUT bits need to know DIRA/DIRB and OUTA/OUTB. Conveniently, the smart pin instructions work solely from the pin number, which is very straightforward.

I have wanted instructions that can manipulate a pin's DIR/OUT bits by the pin number for quite a while, but I figured the timing would be impossible when it came to the data forwarding circuitry. I realized tonight that it's not a problem, actually, because we have result-write redirection circuitry and those DIR/OUT bits are always available from their flops, unlike the cog RAM.

It turned out to be quite a simple matter to add instructions that manipulate the DIR/OUT bits via the pin number, and support data-forwarding, as well. On the Cyclone V, it only added 42 ALM's to each cog.

Here are the new instructions:
CCCC 1101011 ZCL DDDDDDDDD 001000000	DIRL	D/#	(pin D/# DIR bit = 0,  IN bit -> C/NZ)
CCCC 1101011 ZCL DDDDDDDDD 001000001	DIRH	D/#	(pin D/# DIR bit = 1,  IN bit -> C/NZ)
CCCC 1101011 ZCL DDDDDDDDD 001000010	DIRC	D/#	(pin D/# DIR bit = C,  IN bit -> C/NZ)
CCCC 1101011 ZCL DDDDDDDDD 001000011	DIRNC	D/#	(pin D/# DIR bit = !C, IN bit -> C/NZ)
CCCC 1101011 ZCL DDDDDDDDD 001000100	DIRZ	D/#	(pin D/# DIR bit = Z,  IN bit -> C/NZ)
CCCC 1101011 ZCL DDDDDDDDD 001000101	DIRNZ	D/#	(pin D/# DIR bit = !Z, IN bit -> C/NZ)
CCCC 1101011 ZCL DDDDDDDDD 001000110	DIRN	D/#	(pin D/# DIR bit = !,  IN bit -> C/NZ)
CCCC 1101011 ZCL DDDDDDDDD 001000111	TESTIN	D/#	(pin D/#               IN bit -> C/NZ)

CCCC 1101011 ZCL DDDDDDDDD 001001000	OUTL	D/#	(pin D/# OUT bit = 0,  IN bit -> C/NZ)
CCCC 1101011 ZCL DDDDDDDDD 001001001	OUTH	D/#	(pin D/# OUT bit = 1,  IN bit -> C/NZ)
CCCC 1101011 ZCL DDDDDDDDD 001001010	OUTC	D/#	(pin D/# OUT bit = C,  IN bit -> C/NZ)
CCCC 1101011 ZCL DDDDDDDDD 001001011	OUTNC	D/#	(pin D/# OUT bit = !C, IN bit -> C/NZ)
CCCC 1101011 ZCL DDDDDDDDD 001001100	OUTZ	D/#	(pin D/# OUT bit = Z,  IN bit -> C/NZ)
CCCC 1101011 ZCL DDDDDDDDD 001001101	OUTNZ	D/#	(pin D/# OUT bit = !Z, IN bit -> C/NZ)
CCCC 1101011 ZCL DDDDDDDDD 001001110	OUTN	D/#	(pin D/# OUT bit = !,  IN bit -> C/NZ)
CCCC 1101011 ZCL DDDDDDDDD 001001111	TESTNIN	D/#	(pin D/#               IN bit -> NC/Z)

These instructions simplify code quite a bit, especially when you are using smart pins.

Comments

  • Peter JakackiPeter Jakacki Posts: 10,193
    Yay! that's what I've been looking for. That whole A/B thing was darn right annoying and cumbersome.
  • cgraceycgracey Posts: 14,152
    edited 2016-08-13 12:32
    I also realized that only one edge event was totally insufficient, given the requirement of keeping up with a few smart pins. So, I made four generic events which can each be set to track pin edges (and states!), LUT reads and writes, and lock changes. This works really well. Being able to interrupt based on INA/INB pin states (not edges) is really important, because it keeps you away from chicken and egg problems having to do with missing an initial smart pin IN rise.

    I also made some instructions to trigger interrupts, regardless of events: TRGINT1/TRGINT2/TRGINT3. I needed these in my auto-baud detector ISR, to be sure that the serial-receive ISR always executes after a re-frame. In some cases, people will find them necessary to keep things in order when multiple events are triggering and you want to be sure that an ISR executes.
  • cgraceycgracey Posts: 14,152
    Peter Jakacki wrote: »
    Yay! that's what I've been looking for. That whole A/B thing was darn right annoying and cumbersome.

    Yeah, I was thinking that this A/B matter was going to frustrate people and demotivate them. It was making things quite unpleasant.
  • RaymanRayman Posts: 14,641
    That is nice. It was a bit of a pain to move USB code from Port A to Port B. Not a huge problem, but rather inconvenient as had to search whole code for any ina or dira or outa and change them.

    There are some cases where I'd have to add an instruction to operate on more than one pin, but I think that's worth it to have it easier to move between ports.
  • Bill HenningBill Henning Posts: 6,445
    Love it. I can already see a ton of uses for these new instructions!
  • jmgjmg Posts: 15,173
    cgracey wrote: »
    Here are the new instructions:
    ...
    These instructions simplify code quite a bit, especially when you are using smart pins.

    Looks good.
    Are there not already some Boolean opcodes ?
    Would it make sense to follow a more common mnemonic approach to bit-level opcodes.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2016-08-13 23:24
    As soon as Chip posted these new instruction I immediately applied them to Tachyon and reduced the code snippets to 50% which also increases the speed of execution. I can see that although more standard mnemonics would be good I can also see that would not be so simple since we only have a single operand. The OUT and DIR instructions are already a standard for their class :)

    EDIT: perhaps dirh becomes setdir and outl becomes clrout etc

    @Chip: I don't think this would be possible but when I do an OUT I certainly would like the DIR set accordingly and automatically which I normally have to handle with another instruction. 
    		outl	ss			' chip enable
		dirh	ss
  • cgraceycgracey Posts: 14,152
    edited 2016-08-13 23:32
    The problem with affecting both the DIR and OUT registers in a single instruction is that data forwarding would have to grow to accommodate TWO potential register values, not just one. Maybe there's a simple way to do it.

    Prop2-Hot did both, but logic was no object. Neither was power.
  • cgraceycgracey Posts: 14,152
    I thought more about this matter of affecting both DIR and OUT bits and it's just not practical. Not only would the data forwarding be complicated, but we would need to go beyond the current 32-bit result conduit. What we have now is pretty good.
  • Peter JakackiPeter Jakacki Posts: 10,193
    cgracey wrote: »
    I thought more about this matter of affecting both DIR and OUT bits and it's just not practical. Not only would the data forwarding be complicated, but we would need to go beyond the current 32-bit result conduit. What we have now is pretty good.

    Couldn't hoit to ask and it might have been a "yeah sure, no problems" though that didn't seem probable. I had been thinking of actual hardware between the OUT and DIR to effect this though.

  • Cluso99Cluso99 Posts: 18,069
    Good news Chip. I discovered this too, but just worked around it.
Sign In or Register to comment.