Re: [fpc-devel] fpcmkcfg and fpc.cfg questions

[wkitty42]

On 3/24/19 6:21 PM, Bart wrote:

Extract from fpc.cfg from 3.0.4 (created by offcial installer)
# searchpath for units and other system dependent things
-FuC:\devel\fpc\3.0.4/units/$fpctarget
-FuC:\devel\fpc\3.0.4/units/$fpctarget/*
-FuC:\devel\fpc\3.0.4/units/$fpctarget/rtl

Extract from fpc.cfg from fpc trunk: created with fpcmkcfg.exe (from trunk)
# searchpath for units and other system dependent things
-Fu/units/$fpctarget
-Fu/units/$fpctarget/*
-Fu/units/$fpctarget/rtl

Notice all paths are relative (to what?)


none of the paths listed above are relative... they all start with a drive 
letter and backslash or a slash...


relative paths do not start with a drive letter or slash but they may start with 
".."



--
 NOTE: No off-list assistance is given without prior approval.
   *Please keep mailing list traffic on the list unless*
   *a signed and pre-paid contract is in effect with us.*
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] implicit generic specialization modeswitch name

[Ryan Joseph]

implicitroutinespecialization is one character shorter. ;) It’s maybe more 
accurate also since Pascal has the distinction between procedure/function.

Because this would be the longest mode switch is this maybe a good candidate 
for abbreviations? Could be implicitroutinespez or implicitprocspecialization.

There’s the list of other mode switches for some point of reference.

 m_class,   { delphi class model }
 m_objpas,  { load objpas unit }
 m_result,  { result in functions }
 m_string_pchar,{ pchar 2 string conversion }
 m_cvar_support,{ cvar variable directive }
 m_nested_comment,  { nested comments }
 m_tp_procvar,  { tp style procvars (no @ needed) }
 m_mac_procvar, { macpas style procvars }
 m_repeat_forward,  { repeating forward declarations is needed }
 m_pointer_2_procedure, { allows the assignement of pointers to
  procedure variables }
 m_autoderef,   { does auto dereferencing of struct. vars }
 m_initfinal,   { initialization/finalization for units }
 m_default_ansistring,  { ansistring turned on by default }
 m_out, { support the calling convention OUT }
 m_default_para,{ support default parameters }
 m_hintdirective,   { support hint directives }
 m_duplicate_names, { allow locals/paras to have duplicate names of 
globals }
 m_property,{ allow properties }
 m_default_inline,  { allow inline proc directive }
 m_except,  { allow exception-related keywords }
 m_objectivec1, { support interfacing with Objective-C (1.0) }
 m_objectivec2, { support interfacing with Objective-C (2.0) }
 m_nested_procvars, { support nested procedural variables }
 m_non_local_goto,  { support non local gotos (like iso pascal) }
 m_advanced_records,{ advanced record syntax with visibility 
sections, methods and properties }
 m_isolike_unary_minus, { unary minus like in iso pascal: same 
precedence level as binary minus/plus }
 m_systemcodepage,  { use system codepage as compiler codepage by 
default, emit ansistrings with system codepage }
 m_final_fields,{ allows declaring fields as "final", which 
means they must be initialised
  in the (class) constructor and are constant 
from then on (same as final
  fields in Java) }
 m_default_unicodestring, { makes the default string type in $h+ mode 
unicodestring rather than
ansistring; similarly, char becomes 
unicodechar rather than ansichar }
 m_type_helpers,{ allows the declaration of "type helper" for 
all supported types
  (primitive types, records, classes, 
interfaces) }
 m_blocks,  { support for 
http://en.wikipedia.org/wiki/Blocks_(C_language_extension) }
 m_isolike_io,  { I/O as it required by an ISO compatible 
compiler }
 m_isolike_program_para, { program parameters as it required by an ISO 
compatible compiler }
 m_isolike_mod, { mod operation as it is required by an iso 
compatible compiler }
 m_array_operators, { use Delphi compatible array operators instead 
of custom ones ("+") }


Regards,
Ryan Joseph

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

Re: [fpc-devel] TRegistry and Unicode

[Bart]

On Sat, Mar 23, 2019 at 2:27 PM Bart  wrote:

> > I will look at it tomorrow. It has been a busy week.

Thanks for applying.
Thanks to all of you for your advice and patience.

Should the changes be documented at
http://wiki.lazarus.freepascal.org/FPC_New_Features_Trunk#Units ?

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

[fpc-devel] fpcmkcfg and fpc.cfg questions

[Bart]

Hi,

First problem:

I tried to build lazarus trunk with fpc trunk.
Lazarus r60747, fresh checkout
Fpc r41788, installed from source in C:\PP

It failed with:
C:\devel\laztrunktrunk\packager\registration\fcllaz.pas(11,3) Fatal:
(10022) Can't find unit db used by fcllaz

I took a look at my fpc.cfg files.

Extract from fpc.cfg from 3.0.4 (created by offcial installer)
# searchpath for units and other system dependent things
-FuC:\devel\fpc\3.0.4/units/$fpctarget
-FuC:\devel\fpc\3.0.4/units/$fpctarget/*
-FuC:\devel\fpc\3.0.4/units/$fpctarget/rtl

Extract from fpc.cfg from fpc trunk: created with fpcmkcfg.exe (from trunk)
# searchpath for units and other system dependent things
-Fu/units/$fpctarget
-Fu/units/$fpctarget/*
-Fu/units/$fpctarget/rtl

Notice all paths are relative (to what?)
How does fpc know that, in relation to fpc.exe this must be translated to:
..\..\units\$fpctarget  ?

=== output of make ===
make distclean
make bigide OPT="-vut"

make -C packager/registration
make[1]: Entering directory `C:/devel/laztrunktrunk/packager/registration'
C:/devel/fpc/3.0.4/bin/i386-win32/rm.exe -f ../units/i386-win32/fcllaz.ppu
C:/pp/bin/i386-win32/ppc386.exe -MObjFPC -Scghi -O1 -g -gl -l
-vewnhibq -Fu. -Fuc:/pp/units/i386-win32/rtl -FE.
-FU../units/i386-win32 -g -gl -vut -di386 fcllaz.pas
Configfile search: fpc.cfg
Configfile search: C:\Users\Bart\fpc.cfg
Configfile search: C:\ProgramData\fpc.cfg
Configfile search: C:\pp\bin\i386-win32\fpc.cfg
(11026) Reading options from file C:\pp\bin\i386-win32\fpc.cfg
Hint: (11030) Start of reading config file C:\pp\bin\i386-win32\fpc.cfg
Path "C:\units\i386-win32\" not found
Path "C:\units\i386-win32\*\" not found
Path "C:\units\i386-win32\rtl\" not found
Path "C:\units\i386-win32\httpd22\" not found
Path "C:\Users\Bart\AppData\Local\FreePascal\fppkg\units\i386-win32\*\"
not found
Path "C:\lib\i386-win32\" not found
Hint: (11031) End of reading config file C:\pp\bin\i386-win32\fpc.cfg
Free Pascal Compiler version 3.3.1 [2019/03/17] for i386
Copyright (c) 1993-2018 by Florian Klaempfl and others
(1000) Compiler: C:\pp\bin\i386-win32\ppc386.exe
(1002) Target OS: Win32 for i386
(1003) Using executable path: C:\pp\bin\i386-win32\
(1004) Using unit path: .\
(1004) Using unit path: C:\pp\units\i386-win32\rtl\
(1004) Using unit path: C:\pp\bin\i386-win32\
(1006) Using library path: .\
(1006) Using library path: C:\pp\units\i386-win32\rtl\
(1006) Using library path: C:\pp\bin\i386-win32\
(1007) Using object path: .\
(1007) Using object path: C:\pp\units\i386-win32\rtl\
(1007) Using object path: C:\pp\bin\i386-win32\
(3104) Compiling fcllaz.pas
Searching file fcllaz.pas... found
(PROGRAM)  (10057) Registering new unit SYSTEM
(PROGRAM)  (10027) Load from FCLLAZ (interface) unit SYSTEM
(SYSTEM)   (10055) Loading unit SYSTEM
(1) Unitsearch: system.ppu
(1) Unitsearch: ..\units\i386-win32\system.ppu
(1) Unitsearch: system.pp
(1) Unitsearch: system.pas
(1) Unitsearch: system.ppu
(1) Unitsearch: system.pp
(1) Unitsearch: system.pas
(1) Unitsearch: C:\pp\units\i386-win32\rtl\system.ppu
(10001) PPU Loading C:\pp\units\i386-win32\rtl\system.ppu
(SYSTEM)   (10002) PPU Name: C:\pp\units\i386-win32\rtl\system.ppu
(SYSTEM)   (10005) PPU Time: 2019/03/17 12:28:14
(SYSTEM)   (10003) PPU Flags: 225409
(SYSTEM)   (10004) PPU Crc: D0EC42A2
(SYSTEM)   (10004) PPU Crc: 5CA0AD90 (intfc)
(SYSTEM)   (10004) PPU Crc: 5B736799 (indc)
(SYSTEM)   Number of definitions: 2746
(SYSTEM)   Number of symbols: 8557
(SYSTEM)   (10011) PPU Source: system.pp not available
(SYSTEM)   (10011) PPU Source: systemh.inc not available
(SYSTEM)   (10011) PPU Source: sysosh.inc not available
(SYSTEM)   (10011) PPU Source: rtldefs.inc not available
(SYSTEM)   (10011) PPU Source: filerec.inc not available
(SYSTEM)   (10011) PPU Source: textrec.inc not available
(SYSTEM)   (10011) PPU Source: innr.inc not available
(SYSTEM)   (10011) PPU Source: cpuh.inc not available
(SYSTEM)   (10011) PPU Source: cpuinnr.inc not available
(SYSTEM)   (10011) PPU Source: mathh.inc not available
(SYSTEM)   (10011) PPU Source: currh.inc not available
(SYSTEM)   (10011) PPU Source: ustringh.inc not available
(SYSTEM)   (10011) PPU Source: wstringh.inc not available
(SYSTEM)   (10011) PPU Source: setjumph.inc not available
(SYSTEM)   (10011) PPU Source: rttih.inc not available
(SYSTEM)   (10011) PPU Source: objpash.inc not available
(SYSTEM)   (10011) PPU Source: varianth.inc not available
(SYSTEM)   (10011) PPU Source: dynarrh.inc not available
(SYSTEM)   (10011) PPU Source: compproc.inc not available
(SYSTEM)   (10011) PPU Source: heaph.inc not available
(SYSTEM)   (10011) PPU Source: threadh.inc not available
(SYSTEM)   (10011) PPU Source: dynlibh.inc not available
(SYSTEM)   (10011) PPU Source: sysdlh.inc not available
(SYSTEM)   (10011) PPU Source: resh.inc not available
(SYSTEM)   (10011) PPU Source: excepth.inc not available
(SYSTEM)   (10011) PPU Source: system.inc not available
(SYSTEM)   (10011) PPU Source: 

Re: [fpc-devel] implicit generic specialization modeswitch name

[Sven Barth via fpc-devel]

Bart  schrieb am So., 24. März 2019, 17:44:

> On Sun, Mar 24, 2019 at 5:18 PM Sven Barth via fpc-devel
>  wrote:
>
> > I agree with Florian that a better name is needed for the modeswitch
> > ("implicitgenerics" as a different meaning in my opinion). But I don't
> > have a better idea than "implicitfunctionspecialization" either...
>
> implicitgenericfunctions?
> Just a little bit shorter.
>

No, that has the same wrong connotations. It's about specializations, but
"generic" suggests that it's about the declarations.

Regards,
Sven

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

Re: [fpc-devel] implicit generic specialization modeswitch name

[Bart]

On Sun, Mar 24, 2019 at 5:18 PM Sven Barth via fpc-devel
 wrote:

> I agree with Florian that a better name is needed for the modeswitch
> ("implicitgenerics" as a different meaning in my opinion). But I don't
> have a better idea than "implicitfunctionspecialization" either...

implicitgenericfunctions?
Just a little bit shorter.
-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] implicit generic specialization modeswitch name

[Sven Barth via fpc-devel]

Am 24.03.2019 um 15:02 schrieb Ryan Joseph:

For my patch https://bugs.freepascal.org/view.php?id=35261 I have named the 
modeswitch “implicitgenerics” but Florian liked the name 
“implicitfunctionspecialization” (long but clear were his words). Btw this is 
the mode switch will allows specialization of generic routines by inferring the 
types from the parameters.

I have no preference either way but I wanted to ask the list if they had any 
better ideas to contribute. If there’s nothing better I’ll just defer to what 
Florian wants.
I agree with Florian that a better name is needed for the modeswitch 
("implicitgenerics" as a different meaning in my opinion). But I don't 
have a better idea than "implicitfunctionspecialization" either...


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

Re: [fpc-devel] Running test suite linker error (mac)

[Jonas Maebe]

On 24/03/2019 14:53, Ryan Joseph wrote:

This same problem of the missing crt1.10.5.o file on macOS 10.14 is now 
affecting running the test suite. I have no idea what changed because this 
worked just a couple weeks ago.

When building with FPC now I need to include a search path with 
-Fl/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib but I’m not able 
to do this with the tests.

make full TEST_FPC=/Developer/ObjectivePascal/fpc-git/compiler/x86_64/pp 
OPT="-Fl/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib”


The options used by the test compiler come from TEST_OPT rather than 
from OPT



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

[fpc-devel] Running test suite linker error (mac)

[Ryan Joseph]

This same problem of the missing crt1.10.5.o file on macOS 10.14 is now 
affecting running the test suite. I have no idea what changed because this 
worked just a couple weeks ago.

When building with FPC now I need to include a search path with 
-Fl/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib but I’m not able 
to do this with the tests.

make full TEST_FPC=/Developer/ObjectivePascal/fpc-git/compiler/x86_64/pp 
OPT="-Fl/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib”

[…]
/Developer/ObjectivePascal/fpc-git/compiler/x86_64/pp fpmake.pp -n 
-Fu../packages/fpmkunit/units_bs/x86_64-darwin -Fu../rtl/units/x86_64-darwin  
-Fd -n
ld: file not found: /usr/lib/crt1.10.5.o

Regards,
Ryan Joseph

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

[fpc-devel] implicit generic specialization modeswitch name

[Ryan Joseph]

For my patch https://bugs.freepascal.org/view.php?id=35261 I have named the 
modeswitch “implicitgenerics” but Florian liked the name 
“implicitfunctionspecialization” (long but clear were his words). Btw this is 
the mode switch will allows specialization of generic routines by inferring the 
types from the parameters.

I have no preference either way but I wanted to ask the list if they had any 
better ideas to contribute. If there’s nothing better I’ll just defer to what 
Florian wants.

Regards,
Ryan Joseph

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

Re: [fpc-devel] Successful implementation of inline supportforpureassembler routines on x86

[Florian Klämpfl]

Am 24.03.2019 um 12:30 schrieb J. Gareth Moreton:
> If Trunc is automatically inlined, why is there a separate implementation of 
> it on x86_64 anyway?

Probably when optimizing for size on x86_64-linux (where extended is no 
deprecated) and if sse3 is no enabled.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Successful implementation of inline supportforpureassembler routines on x86

[J. Gareth Moreton]

 Well I already decided not to pursue this particular feature any further
because of the Holy Grail that are intrinsics.
 If Trunc is automatically inlined, why is there a separate implementation
of it on x86_64 anyway?
 On Sun 24/03/19 12:09 , Florian Klämpfl flor...@freepascal.org sent:
 ...

 This is a not a valid reason. You can play with the svn branch.
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel [1]">

 Who's going to? No-one's doing to develop real-world examples of the use
of intrinsics on an unofficial branch whose address takes some hunting to
find.  At least on the SVN trunk, you'll be playing and DEVELOPING with
features that are most likely going to stay.  This won't happen with
intrinsics until they are merged with the trunk, whenever that will happen.

 Heck, with the current branch I can't even compile through Lazarus
properly because it gets completely mixed up somewhere with conflicting
definitions of TProcessPriority, so testing and development there is
limited even further.
 Gareth aka. Kit
 

Links:
--
[1] http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Successful implementation of inline support forpureassembler routines on x86

[Florian Klämpfl]

Am 24.03.2019 um 11:33 schrieb J. Gareth Moreton:
> The main thing is the degree of control you have using pure assembler over 
> intrinsics, and someone brought up that
> intrinsics don't give you good access to the FLAGS register. 

Juggling with the flags is rarely possible on x86 anyways as almost all 
instructions change them.

> Additionally, unless you do some rather untidy nested
> parameter chaining (calling an intrinsic and passing its result into another 
> intrinsic, several layers deep), you don't
> have too much control over how the results are stored.  Normally not a 
> terrible thing, but if you have a temporary value
> that you know will be discarded, you want it in a register and never stored 
> on the stack, for example.

You do not ensure this with pure assembler either. It's even worse here: the 
instructions use always the same registers
so the code is very prone to do a lot of spilling. Inline pure assembler 
routines will result in most cases in far worse
code than intrinsics as the compiler cannot change the register usage in the 
inlined assembler.

> 
> There's also the issue of maintenance... writing intrinsics for every single 
> possible instruction on every single
> platform and determining that they behave in the way they should.

Just look at the intrinsics branch, this can be easily automated.

> 
> I guess we have been spoilt in a way because Pascal has always supported a 
> clean and efficient way to drop into assembly
> language if you so choose, and this is what I've gotten used to rather than 
> the intrinsics of C++.  I don't like the
> idea of putting breakpoints on the intrinsics and opening up the Disassembly 
> window just to check that the compiler
> isn't blindly storing temporary values on the stack.

... which will happen much more for inlined assembler as the compiler is less 
flexible regarding register usage.

> 
> If I had to give one final reason... there are already functions in the RTL 
> that are written in pure assembly language
> that would easily benefit being inlined, such as SwapEndian and Trunc.  

Actually, trunc renders all these reasons void: it is inlined, if the code is 
compiled for an architecture supporting
the needed instructions (i386-win32, compiled with  -Cpcoreavx2 -Cavx2):

# [5] writeln(trunc(d));
callfpc_get_output
movl%eax,%ebx
fldlU_$P$PROGRAM_$$_D
fisttpq -8(%ebp)
pushl   -4(%ebp)
pushl   -8(%ebp)
movl%ebx,%edx
movl$0,%eax
callfpc_write_text_int64


This is not possible with inlined pure assembler routines. They would use the 
instruction set selected when the rtl was
compiled. trunc shows perfectly why intrinsics are the way to go.

Same could be done for SwapEndian.

> Otherwise they'd have to be rewritten to use
> intrinsics if anyone remembers to.
> 
> There is one other thing... intrinsics haven't been merged into the trunk 
> yet, so we can't test them or determine if
> they are actually what we desire.

This is a not a valid reason. You can play with the svn branch.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Successful implementation of inline support forpureassembler routines on x86

[J. Gareth Moreton]

 The main thing is the degree of control you have using pure assembler over
intrinsics, and someone brought up that intrinsics don't give you good
access to the FLAGS register.  Additionally, unless you do some rather
untidy nested parameter chaining (calling an intrinsic and passing its
result into another intrinsic, several layers deep), you don't have too
much control over how the results are stored.  Normally not a terrible
thing, but if you have a temporary value that you know will be discarded,
you want it in a register and never stored on the stack, for example.
 I know you keep saying the compiler should be smart enough to determine
that, but it's not.  It's not even smart enough to merge nearby "div" and
"mod" instructions with the same denominator, and putting individual cases
in the peephole optimizer can only go so far before you have to redesign it
from the ground up (things like "full tree optimization"), and there comes
a point where you can put so many possible optimisations into a compiler
that it becomes prohibitively slow or take up too much memory... the main
problem is that optimisation as a whole is NP-complete.  You'll never get
everything, and assembly language is the only way to be sure you're making
the most efficient code in specialised situations where speed is of
paramount importance.

 There's also the issue of maintenance... writing intrinsics for every
single possible instruction on every single platform and determining that
they behave in the way they should.
 I guess we have been spoilt in a way because Pascal has always supported a
clean and efficient way to drop into assembly language if you so choose,
and this is what I've gotten used to rather than the intrinsics of C++.  I
don't like the idea of putting breakpoints on the intrinsics and opening up
the Disassembly window just to check that the compiler isn't blindly
storing temporary values on the stack.
 If I had to give one final reason... there are already functions in the
RTL that are written in pure assembly language that would easily benefit
being inlined, such as SwapEndian and Trunc.  Otherwise they'd have to be
rewritten to use intrinsics if anyone remembers to.

 There is one other thing... intrinsics haven't been merged into the trunk
yet, so we can't test them or determine if they are actually what we
desire.
 Gareth aka. Kit

 On Sun 24/03/19 09:45 , Florian Klämpfl flor...@freepascal.org sent:
 Am 18.03.2019 um 02:57 schrieb Ben Grasset: 
 > On Sun, Mar 17, 2019 at 1:57 PM Florian Klämpfl  wrote: 
 > 
 > 
 > How is it better than intrinsics support (similiar to gcc/icc etc.)? 
 > 
 > 
 > Well, it wouldn't be better than a literal equivalent to those
intriniscs, if that's what we're talking about. By which 
 > I mean, like, say how in Clang/GCC (or languages such as Rust that use
LLVM), if you do _mm_loadl_pd or whatever, that 
 > translates not to a function call but directly to the "inlined"
assembler instructions (at least in release builds.)  

 Yes, that's what I mean. So far I have not seen a single advantage of
inlining pure assembler routines over such intrinsics. 
 ___ 
 fpc-devel maillist - fpc-devel@lists.freepascal.org [1] 
 http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[2]">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel 

 

Links:
--
[1] mailto:fpc-devel@lists.freepascal.org
[2] http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Successful implementation of inline support for pure assembler routines on x86

[Florian Klämpfl]

Am 19.03.2019 um 20:17 schrieb J. Gareth Moreton:
> I would have allowed writing to the stack with inline assembly functions if a 
> way could be found to ensure that the
> compiled program behaves the same way whether the function is inlined or 
> called directly (e.g. through a direct CALL or
> a function pointer), which would otherwise require shifting byte offsets 
> depending on if the function return address was
> pushed or not, so I decided to just forbid it completely.
> 
> If you want to inline regular functions with assembler blocks, you'll need 
> the attached bug fixes.  The rest I'll leave
> up to you.
> 
> What is Florian's and your vision for Free Pascal? You already have a 
> cross-platform Object Pascal compiler... what's
> next for it?  Does any of my proposals even have a place in that vision, 
> because honestly I don't know if the following
> is wanted:
> 
> - pure functions
> - XML node dump (compiler debugging feature) - I personally need it for pure 
> functions and for fixing #32913.
> - faster and smarter optimization on x86-64

All of them are in the scope of FPC imo, currently things are time limited 
though :(
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Successful implementation of inline support for pureassembler routines on x86

[Florian Klämpfl]

Am 21.03.2019 um 09:50 schrieb J. Gareth Moreton:
> Well, I guess that's good. I did wonder 
> though, because the XML dump patches have 
> been sitting in the bug tracker since the 
> start of February: 
> https://bugs.freepascal.org/view.php?
> id=35017

Matter of time.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Successful implementation of inline support forpure assembler routines on x86

[Florian Klämpfl]

Am 18.03.2019 um 02:57 schrieb Ben Grasset:
> On Sun, Mar 17, 2019 at 1:57 PM Florian Klämpfl  > wrote:
> 
> 
> How is it better than intrinsics support (similiar to gcc/icc etc.)?
> 
> 
> Well, it wouldn't be better than a literal equivalent to those intriniscs, if 
> that's what we're talking about. By which
> I mean, like, say how in Clang/GCC (or languages such as Rust that use LLVM), 
> if you do _mm_loadl_pd or whatever, that
> translates not to a function call but directly to the "inlined" assembler 
> instructions (at least in release builds.) 

Yes, that's what I mean. So far I have not seen a single advantage of inlining 
pure assembler routines over such intrinsics.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel