Shop OBEX P1 Docs P2 Docs Learn Events
Is this an undocumented feature????? — Parallax Forums

Is this an undocumented feature?????

SamMishalSamMishal Posts: 468
edited 2009-08-07 12:22 in Propeller 1
idea.gif·idea.gif I just learned something new today THANKS to Mike Green.

I did not realize that if you have a variable, say Long F, that you can access individual bytes or words of the variable by using
F.Byte[noparse][[/noparse]i] or F.Word[noparse][[/noparse]i].

Thanks Mike for that information.....


HOWEVER.......where is this in the manual.........I actually had occasion to use this previously and remember looking
all over the manual to see if this can be done and eventually had to resort to using·Byte[noparse][[/noparse]@F][noparse][[/noparse]i] instead


I am glad to see that F.Byte[noparse][[/noparse]i] can be used ...BUT....I still don't see where in the manual does it say so.....
is it something new that has been added recently???



Samuel
·

Comments

  • TimmooreTimmoore Posts: 1,031
    edited 2009-08-06 17:30
    Yes, its in hte manual look under byte for example, the last syntax variant is symbol.byte<[noparse][[/noparse]offset]>
  • SamMishalSamMishal Posts: 468
    edited 2009-08-06 17:42
    Timmoore said...
    Yes, its in hte manual look under byte for example, the last syntax variant is symbol.byte<[noparse][[/noparse]offset]>
    blush.gif aah....well I guess it is time for me to get glasses..... I have known for a while that my age is catching up
    with me but I have been in denial....well I am now entering the anger stage.....mad.gif


    Thanks Tim for the pointer.......

    Sam
    ·
  • localrogerlocalroger Posts: 3,452
    edited 2009-08-06 18:12
    F.byte[noparse][[/noparse] i ], byte[noparse][[/noparse] @F ][noparse][[/noparse] i ], and byte[noparse][[/noparse] @F + i ] all work and in fact should generate exactly the same byte code.

    Post Edited (localroger) : 8/6/2009 6:19:06 PM GMT
  • WhitWhit Posts: 4,191
    edited 2009-08-06 19:00
    SamMishal said...
    blush.gif aah....well I guess it is time for me to get glasses..... I have known for a while that my age is catching up
    with me but I have been in denial....well I am now entering the anger stage.....mad.gif
    Sam,

    Thanks for making an old guy feel like he is not alone.

    I love reading stuff like this, because then I can look it up and maybe (notice I said maybe - the memory goes after the eyes) remember it when I am looking for the info!

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Whit+


    "We keep moving forward, opening new doors, and doing new things, because we're curious and curiosity keeps leading us down new paths." - Walt Disney

    Post Edited (Whit) : 8/6/2009 7:05:29 PM GMT
  • mparkmpark Posts: 1,305
    edited 2009-08-06 19:10
    localroger said...
    F.byte[noparse][[/noparse] i ], byte[noparse][[/noparse] @F ][noparse][[/noparse] i ], and byte[noparse][[/noparse] @F + i ] all work and in fact should generate exactly the same byte code.
    They may do the same thing but they all generate different bytecode!
    ·
  • ratronicratronic Posts: 1,451
    edited 2009-08-06 20:41
    Yes mpark, I just ran into that too trying to transfer bytes from 1 object to another.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    ···································Fix it, if ain't broke!


    D Rat

    Dave Ratcliff N6YEE
  • mparkmpark Posts: 1,305
    edited 2009-08-06 21:33
    Ratronic, what were you trying to accomplish?
  • ratronicratronic Posts: 1,451
    edited 2009-08-06 21:55
    Well it's kinda of hard to explain, but I was using SamMishalls robot basic and I am receiving ascii bytes from the props port from the pc's joystick (via robot basic) and in the joystick1.spin routine I found that I could not use code.byte[noparse][[/noparse]0] and had to stick to byte[noparse][[/noparse]code][noparse][[/noparse]0] to get it to work to be able to run some dynamixel servo's.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    ···································Fix it, if ain't broke!


    D Rat

    Dave Ratcliff N6YEE
    zip
    zip
    armjoy - Archive [Date 2009.08.06 Time 14.46].zip
    28K
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2009-08-06 22:47
    mpark said...
    They may do the same thing but they all generate different bytecode!
    So which one was shorter?

    Also, it's a puzzle that F[noparse]/noparse]j].byte[noparse][[/noparse]k][/b] isn't supported, particularly given that [b]byte[noparse][[/noparse]@F[noparse][[/noparse]j[noparse][[/noparse]k] is. The former shouldn't be any harder to parse than the latter and is certainly more readable.

    -Phil
  • SamMishalSamMishal Posts: 468
    edited 2009-08-06 23:12
    Whit said...
    ·the memory goes after the eyes
    Haha.... I guess maybe you can consider the memory loss as a blessing ....
    it helps us get out of the anger stage.....since if we keep remembering our
    youthful days and compare how we used to be to the way we are we would never
    get out of the anger stage....

    Also the eyesight loss is not so bad....otherwise I would be·horrified every time I
    look to my left upon waking up·in the morning.....devil.gifnono.gif


    Sam
  • jazzedjazzed Posts: 11,803
    edited 2009-08-06 23:15
    Phil said...
    So which one was shorter?
    Build a sample with homespun or bstc list file output and find out.

    homespun -d file.spin
    bstc -ls file.spin

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    --Steve


    Propalyzer: Propeller PC Logic Analyzer
    http://forums.parallax.com/showthread.php?p=788230
  • SamMishalSamMishal Posts: 468
    edited 2009-08-06 23:36
    ratronic said...
    Well it's kinda of hard to explain, but I was using SamMishalls robot basic and I am receiving ascii bytes from the props port from the pc's joystick (via robot basic) and in the joystick1.spin routine I found that I could not use code.byte[noparse][[/noparse]0] and had to stick to byte[noparse][[/noparse]code][noparse][[/noparse]0] to get it to work to be able to run some dynamixel servo's.

    Hi Ratronics,

    The zip file does not incorporate the .BAS files.....it would be nice to see those too!!!
    Is it ok if you show us that program too???

    Thanks for your support for RobotBASIC

    Regards

    Samuel Mishal
    ·
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2009-08-06 23:41
    jazzed said...
    Build a sample with homespun or bstc list file output and find out.
    LOL! How many times have I admonished someone in the forums to "try it yourself and see"? Touch
  • ratronicratronic Posts: 1,451
    edited 2009-08-06 23:44
    OOPS sorry Samuel, here's the robot basic part of the program which is the simplest part.
    SetCommPort 5,br19200
    loop:
    Joystick 1,x,y,z,b
    x = tobyte(round(x*255))
    y = tobyte(round(y*255))
    z = tobyte(round(z*255))
    b = tobyte(b)

    serout "!","~","#","}",x,y,z,b
    goto loop

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    ···································Fix it, if ain't broke!


    D Rat

    Dave Ratcliff N6YEE

    Post Edited (ratronic) : 8/7/2009 12:25:16 AM GMT
  • jazzedjazzed Posts: 11,803
    edited 2009-08-07 00:02
    I was just tying to be helpful Phil. Glad you took it on the nicest terms. I forgot the smiley wink.gif

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    --Steve


    Propalyzer: Propeller PC Logic Analyzer
    http://forums.parallax.com/showthread.php?p=788230
  • localrogerlocalroger Posts: 3,452
    edited 2009-08-07 02:11
    @mark: They may do the same thing but they all generate different bytecode!

    Really?· That's very odd.· I noticed recently that var~ and var~~ generated exactly the same code as var := FALSE and var := TRUE which I find much more readable, which kind of makes sense since it's getting translated into a FORTH-like RPN bytecode.· The different methods of sub-byteing a long should all end up with a byte address getting calculated and a RDBYTE executed.
  • BradCBradC Posts: 2,601
    edited 2009-08-07 04:55
    localroger said...
    I noticed recently that var~ and var~~ generated exactly the same code as var := FALSE and var := TRUE which I find much more readable, which kind of makes sense since it's getting translated into a FORTH-like RPN bytecode.

    I don't know where you got that impression from..

    |===========================================================================|
Spin Block ABCD with 0 Parameters and 1 Extra Stack Longs. Method 1
Pub ABCD | X

Local Parameter DBASE:0000 - Result
Local Variable  DBASE:0004 - X
|===========================================================================|
2                       X~~
Addr : 0018:          66 1C  : Variable Operation Local Offset - 1 Assign VAR~~ Post-set
3                       X~
Addr : 001A:          66 18  : Variable Operation Local Offset - 1 Assign VAR~ Post-clear
4                       X := False
Addr : 001C:             35  : Constant 1 $00000000
Addr : 001D:             65  : Variable Operation Local Offset - 1 Write
5                       X := True
Addr : 001E:             34  : Constant 0 $FFFFFFFF
Addr : 001F:             65  : Variable Operation Local Offset - 1 Write
Addr : 0020:             32  : Return

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    lt's not particularly silly, is it?
  • mparkmpark Posts: 1,305
    edited 2009-08-07 04:56
    localroger said...
    ...I noticed recently that var~ and var~~ generated exactly the same code as var := FALSE and var := TRUE ...

    What's odd is that they do not generate the same code! Or shouldn't, anyway. What makes you think they did?
  • localrogerlocalroger Posts: 3,452
    edited 2009-08-07 12:22
    Well that's weird. I had a Spin program with quite a few var := true/false in it, and I hit F8, replaced a bunch of them with post-set and post-clear, hit F8 again, and the length didn't change. I assumed the proptool must be optimizing them out but now I see now what is actually going on is that the constants true and false are part of the interpreter and so the totally different bytecodes are the same length.

    I would still use var := true because it's much more readable.

    on edit...

    OK I now see what the difference is.· They do the same thing standalone, but if you use them to return a value, e.g. var2 := var~~ var2 gets the value before the post operation, but if you were to do var2 := (var := true) var2 would get the value after the assignment.· Don't write code like that, it makes my eyes bleed kthx.

    Post Edited (localroger) : 8/7/2009 12:49:21 PM GMT
Sign In or Register to comment.