Shop OBEX P1 Docs P2 Docs Learn Events
flexspin compiler for P2: Assembly, Spin, BASIC, and C in one compiler - Page 66 — Parallax Forums

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

16364666869116

Comments

  • RaymanRayman Posts: 13,805
    edited 2020-09-25 21:56
    Is "bool_t" something that is usually defined somewhere?

  • evanhevanh Posts: 15,126
    That's probably C++ again.

    C historically relied on binary operators to handle bits within an integer (The CPU's register size). Mirroring the fact that general CPUs don't have bitwise instructions either.

  • roglohrogloh Posts: 5,122
    edited 2020-09-27 09:18
    @ersmith I just hit a snag in making my HyperRAM driver compile with both Fastspin and PNUT. This was the last thing I need to sort out before release.

    Chip's SPIN2 documentation shows this information about how to method pointers:
    Method pointers are then used in the following ways to call methods:
    
    LongVar()                                         'no parameters and no return values
    LongVar(Par1, Par2)                               'two parameters and no return values
    Var := LongVar():1                                'no parameters and one return value
    Var1,Var2 := LongVar(Par1):2                      'one parameters and two return values
    Var1,Var2 := POLXY(LongVar(Par1,Par2,Par3):2)     'three parameters and two return values
    

    I pass a callback method into my programFlash and when I try to call it, Pnut seems to want to know the number of arguments it will return. It needs the :1 on the end in order to compile in PNut.
    PUB programFlash(addr, srcHubAddr, byteCount, callBack, flags) : r | size, burst, origCount, written, eraseAddr
    
    ...
                if callback(0, origCount):1
                    return ERR_CANCELLED ' we can still cancel erase if done by sectors
    
    but Fastspin wants this syntax without the :1 on the end and won't compile with the :1
                if callback(0, origCount)
                    return ERR_CANCELLED ' we can still cancel erase if done by sectors
    

    If I include it I get this Fastspin error:

    memory.spin2:2126: error: syntax error, unexpected ':'

    Is this something that will be resolved or is there no way to use method pointers returning results in both PNut and Fastspin?
  • Rayman wrote: »
    Think I’m seeing that loadp2 only works with low number com ports. Can that be?

    No, loadp2 can work with any port, but it only auto-detects ports less than 20. For ports higher than that you'll have to use the -p option to give the port, as evanh described above.
    Rayman wrote: »
    Is "bool_t" something that is usually defined somewhere?

    No. The C99 name for a boolean type is "_Bool", and the C++ name for a boolean type is "bool" (which C99 also defines in <stdbool.h>).
  • @rogloh: The parsing of ":" in Spin2 is *highly* context dependent and very nasty, e.g. consider the fragment
      lookup( a ? b():1 ...
    
    Does that ":" go with the lookup, the ? : operator, or is it a marker of the number of results returned by b()? The current fastspin yacc parser got completely confused by things like this and I had to disable the number of results option.

    I've taken a stab at re-enabling it, you can try the binary in the attached .zip. Parsing of ":" is still very fragile though, I recommend keeping it to no more than one per line.

    @Rayman: the .zip also fixes the nested struct problem you found in C.
  • It was with the number of results returned by b() not the ? : operator. Thankfully I found a workaround and didn't need it in the end, but it would be good to allow the same syntax to work on both systems. I agree it is confusing.
  • RaymanRayman Posts: 13,805
    edited 2020-09-27 14:33
    @ersmith What kind of C compatibility are you aiming for?
    Is it C89, C99, C99 with some c++?

    Just wondering what I can look for in c codes description to know if they should work or not...

    A lot say either c89 or c99...
  • RaymanRayman Posts: 13,805
    Doesn't appear to be any way of redefining the uSD pins used in FlexC, is this right?

    BTW: Are you still calling it FlexC?

    Looks like I have to include a separate copy of the FatFs files with variable pin defines.
    Maybe that's the way to go anyway since I want to expand on the types of drives later...
  • Rayman wrote: »
    @ersmith What kind of C compatibility are you aiming for?
    Is it C89, C99, C99 with some c++?
    Eventually C99 with a few C++ extensions.

    Rayman wrote: »
    Doesn't appear to be any way of redefining the uSD pins used in FlexC, is this right?
    Not yet; it's something that would be nice to have (some parameter to the _vfs_open_sdcard() function, or something like that).
    BTW: Are you still calling it FlexC?

    Yes. I'll probably rename the whole system + GUI "FlexProp" or something like that so the compilers can stay "FlexC", "FlexBASIC", and "FlexSpin".
  • JRoarkJRoark Posts: 1,214
    edited 2020-09-27 22:02
    Yes. I'll probably rename the whole system + GUI "FlexProp" or something like that so the compilers can stay "FlexC", "FlexBASIC", and "FlexSpin".

    Your Marketing Dept approves. :). The term “Flex” aptly describes this suite for its interoperability.
  • RaymanRayman Posts: 13,805
    I'm getting errors when trying to declare an array inside a function like this:
    uint32_t pixels[camResX * camResY];
    

    Where camResX and Y are inputs to the function. Says "Unable to determine size of array".

    Is this a bug or are you not allowed to do this in C?
  • Rayman wrote: »
    I'm getting errors when trying to declare an array inside a function like this:
    uint32_t pixels[camResX * camResY];
    

    Where camResX and Y are inputs to the function. Says "Unable to determine size of array".

    Is this a bug or are you not allowed to do this in C?

    That's a C99 special feature, variable-sized local arrays... If it doesn't work like that, try replacing it with
    uint32_t *pixels = alloca(camResX * camResY * sizeof(uint32_t));
    
    I think fastspin supports alloca...
  • evanhevanh Posts: 15,126
    It's not a compile time known therefore requires runtime smarts to handle. To do that in C you'd be malloc()ing and using pointers. Ie: Handcrafted or a support library. And C++ can make it look tidy.

    Interpreted languages could do it. Compiled languages with garbage collection can probably handle it. I've always avoided those for realtime work so don't really know.

  • evanhevanh Posts: 15,126
    Wuerfel_21 wrote: »
    That's a C99 special feature, variable-sized local arrays...
    Cool. I guess I should get up to speed on C99 at some stage.

  • ersmith wrote: »
    Rayman wrote: »
    @ersmith What kind of C compatibility are you aiming for?
    Is it C89, C99, C99 with some c++?
    Eventually C99 with a few C++ extensions.
    If you get C99 compatibility that could eventually allow a native Micropython compilation too. :smile: Though a Makefile compatible build sequence would be preferable there if you don't have a separate linker. I don't imagine hundreds of files on the one command line.
  • RaymanRayman Posts: 13,805
    edited 2020-09-29 15:15
    I've got one FTDI EVE2 example code working in FlexC (Yeh!)

    Trying this "Jackpot" example and getting "error: too many initializers for struct or union" errors on several array initializers.
    I'm not sure if they are using C++ stuff here or if it's a bug...

    Anyway, here's an example that errors out:
    bet_lines_index linePosition[] = {
    
    	{'t','t','t','t','t'},  //0
    	{'t','t','t','m','b'},//1
    	{'m','m','m','m','m'},//2
    	{'m','m','m','m','t'},//3
    	{'b','b','b','b','b'},//4
    	{'b','b','b','m','t'},//5
    	{'m','t','t','t','t'},//6
    	{'t','m','b','m','t'},//7
    	{'b','m','m','m','m'},//8
    	{'t','m','m','m','m'},//9
    	{'m','m','m','m','b'},//10
    	{'b','m','t','m','b'}//11
    
    };
    

    Where the type is defined like this:
    typedef struct bet_lines_index_t
    {
    	char8_t line[5];
    }bet_lines_index;
    

    Also, there's this in a .h file:
    typedef char		char8_t;
    

    Should this work?
  • RaymanRayman Posts: 13,805
    Seems I might be able to fix it by changing the above declaration to this:
    char linePosition[12][5]=
    {
    

    And, changing references from this:
    if(linePosition[i].line[j] == 't'){
    

    to this:
    if (linePosition[i][j] == 't') {
    
  • RaymanRayman Posts: 13,805
    FlexC appears to be working out really well in compiling FTDI EVE2 example code!
    Two more worked without the need for workarounds...

    But, (sorry to do this to you), I found a couple hiccups in this keyboard editor example...

    This gives the error: Expected integer type for parameter of operator
    Buffer.temp = Buffer.notepad[Line]+strlen(Buffer.notepad[Line]);  // load into temporary buffer
    

    Where buffer is defined like this:
    struct Notepad_buffer
    {
    	char8_t *temp;
    	char8_t  notepad[MAX_LINES][80];
    }Buffer;
    

    But, the strange thing is that if I break it up like this, it doesn't give an error:
          int x= strlen(Buffer.notepad[Line]);  // load into temporary buffer 
          Buffer.temp = Buffer.notepad[Line] + x;  // load into temporary buffer
    
  • RaymanRayman Posts: 13,805
    edited 2020-09-29 19:57
    Here's another one I don't get...
      static uint8_t Read_tag=0,temp_tag=0,ret_tag=0,touch_detect=1;	
      Read_tag = Gpu_Hal_Rd8(phost,REG_TOUCH_TAG);
      ret_tag = NULL;
    

    The bottom line gives "incompatible types in assignment" error...

    It's OK with this:
    ret_tag = (uint8_t) NULL; //RJA added typecast
    

    Good News is that it does seem to work with those workarounds...
    3024 x 4032 - 4M
  • Eric, I think Chip's Spin has the redirected SEND restored at the end of each method call back to that of the caller. Fastspin's SEND seems to take effect globally after it is called. This is a key difference, which if remedied, may impact performance as I could see that checking/restoring it after every function call could be slow and consume more memory too, particularly once it is a per COG setting as intended. What's your plan for SEND and the new RECV with Fastspin?
  • Rayman wrote: »
    Here's another one I don't get...
      static uint8_t Read_tag=0,temp_tag=0,ret_tag=0,touch_detect=1;	
      Read_tag = Gpu_Hal_Rd8(phost,REG_TOUCH_TAG);
      ret_tag = NULL;
    

    The bottom line gives "incompatible types in assignment" error...

    It's OK with this:
    ret_tag = (uint8_t) NULL; //RJA added typecast
    

    That one is just terrible. NULL is the value for an invalid pointer, not necessarily zero. If you want to set an integer to zero, just use zero...
  • RaymanRayman Posts: 13,805
    Think I'm seeing an issue initializing a structure that includes an array like this:
    /* Arrawy used for custom fonts */
    S_LiftAppFont_t G_LiftAppFontArrayNumbers[1] =
    {
    	//font structure
    	{
    		/* Max Width */
    		80,
    		/* Max Height */
    		156,
    		/* Max Stride */
    		80,
    		/* format */
    		L8,
    		/* Each character width */
    		80, 80, 80, 80, 80, 80, 80, 80, 80, 80, 80, 80,
    	}
    };
    

    Where the type is defined like this:
    typedef struct S_LiftAppFont
    {
    	uint32_t MaxWidth;
    	uint32_t MaxHeight;
    	uint32_t Stride;
    	uint8_t Format;
    	uint8_t Width[LIFTAPPMAXCHARS];
    }S_LiftAppFont_t;
    

    Gives: error: too many initializers for struct or union
    on "Max Width" line.
  • RaymanRayman Posts: 13,805
    is abs() part of stdlib? Doesn't seem to be finding it...
  • Rayman,
    You shouldn't be using NULL with non-pointer types.

    abs() would be in math.h
  • RaymanRayman Posts: 13,805
    edited 2020-09-30 18:07
    This is code from FTDI... EVE2 examples... Not mine...

    This code seems to have worked with a variety of other compilers...

    I agree that it's not good style though..
  • @Rayman: Thanks for the various bug reports -- you're really givinig this a good workout! Some points:

    - Most of the initialization problems stem from FlexC being too strict on initializers; it wants arrays inside of structs (and structs inside arrays) to always be enclosed in {}. The C standard allows this to be relaxed in some cases. I'll try to fix this. In the meantime whenever you get an error like that look at the structure and try to make the initializer layout fully match the logical layout of the structure, with each sub-array or sub-structure delimited by {}.

    - The strlen problem is a missing #include of <string.h>

    - As @Wuerfel_21 noted abs() is in <math.h>
  • rogloh wrote: »
    Eric, I think Chip's Spin has the redirected SEND restored at the end of each method call back to that of the caller. Fastspin's SEND seems to take effect globally after it is called. This is a key difference, which if remedied, may impact performance as I could see that checking/restoring it after every function call could be slow and consume more memory too, particularly once it is a per COG setting as intended. What's your plan for SEND and the new RECV with Fastspin?

    I can't guarantee anything, but I'll try to make SEND in fastspin work with any real world objects that use it.
  • On the subject of variable length arrays, I do plan to support them eventually, but not in this release. Just replacing the array declaration with an alloca() would be straightforward, but the C standard requires that the memory be reclaimed when the array goes out of scope, and that part will need some work.
  • Here's an updated fastspin.zip that has better code for C initialization and which saves/restores the SEND pointer in any function which modifies it.
  • ersmith wrote: »
    Here's an updated fastspin.zip that has better code for C initialization and which saves/restores the SEND pointer in any function which modifies it.

    Thanks Eric. :smile:
Sign In or Register to comment.