Spin2 Interpreter

123578

Comments

  • msrobots wrote: »
    Slowly this ship turns in the right direction. @ersmith is the fore runner, I fight with TAQOZ to get it cooperative (and finally @Peter Jakacki is helping me to do that, what a wonderful thing) Now getting Chip on board, YES the multi language P2.


    + 1, this is looking very promising. Could be a great step forward.
    In science there is no authority. There is only experiment.
    Life is unpredictable. Eat dessert first.
  • evanh wrote: »
    cgracey wrote: »
    One-time-use boot code is going to be at the very start of memory. I don't think it will ever need to run twice. It might as well clean up after itself (setq+wrlong from cog) and open up a nice little buffer. And it's very convenient if the buffer starts at $00000 and it goes to some 2^n-1 address.
    There's no conflict with that idea. These special reserved locations are really only reserved for the boot-up code. After they've served the parameter passing purpose you don't have to keep them reserved.

    But they do need to be agreed upon. The earlier, the better.

    Not as worried about where the various booters read their arguments once for setting up the initial clkfreq/mode, but after the init is done I do like the end result of keeping the first 64 bytes free for mailbox or other use without having any holes in the middle of that block. 8 COGs * 2 longs/COG for mailbox request/args = 64 bytes like Chip is talking about. It could be nice after bootup to have the "official" CLKFREQ/MODE values get stored at 0x40 and 0x44 to allow this space. Obviously only the SPIN booter should really ever need to clear out this memory once at reset, and we don't want it cleared on any later SPIN invocation by other languages.

    Keeping things free higher up in the immediate accessible low memory for vectors above 0x60 (or perhaps it would now be 0x68) allows expansion of the SPIN2 language as well. Chip mentions up to 96 word vectors in his code, consuming memory from 0x40-0xff. I sort of see a possibility for putting in expanded vectors there for putch/getch type operations on stdin/stdout etc, or alternatively use some mailboxes for this - sort of like OS service calls. That may in future allow multiple COGs (potentially running different languages) to share code controlling a common resource like a serial port for debug output for example, or for passing data between them using pipes in shared memory etc, or even for requesting access to SD or FLASH blocks, though there are various ways to achieve this type of thing. We don't want to have to go invent a full OS for doing this right now, but just have the flexibility to support things like that later.

    The only downside to doing changes in the vector area is that it might make the SPIN2 implementation a bit of a moving target over time. On the P1 the interpreter was locked into ROM and stayed fixed, but on the P2 it is now RAM based. That could become a problem with incompatibility if some SPIN2 objects depend on different versions/services of the SPIN2 interpreter. We may then need a getVersion() service call. Arrgh...No.
  • Talking about mailbox space is a red herring to agreeing on the addresses to use for these parameters. The two topics are independent with no conflict.

    "We suspect that ALMA will allow us to observe this rare form of CO in many other discs.
    By doing that, we can more accurately measure their mass, and determine whether
    scientists have systematically been underestimating how much matter they contain."
  • evanh wrote: »
    There's no conflict with that idea. These special reserved locations are really only reserved for the boot-up code. After they've served the parameter passing purpose you don't have to keep them reserved.

    But they do need to be agreed upon. The earlier, the better.

    The clock frequency and mode need to be in an agreed upon place whenever we hand off between languages, not just at boot time.

    I give up. @cgracey will do whatever he wants, and I'll do whatever I want and TAQOZ will do what it always has (since it's in the ROM we can't change that). Interoperability would have been nice, but we had this discussion months ago and I thought we had agreed on a standard. Apparently not. c'est la vie, it's typical of the Propeller world that everyone goes off and does their own thing
  • ersmith wrote: »
    The clock frequency and mode need to be in an agreed upon place whenever we hand off between languages, not just at boot time.
    A language can internally manage separate addresses if it likes. Just as long as it does the initial pickup from the agreed addresses.

    "We suspect that ALMA will allow us to observe this rare form of CO in many other discs.
    By doing that, we can more accurately measure their mass, and determine whether
    scientists have systematically been underestimating how much matter they contain."
  • Hi
    I give up. @cgracey will do whatever he wants, and I'll do whatever I want and TAQOZ will do what it always has (since it's in the ROM we can't change that). Interoperability would have been nice, but we had this discussion months ago and I thought we had agreed on a standard. Apparently not. c'est la vie, it's typical of the Propeller world that everyone goes off and does their own thing

    I feel your pain.
    How many times have people tried to get a consensus on some thing or other- and ended up going their own way!

    Must admit- I'm not immune...

    Dave
  • Been down that path with P1. No matter how hard a few of us tried, there was no agreement that it was needed, let alone what and where. :(
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • My guess is that no matter how good the various other tools are most Parallax customers will use what Chip creates. That seems to have been true for P1. We had lots of other tools but most people seemed to stick with the PropTool unless they ran on a platform other than Windows.
  • ersmith, can't you just fork Chip's Spin2 to make it the way you want?
    Prop Info and Apps: http://www.rayslogic.com/
  • Guys, there has to be agreement on this. The flaw in the clock setting hardware means that not following a convention will create intermittent boot failures. There's no other way to head it off.

    "We suspect that ALMA will allow us to observe this rare form of CO in many other discs.
    By doing that, we can more accurately measure their mass, and determine whether
    scientists have systematically been underestimating how much matter they contain."
  • ersmith wrote: »
    evanh wrote: »
    There's no conflict with that idea. These special reserved locations are really only reserved for the boot-up code. After they've served the parameter passing purpose you don't have to keep them reserved.

    But they do need to be agreed upon. The earlier, the better.

    The clock frequency and mode need to be in an agreed upon place whenever we hand off between languages, not just at boot time.

    I give up. @cgracey will do whatever he wants, and I'll do whatever I want and TAQOZ will do what it always has (since it's in the ROM we can't change that). Interoperability would have been nice, but we had this discussion months ago and I thought we had agreed on a standard. Apparently not. c'est la vie, it's typical of the Propeller world that everyone goes off and does their own thing

    No Eric, no, don't give up.

    We are getting there. I even got TAQOZ on board. @Peter Jakacki is very helpful there and we soon have a 64K image without VGA and a $48800 image with VGA-Buffer included.

    I hacked Spin2Gui with some more buttons to make integration painless. will post soon. Basically you will get a object usable from all FastSpin supported languages, gimme a couple of hours, I need to create two new TAQOZ images, Peter was busy.

    Mike
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • So as of now, just trying to understand what is already locked into stone and can't possibly be altered to some new clkfreq/clkmode storage convention Chip may use accordingly? Isn't it just the ROM TAQOZ that can't change and uses its own clock setting method from particular addresses in the boot image or is something else as well? Is the problem now just that if ROM TAQOZ tries to exit (without reset) to run code compiled for any new boot standard that does further clock settings using different addresses that might break, or is there something else to this?

    What else has been released yet in large volumes that couldn't be patched accordingly before the final P2 is released? It is the inconvenience of all various software changes or is there something else to this?

    I do also agree that a convention is required, by the way. Just wondering about real impacts of any changes. Less worried about boot storage for each image (that's more of a tool issue but it would be nice if that was consistent too for something like loadp2), but very interested in a common runtime storage of these values, so code written in various languages could all read the same frequency long etc.
  • There should be a good reason to go changing it. So far, there hasn't been anything put forward of note. Just one red herring.
    "We suspect that ALMA will allow us to observe this rare form of CO in many other discs.
    By doing that, we can more accurately measure their mass, and determine whether
    scientists have systematically been underestimating how much matter they contain."
  • Peter JakackiPeter Jakacki Posts: 8,708
    edited 2019-07-29 - 02:08:41
    I'm actually quite amenable to making changes to suit. I don't know what the best way to do it is, but the worst way is not to have "a" way. TAQOZ in ROM should be regarded as a different animal though and primarily you can think of it as a hardware debugging tool or a sanity checker. Of course you can develop code for the P2 without any tools other than an editor and a terminal, so in a way it is a fallback.

    However the TAQOZ module which is loaded into a corner of RAM is a different story, and while I'm shy to say "it's gotta be done this way", I am quite happy to work in with others. In the case of @msrobots it wasn't until he was wading in the muck that I started to get more involved (you know someone is serious when they get their hands dirty). I really admire the work that you do Eric and would love to help, so just tell me and I will see what I can do.
    Debates I stay clear of though.

    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    P2 --- TAQOZ INTRO & LINKS --- P2 SHORTFORM DATASHEET --- TAQOZ RELOADED - 64kB binary with room to spare
    P1 --- Latest Tachyon with EASYFILE --- Tachyon Forth News Blog --- More
    paypal.png PayPal me
    Brisbane, Australia
  • evanhevanh Posts: 8,035
    edited 2019-07-29 - 02:16:39
    How about $3f0-$3ff? Slot them in snugly right before first hubexec address. That's a little less arbitrary at least.

    "We suspect that ALMA will allow us to observe this rare form of CO in many other discs.
    By doing that, we can more accurately measure their mass, and determine whether
    scientists have systematically been underestimating how much matter they contain."
  • Peter JakackiPeter Jakacki Posts: 8,708
    edited 2019-07-29 - 02:32:32
    Aren't the hub read/write instructions limited to an 8-bit immediate address? It's best to stick with $0-$FF for easy and efficient to access locations. I won't give up location 0 though because that is the jump vector which is necessary for when I do a backup image so that when it resets or is powered up, it will just work. I'm not sure what mechanism Chip has for this......

    BTW, I don't follow a lot of the discussions too closely otherwise I wouldn't get anything done, so most of the detail is lost on me.

    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    P2 --- TAQOZ INTRO & LINKS --- P2 SHORTFORM DATASHEET --- TAQOZ RELOADED - 64kB binary with room to spare
    P1 --- Latest Tachyon with EASYFILE --- Tachyon Forth News Blog --- More
    paypal.png PayPal me
    Brisbane, Australia
  • roglohrogloh Posts: 1,415
    edited 2019-07-29 - 02:50:01
    evanh wrote: »
    How about $3f0-$3ff? Slot them in snugly right before first hubexec address. That's a little less arbitrary at least.

    Another option is to go from 0xF0-0xFF which are immediate addressable. If the vector space then grew downwards from 0xF0 instead of upwards from 0x40 you might keep the maximum contiguous space free from 0x0-0xN for as long as possible. Though the downside is this 0xN value might potentially change over time which isn't good. The 0x40 and up approach does at least guarantee to save you some 64 byte fixed space below it for all time, which could be very good for general mailbox or other uses. Ideally all 256 lowest bytes could be kept free for general purpose use allowing fast complete 8 bit table lookups etc, but that probably does not work out with SPIN interpreter's memory footprint and keeping it all below 4k which is a laudable goal too.

    By the way, these 16 bit SPIN vectors imply that any further SPIN language hub extensions can only fit in the lowest 64kB too. Perhaps using a 32 bit address for each was deemed wasteful and would halve the vector space available to 48, but it would at least allow code or custom overrides to be located anywhere in HUB RAM.
  • Aren't the hub read/write instructions limited to an 8-bit immediate address? It's best to stick with $0-$FF for easy and efficient to access locations.
    Good point, bugger.
    I won't give up location 0 though because that is the jump vector which is necessary for when I do a backup image so that when it resets or is powered up, it will just work. I'm not sure what mechanism Chip has for this......
    Yes, first longword is fixed as the first instruction. Prop_Hex and Prop_Txt both do a COGINIT to #0.

    I would have choosen addresses $04-$0f for the parameters myself, but I don't see any good reason to move the parameters away from existing $10-$1f.

    "We suspect that ALMA will allow us to observe this rare form of CO in many other discs.
    By doing that, we can more accurately measure their mass, and determine whether
    scientists have systematically been underestimating how much matter they contain."
  • rogloh wrote: »
    Another option is to go from 0xF0-0xFF which are immediate addressable.
    That's just messy again. The mailbox thing is a red herring.

    "We suspect that ALMA will allow us to observe this rare form of CO in many other discs.
    By doing that, we can more accurately measure their mass, and determine whether
    scientists have systematically been underestimating how much matter they contain."
  • roglohrogloh Posts: 1,415
    edited 2019-07-29 - 02:55:31
    evanh wrote: »
    rogloh wrote: »
    Another option is to go from 0xF0-0xFF which are immediate addressable.
    That's just messy again. The mailbox thing is a red herring.
    Yep messy.
    By the way I was talking about runtime storage not boot storage, in case we are on different topics.
  • rogloh wrote: »
    I was talking about runtime storage not boot storage, ...
    Runtime parameters can be copied anywhere. That's why talking about mailboxes at all makes them a red herring.

    "We suspect that ALMA will allow us to observe this rare form of CO in many other discs.
    By doing that, we can more accurately measure their mass, and determine whether
    scientists have systematically been underestimating how much matter they contain."
  • Well yes, but I like the idea about keeping runtime frequency/clkmode parameters at well known addresses so that code written in say C as well as code written in SPIN can be written to access the same value after the system is booted. It becomes useful when you have a system that includes code developed using multiple tools/languages, not just SPIN only, or just C only for example. If each language has knowledge of these special locations it will be be simpler to co-ordinate if the values ever have to be changed after bootup.

    All this red-herring talk is a red-herring for me too LOL!
  • Load/boot time is all that really matters. Beyond that is asking way too much of community cohesiveness.

    "We suspect that ALMA will allow us to observe this rare form of CO in many other discs.
    By doing that, we can more accurately measure their mass, and determine whether
    scientists have systematically been underestimating how much matter they contain."
  • I'm actually quite amenable to making changes to suit. I don't know what the best way to do it is, but the worst way is not to have "a" way. TAQOZ in ROM should be regarded as a different animal though and primarily you can think of it as a hardware debugging tool or a sanity checker. Of course you can develop code for the P2 without any tools other than an editor and a terminal, so in a way it is a fallback.

    However the TAQOZ module which is loaded into a corner of RAM is a different story, and while I'm shy to say "it's gotta be done this way", I am quite happy to work in with others. In the case of @msrobots it wasn't until he was wading in the muck that I started to get more involved (you know someone is serious when they get their hands dirty). I really admire the work that you do Eric and would love to help, so just tell me and I will see what I can do.
    Debates I stay clear of though.

    And I did.

    And that is EXACTLY a example why chip should stick to it. I currently mash FastSpin and TAQOZ together. And I CAN change the clock speed in FastSpin, while TAQOZ runs in another COG, STILL a 56 BLINK blinks in the same frequency as before. Because they agree about those settings.

    And @cgracey should too.

    Mike
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • But at this early stage we could also work in with Chip too.

    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    P2 --- TAQOZ INTRO & LINKS --- P2 SHORTFORM DATASHEET --- TAQOZ RELOADED - 64kB binary with room to spare
    P1 --- Latest Tachyon with EASYFILE --- Tachyon Forth News Blog --- More
    paypal.png PayPal me
    Brisbane, Australia
  • roglohrogloh Posts: 1,415
    edited 2019-07-29 - 04:21:10
    evanh wrote: »
    Load/boot time is all that really matters. Beyond that is asking way too much of community cohesiveness.

    Perhaps you might be right there @evanh with everyone's different opinions, though I'd sort of hope not if now is an opportunity to resolve it.

    Seems there are two issues to sort out:

    1) where the bootup parameters used for frequency/clock mode are to be written into the image. This impacts tools that generate these images and the values the booter code reads and initializes the HW to.
    2) choice of addresses where operational runtime values holding the current frequency/mode are to be kept. This impacts operational code running after initialisation.

    Decisions for 1) can make things inconvenient for tools such as loadp2 if such addresses are different and would cause tools to begin to fragment for different images/applications.

    Decisions for 2) can hinder interoperability between code written in different languages if they start to use different addresses for holding these values, and potentially cause this clock mode setting problem to happen if one language's code changes the clock state regardless of reading the existing state made by another language's code for example. This becomes an issue when you might want to have SPIN routines called by some C or Python code etc.

    Choices for 2) can also impact free memory availability in low memory if these clock settings end up also being stored there somewhere as is being discussed by Chip. Having as much low memory free for other purposes beyond simply storing clock frequencies is a good thing, particularly starting at address zero which is special, either for table use, mailbox use, whatever people may wish to use it for down the line. This is why I've talked about it. And in the worst case if both 1) and 2) somehow end up being maintained at the same addresses it might limit a nice block of contiguous zero-based immediate memory you can rely on having in the P2.
  • But at this early stage we could also work in with Chip too.

    as usual you are right. At this stage all could switch to another agreed standard location, but it should stay there, then.

    Mike
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • Guys, I don't want to drive any of you to despair. I just need to have the freedom at this stage to sculpt things optimally, in order to maintain sufficient motivation to get Spin2 working. I'm kind of tired at this stage. I think once Spin2 is working, I'll get a burst of energy. I need to get there.

    Once Spin2 is working, it can easily be modified and reformed to work in any fashion.

    Eric may choose to employ the final Spin2 syntax into his compiler and provide the fastest execution possible. It's up to him. It's harder for me to envision how some compiled language aggregator is going to pull different code together and make it all play. Seems rather O.S.-level. Maybe I can think about that later.
  • Cluso99Cluso99 Posts: 15,453
    edited 2019-07-29 - 08:36:30
    I see two issues...

    1) The location of the clockfreq and current mode. The first is a requirement by almost every program. Otherwise you cannot do any timing!! The clock mode is required if the clockfreq needs changing. This second part is problematic from the point that all running programs will need to be coded to permit such a change. While this is dangerous, at least knowing the current mode bits permits a change. Without these bits, P2 lockup is likely!!

    2) A dedicated mailbox area. This is most definitely not a red-herring and should be agreed sooner rather than later. It is a sort of OS feature. Consider this...

    Peter writes a VGA routine for a cog.
    Msrobots writes a FullDuplexSerial routine for a cog.
    Rayman writes an HDMI routine for a cog.
    Gary writes a USB routine for a cog.
    Cluso (me) writes a simple OS for a cog.
    Fred writes a PS2 Keyboard routine for a cog.

    Everyone has a different way of interfacing their object (just like we are proposing now).

    How can we use each of these objects together? Without forking each of these objects, we can’t !!!

    Now, if we agreed upon a minimum mailbox, all these objects could work together provided they adhered to the mailbox.

    This would mean the OS, and other programs could use the mailbox to dynamically use the desired objects.

    In my P1 OS, all std I/O goes via the mailbox. The OS always writes to the STDOUT and reads from STDIN. The OS does not need to know if FullDuplexSerial or VGA or TV (composite video) or USB or some new driver is being used as the STDOUT object. Similarly, it takes input from the STDIN mailbox, which could be from FullDuplexSerial or USB or PS2 Keyboard or some future object.
    My OS has some additional parameters which do CRLF or just CR, knows the screen size in rows by columns (used for output formatting in a LS or DIR command), ECHO, and a couple of other parameters.

    None of this is possible without an agreed mailbox!!! Evan, this is definately not a red-herring. I know, because in P1 I had to fork all those objects that I use to make them work.

    Postedit
    BTW None of this forces anyone to comply. I would expect commercial P2 users to just do their own thing, like we/they do on P1.

    I also use Catalina’s mailboxes to communicate with my objects in a commercial P1 product.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • Cluso99Cluso99 Posts: 15,453
    edited 2019-07-29 - 08:28:59
    Don’t forget it’s only HUB $00-$FF that is directly (immediately) addressable. $100-$1FF is used as PTRx options.

    Personally I’d like to see the whole 256 bytes reserved, with the mailbox and clock parameters working down from $FF.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
Sign In or Register to comment.