Loading ...
Sorry, an error occurred while loading the content.

relocatable jal

Expand Messages
  • Craig Franklin
    I spend most of my free time working on gputils. I just released my first version of gplink. A GPL COFF linker for PICs. It isn t bug free, but the basics
    Message 1 of 12 , Apr 1, 2003
    • 0 Attachment
      I spend most of my free time working on gputils. I just released my
      first version of gplink. A GPL COFF linker for PICs. It isn't bug
      free, but the basics are working. The plan is to use this linker for
      the SDCC pic port.

      Is there any interest in relocatable outputs from jal?

      It would have several advantages. Files would only have to compiled if
      they change. If a common linker is used, libraries and objects could be
      shared by several High Level Languages. There should be some
      performance/memory improvements because Jal doesn't have to process as
      much data at one time.

      This isn't a simple task. It would require some additions to the
      language. The assembly output would need some changes. Jal would have
      to automatically sqawn the assembler and linker to generate the output
      files.

      If there is interest in doing this and gplink will be used, I will
      gladly donate some time to get this working. Any takers?
    • Mark Gross
      ... I am quite interested in this, but I personaly don t want to start considering it until we get JAL to the state that it can be called beta or stable. At a
      Message 2 of 12 , Apr 1, 2003
      • 0 Attachment
        On Tuesday 01 April 2003 06:31 pm, Craig Franklin wrote:
        > I spend most of my free time working on gputils. I just released my
        > first version of gplink. A GPL COFF linker for PICs. It isn't bug
        > free, but the basics are working. The plan is to use this linker for
        > the SDCC pic port.
        >
        > Is there any interest in relocatable outputs from jal?
        >
        > It would have several advantages. Files would only have to compiled if
        > they change. If a common linker is used, libraries and objects could be
        > shared by several High Level Languages. There should be some
        > performance/memory improvements because Jal doesn't have to process as
        > much data at one time.
        >
        > This isn't a simple task. It would require some additions to the
        > language. The assembly output would need some changes. Jal would have
        > to automatically sqawn the assembler and linker to generate the output
        > files.
        >
        > If there is interest in doing this and gplink will be used, I will
        > gladly donate some time to get this working. Any takers?

        I am quite interested in this, but I personaly don't want to start considering
        it until we get JAL to the state that it can be called beta or stable.

        At a minimum I would like to get most of the compiler quirks out of CVS
        version and its quality up through testing and debugging before adding a
        significant feature such as this.

        Javi has a fix to that a = 10 - a bug I'm testing out now (it looks good on my
        test programs) But JAL still has some funnies in other areas I would like to
        see cleaned up.

        I think it will take a few months before JAL will be in a state that adding
        support for relocatible compiler output that integrates with gnu-utils can be
        considered and developed off of a stable baseline.

        On a related note: making this change makes JAL much more of a POSIX only type
        of product. (It makes it "hard" to use under windows and reduces its
        accesibility to Windows users without Cygwin).

        We just had an un-fun thread over supported build enviornments, where I felt
        like the minority for wanting to support MSDev as well as gnu-linux and
        cywin.

        --mgross
      • Wouter van Ooijen
        ... Have you considered how you would then do the set page bits optimization? IMHO separate compilation down to asm level will prevent a lot of
        Message 3 of 12 , Apr 2, 2003
        • 0 Attachment
          > Is there any interest in relocatable outputs from jal?

          Have you considered how you would then do the 'set page bits'
          optimization?

          IMHO separate compilation down to asm level will prevent a lot of
          optimizations.

          Separate compilation down to 'tree' level would be another matter, but I
          think it would only slow things down.

          Wouter van Ooijen

          -- -------------------------------------------
          Van Ooijen Technische Informatica: www.voti.nl
          consultancy, development, PICmicro products
        • Craig Franklin
          ... That is probably the biggest challenge. There are a few options. I am still forming an opinion. Right now, I think my favorite is to add near and far
          Message 4 of 12 , Apr 2, 2003
          • 0 Attachment
            Wouter van Ooijen wrote:
            >
            > > Is there any interest in relocatable outputs from jal?
            >
            > Have you considered how you would then do the 'set page bits'
            > optimization?
            >

            That is probably the biggest challenge. There are a few options. I am
            still forming an opinion.

            Right now, I think my favorite is to add "near" and "far" storage
            qualifiers to the language. Along with section pragmas. Then insert
            BANKSEL and PAGESEL directives into the assembly on the "fars". This
            will allow the user to control what happens. The Microchip C compiler
            does this.

            > IMHO separate compilation down to asm level will prevent a lot of
            > optimizations.
            >

            The plan has been to perform some optimizations in the linker. After
            symbol resolution, but before relocation. To remove dead code, auto
            inlining, ...

            Scott Dattalo has a optimizer for SDCC. It is not mature yet, but
            something like it was planned to be merged into gputils.

            This could also help the banksel/pagesel problem. If we wanted it to be
            more automatic, extra data could be inserted into the COFF symbol table
            through the assembly file. This data could be used to do an automatic
            'set page bits' optimization in the linker. This would be long term
            goal. It is kind of tricky. That is why I am leaning towards the
            manual user method for now.

            > Separate compilation down to 'tree' level would be another matter, but I
            > think it would only slow things down.
            >

            In the short term, there probably would be a performance hit on the PIC
            executable.

            Honestly, I expect to use jal as a test bed. That is the reason I have
            been on this list. Maybe it would be better to take a copy of the
            source and go work in a corner somewhere. If I come up with something
            useful, I will send it back to you guys. I wanted to know how the list
            felt before doing so. If I do come up with something good, I wouldn't
            want to throw it in the trash can.

            > Wouter van Ooijen
            >
          • Craig Franklin
            I do generate a win32 (without cygwin) version of gputils. It doesn t run on DOS, which will probably be a problem, but it isn t POSIX only.
            Message 5 of 12 , Apr 2, 2003
            • 0 Attachment
              I do generate a win32 (without cygwin) version of gputils. It doesn't
              run on DOS, which will probably be a problem, but it isn't POSIX only.

              Mark Gross wrote:
              >
              > I am quite interested in this, but I personaly don't want to start considering
              > it until we get JAL to the state that it can be called beta or stable.
              >
              > At a minimum I would like to get most of the compiler quirks out of CVS
              > version and its quality up through testing and debugging before adding a
              > significant feature such as this.
              >
              > Javi has a fix to that a = 10 - a bug I'm testing out now (it looks good on my
              > test programs) But JAL still has some funnies in other areas I would like to
              > see cleaned up.
              >
              > I think it will take a few months before JAL will be in a state that adding
              > support for relocatible compiler output that integrates with gnu-utils can be
              > considered and developed off of a stable baseline.
              >
              > On a related note: making this change makes JAL much more of a POSIX only type
              > of product. (It makes it "hard" to use under windows and reduces its
              > accesibility to Windows users without Cygwin).
              >
              > We just had an un-fun thread over supported build enviornments, where I felt
              > like the minority for wanting to support MSDev as well as gnu-linux and
              > cywin.
              >
              > --mgross
              >
              >
              > To unsubscribe from this group, send an email to:
              > Jal_developers-unsubscribe@yahoogroups.com
              >
              >
              >
              > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
            • Javier Martinez
              Hi Craig, As you are still here: ;-) ... I understand relocatable like *.exe files in ms-dos, that is (more or less) prepared to be placed in
              Message 6 of 12 , Apr 7, 2003
              • 0 Attachment
                Hi Craig,


                As you are still here: ;-)

                > > > Is there any interest in relocatable outputs from jal?
                > >
                > > Have you considered how you would then do the 'set page bits'
                > > optimization?
                > >


                I understand 'relocatable' like '*.exe' files in ms-dos, that is (more or
                less) prepared to be placed in any address of the ram (that is executable). For
                small PICs, that is, those who can't execute code from ram, what benefits we
                will get? Can you explain to me (in a few lines) the theory of the linker for
                pics like f628 or f452 (i'm not talking with pics with external memory
                capabilities)?


                Regards, Javi.
              • Javier Martinez
                Hi Craig, As you are still here: ;-) ... I understand relocatable like *.exe files in ms-dos, that is (more or less) prepared to be placed in
                Message 7 of 12 , Apr 7, 2003
                • 0 Attachment
                  Hi Craig,


                  As you are still here: ;-)

                  > > > Is there any interest in relocatable outputs from jal?
                  > >
                  > > Have you considered how you would then do the 'set page bits'
                  > > optimization?
                  > >


                  I understand 'relocatable' like '*.exe' files in ms-dos, that is (more or
                  less) prepared to be placed in any address of the ram (that is executable). For
                  small PICs, that is, those who can't execute code from ram, what benefits we
                  will get? Can you explain to me (in a few lines) the theory of the linker for
                  pics like f628 or f452 (i'm not talking of pics with external memory
                  capabilities)?


                  Regards, Javi.
                • Craig Franklin
                  ... I am still listening. I might sign off later. If you guys ever have trouble reaching me, my email address is on the gputils website. ... The code is
                  Message 8 of 12 , Apr 7, 2003
                  • 0 Attachment
                    Javier Martinez wrote:
                    >
                    > Hi Craig,
                    >
                    > As you are still here: ;-)
                    >

                    I am still listening. I might sign off later. If you guys ever have
                    trouble reaching me, my email address is on the gputils website.

                    > I understand 'relocatable' like '*.exe' files in ms-dos, that is (more or
                    > less) prepared to be placed in any address of the ram (that is executable). For
                    > small PICs, that is, those who can't execute code from ram, what benefits we
                    > will get? Can you explain to me (in a few lines) the theory of the linker for
                    > pics like f628 or f452 (i'm not talking with pics with external memory
                    > capabilities)?
                    >

                    The code is compiled or assembled into relocatable objects. After all
                    the code is compiled, they are input into the linker. Symbols are
                    resolved, addresses are assigned, and the machine code is patched with
                    the new addresses. The output from the linker is an absolute executable
                    object. The object can be simulated and converted into a hex file.

                    The relocation occurs in the linker. It isn't loaded like an executable
                    in an operating system. As you point out, there aren't sufficent
                    resources available to do that.

                    There are many benefits.
                    1. Code can be written without regard to addresses. This makes it
                    easier to write and reuse.

                    2. The objects can be archived to create a library, which also
                    simplifies reuse.

                    3. Recompiling a project can be faster, because you only compile the
                    portions that have changed.

                    4. Files can have local name spaces. The user chooses what symbols are
                    global.

                    For pics, this has its challenges. The bank and page control being the
                    main one.

                    I have been having discussions with the SDCC developers. It looks like
                    we are going to insert BANKSEL and PAGESEL directives everywhere and
                    optimize out the redundant ones. It is more work for me, but this is a
                    good solution for the users.

                    > Regards, Javi.
                  • japus10
                    Hi Craig, ... all ... with ... executable ... This linker and simulator are those of gputils? If yes, this means change at least the latest 2 or 3 stages of
                    Message 9 of 12 , Apr 7, 2003
                    • 0 Attachment
                      Hi Craig,

                      > The code is compiled or assembled into relocatable objects. After
                      all
                      > the code is compiled, they are input into the linker. Symbols are
                      > resolved, addresses are assigned, and the machine code is patched
                      with
                      > the new addresses. The output from the linker is an absolute
                      executable
                      > object. The object can be simulated and converted into a hex file.
                      >

                      This linker and simulator are those of gputils? If yes, this
                      means change at least the latest 2 or 3 stages of JAL compiler. If no
                      this means double work.

                      Can you send me a link of the linker specifications? Only to see
                      what's inside a linker file.


                      > There are many benefits.
                      > 1. Code can be written without regard to addresses. This makes it
                      > easier to write and reuse.
                      >

                      Except interrupts, because we can use interrupts, can we?


                      > For pics, this has its challenges. The bank and page control being
                      the
                      > main one.


                      Do you mean that this is done in the linker?

                      Are there more optimizations in the linker?



                      > I have been having discussions with the SDCC developers. It looks
                      like
                      > we are going to insert BANKSEL and PAGESEL directives everywhere and
                      > optimize out the redundant ones. It is more work for me, but this
                      is a
                      > good solution for the users.
                      >


                      How is the work of SDCC for pics? I know that Scott it's working
                      with it.




                      Regards, Javi.
                    • Craig Franklin
                      ... The linker is gplink, part of gputils. The simulator is gpsim another gnupic project. You don t have to use gpsim. I have been loading gputils COD files
                      Message 10 of 12 , Apr 8, 2003
                      • 0 Attachment
                        japus10 wrote:
                        >
                        > This linker and simulator are those of gputils? If yes, this
                        > means change at least the latest 2 or 3 stages of JAL compiler. If no
                        > this means double work.
                        >

                        The linker is gplink, part of gputils. The simulator is gpsim another
                        gnupic project. You don't have to use gpsim. I have been loading
                        gputils COD files into MPLAB. Aside from a couple of bugs I just fixed,
                        they seem to work.

                        Parts of jal would have to be disabled.

                        The bigger problem is support for DOS. It sounds like it is important
                        for you guys. I have no plans to make a DOS version of gputils. Seems
                        like a show stopper to me.

                        > Can you send me a link of the linker specifications? Only to see
                        > what's inside a linker file.
                        >
                        >

                        So far it operates like mplink, but I have plans to extend its
                        capibilites beyond those of mplink.

                        http://gputils.sourceforge.net/33014g.pdf

                        > > There are many benefits.
                        > > 1. Code can be written without regard to addresses. This makes it
                        > > easier to write and reuse.
                        > >
                        >
                        > Except interrupts, because we can use interrupts, can we?
                        >
                        >

                        The interrupt and reset vectors can't move, thats correct. The code can
                        be moved.

                        > > For pics, this has its challenges. The bank and page control being
                        > the
                        > > main one.
                        >
                        >
                        > Do you mean that this is done in the linker?
                        >

                        Yes. BANKSEL and PAGESEL relocation entries are placed in the object.
                        After the linker determines the address it patches the machine code with
                        the proper bank/page logic.

                        > Are there more optimizations in the linker?
                        >

                        I am still planing the optimizations. I just got the linker into a
                        semi-functional state.

                        > > I have been having discussions with the SDCC developers. It looks
                        > like
                        > > we are going to insert BANKSEL and PAGESEL directives everywhere and
                        > > optimize out the redundant ones. It is more work for me, but this
                        > is a
                        > > good solution for the users.
                        > >
                        >
                        > How is the work of SDCC for pics? I know that Scott it's working
                        > with it.
                        >

                        Scott has been distracted recently ... by a paying job. He hopes to
                        have more time in the near future. All my time has been going into
                        these backend tools. Hopefully, I my stuff will be ready, when he comes
                        back.

                        > Regards, Javi.
                        >
                        >
                        >
                        > To unsubscribe from this group, send an email to:
                        > Jal_developers-unsubscribe@yahoogroups.com
                        >
                        >
                        >
                        > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                      • Javier Martinez
                        Hi Craig, ... Craig, I don t want to give you hope about relocatable jal now ... we have other thing to do now, perhaps in a future (hope soon) when jal will
                        Message 11 of 12 , Apr 8, 2003
                        • 0 Attachment
                          Hi Craig,

                          > Parts of jal would have to be disabled.

                          Craig, I don't want to give you hope about relocatable jal now ... we have
                          other thing to do now, perhaps in a future (hope soon) when jal will be 'bug
                          free' and some types added ...

                          ... but, for me, it's a nice option ... thinking in 18xxx cores.


                          > So far it operates like mplink, but I have plans to extend its
                          > capibilites beyond those of mplink.
                          >
                          > http://gputils.sourceforge.net/33014g.pdf
                          >

                          Thanks, I've now a better idea about this.


                          > Yes. BANKSEL and PAGESEL relocation entries are placed in the object.
                          > After the linker determines the address it patches the machine code with
                          > the proper bank/page logic.
                          > ...
                          > we are going to insert BANKSEL and PAGESEL directives everywhere and
                          > optimize out the redundant ones. It is more work for me, but this
                          > is a good solution for the users.

                          This take off a lot of work to the compiler! And optimize those who are not
                          needed?



                          [PS] Nice for you and for Scott!! Good work!!


                          Regards, Javi.
                        • Craig Franklin
                          ... I gathered as much. That is why I referred to signing off earlier. No hard feelings. I have plenty of other work to keep me busy. Talk to you all later.
                          Message 12 of 12 , Apr 8, 2003
                          • 0 Attachment
                            Javier Martinez wrote:
                            >
                            > Craig, I don't want to give you hope about relocatable jal now ... we have
                            > other thing to do now, perhaps in a future (hope soon) when jal will be 'bug
                            > free' and some types added ...
                            >

                            I gathered as much. That is why I referred to signing off earlier. No
                            hard feelings. I have plenty of other work to keep me busy.

                            Talk to you all later. Good luck.

                            > Regards, Javi.
                          Your message has been successfully submitted and would be delivered to recipients shortly.