Cross gcc Mailing List Archive

Re: Newlib's crt0.S

Date: Thu, 23 Jan 1997 12:39:29 -0600 (CST)
From:
"Joel Sherrill <joel@merlin.gcs.redstone.army.mil>" <joel@merlin.gcs.redstone.army.mil>
Reply-To:
"Joel Sherrill <joel@merlin.gcs.redstone.army.mil>" <joel@merlin.gcs.redstone.army.mil>
cc: David Wood <david@thermoteknix.co.uk>, "'Ng BengKiat'" <nbk@np.ac.sg>, "'crossgcc@cygnus.com'" <crossgcc@cygnus.com>
Content-Type: TEXT/PLAIN; charset=US-ASCII
In-Reply-To: <32E76536.41C67EA6@spam.frisbee.net.au>

On Thu, 23 Jan 1997, michael smith wrote:

> > assumption for initialised variables is that the compiler will generate code
> > that will initialise them before the main body of code is entered.
> 
> Again, this depends on your environment.  If your code is running
> in RAM, then initialised globals will normally be in the data 
> segment, and are thus implicitly initialised when the image is
> loaded.
> 
> If you're running from ROM, the startup code may have to copy 
> values from ROM to RAM.  (It's generally a pain in the rear to
> relocate the data segment like this.)

Locally we use a scheme in whic the entire program image is burned into 
ROM but we use a small program (< 64 bytes) to copy everything to RAM 
before jumping to it.  I used this scheme in an earlier life and we 
actually compressed our ROM images and used the boot loader to decompress 
them into RAM.  The trick is lying to the PROM programmer such that it 
all works out. :)

I would think a similar trick would work in which you link an initialized 
data only image and place it at a special place in PROM.  Have your crt 
copy it to the prpoer RAM address before passing control to C.

--joel
Joel Sherrill                    Sr. Computer Scientist
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (205) 722-9985

References:

Re: Newlib's crt0.S

From: michael smith <miff@spam.frisbee.net.au>

Home | Subject Index | Thread Index