On 23.10.15 22:31, George Neuner wrote:> On Fri, 23 Oct 2015 18:10:05 +0000 (UTC), Simon Clubley > <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote: > >> On 2015-10-23, srao <109468@EmbeddedRelated> wrote: >> >>> David Brown wrote: >>>> First, forget the boot code. Aim to reduce the size of the main >>>> application, not the boot loader. There are three reasons for that: >>>> : >>> >>> I don't have privilege to do that, boot code would reside in high address >>> and is allocated a particular amount of region. :( >> >> If you are not allowed to do that, then are there any secondary functions >> which can be placed in the application area (those that don't need to be >> present for the primary bootloader code to work) ? >> >> What kind of functionality do you need to add into the bootloader code ? >> >> Is the bootloader downloading and burning the later versions of the >> application or are you physically burning bootloader + application using >> some external programmer ? > > > I think there may be a misunderstanding here. From the discussion I > have formed the (maybe wrong) impression that the OP considers the > "boot" code to be the entirety of the init/loader and application > because they are linked (or at least bound) together into a single > file. > > In contrast, others here are distinguishing those logical sections and > advocating concentrating on the "program" portion. > > From the original post, srao wrote: >> FOR EXAMPLE : The boot make file below has files a and b >> dependent on it to be built to create an hex image file. These >> files a, b contribute to the code memory and hence overall boot >> memory. >> >> $(ObjDir)a.obj: w:a.cpp >> $(ObjDir)b.obj: w:b.cpp >> main_obj= >> $(ObjDir)a.obj >> $(ObjDir)b.obj >> mainEXE.exe:$(main_obj) >> mainEXE.exe mainEXE.map >> >> Could someone please help me with possible steps to be taken to >> decrease/optimize existing code or how to go about looking at this >> problem? > > Thus my question to srao is: > > Understanding that you didn't show us your actual makefile - what > exactly is in the files you called "a.cpp" and "b.cpp"? Are they: > - hardware initialization? > - code which copies information from Flash to RAM? > - code for the application's actual purpose? > - something else? > > > I think we need to make sure we are all talking about the same things. > > YMMV, > GeorgeThe initialization of an 80186/80188 can hardly be done in Borland C, and IMHO, not at all in C++. The initial start-up modules are very probably assembly code. The processor wakes up with only chip select 0 alive, with a 1 kbyte window into the start-up ROM/Flash/EPROM, and this is a very tight place (but doable for an experienced programmer) in Borland C, but the machinery of Borland C++ is definitively too much. -- -TV
Reduce/Optimize boot code memory C++
Started by ●October 22, 2015
Reply by ●October 23, 20152015-10-23
Reply by ●October 23, 20152015-10-23
On Friday, October 23, 2015 at 3:47:30 PM UTC-4, Tauno Voipio wrote:> On 23.10.15 22:31, George Neuner wrote: > > On Fri, 23 Oct 2015 18:10:05 +0000 (UTC), Simon Clubley > > <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote: > > > >> On 2015-10-23, srao <109468@EmbeddedRelated> wrote: > >> > >>> David Brown wrote: > >>>> First, forget the boot code. Aim to reduce the size of the main > >>>> application, not the boot loader. There are three reasons for that: > >>>> : > >>> > >>> I don't have privilege to do that, boot code would reside in high address > >>> and is allocated a particular amount of region. :( > >> > >> If you are not allowed to do that, then are there any secondary functions > >> which can be placed in the application area (those that don't need to be > >> present for the primary bootloader code to work) ? > >> > >> What kind of functionality do you need to add into the bootloader code ? > >> > >> Is the bootloader downloading and burning the later versions of the > >> application or are you physically burning bootloader + application using > >> some external programmer ? > > > > > > I think there may be a misunderstanding here. From the discussion I > > have formed the (maybe wrong) impression that the OP considers the > > "boot" code to be the entirety of the init/loader and application > > because they are linked (or at least bound) together into a single > > file. > > > > In contrast, others here are distinguishing those logical sections and > > advocating concentrating on the "program" portion. > > > > From the original post, srao wrote: > >> FOR EXAMPLE : The boot make file below has files a and b > >> dependent on it to be built to create an hex image file. These > >> files a, b contribute to the code memory and hence overall boot > >> memory. > >> > >> $(ObjDir)a.obj: w:a.cpp > >> $(ObjDir)b.obj: w:b.cpp > >> main_obj= > >> $(ObjDir)a.obj > >> $(ObjDir)b.obj > >> mainEXE.exe:$(main_obj) > >> mainEXE.exe mainEXE.map > >> > >> Could someone please help me with possible steps to be taken to > >> decrease/optimize existing code or how to go about looking at this > >> problem? > > > > Thus my question to srao is: > > > > Understanding that you didn't show us your actual makefile - what > > exactly is in the files you called "a.cpp" and "b.cpp"? Are they: > > - hardware initialization? > > - code which copies information from Flash to RAM? > > - code for the application's actual purpose? > > - something else? > > > > > > I think we need to make sure we are all talking about the same things. > > > > YMMV, > > George > > > The initialization of an 80186/80188 can hardly be done in Borland C, > and IMHO, not at all in C++. The initial start-up modules are very > probably assembly code. > > The processor wakes up with only chip select 0 alive, with a 1 kbyte > window into the start-up ROM/Flash/EPROM, and this is a very tight > place (but doable for an experienced programmer) in Borland C, but > the machinery of Borland C++ is definitively too much. > > -- > > -TVThe application I'm working on TODAY uses Borland C 5.0 for startup on the AM186 (80186 clone), save a very tiny bit of assembler. That's for both the bootloader and the main application. C++ is just fine BUT one must be careful not to drag in lots of junk. Hope that helps, Best Regards, Dave
Reply by ●October 23, 20152015-10-23
On Friday, October 23, 2015 at 1:54:26 PM UTC-4, srao wrote:> >Can you tell us: > >- 16-bit or 32-bit application? > >- what is the processor chip? > >- which version of the Borland toolchain? > > > >Older versions of the Borland toolchain have "issues" with some > >optimization settings - change these at your peril. > > > >Care must be taken with this toolchain to avoid dragging in > >all kinds of unwanted runtime parts. However, whomever originally > >did the bootloader was most likely somewhat aware of the issues. > >A review of the MAP file will show where the space is used. > > > >There are a number of techniques you can use to minimize > >memory use with this toolchain - suppressing inclusion of > >free storage management, forcing constants into ROM, etc... > > > >I'm still supporting an app with these tools (also 1MB total > >memory, including bootloader, and also using C++)... > > > >Hope this helps! > >Best Regards, Dave > > > Thank you for the reply, please see answers below > > >Can you tell us: > >- 16-bit or 32-bit application? > >- what is the processor chip? > >- which version of the Borland toolchain? > > Its a 32 bit application > Processor is 80188/86 intel however the flash ship on which the bootloader > goes is an external memory chip. > Borland version 4.5 .The 80186 is a 16-bit processor and thus you have a 16-bit application. Can you clarify: 1) what is the flash chip part number? 2) confirm: you are trying to reduce the number of PAGES used by the bootloader, so you can get an additional flash PAGE or two for the application? 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? Thanks, Best Regards, Dave
Reply by ●October 23, 20152015-10-23
On Friday, October 23, 2015 at 3:32:28 AM UTC-4, David Brown wrote:> > Etc. -- it's not an easy thing to do, it's mostly lots of really picky > > work by someone with some expertise. > > > > Absolutely true. I have worked on projects that were so full that I > have had to fight for a few bytes of code space (or /bits/ of data > space!) in order to get changes into the system. It can be difficult work.Yep. I'm using the same toolchain and target as the OP today. Yesterday I saved 722 bytes, and today I'm filling it up. Digging holes and filling them back up does get tedious... Amazing that this product, which I designed 2 decades ago, is still being produced and sold! See ya, Dave
Reply by ●October 23, 20152015-10-23
On Friday, October 23, 2015 at 3:37:51 AM UTC-4, David Brown wrote:> I hope you meant "C++ for embedded programming" here, rather than > "Embedded C++" - the disastrous EC++ semi-standard that was attempted a > fair number of years, and although dead continues to haunt people to > this day.IIRC this toolchain predates that debacle by a decade or so... It's an early C++ with lots of exciting bugs, like calling dtors multiple times and interesting issues with 16-bit x86 segmentation. But, it was the most powerful tool around 20 years ago, and its still possible to get lots of benefit from C++ despite the warts... See ya, Dave
Reply by ●October 23, 20152015-10-23
On 23/10/15 19:54, srao wrote:> >> First, forget the boot code. Aim to reduce the size of the main >> application, not the boot loader. There are three reasons for that: > > I don't have privilege to do that, boot code would reside in high address > and is allocated a particular amount of region. :( >(Please try to get your quotations and attributions correct, and reply to the correct messages. If you are hoping that people here provide free expert advice, the least you can do is follow the standards of Usenet. www.EmbeddedRelated.com provides a rather poor interface into the comp.arch.embedded newsgroup, and I believe it takes quite an effort to use it appropriately. If you intend to use this newsgroup regularly (and it is full of helpful and experienced people, even if you don't always like the helpful advice you are given), consider getting a proper Usenet client and server. Thunderbird is free on all platforms, and eternal-september.org is a free newsserver - it's a combination that works for many of us here.) Back to the case in point - it was not at all clear that it is the boot program you are expanding rather than the main program. But all the advice you have been given regarding reducing the size of the main program, also applies for the boot program. But you need to be even more careful about testing your changes to the code or compilation flags to be sure that you have not caused new problems.
Reply by ●October 26, 20152015-10-26
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: >1) what is the flash chip part number? >>2) confirm: you are trying to reduce the number of PAGES used >>by the bootloader, so you can get an additional flash PAGE or >>two for the application? >>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 2)Yes, trying to reduce the memory to add in a new protocol implementation in boot code. 3)Make File build creates the boot image or hex file. --------------------------------------- Posted through http://www.EmbeddedRelated.com
Reply by ●October 26, 20152015-10-26
On Mon, 26 Oct 2015 11:42:35 -0500, 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: >>1) what is the flash chip part number? >>>2) confirm: you are trying to reduce the number of PAGES used >>>by the bootloader, so you can get an additional flash PAGE or >>>two for the application? >>>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 >2)Yes, trying to reduce the memory to add in a new protocol implementationin boot code. >3)Make File build creates the boot image or hex file.I'm no C++ expert, but what I've seen C gives smaller code. You cannot reprogram to that to try? 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. Mat Nieuwenhoven
Reply by ●October 27, 20152015-10-27
On 26.10.15 18:42, 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: >> 1) what is the flash chip part number? >>> 2) confirm: you are trying to reduce the number of PAGES used >>> by the bootloader, so you can get an additional flash PAGE or >>> two for the application? >>> 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@TSOP48OK> 2)Yes, trying to reduce the memory to add in a new protocol implementation > in boot code.The first step would be to change to plain C and read the generated assembly code. It helps immensely for understanding which high-level constructions are costly in machine code.> 3)Make File build creates the boot image or hex file.It seems that you did not understand the question: The make utility does not do the image - for Borland tools, there must be a locator, e.g. Paradign Locate. The Borland linker produces a segment/group -relocatable image, usually known as DOS exe. It cannot be directly executed on bare hardware. -- -TV
Reply by ●October 27, 20152015-10-27
On Friday, October 23, 2015 at 4:46:56 PM UTC-4, Dave Nadler wrote:> On Friday, October 23, 2015 at 3:47:30 PM UTC-4, Tauno Voipio wrote: > > The initialization of an 80186/80188 can hardly be done in Borland C, > > and IMHO, not at all in C++. The initial start-up modules are very > > probably assembly code. > > > > -- > > > > -TV > > The application I'm working on TODAY uses Borland C 5.0 for startup > on the AM186 (80186 clone), save a very tiny bit of assembler. > That's for both the bootloader and the main application. > C++ is just fine BUT one must be careful not to drag in lots > of junk. > > Hope that helps, > Best Regards, DaveThe flash chips used for this generation are all page-erase, so the minimum size of memory consumed by bootloader is the size of the boot page. In the application I'm working on, that's 32kb, which is more than enough for the C/C++ bootloader plus some diagnostic code using Borland C++ 4.5 vintage tools.
