Reduce/Optimize boot code memory C++

On Monday, October 26, 2015 at 5:28:01 PM UTC-4, Mat Nieuwenhoven wrote:
> I'm no C++ expert, but what I've seen C gives smaller code. You
> cannot reprogram to that to try?

Sometimes C++ gives smaller code (please no religious wars; I have
examples here). It is unlikely the original bootloader author used
any C++ features that used much memory.

First, understand what is consuming the memory (from the MAP / LOC).
If, and only if, C++ RTL is chewing up much space consider recoding.

> Have you looked at the OpenWatcom compiler? I'm positive people made
> 16 bit embedded code with it. But if it's using real C++ object
> features OW might not generate the smallest code. 

Changing toolchains could easily be a major undertaking; certainly
all assembler and/or hardware-access code would need a revisit.

First, understand what is currently consuming memory...

Hope that helps!
Best Regards, Dave

On Monday, October 26, 2015 at 12:42:40 PM UTC-4, srao wrote:
> On October 23,2015  Dave Nadler wrote:-
> >>The 80186 is a 16-bit processor and thus you have a 16-bit application.
> >>Can you clarify:
> >>3) What are you using for processing the linker output into HEX file?
> >>If it's Paradigm Locate, can you please post the CFG and LOC files?
> 
> 1) Flashchip part number - MX29GL320ET@TSOP48

That is a 4MB part.
The 80186 can only address 1MB, of which some is RAM.
1a) Are you SURE that's the right flash part number?
1b) What is the CPU chip part number?
1c) Does the application use overlays and switch FLASH banks?
1d) Or, does the application only use part of the flash memory chip?

> 2)Yes, trying to reduce the memory to add in a new protocol
> implementation in boot code.

OK. Now that you've clarified you're trying to add stuff to the bootloader...
2a) How much flash is allocated to the bootloader?
2b) from your LOC file, how much space is remaining?
2c) What is the "new protocol" you are trying to add?
2d) Have you compiled the "new protocol" code, examined the map file,
and totaled how much memory that will take?
2e) What is the memory deficit (2d - 2c)?
2f) Have you analyzed your MAP/LOC file to understand WHAT is
consuming the code space and potantial improvements


> 3)Make File build creates the boot image or hex file. 
To do so, it uses a utility to process the DOS EXE
output by the linker to a loadable HEX file.
Do you have a CFG and LOC file for the bootloader?
If so, please post them...


Hope this helps!
Best Regards, Dave

On Tuesday, October 27, 2015 at 9:45:17 AM UTC-4, Dave Nadler wrote:
> The 80186 can only address 1MB, of which some is RAM.

...Excepting some late non-Intel 186 clones that redefine the segment
register to get 24-bit total address space. That is not directly
supported by Borland 4.50 but it can be kludged...

Thankfully, next project I'm back to ARM critters with adequate memory!

See ya, Dave

On 27.10.15 16:17, Dave Nadler wrote:
> On Tuesday, October 27, 2015 at 9:45:17 AM UTC-4, Dave Nadler wrote:
>> The 80186 can only address 1MB, of which some is RAM.
>
> ...Excepting some late non-Intel 186 clones that redefine the segment
> register to get 24-bit total address space. That is not directly
> supported by Borland 4.50 but it can be kludged...
>
> Thankfully, next project I'm back to ARM critters with adequate memory!
>
> See ya, Dave


The OP asked for UART help for 80C188EB, which has definitively a
plain Intel 80186 addressing scheme.

-- 

-TV

>On Monday, October 26, 2015 at 12:42:40 PM UTC-4, srao wrote:
>> On October 23,2015  Dave Nadler wrote:-
>> >>The 80186 is a 16-bit processor and thus you have a 16-bit
application.
>> >>Can you clarify:
>> >>3) What are you using for processing the linker output into HEX
file?
>> >>If it's Paradigm Locate, can you please post the CFG and LOC files?
>> 
>> 1) Flashchip part number - MX29GL320ET@TSOP48
>
>That is a 4MB part.
>The 80186 can only address 1MB, of which some is RAM.
>1a) Are you SURE that's the right flash part number?
>1b) What is the CPU chip part number?
>1c) Does the application use overlays and switch FLASH banks?
>1d) Or, does the application only use part of the flash memory chip?

Yes, I am sure about the flash chip part.The application uses only a part
of flash memory chip - 1MB. No flash bank switch /overlays right now.

>> 2)Yes, trying to reduce the memory to add in a new protocol
>> implementation in boot code.
>OK. Now that you've clarified you're trying to add stuff to the
>bootloader...
>2a) How much flash is allocated to the bootloader?
>2b) from your LOC file, how much space is remaining?
>2c) What is the "new protocol" you are trying to add?
>2d) Have you compiled the "new protocol" code, examined the map file,
>and totaled how much memory that will take?
>2e) What is the memory deficit (2d - 2c)?
>2f) Have you analyzed your MAP/LOC file to understand WHAT is
>consuming the code space and potantial improvements

a)Total space - 3FFF
b)From Loc file spcae remaining - 118 bytes
c)Initial step is a feasibility test to ensure space reduction is
possible, and memory can be shrinked. So, not i have not tried to
build/add the new code.

Thanks a lot for your comments, I think i will able able to head in the
right direction with your help.

---------------------------------------
Posted through http://www.EmbeddedRelated.com

On Tuesday, October 27, 2015 at 2:43:19 PM UTC-4, srao wrote:
> >> On October 23,2015  Dave Nadler wrote:-
> >2c) What is the "new protocol" you are trying to add?
> >2d) Have you compiled the "new protocol" code, examined the map file,
> >and totaled how much memory that will take?
> >2e) What is the memory deficit (2d - 2c)?
> >2f) Have you analyzed your MAP/LOC file to understand WHAT is
> >consuming the code space and potential improvements...
> 
> a)Total space - 3FFF

16kb is pretty tight...

> b)From Loc file spcae remaining - 118 bytes
> c)Initial step is a feasibility test to ensure space reduction is
> possible, and memory can be shrinked. So, not i have not tried to
> build/add the new code.

If you do not know how much space you need for the new code,
you have no clue how much you have to prune, or if it is
even feasible. START by building the new protocol code and
finding out how much space you will need...

Hope that helps!
Best Regards, Dave

>On Tuesday, October 27, 2015 at 2:43:19 PM UTC-4, srao wrote:
>> >> On October 23,2015  Dave Nadler wrote:-
>> >2c) What is the "new protocol" you are trying to add?
>> >2d) Have you compiled the "new protocol" code, examined the map file,
>> >and totaled how much memory that will take?
>> >2e) What is the memory deficit (2d - 2c)?
>> >2f) Have you analyzed your MAP/LOC file to understand WHAT is
>> >consuming the code space and potential improvements...
>> a)Total space - 3FFF
>16kb is pretty tight...
>> b)From Loc file spcae remaining - 118 bytes
>> c)Initial step is a feasibility test to ensure space reduction is
>> possible, and memory can be shrinked. So, not i have not tried to
>> build/add the new code.
>If you do not know how much space you need for the new code,
>you have no clue how much you have to prune, or if it is
>even feasible. START by building the new protocol code and
>finding out how much space you will need...
>
>Hope that helps!
>Best Regards, Dave


Sure will try that, but before that i have one more question related to
this topic. As this i am dealing with legacy code, the boot code was built
with multiple targets in mind. And this enhancement is only for one of the
targets. So there might be many unused functions. Is there a tool to
identify the unused functions so that i can exclude them from the build?
So far I have been using source tree to find the link between various
files/functions.
---------------------------------------
Posted through http://www.EmbeddedRelated.com

>Sure will try that, but before that i have one more question related to
>this topic. As this i am dealing with legacy code, the boot code was
built
>with multiple targets in mind. And this enhancement is only for one of
the
>targets. So there might be many unused functions. Is there a tool to
>identify the unused functions so that i can exclude them from the build?
>So far I have been using source tree to find the link between various
>files/functions.
>---------------------------------------
Sorry not source tree, 'source insight' tool.


---------------------------------------
Posted through http://www.EmbeddedRelated.com

"srao"  wrote:

>... Is there a tool to
>identify the unused functions so that i can exclude them from the build?

Gimpel's PC-Lint.

R.W.

On Wednesday, October 28, 2015 at 2:00:05 PM UTC-4, srao wrote:
>... Is there a tool to
>identify the unused functions so that i can exclude them from the build?
>So far I have been using source tree to find the link between various
>files/functions.

You can try Borland objxref. WARNING: Don't take OBJXREF output too
seriously. A label listed as 'unreferenced' means it is not referenced
outside the module that defines it. It is not NECESSARILY unused,
but probably it should not be global. objxref has lots of other
'features' with C++ code as well.

Hope that helps,
Best Regards, Dave