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

Extra Features in GNU

Expand Messages
  • peter_lingier
    Hello all, During the use of the GNU I encountered some problems which are for me restrictions of the GNU. I believe if someone could adapt the GNU source it
    Message 1 of 11 , Apr 1 1:40 AM
    • 0 Attachment
      Hello all,

      During the use of the GNU I encountered some problems which are for
      me restrictions of the GNU. I believe if someone could adapt the
      GNU source it would make some good features.

      1) Rodata in banked memory

      In my linkerscript I want to keep for every o - file I put in a
      bank, the .text and the .rodata together. In my script it would be
      like this:

      .bank1 :
      {
      *(.text.bank1*)
      LINK/OBJ/string*.o(.text .rodata)
      } > bank1

      The problem is that the rodata in the bank is referenced with the
      near adress (adress 8000 - BFFF) and not with the far adress (in
      which the banknumber is included). With a bankswitch or for example
      a copy to stack with memcpy (out of the libgcc), the near adress is
      used and the supposed rodata is taken out of the wrong bank.
      To avoid this problem I could put all my rodata in page 3E (adress
      4000 - 7FFF) or in page 3F (adress C000 - FFFF). But it isn't a
      good solution.
      I have page 3E already totally filled up with functions of the
      libgcc. In page 3F, I have already the data_image and the
      interupthandlers, so with the rodata I'm afraid to run out of memory
      there.

      Out of curiosity I checked what the effect is on functionpointers in
      combination with bankswitching. With the use of the compileroption -
      m_long_calls a trampolinefunction is generated which handles the
      bankswitch to the function referenced to by the functionpointer.
      So, with functionpointers it is OK.

      2) Data Image

      What's disturbing me is that my page 3F is half filled up with this
      data_image.

      All global declared variables, initialised or not initialised,
      are .data .
      Ex:
      - initialised: short x = 10;
      - not initialised: short x;

      In the beginning of my code, all data is copied from ROM to RAM. I
      find this logical if the variables are initialised. But, why must
      this be done with not initialised data? This data is initialised
      afterwards with init_functions.

      If there would be no _data_image and all data is not initialised,
      would this work?
      If so, could a split up be possible between the initialised (.data)
      and not initialised data (.idata ???)? This to free page 3F from
      the data_image.

      Or are there other possibilities?

      I would appreciate your comments very much and if someone has
      knowledge about the 2 subjects, I hope to share it with them.

      Thanks,

      Peter
    • NZG
      ... I agree it s not a good solution, but that s what I ve had to do as well, put all my rodata at 3E. I have yet to see a way around this, let me know if you
      Message 2 of 11 , Apr 1 7:25 AM
      • 0 Attachment
        >1) Rodata in banked memory
        >To avoid this problem I could put all my rodata in page 3E (adress
        >4000 - 7FFF) or in page 3F (adress C000 - FFFF). But it isn't a
        >good solution.

        I agree it's not a good solution, but that's what I've had to do as well,
        put all my rodata at 3E. I have yet to see a way around this, let me know if
        you find one!

        thx,
        NZG.
      • Jefferson Smith
        Looks like a big limitation of the DP256 (and family) is the lack of a paged data system. It is only meant for paging through code. Some older motorola chips I
        Message 3 of 11 , Apr 1 8:32 AM
        • 0 Attachment
          Looks like a big limitation of the DP256 (and family) is the lack of a
          paged data system. It is only meant for paging through code. Some
          older motorola chips I heard have a different window for paged data
          access (something like a DPAGE register)

          On Thu April 1 2004 08:25, NZG wrote:
          > >1) Rodata in banked memory
          > >To avoid this problem I could put all my rodata in page 3E (adress
          > >4000 - 7FFF) or in page 3F (adress C000 - FFFF). But it isn't a
          > >good solution.
          >
          > I agree it's not a good solution, but that's what I've had to do as
          well,
          > put all my rodata at 3E. I have yet to see a way around this, let me
          know if
          > you find one!
          >
          > thx,
          > NZG.
          >
          >
          >
        • Marc Vincent
          ... I am not sure I understand what you mean.. Without changing the mapping of the internal flash, you can still access 48*16KB of paged data (ie. devices on
          Message 4 of 11 , Apr 2 9:23 AM
          • 0 Attachment
            Jefferson Smith wrote:
            > Looks like a big limitation of the DP256 (and family) is the lack of
            > a paged data system. It is only meant for paging through code. Some
            > older motorola chips I heard have a different window for paged data
            > access (something like a DPAGE register)

            I am not sure I understand what you mean.. Without changing the mapping
            of the internal
            flash, you can still access 48*16KB of paged data (ie. devices on the
            external bus), by
            setting register PPAGE between 0 and $2F. However, you must obviously
            not be running
            from paged flash when changing PPAGE; you must force your paged data
            access functions
            to locate into unpaged flash. There are several registers to set in
            order to run the external
            bus properly; Moto has a couple of app notes that help explain it.

            Marc
          • NZG
            I think Jeffs is mostly talking about romemory, typically constant strings that are stored in flash at a different bank than you are currently in. Accessing
            Message 5 of 11 , Apr 2 9:42 AM
            • 0 Attachment
              I think Jeffs is mostly talking about romemory, typically constant strings
              that are stored in flash at a different bank than you are currently in.
              Accessing them can be a pain as you have to change PPAGE to get to them and
              many(I'd go so far as to say most) DP256/128 boards do run their programs
              out of flash sense RAM space is so limited.
              IMHO the hardware weirdness is the huge disparity between RAM and flash
              size, having only 8/12k of RAM but 128/256k of flash makes for some weird
              programs.

              NZG.

              -----Original Message-----
              From: Marc Vincent [mailto:mv@...]
              Sent: Friday, April 02, 2004 11:23 AM
              To: gnu-m68hc11@yahoogroups.com
              Subject: Re: Extra Features in GNU


              Jefferson Smith wrote:
              > Looks like a big limitation of the DP256 (and family) is the lack of
              > a paged data system. It is only meant for paging through code. Some
              > older motorola chips I heard have a different window for paged data
              > access (something like a DPAGE register)

              I am not sure I understand what you mean.. Without changing the mapping
              of the internal
              flash, you can still access 48*16KB of paged data (ie. devices on the
              external bus), by
              setting register PPAGE between 0 and $2F. However, you must obviously
              not be running
              from paged flash when changing PPAGE; you must force your paged data
              access functions
              to locate into unpaged flash. There are several registers to set in
              order to run the external
              bus properly; Moto has a couple of app notes that help explain it.

              Marc




              To Post a message, send it to: gnu-m68hc11@...

              To Unsubscribe, send a blank message to: gnu-m68hc11-unsubscribe@...
              Yahoo! Groups Links
            • Jefferson Smith
              I especially mean that PPAGE stands for Program Page (the executable code), and it is missing DPAGE, which stands for Data Page . Many are experiencing
              Message 6 of 11 , Apr 2 1:56 PM
              • 0 Attachment
                I especially mean that PPAGE stands for "Program Page" (the executable
                code), and it is missing DPAGE, which stands for "Data Page". Many are
                experiencing dificulty because they do not have both. Exactly... you
                can't access data from a different page when you were executing your
                large program in paged mem. Whether it is internal flash or external
                mem: irrelevant.

                Also, like NZG mentioned, it's a problem because when you make a
                program so large that it requires using PPAGE, then you increase the
                need for data storage. Not near enough ram for many applications. So
                many things you must put in common (unbanked) rom. Don't forget
                interrupt entry points, which could be optimized to go right into a
                paged address.

                On Fri April 2 2004 10:23, Marc Vincent wrote:
                > Jefferson Smith wrote:
                > > Looks like a big limitation of the DP256 (and family) is the lack of
                > > a paged data system. It is only meant for paging through code. Some
                > > older motorola chips I heard have a different window for paged data
                > > access (something like a DPAGE register)
                >
                > I am not sure I understand what you mean.. Without changing the mapping
                > of the internal
                > flash, you can still access 48*16KB of paged data (ie. devices on the
                > external bus), by
                > setting register PPAGE between 0 and $2F. However, you must obviously
                > not be running
                > from paged flash when changing PPAGE; you must force your paged data
                > access functions
                > to locate into unpaged flash. There are several registers to set in
                > order to run the external
                > bus properly; Moto has a couple of app notes that help explain it.
                >
                > Marc
              • Marc Vincent
                OK, now I understand Jeffs point. The natural location for constant (flash) data is within one of the unpaged window ($4000-$7FFF and $C000-$FFFF). If your
                Message 7 of 11 , Apr 3 6:31 AM
                • 0 Attachment
                  OK, now I understand Jeffs' point. The "natural" location for
                  constant (flash) data is within one of the unpaged window
                  ($4000-$7FFF and $C000-$FFFF). If your needs exceed 32KB (minus
                  vectors and startup code), then you have to locate this data
                  into paged flash, and my comment about requiring access
                  functions located in unpaged flash still applies. I guess
                  Motorola decided that not enough people needed so much constant
                  data to justify implementing a DPAGE register. IMHO, they are
                  right in that most programs that grow to fill 256KB still don't
                  have more than 16KB of constant data. I also agree there are
                  many cases where this is not true; for example programs with a
                  complex user interface contain lots of string data. A DPAGE
                  register would have been useful for data accessed on the
                  external bus as well. :-(

                  Marc

                  NZG wrote:

                  > I think Jeffs is mostly talking about romemory, typically constant
                  strings
                  > that are stored in flash at a different bank than you are currently in.
                  > Accessing them can be a pain as you have to change PPAGE to get to
                  them and
                  > many(I'd go so far as to say most) DP256/128 boards do run their programs
                  > out of flash sense RAM space is so limited.
                  > IMHO the hardware weirdness is the huge disparity between RAM and flash
                  > size, having only 8/12k of RAM but 128/256k of flash makes for some weird
                  > programs.
                  >
                  > NZG.
                  >
                  > -----Original Message-----
                  > From: Marc Vincent [mailto:mv@...]
                  > Sent: Friday, April 02, 2004 11:23 AM
                  > To: gnu-m68hc11@yahoogroups.com
                  > Subject: Re: Extra Features in GNU
                  >
                  >
                  > Jefferson Smith wrote:
                  > > Looks like a big limitation of the DP256 (and family) is the lack of
                  > > a paged data system. It is only meant for paging through code. Some
                  > > older motorola chips I heard have a different window for paged data
                  > > access (something like a DPAGE register)
                  >
                  > I am not sure I understand what you mean.. Without changing the mapping
                  > of the internal
                  > flash, you can still access 48*16KB of paged data (ie. devices on the
                  > external bus), by
                  > setting register PPAGE between 0 and $2F. However, you must obviously
                  > not be running
                  > from paged flash when changing PPAGE; you must force your paged data
                  > access functions
                  > to locate into unpaged flash. There are several registers to set in
                  > order to run the external
                  > bus properly; Moto has a couple of app notes that help explain it.
                  >
                  > Marc

                  >
                • peter_lingier
                  Hello, I saw already some posting on my problems, but only related to the first subject. I don t have that much rodata, so I can live with putting it all in
                  Message 8 of 11 , Apr 6 12:17 AM
                  • 0 Attachment
                    Hello,

                    I saw already some posting on my problems, but only related to the
                    first subject. I don't have that much rodata, so I can live with
                    putting it all in page 3F.

                    What I'm really interested in, is to get rid of this data_image.
                    So, if someone has advice or can help me, please do.
                    Thanks very much.

                    Peter







                    --- In gnu-m68hc11@yahoogroups.com, "peter_lingier" <plingier@m...>
                    wrote:
                    > Hello all,
                    >
                    > During the use of the GNU I encountered some problems which are
                    for
                    > me restrictions of the GNU. I believe if someone could adapt the
                    > GNU source it would make some good features.
                    >
                    > 1) Rodata in banked memory
                    >
                    > In my linkerscript I want to keep for every o - file I put in a
                    > bank, the .text and the .rodata together. In my script it would
                    be
                    > like this:
                    >
                    > .bank1 :
                    > {
                    > *(.text.bank1*)
                    > LINK/OBJ/string*.o(.text .rodata)
                    > } > bank1
                    >
                    > The problem is that the rodata in the bank is referenced with the
                    > near adress (adress 8000 - BFFF) and not with the far adress (in
                    > which the banknumber is included). With a bankswitch or for
                    example
                    > a copy to stack with memcpy (out of the libgcc), the near adress
                    is
                    > used and the supposed rodata is taken out of the wrong bank.
                    > To avoid this problem I could put all my rodata in page 3E (adress
                    > 4000 - 7FFF) or in page 3F (adress C000 - FFFF). But it isn't a
                    > good solution.
                    > I have page 3E already totally filled up with functions of the
                    > libgcc. In page 3F, I have already the data_image and the
                    > interupthandlers, so with the rodata I'm afraid to run out of
                    memory
                    > there.
                    >
                    > Out of curiosity I checked what the effect is on functionpointers
                    in
                    > combination with bankswitching. With the use of the
                    compileroption -
                    > m_long_calls a trampolinefunction is generated which handles the
                    > bankswitch to the function referenced to by the functionpointer.
                    > So, with functionpointers it is OK.
                    >
                    > 2) Data Image
                    >
                    > What's disturbing me is that my page 3F is half filled up with
                    this
                    > data_image.
                    >
                    > All global declared variables, initialised or not initialised,
                    > are .data .
                    > Ex:
                    > - initialised: short x = 10;
                    > - not initialised: short x;
                    >
                    > In the beginning of my code, all data is copied from ROM to RAM.
                    I
                    > find this logical if the variables are initialised. But, why must
                    > this be done with not initialised data? This data is initialised
                    > afterwards with init_functions.
                    >
                    > If there would be no _data_image and all data is not initialised,
                    > would this work?
                    > If so, could a split up be possible between the initialised
                    (.data)
                    > and not initialised data (.idata ???)? This to free page 3F from
                    > the data_image.
                    >
                    > Or are there other possibilities?
                    >
                    > I would appreciate your comments very much and if someone has
                    > knowledge about the 2 subjects, I hope to share it with them.
                    >
                    > Thanks,
                    >
                    > Peter
                  • Jefferson Smith
                    I thought un-initialized global variables were not placed in .data section, but in .bss, whos RAM is zeroed at startup. The way I ve seen it, only global
                    Message 9 of 11 , Apr 6 11:57 AM
                    • 0 Attachment
                      I thought un-initialized global variables were not placed in .data
                      section, but in .bss, whos RAM is zeroed at startup. The way I've seen
                      it, only global variables who are asigned initial values (other than
                      the default defined by C) are put in the data_image.

                      Regardless, the answer is to write your own startup routines, using
                      the gcc option -nostartfiles (see my recent post).

                      --- In gnu-m68hc11@yahoogroups.com, "peter_lingier" <plingier@m...> wrote:
                      > Hello,
                      >
                      > I saw already some posting on my problems, but only related to the
                      > first subject. I don't have that much rodata, so I can live with
                      > putting it all in page 3F.
                      >
                      > What I'm really interested in, is to get rid of this data_image.
                      > So, if someone has advice or can help me, please do.
                      > Thanks very much.
                      >
                      > Peter
                      >
                      >
                      >
                      ..........

                      > > 2) Data Image
                      > >
                      > > What's disturbing me is that my page 3F is half filled up with
                      > this
                      > > data_image.
                      > >
                      > > All global declared variables, initialised or not initialised,
                      > > are .data .
                      > > Ex:
                      > > - initialised: short x = 10;
                      > > - not initialised: short x;
                      > >
                      > > In the beginning of my code, all data is copied from ROM to RAM.
                      > I
                      > > find this logical if the variables are initialised. But, why must
                      > > this be done with not initialised data? This data is initialised
                      > > afterwards with init_functions.
                      > >
                      > > If there would be no _data_image and all data is not initialised,
                      > > would this work?
                      > > If so, could a split up be possible between the initialised
                      > (.data)
                      > > and not initialised data (.idata ???)? This to free page 3F from
                      > > the data_image.
                      > >
                      > > Or are there other possibilities?
                      > >
                      > > I would appreciate your comments very much and if someone has
                      > > knowledge about the 2 subjects, I hope to share it with them.
                      > >
                      > > Thanks,
                      > >
                      > > Peter
                    • peter_lingier
                      Nope, both are .data . Example: short global_var; short global_initialised_var = 10; Map-file shows: .data 0x00000ad3 0x4 LINK/OBJ/appl00.o
                      Message 10 of 11 , Apr 7 12:07 AM
                      • 0 Attachment
                        Nope, both are .data .
                        Example:
                        short global_var;
                        short global_initialised_var = 10;

                        Map-file shows:
                        .data 0x00000ad3 0x4 LINK/OBJ/appl00.o
                        0x00000ad5 global_var
                        0x00000ad3 global_initialised_var

                        Can you give an example how I would have to declare it to make
                        it .bss .
                        Thanks,

                        Peter

                        --- In gnu-m68hc11@yahoogroups.com, "Jefferson Smith" <imajeff@a...>
                        wrote:
                        > I thought un-initialized global variables were not placed in .data
                        > section, but in .bss, whos RAM is zeroed at startup. The way I've
                        seen
                        > it, only global variables who are asigned initial values (other
                        than
                        > the default defined by C) are put in the data_image.
                        >
                        > Regardless, the answer is to write your own startup routines, using
                        > the gcc option -nostartfiles (see my recent post).
                        >
                        > --- In gnu-m68hc11@yahoogroups.com, "peter_lingier"
                        <plingier@m...> wrote:
                        > > Hello,
                        > >
                        > > I saw already some posting on my problems, but only related to
                        the
                        > > first subject. I don't have that much rodata, so I can live
                        with
                        > > putting it all in page 3F.
                        > >
                        > > What I'm really interested in, is to get rid of this
                        data_image.
                        > > So, if someone has advice or can help me, please do.
                        > > Thanks very much.
                        > >
                        > > Peter
                        > >
                        > >
                        > >
                        > ..........
                        >
                        > > > 2) Data Image
                        > > >
                        > > > What's disturbing me is that my page 3F is half filled up with
                        > > this
                        > > > data_image.
                        > > >
                        > > > All global declared variables, initialised or not initialised,
                        > > > are .data .
                        > > > Ex:
                        > > > - initialised: short x = 10;
                        > > > - not initialised: short x;
                        > > >
                        > > > In the beginning of my code, all data is copied from ROM to
                        RAM.
                        > > I
                        > > > find this logical if the variables are initialised. But, why
                        must
                        > > > this be done with not initialised data? This data is
                        initialised
                        > > > afterwards with init_functions.
                        > > >
                        > > > If there would be no _data_image and all data is not
                        initialised,
                        > > > would this work?
                        > > > If so, could a split up be possible between the initialised
                        > > (.data)
                        > > > and not initialised data (.idata ???)? This to free page 3F
                        from
                        > > > the data_image.
                        > > >
                        > > > Or are there other possibilities?
                        > > >
                        > > > I would appreciate your comments very much and if someone has
                        > > > knowledge about the 2 subjects, I hope to share it with them.
                        > > >
                        > > > Thanks,
                        > > >
                        > > > Peter
                      • Jefferson Smith
                        Here are some extracts from my project which might be relevant to placing globals in either .data or .bss . I don t see anything specific where I tell it
                        Message 11 of 11 , Apr 7 8:49 AM
                        • 0 Attachment
                          Here are some extracts from my project which might be relevant to
                          placing globals in either ".data" or ".bss". I don't see anything
                          specific where I tell it to do that. Can you give me an example of how
                          I would have to code it to place them both in .data ? --jeffs

                          -------------
                          gcc version 3.0.4 m68hc1x-20030430
                          -------------
                          obj1.c:
                          static byte audioMiscSw, audioMiscSw_pend,
                          audioMiscSw_dbnc=AUDIOSW_DBNC;

                          ctl.c:
                          char robotMiscFlgs;

                          Command lines:
                          m6811-elf-gcc -m68hc12 -mshort -Wall -g -Os -fomit-frame-pointer \
                          -msoft-reg-count=1 -I. -I./../../../robotronics/include \
                          -I./../../../include/asm-m68hc12/arch-adapt912 \
                          -I./../../../include -DBOARD_MODE=1 -c -o obj1.o obj1.c
                          m6811-elf-gcc -m68hc12 -mshort -Wl,-m,m68hc12elfb \
                          -L./../../../config/adapt912-evbrom -L./../../../robotronics/lib \
                          -o ctl.elf ctl.o obj1.o -lrobhc12 -lbcc -lm -lc -lbcc

                          Outputs:
                          obj1.o:
                          00000000 l O .data 00000001 audioMiscSw_dbnc
                          00000001 l O .bss 00000001 audioMiscSw
                          00000002 l O .bss 00000001 audioMiscSw_pend

                          buzzctl.o:
                          00000001 O *COM* 00000001 robotMiscFlgs

                          buzzctl.elf:
                          000009e4 g O .bss 00000001 robotMiscFlgs


                          Ldscript "m68hc12elfb.x":
                          SECTIONS
                          {
                          ...

                          /* Start of the data section image in ROM. */
                          __data_image = .;
                          PROVIDE (__data_image = .);
                          /* All read-only sections that normally go in PROM must be above.
                          We construct the DATA image section in PROM at end of all these
                          read-only sections. The data image must be copied at init time.
                          Refer to GNU ld, Section 3.6.8.2 Output Section LMA. */
                          .data : AT (__data_image)
                          {
                          __data_section_start = .;
                          PROVIDE (__data_section_start = .);
                          *(.sdata)
                          *(.data)
                          *(.data.*)
                          *(.data1)
                          *(.gnu.linkonce.d.*)
                          CONSTRUCTORS
                          _edata = .;
                          PROVIDE (edata = .);
                          } > data
                          __data_section_size = SIZEOF(.data);
                          PROVIDE (__data_section_size = SIZEOF(.data));
                          __data_image_end = __data_image + __data_section_size;
                          /* SCz: this does not work yet... This is supposed to force the loading
                          of _map_data.o (from libgcc.a) when the .data section is not empty.
                          By doing so, this should bring the code that copies the .data section
                          from ROM to RAM at init time.
                          ___pre_comp_data_size = SIZEOF(.data);
                          __install_data_sections = ___pre_comp_data_size > 0 ?
                          __map_data_sections : 0;
                          */
                          /* .install :
                          {
                          . = _data_image_end;
                          } > text */
                          /* Relocation for some bss and data sections. */
                          .bss :
                          {
                          __bss_start = .;
                          *(.softregs)
                          *(.sbss)
                          *(.scommon)
                          *(.dynbss)
                          *(.bss)
                          *(.bss.*)
                          *(.gnu.linkonce.b.*)
                          *(COMMON)
                          PROVIDE (_end = .);
                          } > data
                          __bss_size = SIZEOF(.bss);
                          PROVIDE (__bss_size = SIZEOF(.bss));

                          ...
                          }
                        Your message has been successfully submitted and would be delivered to recipients shortly.