fastspin compiler for P2: Assembly, Spin, BASIC, and C in one compiler

11011131516

Comments

  • So many FastSpin threads... Maybe this is the right one...

    I'm getting an error when I use ".end" but not with "end" here:
    DAT 'ReadRegOrId 
    ReadRegOrId                
                    or      outa,mRSTn  'bring resetn high
                    setbyte   dira,#$FF,#0
                    andn      outa,mCSn 'bring cs low
                    
                    'Send Command Address
                    mov     altsd,#datain0
                    rep @.end,#7
    alts1           alts    altsd
                    setbyte outa,0,#0
                    xor     outa,mCK
                    add     altsd,#1
    .end
    

    this is the error (see attached image).
    541 x 150 - 7K
    Prop Info and Apps: http://www.rayslogic.com/
  • garryjgarryj Posts: 265
    edited 2019-03-12 - 19:48:43
    The .end label is local and is used prior to the alts1 label, which is not local, so the REP cannot "see" .end.

    Addit: if alts1 is not local you can just rename it to .alts1 and all should be good.
    garryj
  • Ok, I think you're saying one can't have non-local references in between local ones.
    Guess that explains it...
    Prop Info and Apps: http://www.rayslogic.com/
  • Rayman wrote: »
    Ok, I think you're saying one can't have non-local references in between local ones.
    Guess that explains it...

    Correct. By definition a "local" reference only extends until the next non-local one. This is the same as for P1 PASM; the only difference is that for P2 PASM we use "." to introduce a local label instead of ":".
  • I don't really use this for P1.
    But, for P2 it's handy for the REP instruction...
    Prop Info and Apps: http://www.rayslogic.com/
  • RaymanRayman Posts: 9,482
    edited 2019-03-16 - 18:12:38
    So this is strange...
    If I add this line to a program, it doesn't work anymore:
    loc       ptra,##@HyperBuffer
    
    I think it's maybe supposed to just be #@ instead of ##@.
    But, don't know why that should kill the whole application...
    Prop Info and Apps: http://www.rayslogic.com/
  • Something is wrong with REP...
    It's slower using @.reploop2 than with #1..
    rep   #1,##640'@.reploop2,##640  
                  wfbyte    inb
    .reploop2
    
    Prop Info and Apps: http://www.rayslogic.com/
  • ersmithersmith Posts: 3,147
    edited 2019-03-16 - 20:49:46
    Rayman wrote: »
    Something is wrong with REP...
    It's slower using @.reploop2 than with #1..
    rep   #1,##640'@.reploop2,##640  
                  wfbyte    inb
    .reploop2
    

    Yes, there's a bug in the parsing of rep instructions; if a ## is present the augment instruction is counted as part of the loop for @ expressions. That's wrong of course, and I'll try to fix it soon. You can avoid it for now by putting the "640" in a register and using that for the loop count.

    As for the loc ptra, ##@HyperBuffer; there are probably multiple issues there. ## will generate an augment, which will probably mess up the loc address. Also, if you have Spin code in the same file (it's not a pure assembly program) then the whole meaning of "@" is a bit fuzzy, just as in Spin1 (where we had @ to handle this kind of thing). The upcoming fastspin release will handle this better, I think, but for now I'd suggest doing something like:
       mov ptra, HyperBufferPtr
       ...
    HyperBufferPtr long @ @ @ HyperBuffer
    
    (without the spaces between the "@" signs -- why does the forum try to parse those inside code blocks??) which will work even if you have Spin code there.
  • Thing about the loc ##@ is that it appears to mess up all the cogs, not just the one whose code this is in...
    Prop Info and Apps: http://www.rayslogic.com/
  • I tried using COGATN and WAITATN and couldn't make it work...
    Not sure it's a FastSpin bug, maybe I did it wrong...
    Prop Info and Apps: http://www.rayslogic.com/
  • Rayman wrote: »
    Thing about the loc ##@ is that it appears to mess up all the cogs, not just the one whose code this is in...

    Well, I guess the effects would depend on what the loc result was used for -- if you end up with a bad address in ptra you could overwrite other COGs memory.
  • Rayman wrote: »
    I tried using COGATN and WAITATN and couldn't make it work...
    Not sure it's a FastSpin bug, maybe I did it wrong...

    Remember that cogatn takes a mask as parameter (to signal multiple COGs). I've attached a sample program that works for me.
  • I've posted new versions of fastspin and spin2gui.

    @Rayman : this fixes the REP bug you noticed, as well as another REP bug where the optimizer would get confused when inlining a function that contained REP. It also handles loc better, although there are probably still some issues with addresses when mixing Spin and PASM code.

    @pilot0315 : spin2gui checks now for deleted files and always re-writes the files if it can't find them on disk.

    There are also a bunch more bug fixes (see the release notes for details). The only major new feature is that FCACHE is supported in P2 mode, using the LUT to cache small loops, but that has to be explicitly enabled by saying something like --fcache=240 on the command line. FCACHE doesn't make nearly as much difference on P2 as on P1, since hub exec is already pretty efficient, but it does provide a small speedup, e.g. the fftbench time dropped from 46 microseconds without fcache to 40 microseconds with --fcache=240.
  • There are new releases of fastspin and spin2gui. Mostly this is a bugfix release to fix various issues that people have reported (thanks for the bug reports, everyone). The only "new" features are (1) FCACHE is enabled automatically on P2 at optimization level -O2, and (2) if an object is given without an extension, fastspin looks for it as a .spin2 file first, and then a .spin file.
  • @ersmith,

    I stumbled over a idea on the P1 thread. And that got me thinking. I am not sure if fastspin already does this, but if not you might add this to the spin syntax.

    In p1 Spin you can set bits in dira/outa and read bits from ina with that nice syntax a := ina[3..19] for example. Or a := ina[19..3]

    I think it would be nice if that would be possible with any variable so one could say in Spin a[5..9] := b[8..4] or similar, a and b being single longs.

    Currently you are defining Spin2 and Chip will have to follow, right? :smile:

    I really like fastspin, it works for P1 and P2 and the multi language aspect is phenomenal.

    In my not at all humble opinion this is wonderful work you are doing there. And if Chip gets his bytecodes done then you might be able to assimilate that too.

    Thank you for putting all that work into it.

    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.
  • msrobots wrote: »
    I stumbled over a idea on the P1 thread. And that got me thinking. I am not sure if fastspin already does this, but if not you might add this to the spin syntax.

    In p1 Spin you can set bits in dira/outa and read bits from ina with that nice syntax a := ina[3..19] for example. Or a := ina[19..3]

    I think it would be nice if that would be possible with any variable so one could say in Spin a[5..9] := b[8..4] or similar, a and b being single longs.
    There's a problem with that syntax: in Spin you are allowed to use any variable as an array, so for example in:
    VAR
      long x, y
    PUB setit(a, b)
      x[0] := a
      x[1] := b
    
    the "x[0]" refers to "x" and "x[1]" refers to "b". So we would need a completely new syntax.

    It might be possible to do something like that via a new suffix like ".bit":
       x.bit[4] := 1 ' same as x |= (1<<4)
       x.bit[3..0] := 2 ' same as x := (x & !$F) | 2
    

    How does that sound?
    Currently you are defining Spin2 and Chip will have to follow, right? :smile:

    Definitely not :). Spin is Chip's baby, and I think we'll all follow where he leads. That said, Chip has been very open to community suggestions, so perhaps he'll adopt something like this for Spin2 as well.
    I really like fastspin, it works for P1 and P2 and the multi language aspect is phenomenal.
    Thanks! It's nice to know that people find it useful.

    Regards,
    Eric
  • ah, yes I forgot dir[4] for bit access.

    My thinking was that var[a..b] would be easy distinguishable from var[a] or var[a,b] / var[a].

    how about var[1..1] for the single bit?

    But basically var.bit[] fits nice into var.byte[] var.word[] var.long[] already existing.

    Enjoy!

    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.
  • yetiyeti Posts: 529
    edited 2019-04-01 - 00:24:31
    Would var.bit[n] with n>31 act on the bits of the next long(s) in memory?
    That'd probably be too confusing...
    ◁ propeller-wiki ▷ ◁ FastSpin ▷ ◁ DK-E ▷ ◁ :-D ▷ ◁ Stay OmmmmmmPtimistic! ▷ ◁ No Source – No Go! ▷ ◁ Help Spin at RosettaCode.org ▷ ◁ Why Asimov's Laws of Robotics Don't Work ▷ ◁ DNA is a four letter word. ▷
  • yeti wrote: »
    Would var.bit[n] with n>31 act on the bits of the next long(s) in memory?
    That'd probably be too confusing...

    would be conform with spin a.byte/word/long do it like that and do not check boundariessame goes for the alternate syntax of
    long[@a+b] could be bit[@a+33] for the first bit of the long after a.

    But I am more after the [a..b] syntax, it is already in fastspin for dir/out/in

    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.
  • @ersmith,

    while pluming along with my two port serial driver I adapted your std_text_routines for use with a additional port parameter.

    The ability to have optional parameters is really nice and your prinf saves so much code in my test routines, it is just fantastic.

    Thank you for all the work you are putting in here,

    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.
  • msrobots wrote: »
    while pluming along with my two port serial driver I adapted your std_text_routines for use with a additional port parameter.

    The ability to have optional parameters is really nice and your prinf saves so much code in my test routines, it is just fantastic.

    Thank you for all the work you are putting in here,

    You're very welcome, Mike. I'm glad you're finding it all useful! Let me know if you run into any problems.

    Thanks,
    Eric
  • Eric,
    I've started using the -l listing output for Fastspin. I see a couple of formatting niggles:

    - I note the hexadecimal is all byte sized big-endian in a little-endian system. It's a little disorienting trying to visually maintain the hexadecimal pairs without any delimiters. The easiest improvement would be to have a space between bytes to show the hexadecimal big-endian pairings. The alternative would be go pure little-endian.

    - There is some oddball miss-align occurs at memory boundaries, eg: going from cogram to hubram with an ORGH.
    00040 010 7C0480FE    | 		loc	pa, #loctest3
    00044 011 0004A0FD    | 		call	#diagloc
    00048 012             | 
    00048 012 FCFF9FFD
    0004c 013 00000000
    00050 014 00000000
    00054 015 00000000    | 		jmp	#$
    00058 016 00000000
    0005c 017 00000000
    00060 018 00000000
    00064 019 00000000
    00068 01a 00000000
    0006c 01b 00000000
    00070 01c 00000000
    00074 01d 00000000
    00078 01e 00000000
    0007c 01f 00000000
    00080 020 00000000
    00084 021 00000000
    00088 022 00000000
    0008c 023 00000000
    00090 024 00000000
    00094 025 00000000
    00098 026 00000000
    0009c 027 00000000
    000a0 028 00000000
    000a4 029 00000000
    000a8 02a 00000000
    000ac 02b 00000000
    000b0 02c 00000000
    000b4 02d 00000000
    000b8 02e 00000000
    000bc 02f 00000000
    000c0 030 00000000
    000c4 031 00000000
    000c8 032 00000000
    000cc 033 00000000
    000d0 034 00000000
    000d4 035 00000000
    000d8 036 00000000
    000dc 037 00000000
    000e0 038 00000000
    000e4 039 00000000
    000e8 03a 00000000
    000ec 03b 00000000
    000f0 03c 00000000
    000f4 03d 00000000
    000f8 03e 00000000
    000fc 03f 00000000
    00100 040 00000000
    00104 041 00000000
    00108 042 00000000
    0010c 043 00000000    | 	byte	$00[184]
    00110 044             | 
    00110 044             | 
    00110 044             | ORGH $110
    00110 044 EFBEADDE
    00114 045 00000000
    00118 046 00000000
    0011c 047 00000000    | loctest2	long    $deadbeef	' Cogram equivalent address is $44
    00120 048 00000000
    00124 049 00000000
    00128 04a 00000000
    0012c 04b 00000000
    00130 04c 00000000
    
    "... peers into the actual workings of a quantum jump for the first time. The results
    reveal a surprising finding that contradicts Danish physicist Niels Bohr's established view
    —the jumps are neither abrupt nor as random as previously thought."
  • evanh wrote: »
    Eric,
    I've started using the -l listing output for Fastspin. I see a couple of formatting niggles:

    - I note the hexadecimal is all byte sized big-endian in a little-endian system. It's a little disorienting trying to visually maintain the hexadecimal pairs without any delimiters. The easiest improvement would be to have a space between bytes to show the hexadecimal big-endian pairings. The alternative would be go pure little-endian.

    Normally, in little-endian systems the bytes (hexadecimal pairs) are the same as big-endian, but ordered differently; this is exactly what you are seeing. For "pure little-endian" bit 31 would represent a value of 1, bit 30 a value of 2, and so on.

    Having inter-byte delimiters is not a bad idea, at least as an option, if the data is going to be listed in little-endian form.

    Perhaps it would actually make more sense to list the data twice (little-endian for hub and "big-endian" long form for cog), as well as the hub and cog address equivalents, with a header row to show the fields, and maybe even some in-line field delimiters.
    e.g.
    hub   | bytes       | cog | long
    00040 | 7C 04 80 FE | 010 | FE80047C    | 		loc	pa, #loctest3
    00044 | 00 04 A0 FD | 011 | FDA00400    | 		call	#diagloc
    00048 |             | 012 |             |
    00048 | FC FF 9F FD | 012 | FD9FFFFC    
    0004c | 00 00 00 00 | 013 | 00000000     
    00050 | 00 00 00 00 | 014 | 00000000     
    00054 | 00 00 00 00 | 015 | 00000000      		jmp	#$
    
  • evanhevanh Posts: 7,285
    edited 2019-04-11 - 04:09:15
    AJL wrote: »
    Normally, in little-endian systems the bytes (hexadecimal pairs) are the same as big-endian, but ordered differently; this is exactly what you are seeing.
    Ya, it's ugly and I'd prefer each hex character be displayed in little-endian order to match the hardware but with spaces between bytes it clarifies enough to be readable.
    For "pure little-endian" bit 31 would represent a value of 1, bit 30 a value of 2, and so on.
    Bad idea. Bit numbering must always represent the numerical significance. Anything else is just adding confusion.
    "... peers into the actual workings of a quantum jump for the first time. The results
    reveal a surprising finding that contradicts Danish physicist Niels Bohr's established view
    —the jumps are neither abrupt nor as random as previously thought."
  • jmgjmg Posts: 13,611
    AJL wrote: »
    Perhaps it would actually make more sense to list the data twice (little-endian for hub and "big-endian" long form for cog), as well as the hub and cog address equivalents, with a header row to show the fields, and maybe even some in-line field delimiters.
    e.g.
    hub   | bytes       | cog | long
    00040 | 7C 04 80 FE | 010 | FE80047C    | 		loc	pa, #loctest3
    00044 | 00 04 A0 FD | 011 | FDA00400    | 		call	#diagloc
    00048 |             | 012 |             |
    00048 | FC FF 9F FD | 012 | FD9FFFFC    
    0004c | 00 00 00 00 | 013 | 00000000     
    00050 | 00 00 00 00 | 014 | 00000000     
    00054 | 00 00 00 00 | 015 | 00000000      		jmp	#$
    

    That could work, as it is common for listing files to firstly follow the memory map, as in a HEX dump does.
    If there is a number involved, that could be quoted in numeric format, & should character strings be listed in ASCII ?
  • evanh wrote: »
    AJL wrote: »
    Normally, in little-endian systems the bytes (hexadecimal pairs) are the same as big-endian, but ordered differently; this is exactly what you are seeing.
    Ya, it's ugly and I'd prefer each hex character be displayed in little-endian order to match the hardware but with spaces between bytes it clarifies enough to be readable.
    For "pure little-endian" bit 31 would represent a value of 1, bit 30 a value of 2, and so on.
    Bad idea. Bit numbering must always represent the numerical significance. Anything else is just adding confusion.

    That was my point. I'm not aware of any computer systems that use "pure little-endianness" for anything but serial communications, certainly not for memory contents.
  • AJL wrote: »
    Perhaps it would actually make more sense to list the data twice (little-endian for hub and "big-endian" long form for cog), as well as the hub and cog address equivalents, with a header row to show the fields, and maybe even some in-line field delimiters.
    e.g.
    hub   | bytes       | cog | long
    00040 | 7C 04 80 FE | 010 | FE80047C    | 		loc	pa, #loctest3
    00044 | 00 04 A0 FD | 011 | FDA00400    | 		call	#diagloc
    00048 |             | 012 |             |
    00048 | FC FF 9F FD | 012 | FD9FFFFC    
    0004c | 00 00 00 00 | 013 | 00000000     
    00050 | 00 00 00 00 | 014 | 00000000     
    00054 | 00 00 00 00 | 015 | 00000000      		jmp	#$
    

    I like it! It makes clear the addressing.
    It also makes the list format fatter but that's no problem these days.
    "... peers into the actual workings of a quantum jump for the first time. The results
    reveal a surprising finding that contradicts Danish physicist Niels Bohr's established view
    —the jumps are neither abrupt nor as random as previously thought."
  • AJL wrote: »
    That was my point. I'm not aware of any computer systems that use "pure little-endianness" for anything but serial communications, certainly not for memory contents.
    Those were two independent replies. Pertaining to the first one, I'll point out that the traditional solutions have always been problematic.
    "... peers into the actual workings of a quantum jump for the first time. The results
    reveal a surprising finding that contradicts Danish physicist Niels Bohr's established view
    —the jumps are neither abrupt nor as random as previously thought."
  • evanhevanh Posts: 7,285
    edited 2019-04-11 - 06:07:03
    Eric,
    I've just had a nosy at the Fastspin sources looking for encoding details of LOC instruction. One thing that looked mismatched is in frontends/lexer.c
      // long jumps
        { "jmp" ,   0x0d800000, P2_JUMP, OPC_JUMP, 0 },
        { "call",   0x0da00000, P2_JUMP, OPC_GENERIC_BRANCH, 0 },
        { "calla",  0x0dc00000, P2_JUMP, OPC_CALL, 0 },
        { "callb",  0x0de00000, P2_JUMP, OPC_GENERIC_BRANCH, 0 },
    
    I have no understanding of these but I would have expected OPC_GENERIC_BRANCH would apply to both "calla" and "callb" equally. And presumably the OPC_CALL would go with the "call".
    PS: Fastspin v3.9.21
    "... peers into the actual workings of a quantum jump for the first time. The results
    reveal a surprising finding that contradicts Danish physicist Niels Bohr's established view
    —the jumps are neither abrupt nor as random as previously thought."
  • Thanks everyone for the suggestions / comments about listing files. Definitely there should have been spaces between the bytes to make it clear that they were bytes, not longs. I've fixed that in github now and it'll be in the next release.

    Eric
Sign In or Register to comment.