Re: [fpc-pascal] intel vs att asm (fstp instruction) (osx/clang features)

2016-05-04 Thread Dmitry Boyarintsev 
On Wed, May 4, 2016 at 6:14 AM, Pierre Free Pascal 
wrote:

> I think the correct solution for you is to use explicit size information:
>
>
>
>   FSTP SINGLE PTR [EDX]
>
>   FSTP SINGLE PTR [EAX]
>
Indeed that worked as expected. Thank you.


> but
>
>   FSTP [s]
>
> and
>
>   FSTP [c]
>
It still requires explicit size information, like
   FSTP SINGLE [s]


>   My GNU as version 2.26 does not seem to need an explicit size,
>
> but I don’t know what Xcode uses, isn’t it also a GNU assembler?
>
> Could you tell us which assembler is used?
>

It's Apple's clang IIRC Apple stopped using gnu-tools since Xcode 3.2 or
something like that.
Here are more exact details:

$ as -v
Apple LLVM version 7.3.0 (clang-703.0.29)
Target: x86_64-apple-darwin15.3.0
Thread model: posix
InstalledDir:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
 
"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang"
-cc1as -triple x86_64-apple-macosx10.11.0 -filetype obj -main-file-name -
-target-cpu core2 -dwarf-version=2 -fdebug-compilation-dir
/Users/dmitry/FPC_Laz -dwarf-debug-producer Apple LLVM version 7.3.0
(clang-703.0.29) -mrelocation-model pic -o a.out -

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

Re: [fpc-pascal] intel vs att asm (fstp instruction) (osx/clang features)

2016-05-04 Thread Ched 

Hello,

I have something like this which seems to work very nicely

Cheers, Ched'



PROCEDURE SINCOS(CONST X: DOUBLE; VAR S, C: DOUBLE);
BEGIN
   {$IFDEF NOASM}
  S:=SIN(X);
  C:=COS(X);
   {$ELSE}
  {$IFDEF VER70}
 IF TEST8087=3 THEN
ASM
   FLD   X
   DB$D9,$FB
   LES   DI,C
   FSTP  DOUBLE(ES:[DI])
   LES   DI,S
   FSTP  DOUBLE(ES:[DI])
END
 ELSE
BEGIN
   S:=SYSTEM.SIN(X);
   C:=SYSTEM.COS(X);
END;
  {$ELSE}
  ASM
 FLD X
 FSINCOS
 MOV  ECX,C
 FSTP DOUBLE([ECX])
 MOV  ECX,S
 FSTP DOUBLE([ECX])
  END
  {$ENDIF}
   {$ENDIF}
END;



Le 04.05.2016 à 10:14, Pierre Free Pascal a écrit :

I think the correct solution for you is to use explicit size information:



  FSTP SINGLE PTR [EDX]

  FSTP SINGLE PTR [EAX]



but

  FSTP [s]

and

  FSTP [c]

would be even better, I don’t know if this syntax is Delphi compatible or not.



  It seems that indeed Free Pascal does not set the size of those instruction,

but seems to use single as default size for internal code generation…

  When generating assembler file for GNU assembler or NASM,

it does not seem to print out this “assumed” size, which indeed

leads to a failure using –Anasm option on trunk compiler with i386-win32 target.



  My GNU as version 2.26 does not seem to need an explicit size,

but I don’t know what Xcode uses, isn’t it also a GNU assembler?

Could you tell us which assembler is used?





Pierre





*De :*fpc-pascal-boun...@lists.freepascal.org 
[mailto:fpc-pascal-boun...@lists.freepascal.org] *De la
part de* Dmitry Boyarintsev
*Envoyé :* mercredi 4 mai 2016 02:28
*À :* FPC-Pascal users discussions
*Objet :* [fpc-pascal] intel vs att asm (fstp instruction) (osx/clang features)



Hello,



I'm dealing with the following code (from ZenGL library), targeting OSX

---

{$mode delphi}



procedure m_SinCos( Angle : Single; out s, c : Single ); assembler;

asm

  FLD Angle

  FSINCOS

  FSTP [EDX]

  FSTP [EAX]

end;



var

  s,c: single;

begin

  m_SinCos(0,s,c);

end.

---



The latest Xcode 7.0 tools does recognize the generated assembler (fpc trunk):

-

# [5] FLD Angle

  flds  8(%ebp)

# [6] FSINCOS

  fsincos

# [7] FSTP [EDX]

  fstp  (%edx)

# [8] FSTP [EAX]

  fstp  (%eax)

-



as a problem:



Assembling program

test.s:21:2: error: ambiguous instructions require an explicit suffix (could be 
'fstps', 'fstpl', or 'fstpt')

fstp(%edx)

^

test.s:23:2: error: ambiguous instructions require an explicit suffix (could be 
'fstps', 'fstpl', or 'fstpt')

fstp(%eax)



One interested could search the internet for the problem encountered with other 
platforms, and find out
that the newer clang is somewhat backward incompatible.



My first attempt was to replace to put the suggested FSTPS instruction in place:

FSTPS [EDX]

However, the compiler stopped me, complaining about "FSTPS" is not a recognized 
instruction.



The next approach was to rewrite the function into at syntax. (The actual 
implementation could be found
at sincos() of RTL math unit).



Is it a yet to be developed feature for FPC to satisfy demands of external 
tools relies on?



I presume since the compiler parses intel asm and translates it into at asm, 
it should take into
consideration requirements of the latest osx building tools.

Or is it already supported and I'm just missing a compiler switch?



thanks,

Dmitry





___
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] getopts unit vs CustApp parameter handling

2016-05-04 Thread Graeme Geldenhuys 
On 2016-05-04 10:24, Michael Van Canneyt wrote:
> It would be, but you had better update your interface, various things
> have been added.

I assume you mean FPC 2.6.4 (what I used) verses FPC 3.x. Thanks for the
tip, I’ll take a look tonight and update the code appropriately.


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

Re: [fpc-pascal] FCL: moving FastHTMLParser

2016-05-04 Thread Dmitry Boyarintsev 
On Wed, May 4, 2016 at 10:36 AM, Graeme Geldenhuys <
mailingli...@geldenhuys.co.uk> wrote:

>   FPC manages to find in somehow (not sure how yet - FPC magic ).
>

Isn't it in fpc.cfg?
-Fu/usr/local/bin/x.x.x/units/$fpctarget/*

That's forcing FPC to look through all compiled packages.
Since fasthtmlparser.o and fasthtmlparser.ppu are found at:
   /usr/local/bin/x.x.x/units/$fpctarget/chm/
it allows you to use it "out of the box".

thanks,
Dmitry

P.S: /usr/local/bin should be replaced with the proper FPC installation
folder. and "x.x.x" with the proper FPC version.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FCL: moving FastHTMLParser

2016-05-04 Thread Graeme Geldenhuys 
On 2016-05-04 15:10, Graeme Geldenhuys wrote:
> So for now I made a copy of that unit, but that definitely doesn’t seem
> like the best way of doing things. Is there a better why of handling this?

Umm, in hind sight, simply adding the “fasthtmlparser” to the uses
clause in my code seems to work. I don’t need a copy of that unit after
all. FPC manages to find in somehow (not sure how yet - FPC magic ).

Either way, I see the fpindexer also uses that unit. So maybe it is
worth moving it to a more public [obvious] location in FCL?

Regards,
  Graeme

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] FCL: moving FastHTMLParser

2016-05-04 Thread Graeme Geldenhuys 
Hi,

Is there any chance of moving “packages/chm/src/fasthtmlparser.pas”
to a more publicly accessible location inside the FCL? eg: fcl-base?

That way other FCL packages could use that code as well (I think)? I’m
working on new code which will eventually live in the FCL. The code
needs a simple HTML-like tag parser. I started writing my own, then
while searching for something else in the FCL I stumbled across the
fasthtmlparser.pas unit which is exactly what I needed (no need for my
html parser any more). But I don't need anything else from the CHM
directory though.

So for now I made a copy of that unit, but that definitely doesn’t seem
like the best way of doing things. Is there a better why of handling this?

Regards,
  Graeme

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] intel vs att asm (fstp instruction) (osx/clang features)

2016-05-04 Thread Pierre Free Pascal 
I think the correct solution for you is to use explicit size information:

 

  FSTP SINGLE PTR [EDX]

  FSTP SINGLE PTR [EAX]

 

but

  FSTP [s]

and

  FSTP [c] 

would be even better, I don’t know if this syntax is Delphi compatible or not.

 

  It seems that indeed Free Pascal does not set the size of those instruction, 

but seems to use single as default size for internal code generation…

  When generating assembler file for GNU assembler or NASM,

it does not seem to print out this “assumed” size, which indeed

leads to a failure using –Anasm option on trunk compiler with i386-win32 target.

 

  My GNU as version 2.26 does not seem to need an explicit size,

but I don’t know what Xcode uses, isn’t it also a GNU assembler?

Could you tell us which assembler is used?

 

 

Pierre

  

 

De : fpc-pascal-boun...@lists.freepascal.org 
[mailto:fpc-pascal-boun...@lists.freepascal.org] De la part de Dmitry 
Boyarintsev
Envoyé : mercredi 4 mai 2016 02:28
À : FPC-Pascal users discussions
Objet : [fpc-pascal] intel vs att asm (fstp instruction) (osx/clang features)

 

Hello,

 

I'm dealing with the following code (from ZenGL library), targeting OSX

---

{$mode delphi}

 

procedure m_SinCos( Angle : Single; out s, c : Single ); assembler; 

asm

  FLD Angle

  FSINCOS

  FSTP [EDX]

  FSTP [EAX]

end;

 

var

  s,c: single;

begin

  m_SinCos(0,s,c);

end.

---

 

The latest Xcode 7.0 tools does recognize the generated assembler (fpc trunk):

-

# [5] FLD Angle

  flds  8(%ebp)

# [6] FSINCOS

  fsincos

# [7] FSTP [EDX]

  fstp  (%edx)

# [8] FSTP [EAX]

  fstp  (%eax) 

-

 

as a problem:

 

Assembling program

test.s:21:2: error: ambiguous instructions require an explicit suffix (could be 
'fstps', 'fstpl', or 'fstpt')

fstp(%edx)

^

test.s:23:2: error: ambiguous instructions require an explicit suffix (could be 
'fstps', 'fstpl', or 'fstpt')

fstp(%eax)

 

One interested could search the internet for the problem encountered with other 
platforms, and find out that the newer clang is somewhat backward incompatible.

 

My first attempt was to replace to put the suggested FSTPS instruction in place:

FSTPS [EDX]

However, the compiler stopped me, complaining about "FSTPS" is not a recognized 
instruction.

 

The next approach was to rewrite the function into at syntax. (The actual 
implementation could be found at sincos() of RTL math unit).

 

Is it a yet to be developed feature for FPC to satisfy demands of external 
tools relies on?

 

I presume since the compiler parses intel asm and translates it into at asm, 
it should take into consideration requirements of the latest osx building 
tools. 

Or is it already supported and I'm just missing a compiler switch?

 

thanks,

Dmitry

 

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

Re: [fpc-pascal] getopts unit vs CustApp parameter handling

2016-05-04 Thread Michael Van Canneyt 



On Wed, 4 May 2016, Graeme Geldenhuys wrote:


On 2016-05-03 11:02, Michael Van Canneyt wrote:

They serve the same purpose, but function differently.

Simply use the one whose interface you like best.


I'm used to the command line parameters handling of CustApp, but none of
my applications are TCustomApp based. Plus CustApp gives no code reuse
regarding command line parameters code. So I refactored the code out of
TCustomApp into an Interface and Class implementing that interface. So
now if I need good parameter list handling I simply mix in Interface
Delegation into any of my applications. This seems to work very well
thus far.

Would this be of interest to Free Pascal? If so, I can refactor the
CustApp code to use the Interface too.


It would be, but you had better update your interface, various things have been 
added.

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

Re: [fpc-pascal] getopts unit vs CustApp parameter handling

2016-05-04 Thread Graeme Geldenhuys 
On 2016-05-03 11:02, Michael Van Canneyt wrote:
> They serve the same purpose, but function differently.
> 
> Simply use the one whose interface you like best.

I'm used to the command line parameters handling of CustApp, but none of
my applications are TCustomApp based. Plus CustApp gives no code reuse
regarding command line parameters code. So I refactored the code out of
TCustomApp into an Interface and Class implementing that interface. So
now if I need good parameter list handling I simply mix in Interface
Delegation into any of my applications. This seems to work very well
thus far.

Would this be of interest to Free Pascal? If so, I can refactor the
CustApp code to use the Interface too.

If you wanted to take a look, the code is in the fpg_cmdlineparams.pas
unit in fpGUI. The ICmdLineParams interface and TfpgCmdLineParams class
(ignore the other deprecated class in that unit).


https://github.com/graemeg/fpGUI/blob/develop/src/corelib/fpg_cmdlineparams.pas

Example usage:
  See the nanoedit project in fpGUI:


https://github.com/graemeg/fpGUI/blob/develop/examples/apps/nanoedit/nanoedit.lpr

Regards,
  Graeme

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal