Shop OBEX P1 Docs P2 Docs Learn Events
Can't Wait for PropGCC on the P2? - Page 5 — Parallax Forums

Can't Wait for PropGCC on the P2?

1235726

Comments

  • I can't find propeller1.h in my install of SimpleIDE/PropGCC. I'll just replace the reference to getcnt() with CNT, and that will solve the problem in sdspi.h.
  • Dave Hein wrote: »
    I can't find propeller1.h in my install of SimpleIDE/PropGCC. I'll just replace the reference to getcnt() with CNT, and that will solve the problem in sdspi.h.
    propeller1.h is part of the more recent build of PropGCC that SimpleIDE does not use. When I say "recent" I mean one that is several years old at least. It's the version that supports P2-hot which is why there is a propeller1.h and a propeller2.h.

  • I have updated p2gcc, and attached the latest zip file here. I moved the file I/O routines to the stdio library. I also modified p2link and loadp2 so that a binary executable could be linked to a starting address other than zero. I then created a new sample program called shell.c that starts at address 0x8000 in hub RAM. This program can load binary files from an SD card and execute them. There's a script file named build_all that will build all of the sample programs. The binary files can then be copied to an SD card, which can be used by the shell program. The shell program is built and loaded by running the load_shell script file.

    I now include the fft_bench program. It runs in 54 msec with the P2 set at 60 MHz.

    I added support for spinsim to the p2gcc script file. A program can be build and run using the simulator by specifying the -s option. As an example, the hello program is run under spinsim by typing "p2gcc -s hello.c". spinsim is not included in the zipfile, and must be built separately.

    p2gcc now requires that the bin directory be added to the PATH environment variable. Alternatively, the contents of the bin directory could be copied to an existing directory that is already included in the PATH. p2gcc also requires that the environment variable P2GCC_LIBDIR be specified and set to point to the p2gcc lib directory.

    Another change I made was to enable the -c option in p2asm that makes the assembler case sensitive. This is required so that C variables such as temp and Temp can be distinguished from each other. PASM symbols, such as IF_C_OR_NZ are still handled without case sensitivity.

    I renamed s2p to s2pasm. It turns out that there is already a Linux utility named s2p.

    I renamed the dump utility to p2dump. I also added a disassembler option to p2dump. The disassembler can produce a spin2 file from a binary file that can be re-assembled back to a matching binary file. I've tested it with most of the sample programs that Chip includes with his FPGA updates.
  • evanhevanh Posts: 15,091
    You have been busy! I should give p2asm whirl. The PNut route gets a bit monotonous having to click back and forth between windows. Not to mention the recurring PNut jam-ups when I accidentally have two programs vying for the one comport due to PNut insisting on it's download after compile.
  • evanh wrote: »
    ...PNut insisting on it's download after compile.
    In Pnut a Ctrl-M (List Toggle - PASM) will compile without a download.


  • evanhevanh Posts: 15,091
    ozpropdev wrote: »
    In Pnut a Ctrl-M (List Toggle - PASM) will compile without a download.
    Ha, indeed it does, thanks for that.
  • The attached file contains the latest version of p2gcc, which has been updated to support the v32b FPGA image. The source is also available on GitHub at https://github.com/davehein/p2gcc .
  • dgatelydgately Posts: 1,620
    edited 2018-04-24 00:40
    BTW: the build_linux script works in building p2gcc and other binaries in the project, on macOS as well!

    dgately
  • Thanks. I added that comment about macOS to the readme.txt file, and checked it into GitHub.
  • cgraceycgracey Posts: 14,131
    Dave Hein wrote: »
    The attached file contains the latest version of p2gcc, which has been updated to support the v32b FPGA image. The source is also available on GitHub at https://github.com/davehein/p2gcc .

    Dave, does this mean we have a passable C compiler for the Prop2, or one that can be made into a final compiler? Please forgive my ignorance on this subject. Thanks for taking interest in this!
  • Dave Hein wrote: »
    Thanks. I added that comment about macOS to the readme.txt file, and checked it into GitHub.
    Thanks, but I spoke a little too soon!

    First, loadp2 needs a little help! You'll need to "#define MACOSX" in building loadp2 for a Mac to find a P2 on a PropPlug (a small serial open issue). A new build_macosx file that does the define before it execs compiles osint_linux.c, would fix this!

    There's code in osint_linux.c that needs the MACOSX define. Here's an example:
    /* open the port */
    #ifdef MACOSX
        hSerial = open(port, O_RDWR | O_NOCTTY | O_NONBLOCK);
    #else
        hSerial = open(port, O_RDWR | O_NOCTTY | O_NDELAY | O_NONBLOCK);
    #endif
    

    Once the above is fixed, p2gcc seems to compile a binary, loadp2 appears to upload it to the FPGA (DE0-Nano), but it's not getting expected results on the FPGA. I'm running a simple blink.c type program, that should blink an LED on pins P0 or P1. Could be my code...
    #include <propeller.h>
    
    unsigned int _clkfreq = 60000000;
    
    int main(void)
    {
      DIRB |= (3);
      while (1) {
          OUTB |= (1 << 1);     // turn on pin #1?
          waitcnt(((CLKFREQ / 50) + CNT));
          OUTB &= (0 << 1);     // turn off pin #1?
          waitcnt(((CLKFREQ / 50) + CNT));
      }
    }
    
    With the limit in cogs on the DE0-Nano, I'm not sure if any of the examples should work (dry.c, prime.c, etc...), as they do not return any text when run with "-t"...

    dgately
  • Dave HeinDave Hein Posts: 6,347
    edited 2018-04-24 13:03
    Single-character non-buffered serial I/O is a little tricky on the Mac. Output should work fine, but it may be hanging on the input. I found a solution for spinsim, but I'm not sure I ported that to loadp2. I'll look into it when I have a chance.
  • Dave HeinDave Hein Posts: 6,347
    edited 2018-04-24 13:02
    cgracey wrote: »
    Dave Hein wrote: »
    The attached file contains the latest version of p2gcc, which has been updated to support the v32b FPGA image. The source is also available on GitHub at https://github.com/davehein/p2gcc .

    Dave, does this mean we have a passable C compiler for the Prop2, or one that can be made into a final compiler? Please forgive my ignorance on this subject. Thanks for taking interest in this!
    I think p2gcc is a passable C compiler for the P2. However, it is not intended to be the final compiler for the P2. I'm hoping Parallax and people that are more experienced with GCC get involved at some point, and a compiler such as PropGCC can be developed for the P2. I think components of p2gcc can be used, but we need a team of people that understand GUIs, ELF files and other details to really make it work for everyone.

  • Dave Hein wrote: »
    cgracey wrote: »
    Dave Hein wrote: »
    The attached file contains the latest version of p2gcc, which has been updated to support the v32b FPGA image. The source is also available on GitHub at https://github.com/davehein/p2gcc .

    Dave, does this mean we have a passable C compiler for the Prop2, or one that can be made into a final compiler? Please forgive my ignorance on this subject. Thanks for taking interest in this!
    I think p2gcc is a passable C compiler for the P2. However, it is not intended to be the final compiler for the P2. I'm hoping Parallax and people that are more experienced with GCC get involved at some point, and a compiler such as PropGCC can be developed for the P2. I think components of p2gcc can be used, but we need a team of people that understand GUIs, ELF files and other details to really make it work for everyone.
    As I understand it, p2gcc depends on PropGCC for P1 to compile the C/C++ code. Given that, I'm not sure p2gcc is a viable alternative unless some effort gets put into PropGCC for P1. It isn't really possible to just let PropGCC for P1 run on autopilot. David Zemon's build server currently cannot build PropGCC because of issues that have crept in with later versions of the tools used to build it. The sources have to be continually updated for the more modern tools and the code should be updated to the later releases of the GCC and binutils sources as well. As far as I can tell, even PropGCC for P1 is currently broken so any tool like p2gcc that sits on top of it is also broken.
  • Dave HeinDave Hein Posts: 6,347
    edited 2018-04-24 19:34
    dgately, I think the problem you're having is due to a change I made in the stack setting in lib/prefix.spin2. I changed it from 32K to 104K when I was doing some tests with a VGA driver. Try changing "hub_ram_size = 104 *1024" to "hub_ram_size = 30 *1024". The DE0-Nano only has 32K of RAM, so a stack at 104K won't work. I think we need to use 30K instead of 32K because of the way the last 2K of ram is handled now.

    You will also need to assemble prefix.spin2 to build a new object file. From the lib directory run "p2asm -o prefix.spin2".
  • Dave Hein wrote: »
    dgately, I think the problem you're having is due to a change I made in the stack setting in lib/prefix.spin2. I changed it from 32K to 104K when I was doing some tests with a VGA driver. Try changing "hub_ram_size = 104 *1024" to "hub_ram_size = 30 *1024". The DE0-Nano only has 32K of RAM, so a stack at 104K won't work. I think we need to use 30K instead of 32K because of the way the last 2K of ram is handled now.

    You will also need to assemble prefix.spin2 to build a new object file. From the lib directory run "p2asm -o prefix.spin2".

    Thanks! Yes, set the hub ram size to 30*1024, re-assembled prefix.spin2 and "most" of the test samples respond. One thing to note is that p2gcc cannot find P2's with its current method on macOS. macOS does not use the Linux-type, iterative port naming, so p2gcc will never find a port that looks like "cu.usbserial-AE00BG4H", on macOS. So, I use loadp2 with "-p /dev/cu.usbserial-AE00BG4H..." after creating an output file from p2gcc, to load binaries to the P2.

    Also, I'm getting text responses in a terminal for many of the samples, but 0 (zero) values from dry.c, prime.c, etc...

    Not able to blink an LED yet, with the code from my post above. Not also able to get the blin.c sample to blink an LED either. Timing issue?

    Could all be something I'm missing, of course!

    dgately


  • Could you try building "p2gcc -v test7.c test8.c", and then run the binary a.out. Please post the output from both the build and from running the executable. There may be a problem in the linker.
  • Dave Hein wrote: »
    Could you try building "p2gcc -v test7.c test8.c", and then run the binary a.out. Please post the output from both the build and from running the executable. There may be a problem in the linker.
    $p2gcc -v test7.c test8.c
    propeller-elf-gcc -mcog -Os -m32bit-doubles -S test7.c
    s2pasm -g -p/opt/parallax/lib/prefix.spin2 test7
    p2asm -c -o test7.spin2
    propeller-elf-gcc -mcog -Os -m32bit-doubles -S test8.c
    s2pasm -g -p/opt/parallax/lib/prefix.spin2 test8
    p2asm -c -o test8.spin2
    p2link /opt/parallax/lib/prefix.o -v test7.o test8.o /opt/parallax/lib/stdio.a /opt/parallax/lib/stdlib.a /opt/parallax/lib/string.a
    Found offset of 52 for symbol ___files of type R at location 5dc
    Found offset of 52 for symbol ___files of type R at location 840
    Found offset of 12 for symbol ___files of type W at location 1004
    WARNING: Global variable ___files initialized in another object
    Setting value of _heapaddrlast at location 5ce4 to 5f28
    Setting value of _heapaddr at location 5ce8 to 5f28
    
    $ls -latr
    -rw-r--r--    1 myUser  staff     1281 Apr 24 20:23 test7.o
    -rw-r--r--    1 myUser  staff     1964 Apr 24 20:23 test8.o
    drwxr-xr-x   47 myUser  staff     1504 Apr 24 20:23 .
    -rw-r--r--    1 myUser  staff    24360 Apr 24 20:23 a.out
    
    $p2load -p /dev/cu.usbserial-AE00BU4H -b 115200 -t -v /Users/myUser/source/p2gcc/a.out
    Loading /Users/myUser/source/p2gcc/a.out - 24360 bytes
    /Users/myUser/source/p2gcc/a.out loaded
    [ Entering terminal mode.  Press ESC to exit. ]
    value1 = 0, &value1 = 0
    value2 = 0, &value2 = 0
    value3 = 0, &value3 = 0
    __files = 0
    &__files[1] = 0
    sizeof(FILE) = 0
    value1 = 0, &value1 = 0
    value2 = 0, &value2 = 0
    value3 = 0, &value3 = 0
    value4 = 0, &value4 = 0
    value5 = 0, &value5 = 0
    __files = 0
    &__files[1] = 0
    

    BTW: I move copies of the lib & bin directories to /opt/parallax/lib & /opt/parallax/bin/ since those are my system's known paths to propeller binaries & libs.

    dgately
  • David Betz wrote: »
    David Zemon's build server currently cannot build PropGCC because of issues that have crept in with later versions of the tools used to build it. The sources have to be continually updated for the more modern tools and the code should be updated to the later releases of the GCC and binutils sources as well. As far as I can tell, even PropGCC for P1 is currently broken so any tool like p2gcc that sits on top of it is also broken.

    As far as I can tell from the error, the build server just needs makeinfo installed, should not be a big problem. I'm compiling propgcc myself on an updated ubuntu server and I don't see any problem with it. Maybe I can help if you have issues.
  • macca wrote: »
    David Betz wrote: »
    David Zemon's build server currently cannot build PropGCC because of issues that have crept in with later versions of the tools used to build it. The sources have to be continually updated for the more modern tools and the code should be updated to the later releases of the GCC and binutils sources as well. As far as I can tell, even PropGCC for P1 is currently broken so any tool like p2gcc that sits on top of it is also broken.

    As far as I can tell from the error, the build server just needs makeinfo installed, should not be a big problem. I'm compiling propgcc myself on an updated ubuntu server and I don't see any problem with it. Maybe I can help if you have issues.
    This particular problem may be fairly easy to fix but it just points out that you can't just assume that something that was once working will continue working forever without some attention.

  • David Betz wrote: »
    This particular problem may be fairly easy to fix but it just points out that you can't just assume that something that was once working will continue working forever without some attention.

    Have you sent a note to David Zemon reporting the problem ?
  • dgately wrote: »
    Dave Hein wrote: »
    Could you try building "p2gcc -v test7.c test8.c", and then run the binary a.out. Please post the output from both the build and from running the executable. There may be a problem in the linker.
    $p2gcc -v test7.c test8.c
    propeller-elf-gcc -mcog -Os -m32bit-doubles -S test7.c
    s2pasm -g -p/opt/parallax/lib/prefix.spin2 test7
    p2asm -c -o test7.spin2
    propeller-elf-gcc -mcog -Os -m32bit-doubles -S test8.c
    s2pasm -g -p/opt/parallax/lib/prefix.spin2 test8
    p2asm -c -o test8.spin2
    p2link /opt/parallax/lib/prefix.o -v test7.o test8.o /opt/parallax/lib/stdio.a /opt/parallax/lib/stdlib.a /opt/parallax/lib/string.a
    Found offset of 52 for symbol ___files of type R at location 5dc
    Found offset of 52 for symbol ___files of type R at location 840
    Found offset of 12 for symbol ___files of type W at location 1004
    WARNING: Global variable ___files initialized in another object
    Setting value of _heapaddrlast at location 5ce4 to 5f28
    Setting value of _heapaddr at location 5ce8 to 5f28
    
    $ls -latr
    -rw-r--r--    1 myUser  staff     1281 Apr 24 20:23 test7.o
    -rw-r--r--    1 myUser  staff     1964 Apr 24 20:23 test8.o
    drwxr-xr-x   47 myUser  staff     1504 Apr 24 20:23 .
    -rw-r--r--    1 myUser  staff    24360 Apr 24 20:23 a.out
    
    $p2load -p /dev/cu.usbserial-AE00BU4H -b 115200 -t -v /Users/myUser/source/p2gcc/a.out
    Loading /Users/myUser/source/p2gcc/a.out - 24360 bytes
    /Users/myUser/source/p2gcc/a.out loaded
    [ Entering terminal mode.  Press ESC to exit. ]
    value1 = 0, &value1 = 0
    value2 = 0, &value2 = 0
    value3 = 0, &value3 = 0
    __files = 0
    &__files[1] = 0
    sizeof(FILE) = 0
    value1 = 0, &value1 = 0
    value2 = 0, &value2 = 0
    value3 = 0, &value3 = 0
    value4 = 0, &value4 = 0
    value5 = 0, &value5 = 0
    __files = 0
    &__files[1] = 0
    

    BTW: I move copies of the lib & bin directories to /opt/parallax/lib & /opt/parallax/bin/ since those are my system's known paths to propeller binaries & libs.

    dgately
    The linker prints match the ones I get. The binary file size matches as well. Can you post your a.out file so I can compare it to mine. You may have to put it in a zip file so that the forum software will allow you to attach it.

  • macca wrote: »
    David Betz wrote: »
    This particular problem may be fairly easy to fix but it just points out that you can't just assume that something that was once working will continue working forever without some attention.

    Have you sent a note to David Zemon reporting the problem ?

    Yes, he's aware :)
    He's working on a Docker solution so that this doesn't happen again. The current problem is because I migrated servers and apparently forgot to install the old texinfo package.
  • dgately, I've attached a zipfile with the binary files for all the test programs with the stack at 30K. Can you try running some of these to see if they work for you.
  • Dave Hein wrote: »
    dgately wrote: »
    Dave Hein wrote: »
    Could you try building "p2gcc -v test7.c test8.c", and then run the binary a.out. Please post the output from both the build and from running the executable. There may be a problem in the linker.
    The linker prints match the ones I get. The binary file size matches as well. Can you post your a.out file so I can compare it to mine. You may have to put it in a zip file so that the forum software will allow you to attach it.

    The a.out is attached as a zip!

    dgately
  • Dave Hein wrote: »
    dgately, I've attached a zipfile with the binary files for all the test programs with the stack at 30K. Can you try running some of these to see if they work for you.

    Results attached

    dgately

  • I ran your a.out under spinsim, and it produces the same output as the test7.bin that I posted in the zipfile. I did a binary compare of a.out and test7.bin, and they are different. However, the differences are insignificant, and I suspect it's because we may be using different versions of propeller-elf-gcc. I ran p2dump on both files and did a diff. The results are as follows:
    446,449c446,449
    < 06f4 fb042e0c              rdlong  $17, #$c
    < 06f8 fc602e16              wrlong  $17, $16
    < 06fc ff000004              augs    #4 << 9
    < 0700 fb041c10              rdlong  $e, #$10
    ---
    > 06f4 fb041c10              rdlong  $e, #$10
    > 06f8 ff000004              augs    #4 << 9
    > 06fc fb042e0c              rdlong  $17, #$c
    > 0700 fc602e16              wrlong  $17, $16
    452,454c452,454
    < 070c f6002816              mov     $14, $16
    < 0710 f1042808              add     $14, #8
    < 0714 fb001a0e              rdlong  $d, $e
    ---
    > 070c fb001a0e              rdlong  $d, $e
    > 0710 f6002816              mov     $14, $16
    > 0714 f1042808              add     $14, #8
    
    The difference is due to a slightly different order of operations. The different order shouldn't affect the results.

    So there must be some problem with loadp2 loading your FPGA board. I'll look into it some more.
  • Dave Hein wrote: »
    So there must be some problem with loadp2 loading your FPGA board. I'll look into it some more.

    Yes, probably! I use:
    $ propeller-elf-gcc --version
    propeller-elf-gcc (propellergcc-alpha_v1_9_0_) 4.6.1
    Copyright (C) 2011 Free Software Foundation, Inc.
    This is free software; see the source for copying conditions.  There is NO
    warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
    
    Here's a dry.c build where I specify keeping all intermediate files (which I zipped-up and have attached):
    $ p2gcc -v -k dry.c -o dry.myout
    propeller-elf-gcc -mcog -Os -m32bit-doubles -S dry.c
    s2pasm -g -p/opt/parallax/lib/prefix.spin2 dry
    p2asm -c -o dry.spin2
    p2link /opt/parallax/lib/prefix.o -v dry.o -o dry.myout /opt/parallax/lib/stdio.a /opt/parallax/lib/stdlib.a /opt/parallax/lib/string.a
    Found offset of 12 for symbol ___files of type W at location 46e4
    Setting value of _heapaddrlast at location 4abc to 4b80
    Setting value of _heapaddr at location 4ac0 to 4b80
    
    $ ls -al | grep dry
    -rw-r--r--    1 altergator  staff    16704 Apr 25 10:11 dry.bin
    -rwxr-xr-x    1 altergator  staff    37387 Apr 23 17:26 dry.c
    -rw-r--r--    1 altergator  staff    46795 Apr 25 10:11 dry.lst
    -rw-r--r--    1 altergator  staff    19328 Apr 25 10:11 dry.myout
    -rw-r--r--    1 altergator  staff    21919 Apr 25 10:11 dry.o
    -rw-r--r--    1 altergator  staff    17113 Apr 25 10:11 dry.s
    -rw-r--r--    1 altergator  staff    21215 Apr 25 10:11 dry.spin2
    

    Hopefully, something might help in finding an issue. Are you testing with a DE0-Nano or BeMicro-A2? All I have are these single cog FPGAs, so could that be problematic for these test examples?

    dgately
    dry.zip 39.9K
  • My version for propeller-elf-gcc is (propellergcc_v1_0_0_2408) 4.6.1, so it is different from yours. I ran both your dry binary file and mine, and the outputs are identical except for the cycle times. Here's a diff of the outputs.
    7c7
    < User_Time = 48721773 - 13201709 = 35520064
    ---
    > User_Time = 48641773 - 13201709 = 35440064
    12c12
    < User_Time = 405125853 - 49925789 = 355200064
    ---
    > User_Time = 404245853 - 49845789 = 354400064
    64c64
    < Dhrystones per Second:                      8445 
    ---
    > Dhrystones per Second:                      8465 
    
    Because some of the instructions are in a different order they will hit the hub at different times. This causes the different cycle times.

    I'm using the DE2-115, but I verified in spinsim that only cog 0 is used. So it should work on a single cog FPGA. I'm wondering if the 2 Mbaud rate is causing problems in loadp2. Maybe you could try a lower baud rate by changing the define for LOADER_BAUD in p2load.c to a lower value.
  • dgately, please try running the two test programs that are in the attached zipfile. test1.c is a minimal program that just prints "Hello". test2.c checks an array of 5000 ints to see if there is any data corruption.
Sign In or Register to comment.