Re: [fpc-pascal] Inline ASM code

[Karoly Balogh (Charlie/SGR)]

Hi,

On Thu, 24 Aug 2017, LacaK wrote:

> Thank you!
> I have hoped, that there is some kind of direct usage. Because
> "fstp a" is compiled into:
>fstps  -0x24(%ebp) // address of local variable "a" on stack
> and "pa^ := a" into:
>mov-0x4(%ebp),%eax
>mov-0x40(%eax),%edx   // pa
>mov-0x24(%ebp),%eax   // a
>mov%eax,(%edx) // a -> pa^
>
> so I hoped, that there is possibility to do it directly :
>fstps  (-0x24(%ebp))
> but seems that this construct (use address stored on address) is not
> supported by processors instructions at all.

Such double-dereference is actually supported by the CALL instruction
which can jump to an address stored at the address pointed by the
reference operand, IIRC. But that's the exception. The x86 instruction set
is not too orthogonal, it's full of "special" cases like that one.

But really fast CPUs usually don't like such constructs, because it has
too many interdependencies and sub-instructions (like, address calculation
has to be done multiple times), so it's hard decode, pair and to pipeline
them. Yes, the encoding would be smaller, but less instructions doesn't
directly mean faster execution on most modern processors.

Charlie
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] ExtractRelativePath() not always returning expected result

[James Richters]

>You must make sure directories are appended with /

Thank you,  I just tried that and now  I get the expected results:  both / and 
\ work

From "/pp/src/compiler/" to "/pp/bin/win32/ppc386/" via 
"..\..\bin\win32\ppc386\"
From "/pp/bin/win32/ppc386/" to "/pp/src/compiler/" via "..\..\..\src\compiler\"
From "e:/pp/bin/win32/ppc386/" to "d:/pp/src/compiler/" via 
"d:/pp/src/compiler/"
From "e:\pp\bin\win32\ppc386/" to "d:\pp\src\compiler/" via 
"d:\pp\src\compiler/"
From "C:\FPC\3.0.2\" to "C:\FPC\3.0.2\" via ""
From "C:\FPC\3.0.2\" to "C:\FPC\3.0.4rc1\" via "..\3.0.4rc1\"
From "Q:\" to "Q:\FPC\3.0.4rc1\" via "FPC\3.0.4rc1\"

I guess the example program should have the trailing / in the examples to make 
it clear they are needed.  None of the sample test cases have trailing / or \   

I am curious about this though: 
From "/pp/src/compiler/" to "/pp/bin/win32/ppc386/" via 
"..\..\bin\win32\ppc386\"  
Shouldn't the output use / since / was used in both the source and destination  
not \ ?

James

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Freepascal Floating Point Issue

[el es]

On 24/08/17 13:26, Sven Barth via fpc-pascal wrote:
[...]
> 
> Note: FPC (and Delphi) has a single fixed point type which is
> Currency. AFAIK it uses four digits after the comma and 28 in front
> of it.
> 
> Regards, Sven
> 

There was a project I remember, that I was told, for some e.g. tax purposes,
4 digits after the decimal point are not enough to round them properly...
That is because, the calculation of e.g. VAT has to work out both ways 
(total=net+VAT and
has to work out in every way, including when a bigger package is split into 
smaller units)
and 4 decimal digits are not always enough to ensure this (and the program had 
to work
internationally with all the different tax rules too) for arbitrarily large 
quantities, prices and tax bands.

I don't remember the exact details (it long time ago and couple of workplaces 
ago), of what they did,
but the team developing it (in D7) was pretty stressed... 

-l.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] ExtractRelativePath() not always returning expected result

[James Richters]

I’m trying to figure out ExtractRelativePath() and I’ve run the sample program 
found here:

https://www.freepascal.org/docs-html/rtl/sysutils/extractrelativepath.html

 

I get the following results from the sample (with a few test I threw in myself):

>From "/pp/src/compiler" to "/pp/bin/win32/ppc386" via "..\bin\win32\ppc386"
>// Shouldn’t this be “..\..\bin\win32\ppc386” ?

>From "/pp/bin/win32/ppc386" to "/pp/src/compiler" via "..\..\src\compiler" 
>  // Shouldn’t this be "..\..\..\src\compiler" ?

>From "e:/pp/bin/win32/ppc386" to "d:/pp/src/compiler" via "d:/pp/src/compiler" 
>//Expected

>From "e:\pp\bin\win32\ppc386" to "d:\pp\src\compiler" via "d:\pp\src\compiler" 
>//Expected

>From "C:\FPC\3.0.2" to "C:\FPC\3.0.2" via "3.0.2"  
>   // Shouldn’t this be “”  since we are already 
>there?

>From "C:\FPC\3.0.2" to "C:\FPC\3.0.4rc1" via "3.0.4rc1"
>  // Shouldn’t this be "..\3.0.4rc1"?

>From "Q:\" to "Q:\FPC\3.0.4rc1" via "FPC\3.0.4rc1" 
> //Expected

 

Am I missing something here?

 

James

 

 

 

 

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] ExtractRelativePath() not always returning expected result

[Michael Van Canneyt]

On Thu, 24 Aug 2017, James Richters wrote:


I’m trying to figure out ExtractRelativePath() and I’ve run the sample program 
found here:

https://www.freepascal.org/docs-html/rtl/sysutils/extractrelativepath.html



I get the following results from the sample (with a few test I threw in myself):


From "/pp/src/compiler" to "/pp/bin/win32/ppc386" via "..\bin\win32\ppc386"
// Shouldn’t this be “..\..\bin\win32\ppc386” ?


You must make sure directories are appended with /

Michael.___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Freepascal Floating Point Issue

[James Richters]

Thanks everyone for the explanation and solutions.  I can work around it well 
enough now that I understand what’s happening, but I’m still curious if there 
is a way to define fixed point variables?  In a C++ Project I was helping with 
recently, they had a way of defining a variable as having 2 places before the 
decimal and 30 places after?  Since the decimal could never move (float) It 
ended up being much better defined.   It’s like always moving the decimal over 
30 places to the right, using integer math, then moving it back.  I’m not sure 
if this was something the compiler did, or if maybe they had their own 
functions to do this… I had a difficult time following how things worked, but I 
do remember the fixed point variables.  Anyway I thought I would just ask the 
question in case there is a way to define this in FreePascal

 

It seems to me that if you know you never need more than a fixed number of 
places before and after the decimal, then moving the decimal over the maximum 
number of places, performing integer math, which would round to the nearest 
integer(and cut off the useless garbage), then moving the decimal back would 
mean a fixed amount of precision with the benefit that one could do things like 
exact conditionals and get the expected result

 

James

 

From: fpc-pascal [mailto:fpc-pascal-boun...@lists.freepascal.org] On Behalf Of 
Sven Barth via fpc-pascal
Sent: Tuesday, August 22, 2017 1:55 AM
To: FPC-Pascal users discussions 
Cc: Sven Barth 
Subject: Re: [fpc-pascal] Freepascal Floating Point Issue

 

Am 22.08.2017 00:02 schrieb "James Richters"  >:

The others already wrote about floating point precision, so I won't repeat that.

> The reason I noticed this is because I have some conditional statements like
> If Draw_GX_Min<>99.999 then
> Something

*DON'T* compare floating point numbers like that. Instead use SameValue() from 
the Math unit which has an additional epsilon value (with a default value) that 
defines a lower and upper bound from your desired value to compare to.

Regards,
Sven

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] ExtractRelativePath() not always returning expected result

[Michael Van Canneyt]

On Thu, 24 Aug 2017, James Richters wrote:


You must make sure directories are appended with /


Thank you,  I just tried that and now  I get the expected results:  both / and 
\ work

From "/pp/src/compiler/" to "/pp/bin/win32/ppc386/" via 
"..\..\bin\win32\ppc386\"
From "/pp/bin/win32/ppc386/" to "/pp/src/compiler/" via "..\..\..\src\compiler\"
From "e:/pp/bin/win32/ppc386/" to "d:/pp/src/compiler/" via 
"d:/pp/src/compiler/"
From "e:\pp\bin\win32\ppc386/" to "d:\pp\src\compiler/" via 
"d:\pp\src\compiler/"
From "C:\FPC\3.0.2\" to "C:\FPC\3.0.2\" via ""
From "C:\FPC\3.0.2\" to "C:\FPC\3.0.4rc1\" via "..\3.0.4rc1\"
From "Q:\" to "Q:\FPC\3.0.4rc1\" via "FPC\3.0.4rc1\"

I guess the example program should have the trailing / in the examples to make 
it clear they are needed.  None of the sample test cases have trailing / or \


Can you please file a bugreport for that, so I will not forget it ?



I am curious about this though: 
From "/pp/src/compiler/" to "/pp/bin/win32/ppc386/" via "..\..\bin\win32\ppc386\" 
Shouldn't the output use / since / was used in both the source and destination  not \ ?


The default for the OS is used; This is by design.

Michael.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] ExtractRelativePath() not always returning expected result

[James Richters]

>Can you please file a bugreport for that, so I will not forget it ?
Done.

>The default for the OS is used; This is by design.

That makes sense for most cases but is there / could there be a way to override 
this?  I normally write programs for Windows, however I've had to write out the 
Linux Slashes on my windows system before.  An example is writing out a 
playlist files, and if I use the linux / the file would be useable on both 
windows and linux, but if I use the windows \ it only worked on windows.  

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Freepascal Floating Point Issue

[Peter]

FPC has a header for the GMP library.


Regards,
Peter B
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Freepascal Floating Point Issue

[Sven Barth via fpc-pascal]

Am 24.08.2017 23:46 schrieb "Ched" <
charles.edouard.des.vastes.vig...@gmail.com>:
>
> And under "modern" Windows, the extended type, which is fully supported
by the FPU, is *degraded* to double. So, I can't do high precision
computation with fpc even if the native hardware permits such computations.
I'm glued to XP as the full capabilities of the FPU were on the hands of
programmers, years ago.

Please note that this is only true for the 64-bit variants of Windows with
64-bit software. 32-bit software on those systems can use the FPU without
any problems (in fact even 64-bit software can, but since Microsoft
declared it as deprecated for the 64-bit mode it might happen in the future
that it is no longer supported).

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Freepascal Floating Point Issue

[Ralf Quint]

On 8/24/2017 2:18 AM, Sven Barth via fpc-pascal wrote:
>
> Am 23.08.2017 02:16 schrieb "Paul Nance"  >:
> >
> > Turbo Pascal also had a BCD unit.
>
> Free Pascal also has a BCD unit: FmtBCD. It provides a BCD type and
> operators as well operator overloads.
>
And where would such gem be hiding? It's not in neither my Lazarus
1.6/FPC 3.02 nor the Lazarus 1.8RC4/FPC 3.04 installs...

Ralf


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Freepascal Floating Point Issue

[Bernd Oppolzer]

Am 24.08.2017 um 15:02 schrieb el es:

On 24/08/17 13:26, Sven Barth via fpc-pascal wrote:
[...]

Note: FPC (and Delphi) has a single fixed point type which is
Currency. AFAIK it uses four digits after the comma and 28 in front
of it.

Regards, Sven


There was a project I remember, that I was told, for some e.g. tax purposes,
4 digits after the decimal point are not enough to round them properly...
That is because, the calculation of e.g. VAT has to work out both ways 
(total=net+VAT and
has to work out in every way, including when a bigger package is split into 
smaller units)
and 4 decimal digits are not always enough to ensure this (and the program had 
to work
internationally with all the different tax rules too) for arbitrarily large 
quantities, prices and tax bands.

I don't remember the exact details (it long time ago and couple of workplaces 
ago), of what they did,
but the team developing it (in D7) was pretty stressed...


When you do calculations of actual values of
on-board securities, you need 8 digits after the decimal point
and more, because the stock quotation already has 6 digits after
the decimal point, and you have to multiply that with the quantity,
which has decimal parts, too.

With decimal arithmetic, rounded multiplication is pretty simple:
you multiply the two items, giving a result with one decimal digit
more as you need, then you round the result.

In PL/1:

   value = round (multiply (quantity, quotation, 15, 3), 2);

gives the rounded value in Euro, no matter how many digits after
the decimal point quantity and quotation had. The multiply function
will take care of the proper scaling and stop after the third digit
which is sufficient to round at the second position.

Kind regards

Bernd



-l.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Freepascal Floating Point Issue

[Bernd Oppolzer]

Am 24.08.2017 um 14:00 schrieb James Richters:


Thanks everyone for the explanation and solutions.  I can work around 
it well enough now that I understand what’s happening, but I’m still 
curious if there is a way to define fixed point variables?  In a C++ 
Project I was helping with recently, they had a way of defining a 
variable as having 2 places before the decimal and 30 places after? 
Since the decimal could never move (float) It ended up being much 
better defined.   It’s like always moving the decimal over 30 places 
to the right, using integer math, then moving it back.  I’m not sure 
if this was something the compiler did, or if maybe they had their own 
functions to do this… I had a difficult time following how things 
worked, but I do remember the fixed point variables.  Anyway I thought 
I would just ask the question in case there is a way to define this in 
FreePascal


It seems to me that if you know you never need more than a fixed 
number of places before and after the decimal, then moving the decimal 
over the maximum number of places, performing integer math, which 
would round to the nearest integer(and cut off the useless garbage), 
then moving the decimal back would mean a fixed amount of precision 
with the benefit that one could do things like exact conditionals and 
get the expected result


James




IBM mainframes have decimal data types involving 31 decimal digits
(maximum); the numbers of digits left and right of the decimal point
may be chosen freely. The types are all compatible and promoted to
floating point, when necessary. The mainframe languages, like PL/1
and COBOL, support them natively, and mainframe C, too:

   int x, y;
   decimal (15,2) amt;
   ...

These decimal data types are supported by the hardware (by
machine instructions). This was an optional feature in the 1960s,
but the modern machines of today all support it.

The decimal data is implemented as BCD data; hex digits are
decimal digits, and a sign half byte is added, that makes 16 bytes
for 31 digits. If shorter numbers are needed, less bytes are allocated
(all lengths from 1 to 16 are supported). All decimal fields have
odd numbers of digits.

I am thinking about adding support for decimal data in one of the
next versions of my Stanford Pascal compiler, which targets this
platform, as well as Windows, Linux, macOS etc.; of course, this
decimal format will need to be emulated on the non-mainframe
platforms.

For some years now, the mainframe also supports floating point
data based on a decimal representation. But I don't have experience
with this so far. Some compilers support this (PL/1).

Kind regards

Bernd

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Freepascal Floating Point Issue

[Tomas Hajny]

On Thu, August 24, 2017 22:25, Ralf Quint wrote:
> On 8/24/2017 2:18 AM, Sven Barth via fpc-pascal wrote:
>>
>> Am 23.08.2017 02:16 schrieb "Paul Nance" > >:
>> >
>> > Turbo Pascal also had a BCD unit.
>>
>> Free Pascal also has a BCD unit: FmtBCD. It provides a BCD type and
>> operators as well operator overloads.
>>
> And where would such gem be hiding? It's not in neither my Lazarus
> 1.6/FPC 3.02 nor the Lazarus 1.8RC4/FPC 3.04 installs...

Good point... It's in package rtl-objpas. I can see it included in the
standard FPC 3.0.2 installation, but it's missing in 3.0.4 at the moment,
because it got lost in the transition from fpcmake to fpmake apparently.
Fortunately, that should be rather easy to fix. :-)

Tomas


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Freepascal Floating Point Issue

[Ched]

And under "modern" Windows, the extended type, which is fully supported by the FPU, is *degraded* to 
double. So, I can't do high precision computation with fpc even if the native hardware permits such 
computations. I'm glued to XP as the full capabilities of the FPU were on the hands of programmers, years 
ago.


Cheers, Ched'




Le 24.08.2017 à 21:31, Bernd Oppolzer a écrit :

Am 24.08.2017 um 14:00 schrieb James Richters:


Thanks everyone for the explanation and solutions.  I can work around it well enough now that I 
understand what’s happening, but I’m still curious if there is a way to define fixed point variables?  
In a C++ Project I was helping with recently, they had a way of defining a variable as having 2 places 
before the decimal and 30 places after? Since the decimal could never move (float) It ended up being 
much better defined.   It’s like always moving the decimal over 30 places to the right, using integer 
math, then moving it back.  I’m not sure if this was something the compiler did, or if maybe they had 
their own functions to do this… I had a difficult time following how things worked, but I do remember 
the fixed point variables.  Anyway I thought I would just ask the question in case there is a way to 
define this in FreePascal


It seems to me that if you know you never need more than a fixed number of places before and after the 
decimal, then moving the decimal over the maximum number of places, performing integer math, which 
would round to the nearest integer(and cut off the useless garbage), then moving the decimal back would 
mean a fixed amount of precision with the benefit that one could do things like exact conditionals and 
get the expected result


James




IBM mainframes have decimal data types involving 31 decimal digits
(maximum); the numbers of digits left and right of the decimal point
may be chosen freely. The types are all compatible and promoted to
floating point, when necessary. The mainframe languages, like PL/1
and COBOL, support them natively, and mainframe C, too:

    int x, y;
    decimal (15,2) amt;
    ...

These decimal data types are supported by the hardware (by
machine instructions). This was an optional feature in the 1960s,
but the modern machines of today all support it.

The decimal data is implemented as BCD data; hex digits are
decimal digits, and a sign half byte is added, that makes 16 bytes
for 31 digits. If shorter numbers are needed, less bytes are allocated
(all lengths from 1 to 16 are supported). All decimal fields have
odd numbers of digits.

I am thinking about adding support for decimal data in one of the
next versions of my Stanford Pascal compiler, which targets this
platform, as well as Windows, Linux, macOS etc.; of course, this
decimal format will need to be emulated on the non-mainframe
platforms.

For some years now, the mainframe also supports floating point
data based on a decimal representation. But I don't have experience
with this so far. Some compilers support this (PL/1).

Kind regards

Bernd



___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal



___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Freepascal Floating Point Issue

[Ralf Quint]

On 8/24/2017 2:45 PM, Ched wrote:
> And under "modern" Windows, the extended type, which is fully
> supported by the FPU, is *degraded* to double. So, I can't do high
> precision computation with fpc even if the native hardware permits
> such computations. I'm glued to XP as the full capabilities of the FPU
> were on the hands of programmers, years ago. 
It's not a problem of "modern" Windows, but a problem of any 64bit x86
OS that in that "long" mode the FPU does NOT support the extended data
type (80 bits, 10 bytes). In 32bit mode, the FPU is using the "old" x87
FP unit on the chip, in 64bit mode, it is using the SSE FP unit, which
doesn't have those 80 bit registers, it's 64 bit only (and several times
faster).
So that you can use that with your Windows XP version is likely due to
the fact that this is a 32bit version, not XP Professional 64 (or
Windows Server 2003 64 for that matter).

There are apparently some ways to enable the FP calculation to use the
x87 FPU and therefor the possibility of those 80 bit registers on Inter
chips (so far), but for one, this runs significantly slower that the SSE
FPU, and then this is apparently not supported by (all) AMD CPUs, so you
are limiting yourself also on which systems your code can run...

Ralf


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Inline ASM code

[LacaK]

Hi *,

I need store result of floating point calculation (in my example 
arctan()) in memory pointed by some variable. See this code:

var a: single; pa: PSingle;
  asm
  fild dy
  fild dx
  fpatan
  fstp a
  fwait
  end;
  pa^ := a;

It works, but is there any way how to store result directly to "pa^" in 
assembler ?

I have tried:
  ...
  fpatan
  fstp pa^ ... fstp (pa) ... but this does not compile ... I need 
store to memory location pointed by pa "variable"

  fwait
  end;

Thanks
-Laco.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] H2pas tool vs others, C header translation

[Martok]

> It is perfectly predictable. Just do not store invalid values in enumeration 
> variables. And invalid
> is everything not being declared. This is how FPC works and will work.
Aye. The point being, if the store operation is in a library (a getter, such as
mpfr_get_default_rounding_mode), there is just no way of absolutely enforcing
that - so the FPC side must be defensive. As you say, enums already contain
typing assumptions and are not meant to be defensive, so they can't be used
here. That's all I wanted to point out.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Inline ASM code

[Sven Barth via fpc-pascal]

Am 24.08.2017 08:32 schrieb "LacaK" :
>
> Hi *,
>
> I need store result of floating point calculation (in my example
arctan()) in memory pointed by some variable. See this code:
> var a: single; pa: PSingle;
>   asm
>   fild dy
>   fild dx
>   fpatan
>   fstp a
>   fwait
>   end;
>   pa^ := a;
>
> It works, but is there any way how to store result directly to "pa^" in
assembler ?
> I have tried:
>   ...
>   fpatan
>   fstp pa^ ... fstp (pa) ... but this does not compile ... I need
store to memory location pointed by pa "variable"
>   fwait
>   end;
>

You need to retrieve the value of pa into a register and then store at that
address. Something like this:

=== code begin ===
mov edx, pa
fstp [pa]
=== code end ===

Note 1: not tested
Note 2: you might want to check which register you can use for that
Note 3: I hope you keep the global and the assembler function in the same
unit, because inter-unit access to globals changes when dynamic packages
are enabled for a target

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Freepascal Floating Point Issue

[Sven Barth via fpc-pascal]

Am 23.08.2017 02:16 schrieb "Paul Nance" :
>
> Turbo Pascal also had a BCD unit.

Free Pascal also has a BCD unit: FmtBCD. It provides a BCD type and
operators as well operator overloads.

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Freepascal Floating Point Issue

[Sven Barth via fpc-pascal]

Am 25.08.2017 01:33 schrieb "Ralf Quint" :
>
> On 8/24/2017 2:45 PM, Ched wrote:
> > And under "modern" Windows, the extended type, which is fully
> > supported by the FPU, is *degraded* to double. So, I can't do high
> > precision computation with fpc even if the native hardware permits
> > such computations. I'm glued to XP as the full capabilities of the FPU
> > were on the hands of programmers, years ago.
> It's not a problem of "modern" Windows, but a problem of any 64bit x86
> OS that in that "long" mode the FPU does NOT support the extended data
> type (80 bits, 10 bytes). In 32bit mode, the FPU is using the "old" x87
> FP unit on the chip, in 64bit mode, it is using the SSE FP unit, which
> doesn't have those 80 bit registers, it's 64 bit only (and several times
> faster).
> So that you can use that with your Windows XP version is likely due to
> the fact that this is a 32bit version, not XP Professional 64 (or
> Windows Server 2003 64 for that matter).
>
> There are apparently some ways to enable the FP calculation to use the
> x87 FPU and therefor the possibility of those 80 bit registers on Inter
> chips (so far), but for one, this runs significantly slower that the SSE
> FPU, and then this is apparently not supported by (all) AMD CPUs, so you
> are limiting yourself also on which systems your code can run...

Plase note that all non-Windows 64-bit systems have no problems with
enabling the FPU and even Windows needs to handle it due to 32-bit software
requiring it.
The only x86_64 OS we support that doesn't have Extended enabled (by
default) *is* Win64.

Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal