Cosmic Compiler - Moveable Code Function

We're using Cosmic Compiler for Motorola HC08. In reading the linker portion of the Cosmic manual, it appears there is a function _fctcpy(), which will automatically move a segment of code from ROM to RAM - for use with bootloader routines. The manual claims this function is packaged in the integer library, but I can't find it anywhere. Anyone have any experience with this "Moveable Code" feature?

Thanks for any info.

Michael

Reply to
Michael
Loading thread data ...

It's been a while since I've used it, but I just checked my installation directory (V4.3e) . The source is in ../COSMIC/CX08/src08/LIBI/fctcpy.s. I've never actually used that one, though...

Regards,

-=Dave

--
Change is inevitable, progress is not.
Reply to
Dave Hansen

:Dave Hansen wrote: :> On 8 Aug 2003 14:43:23 -0700, snipped-for-privacy@yahoo.com (Michael) wrote: :> :>>We're using Cosmic Compiler for Motorola HC08. In reading the linker :>>portion of the Cosmic manual, it appears there is a function :>>_fctcpy(), which will automatically move a segment of code from ROM to :>>RAM - for use with bootloader routines. The manual claims this :>>function is packaged in the integer library, but I can't find it :>>anywhere. Anyone have any experience with this "Moveable Code" :>>feature? :>>

:> :> It's been a while since I've used it, but I just checked my :> installation directory (V4.3e) . The source is in :> ../COSMIC/CX08/src08/LIBI/fctcpy.s. I've never actually used that :> one, though... : :Likewise, we were doing some flash erase code in Cosmic C on :the '08 many years ago and ended up handrolling our own copy routine - :I can't remember why we didn't use fctcpy - must've been a good reason! : :pete

Reply to
David R Brooks

we used the _fctcpy for HC08 flash programming code and another _fctcpy for ST7 code recently and both are working fine. I first also thought about writing a own and more simple function to move the code, but after a day reading in the compiler library sources I finally came to the point where I recognized that _fctcpy_ is the "deluxe-universal" version of what I like to write myself. It covers all current and future needs and the code size is very small. You an hardly write this yourself becouse you dont get the linker generated source addresses from the descriptor ___idesc__.

There is one thing to consider: If one memory area (typical ram page 0 from 0x50 up) is shared by more than one piece of code, only one segment should be compiled with debug info switched on. E.g. if you have diffrent code section "a", "b" or "c" what can be moved to ram by _fctcpy and a breakpoint appears, debuggers cannot know which of the sections has been moved to that place before in realtime. With banking mechanism, the debuggers can read back the actual bank number from MMU but this is not possible for movable code. This means, to debug movable code you must not enable debug info at more than one section.

_fctcpy() is with leading underscore in C language and the assembly label in source has been defined with two underscores __fctpy: The function uses the same __idesc__ structure than crtsi (C runtime startup) is using for initialized data. __idesc__ is a linker generated chained data structure with a "end of file" flag character. The generation of that linker information is triggered if __idesc__ remains unresolved at linking time becouse it is used by the crtsi or fctcpy library code or even if you write a own piece of code what tries to access the __idesc__ data.

If one memory area is shared by morethan one code piece, you have to create diffrent namespaces in the lkf linker file using the +seg -s spacename option to avoid clashes while linking. Further you need to identify the segment by using the -n segmentname option. Therefore I always use 1code, 2code, 3code ... while the first character is the argument for _fctcpy().

The diffrence between movable code by fctcpy and initialized data by crtsi is the flag byte in __idesc__. Both, fctcpy and crtsi scans the __idesc__ structure in same manner and the code is very similar. crtsi copies all data sections with flag bytes below visible ascii and fctcpy copies only one section what is given by the argument when invoked by application programs.

The linker generated __idesc__ structure is a rarely seen accumulation of cleverness. The first entry of the chained structure is the start address of source from indicated section and the first element is 7 bytes of length. The last 2 bytes of the element are the last address+1 of the source address. Becouse the linker chains all "from" segments into one area, this address is equal to the start adddress of the next section. While the linker places the automatically generated "from" section of source in consecutive areas, the destination address of each movable section can be diffrent. With other words, all following entries of the descriptor chain have only 5 bytes but they can be interpreted with 7 bytes whith overlapping first word with the previous chain element.

The interpreting library code of crtsi and fctcpy is a bit tricky to understand becouse it is completely reentrent. I already took the time to rewrite the _fctcpy() library function using fix ram allocations instead the HC08 stack instructions. After comparing the gain in code size and execution cycles I went back to the given library function. From that day, the library source of _fctcpy() is my prototype model on how to learn effizient stack usage of small microcontrollers.

Reply to
Janvi

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.