Spin2

145791018

Comments

  • RaymanRayman Posts: 10,279
    edited 2020-01-16 - 17:18:28
    This just got me thinking... In addition to removing stuff from objects, maybe we can add stuff?
    This may not make any sense, but what if you wanted to add a custom method to an existing object.
    You could make a copy, call it something else, and add your stuff.

    But, what if you could merge Spin2 files into a single object?
    Maybe it'd go like this:
    OBJ
    ser     :       "fullduplexserial.spin2"   :  "MyCustomSerialMethods.spin2"
    

    It'd be sorta like a child class...
  • pedwardpedward Posts: 1,583
    edited 2020-01-16 - 18:57:41
    On the surface it looks like polymorphism, but just below the surface you could just call it an "overlay", as long as you don't have any collisions of method names, but overriding another method brings some messes with it, in the above syntax there is nothing to suggest inheritance and order.
  • Can there be a helper function(s) to build the mode bits? The return value of which then goes into the pinmode instruction or into a var?

    Those 0011_0001_00000_0 bit strings are too long, and since the underscores aren't enforced, it's easy to get out of alignment. How about where there's an underscore in the mode bits, separate that out into individual vars in the helper function?

    What's nice is that if ersmith's compiler notices it's all constants and literal values, the function call would get optimized out.
  • whicker wrote: »
    Can there be a helper function(s) to build the mode bits? The return value of which then goes into the pinmode instruction or into a var?

    Those 0011_0001_00000_0 bit strings are too long, and since the underscores aren't enforced, it's easy to get out of alignment. How about where there's an underscore in the mode bits, separate that out into individual vars in the helper function?

    What's nice is that if ersmith's compiler notices it's all constants and literal values, the function call would get optimized out.

    IMHO The less there is to learn in the basic Spin2 language the better. So far, so good:)
    But the P2 is also a whole new ball game... with a lot to learn.

    I think the helper function you are describing belongs in "the tool."
    Help->Smart_Pins->Configure->Mode->etc.->etc.

    From which one possible result is a new text file with your realized configuration.

    I've seen calls for another Propeller Manual... a short introduction and description of a very extensive help structure within the PropTool itself (and/or FlexGui) might be far better.

    Books are great for long plane flights... not so good cluttering up the workspace.
  • > @pedward said:
    > On the surface it looks like polymorphism, but just below the surface you could just call it an "overlay", as long as you don't have any collisions of method names, but overriding another method brings some messes with it, in the above syntax there is nothing to suggest inheritance and order.

    Yes, I was thinking it'd be just as if one of them #included the other one in it.
    Or, as if the compiler just concatenated the two files into one before compiling...

    It could be that duplicate names or symbols are not allowed...
  • whicker wrote: »
    Can there be a helper function(s) to build the mode bits? The return value of which then goes into the pinmode instruction or into a var?

    Those 0011_0001_00000_0 bit strings are too long, and since the underscores aren't enforced, it's easy to get out of alignment. How about where there's an underscore in the mode bits, separate that out into individual vars in the helper function?

    If pin modes aren't going to be assigned "friendly names" in spin, I would hope that we can have friendly names placed in an include file. Having them in the "tool" would be nice too.

    When I was last picking over the PIN modes for clocked serial out, I was going cross eyed trying to ensure what I typed in was correct. I needed to change the clock divisor for Rev B silicon and it took way too long to re-learn where it was. It's not intuitive at all, but I believe it could be for the most common modes.

    Just my $.02

  • I suggested to Chip that the special capabilities of pins be given friendly mnemonics. Hence the DACSETUP and PWMSETUP. I suggested also to have many of these peripheral capabilities be expressed in an object oriented interface.

    So DAC.SETUP(pins, mode) where mode would have constants/enums for 75_OHM, and the like.

    Pins would have something similar for common use cases.

    That said, for anything uncommon, an interface to just set a bit mask for mode settings, would be the preferred interface.

    The OBJECT.VERB format lends itself to being easily understood and is clean to write and read. Making Spin2 easy to translate from high level to assembly language shouldn't be a primary motivating factor, Parallax's bread and butter is education, making interfaces easy to understand and use is extremely important.

    That is what drove the longer mnemonics we discussed; NOUNVERB was the embodiment I suggested because it makes the code completely readable without needing to refer to the manual. PINFLOAT and PINTOGGLE are very straightforward and communicate a lot of information quickly and simply.

    The OBJECT.VERB notation is an extension of NOUNVERB in a friendly way that equally satisfies CS style guidelines as well as making it easy for beginners to grasp.

    The downside of the OBJECT.VERB interface is that it requires more verbosity when programming. In the NOUNVERB model you just have DAC(pin, value), since you can only write to a DAC, the verb WRITE is superfluous. With an OBJECT.VERB syntax you would do:

    DAC.WRITE(pin,value)

    Which is just a little more verbose, but also conveys more information to unfamiliar readers.

    --Perry
  • @cgracey
    do you think it is possible to have a command or special pub (eg HPUB) to execute outside (spin2-unaware) code?

    something like
    HPUB HubAddress(a,b,c,...):x,y
    
    I mean:
    - Spin2 will write to hubaddress+1 a, to hubaddress+2 b, .... and then jump to hubaddress
    - from here hubexec code will be executed which should preserve all cog registers (spin environment)
    - at the end the foreign code will write up to 2 results in two defined cog registers and jump to a third defined cog register which is the end of the HPUB and will pass the x and y results away, along the spin code
  • deleted
    dMajo wrote: »
    @cgracey
    do you think it is possible to have a command or special pub (eg HPUB) to execute outside (spin2-unaware) code?

    something like
    HPUB HubAddress(a,b,c,...):x,y
    
    I mean:
    - Spin2 will write to hubaddress+1 a, to hubaddress+2 b, .... and then jump to hubaddress
    - from here hubexec code will be executed which should preserve all cog registers (spin environment)
    - at the end the foreign code will write up to 2 results in two defined cog registers and jump to a third defined cog register which is the end of the HPUB and will pass the x and y results away, along the spin code

    I think you could construct an object to do that, using inline assembly. For example, if the return address is in ptrb and return values should be placed in pa and pb you could do something like:
    PUB CallHub(hubaddress, a, b, c) : x,y
      long[hubaddress+1] := a
      long[hubaddress+2] := b
      long[hubaddress+3] := c
      asm ' I think Chip's syntax is different, I'm using fastspin syntax
        calld ptrb, hubaddress
        mov   x, pa
        mov   y, pb
      endasm
    
  • Chip,
    Is pnut available for trying out spin2 yet?
  • > @Cluso99 said:
    > Chip,
    > Is pnut available for trying out spin2 yet?

    No. I need to document the language. Also, I'm working on the programmer and fast loader for it now. It's getting close.
  • Does anybody think it would be worthwhile to add BMASK as an operator to Spin2?

    BMASK is a unary operator which makes a bitmask whose MSB is the lower 5 bits of the argument. For example (BMASK 7) would result in $000000FF.
  • IMHO these are parts that make a language unreadable, so no.
  • Cluso99 wrote: »
    IMHO these are parts that make a language unreadable, so no.

    I kind of agree.
  • Might be nice to have something to get/set a range values over two consecutive registers, like ina/outa...

    Might help if you have a bus that spans over INA and INB...

    Maybe like this:
    xin:=GetBits64(INA,nBitsWide,nBasePin)
    SetBits64(OUTA,nBitsWide,nBasePin,xin)
    
  • Rayman wrote: »
    Might be nice to have something to get/set a range values over two consecutive registers, like ina/outa...

    Might help if you have a bus that spans over INA and INB...

    Maybe like this:
    xin:=GetBits64(INA,nBitsWide,nBasePin)
    SetBits64(OUTA,nBitsWide,nBasePin,xin)
    

    Yes, that could be useful. I have a few bytecodes and longs free.
  • cgracey wrote: »
    No. I need to document the language. Also, I'm working on the programmer and fast loader for it now. It's getting close.

    We can't use PropPlug to program P2?
  • cgracey wrote: »
    No. I need to document the language. Also, I'm working on the programmer and fast loader for it now. It's getting close.

    We can't use PropPlug to program P2?

    You can. The P2 Eval board has the USB built-in, though. If you make your own board without USB, you'll need a PropPlug.
  • cgracey wrote: »
    > @Cluso99 said:
    > Chip,
    > Is pnut available for trying out spin2 yet?

    No. I need to document the language. Also, I'm working on the programmer and fast loader for it now. It's getting close.

    @Dave Hein wrote a fast loader as part of his loadp2 program, which I'm maintaining (https://github.com/totalspectrum/loadp2). @evanh and @ozpropdev wrote an SPI flash programmer that's also part of the loadp2 package. All of that code is under the MIT license, so you can take whatever bits you'd like from it.

    The fast loader is https://github.com/totalspectrum/loadp2/blob/master/MainLoader1.spin2, and the SPI flash programmer is at https://github.com/totalspectrum/loadp2/blob/master/board/P2ES_flashloader.spin2.
  • ersmith wrote: »
    cgracey wrote: »
    > @Cluso99 said:
    > Chip,
    > Is pnut available for trying out spin2 yet?

    No. I need to document the language. Also, I'm working on the programmer and fast loader for it now. It's getting close.

    @Dave Hein wrote a fast loader as part of his loadp2 program, which I'm maintaining (https://github.com/totalspectrum/loadp2). @evanh and @ozpropdev wrote an SPI flash programmer that's also part of the loadp2 package. All of that code is under the MIT license, so you can take whatever bits you'd like from it.

    The fast loader is https://github.com/totalspectrum/loadp2/blob/master/MainLoader1.spin2, and the SPI flash programmer is at https://github.com/totalspectrum/loadp2/blob/master/board/P2ES_flashloader.spin2.

    Thanks, Eric. I think I might have mine done, already. I'm looking at in on the scope now. It does everything as fast as can be done using RCFAST. Once I get it cleaned up, I'll hook it into PNut.exe and see what happens.
  • Chip, the fast loader that I added to loadp2 was based on the MainLoader.spin2 program that you included in the FPGA zip files. You removed it from the zip file somewhere between v21 and v30. I just modified it a bit so I could pass some parameters to it.
  • Dave Hein wrote: »
    Chip, the fast loader that I added to loadp2 was based on the MainLoader.spin2 program that you included in the FPGA zip files. You removed it from the zip file somewhere between v21 and v30. I just modified it a bit so I could pass some parameters to it.

    I had forgotten all about the MainLoader program. Yes, that was how things worked for a long time. I think I removed it from the FPGA files when we got the new ROM_Booter working which uses a text-only/terminal-friendly protocol.
  • cgracey wrote: »
    Here's the current interpreter. This has been a lot of fun to work on and very challenging. The code that does the Spin2 calls and returns was really difficult to work out and optimize. It took me days to spool it up if I had been away from it too long. In time, we'll find ways to improve it, I think.

    Three skips > 7 after label hub_p can be made 7 or less, saving two cycles for each. Code just before that doesn't need changing but I've done it anyway below for consistency:
    '
    ' Setup hub variable
    '
    hub_im		getnib	ad,pa,#0	'a b							a: setup long[vbase][0..15]
    hub_ap		rfvar	ad		'| | c d e f g h i j k l m n o p q r s t		b: setup long[dbase][0..15]
    hub_pp		popa	ad		'| | | | | | | | | | | | | | | | | | | | u v w		c: setup byte[pbase + rfvar]
    					'							d: setup byte[vbase + rfvar]
    		shl	ad,#2		'a b | | | | | | | | | | | | | | | | | | | | |		e: setup byte[dbase + rfvar]
    		shl	x,#1		'| | | | | | | | | | | l m n | | | | | | | v |		f: setup byte[pbase + rfvar][pop index]
    		shl	x,#2		'| | | | | | | | | | | | | | | | | r s t | | w		g: setup byte[vbase + rfvar][pop index]
    		add	ad,x		'| | | | | f g h | | | l m n | | | r s t u v w		h: setup byte[dbase + rfvar][pop index]
    					'							i: setup word[pbase + rfvar]
    		add	ad,vbase	'a | | d | | g | | j | | m | | p | | s | | | |		j: setup word[vbase + rfvar]
    		add	ad,dbase	'| b | | e | | h | | k | | n | | q | | t | | |		k: setup word[dbase + rfvar]
    		add	ad,pbase	'| | c | | f | | i | | l | | o | | r | | | | |		l: setup word[pbase + rfvar][pop index]
    					'							m: setup word[vbase + rfvar][pop index]
    hub_p		mov	ad,x		'| | | | | | | | | | | | | | | | | | | | | | | x y z	n: setup word[dbase + rfvar][pop index]
    		popa	x		'| | | | | f g h | | | l m n | | | r s t u v w x y z	o: setup long[pbase + rfvar]
    					'							p: setup long[vbase + rfvar]
    		mov	rd,rd_long	'a b | | | | | | | | | | | | o p q r s t | | w | | z	q: setup long[dbase + rfvar]
    		mov	rd,rd_byte	'| | c d e f g h | | | | | | | | | | | | u | | x | |	r: setup long[pbase + rfvar][pop index]
    		mov	rd,rd_word	'| | | | | | | | i j k l m n | | | | | | | v | | y |	s: setup long[vbase + rfvar][pop index]
    					'							t: setup long[dbase + rfvar][pop index]
    		mov	wr,wr_long	'a b | | | | | | | | | | | | o p q r s t | | w | | z	u: setup byte[pop base][pop index]
    		mov	wr,wr_byte	'| | c d e f g h | | | | | | | | | | | | u | | x | |	v: setup word[pop base][pop index]
    		mov	wr,wr_word	'| | | | | | | | i j k l m n | | | | | | | v | | y |	w: setup long[pop base][pop index]
    					'							x: setup byte[pop address]
    		mov	sz,#31		'a b | | | | | | | | | | | | o p q r s t | | w | | z	y: setup word[pop address]
    		mov	sz,#7		'| | c d e f g h | | | | | | | | | | | | u | | x | |	z: setup long[pop address]
    		mov	sz,#15		'| | | | | | | | i j k l m n | | | | | | | v | | y |
    
    	_ret_	setq2	#$160		'a b c d e f g h i j k l m n o p q r s t u v w x y z	(next bytecode is variable operator)
    '
    

    There are other skips > 7 starting at label op_sqrt that might be avoidable. Using unique letters immediately after ' for each skipping option is an idea I have copied (without spaces, though, to reduce line length). It would be very good if assemblers could use these comments to generate skip patterns automatically.

    However, starting at op_sqrt, there are some "x x " that appear to be alternatives to "m n ". Repeating the same latter might make auto-generation a bit tricky. What does "x x" mean?

    Also, should
    		call	#.scas		'SCAS	x x | | | | | | g |
    		alti	wr		'wr	m n | | | | | | | |
    

    be this?
    		call	#\.scas		'SCAS	x x | | | | | | g |
    		alti	wr		'wr	m n | | | | | | | |
    
  • cgraceycgracey Posts: 12,458
    edited 2020-01-21 - 11:40:25
    Whoah! Good finds, Tony.

    I just changed the 'call #\.scas'. That would have been a sleeper.

    I will get those hub_p patterns rearranged. I was stuck thinking it wasn't possible, for some reason, so I let the word-size setups suffer, thinking they were going to be the least-commonly used.

    I let those SQRT/LOG/EXP patterns be long, because I figured they were not going to be super common and the CORDIC takes lots of cycles, anyway.

    Those 'x' characters within 'm' and 'n' patterns mean 'substitute the letter pattern here (a..j). It's how we get variable assignments (x += 4), both isolated and push versions. The push versions leave the written value on the stack for further operations (see y, x := (y += 5) * 3).
  • Chip, etc
    I was just pondering about writing a python program to pre-parse the spin2 bytecode tables. for example...
    ' Setup hub variable
    'b=====================================================================================================================================
    hub_im          getnib  ad,pa,#0        'a b                                                    a: setup long[vbase][0..15]
    hub_ap          rfvar   ad              '| | c d e f g h i j k l m n o p q r s t                b: setup long[dbase][0..15]
    hub_pp          popa    ad              '| | | | | | | | | | | | | | | | | | | | u v w          c: setup byte[pbase + rfvar]
                                            '                                                       d: setup byte[vbase + rfvar]
                    shl     x,#2            '| | | | | | | | | | | | | | | | | r s t | | w          e: setup byte[dbase + rfvar]
                    shl     x,#1            '| | | | | | | | | | | l m n | | | | | | | v |          f: setup byte[pbase + rfvar][pop index]
                    add     ad,x            '| | | | | f g h | | | l m n | | | r s t u v w          g: setup byte[vbase + rfvar][pop index]
                    shl     ad,#2           'a b | | | | | | | | | | | | | | | | | | | | |          h: setup byte[dbase + rfvar][pop index]
                                            '                                                       i: setup word[pbase + rfvar]
                    add     ad,pbase        '| | c | | f | | i | | l | | o | | r | | | | |          j: setup word[vbase + rfvar]
                    add     ad,vbase        'a | | d | | g | | j | | m | | p | | s | | | |          k: setup word[dbase + rfvar]
                    add     ad,dbase        '| b | | e | | h | | k | | n | | q | | t | | |          l: setup word[pbase + rfvar][pop index]
                                            '                                                       m: setup word[vbase + rfvar][pop index]
    hub_p           mov     ad,x            '| | | | | | | | | | | | | | | | | | | | | | | x y z    n: setup word[dbase + rfvar][pop index]
                    popa    x               '| | | | | f g h | | | l m n | | | r s t u v w x y z    o: setup long[pbase + rfvar]
                                            '                                                       p: setup long[vbase + rfvar]
                    mov     rd,rd_long      'a b | | | | | | | | | | | | o p q r s t | | w | | z    q: setup long[dbase + rfvar]
                    mov     wr,wr_long      'a b | | | | | | | | | | | | o p q r s t | | w | | z    r: setup long[pbase + rfvar][pop index]
                    mov     sz,#31          'a b | | | | | | | | | | | | o p q r s t | | w | | z    s: setup long[vbase + rfvar][pop index]
                                            '                                                       t: setup long[dbase + rfvar][pop index]
                    mov     rd,rd_byte      '| | c d e f g h | | | | | | | | | | | | u | | x | |    u: setup byte[pop base][pop index]
                    mov     wr,wr_byte      '| | c d e f g h | | | | | | | | | | | | u | | x | |    v: setup word[pop base][pop index]
                    mov     sz,#7           '| | c d e f g h | | | | | | | | | | | | u | | x | |    w: setup long[pop base][pop index]
                                            '                                                       x: setup byte[pop address]
                    mov     rd,rd_word      '| | | | | | | | i j k l m n | | | | | | | v | | y |    y: setup word[pop address]
                    mov     wr,wr_word      '| | | | | | | | i j k l m n | | | | | | | v | | y |    z: setup long[pop address]
                    mov     sz,#15          '| | | | | | | | i j k l m n | | | | | | | v | | y |
    
            _ret_   setq2   #$160           'a b c d e f g h i j k l m n o p q r s t u v w x y z    (next bytecode is variable operator)
    'e=====================================================================================================================================
    '
    
    results in a table as follows...
    bc_setup_var_0_15       long  hub_im    |%0111111000111010111110 << 10  'Cx *   setup long[vbase][0..15]
    bc_setup_local_0_15     long  hub_im    |%0111111000110110111110 << 10  'Dx *   setup long[dbase][0..15]
    
    bc_setup_byte_pbase     long  hub_ap    | %011100011111110111110 << 10  '53 *   setup byte[pbase + rfvar]
    bc_setup_byte_vbase     long  hub_ap    | %011100011111101111110 << 10  '54 *   setup byte[vbase + rfvar]
    bc_setup_byte_dbase     long  hub_ap    | %011100011111011111110 << 10  '55 *   setup byte[dbase + rfvar]
    
    bc_setup_byte_pbase_pi  long  hub_ap    | %011100011101110101110 << 10  '56 *   setup byte[pbase + rfvar][pop index]
    bc_setup_byte_vbase_pi  long  hub_ap    | %011100011101101101110 << 10  '57 *   setup byte[vbase + rfvar][pop index]
    bc_setup_byte_dbase_pi  long  hub_ap    | %011100011101011101110 << 10  '58 *   setup byte[dbase + rfvar][pop index]
    
    bc_setup_word_pbase     long  hub_ap    | %000011111111110111110 << 10  '59 *   setup word[pbase + rfvar]
    bc_setup_word_vbase     long  hub_ap    | %000011111111101111110 << 10  '5A *   setup word[vbase + rfvar]
    bc_setup_word_dbase     long  hub_ap    | %000011111111011111110 << 10  '5B *   setup word[dbase + rfvar]
    
    bc_setup_word_pbase_pi  long  hub_ap    | %000011111101110100110 << 10  '5C *   setup word[pbase + rfvar][pop index]
    bc_setup_word_vbase_pi  long  hub_ap    | %000011111101101100110 << 10  '5D *   setup word[vbase + rfvar][pop index]
    bc_setup_word_dbase_pi  long  hub_ap    | %000011111101011100110 << 10  '5E *   setup word[dbase + rfvar][pop index]
    
    bc_setup_long_pbase     long  hub_ap    | %011111100011110111110 << 10  '5F *   setup long[pbase + rfvar]
    bc_setup_long_vbase     long  hub_ap    | %011111100011101111110 << 10  '60 *   setup long[vbase + rfvar]
    bc_setup_long_dbase     long  hub_ap    | %011111100011011111110 << 10  '61 *   setup long[dbase + rfvar]
    
    bc_setup_long_pbase_pi  long  hub_ap    | %011111100001110101010 << 10  '62 *   setup long[pbase + rfvar][pop index]
    bc_setup_long_vbase_pi  long  hub_ap    | %011111100001101101010 << 10  '63 *   setup long[vbase + rfvar][pop index]
    bc_setup_long_dbase_pi  long  hub_ap    | %011111100001011101010 << 10  '64 *   setup long[dbase + rfvar][pop index]
    
    bc_setup_byte_pb_pi     long  hub_pp    |  %01110001110111110110 << 10  '65 *   setup byte[pop base][pop index]
    bc_setup_word_pb_pi     long  hub_pp    |  %00001111110111110010 << 10  '66 *   setup word[pop base][pop index]
    bc_setup_long_pb_pi     long  hub_pp    |  %01111110000111110100 << 10  '67 *   setup long[pop base][pop index]
    
    bc_setup_byte_pa        long  hub_p     |          %011100011100 << 10  '68 *   setup byte[pop address]
    bc_setup_word_pa        long  hub_p     |          %000011111100 << 10  '69 *   setup word[pop address]
    bc_setup_long_pa        long  hub_p     |          %011111100000 << 10  '6A *   setup long[pop address]
    

    Note that I put a delimiter line before and after the set of instructions to make it easy for the program to encode the skip info.

    I am thinking that the skip bitmap could be formulated and output back into the spin2 code as a CON section with the equates for the label appended with "_skip_a" where "a" is the alpha character used in the comments for the appropriate skip.
    So, for example we would get a CON section with comments picked up from the instruction code thus...
    CON
    hub_im_skip_a     =  hub_im    |%0111111000111010111110 << 10     ' a: setup long[vbase][0..15]
    hub_im_skip_b     =  hub_im    |%0111111000110110111110 << 10     ' b: setup long[dbase][0..15]
    hub_ap_skip_c     =  hub_ap    | %011100011111110111110 << 10     ' c: setup byte[pbase + rfvar]
    .....
    
    and the spin2 code for the execf table would become...
    bc_setup_var_0_15       long  hub_im_skip_a                       'Cx *   setup long[vbase][0..15]
    bc_setup_local_0_15     long  hub_im_skip_b                       'Dx *   setup long[dbase][0..15]
    
    bc_setup_byte_pbase     long  hub_ap_skip_c                       '53 *   setup byte[pbase + rfvar]
    .....
    
    meaning after a change the python program would re-run and generate or replace the CON section with new values. The execf tables would remain unchanged.
  • That would save some effort, for sure. I have to shift into 1st gear to update those skip tables. Carefully.
  • I’ve started to parse the comment section. If the first “a” instruction always begins with the comment ‘a<space> and has 3 characters a:<space> then I can pick out each sequence easily I think.

    Last August I did some bytecodes and I used a different commenting method. I thought it was a little easier but it still wasn’t easy. So I think a software solution is better as it’s less prone to errors which would be hard to debug.

    Might get some time tomorrow.
  • Cluso99Cluso99 Posts: 15,775
    edited 2020-01-21 - 21:36:52
    Chip, etc

    Would it be reasonable to expect the comment sequence of a set of skip'd instructions to begin the comment with a 2-3 character sequence
    eg 3 characters '~<space>
    ' Address/read/write variable
    '
    var_rd          pusha   x               '~ a b   d                a: @var
            _ret_   mov     x,ad            '~ a |   |                b: read  long[dbase][0..15]
                                            '~                        c: write long[dbase][0..15]     (isolated)
    var_wr_im       getnib  ad,pa,#0        '~   b c |                d: read var
                    shl     ad,#2           '~   b c |                e: write var                    (isolated)
                    add     ad,dbase        '~   b c |                f: write var                    (push)
    
                    alti    rd              '~   | | d
            _ret_   rdlong  x,ad            '~   b | d
    
    var_wr          alti    wr              '~     | | e f
                    wrlong  x,ad            '~     c | e f
    
            _ret_   popa    x               '~     c | e |
            _ret_   zerox   x,sz            '~       d   f            (ret for d, trim+ret for f)
    '
    
    Blank lines would be ignored
    Any other lines in between wiithout the '~<space> sequence would be considered a break from the skip format, so the next '!<space> sequence would be a new skip sequence.

    This would make it easy to find skip sequences in the source code.

    Your thoughts?
  • That looks like a good approach.
  • Chip,
    I've noticed these don't fit the mould
    una_iso		mov	w,x		'	m				a: !!
    una_psh		pusha	x		'push	| n				b: !			
    		alti	rd		'rd	m n				c: - (neg)
    op_notb		test	x	wz	'rd,!!	m n a				d: ABS
    op_sqrt		qsqrt	x,#0		'SQRT	x x |             h		e: ENCOD
    op_log		qlog	x		'LOG	x x |             | i		f: DECOD
    op_exp		qexp	x		'EXP	x x |             | | j		g: ONES
    		muxz	x,_FFFFFFFF	'!!	x x a             | | |		h: SQRT
    op_not		not	x		'!	x x | b           | | |		i: LOG
    op_neg		neg	x		'-	x x | | c         | | |		j: EXP
    op_abs		abs	x		'ABS	x x | | | d       | | |
    op_ncod		encod	x		'ENCOD	x x | | | | e     | | |
    op_dcod		decod	x		'DECOD	x x | | | | | f   | | |
    op_ones		ones	x		'ONES	x x | | | | | | g | | |
    		getqx	x		'	x x | | | | | | | h i j
    		alti	wr		'wr	m n | | | | | | | | | |
    		ret			'wr,op	m n a b c d e f g h i j		m: ?= var	(isolated)
    	_ret_	mov	x,w		'iso	m |				n: ?= var	(push)
    	_ret_	zerox	x,sz		'push	  n				x: use a..j
    
    I haven't checked out the code but what is the purpose of the m and n? Are they masks?

    By enforcing the use of '~<space> I can pick out the sequences beginning with a... but I'm unsure about the ones beginning with m, n etc (ie not a)
Sign In or Register to comment.