🚀 go-pugleaf

In article <1gt7r0INNhrd@usenet.INS.CWRU.Edu> an375@cleveland.Freenet.Edu (Jason Baker) writes:
>
>>If the program was compiled so that it doesn't have any absolute
>>references to data (e.g. it uses an address register as a base pointer)
>>then this is possible. However, most programs cannot be so shared,
>>because they do contain absolute references (and thus every copy of
>>the program would share the same data and variables).
>>
>>(gcc can compile shared text programs if it is given the -mbaserel
>>parameter)

>	I was wondering what that meant.  The new mintlib readme metions 
>-mpcrel (or something).  What does this mean; under what conditions will
>gcc generate non-pc-relative code?

-mbaserel means "use a base register for all data", or in other words
"more than one copy of this program may be using the same image
in memory, so don't assume that data always follows the program in
memory". This option is essential for allowing shared text programs;
without it programs use absolute addresses and so each copy of
the program must be loaded and relocated in its entirety
every time.

-mpcrel means "use PC-relative addressing for constant data. e.g.
strings". This results in a small savings in time and space, and
means that constant data can be put into the text segment and
thus shared between multiple invocations of the program (assuming
that -mbaserel was also used).

>  Does the new gcc support both shared 
>and private data in the same program?

Only if the shared data is constant (or at least declared constant).

>	I would also like to bother you about tcsh.  I have version 6.00.02,
>and it doesn't complete dir names.

I don't understand; directory names are completed for me (except at
the beginning of the line).

>  Is 6.02.00 available?

I haven't seen it. If the Unix source is available, porting it to
the ST wouldn't be hard. (Note that I'm not offering to do the
port, I don't have time.)

>  Also, would it 
>be fairly simple to support threading and other options through shell_p?

No.

>And finally, how come tcsh needs such a huge stack?

Because all memory is allocated from the stack; tcsh has a very
silly memory management algorithm that assumes Unix like semantics
for sbrk(), i.e. that all the chunks of memory you allocate are
contiguous.
--
Eric Smith	ersmith@netcom.com	ersmith@atari.uucp
Not an official Atari spokesperson.