Shop OBEX P1 Docs P2 Docs Learn Events
LLVM Backend for Propeller 2 - Page 9 — Parallax Forums

LLVM Backend for Propeller 2

179111213

Comments

  • I changed them on purpose--the locations loadp2 uses will intersect with the entry routine. So if you use the patching in loadp2 it will not function properly. So to use the locations from loadp2, we'd need to change how startup works to add a function to jump over those locations. In fact, looking at it now, even my locations intersect if you patch it in... so maybe the best course of action is to move the entry function, and make the instruction at 0x00 just jump to that function

    As an aside, where do those addresses come from? Convention from P1? Is there a specific reason we need to keep those values at those addresses, or can we leave it up to compiler implementation to define? It would make patching when loading a bit more difficult, because you'd need to specify where to patch the values, but adds flexibility.

  • Okay it was actually pretty simple. Something like this: https://github.com/ne75/p2llvm/blob/new_startup/libp2/lib/crt0.c. lets merge your changes to set clkmode on startup into this branch to change it all at once in mater

  • RaymanRayman Posts: 14,579

    @iseries I'm not finding libp2.a ... Where should it be?

  • hummm, don't see any code at those locations?

           0: f8 a1 03 fb            rdlong r0, ptra    
           4: 00 00 00 ff            augs #0
           8: 40 a0 07 f6            mov r0, #64    
           c: d0 01 e8 fc            coginit #0, r0 
    
    Disassembly of section .cog:
    
    00000040 <__start>:
          40: f8 a1 03 fb            rdlong r0, ptra    
          44: 29 fe 67 fd            setq2 #511
    

    Seems to work fine for me.

    Mike

    Dave Hein came up with those numbers who wrote the loadp2 code. Chip had some numbers as well but I don't think they match. And yes, the P1 had similar items.

  • n_ermoshn_ermosh Posts: 293
    edited 2022-02-19 19:19

    @iseries said:
    hummm, don't see any code at those locations?

           0: f8 a1 03 fb              rdlong r0, ptra    
           4: 00 00 00 ff              augs #0
           8: 40 a0 07 f6              mov r0, #64    
           c: d0 01 e8 fc              coginit #0, r0 
    
    Disassembly of section .cog:
    
    00000040 <__start>:
          40: f8 a1 03 fb              rdlong r0, ptra    
          44: 29 fe 67 fd              setq2 #511
    

    Seems to work fine for me.

    Mike

    Dave Hein came up with those numbers who wrote the loadp2 code. Chip had some numbers as well but I don't think they match. And yes, the P1 had similar items.

    It looks like you removed the debug init code (https://github.com/iseries1/p2llvm/blob/master/libp2/lib/crt0.c#L33-L43), so yours is okay, but if you leave the debug code in, it makes the __entry function extend up to 0x24.

    Also, to set the patched values, you should be able to just call _clkset instead of using a bunch of inline assembly, like you have here https://github.com/iseries1/p2llvm/blob/master/libp2/lib/crt0.c#L72-L83

  • @Rayman ,

    When I loaded my project I had 555 items, you only have 400?

    What path did you use to build your P2LLVM code?

    I made a folder called "opt" and then "p2llvm". In there you put bin, lib, libc, libp2 folders.

    Mike

  • Where does Chip put his debug code? He uses similar addresses.

    Mike

  • RaymanRayman Posts: 14,579
    edited 2022-02-19 19:33

    Here's what opt looks like (see pic). Is this right?

    Just tried to build a cpp file and got this:

    C:\opt\p2llvm\llvm-project\build\Release>clang --target=p2 -Wl,--gc-sections -Wl,--print-gc-sections -o test.elf test.o
    ld.lld: error: unable to find library -lc
    ld.lld: error: unable to find library -lp2
    clang: error: ld.lld command failed with exit code 1 (use -v to see invocation)

    Also, the solution does show 555 projects...

    1094 x 827 - 48K
  • n_ermoshn_ermosh Posts: 293
    edited 2022-02-19 19:25

    @iseries said:
    Where does Chip put his debug code? He uses similar addresses.

    Mike

    Not sure, but hubset to enable cog 0 debugging needs to be called before coginit for cog 0, so it needs to happen in __entry. Actual debugger code lives in debug space at the end of RAM

  • RaymanRayman Posts: 14,579
    edited 2022-02-19 19:35

    @iseries VS Solution looks like this:

    516 x 1088 - 57K
  • @Rayman ,

    Looks like you have everything. You need to build libc.a and libp2.a before you can compile.

    My github environment is located somewhere else so I just copy bin, lib over to this location.

    I have a startup shortcut that adds bin to my path so I can compile with a special bat file.

    P2 LLVM folders

    Mike

  • RaymanRayman Posts: 14,579

    @iseries How do I build libc.a and libp2.a ?

  • RaymanRayman Posts: 14,579

    Looks like I was supposed to do "cmake libc" at some point?

  • @Rayman ,

    That's a good one. My Cmake does not work for that so I used make instead. There are some leftover make files in each folder that when you run make it will create a build folder and put the two archives in it. Those need to be copied out to the p2llvm folder.

    Don't know if you can get cmake to work for you but you can also try that. cd to libp2 and run cmake I think.

    I could also give you a copy of libc.a and libp2.a but these would be custom build and not the official versions, but I know they work.

    Mike

  • RaymanRayman Posts: 14,579

    @iseries If you can just give me these files, that would be great. I don't think I have "make" installed...

  • RaymanRayman Posts: 14,579

    I'm guessing I could build these with make on a Mac, right? Would those then be able to be used in Windows?

  • you can download a build off of Zemon's CI server here: https://ci.zemon.name/repository/download/P2llvm_LlvmMacosArm/14773:id/p2llvm-macos-arm64-be79cd8705edcbb3b3e2b4e1d5f4927500c77573.tar.gz?guest=1 and pull out the built libraries from there.

  • @Rayman said:
    I'm guessing I could build these with make on a Mac, right? Would those then be able to be used in Windows?

    Yeah that would work, and for mac or linux, you don't need to build from scratch--we've got it building for linux and mac (for both arm and x86)

  • @Rayman ,

    Please note that programs that are compiled with libp2.a have debug code in them and will generate bloated programs (512k) in size. This does not represent the program size just that in order to load them as one file they need to load the dead space as well.

    I disabled the debug code and my compiles are around 25k for a simple program.

    Mike

  • RaymanRayman Posts: 14,579

    @iseries I was just about to ask about that!

  • RaymanRayman Posts: 14,579

    How do you disable the debug code?

  • @Rayman said:
    How do you disable the debug code?

    If you use the downloaded build, libp2.a no longer contains debug code--that now lives in libp2db.a, so if you don't link p2db, no debugging code should be included.

  • Only thing is that I think it will still try to load 0's for that section of code, which is at the end of ram, so if you first use objcopy to convert the elf to load a bin, it will load significantly faster cause it will ignore all of that.

  • RaymanRayman Posts: 14,579
    edited 2022-02-19 20:18

    @n_ermosh I downloaded libp2.a from Zemon's CI server using your link and it compiled.
    But, my nearly empty program produced a 521 kB elf file.
    So, maybe it's still in that one?

    Also, it seems I need to compile loadp2.exe as well.
    Is this the same loadp2 that I think has been around?

  • In the build for libc I see that the math functions are commented out. I need the atan2f function which are in there. Can I just add that back or is there a reason those are not included?

    Mike

  • @Rayman said:
    @n_ermosh I downloaded libp2.a from Zemon's CI server using your link and it compiled.
    But, my nearly empty program produced a 521 kB elf file.
    So, maybe it's still in that one?

    Also, it seems I need to compile loadp2.exe as well.
    Is this the same loadp2 that I think has been around?

    I'm running tests on this right now. A simple program without p2db linked appears to be 512kb but loads super fast, so I don't think it's actually loading those sections.

    @iseries said:
    In the build for libc I see that the math functions are commented out. I need the atan2f function which are in there. Can I just add that back or is there a reason those are not included?

    Mike

    I commented them out because I never tried building them, feel free to uncomment and try building. FYI I've moved the libc build to cmake so be consistent with everything else

  • iseriesiseries Posts: 1,490
    edited 2022-02-19 20:31

    Yes, I saw you were changing that to cmake.

    If you use loadp2 to load the programs it runs at 2,000,000 baud so even the largest program will load fast. Trust me it's loading the whole shebang.

    Mike

  • RaymanRayman Posts: 14,579
    edited 2022-02-19 20:35

    I tried using FlexProp to load the .elf file by renaming to .bin2. It took a very long time to load...

    Now, trying to add something so that I can tell if it's actually working...
    Tried this:

    #include "propeller2.h"
    
    int main()
    {
       for(;;)
       {
         pinnot(56);
         waitms(1000);
       }
       return 0;
    }
    
    

    But, it gives errors on pinnot and waitms... How can I do things like this?

  • @Rayman said:
    I tried using FlexProp to load the .elf file by renaming to .bin2. It took a very long time to load...

    Now, trying to add something so that I can tell if it's actually working...
    Tried this:

    #include "propeller2.h"
    
    int main()
    {
       for(;;)
       {
         pinnot(56);
         waitms(1000);
       }
       return 0;
    }
    
    

    But, it gives errors on pinnot and waitms... How can I do things like this?

    See https://github.com/ne75/p2llvm/blob/master/libp2/include/propeller2.h for the various macros and functions to control hardware. in your case, I'd do:

    #include <propeller.h>
    
    int main()
    {
       for(;;)
       {
         drvnot(56);
         waitx(CLKFREQ);
       }
       return 0;
    }
    
  • @iseries said:
    Yes, I saw you were changing that to cmake.

    If you use loadp2 to load the programs it runs at 2,000,000 baud so even the largest program will load fast. Trust me it's loading the whole shebang.

    Mike

    Okay... I will look into this today, time to solve this once and for all :)

Sign In or Register to comment.