Spin2 Interpreter

123457

Comments

  • evanhevanh Posts: 8,065
    edited 2019-07-30 - 09:41:47
    Whoa Mike,
    You're misunderstanding. What Chip is proposing now is a way to separate the problem of reliable boot, which is a prop2 specific problem, from the desires of having OS level features added.

    Once there is a separation then they can go their own ways.

    "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."
  • AJLAJL Posts: 205
    edited 2019-07-30 - 09:45:52
    evanh wrote: »
    The new proposal has a nice short name for easy reference at a later date: RCFAST hand-off

    I'm confused.

    Will people who wish to contribute a timing-critical object to the OBEX2 (or whatever it will be called) have to include a system frequency parameter in the calling convention so that it can be informed by the calling program what frequency has been set?

    Or a language agnostic compile-time constant such that every object will need to be provided as source and compiled into a monolithic code blob?

    As we lose the hardware assistance of the P1 that every object could rely on to know the system frequency, we now need agreement on the software solution to the same problem. Allocating a long for this seems a no-brainer, and adding a second long to contain the configuration word needed to shift gears (so to speak) also seems totally reasonable.

    Without at least the frequency word, having agreement on mailbox locations seems pointless.

    RCFAST hand-off works for handing control between programs, but not for coordination of modules from different authors operating in different cogs.


  • evanhevanh Posts: 8,065
    edited 2019-07-30 - 09:49:39
    AJL,
    Many objects have parameters. It's just one init parameter to pass if needed.
    "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."
  • jmgjmg Posts: 14,015
    cgracey wrote: »
    evanh wrote: »
    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.

    What about a fast booter/loader safely returning the clock mode to 20MHz (%00) on its own steam before it launches the app by doing a 'COGINIT #0,#0' ? Then, there'd be no boot problem, as there's no need for agreement.

    That only half solves the problem, as there is benefit in having all software that is running knowing the SysCLK.
    That means code in each COG can be made smarter and more tolerant of SysCLK, and if that changes then you can all keep in phase.
  • MJBMJB Posts: 1,126
    msrobots wrote: »
    ...
    [RANT]
    I mashed TAQOZ and FastSpin together. There is a thread about it. But basically I start TAQOZ in COG0 and a FastSpin compiled Program in COG1 able to talk to TAQOZ via Mailbox. Both Programs agree about the locations in HUB where the clocksettigs are.

    I CAN change the clockfreq in my FastSpin program while the TAQOZ COG0 is running. FastSpin program will change the HUB location after changing the freq. And TAQOZ still knows what freq we are running on, still knows to pulse a pin at 1,10 or 100 Hz because it knows the system frequency has changed.
    Because both programs agree on that location.
    [/RANT]
    Mike
    well - in this example Taqoz will get the new clockfreq when it reads it again.
    So the blinker would need to be prepared for this and recalculate a delta each time based on current clockfreq.

  • msrobotsmsrobots Posts: 2,936
    edited 2019-07-30 - 10:06:11
    And - sorry @Cluso99 - yes we should think about some std mailboxes, there was a big discussion without solution years ago for the P1 to agree on something and it failed.

    So lets stay with the current $14 and $18 and discuss if we could agree on some mailboxes at $10, $C, $8 and $4 if $0 jmps to the starting code.

    That could be locations for stdout,stderr,stdsd whatever if agreed on LATER,

    But for now lets PLEASE stick with the existing agreement of $14 and $18

    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.
  • jmg wrote: »
    That only half solves the problem, ...
    JMG,
    It completely solves the loading handover problem. Anything else is a separate concern and can be defined as desired.
    "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."
  • AJL wrote: »
    evanh wrote: »
    The new proposal has a nice short name for easy reference at a later date: RCFAST hand-off

    I'm confused.

    Will people who wish to contribute a timing-critical object to the OBEX2 (or whatever it will be called) have to include a system frequency parameter in the calling convention so that it can be informed by the calling program what frequency has been set?

    Or a language agnostic compile-time constant such that every object will need to be provided as source and compiled into a monolithic code blob?

    As we lose the hardware assistance of the P1 that every object could rely on to know the system frequency, we now need agreement on the software solution to the same problem. Allocating a long for this seems a no-brainer, and adding a second long to contain the configuration word needed to shift gears (so to speak) also seems totally reasonable.

    Without at least the frequency word, having agreement on mailbox locations seems pointless.

    RCFAST hand-off works for handing control between programs, but not for coordination of modules from different authors operating in different cogs.


    Exactly @AJL

    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.
  • evanhevanh Posts: 8,065
    edited 2019-07-30 - 10:18:17
    We're discussing two independent concerns, that only came into contact because the loaders are initialising the hardware clockfreq.
    "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."
  • msrobotsmsrobots Posts: 2,936
    edited 2019-07-30 - 10:21:36
    MJB wrote: »
    msrobots wrote: »
    ...
    [RANT]
    I mashed TAQOZ and FastSpin together. There is a thread about it. But basically I start TAQOZ in COG0 and a FastSpin compiled Program in COG1 able to talk to TAQOZ via Mailbox. Both Programs agree about the locations in HUB where the clocksettigs are.

    I CAN change the clockfreq in my FastSpin program while the TAQOZ COG0 is running. FastSpin program will change the HUB location after changing the freq. And TAQOZ still knows what freq we are running on, still knows to pulse a pin at 1,10 or 100 Hz because it knows the system frequency has changed.
    Because both programs agree on that location.
    [/RANT]
    Mike
    well - in this example Taqoz will get the new clockfreq when it reads it again.
    So the blinker would need to be prepared for this and recalculate a delta each time based on current clockfreq.

    nono, @MJB it simply works, becaue both COGS agree about the location of clockfreq. So I can switch to 80Mhz (in Spin) or to 160 or 200, does not matter, 56 BLINK blinks in the same frequency. It just works. Because @ersmith and @Peter Jakacki agree about the HUB location of clockfreq.

    EDIT - ok, I need to send "56 BLINK" again after changing the clockfreq so TAQOZ read the clockfreq again.

    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.
  • MJBMJB Posts: 1,126
    msrobots wrote: »
    MJB wrote: »
    msrobots wrote: »
    ...
    [RANT]
    I mashed TAQOZ and FastSpin together. There is a thread about it. But basically I start TAQOZ in COG0 and a FastSpin compiled Program in COG1 able to talk to TAQOZ via Mailbox. Both Programs agree about the locations in HUB where the clocksettigs are.

    I CAN change the clockfreq in my FastSpin program while the TAQOZ COG0 is running. FastSpin program will change the HUB location after changing the freq. And TAQOZ still knows what freq we are running on, still knows to pulse a pin at 1,10 or 100 Hz because it knows the system frequency has changed.
    Because both programs agree on that location.
    [/RANT]
    Mike
    well - in this example Taqoz will get the new clockfreq when it reads it again.
    So the blinker would need to be prepared for this and recalculate a delta each time based on current clockfreq.

    nono, @MJB it simply works, becaue both COGS agree about the location of clockfreq. So I can switch to 80Mhz (in Spin) or to 160 or 200, does not matter, 56 BLINK blinks in the same frequency. It just works. Because @ersmith and @Peter Jakacki agree about the HUB location of clockfreq.

    EDIT - ok, I need to send "56 BLINK" again after changing the clockfreq so TAQOZ read the clockfreq again.

    Mike

    that's what I mean -
    there is no sysclock has changed interrupt ;-)

    but changing sysclock in the middle of some program is not what you often do ...
    maybe for power savings ...
    the programmer can design this as he likes.

    but a standard way to find out the current sysclock would be REALLY helpful
    if you think about OBEX objects collaboration.
  • Peter JakackiPeter Jakacki Posts: 8,725
    edited 2019-07-30 - 10:36:35
    If I change sysclock from TAQOZ itself, it also recalculates baudrate and VGA NCO based on the new frequency. So if it is running at 160MHz and I type 300 P2MHZ then the console will continue running at the same baudrate and the VGA will continue at the same pixel frequency.
    So it can be done dynamically but mostly it is done during reset.

    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    P2 --- The LOT --- 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
  • I agree with msrobots. Chip, at this point I think it would be best to conform with what the other tools are doing instead of trying to impose your own arbitrary rules.
  • evanh wrote: »
    AJL,
    Many objects have parameters. It's just one init parameter to pass if needed.

    Assuming it only needs to know the sysclock rate at init....
  • MJB wrote: »
    msrobots wrote: »
    MJB wrote: »
    msrobots wrote: »
    ...
    [RANT]
    I mashed TAQOZ and FastSpin together. There is a thread about it. But basically I start TAQOZ in COG0 and a FastSpin compiled Program in COG1 able to talk to TAQOZ via Mailbox. Both Programs agree about the locations in HUB where the clocksettigs are.

    I CAN change the clockfreq in my FastSpin program while the TAQOZ COG0 is running. FastSpin program will change the HUB location after changing the freq. And TAQOZ still knows what freq we are running on, still knows to pulse a pin at 1,10 or 100 Hz because it knows the system frequency has changed.
    Because both programs agree on that location.
    [/RANT]
    Mike
    well - in this example Taqoz will get the new clockfreq when it reads it again.
    So the blinker would need to be prepared for this and recalculate a delta each time based on current clockfreq.

    nono, @MJB it simply works, becaue both COGS agree about the location of clockfreq. So I can switch to 80Mhz (in Spin) or to 160 or 200, does not matter, 56 BLINK blinks in the same frequency. It just works. Because @ersmith and @Peter Jakacki agree about the HUB location of clockfreq.

    EDIT - ok, I need to send "56 BLINK" again after changing the clockfreq so TAQOZ read the clockfreq again.

    Mike

    that's what I mean -
    there is no sysclock has changed interrupt ;-)

    but changing sysclock in the middle of some program is not what you often do ...
    maybe for power savings ...
    the programmer can design this as he likes.

    but a standard way to find out the current sysclock would be REALLY helpful
    if you think about OBEX objects collaboration.

    That is exactly what we are asking for. Some don't seem to see the benefit, or want to dismiss it as "a separate concern and can be defined as desired."

    Given that this thread is "Spin2 Interpreter" I don't see how loading handover is relevant, yet object coordination is "a separate concern".

    We never had this problem on P1 because the hardware provided the service. P2 doesn't, so we need a software solution. Most languages developed to date have agreed on the solution and SPIN2 is now apparently going a different way. This should be resolved now.
  • evanhevanh Posts: 8,065
    edited 2019-07-30 - 12:31:19
    AJL wrote: »
    That is exactly what we are asking for. Some don't seem to see the benefit, or want to dismiss it as "a separate concern and can be defined as desired."

    Given that this thread is "Spin2 Interpreter" I don't see how loading handover is relevant, yet object coordination is "a separate concern".
    It's because there is a flaw in the hardware that is currently being worked around with the help of those mailbox parameters. Chip has identified that this borrowing of the parameters isn't needed after all. As long as the loaders all change to a RCFAST handover instead.

    So it is separate, but still needs resolved in its own way. And I'd prefer the option of disentanglement by changing to RCFAST handover.

    "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."
  • Here's an updated Mainloader1.spin2 for loadp2
    CON
    		rxpin = 63
    
    DAT		org
    
    begin
                    andn    clkmode, #3             'disable XI+PLL mode
    		hubset	clkmode			'set up oscillator while still in RCFAST mode
                    waitx   ##20_000_000/100        'wait 10 ms
                    or      clkmode, #3             'enable XI+PLL mode
                    hubset  clkmode                 'switch to PLL mode
    
    		wrfast	#0,address		'ready to write entire memory starting at address
    		setse1	#%010_000000 | rxpin	'select negative edge on p63
    
    mainloop	pollse1				'clear edge detector
    		waitse1				'wait for start bit
    		waitx	waitbit1_5		'wait for middle of 1st data bit
    
    		rep	@loopend,#8		'get 8 bits
    		testp	#rxpin		wc	'sample rx
    		rcr	rxbyte,#1		'rotate bit into byte
    		waitx	waitbit			'wait for middle of nth data bit
    loopend
    		shr	rxbyte,#32-8		'justify received byte
    		wfbyte	rxbyte			'write to hub
    
    		djnz	filesize,#mainloop	'loop until all bytes received
    
                    rdfast  #0,#0                   'wait for last byte to be written
    
                    andn    clkmode, #3             'disable XI+PLL mode
                    hubset  clkmode                 'switch to RCFAST mode
                    hubset  #0                      'turn off all crystal/PLL modes
                    waitx   ##20_000_000/100        'wait 10 ms for crystal shutdown
    
    		coginit	#0,address		'launch cog 0 from address
    
    clkmode		res	1			'clock mode
    waitbit1_5	res	1			'1.5 bit cycles = 3*clock_freq/baud_rate/2 - 6
    waitbit		res	1			'1 bit cycles = clock_freq/baud_rate - 6
    filesize	res	1			'binary file size in bytes
    address		res	1			'starting address
    rxbyte		res	1			'received byte
    
    "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."
  • What did you change?
  • evanhevanh Posts: 8,065
    edited 2019-07-30 - 13:29:22
    Here's the unchanged version. Obviously, loadp2.c also needs some changes to remove the patching feature.
    CON
    		rxpin = 63
    
    DAT		org
    
    begin		hubset	clkmode			'set up oscillator 
                    waitx   ##20_000_000/100        'wait 10 ms
                    or      clkmode, #3             'enable XI+PLL mode
                    hubset  clkmode                 'enable oscillator
    		wrfast	#0,address		'ready to write entire memory starting at address
    		setse1	#%010_000000 | rxpin	'select negative edge on p63
    
    mainloop	pollse1				'clear edge detector
    		waitse1				'wait for start bit
    		waitx	waitbit1_5		'wait for middle of 1st data bit
    
    		rep	@loopend,#8		'get 8 bits
    		testp	#rxpin		wc	'sample rx
    		rcr	rxbyte,#1		'rotate bit into byte
    		waitx	waitbit			'wait for middle of nth data bit
    loopend
    		shr	rxbyte,#32-8		'justify received byte
    		wfbyte	rxbyte			'write to hub
    
    		djnz	filesize,#mainloop	'loop until all bytes received
    
                    rdfast  #0,#0                   'wait for last byte to be written
    
    		coginit	#0,address		'launch cog 0 from address
    
    clkmode		res	1			'clock mode
    waitbit1_5	res	1			'1.5 bit cycles = 3*clock_freq/baud_rate/2 - 6
    waitbit		res	1			'1 bit cycles = clock_freq/baud_rate - 6
    filesize	res	1			'binary file size in bytes
    address		res	1			'starting address
    rxbyte		res	1			'received byte
    
    "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."
  • cgraceycgracey Posts: 11,747
    edited 2019-07-30 - 13:42:46
    Guys, I agree that there needs to be statically-located CLKFREQ and CLKMODE longs, as those are most-easily used by all potential language systems.

    Personally, I would like those longs to be at $40 and $44, freeing $00..$3F. Others, though, feel it's critical that $00 be preserved as a restart location or null-pointer trap, which singly preempts generic use of $00..$3F. Everyone is already using $14 and $18 (I think) for CLKMODE and CLKFREQ. For now, I will just follow that convention, too.

    There will be no $00-based generic hub RAM in this case. So, any mailboxes in hub will have to be worked out on a case-by-case basis. I suppose if I could do anything, I might have $00..$FF free, with an understanding that each potential cog has 16 bytes of space to use for whatever purpose it wants in hub. That might just be superfluous, anyway, and lead people to suppose they must use that RAM, just because it's there. That wouldn't be good.

    So, I'll use $14 for CLKMODE and $18 for CLKFREQ. There will be no $00-based free hub RAM. There will be a few reusable longs near $00, but they won't all be contiguous.
  • Would this problem be resolved if there were a "HUBGET" instruction that would return the clock settings?
    Prop Info and Apps: http://www.rayslogic.com/
  • evanhevanh Posts: 8,065
    edited 2019-07-30 - 14:53:54
    The die is cast, such questions are academic now. But sure, that would be one way. Although it may not be a straight forward verilog fix since it will depend on where the mode store flops are located. If they are in the custom ring then there won't be an available read back mechanism without redoing the custom layout. If it comes to that then correcting the flaw would be the right solution.
    "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."
  • Actually, didn't Chip say there were extra registers in the Spin2 cog not being used?
    Can't you use 2 of those for this and then add some new Spin2 instructions to fetch them?
    Prop Info and Apps: http://www.rayslogic.com/
  • Ah, oh, um .... all the cogs are part of the synthesised verilog that makes up the bulk core area of the die. The RC oscillators and crystal oscillator and PLL circuits are all in the custom layout (like a circuit board) that rings the outer perimeter of the prop2 die. The flaw is to do with PLL select management which is part of that custom ring.

    Where the flops of the mode register are located I don't know. They could be either part of the synthesised core or in the custom ring. If they are in the core then, sure, a respin with a new read back instruction would be quicker and cheaper than relaying the custom layout but it would still be a respin.
    "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 just meant to ask if the clkfreq and clkmode could be stored in COG ram rather than HUB ram.
    Chip's Spin2 runs in a cog as interpreter...
    I guess FastSpin doesn't use an interpreter cog though...
    Prop Info and Apps: http://www.rayslogic.com/
  • evanh wrote: »
    Here's the unchanged version. Obviously, loadp2.c also needs some changes to remove the patching feature.
    Can explain what you changed instead of just posting code? Did you remove something? And why does the pathing feature need to be removed? It is controlled by an optional parameter on the command line.

    I don't think everybody has bought into the changes that you and Chip are trying to force on us. It's tactics like this that make me wonder if it's worth spending time on the P2.
  • Dave Hein, doesn't it appear that Chip agreed to grab and update the system clock parameters from the agreed upon spot?
    Isn't this discussion over at this point?
  • Thanks, I had missed that. I should have read it more carefully. I think I quit reading it after the first couple of lines where it looked like he was still pushing his proposal. My previous response was actually more about evanh's proposal to change loadp2. I don't understand the need for the change. Maybe he'll explain it when he has a chance.
  • cgracey wrote: »
    So, I'll use $14 for CLKMODE and $18 for CLKFREQ. There will be no $00-based free hub RAM. There will be a few reusable longs near $00, but they won't all be contiguous.

    It's actually the other way around, Chip. $14 is the frequency address and $18 was the CLKMODE.
    Personally, I would like those longs to be at $40 and $44, freeing $00..$3F. Others, though, feel it's critical that $00 be preserved as a restart location or null-pointer trap, which singly preempts generic use of $00..$3F. Everyone is already using $14 and $18 (I think) for CLKMODE and CLKFREQ. For now, I will just follow that convention, too.
    I sympathise Chip. I rather liked your idea too and thought it opened up some nice options but I guess it became too hard for two reasons...legacy software interests and intercepting the unique 0 call address cases in various languages which was the PITA as it is harder to avoid. We now can't fully use the low memory for larger directly indexed tables if we want compatibility with SPIN2 and the clock frequency long storage. Not ideal but looks like we will just need to live with it. Any custom system independent of SPIN2 can still obviously fully use this memory for its own purposes at least, so all is not lost.
  • Peter JakackiPeter Jakacki Posts: 8,725
    edited 2019-07-30 - 22:59:44
    Chip, now is the time for us to work out these addresses which could be $04,$08 or $F8 and $FC even as it is still easily reached with un-augmented rdlong imediate. P1 Spin reserved the first 16 bytes anyway.

    My original addresses were mainly for some functionality and I always had the option of changing it later. This has nothing to do with the ROM though, because what's in ROM, stays in ROM.

    Tachyon Forth - compact, fast, forthwright and interactive
    useforthlogo-s.png
    P2 --- The LOT --- 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
Sign In or Register to comment.