Re: [Bug-gnupress] gcc.006.txt unanswered questions

[Simon Law]

On Sun, May 04, 2003 at 08:58:35PM -0700, Paul A. Crable wrote:
> I had several questions imbeded in my changes for section 3.17.1 but 
> did not receive answers:

        Oh, I was unsure that I was supposed to answer these, or whether
you were editorialising.  I shall now explain.

> " -m68881
>             Generate code for a ?????. The code will invoke 68881
> instruction for floating point processing.  Unless the '--nfp' option
> was specified when the compiler was configured, this option is on by
> default and may be omitted."
> 
> ??? The last two sentences don't make sense to me

        The 68881 is a floating point processor, used for non-integer
numbers.  The original 68000, 68020 and 68040 could only deal with
integer numbers natively, so floating point processing was very slow.
If '--nfp' is passed to GCC, then it will abstain from using these extra
instructions.

>  " -m68040
>             Generate code for a 68040. If the compiler has been 
> configured for 68040based microcontrollers, this option is set by 
> default and may be omitted.  If the compiler has been configured for 
> other systems, then this option will force GCC to generate code for 
> the 68040.  This option inhibits the production of 68881/68882 
> instructions that have to be emulated by software on the 68040. Use 
> this option if your 68040 does not have code to emulate those 
> instructions."
> 
> ??? The last two sentences don't make sense to me. I don't see how 
> instructions can be emulated in software on a hardware device. In my 
> experience, software is used to emulate features that are expected to
> be provided by the hardware but are not in place; e.g., floating 
> point processing on an Intel 8086 with the 8087 is missing.

        Yes, that's exactly right.  The 8087 provided additional
instructions beyond the capability of the 8086.  Software written to
take advantage of the 8087 would typically probe to see if the 8087 was
available.  If so, it would off-load floating point calculations to the
8087.  If not, it would do them manually using the integer instructions
on the 8087.

        It is analogous with the 68040 and the 68881.

> "-m68020-40
>             Generate code for a 68040 but do not use the new 
> instructions..."
> 
> ??? Is it going to be clear to the reader what the "new instructions"
> are?

        I don't know.  I presume that a reader working with a 68040
machine will know that it has several additional instructions compared
to a 68020 machine.  But this is ancient history.

> " -msoft-float
>             Generate code containing calls to software for floating 
> point processing.  Be advised that supporting libraries are not 
> available for all m68k targets. Normally the facilities of the 
> machine's usual C compiler are used, but this can't be done directly 
> in crosscompilation. You must make your own arrangements to provide 
> suitable library functions for cross compilation. The embedded 
> targets `m68k-*-aout' and `m68k-*-coff' do provide software floating 
> point support."
> 
> ??? The last three sentences don't make sense to me. If they are 
> clear to everyone else, then that's OK.

        During native compilation, the C compiler is running natively; so
it would have been configured to drop floating point instructions when
they are not supported.  In cross compilation, the C compiler does not
know which libraries are available on the target system, so they may
need to be supplied by the user.  'm68k-*-aout' and 'm68k-*-coff'
specify a group of binary output formats used by GCC.

> "-mpcrel
>      Use the pcrelative addressing mode of the 68000 directly,
> instead of using a global offset table. If -mpcrel is set, then -fpic
> is set by default, allowing at most a 16bit offset for pcrelative
> addressing. `-fPIC' is not presently supported with `-mpcrel', though
> this could be supported for 68020 and higher processors.
> 
> ??? It seems the last sentence contradicts the one before it.

        These options are case sensitive.  '-fpic' and '-fPIC' mean two
different things.

>     -mno-strict-align
>     -mstrict-align
>             Assume (?????) or do not assume (?????) that unaligned 
> memory references will be handled by the system.
> 
> ??? Which selection is used for which function?

        '-mno-strict-align' will assume that unaligned memory references
will be handled by the system.  I believe I elaborated more when I
created the patch.

Simon