Shop OBEX P1 Docs P2 Docs Learn Events
Is there a simple trick to take the signed 32bit count — Parallax Forums

Is there a simple trick to take the signed 32bit count

MicksterMickster Posts: 2,603
in BASIC (for Propeller)

and extend it to signed 64bit?

I can think of a few really clunky ways to achieve this but I wouldn't be surprised to learn that there is a standard (simple) technique.

Craig

Comments

  • ersmithersmith Posts: 5,909

    Which count do you mean? If you're referring to the standard system clock counter, the full 64 bit value may be read via _getcnthl():

    dim lo as ulong
dim hi as long

do
  lo,hi = _getcnthl()
  print "counter = "; hex$(hi); ":"; hex$(lo)
  pausems 1000
loop
  • MicksterMickster Posts: 2,603

    @ersmith

    Oops, my bad. Forgot to mention that I was referring to the quadrature counters :blush:

    Craig

  • ersmithersmith Posts: 5,909

    Ah. Well, if you have a signed 32 bit value and want to know what the upper word of the full 64 bit value would be, you'd just shift the lower value right by 31, like:

    function hilo_from_low(count as integer) as uinteger, integer
  var hi = count >> 31
  return count, hi
end function

    Or you could convert to a 64 bit longint, like:

    function big_from_little(count as integer) as longint
  return count
end function

    but the latter is of very limited use right now, since 64 bit integers (longint) aren't officially supported and don't fully work.

    What's the ultimate goal here?

  • MicksterMickster Posts: 2,603

    @ersmith said:

    What's the ultimate goal here?

    Keeping track of a motor encoder @ 1.6M counts/sec (a rotary axis, like a spindle)

    It would be nice to keep track of its actual position beyond the 32bit rollover. :neutral:

    Craig

  • ersmithersmith Posts: 5,909

    Well, for totally basic arithmetic you could use a longint to keep track of things -- I think add, sub, and shifts, at least, will work on longints, and probably comparisons will as well. If you want to do some more complicated work you will probably have to split the longint up into a 32 bit high, low pair, but that's easy enough to do:

    dim as longint bigcounter ' running total (signed 64 bit integer)
dim as integer count ' 32 bit quadrature count result
dim as uinteger hi, lo ' working 32 bit variables
bigcounter = 0 ' initialize 64 bit counter
' do stuff here to get 32 bit signed count
bigcounter = bigcounter + count ' should work to accumulate into the 64 bit counter
' if you need to extract the high and low:
hi = bigcounter >> 32
lo = bigcounter
  • Wuerfel_21Wuerfel_21 Posts: 4,448

    I think(tm) most of the obvious 64bit issues are gone now (literal parsing aside)

  • MicksterMickster Posts: 2,603

    Sort of thing that I had in mind except for the longint. I mean, I have seen it in the manual but the wording kinda gave me the impression of "this is it but it doesn't work yet" :lol:

    This is soooo cool, many thanks :+1:

    Craig

  • MicksterMickster Posts: 2,603
    edited 2022-07-15 10:26

    Hmm, does Hex$ know about the longint?

    Might help if I wasn't still on 5.9.6 :blush:
    Craig

  • MicksterMickster Posts: 2,603

    print hex$(68719476735)

    Only displays the lower 32 bits.

    Craig

  • ersmithersmith Posts: 5,909

    hex$() takes a uinteger parameter, so it only works on 32 bits. Someday we'll have to create a hexl$() for longints.

  • MicksterMickster Posts: 2,603
    edited 2022-07-15 13:03

    @ersmith said:
    hex$() takes a uinteger parameter, so it only works on 32 bits. Someday we'll have to create a hexl$() for longints.

    Not a problem. 64 bit counter working beautifully but I didn't know it until I split it to "lo" and "hi"....bit of a head-scratcher for a minute :lol:

    Craig

    Edit: Got some strange looks in the office when I used voice to ask Google and they heard the reply: "range of a 64 bit integer". :lol:

  • MicksterMickster Posts: 2,603

    @ersmith
    Bit of a quirk? :/

    `dim as longint sixty4A,sixty4B
    dim as uinteger hi, lo

    sixty4A = &hFFFFFFFE
    lo = &hCD2FA200

    sixty4B = sixty4A<<32
    sixty4B = sixty4B + lo

    hi = sixty4B>>32
    lo = sixty4B

    print "method 1"
    print hex$(hi)
    print hex$(lo)

    sixty4B =&hFFFFFFFECD2FA200

    hi = sixty4B>>32
    lo = sixty4B

    print
    print
    print "method 2"
    print hex$(hi)
    print hex$(lo)
    `

  • Wuerfel_21Wuerfel_21 Posts: 4,448

    That's your literal getting truncated to 32 bit: https://github.com/totalspectrum/spin2cpp/issues/215

  • MicksterMickster Posts: 2,603

    @Wuerfel_21 said:
    That's your literal getting truncated to 32 bit: https://github.com/totalspectrum/spin2cpp/issues/215

    Thanks Ada. It's no biggie. I was only preloading for testing :+1:

    Craig

  • ersmithersmith Posts: 5,909

    Yep. Longints aren't completely ready for prime time yet, although we've made some good progress on them.

  • JRoarkJRoark Posts: 1,215

    @ersmith said:
    Yep. Longints aren't completely ready for prime time yet, although we've made some good progress on them.

    Once longints arrive, I betcha you/Ada/both could knock out double-precision floats before dinner time, right? 😜

  • MicksterMickster Posts: 2,603

    Based on my tests.......looking really good now that I understand how to handle what we have :+1:

    At full speed, this thing would need to run for ~170,000 years before rollover. What the heck, that's well out of warranty anyway :smile:

    Craig

  • MicksterMickster Posts: 2,603

    @JRoark said:

    @ersmith said:
    Yep. Longints aren't completely ready for prime time yet, although we've made some good progress on them.

    Once longints arrive, I betcha you/Ada/both could knock out double-precision floats before dinner time, right? 😜

    I go along with @"Heater." 's boss (or colleague):
    "If you can't solve the problem with integers, you don't understand the problem"

    I just eliminated a bunch of floats. Lost nothing but gained significant execution speed. :+1:

    But then, my stuff is pretty simplistic :lol:

  • JRoarkJRoark Posts: 1,215
    edited 2022-07-16 17:30

    @Mickster said:
    I go along with @"Heater." 's boss (or colleague):
    "If you can't solve the problem with integers, you don't understand the problem"

    I just eliminated a bunch of floats. Lost nothing but gained significant execution speed. :+1:

    But then, my stuff is pretty simplistic :lol:

    I’ve heard that quote in different variations from several sources. And faster would definitely be better!

    Rather than hijack this thread, I’ll open a new topic in a bit where I can better explain what I’m up to and solicit some guidance.

    ADDIT: The new thread is here: https://forums.parallax.com/discussion/174704/integer-calcs-instead-of-floating-point/p1?new=1

  • ersmithersmith Posts: 5,909

    @JRoark said:

    @ersmith said:
    Yep. Longints aren't completely ready for prime time yet, although we've made some good progress on them.

    Once longints arrive, I betcha you/Ada/both could knock out double-precision floats before dinner time, right? 😜

    Unfortunately, no :(. There are a whole load of library functions like sin(), cos(), log(), etc. that will need to be modified to support 64 bits.

  • JRoarkJRoark Posts: 1,215

    @ersmith said:

    @JRoark said:

    @ersmith said:
    Yep. Longints aren't completely ready for prime time yet, although we've made some good progress on them.

    Once longints arrive, I betcha you/Ada/both could knock out double-precision floats before dinner time, right? 😜

    Unfortunately, no :(. There are a whole load of library functions like sin(), cos(), log(), etc. that will need to be modified to support 64 bits.

    Okay. So… maybe by supper then? 🤣

Sign In or Register to comment.