Shop Learn P1 Docs P2 Docs
Code works when object added, how possible? — Parallax Forums

Code works when object added, how possible?

RaymanRayman Posts: 12,734
edited 2022-07-24 20:36 in Propeller 2

Here's another strange behavior, that I thought I'd share.
Not asking for help with the code, just wondering how it is possible...

This FSRW, sd reading code, worked a couple years ago, but now has a problem with the assembly version of the low level driver. The cogless, inline assembly version seems to work.

So, the assembly version is broken badly and can actually destroy the filesystem.
But, trying to troubleshoot was proving difficult. It breaks debug commands too.

So, I added "jm_serial" as an object in the assembly driver, hoping I could use it for debugging.
But then, it started working!

Obviously, something is broke, but how can adding an extra object fix it?
Anyway, a bit of a mystery at the moment...

Comments

  • RaymanRayman Posts: 12,734

    BTW: I'm not sure adding "jm_serial" to the low level driver actually changes the binary size because it's already included in the top level...

  • I've seen odd things like this with the P1. It came down to some section of RAM being long aligned or not. I know the P1 needed the par to be a long sized value (when launching a PASM cog).
    I can't think of anything which needs to be long aligned with the P2 but maybe there's something similar happening here?

  • RaymanRayman Posts: 12,734
    edited 2022-07-26 22:57

    Thanks, interesting idea.
    I do remember seeing an alignl command in the dat section…
    Maybe that is broke…

  • @Rayman said:
    I do remember seeing an alignl command in the dat section…

    I wondered about that as well.
    Am I correct that ptra doesn't need to be long aligned? I see that this special register is used a lot.

    I barely felt like I was getting the hang of the P1 when the P2 came out. I haven't caught up with all the new stuff in the P2 yet.

  • RaymanRayman Posts: 12,734
    edited 2022-07-27 18:49

    Think I found the problem...
    The assembly is using a variable (delay1s) that is declared using "RES", but not given a value anywhere.

    Guess it's just winding up with a value from whatever code comes after the defined assembly...

    Kind of amazing it worked at all, this is part of a timeout scheme using pollct1...

    Not exactly sure how this is breaking debug though. Also, not clear why behavior is different in FlexProp.
    But, this is clearly bad code and I guess anything can happen...

  • RaymanRayman Posts: 12,734

    Ok, I see that you can't use "jm_serial" output along with debug. Guess that makes sense.

  • Wuerfel_21Wuerfel_21 Posts: 3,038
    edited 2022-07-27 19:32

    @Rayman said:
    Not exactly sure how this is breaking debug though. Also, not clear why behavior is different in FlexProp.
    But, this is clearly bad code and I guess anything can happen...

    If the RES is at the end of the file's last DAT block, the actual value that ends up there is undefined and depends on what the compiler chooses to put after the DAT block. In particular, in Chip's compiler this will be the bytecodes of the first function in the object (going from Spin1 experience. Might be different in Spin2). In Flexspin it will be the next object's static data (by order of ????) or VAR space if it ends up as the last DAT section.

  • RaymanRayman Posts: 12,734

    @Wuerfel_21 I checked your version of this driver and see you fixed this there, right? Or, maybe you found a version where it was already fixed?

  • Wuerfel_21Wuerfel_21 Posts: 3,038
    edited 2022-07-27 20:22

    Indeed, I remember now that some "timeout scheme using pollct1" was something stupid I had to fix.

    Moral of the story: please don't post Smile code without declaring it as such

  • RaymanRayman Posts: 12,734

    Looks like serial output, like with "jm_serial", works alongside debug commands in FlexProp.
    Both outputs get dumped to terminal.

    Kind of wish Prop Tool was like that. Appears that it hangs if you try to have both going...

  • The debug code is identical, IDK why it wouldn't work in proptool

  • RaymanRayman Posts: 12,734

    Looks like prop tool debug window gets confused by other serial output

Sign In or Register to comment.