"Jason Burgon" <gvision.nos...@ntlworld.com> schreef in bericht
news:BhLT9.38$Ge1.13389@newsfep2-gui...

Better use something like
type
  { Real type [re]defininition }
{$ifopt N+}
{$E+}
    Real = Double;
{$else}
   double=real;
    single=real;
{$endif N+}

Problem with this is that E is switched on only in the unit that
contains this piece of code, while the type definition is valid
throughout the program. Easiest solution is to leave the E+ on in the
compiler anyway. It does not harm the program when compiled in the N-
state.

What I wanted to point out is that the emulated handling of 8 byte
doubles is faster than the normal 6 byte real type.
I tested this long time ago at the time when the E option was
introduced. I had some serious number crunching to do. The presence of a
80X87 processor made the difference between minutes or hours. But when
the program was demo'ed at a client, in most cases his computer would
not have a coprocessor. So the program needed to be runnable on any
machine without recompiling.

What most people here probably don't know is that the standard 6 byte
real is never handled by the coprocessor, which became standard with the
80486 and later.

"The {$E} (80x87 emulation) switch has no effect if used in a unit; it
 applies only to the compilation of a program."

So the above use of {$E+} has no effect at all.

Ok, but what about programs that ~must~ be run on a system with a co-pro
(for performance or other reasons)? IOW, where the programmer insists on
{$N+,E-}? I suppose an application like that could add a test for a real
(excuse the pun) co-pro during its initialialisation, but it will still drag
in the emulation code.

type
  { Real type [re]defininition }
{$ifopt N+}
    Real = Double;
{$else}
   double = real;
    single = real;
{$endif N+}

where both $N and $E are set by the main program or compiler settings?

Femme, you've restored my faith in c.l.p.b. It was starting to get very
boring around here.
--
Jay

"Jason Burgon" <gvision.nos...@ntlworld.com> schreef in bericht
news:2s%T9.953$Dy3.75815@newsfep1-gui.server.ntli.net...

{$ifopt N+}
     {$E+}
{$endif N+}
That covers a possible use of the commandline compiler.

BTW, if you want to have a single real or double regardless of the type
redefinition here, you can always use

system.single
system.real
system.double

BTW. Does anybody know of a way to test for the presence of a coproc?

asm
        fninit
        movl $0x5a5a, %eax
        fnstsw %ax
        cmpw $0, %ax
        seteb %al
end ['EAX'];

The protected mode machinecode is:

AT&T or Motorola style, as used a lot on Unix. (as most other processors do)
The normal way of writing is called "Intel" style. It is mere notational.

Both compilers named above support both conventions (they have to support AT&T because
the back-end assembler uses it). FPC has strong Intel support for historical reasons, but
I prefer AT&T, it is cleaner, more systematic, and has doublechecks (see above, e.g. the
cmp. The suffix w must match the width of ax).

I believe they can even get converted manually. I don't have a good tool for
that. but one can fool the FPC compiler to do so. (put asm code with
convention "A" in a pascal source, and generate code for the opposite convention.
(in this case select tasm as output assembler):

                fninit
                mov     eax,23130
                fnstsw  ax
                cmp     ax,0
                sete    al

The conversion isn't ideal, since hex immediates are now decimal, but I think you can see through
that ;_)