Shop OBEX P1 Docs P2 Docs Learn Events
Possible SPIN float or bigint support? — Parallax Forums

Possible SPIN float or bigint support?

avsa242avsa242 Posts: 452
in Propeller 1
Hi @cgracey, @ersmith, @"Roy Eltham"

Would any of you (or anyone, really) be amenable to getting one or both of some kind of fixed-point (runtime) decimal/not-necessarily-whole-number support and/or a 64bit int (longlong, dlong, qword, int64?) in openspin or fastspin sometime in the future (preferably in openspin, since it produces compact bytecode output)? I know this may raise some people's hackles, and may be totally out of the question for technical reasons, but I'm running into more and more devices for which writing a driver is painstaking when e.g., sensor values need to be calculated to some absolute scale (Bosch, Melexis, TI devices I find, especially) that either yields small fractional numbers or those far in excess of the Prop's signed 32-bit long. I've used objects like F32 or UMath64 for some things before, but I'm also not talking about a simple var = 0.123 * 2 or var = 2^48 type operation here. Rather, formulas that are already a paragraph or half a page long or more in native form; it becomes too difficult to follow, either for me or for someone trying to read my code, when implemented with one of the former. I absolutely adore SPIN, but this is one thing that makes writing some software so difficult, I find myself shelving it, at least for an extended period of time, to come back to it later and try to "chisel away a little bit more."
Thanks for your consideration even if the answer is no!

Cheers,
Jesse

Comments

  • PropGuy2PropGuy2 Posts: 360
    I agree! I was working on a rather big project and it was going nicely. Then it came to getting a Si570 frequency synthesizer chip to work. Horrors! - Spin only had "signed" 32-bit longs, I needed UN-signed math for this synthesizer chip. Three weeks (3 very long weeks) later and a lot of rabbit holes, I got everything to work with the help of UMath64 and some very clever code. Not fun.
  • ersmithersmith Posts: 6,053
    The trouble is that the Spin language has no notion of data types, so an expression like "x+y" can only be interpreted as integer addition (there is no way to know that "x" or "y" is a floating point value). I guess it would be possible to add new operators like "+." and "*." that do floating point math on the 32 bit values, but that would be very prone to errors if people mix up "+" and "+.".

    fastspin does support floating point arithmetic in C and BASIC, and allows you to call functions written in those languages from Spin, so you can do something like: 
    ' File calc.bas
' method dist:
' calculate floating point distance from (0,0) to (x,y)
' "single" is the BASIC single precision (32 bit) floating point type
function dist(x as single, y as single) as single
  return sqr(x*x + y*y)
end function

    ' File main.spin
OBJ
   b: "calc.bas" ' b is an object created from BASIC
PUB delta(x, y)
  return b.dist(x, y)
  • avsa242avsa242 Posts: 452
    I figured it wouldn't be feasible, but thought it was worth asking. :smile:
    What about 64-bit integers? I was thinking that since Spin has an operator that returns the upper 32 bits of a result (**) that it might possibly be only a few steps away? But then I'm not a compiler or interpreter writer :blush:

    Yeah, I thought about the interoperability of C and SPIN in fastspin - and this would probably be the easiest way in the short term. Could probably use that route for 64-bit ints, also? I just wanted to know if there was a path down the bytecode way also, for when programs get bigger...
  • msrobotsmsrobots Posts: 3,709
    Maybe we should start some crowd founding to provide @ersmith with some funds to encourage him to target either chips Spin2 bytecode (running target) or @"Peter Jakacki"'s TAQOZ bytecode (at least in rom) from FastSpin.

    In my (not so humble) opinion that would be the best way to go because the ability to mix BASIC, C, SPIN and PASM in one Program is one of the major features of FastSpin. As of now he targets P1 and P2 in LMM or PASM.

    Like @avsa242 said programs get bigger. Being able to use bytecode for not time critical stuff is something proven to work with the P1 memory restrictions, same will work for the P2.

    Since I never wrote a compiler I have no clue how much work this would be. But looking at his results so far it seems to me that he is a hell of astonishing programmer, lets support him a bit.

    Like I did with the P2-Eval I will make sure he gets a P2-Production as soon as Parallax sells them, same goes for the P2D2.

    I am not a C guy at all but it seems to me that he is now adding some standard library code what might lead to running Blockly generated C code to run thru FastSpin (@"Ken Gracey" are you following this?), that would be a major step to get the P2 into Parallaxes Education System.

    I never had a P2 FPGA (sometimes I am frugal) so I did not use Pnut a lot, as soon as FastSpin (and Spin2gui) was there I was happy.

    Enjoy!

    Mike
  • avsa242avsa242 Posts: 452
    If he's interested/willing/able I'd be more than happy to send money his way...
  • ersmithersmith Posts: 6,053
    It'd certainly be great if people could help support spin2gui/fastspin development -- besides the obvious expense of development time, there are things like software signing keys and additional hardware that'd be nice to buy. I'm in the process of setting up a Patreon account, and I'll post details when that's ready.

    What features do you guys consider the highest priority?

    (1) long (64 bit) integers
    (2) long (64 bit) floating point
    (3) bytecode output
    (4) file I/O libraries
    (5) automatic updates to spin2gui

  • avsa242avsa242 Posts: 452
    For me personally, despite starting this thread, (3), then (1)...I'll leave (2) dangling in third place only because I'm guessing it'd be a lot harder to implement than (1) (put it this way: If I had to choose between only one of the two, I'd choose 64bit ints)
  • jmgjmg Posts: 15,173
    ersmith wrote: »
    It'd certainly be great if people could help support spin2gui/fastspin development -- besides the obvious expense of development time, there are things like software signing keys and additional hardware that'd be nice to buy. I'm in the process of setting up a Patreon account, and I'll post details when that's ready.

    What features do you guys consider the highest priority?

    (1) long (64 bit) integers
    (2) long (64 bit) floating point
    (3) bytecode output
    (4) file I/O libraries
    (5) automatic updates to spin2gui

    There are also some cases where an interim 64 but result is enough, which may give some low hanging fruit ?
    Things like scaling, where you might do A*B/C, where the (A*B) needs to be 64b, but the final answer can be 32b.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    jmg wrote:
    Things like scaling, where you might do A*B/C, where the (A*B) needs to be 64b, but the final answer can be 32b.
    Yup. My umath object does that.

    -Phil
  • avsa242avsa242 Posts: 452
    That's what made me think 64bit int might possibly be the easier one to implement, since the current Spin already has a lower 32bit result of multiply, and an upper 32bit result. I figured the two could be rolled up into whatever assemblage of bytecodes would be equivalent to writing it out longhand, but that the syntax would be the simpler a*b/c, as you say
  • msrobotsmsrobots Posts: 3,709
    I would love 5 because I look always if there is a new version every time I can squeeze some Propeller time in. Some people do not like it, so it should be optional.

    1 and 2 are basically (pun intended) solved by the example you gave.

    3 would be fantastic - but Chips Interpreter is not ready yet and the new TAQOZ in rom is in the next P2.

    That leaves 4.
    I had not thought about that one. Nice! Having file i/o consistent over all languages would be a perfect addition. And you are thinking about adding file support to micro python anyways, it might be a good idea to do that together.

    Enjoy!

    Mike
  • ersmithersmith Posts: 6,053
    msrobots wrote: »
    1 and 2 are basically (pun intended) solved by the example you gave.
    No, actually. The example I gave shows how to use 32 bit floats from Spin via BASIC. None of the fastspin languages currently supports 64 bit arithmetic.
    3 would be fantastic - but Chips Interpreter is not ready yet and the new TAQOZ in rom is in the next P2.
    How important is it that the bytecode be the same as Chip's?

    It seems like there are 4 choices for fastspin bytecode output:

    (a) Spin1 bytecode (runs natively on P1, uses Cluso's or some similar interpreter on P2)
    (b) Spin2 bytecode (we would need to wait for Chip's P2 interpreter, and then would need a port to P1)
    (c) Tachyon/TAQOZ wordcode: I'm not even sure this is possible, I haven't looked at it
    (d) A custom bytecode designed for fastspin

    Option (a) is tempting, but it has some big disadvantages too: some fastspin features (like inline assembly) could not be supported by the P1 bytecode, and others (unsigned arithmetic) would be difficult.

    Option (d) is the one that would allow for the best support. But I worry that no matter how good it is, if it isn't the "official" Spin bytecode people would not use it.

  • avsa242avsa242 Posts: 452
    Would (d) replace the one running in cog 0 on startup, i.e., the one from ROM (obviously not persistently - I just mean after startup, cog 0 gets restarted with the custom interpreter)? If so, I think if people understood that clearly, that it wouldn't somehow be running inside the existing one or need to dedicate a second cog - that may help alleviate some feelings that some resource is being "wasted," other than the ROM interpreter not being used...
  • msrobotsmsrobots Posts: 3,709
    ersmith wrote: »
    msrobots wrote: »
    1 and 2 are basically (pun intended) solved by the example you gave.
    No, actually. The example I gave shows how to use 32 bit floats from Spin via BASIC. None of the fastspin languages currently supports 64 bit arithmetic.
    3 would be fantastic - but Chips Interpreter is not ready yet and the new TAQOZ in rom is in the next P2.
    How important is it that the bytecode be the same as Chip's?

    It seems like there are 4 choices for fastspin bytecode output:

    (a) Spin1 bytecode (runs natively on P1, uses Cluso's or some similar interpreter on P2)
    (b) Spin2 bytecode (we would need to wait for Chip's P2 interpreter, and then would need a port to P1)
    (c) Tachyon/TAQOZ wordcode: I'm not even sure this is possible, I haven't looked at it
    (d) A custom bytecode designed for fastspin

    Option (a) is tempting, but it has some big disadvantages too: some fastspin features (like inline assembly) could not be supported by the P1 bytecode, and others (unsigned arithmetic) would be difficult.

    Option (d) is the one that would allow for the best support. But I worry that no matter how good it is, if it isn't the "official" Spin bytecode people would not use it.

    Since the bytecode Interpreter has to be loaded together with the bytecode [except (a) on P1] I think it does not matter.

    My simple thinking was that it might be more easy to use a existing interpreter. As often I seem to be wrong.

    If (d) would give best support - go for it. PropGcc for P1 and its CMM interpreter is also not compatible with Spin1 byte codes but is used pretty often. And I never heard anybody complaining that TAQOZ does not create Spin1 byte code.

    Someone here on the forum mentioned the idea that since the interpreter needs to get soft loaded anyways a smart compiler could just include 'used' byte codes to optimize it down in size.

    And I am quite sure that you do not need to worry about people not using FastSpin.

    Enjoy!

    Mike
Sign In or Register to comment.