Re: [fpc-devel] LEA instruction speed

[Nikolay Nikolov via fpc-devel]

On 10/11/23 11:21, Tomas Hajny via fpc-devel wrote:

On 2023-10-11 04:15, J. Gareth Moreton via fpc-devel wrote:

Sweet, thank you.  Would you be willing to share your modified test's
source? I was worried that if CPUID wasn't present it would cause a
SIGILL.


Sure, attached, but I didn't do anything special - I modified it in a 
way allowing easy disabling of this detection for x86 by disabling 
definition of a conditional symbol added to the source and I was 
prepared to recompile with the functionality disabled on the old AMD 
DX4 if needed. However, I didn't need to do so - the AMD DX4 machine 
simply ignored it and chose the branch used in case of missing support 
for the particular CPUID function. I have no idea if this might be due 
to some protection in OS/2 Warp 4 (used for compiling and running the 
test on that machine) potentially masking that exception, or what was 
the reason. Apparently, it should be possible to detect CPUID 
availability (albeit not 100% reliably), see 
https://wiki.osdev.org/CPUID, but I didn't use that.


There's CPUID support detection code in the Free Pascal RTL for i8086 
and i386. It's in unit cpu:


function cpuid_support: boolean;

Nikolay



Tomas




On 11/10/2023 01:47, Tomas Hajny via fpc-devel wrote:

On 2023-10-10 13:24, J. Gareth Moreton via fpc-devel wrote:

I'm all for receiving results for all kinds of processor, as it helps
me to make more informed choices on flags as well as confirming that
Agner Fog''s instruction tables are correct. Also, results for older
processors can be hard to come by sometimes.

Currently, most architectures have a fast LEA, and the default
"Athlon" option lines up with this.  Of the Intel architectures, the
speed slows down on COREAVX onwards (COREI is fine), so I added a new
COREX (for 10th generation Core) option between ZEN2 and ZEN3 to mark
the point where LEA is fast again (its 16-bit version is also fast,
unlike Zen 3).

In the meantime I'll be looking at the benchmarking code that Stefan
provided to see if it can and should be integrated.

Thanks again everyone for the results you're giving.


Alright, fine (I modified your test to include the CPU name as well 
if possible and added an IFDEFed distinction of 32-bits versus 
64-bits):


32-bits:
CPU = AMD A9-9425 RADEON R5, 5 COMPUTE CORES 2C+3G
-
   Pascal control case: 0.85 ns/call
 Using LEA instruction: 0.56 ns/call
Using ADD instructions: 0.84 ns/call

64-bits:
CPU = AMD A9-9425 RADEON R5, 5 COMPUTE CORES 2C+3G
-
   Pascal control case: 0.85 ns/call
 Using LEA instruction: 0.56 ns/call
Using ADD instructions: 0.85 ns/call


32-bits:
CPU = AMD Athlon(tm) Processor
--
   Pascal control case: 6.10 ns/call
 Using LEA instruction: 3.40 ns/call
Using ADD instructions: 3.40 ns/call


32-bits:
(AMD DX4 100 MHz - no CPUID name)
   Pascal control case: 123 ns/call
 Using LEA instruction: 72 ns/call
Using ADD instructions: 73 ns/call

Tomas


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

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

Re: [fpc-devel] WebAssembly compilation problems - Wasm32 symbol xxx without index value error

[Nikolay Nikolov via fpc-devel]

On 3/31/23 01:19, Michalis Kamburelis via fpc-devel wrote:

Thanks for the answers,

I have submitted issue
https://gitlab.com/freepascal.org/fpc/source/-/issues/40229 describing
how to reproduce the problem.


I think I fixed it. At least compilation now continues and fails later, 
due to lack of goto support, so this particular bug should be fixed.


Nikolay



Hopefully it can get some attention :) I would very much like to add
"web" target to CGE, to be able to just run CGE games in a browser.
It's going to be my highest-priority thing after upcoming CGE 7.0
release.

Regards,
Michalis

czw., 30 mar 2023 o 21:11 Nikolay Nikolov via fpc-devel
 napisał(a):


On 3/28/23 02:12, Michalis Kamburelis via fpc-devel wrote:

Hi,

We're experimenting with compiling Castle Game Engine using FPC
WebAssembly target.

A lot of units and classes compiled smoothly, however we hit a weird
bug(s) at compiling our (big, too big!) unit X3DNodes. We get errors
"Wasm32 symbol xxx without index value error" at the code trying to
use various property setters or methods. Examples:

x3dcamerautils.pas(344,0) Error: Wasm32 symbol
X3DFIELDS$_$TSFROTATION_$__$$_SETVALUE$TGENERICVECTOR4 without index
value error

// where TSFRotation.Value is a property with record type, with getter
and setter methods

x3dcamerautils.pas(344,0) Error: Wasm32 symbol
X3DFIELDS$_$TX3DSIMPLEMULTFIELD$3$CRCD1E2ED59_CRCAB5A7799_$__$$_GETITEMS$$TSINGLELIST
without index value error

// where TX3DSimpleMultField.GetItems is a method of a generic class)

x3dcamerautils.pas(344,0) Error: Wasm32 symbol
X3DFIELDS$_$TSFFLOAT_$__$$_SETVALUE$SINGLE without index value error
x3dcamerautils.pas(344,0) Error: Wasm32 symbol

// where TSFFloat.SetValue is a simple setter for a Single property, no generics

castlescenecore.pas(8822,0) Error: Wasm32 symbol
CASTLESHAPEINTERNALSHADOWVOLUMES$_$TSHAPESHADOWVOLUMES_$__$$_PREPARERESOURCES
without index value error

// where TShapeShadowVolumes.PrepareResources is a simple method,
without any parameters, in a simple non-generic class

Weirder, on another machine, the symbols reported contain some exe
filenames at the place of initial "$_$" (maybe independent compiler
bug at message display?):

x3dloadinternalgeo.pas(234,0) Error: Wasm32 symbol
X3DFIELDS/usr/bin/dbus-update-activation-environmentTSFFLOAT_$__$$_SETVALUE$SINGLE
without index value error

x3dloadinternalgeo.pas(234) Error: Wasm32 symbol
X3DFIELDS/home/michalis/bin/castle-engineTSFFLOAT_$__$$_SETVALUE$SINGLE
without index value error

Sometimes the errors can be workarounded by some simple actions --
like moving the property getter/setter protected->private, or avoiding
the call to that particular method. But the solutions, as well as
causes, seem ~random from our perspective. And all in all, we didn't
finish the compilation of X3DNodes unit because after each
fix/workaround/hack for a specific case, another similar error pops
up.

Grepping FPC for the asmw_e_illegal_unset_index (this is "Wasm32
symbol $1 without index value error"), the error can occur when symbol
cannot be found in the list where compiler expected it to be.

We don't have any simple bugreport about it (yet), as the error really
manifests only in a big unit, that is interconnected with a few other
big units. Isolating the testcase (and/or doing much needed refactor
of this unit :) ) will take a while.

Does anyone have a hint:

- What does this error really mean? What is internally wrong at
compilation to cause it? What could be the culprit?

- Is there some universal workaround for it (on CGE side) or fix on
the compiler side?

Even a vague hint could at least help us prepare an isolated
bugreport, because otherwise we have a rather big chunk of code to
dissect in order to provide a simple FPC testcase :)

Even a big unit is fine for a bug report, as long as all the code is
publicly available for download. If you can't seem to get it to
reproduce with a small test case, you can mention in the bug report that
you tried, but didn't succeed and still provide the full code needed.
AFAIK, the Castle Game Engine is open-source, so this shouldn't be a
problem?

Nikolay


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

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

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

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

Re: [fpc-devel] WebAssembly compilation problems - Wasm32 symbol xxx without index value error

[Nikolay Nikolov via fpc-devel]

On 3/28/23 02:12, Michalis Kamburelis via fpc-devel wrote:

Hi,

We're experimenting with compiling Castle Game Engine using FPC
WebAssembly target.

A lot of units and classes compiled smoothly, however we hit a weird
bug(s) at compiling our (big, too big!) unit X3DNodes. We get errors
"Wasm32 symbol xxx without index value error" at the code trying to
use various property setters or methods. Examples:

x3dcamerautils.pas(344,0) Error: Wasm32 symbol
X3DFIELDS$_$TSFROTATION_$__$$_SETVALUE$TGENERICVECTOR4 without index
value error

// where TSFRotation.Value is a property with record type, with getter
and setter methods

x3dcamerautils.pas(344,0) Error: Wasm32 symbol
X3DFIELDS$_$TX3DSIMPLEMULTFIELD$3$CRCD1E2ED59_CRCAB5A7799_$__$$_GETITEMS$$TSINGLELIST
without index value error

// where TX3DSimpleMultField.GetItems is a method of a generic class)

x3dcamerautils.pas(344,0) Error: Wasm32 symbol
X3DFIELDS$_$TSFFLOAT_$__$$_SETVALUE$SINGLE without index value error
x3dcamerautils.pas(344,0) Error: Wasm32 symbol

// where TSFFloat.SetValue is a simple setter for a Single property, no generics

castlescenecore.pas(8822,0) Error: Wasm32 symbol
CASTLESHAPEINTERNALSHADOWVOLUMES$_$TSHAPESHADOWVOLUMES_$__$$_PREPARERESOURCES
without index value error

// where TShapeShadowVolumes.PrepareResources is a simple method,
without any parameters, in a simple non-generic class

Weirder, on another machine, the symbols reported contain some exe
filenames at the place of initial "$_$" (maybe independent compiler
bug at message display?):

x3dloadinternalgeo.pas(234,0) Error: Wasm32 symbol
X3DFIELDS/usr/bin/dbus-update-activation-environmentTSFFLOAT_$__$$_SETVALUE$SINGLE
without index value error

x3dloadinternalgeo.pas(234) Error: Wasm32 symbol
X3DFIELDS/home/michalis/bin/castle-engineTSFFLOAT_$__$$_SETVALUE$SINGLE
without index value error

Sometimes the errors can be workarounded by some simple actions --
like moving the property getter/setter protected->private, or avoiding
the call to that particular method. But the solutions, as well as
causes, seem ~random from our perspective. And all in all, we didn't
finish the compilation of X3DNodes unit because after each
fix/workaround/hack for a specific case, another similar error pops
up.

Grepping FPC for the asmw_e_illegal_unset_index (this is "Wasm32
symbol $1 without index value error"), the error can occur when symbol
cannot be found in the list where compiler expected it to be.

We don't have any simple bugreport about it (yet), as the error really
manifests only in a big unit, that is interconnected with a few other
big units. Isolating the testcase (and/or doing much needed refactor
of this unit :) ) will take a while.

Does anyone have a hint:

- What does this error really mean? What is internally wrong at
compilation to cause it? What could be the culprit?

- Is there some universal workaround for it (on CGE side) or fix on
the compiler side?

Even a vague hint could at least help us prepare an isolated
bugreport, because otherwise we have a rather big chunk of code to
dissect in order to provide a simple FPC testcase :)


Even a big unit is fine for a bug report, as long as all the code is 
publicly available for download. If you can't seem to get it to 
reproduce with a small test case, you can mention in the bug report that 
you tried, but didn't succeed and still provide the full code needed. 
AFAIK, the Castle Game Engine is open-source, so this shouldn't be a 
problem?


Nikolay



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

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

Re: [fpc-devel] Sorting tests

[Nikolay Nikolov via fpc-devel]

On 11/30/22 08:30, Nikolay Nikolov wrote:


On 11/30/22 01:57, J. Gareth Moreton via fpc-devel wrote:
Familarity mostly.  More people are familiar with quicksort than 
introsort. Are there any explicit code examples where quicksort 
succeeds and introsort fails?  I'm told even Lazarus crashes (or used 
to crash), so I'll be interested to see what code causes (or caused) it.


IIRC, Lazarus had a comparison function that returned a

Sorry, I meant to say ahttps://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Sorting tests

[Nikolay Nikolov via fpc-devel]

On 11/30/22 01:57, J. Gareth Moreton via fpc-devel wrote:
Familarity mostly.  More people are familiar with quicksort than 
introsort. Are there any explicit code examples where quicksort 
succeeds and introsort fails?  I'm told even Lazarus crashes (or used 
to crash), so I'll be interested to see what code causes (or caused) it.


IIRC, Lazarus had a comparison function that returned acaused an infinite loop, not a crash. I don't remember the details, you 
should examine the source control history. The problem was fixed a long 
time ago in Lazarus, however it was decided not to change the default 
algorithm, but rather provide a plugable mechanism for changing the 
algorithm, hence the sortalgs unit provides several different options. 
FPC developers didn't want to have the bug tracker be filled with bug 
reports, caused by that (people would first assume it's a bug in the new 
FPC version if their code fails on a new FPC version, but works in the 
previous version).


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

Re: [fpc-devel] Sorting tests

[Nikolay Nikolov via fpc-devel]

On 11/29/22 22:16, J. Gareth Moreton via fpc-devel wrote:


On 29/11/2022 20:03, Nikolay Nikolov via fpc-devel wrote:

if (a

That's the big one that sorting algorithms rely on... the transitive 
law.  If that is violated, then you cannot guarantee a sorted result.


It doesn't matter if (a < b) or (b < a) return False for equal 
elements, or use (a <=b) or (b <= a) instead, as long as it's 
consistent.  Also have to watch out for more subtle instances of it, 
like "if (a < b) then DoX else DoY;" and then having "if (b < a) then 
DoZ else DoQ;".


While I do wish people would fix any bugs that are found in their own 
code, sometimes we do have to accept that this isn't always possible.  
I think the most famous example I can think of is with SimCity 2000... 
there was a critical bug in it where memory was used after it was 
deallocated.  Under DOS and Windows 3.1, this wasn't an issue because 
the memory wouldn't be reused by another application, but under 
Windows 95 this assumption could no longer hold.  So, under the 
guidance of Raymond Chen, Microsoft programmed Windows 95 to delay 
actually releasing that block of memory... only for SimCity 2000!


Yes. Horrible. :)

Another example is Quake 2 or 3 (I forgot which one) having a buffer 
overflow vulnerability, because of copying (strcpy) the OpenGL 
extensions string to a C fixed size buffer (char buf[1024] or something 
like that). After a certain point, OpenGL video cards became so advanced 
and got so many extensions, that the string, returned by the graphics 
card simply became too long for that buffer, thus causing Quake to crash 
instantly on startup. But since nobody wants to buy a video card, that 
doesn't run Quake, graphics card vendors had to implement a hack - the 
detect the Quake .exe and report a different, shorter, extensions string.


Nikolay



Kit

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

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

Re: [fpc-devel] Sorting tests

[Nikolay Nikolov via fpc-devel]

On 11/29/22 16:44, Ondrej Pokorny via fpc-devel wrote:

Am 29.11.2022 um 14:25 schrieb Sven Barth via fpc-devel:
For such a comparison function the issue is indeed in the comparison 
function, but Nikolay also mentioned "ais the case for equal elements.


I assume this was some kind of typo or reasoning error because 
"acompare function is correct. And Nikolay was talking about incorrect 
comparison functions.


Yes, I made a mistake, due to being in a hurry, while writing this 
email. I meant other properties, such as:


(a

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

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

Re: [fpc-devel] Sorting tests

[Nikolay Nikolov via fpc-devel]

On 11/24/22 20:51, J. Gareth Moreton via fpc-devel wrote:

Hi everyone,

I just need to touch on the knowledge base.  What tests exist that 
test the functionality of rtl/inc/sortbase.pp?  As Olly suggested, I'm 
looking at creating Introsort for this unit as well, but I need to 
know if such a unit already exists or if I need to make my own.


But IntroSort is already implemented in 
packages/rtl-extra/src/inc/sortalgs.pp. It's just not the default 
sorting algorithm, because it breaks existing code that implements an 
incorrect comparison function. E.g. if you pass a function that returns 
achange, when you change the algorithm. This even broke Lazarus, it 
caused it to hang on startup.


Best regards,

Nikolay



Also, since Olly mentioned that the unit is used in TStringList, it 
makes me wonder if the RTL has a radix sort algorithm available, since 
radix sort is on the order of O(n) and is ideal for sorting large 
arrays of strings (although it can be memory-intensive).


Kit

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

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

Re: [fpc-devel] Wasm/embedded target compilation error

[Nikolay Nikolov via fpc-devel]

On 7/22/22 01:36, Kostas Michalopoulos via fpc-devel wrote:

Hi all,

I was trying to use the Wasm/embedded target to port a game i made 
some time ago[0] to WebAssembly to run inside a browser, but i am 
getting a bunch of errors that i can't figure out the issue. When 
compiling with the embedded wasm assembler i get errors like:



SndEmit.pas(171) Error: Wasm32 symbol 
RESMAN/home/badsector/.local/bin/fpcTRESOURCEMANAGER_$__$$_GETRESOURCE$ANSISTRING$$TRESOURCE 
without index value error
SndEmit.pas(171) Error: Wasm32 symbol 
SNDDRV/home/badsector/.local/bin/fpcTSOUNDDRIVER_$__$$_SETCHANNELCLIP$LONGINT$TSOUNDCLIP$BYTE 
without index value error

(more errors)


However i'm not sure if it is the internal assembler issue because 
using, e.g. llvm-mc-12 i get other errors like:



./Engine/Misc.wat:7340:3: error: symbol 
MISC$_$TSTRINGKEYVALUESET_$__$$_INDEXOFKEY$ANSISTRING$$LONGINT missing 
.functype
    call 
MISC$_$TSTRINGKEYVALUESET_$__$$_INDEXOFKEY$ANSISTRING$$LONGINT

    ^
./Engine/Misc.wat:7670:3: error: symbol 
MISC$_$TSTRINGKEYVALUESET_$__$$_INDEXOFKEY$ANSISTRING$$LONGINT missing 
.functype
    call 
MISC$_$TSTRINGKEYVALUESET_$__$$_INDEXOFKEY$ANSISTRING$$LONGINT



Trying other assemblers i get other errors too, e.g. wabt/wasa 
displays a bunch of "stream read error" messages and then fails to link.


Does anyone have any idea about what is wrong?

This is running on Linux with a custom built crosscompiler from latest 
git (last commit is 6915cd9b269649ca945a4fc952ee7dedb1b38b85 - Thu Jul 
21 14:01:50).


I've stripped out the game's sources to only contain the units that i 
try to compile, you can get it and try to reproduce the issue from 
here (the archive is ~660KB):


http://runtimeterror.com/pages/badsector/nyan/gimme/papwasm.tar.xz

Just type ./makewasm.sh (the script uses -Awasm here but can be 
changed to try other assemblers). Note that obviously this wont build 
since it is missing any wasm-specific functionality since i never got 
to the point where the "cross platform" units compile properly to 
start writing the wasm-specific stuff.


Kostas

[0] https://bad-sector.itch.io/post-apocalyptic-petra


Hi, can you report in the FPC bugtracker, so it's not forgotten?

https://gitlab.com/freepascal.org/fpc/source/-/issues/new

Thanks,

Nikolay


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

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

Re: [fpc-devel] Questions about cross-compiling (z80)

[Nikolay Nikolov via fpc-devel]

On 2/11/22 19:14, Sven Barth via fpc-devel wrote:
Tomas Hajny via fpc-devel  schrieb am 
Fr., 11. Feb. 2022, 17:24:


On 2022-02-11 14:14, Sven Barth via fpc-devel wrote:
> BogDan via fpc-devel  schrieb am
Fr.,
> 11. Feb. 2022, 11:09:

  .
  .
>> It seems is an IHX format not tzx
>> Also the result for a simple hello world is way too big (over
20k) !
>> I assume that I'm passing wrong params to ppcrossz80. What params
>> should I use? Where I can find more info on this matter?
>
> You need to make sure that the ihxutil built in
> utils/ihxutil/-/ is available in PATH, so that the
> compiler will do the conversion.

@Sven: Sorry for a silly question, but shouldn't the compiler emit
some
error message if the tool isn't available?


It wasn't me who implemented it. But at least a warning or note might 
be good, cause the output *is* usable after all.


Added an error in:

https://gitlab.com/freepascal.org/fpc/source/-/commit/3c91a7c01ea16f5fc9239b21636d4127faacaf31

The error looks like this:

Free Pascal Compiler version 3.3.1 [2022/02/13] for z80
Copyright (c) 1993-2022 by Florian Klaempfl and others
Target OS: ZX Spectrum
Compiling hello.pas
Linking hello.tzx
hello.pas(4,1) Error: Util ihxutil not found, switching to external linking
hello.pas(4,1) Fatal: There were 1 errors compiling module, stopping
Fatal: Compilation aborted

Additionally, there's an extra message that the tool is being used, when 
you compile with -vt and the tool is found.


Nikolay



Regards,
Sven

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

Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC

[Nikolay Nikolov via fpc-devel]

On 1/15/22 01:47, Ben Grasset via fpc-devel wrote:
On Fri, Jan 14, 2022 at 5:49 AM Nikolay Nikolov via fpc-devel 
 wrote:


No, it's not, because in linux I tested "make -j24 all" in the
compiler directory

That isn't what you said in your original comment about benchmarking 
on Linux. You specified "make cycle", which is what I was going off of.


Yes, my mistake, I wrote it in a hurry. Here's exactly what I tested in 
linux:


make -j `nproc` clean OS_TARGET=linux CPU_TARGET=i386 BINUTILSPREFIX= 
PP=/usr/bin/ppcx64
make -j `nproc` all OS_TARGET=linux CPU_TARGET=i386 BINUTILSPREFIX= 
PP=/usr/bin/ppcx64


versus:

make -j `nproc` clean OS_TARGET=linux CPU_TARGET=x86_64 PP=/usr/bin/ppcx64
make -j `nproc` all OS_TARGET=linux CPU_TARGET=x86_64 PP=/usr/bin/ppcx64

And this is all run entirely on my SSD (Samsung SSD 860 EVO 500GB), 
while on Windows, the code I compile is on my HDD (the SSD only contains 
Windows, FPC and Lazarus).


Btw, a full testsuite run in Linux on my computer is also much faster on 
i386, compared to x86_64. But now I'm also in a hurry, so I won't post 
any exact measurements.


Nikolay___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC

[Nikolay Nikolov via fpc-devel]

On 1/14/22 06:45, Ben Grasset via fpc-devel wrote:
On Thu, Jan 13, 2022 at 11:38 PM Nikolay Nikolov via fpc-devel 
 wrote:


For the record, I did try make cycle for ppc386 and ppcx64 on my
Windows 10 (with Windows Defender turned on) and both finished in
exactly 42 seconds :)

Not surprising that you closed the gap a bit with your 5900X IMO, 
although that's still a decent improvement over both of your Linux 
results. I do think probably linking with GNU LD isn't as fast in most 
cases as linking internally, as I mentioned before. Though using LLD 
or mold instead of LD might be a different story.


No, it's not, because in linux I tested "make -j24 all" in the compiler 
directory, which also builds all the packages, textmode ide and 
utilities (and also does a parallel build), but in Windows I tested only 
"make cycle", like you did.


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

Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC

[Nikolay Nikolov via fpc-devel]

On 1/14/22 05:55, Ben Grasset via fpc-devel wrote:
On Thu, Jan 13, 2022 at 10:18 PM Nikolay Nikolov via fpc-devel 
 wrote:


Just for the record, is this with antivirus off or on and which
antivirus program?


I have no anti-virus actively installed or enabled on an ongoing basis 
at all. I just occasionally do manual scans with Malwarebytes and 
such. Beyond that, Windows is installed on a SATA SSD (Samsung 860 
Pro), and my RAM is 16GB DDR3-2400 CL10.


For the record, I did try make cycle for ppc386 and ppcx64 on my Windows 
10 (with Windows Defender turned on) and both finished in exactly 42 
seconds :)


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

Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC

[Nikolay Nikolov via fpc-devel]

On 1/14/22 03:18, Ben Grasset via fpc-devel wrote:
On Thu, Jan 13, 2022 at 11:28 AM Nikolay Nikolov via fpc-devel 
 wrote:


So, instead of giving actual benchmark data on the Windows
performance, you speculate by claiming that having faster
exception handling matters, and then you immediately debunk your
own argument by admitting it probably doesn't matter for the
compilation speed.

 I went ahead and tested "make cycle" for both ppcx64.exe and 
ppc386.exe, using PowerShell's "Measure Command" for timing as it's 
the most accurate method I'm aware of on Windows. Both results came in 
under one minute, and the 64-bit compiler /was /faster, though not by 
a large amount for that relatively short workload (I might test a full 
repo build later to see what the differences are like between longer 
compilations). This also would seem to show that what CPU you have 
basically stops mattering after a certain point as far as FPC's 
performance goes, as mine is MUCH slower than yours (i7-4790K clocked 
at 4.6GHz currently).


64-bit:

PS D:\fpclaz\FPCSource\compiler> Measure-Command {Start-Process make 
-ArgumentList "cycle PP=D:\fpclaz\fpc\bin\x86_64-win64\ppcx64.exe" -Wait}


Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 52
Milliseconds      : 815
Ticks             : 528157597
TotalDays         : 0.000611293515046296
TotalHours        : 0.014671044361
TotalMinutes      : 0.88026266167
TotalSeconds      : 52.8157597
TotalMilliseconds : 52815.7597

32-bit:

PS D:\fpclaz\fpcsource\compiler> Measure-Command {Start-Process make 
-ArgumentList "cycle PP=D:\fpclaz\fpc\bin\x86_64-win64\ppc386.exe" -Wait}


Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 56
Milliseconds      : 873
Ticks             : 568733659
TotalDays         : 0.000658256549768519
TotalHours        : 0.015798157194
TotalMinutes      : 0.94788943167
TotalSeconds      : 56.8733659
TotalMilliseconds : 56873.3659


Just for the record, is this with antivirus off or on and which 
antivirus program?


Also, I know my first benchmark was make cycle comparison between ppc386 
and ppcx64 under linux (and it showcased that 32-bit compilers can be 
much faster, when CPU is the bottleneck), but then I realized it can be 
an apples to oranges comparison, because ppc386 contains a very 
different code generator, it emits 32-bit code, instead of 64-bit code. 
That's why I tried compiling lazarus for win64 using ppcx64 and 
ppcrossx64. On my computer it turned out that ppcrossx64 was slightly 
faster, when antivirus is turned off. When antivirus is on, both became 
slower, with sometimes ppcrossx64 was slightly slower, but other times 
ppcx64 was still slower. It was less predictable with more random 
variance in performance, but it felt like ppcrossx64 was slightly slower 
on average with antivirus on. Another issue is that I/O turned out to be 
a huge bottleneck, even with enormous amounts of RAM for cache. For 
example, cleaning up the git repo between runs sends the deleted files 
to the recycle bin. I then emptied the recycle bin, before running the 
next build. However, skipping this recycle bin emptying resulted in a 
performance boost that was larger than the difference between ppcrossx64 
and ppcx64. So far, my preliminary conclusions are:


1) CPU is usually not a huge bottleneck when compiling with FPC under 
Windows


2) I/O is a huge bottleneck, even with large amounts of free RAM 
available for cache


3) Windows Defender is also a huge bottleneck and it appears to hurt 
startup of 32-bit programs more (perhaps there are more win32 viruses to 
scan for in exe files?). But it still hurts both win32 and win64 
programs. Turning it off during long compilations is almost always 
beneficial.


4) The compilation speed of ppcx64 and ppcrossx64 is comparable 
regardless of whether Windows Defender is on or off.


5) When CPU is the bottleneck (antivirus turned off), the 32-bit hosted 
compiler is faster. This still needs confirmation, though, because your 
results show 32-bit being slower, but you didn't say whether antivirus 
was off.


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

Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC

[Nikolay Nikolov via fpc-devel]

On 1/13/22 16:33, Nikolay Nikolov wrote:



On 1/13/22 10:58, Ben Grasset via fpc-devel wrote:


On Thu, Jan 13, 2022 at 1:58 AM Nikolay Nikolov via fpc-devel 
 wrote:


I haven't tested in Windows, but it would be very strange and
suspicious if the results are very different.

It would be neither of those things. The exception handling on x64 
Windows is the fastest provided by FPC, for example (though the 
compiler AFAIK avoids doing anything that would generate exception 
handling code within its own codebase as much as possible).


So, instead of giving actual benchmark data on the Windows 
performance, you speculate by claiming that having faster exception 
handling matters, and then you immediately debunk your own argument by 
admitting it probably doesn't matter for the compilation speed. Sure, 
using SSE2 is also faster, but it doesn't matter for the compilation 
speed at all, because all the performance critical parts are integer 
code, therefore it would be silly to give this as an argument as well. 
Sometimes 64-bit is faster (due to SSE2, AVX, exception handling, 
having more registers), sometimes 32-bit is faster (pointers are half 
the size, leading to less memory use, leading to less memory bandwidth 
requirements and more data fitting in the processor caches). Which is 
faster must always be determined by running some sort of benchmark, 
not by theoretical speculation. Rule number 1 of optimization is 
"never assume".


Ok, I did some testing in Windows 10 21H2 and the 32-bit crosscompiler 
was faster. I tested compiling lazarus for win64 from lazarus git, using 
FPC 3.2.2. The crosscompiler is the one that we ship, the native 
compiler is the one that is shipped with lazarus 2.2.0 for win64. I did 
not use multithreaded compilation, because "make -j24" didn't work with 
lazarus. Maybe the lazarus makefiles don't support that and I should use 
lazbuild, but I don't know how. I tested "make all", not "make bigide". 
Both the FPC 3.2.2 crosscompiler and the native compiler were on an SSD, 
on an NTFS filesystem, with NTFS compression enabled. The lazarus 
sources that I compiled were on a HDD (no space on my windows SSD 
partition, sorry), but I have 128GB RAM, most of which are free and used 
by Windows as cache. I did several runs and discarded the first result, 
to avoid the effect of HDD files not being in the cache. Before each 
run, I cleaned up with right click->TortoiseGit->Clean up...->Clean Type 
= "Remove all untracked files (-fx)"; + "Remove untracked directories 
(-d)". This was followed by emptying the recycle bin. I have the default 
Microsoft antivirus program Windows Defender installed and fully 
updated. I tested both with antivirus real-time protection enabled and 
disabled. All measurements were made using "Measure-Command" in 
PowerShell. Here are the best results for each case:


antivirus off:

ppcrossx64: 83.8517351 seconds

ppcx64: 85.0845576 seconds

with antivirus on there's a huge variance of speeds:

ppcrossx64: 90.3048706 seconds - 95.4332713 seconds

ppcx64: 86.8207751 seconds - 99.2315772 seconds.

There were some ppcx64 runs that were slightly faster with antivirus on, 
but there were also slower and they didn't converge to a single value 
after several runs, but retained their random variance. But with the 
antivirus off, the crosscompiler was clearly faster.


Any suggestions for testing multithreaded compilation of lazarus are 
welcome. I'll be happy to test that as well.


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

Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC

[Nikolay Nikolov via fpc-devel]

On 1/13/22 10:50, Ben Grasset via fpc-devel wrote:
On Thu, Jan 13, 2022 at 1:25 AM Nikolay Nikolov via fpc-devel 
 wrote:


We do care about scientific code as well as fast code, that's why
we support both the FPU and SSE2+ (as well as AVX, etc.).

FPC *chooses *not to generate x87 FPU instructions on 64-bit Windows 
solely because "it's deprecated". There's no actual technical 
limitation in play for user-mode code as far as the OS support for it 
goes.
What do other win64 compilers do? Do they generate x87 FPU code for 
64-bit Windows?


On Thu, Jan 13, 2022 at 1:25 AM Nikolay Nikolov via fpc-devel 
 wrote:


Floating point precision bugs, caused by loss of precision are
evil, because the code works most of the time during testing, but
they can still cause intermittent faults, which can be
catastrophic. Ariane 5 is a notable example.


I don't disagree with you, but you're missing my point, which is that 
there's trivial solutions for this other than mandating the use of an 
entirely 32-bit bit toolchain even for the common user who just wants 
to use a 64-bit toolchain to generate 64-bit applications on their own 
64-bit operating system.


Simply dropping a 32-bit copy of ppc386.exe into the bin folder of an 
otherwise all-64-bit FPC installation is all that's needed be able to 
build the 32-bit RTL and packages, and then start building 32-bit 
programs, for example.


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

Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC

[Nikolay Nikolov via fpc-devel]

On 1/13/22 10:58, Ben Grasset via fpc-devel wrote:


On Thu, Jan 13, 2022 at 1:58 AM Nikolay Nikolov via fpc-devel 
 wrote:


I haven't tested in Windows, but it would be very strange and
suspicious if the results are very different.

It would be neither of those things. The exception handling on x64 
Windows is the fastest provided by FPC, for example (though the 
compiler AFAIK avoids doing anything that would generate exception 
handling code within its own codebase as much as possible).


So, instead of giving actual benchmark data on the Windows performance, 
you speculate by claiming that having faster exception handling matters, 
and then you immediately debunk your own argument by admitting it 
probably doesn't matter for the compilation speed. Sure, using SSE2 is 
also faster, but it doesn't matter for the compilation speed at all, 
because all the performance critical parts are integer code, therefore 
it would be silly to give this as an argument as well. Sometimes 64-bit 
is faster (due to SSE2, AVX, exception handling, having more registers), 
sometimes 32-bit is faster (pointers are half the size, leading to less 
memory use, leading to less memory bandwidth requirements and more data 
fitting in the processor caches). Which is faster must always be 
determined by running some sort of benchmark, not by theoretical 
speculation. Rule number 1 of optimization is "never assume".


The fact that 32-bit x86 is sometimes faster is the reason why things 
like x86-32




On Thu, Jan 13, 2022 at 1:58 AM Nikolay Nikolov via fpc-devel 
 wrote:


A bug report with steps to reproduce would probably be nice.

That limit is a fundamental hardware limitation, not a bug.
We claim it's virtually impossible to exceed it in practice and we don't 
support a native win64 compiler, therefore it's a bug, if it's 
impossible to compile something with the 32-bit crosscompiler.
Not at all hard to imagine someone encountering it on 32-bit 
particularly if they're using Lazbuild for multi-threaded compilation.


Imagining something is one thing, whether it's possible to occur in 
practice is another.


Why would it matter whether you use lazbuild with multi-threaded 
compilation? Doesn't lazbuild start separate compiler processes? Every 
32-bit process gets a separate 4GB address space (meaning that each 
process has a different set of page tables, thus a different mapping of 
linear to physical memory addresses, this is a memory protection 
mechanism, that ensures that one process isn't able to destroy the 
memory of another process). In 64-bit operating systems (as well as 
32-bit, that use PAE, that is Physical Address Extension), each such set 
of page tables can map 32-bit linear memory pages to physical memory 
beyond the 4GB limit (with PAE it's a 32-bit to 36-bit mapping, in long 
mode it's a 32-bit to 64-bit mapping), therefore running multiple 32-bit 
processes at the same time can access more than 4GB in total, even 
though each process is limited to 4GB.


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

Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC

[Nikolay Nikolov via fpc-devel]

On 1/13/22 02:31, Ben Grasset via fpc-devel wrote:
On Wed, Jan 12, 2022 at 7:38 AM Martin Frb via fpc-devel 
 wrote:



The downloads provided by Lazarus are also NOT a "pure, native 64-bit
download". Only the "fpc.exe" and the non-cross "ppc64.exe" are
native
64 bit.

As I said, I do not know, what is currently provided by the Fpc
"combined 32-/64-bit download".
No Idea, if any of the fpc/ppc executable in this download are
already
64-bit.


Every single executable that actually originates from the FPC 
toolchain (so like `fpc.exe`, `ppcx64.exe`, `ppudump.exe`, 
`pas2js.exe`, `h2pas.exe`, and so on) contained in the current 
"lazarus-2.2.0-fpc-3.2.2-win64.exe" installer that the Lazarus website 
directs to when you click "Download Now" on a system running 64-bit 
Windows *IS* currently 64-bit. I just verified this myself. That 
particular installer does not include any cross compilers at all, also 
(the ones to target 32-bit Windows from 64-bit come in the smaller 
"lazarus-2.2.0-fpc-3.2.2-cross-i386-win32-win64.exe" installer.


On Wed, Jan 12, 2022 at 7:55 AM Tomas Hajny via fpc-devel 
 wrote:


Wrong - applies only to the Win64 target, whereas e.g. 64-bit Linux
(supported by the same compiler targetting 64-bit code) supports
extended. This means that compiling source code with this compiler may
result in a different binary as soon as there's e.g. an extended
contstant included in the source code, or any compile-time
calculations
in this precision need to be performed.


Isn't this specifically the kind of thing that the `FPC_SOFT_FPUX80` 
define solves? FPC does not even let you go from 64-bit Windows to 
32-bit targets if that define isn't active IIRC, so presumably the 
same thing could be made the case in other scenarios if it's something 
people are widely concerned about.


In any case, people who want native 64-bit Windows toolchains want 
them pretty much exclusively for use /on /64-bit Windows to /target/ 
64-bit Windows, and will install any cross-compilers secondarily /if 
/they have a use for them. The 32-bit-to-64-bit Windows FPC toolchain 
is /not /a perfect drop-in replacement. Based on testing I did locally 
previously, it's not as fast as the native 64-bit one,


Really? Are you sure, because I just tested make cycle on Linux and the 
results are:


i386:

real    1m1.032s
user    0m53.194s
sys    0m5.572s

x86_64:

real    1m32.651s
user    1m21.486s
sys    0m9.414s

So, the 64-bit compiler is 50% slower. This is on an AMD Ryzen 9 5900X 
12-core processor, 128 GB RAM and an SSD.


I haven't tested in Windows, but it would be very strange and suspicious 
if the results are very different. I would double check if that's really 
the case and also try some things, like disabling any antivirus programs 
that might be slowing down your computer by scanning every exe file, 
produced by the compiler.


and additionally there are other things to keep in mind like the 4GB 
RAM limit on 32-bit (which I have in fact seen more than one user on 
the Lazarus forums run into with larger projects, none of whom were 
using the 32-bit executables "on purpose").


A bug report with steps to reproduce would probably be nice.

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

Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC

[Nikolay Nikolov via fpc-devel]

On 1/13/22 07:44, Ben Grasset via fpc-devel wrote:

It does work on 64-bit Windows, it's just technically deprecated.

Beyond that, the 80-bit Extended type dates back to the mid 1980s,
The year 1980, not the mid 1980s. But the x86 family dates back to 1978. 
Most x86_64 instructions are the same as the ones, introduced in 1978, 
but with an added prefix to indicate they're 64-bit.
and ran on a particular part of the processor (the FPU, or Floating 
Point Unit),


Ran on an optional separate coprocessor chip, called Intel 8087. It was 
succeeded by 80187, 80287, 80387 and 80487. It was actually integrated 
into the CPU with the 486DX CPU, but the 486SX had no FPU (in fact, it 
was disabled). And the 487 was actually a 486DX in a different socket, 
that took full control of the system as soon as it was installed, while 
the 486SX on the motherboard was switched off.


The Pentium was the first CPU that always had the FPU integrated.

in such a way that it was able to provide a somewhat higher amount of 
precision than the 64-bit "Double" type that's most commonly used 
today. That said, the operations involved generally weren't / aren't 
nearly as efficient as the vector based SSE2+ ones used for 32-bit and 
64-bit floats. So it fell out of favor for most use cases, outside of 
certain things like scientific code that actually needs the highest 
amount of precision possible even at the detriment of efficiency.


We do care about scientific code as well as fast code, that's why we 
support both the FPU and SSE2+ (as well as AVX, etc.).




I'd personally argue that anyone writing code today that actually 
needs true 80-bit extended already certainly is likely to know what 
they're doing as far as tooling, thus meaning the majority of users 
are fairly unlikely to ever encounter any problems that directly 
relate to it.
Floating point precision bugs, caused by loss of precision are evil, 
because the code works most of the time during testing, but they can 
still cause intermittent faults, which can be catastrophic. Ariane 5 is 
a notable example.


On Wed, Jan 12, 2022 at 11:08 PM Travis Siegel via fpc-devel 
 wrote:



On 1/12/2022 5:20 PM, Sven Barth via fpc-devel wrote:

When compiling from a target supporting Extended to one only
supporting Double there isn't a loss of precision when
calculating values at compile time. The other way around however,
there *is* and that is the more crucial problem.

Regards,
Sven


/I understand only part of this issue.  64-bit windows doesn't
have extended support, is there a reason for this? If it's simply
processors, and it works on linux, why does it not work on windows?/

/Also, since it's 64-bit, wouldn't a double on a 64-bit system
match or exceed the numeric range on an extended range for a
32-bit system?/

/I'm no expert on compiler numeric ranges, and 32/64 ranges aren't
something I've studied a whole lot of, other than to note that
64-bit processors can handle *much* larger numbers, so I don't
understand why this problem exists./

/Is there a summary of why this is a problem anywhere I can refer
to so I can understand why this happens, and what (if anything)
can be done to solve it?/

/I've always been fascinated by compilers, though I've never
actually written anything except an assembler for dos several
years ago, I was never able to extend that to other languages,
because of lack of knowledge of how the cpu does things, but this
is still an interesting topic for me, and I honestly can't figure
out why there would be an issue at all./

/I'm not doubting there is one, I'm just missing a piece or two to
understand it./

/Any help would be appreciated.
/

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


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

Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC

[Nikolay Nikolov via fpc-devel]

On 1/13/22 05:59, Travis Siegel via fpc-devel wrote:



On 1/12/2022 5:20 PM, Sven Barth via fpc-devel wrote:
When compiling from a target supporting Extended to one only 
supporting Double there isn't a loss of precision when calculating 
values at compile time. The other way around however, there *is* and 
that is the more crucial problem.


Regards,
Sven

/I understand only part of this issue.  64-bit windows doesn't have 
extended support, is there a reason for this? If it's simply 
processors, and it works on linux, why does it not work on windows?/


/Also, since it's 64-bit, wouldn't a double on a 64-bit system match 
or exceed the numeric range on an extended range for a 32-bit system?/


/I'm no expert on compiler numeric ranges, and 32/64 ranges aren't 
something I've studied a whole lot of, other than to note that 64-bit 
processors can handle *much* larger numbers, so I don't understand why 
this problem exists./


/Is there a summary of why this is a problem anywhere I can refer to 
so I can understand why this happens, and what (if anything) can be 
done to solve it?/


/I've always been fascinated by compilers, though I've never actually 
written anything except an assembler for dos several years ago, I was 
never able to extend that to other languages, because of lack of 
knowledge of how the cpu does things, but this is still an interesting 
topic for me, and I honestly can't figure out why there would be an 
issue at all./


/I'm not doubting there is one, I'm just missing a piece or two to 
understand it./


/Any help would be appreciated.
/

The i386 compiler uses the x87 FPU for floating point. The x87 supports 
the 32-bit single precision floating point type, the 64-bit double 
precision floating point type and the 80-bit extended precision extended 
floating point type. So, the best precision you get is 80-bit.


The x86_64 compiler uses SSE2 instructions for floating point. However, 
the SSE2 instructions only support 32-bit and 64-bit float types.


X86_64 processors still have the FPU, and it still functions in 64-bit 
mode, so the x86_64 compiler can still use the FPU for the 80-bit 
extended type. In fact, this is why the linux x86_64 compiler works 
without limitations. However, Windows doesn't guarantee future 
compatibility if the FPU is used.


https://docs.microsoft.com/en-us/windows/win32/dxtecharts/sixty-four-bit-programming-for-game-developers?redirectedfrom=MSDN#Porting_to_64bit

Quote:

"The x87, MMX, and 3DNow! instruction sets are deprecated in 64-bit 
modes. The instructions sets are still present for backward 
compatibility for 32-bit mode; however, to avoid compatibility issues in 
the future, their use in current and future projects is discouraged."


A logical question that follows is how can they break it in future 
Windows versions, if it's supported by the CPU. The answer is, since 
Windows is a multitasking operating system, they might stop saving the 
FPU registers when switching between 64-bit tasks. So, the only 
guarantee that x87 FPU code will continue to work in future Windows 
versions is if it's in a 32-bit process.


It kinda sucks, but it is what it is. Microsoft have decided that the 
FPU is considered "legacy" and "deprecated". However, the replacement 
(SSE2) doesn't have all the capabilities that the FPU has, namely it 
doesn't have 80-bit extended precision. I guess, you can complain to 
Microsoft about that and not to Free Pascal developers, but I doubt that 
they will care. :)



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

Re: [fpc-devel] Discussion on a particular optimisation development (WARNING: Technical!)

[Nikolay Nikolov via fpc-devel]

On 2/2/21 11:06 PM, J. Gareth Moreton via fpc-devel wrote:

Hi everyone,

I've found a potential optimisation for conditions of the form "(x <> 
0) and (y <> 0)", which are very common because this is semantically 
equivalent to "Assigned(x) and Assigned(y)", for example, and such a 
construct is generated implicity in TObject.Destroy, for example.  The 
node tree for TObject.Destroy example (after the first pass) is as 
follows (it checks the value of Self and VMT):


The node tree inside the if-node's condition branch is as follows:

complexity="3">
   complexity="1">
  complexity="0">

 self
  
  complexity="0">

  
   
   complexity="1">
  flags="nf_pass1_done,nf_explicit,nf_internal" complexity="0" 
convtype="tc_equal">
 flags="nf_pass1_done" complexity="0" convtype="tc_equal">
    flags="nf_pass1_done" complexity="0">

   vmt
    
 
  
  flags="nf_pass1_done,nf_explicit" complexity="0">

 $
  
   


On x86-64_win64, the following assembly language is generated (smart 
pipelining and out-of-order execution MIGHT permit it to be executed 
in 3 cycles, but it's more likely going to take 4 or 5):


    testq    %rbx,%rbx
    setneb   %al
    testq    %rsi,%rsi
    setneb   %dl
    andb     %dl,%al

DeMorgan's Laws for 2 inputs state that "not (A or B) = not A and not 
B", and "not (A and B) = not A or not B", and using these, we can 
develop much more efficient assembly language (which will almost 
certainly take 3 cycles to run, and is much smaller):


    movq     %rbx,%rdx
    orq  %rsi,%rdx
    seteb    %al

For this particular routine, %rsi and %dl/%rdx are not used 
afterwards, and can be simplified further (this bit will probably be a 
peephole optimisation), dropping the cycle count to 2:


    orq  %rbx,%rsi
    seteb    %al

In this situation it is safe because the comparison values are already 
in registers and code generation has permitted the bypassing of 
Boolean short-circuiting.


Rather than write an entire peephole optimisation, I would ideally 
like to program this optimisation at the nodal level, and permit the 
compiler to convert it into something resembing the following ("andn" 
becomes "notn" -> "orn", and the two "unequaln" nodes become "equaln"):


complexity="3">
   complexity="3">
      complexity="1">
         complexity="0">

        self
         
         complexity="0">

         
      
      complexity="1">
         flags="nf_pass1_done,nf_explicit,nf_internal" complexity="0" 
convtype="tc_equal">
        flags="nf_pass1_done" complexity="0" convtype="tc_equal">
           flags="nf_pass1_done" complexity="0">

          vmt
           
            
         
         flags="nf_pass1_done,nf_explicit" complexity="0">

        $
         
      
   


...but there is a catch.  In terms of the raw nodes, converting the 
"andn" node into a "notn" and an "orn" node results in a more complex 
node tree and hence less efficient assembly language in general, 
unless a particular "pass_generate_code" routine knows to look out for 
the set-up of a logical "or" that combines two variables' comparison 
against zero, like that shown above.


My question is... how should it be developed so that the node 
optimisation is performed on platforms that have the necessary 
assembly instructions, like x86_64 and AArch64 (once I develop them), 
but also not perform the optimisation on platforms that don't have the 
necessary instructions or checks in "pass_generate_code"?  Allowing 
the optimisation wouldn't cause bad code generation, but it would be 
more inefficient in the general case.


I hope I explained that okay.


You can introduce a new pass in the compiler, that does the node 
transformation only on platforms that benefit from it. See e.g. what I 
did a few years ago in optloadmodifystore.pas in the compiler sources. 
This is an optimization that introduces new nodes that generate faster 
code on x86 for patterns, such as:


a := a + b

Which can be done with a single 'add mem, const' or 'add mem, reg' 
instruction on all processors in the x86 family (i8086, i386 and 
x86_64). Also, I think there were other CPUs that benefit from this 
optimization (m68k?). For that, I introduced new inline compiler nodes, 
that are only used for this optimization.




(Other possibilities include introducing new node types "norn" and 
"nandn" (and maybe "nxorn" to complete the set), and having the "andn" 
node above be converted into "norn", so that they can be instantly 
converted into the relevant assembly instructions instead of relying 
on multiple steps of optimistion)


Introducing norn and nand for optimization purposes might not be a bad 
idea, considering there are some CPU architectures that also have nor 
and nand instructions (powerpc, for example).


Best regards,

Nikolay

P.S. I don't think we need "WARNING: Technical!" 

Re: [fpc-devel] x86_64 question

[Nikolay Nikolov via fpc-devel]

On 10/4/20 2:01 PM, J. Gareth Moreton via fpc-devel wrote:

Hi Nikolay,

I've got some good code to test, but I need to double-check with 
someone to see if the licensing agreements allow (the code is rather 
complex, but showcases the effect of the TEST instructions quite nicely).


Is your platform a Windows or a Unix machine?  I ask because I don't 
want to send you functions that use the wrong calling convention!


I dual boot Linux and Windows, but prefer testing on Linux.

Best regards,


Nikolay



Gareth aka. Kit

On 02/10/2020 14:13, Nikolay Nikolov via fpc-devel wrote:


On 10/2/20 2:13 PM, J. Gareth Moreton via fpc-devel wrote:
Confirmed my suspicions.  if I zero the upper bits of the register 
(I used something akin to "AND RCX, $F"), there is no speed loss.


Therefore, I can make the hypothesis, on my Intel(R) Core(TM) 
i7-10750H, that using TEST on a sub-register causes a false 
dependency if the bits outside of the subset are not zero, even 
though the register isn't being modified.


If you send me a test program, I can run it on my Ryzen 5 2500U to 
see how AMD behaves. We don't specifically optimize for AMD (yet), 
but it's interesting to know.


Nikolay



Gareth aka. Kit

On 02/10/2020 11:57, J. Gareth Moreton via fpc-devel wrote:
So... I've done some tests, replacing TEST RCX, $4 with TEST CL, $4 
and the like in a number-crunching function, and it seems to cause 
a notable penalty, even though none of the instructions are in my 
critical loop.  So I think it's something that needs to be avoided 
in most cases.  I think the reason why it worked in my Int and Frac 
functions is because the processor knows the upper 48 bits of the 
register are zero.


Long story short... best not to do it unless you have some 
additional insight into what the registers contain.


Gareth aka. Kit



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




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

Re: [fpc-devel] x86_64 question

[Nikolay Nikolov via fpc-devel]

On 10/2/20 2:13 PM, J. Gareth Moreton via fpc-devel wrote:
Confirmed my suspicions.  if I zero the upper bits of the register (I 
used something akin to "AND RCX, $F"), there is no speed loss.


Therefore, I can make the hypothesis, on my Intel(R) Core(TM) 
i7-10750H, that using TEST on a sub-register causes a false dependency 
if the bits outside of the subset are not zero, even though the 
register isn't being modified.


If you send me a test program, I can run it on my Ryzen 5 2500U to see 
how AMD behaves. We don't specifically optimize for AMD (yet), but it's 
interesting to know.


Nikolay



Gareth aka. Kit

On 02/10/2020 11:57, J. Gareth Moreton via fpc-devel wrote:
So... I've done some tests, replacing TEST RCX, $4 with TEST CL, $4 
and the like in a number-crunching function, and it seems to cause a 
notable penalty, even though none of the instructions are in my 
critical loop.  So I think it's something that needs to be avoided in 
most cases.  I think the reason why it worked in my Int and Frac 
functions is because the processor knows the upper 48 bits of the 
register are zero.


Long story short... best not to do it unless you have some additional 
insight into what the registers contain.


Gareth aka. Kit



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

Re: [fpc-devel] x86_64 question

[Nikolay Nikolov via fpc-devel]

On 10/1/20 11:36 PM, J. Gareth Moreton via fpc-devel wrote:
I thought that might be the case - thanks Nikolay.  And I meant to say 
lower bits of a REGISTER, not an instruction!


Admittedly I'm cycle-counting and byte-counting again!  I was looking 
for ways to reduce 13 bytes of padding in one of my pure assembly 
language routines and realised I could make a saving there.  The only 
thing I can think of that I have to watch out for logically is if I 
change, say, TEST EAX, $80 to TEST AL, $80, the latter will set the 
sign flag if the most-significant bit is 1 after the 'and' operation) 
while the former always clears the sign flag.


I have used such subregisters before in the FPC RTL, in fpc_int_real 
and fpc_frac_real in rtl/x86_64/math.inc, where I read AX instead of 
the larger RAX, but that's only after a call to "SHR RAX, 48" that 
guarantees that everything above the 16th bit is zero, and after 
testing other implementation candidates a kind of informal 
competition. (Surprisingly, I think "shr $48, %rax; and $0x7ff0,%ax; 
cmp $0x4330,%ax" runs faster than moving 64-bit constants into 
temporary registers (since 64-bit immediates aren't supported outside 
of MOV) and using 'and' and 'cmp' on %rax directly)


I think you always get a read penalty when using the high-byte 
registers because the processor has to do an implicit shift operation.


I don't remember the reason, but I recall reading they are less 
efficient in Agner Fog's optimization manual. Here's the relevant quote:


"Any use of the high 8-bit registers AH, BH, CH, DH should be avoided 
because it can cause false dependences and less efficient code."


It's from the chapter "Partial registers" (page 61) of this document:

https://www.agner.org/optimize/optimizing_assembly.pdf

Highly recommended reading, as it addresses exactly the topic of partial 
registers. In general, it is the partial register writes of 16-bit or 
8-bit subregisters that cause problems - either false read dependencies 
(usually on AMD) or extra penalties for joining/splitting registers (on 
Intel, at least in the P6 era).


Best regards,

Nikolay

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

Re: [fpc-devel] x86_64 question

[Nikolay Nikolov via fpc-devel]

On 10/1/20 8:17 PM, J. Gareth Moreton via fpc-devel wrote:

Hi everyone,

I have a small question with assembler size optimisation that maybe 
one of you guys can give me a second opinion on:


If you are using the "test" instruction to test some of the lower bits 
of an instruction, e.g. TEST RCX, $2, is there a penalty with calling 
TEST CL, $2 instead? The instruction size is a lot smaller on account 
of the immediate only being 1 byte long instead of 4 bytes, and are 
mathematically equivalent.  I know you have to be careful with partial 
write penalties, but partial reads seem to be a bit more nebulous (the 
register is not modified with TEST).


Yes, I think the shorter TEST CL, $2 is preferred over TEST RCX, $2 on 
every x86_64 CPU. AFAIK, there's no penalty for using 8-bit subregisters 
(except perhaps AH, BH, CH and DH, but the FPC code generator doesn't 
use them). Others can correct me if I'm wrong.


Nikolay

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

Re: [fpc-devel] Another thread about the fact that official FPC releases are *unnecessarily* non-representative of the platforms it actually runs on

[Nikolay Nikolov via fpc-devel]

On 9/28/20 10:01 PM, Bart via fpc-devel wrote:

On Mon, Sep 28, 2020 at 3:45 PM Nikolay Nikolov via fpc-devel
 wrote:


compile to win32 via:

fpc -Pi386 hello.pas

AFAIK a simple fpc hello.pas will do in that setup.

Yes, that is true. The -Pi386 is optional in this case.




and to win64 via:

fpc -Px86_64 hello.pas

Doesn't that need a -TWin64 as well?


It's not needed - Win64 is the default target of the windows-hosted 
x86_64 crosscompiler. But it doesn't hurt if you add it.


Best regards,

Nikolay


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

Re: [fpc-devel] Another thread about the fact that official FPC releases are *unnecessarily* non-representative of the platforms it actually runs on

[Nikolay Nikolov via fpc-devel]

On 9/28/20 12:24 AM, Travis Siegel via fpc-devel wrote:


How does one get a 64-bit version on windows.  When I try to run a 
64-bit version on windows, I encounter an error, though I don't 
remember what that error is, since I've not tried it for a couple 
weeks.  I didn't even know there was a 64-bit windows version, because 
as mentioned below, linking to the 64-bit version on the website links 
to a 32-bit version.  Admittedly, I'm no fan of windows, and honestly, 
I hate that I'm forced to use it for my everyday work, I'd much rather 
use linux/macos, but at the moment, that's not an option, though I was 
windows free for over 10 years at one point, that sadly has changed 
over the past 5 years. 


But, in any case, if there's a way to get 64-bit versions on windows, 
I'd like to know how.


If you want to target Win64, using official FPC releases, you should 
download two packages:


fpc-3.2.0.i386-win32.exe

fpc-3.2.0.i386-win32.cross.x86_64-win64.exe


Install the first one, then the second one (it's an add-on package that 
adds win64 target support to the 32-bit compiler). After that you can 
compile to win32 via:


fpc -Pi386 hello.pas

and to win64 via:

fpc -Px86_64 hello.pas

The two install packages will be combined into one starting with FPC 
3.2.2, so it will be a single download.



Lazarus provides a native win64-hosted win64-targeting FPC, but I don't 
use it, because of the 80-bit floating point issues. That's why I don't 
recommend it. I prefer to install these two:


lazarus-2.0.10-fpc-3.2.0-win32.exe

lazarus-2.0.10-fpc-3.2.0-cross-x86_64-win64-win32.exe


This allows me to target both win32 and win64. I don't know if there's 
any downside to using these instead of the win64 version of Lazarus. 
Disclaimer: I don't write GUI apps, so I don't use the LCL.



Best regards,

Nikolay

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

Re: [fpc-devel] Another thread about the fact that official FPC releases are *unnecessarily* non-representative of the platforms it actually runs on

[Nikolay Nikolov via fpc-devel]

On 9/28/20 12:30 AM, Tomas Hajny via fpc-devel wrote:

On 2020-09-27 18:27, Nikolay Nikolov via fpc-devel wrote:

On 9/27/20 7:21 PM, Florian Klämpfl via fpc-devel wrote:

Am 27.09.20 um 18:03 schrieb Martin Frb via fpc-devel:

On 27/09/2020 09:34, Sven Barth via fpc-devel wrote:
Ben Grasset via fpc-devel <mailto:fpc-devel@lists.freepascal.org>> schrieb am So., 27. Sep. 
2020, 07:50:


    That last quote is absolute BS, to be very frank. There is no
    reason whatsoever not to use a natively-64-bit copy of FPC if
    running a natively-64-bit copy of Windows, and there hasn't been
    for well over half a decade at this point.


Yes, there is a reason: you can not build a i8086 or i386 cross 
compiler with the Win64 compiler (or any non-x86 compiler to be 
fair) due to missing Extended support. Thus the majority of the 
FPC Core team considers the Win64 compiler as inferior and also 
unnecessary cause the 32-bit one works just as well on that platform.



Just my 2 cents.

Well, one the one hand, native 64 bit is only really important if 
it can do something that 32 bit can not do. (faster, bigger 
sources, ).


On the other hand, not everyone needs a win64 to win32 cross 
compiler. And if they do, a native 32bit compiler can be renamed 
and will happily serve as such a cross compiler. (But that is not a 
must be included / such workarounds may not be wanted, especially 
since they might cause repeated extra work)


So the question here is/are imho about the work it takes to amend 
the release-build process (i.e. update the scripts). And then the 
amount of extra time needed for each release (build and testing).


The thing is: we would distribute a compiler (the x86_64-win64 one) 
which claims to be able to compile to e.g. to x86_64-linux, but it 
would generate programs which might behave differently than natively 
compiled ones as float constants are handled internally different.


And in this particular case, "different" means "less accurate", due to
rounding errors, caused by compile time conversion of 80-bit extended
float constants to 64-bit double precision constants. And "less
accurate" is bad. :)


Sorry for a silly question, but is it really the case that a higher 
precision is good (or that it doesn't matter at least)? I assume that 
performing compile-time calculations in higher precision than 
calculations performed at run-time may still result in differences 
and, in spite of the fact that the calculations are more precise, the 
differences may still lead to confusion of our users (if not something 
worse) - especially if it may not be always clear which part will be 
computed at compile-time and which part at run-time. Is my 
understanding correct? Or is there some solution allowing to achieve 
specific precision with a higher precision library?


I don't have an exact answer, but I think higher precision is better, 
compared to lower. You can not expect bitwise identical result, when 
using floating point calculations anyway. For example AMD and Intel FPUs 
perform calculations with some very slight variations, so the same 
calculation doesn't always result in the same bitwise identical floating 
point number, even though, they're practically really close, so it 
doesn't matter. I don't know of any program that breaks e.g. on AMD 
FPUs, because it was designed for Intel or vice versa.


In theory this matters, if we implement 128-bit soft float support in 
the compiler, or if we encounter an FPU that supports 128-bit floating 
point. The question is whether it's safe to implement 80-bit x87 FPU 
floating point support on host targets with 128-bit FPU support. I think 
it's safe, but I'm not an expert on floating point.


But compile time calculations having a lower precision, compared to the 
runtime precision is definitely bad.


Nikolay

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

Re: [fpc-devel] Another thread about the fact that official FPC releases are *unnecessarily* non-representative of the platforms it actually runs on

[Nikolay Nikolov via fpc-devel]

On 9/27/20 7:21 PM, Florian Klämpfl via fpc-devel wrote:

Am 27.09.20 um 18:03 schrieb Martin Frb via fpc-devel:

On 27/09/2020 09:34, Sven Barth via fpc-devel wrote:
Ben Grasset via fpc-devel > schrieb am So., 27. Sep. 
2020, 07:50:


    That last quote is absolute BS, to be very frank. There is no
    reason whatsoever not to use a natively-64-bit copy of FPC if
    running a natively-64-bit copy of Windows, and there hasn't been
    for well over half a decade at this point.


Yes, there is a reason: you can not build a i8086 or i386 cross 
compiler with the Win64 compiler (or any non-x86 compiler to be 
fair) due to missing Extended support. Thus the majority of the FPC 
Core team considers the Win64 compiler as inferior and also 
unnecessary cause the 32-bit one works just as well on that platform.



Just my 2 cents.

Well, one the one hand, native 64 bit is only really important if it 
can do something that 32 bit can not do. (faster, bigger sources, ).


On the other hand, not everyone needs a win64 to win32 cross 
compiler. And if they do, a native 32bit compiler can be renamed and 
will happily serve as such a cross compiler. (But that is not a must 
be included / such workarounds may not be wanted, especially since 
they might cause repeated extra work)


So the question here is/are imho about the work it takes to amend the 
release-build process (i.e. update the scripts). And then the amount 
of extra time needed for each release (build and testing).


The thing is: we would distribute a compiler (the x86_64-win64 one) 
which claims to be able to compile to e.g. to x86_64-linux, but it 
would generate programs which might behave differently than natively 
compiled ones as float constants are handled internally different.


And in this particular case, "different" means "less accurate", due to 
rounding errors, caused by compile time conversion of 80-bit extended 
float constants to 64-bit double precision constants. And "less 
accurate" is bad. :)


Nikolay

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

Re: [fpc-devel] Another thread about the fact that official FPC releases are *unnecessarily* non-representative of the platforms it actually runs on

[Nikolay Nikolov via fpc-devel]

On 9/27/20 7:03 PM, Martin Frb via fpc-devel wrote:

On 27/09/2020 09:34, Sven Barth via fpc-devel wrote:
Ben Grasset via fpc-devel > schrieb am So., 27. Sep. 
2020, 07:50:


That last quote is absolute BS, to be very frank. There is no
reason whatsoever not to use a natively-64-bit copy of FPC if
running a natively-64-bit copy of Windows, and there hasn't been
for well over half a decade at this point.


Yes, there is a reason: you can not build a i8086 or i386 cross 
compiler with the Win64 compiler (or any non-x86 compiler to be fair) 
due to missing Extended support. Thus the majority of the FPC Core 
team considers the Win64 compiler as inferior and also unnecessary 
cause the 32-bit one works just as well on that platform.



Just my 2 cents.

Well, one the one hand, native 64 bit is only really important if it 
can do something that 32 bit can not do. (faster, bigger sources, ).
There's no known advantage of using a native win64 compiler, versus the 
win32 to win64 crosscompiler. There could be, if, while compiling very 
large programs, the 32-bit address space the compiler uses during 
compilation was exhausted (i.e. if the memory used by the compiler 
during compilation exceeds 4GB), and this happens AFAIK in C compilers, 
but, as far as we know, it just doesn't happen with FPC, because we 
don't use that much memory.


On the other hand, not everyone needs a win64 to win32 cross compiler. 
And if they do, a native 32bit compiler can be renamed and will 
happily serve as such a cross compiler. (But that is not a must be 
included / such workarounds may not be wanted, especially since they 
might cause repeated extra work)


A win64 to win32 crosscompiler is crippled, because it doesn't support 
80-bit extended float. That's why only a native win32 compiler is used 
to target win32.


Nikolay

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

Re: [fpc-devel] Another thread about the fact that official FPC releases are *unnecessarily* non-representative of the platforms it actually runs on

[Nikolay Nikolov via fpc-devel]

On 9/27/20 10:48 AM, Florian Klämpfl via fpc-devel wrote:

As long as there is no generic 80 bit float support in the compiler, there is 
no need to discuss anything else.


Yes. And unlike some other compilers, we don't exhaust our 32-bit 
address space during compilation or linking of very large programs, so 
the fact that it is a cross-compiler should be irrelevant to the user.


Regarding ease of installation, we're planning to release the Windows 
version of FPC 3.2.2 as a single install package, that supports both 
32-bit and 64-bit Windows - it will include the 32-bit native and 32-bit 
to 64-bit crosscompiler, so it will be a single download for both Win32 
and Win64.


The necessary changes for the that are already committed to trunk, but 
it will need testing during the beta and release candidate phases.


Nikolay

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

Re: [fpc-devel] Object upgrades

[Nikolay Nikolov]

On 5/27/19 1:08 AM, Ryan Joseph wrote:

Records don’t have a VMT table and overriding but otherwise they’re the same 
afaik (constructors don’t work the same also). Operator overloads simply aren’t 
enabled for objects because apparently they’re a legacy syntax but as you 
pointed out they’re still useful.


Are you sure about the operator overloads? I'm pretty sure I've used 
them on objects since FPC 1.0.x (even before that) and they've always 
worked fine. They are also used by some of the PTCPas example programs, 
which are shipped with FPC and also work fine. I even tested it again 
with a trivial example. Here it is: It works with FPC 3.0.4 and almost 
certainly FPC trunk as well:


type
  TMyObject = object
  end;

operator + (a, b: TMyObject) res: TMyObject;
begin
  Writeln('Plus operator! yeah!');
end;

var
  a, b, c: TMyObject;
begin
  c := a + b;
end.

So, what's with all this FUD surrounding operator overloading not 
working with objects? Did you even test it, before screaming "legacy!"? :)


Nikolay

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

Re: [fpc-devel] New sorting routines

[Nikolay Nikolov]

On 2/3/19 11:22 PM, C Western wrote:
I suspect the new sorting routines need some work - lazarus compiled 
with the latest trunk hangs on start up, and it looks like an infinite 
loop in sorting. Stack trace below.


Even though the sort routine did slightly change, I believe this exposes 
a bug in lazarus. The CompareBinary routine in syneditmarkuphighall.pp 
returns -1 when the strings are equal, while it should return 0 in this 
case. This is like having two elements in the array, for which (a(bthe sort algorithms must satisfy the mathematical properties of 
comparisons, otherwise the result is undefined (whether it should 
results in a hang (like in this case), or in a bad sort (like in the 
previous variation of the algorithm) is a separate discussion).


The attached patch fixes this.



Colin

#0  0x00422167 in DECLOCKED (L=2) at ../x86_64/x86_64.inc:709
#1  0x0042c325 in fpc_ansistr_decr_ref (S=0x2)
    at ../inc/astrings.inc:148
#2  0xfffa in  ()
#3  0x00e8d67b in COMPAREBINARY (LIST=0x7fffdf4f5f00, 
INDEX1=6, INDEX2=

    7) at syneditmarkuphighall.pp:807
#4  0x0053abf6 in TSTRINGLIST_CUSTOMSORT_COMPARER (ITEM1=
    0x7fffded60e88, ITEM2=0x1, CONTEXT=0x1b18e80)
    at ../objpas/classes/stringl.inc:1642
#5  0x01b63530 in TC_$SORTBASE_$$_QUICKSORT ()
#6  0x00558b60 in QUICKSORT (parentfp=0x7fffc740, L=2, R=7)
    at ../inc/sortbase.pp:182
#7  0x7fffc740 in  ()
#8  0x0043aeb5 in SYSGETMEM (SIZE=140736931958424)
    at ../inc/heap.inc:1082
#9  0x0003 in  ()
#10 0x000b in  ()
#11 0x01b63530 in TC_$SORTBASE_$$_QUICKSORT ()
#12 0x00e8d430 in 
SYNEDITMARKUPHIGHALL_$$_COMPAREBINARY$TSTRINGLIST$LONGINT$LONGINT$$LONGINT 
()

#13 0x000c in  ()
#14 0x00558a8e in QUICKSORT_ITEMLIST_CONTEXT (ITEMS=
    0x7fffdfc3c240, ITEMCOUNT=140736931958400, ITEMSIZE=16, COMPARER=
    {function  (POINTER, POINTER, POINTER) : LONGINT} 0x7fffc750, 
CONTEXT=

    0x7fffc780) at ../inc/sortbase.pp:222
#15 0x7fffdfc3c240 in  ()
#16 0x0010 in  ()
#17 0x0053abb0 in 
CLASSES_$$_TSTRINGLIST_CUSTOMSORT_COMPARER$POINTER$POINTER$POINTER$$LONGINT 
()

#18 0x7fffc780 in  ()
#19 0x7fffdf0017a0 in  ()
#20 0x00b0 in  ()
#21 0x7fffdf4f5f00 in  ()
#22 0x0053ace2 in CUSTOMSORT (this=0x7fffded60e80, COMPAREFN=
    {function  (TSTRINGLIST, LONGINT, LONGINT) : LONGINT} 0x0, 
SORTINGALGORITHM=0x7fffded63018) at ../objpas/classes/stringl.inc:1668

#23 0x7fffdf4f5f00 in  ()
#24 0x7fffdfc3c240 in  ()
#25 0x00e8d430 in 
SYNEDITMARKUPHIGHALL_$$_COMPAREBINARY$TSTRINGLIST$LONGINT$LONGINT$$LONGINT 
()

#26 0x0003 in  ()
#27 0x00e8d430 in 
SYNEDITMARKUPHIGHALL_$$_COMPAREBINARY$TSTRINGLIST$LONGINT$LONGINT$$LONGINT 
()

#28 0x7fffdf4f5f00 in  ()
#29 0x01b51b78 in VMT_$CLASSES_$$_TSTRINGLIST ()
#30 0x0053ab9e in CUSTOMSORT (this=0x1b18e80, COMPAREFN=
    {function  (TSTRINGLIST, LONGINT, LONGINT) : LONGINT} 0x0)
    at ../objpas/classes/stringl.inc:1628
#31 0x7fffc890 in  ()
#32 0x00e8da5e in BUILDDICTIONARY (this=0x7fffdf5574c0)
    at syneditmarkuphighall.pp:959
#33 0x00e8f558 in SEARCH (this=0x7fffdf5574c0, ATEXT=


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Index: components/synedit/syneditmarkuphighall.pp
===
--- components/synedit/syneditmarkuphighall.pp	(revision 60330)
+++ components/synedit/syneditmarkuphighall.pp	(working copy)
@@ -801,7 +801,7 @@
   end else begin
 if l > 0 then
   Result := CompareByte(s1[1], s2[1], l);
-if Result = 0 then
+if (Result = 0) and (Length(s2) > l) then
   Result := -1;
   end;
 end;
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Wrong docs: not initialized global variables

[Nikolay Nikolov]

On 04/05/2018 05:22 PM, Karoly Balogh (Charlie/SGR) wrote:



2.) Class fields are initialized. (Why is simple class fields
initialization needed for internal bookkeeping of the compiler?)

I think this is something which happens when constructing the class, so
this is runtime behavior, and not compile or exe loading time, and again,
it's just clearing the allocation after GetMem()'ing the heap area for
the class, so you don't get trash in the fields. But they're don't
necessarily initialized to valid values (if zero is not valid).
Actually, this is done, so that you can safely free all the objects 
owned by the class safely in the destructor. If it wasn't done, instead 
of this:


constructor TMyClass.Create;
begin
  FObject1 := TSomeClass.Create;
  FObject2 := TSomeClass.Create;
end;

destructor TMyClass.Destroy;
begin
  FObject2.Free;
  FObject1.Free;
end;

you would have to do this in the constructor:

constructor TMyClass.Create;
begin
  FObject1 := nil;
  FObject2 := nil;
  FObject1 := TSomeClass.Create;
  FObject2 := TSomeClass.Create;
end;

Why? Because, if something raises an exception inside the constructor, 
the destructor will be called on the partially constructed object. And 
if the exception was raised somewhere before 'FObject2 := 
TSomeClass.Create', then, if you didn't initialize FObject2 to nil in 
the beginning, the destructor would try to free FObject2, which would be 
a random uninitialized pointer.


So, even though filling objects with zero introduces a small runtime 
overhead, it saves a lot of pain and prevents difficult to find bugs 
(people quite often don't test exceptions raised in the constructor).


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

Re: [fpc-devel] rdtscp

[Nikolay Nikolov]

On 10/23/2017 02:21 AM, Wolf wrote:



On 23/10/17 02:53, Nikolay Nikolov wrote:


FPC trunk supports rdtscp. And if you're using a FPC version that 
doesn't support an instruction, you can always hardcode it with 'db' 
(make sure you add a comment with the real instruction to keep your 
code readable), e.g:


db 0fh, 01h, 0f9h  { rdtscp - not supported by FPC 3.0's inline 
assembler }


Nikolay

db 0fh, 01h, 0f9h is a Delphi instruction, as far as I can make it 
out. It does not work with FPC 3.00 - at least with the settings 
Lazarus provides by default running under Linux.

What does work is
  .byte 0x0F, 0x01, 0xF9    // read the Time-Stamp Counter rdtscp 
(as op-code format,
                              // requires setting the 
compiler switch -aas
                              // in Lazarus: 
Options/Custom Options/All Options )
Yes, that's AT asm syntax. FPC supports both AT and Intel syntax 
modes with the {$asmmode} directive:


https://www.freepascal.org/docs-html/prog/progsu3.html

AT is the default for historical reasons, but Intel also works fine.

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

Re: [fpc-devel] rdtscp

[Nikolay Nikolov]

On 10/21/2017 10:41 PM, Wolf wrote:

Hi,

How do you measure time with a one cycle resolution? EpicTimer clearly 
does not cut it, and from what I gather 
, 
rdtsc cannot do it either. You need to have a CPU capable of 
understanding rdtscp.


But then, FPC 3.00 does not want to compile this assembly instruction. 
So how do you guys manage to measure it?


FPC trunk supports rdtscp. And if you're using a FPC version that 
doesn't support an instruction, you can always hardcode it with 'db' 
(make sure you add a comment with the real instruction to keep your code 
readable), e.g:


db 0fh, 01h, 0f9h  { rdtscp - not supported by FPC 3.0's inline assembler }

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

Re: [fpc-devel] Last call for 3.0.4 merges

[Nikolay Nikolov]

On 06/18/2017 01:33 AM, Nikolay Nikolov wrote:



On 06/17/2017 10:31 PM, Marco van de Voort wrote:
While I have not done much the last month, I did keep up with most of 
the
merging so most requests have been honoured, and I plan to branch mid 
next

week or even monday if there is not much response.

If I missed some, or there are important new ones, there is still a 
few days

time, waiting for the win32/64 findfirst fix.

Note that compiler/language merges need approval and an estimate of
mergability from a compiler devel.

Another merge request:

r36498 - the fix for the fpwidestring bug, which caused the #0 in the 
compiler output of fpc-trunk. Even though the fpc-fixes compiler 
doesn't output #0 characters (because it doesn't have code page aware 
compiler messages), the actual bug is in fpwidestring's conversion 
from widestring to utf-8 and it still exists in fpc-fixes, therefore 
this merge request... :)

Are you planning to merge this?

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

Re: [fpc-devel] Last call for 3.0.4 merges

[Nikolay Nikolov]

On 06/17/2017 10:31 PM, Marco van de Voort wrote:

While I have not done much the last month, I did keep up with most of the
merging so most requests have been honoured, and I plan to branch mid next
week or even monday if there is not much response.

If I missed some, or there are important new ones, there is still a few days
time, waiting for the win32/64 findfirst fix.

Note that compiler/language merges need approval and an estimate of
mergability from a compiler devel.


ptc merge request:

r34598, r35481, r36507, r36508, r36509, r36555, r36556

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

Re: [fpc-devel] Last call for 3.0.4 merges

[Nikolay Nikolov]

On 06/17/2017 10:31 PM, Marco van de Voort wrote:

While I have not done much the last month, I did keep up with most of the
merging so most requests have been honoured, and I plan to branch mid next
week or even monday if there is not much response.

If I missed some, or there are important new ones, there is still a few days
time, waiting for the win32/64 findfirst fix.

Note that compiler/language merges need approval and an estimate of
mergability from a compiler devel.

Another merge request:

r36498 - the fix for the fpwidestring bug, which caused the #0 in the 
compiler output of fpc-trunk. Even though the fpc-fixes compiler doesn't 
output #0 characters (because it doesn't have code page aware compiler 
messages), the actual bug is in fpwidestring's conversion from 
widestring to utf-8 and it still exists in fpc-fixes, therefore this 
merge request... :)


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

Re: [fpc-devel] Just saw that FreeSparta now is open source :-)

[Nikolay Nikolov]

On 03/22/2015 11:12 PM, Maciej Izak wrote:



Yes, it has been submitted in the fpc bug tracker as well:


http://bugs.freepascal.org/view.php?id=27206


Hi,

you are wrong :), my http://bugs.freepascal.org/view.php?id=27206 is 
only for Generics.Collections library.


My new dedicated report
http://bugs.freepascal.org/view.php?id=27710

Ah, yes, you're right :) Thanks for the correction.

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

Re: [fpc-devel] Just saw that FreeSparta now is open source :-)

[Nikolay Nikolov]

On 03/22/2015 10:12 PM, Boian Mitov wrote:

Hello Everyone,
Just saw this on Google+, I think it will be great if some of it makes 
it into Lazarus :-) .
FreeSparta is now really free (new interface for Lazarus (similar to 
Delphi), and Generics.Collections library).


Soon will be possible to implement compatible ToolsAPI interface :).

I have hope that Lazarus team can merge some changes to main trunk of 
Lazarus (maybe with some changes/better naming for classes and methods) :)


What is FreeSparta:

https://www.youtube.com/watch?v=6FOjWCLDScQ 
https://www.youtube.com/watch?v=6FOjWCLDScQ

www.freesparta.com http://www.freesparta.com

Repo and more info:

https://github.com/dathox/freesparta 
https://github.com/dathox/freesparta

Yes, it has been submitted in the fpc bug tracker as well:

http://bugs.freepascal.org/view.php?id=27206

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

Re: [fpc-devel] Dumping the syntax tree

[Nikolay Nikolov]

On 23.10.2014 г. 18:59, Vsevolod Alekseyev wrote:
On second look, no, the -vp tree is not sufficient. It doesn't have 
datatype definitions, doesn't have interface definitions...
True. I guess, you can try to use ppudump in order to dump these 
definitions. It'll only work for units though, but I guess it shouldn't 
be too hard to make the compiler output ppu files for programs as well.


Nikolay



On 10/22/2014 4:44 AM, Nikolay Nikolov wrote:

On 10/22/2014 12:23 AM, Vsevolod Alekseyev wrote:

Hi all,

I wonder where in the FPC compilation flow would be a good spot to 
dump the parsed syntax tree of a source?


Here's why I'm asking. For a while now, I've been struggling to 
adapt a bunch of Pascal code to various mobile platforms. It's been 
painful. The code itself is pretty conservative feature-wise, almost 
KR C-like (except sets and ansistrings). I wonder if I could slap 
together a quick and dirty Pascal-to-C converter just for this 
codebase to work, but I'd rather reuse the existing parsing logic.


So if anyone could point me at a spot in the FPC source where the 
source tree is more or less ready, that's be nice. Thanks in advance.
The compiler already supports dumping the parse tree when you use the 
-vp option. But it's more intended for debugging the compiler - I 
don't know if it'll work for you.


Nikolay
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
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


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

Re: [fpc-devel] Dumping the syntax tree

[Nikolay Nikolov]

On 10/22/2014 12:23 AM, Vsevolod Alekseyev wrote:

Hi all,

I wonder where in the FPC compilation flow would be a good spot to 
dump the parsed syntax tree of a source?


Here's why I'm asking. For a while now, I've been struggling to adapt 
a bunch of Pascal code to various mobile platforms. It's been painful. 
The code itself is pretty conservative feature-wise, almost KR C-like 
(except sets and ansistrings). I wonder if I could slap together a 
quick and dirty Pascal-to-C converter just for this codebase to work, 
but I'd rather reuse the existing parsing logic.


So if anyone could point me at a spot in the FPC source where the 
source tree is more or less ready, that's be nice. Thanks in advance.
The compiler already supports dumping the parse tree when you use the 
-vp option. But it's more intended for debugging the compiler - I don't 
know if it'll work for you.


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

Re: [fpc-devel] Suggestion: reference counted objects

[Nikolay Nikolov]

On 10/13/2014 10:58 PM, Sven Barth wrote:

On 13.10.2014 19:23, hinsta...@yandex.ru wrote:

Great!

Sorry for misspelling your name btw


I had worse already. Swen for example. Or a common one at uni was 
Svn ;)

Better than git ;-)

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

Re: [fpc-devel] Support needed in understanding some heap.inc related stuff

[Nikolay Nikolov]

On 09/28/2014 05:45 PM, Lag Programming wrote:

   Hi! I need some help in understanding three things viewed in heap.inc.

...
3) I'm not interested in the importance of the presented function. Why 
the existing code design is preferred over alternative code?


Existing code:
function SysAllocMem(size: ptruint): pointer;
begin
  result := MemoryManager.GetMem(size);
  if resultnil then
FillChar(result^,MemoryManager.MemSize(result),0);
end;

Alternative code:
function SysAllocMem(size: ptruint): pointer;
begin
result:=MemoryManager.GetMem(size);
if resultnil then FillChar(result^,size,0);
end;

The only things I could find to support the existing code over 
alternative code are that(now or in the future):
a) Maybe there is a possibility that the value of variable size gets 
changed after result:=MemoryManager.GetMem(size);
This cannot happen, because the 'size' parameter to MemoryManager.GetMem 
is passed by value, not by reference.
b) Maybe there is a possibility that following 
result:=MemoryManager.GetMem(size); variable result would point to a 
memory block that has allocated a size different than variable 
size's content.
This could happen, at least in theory. Memory managers usually align 
memory block size up to some given granularity, so they often allocate 
more memory than you requested. The question is whether they save and 
return the original size in MemSize or the aligned (i.e. bigger) one. If 
they store the aligned size, it's a good idea, just in case, to clear 
all the memory up to that size.


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

Re: [fpc-devel] Support needed in understanding some heap.inc related stuff

[Nikolay Nikolov]

On 09/28/2014 08:58 PM, Lag Programming wrote:

@Nikolay
   Thank you for your answer. :) Now that you've answered, can you 
further respond to the following question: why is it needed to zero 
fill the memory allocated that exceeds the requested value?
a) pointer:=allocmem(initialsize); 
reallocmem(pointer,increasedsize);. I don't see the benefits of the 
zero filled bytes that exceed the initialsize value at pointer. 
Once you reallocmem to increase size you don't expect to have the 
additional space filled with zeros. This means that an attempt to 
somehow optimize code because of initial more than enough zero filling 
is something hard to believe in.
To be honest, I don't know. It's probably for some extra safety, e.g. to 
minimize the damage from the undefined behaviour of reading beyond the 
memory block you allocated or to be able to detect heap corruption if 
you overwrite these zeros.
b) if your affirmation is right then for 
bytepointer:=allocmem(sizeof(byte)); we would zero fill at least 3 
or 7 times the necessary amount. At the moment I don't see nothing 
good at that. The closest thing that got into my mind was the arrays. 
For an unknown reason to me, yet(somebody please enlighten me) dynamic 
arrays are always zero filled. But even these arrays don't use 
allocmem. It was something that got me curious. Instead of allocmem, 
getmemfillchar are used separately :) (see dynarr.inc 
fpc_dynarray_setlength). Somebody saw the bottleneck(waste, whatever 
you want to call it) with this allocmem situation.
   So. Can you please further develop you answer according to this 
message.


I seriously doubt it makes any difference on 32-bit and 64-bit 
architectures. AFAIK, on a modern CPU, it takes exactly the same amount 
of time to write 32-bits to a 32-bit aligned address as to write a 
single byte. But the extra call to MemSize probably does add some extra 
overhead, yes. As for why are dynarrays zero filled, I can only guess, 
but these things come to mind:


1) delphi compatibility
2) zero filling ensures that magic reference counted types like 
ansistrings, interfaces and other dynarrays are properly initialized. 
The same reason class instances are initialized with zeros before the 
constructor is called.


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

Re: [fpc-devel] weak referencing (was Suggestion:.....)

[Nikolay Nikolov]

On 09/23/2014 11:31 AM, Giuliano Colla wrote:

Il 23/09/2014 02:24, John Briggs ha scritto:

Sven
At the risk of starting a flame war I have been pondering this question
since these threads have started:

Why has there been so many messages on this list debating the pros 
and cons

of reference counting objects?


Because many of us are scared to death from the idea of adding as a 
default a feature which could break millions of lines of existing 
code, degrade performance, and create incredible debugging headaches, 
without bringing any benefit to the overwhelming majority of users.
IMO, it's very unlikely that this feature will be accepted in FPC in a 
form that breaks existing code. FPC has always been very strict about 
keeping backward compatibility. New features are almost always added in 
a way that don't break existing code.


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

Re: [fpc-devel] weak referencing (was Suggestion:.....)

[Nikolay Nikolov]

On 09/23/2014 03:55 AM, Boian Mitov wrote:

Because none of those is a strong typed language.
Each language has weak and strong points.
Pascal is semi strong typed language, and as such is very well 
declarative style oriented.
Functional programming however merges very well with strong typed 
declarations actually getting us closer to the holly grail for pure 
declarative programming.

Those other languages you mentioned don’t do that.
The closest to perfection nowadays is probably C++11 but it also is 
not without flows, mainly practically total lack of RTTI.
What I am saying is that Delphi, C++ with C++11, Java, and C# have all 
been inching toward the goal of a perfect language, while FPC has not.
That's because most people who complaining about the lack of these 
features, don't do any work to implement them and submit patches.


Nikolay


With best regards,
Boian Mitov

---
Mitov Software
www.mitov.com
---
-Original Message- From: John Briggs
Sent: Monday, September 22, 2014 5:24 PM
To: FPC developers' list
Subject: Re: [fpc-devel] weak referencing (was Suggestion:.)

Why has there been so many messages on this list debating the pros and 
cons

of reference counting objects?
The beauty of the Pascal language is in its structure ie:
procedures,functions,OOP. Why does it need to be a functional programming
language as well when there are Haskell, Lisp, Scheme and other 
functional

languages that have already done the hard work.


John
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
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


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

Re: [fpc-devel] Suggestion: reference counted objects

[Nikolay Nikolov]

On 09/23/2014 08:47 PM, Boian Mitov wrote:

This is a valid point.
The only downside is that the object will every time do a deep copy 
versus a shallow (pointer only) copy. Deep copy is very, very 
expensive operation.
Adding ref. counting to objects is probably equivalent of one 
interlocked assembly instruction, so a very small difference, probably 
not even measurable.
Copy of a large object can take a large memory transfer, and will also 
reserve memory for each copy, thus significantly increasing memory.
While both approaches have something going for them, they are not 
total subside for each other.
Yes, but if you have compiler support for objects with automatic calls 
of constructors/destructor/copy constructor/assignment operator (like in 
C++ classes), and if you also have generics support for objects, you can 
make a generic smart pointer object type that adds reference counting to 
any class. And then the regular class references will serve as weak 
references. Exactly like C++:


http://www.boost.org/doc/libs/1_56_0/libs/smart_ptr/smart_ptr.htm

What's more important is that we can extend objects this way, without 
breaking backward compatibility. But, unfortunately, it's a huge 
slippery slope from there, as anyone, who has dealt with C++ STL error 
messages knows:


http://pascalg.wordpress.com/2008/02/24/stl-error-messages-are-so-great/

Nikolay

With best regards,
Boian Mitov

---
Mitov Software
www.mitov.com
---
*From:* August Oktobar mailto:augustokto...@gmail.com
*Sent:* Tuesday, September 23, 2014 10:35 AM
*To:* FPC developers' list mailto:fpc-devel@lists.freepascal.org
*Subject:* Re: [fpc-devel] Suggestion: reference counted objects
To somebody (probably Sven):

In FPC there is concept of stack based objects (object) that behave 
like classes (with inheritance)?
Why not just extend this object with support for constructors and 
destructors, and there is no need for the ARC?
On Mon, Sep 22, 2014 at 2:05 PM, Hans-Peter Diettrich 
drdiettri...@aol.com mailto:drdiettri...@aol.com wrote:


Sven Barth schrieb:

Am 22.09.2014 09:47 schrieb Michael Schnell
mschn...@lumino.de mailto:mschn...@lumino.de


 Why not use interface to add ref-counting to an object ?
This seems to work nicely even though the name interface in
not speaking on that behalf.

Because you'll need to declare an interface for each class you
want to have reference counted so that you can access its
methods, properties, etc.


This overhead could be eliminated by another syntax extension, like
  TMyARCclass = interface(TObject)
where the Compiler could allow for implementations of the declared
methods just as for
  TMyARCclass = class(TObject)
bridging the gap between traditional (strictly declarative)
interfaces and classes (including implementations), with or
without ARC.

DoDi

___
fpc-devel maillist  - fpc-devel@lists.freepascal.org
mailto:fpc-devel@lists.freepascal.org
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


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
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] binutils for avr 8 bit

[Nikolay Nikolov]

On 05/26/2014 03:32 PM, Sven Barth wrote:


Am 26.05.2014 11:42 schrieb Michael Schnell mschn...@lumino.de 
mailto:mschn...@lumino.de:


 On 05/26/2014 11:37 AM, Sven Barth wrote:


 Where did he say that he wants to sell anything? Maybe he just 
wants to try FPC on AVR 8-bit for fun?


 OK :-) :-) :-)
 (For me, this fun would be too expensive in terms of engineering 
effort.)


Why? I'd try it as well if I'd have the time. At least I could then 
help with improving/finishing the AVR port :)


And so would I, if I didn't have the i8086 port to work on ;-) Besides, 
it's the next logical step for the compiler to become 32/64/16/8-bit :)


Also, 6502 becomes even closer ;-)

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

Re: [fpc-devel] OT: Code generation

[Nikolay Nikolov]

On 04/11/2014 11:22 AM, Mark Morgan Lloyd wrote:
Knowing that there are some good compiler guys in here: does anybody 
remember a paper and set of patches for GCC that randomises register 
allocation and makes random choices for the code generator (e.g. zero 
a register either by xor a,a or sub a,a etc.) in order to give buffer 
overflows less to bite on? Any URLs etc. would be much appreciated.


Could such a thing be done for FPC? :-)

For FPC I think it's better for security critical code to use only the 
managed datastructures (strings, dynarrays) and compile it with range 
checking on (and perhaps even overflow checking).


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

Re: [fpc-devel] i8086 huge pointers

[Nikolay Nikolov]

On 9.4.2014 г. 16:32, Max Nazhalov wrote:

Wednesday, April 9, 2014, Nikolay Nikolov wrote:

Hmm, then maybe we should support both and add a
{$HUGEPOINTERNORMALIZATION} directive?

Well, I don't know for sure..
But I think introducing huge pointers implies introduction of some minimal
support routines, like [h]move(hugefrom,hugeto,hugelen), [h]fill(..), etc.
Implementation of such routines is quite different among normalized real
and unnormalized common modes, so going clean way sadly will require twice
effort (and a quadruple maintenance, I suspect.. );


Yes, huge pointers will need RTL helper routines, but IMHO, not that 
many and they would be relatively simple. I think only pointer 
arithmetic will need helpers (i.e. adding a pointer with an integer and 
pointer difference). As for the other routines in the RTL like 
(h)FillChar and (h)Move, they will have to be made to work with 
unnormalized huge pointers (in order to support 16-bit protected mode) 
and this way they will automatically work with normalized huge pointers 
as well.


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

Re: [fpc-devel] i8086 huge pointers

[Nikolay Nikolov]

On 7.4.2014 г. 15:09, Max Nazhalov wrote:

Monday, April 7, 2014, Nikolay Nikolov wrote:

NN Back in the old days, I never used huge pointers, because I wrote in
NN Turbo Pascal, which didn't have them, so I don't have an opinion which
NN way is better.

I've rechecked -- and yes, You are right, BP7 RTL itself uses SelectorInc only
in DPMI16 environment for locating writable alias for the current code segment
(it's just an internal borland EXE loader convention to create such aliases).
For all other modes this variable just maintained [and it works, if you
manually use it in, e.g., Win16 for accessing huge data block allocated with
Win16 API, either in real or protected mode, since Win16 kernel exports
constant __AHIncr, which is exactly the same thing as SelectorInc, and is
used by BP7 RTL for SelectorInc initialization].

For real mode normalization of (typed?) huge pointer probably could be done
during converting it to regular far pointer. But for non-real mode segmented
model access to the data structure crossing segment boundary always a challenge
ending up with stream it out to the safe place at first, if the structure is
relatively small.


Hmm, then maybe we should support both and add a 
{$HUGEPOINTERNORMALIZATION} directive?


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

Re: [fpc-devel] i8086 huge pointers

[Nikolay Nikolov]

On 04/07/2014 03:51 AM, Max Nazhalov wrote:

Sunday, April 6, 2014, Nikolay Nikolov wrote:

NN Back in the old days, I never used huge pointers, because I wrote in Turbo 
Pascal,
NN which didn't have them, so I don't have an opinion which way is better.
NN So, which way should FPC for i8086 follow?

BP7 does not normalize pointers, since it targets DPMI16, where such 
normalization is senseless.
Moreover, it uses special typed const system.SelectorInc to handle offset 
overflows.
Under real mode, SelectorInc is barely $1000.
Under DPMI16 environment SelectorInc can be obtained by DPMI function 
INT31h/AX=0003h (usually, it returns 8).
With this approach the whole pointer arithmetics is similar between real and 
protected modes.
Ok, I just added this constant to the msdos rtl (r27497). However, as 
far as BP7 compatibility is concerned, it doesn't really matter which 
huge pointer model we use, because BP7 doesn't have a huge pointer type 
and in fact, it doesn't even offer any kind of pointer arithmetic as far 
as I know. But it's a good point that the pointer normalization, used in 
Borland C works in real mode only. This means that if we follow that 
way, huge pointers must be either entirely disallowed or behave 
differently (i.e. like Microsoft and Watcom C, but by using 
System.SelectorInc) in 16-bit protected mode. However, the Borland C 
way, IMHO, does have some really nice advantages:


- If you pass a huge pointer to a function or interrupt routine that 
expects only a far (not huge) pointer, it'll always be able to access at 
least the next (64K-15) bytes of the object
- Free Pascal often generates code using [base + index + offset] 
references to access record/object/class fields or array elements. This 
will work nicely with normalized huge pointers, as long as the structure 
itself does not exceed 64kb (which is currently not allowed in the 
compiler). With MS/Watcom-style huge pointers, you could end up, after 
some pointer arithmetic at Ptr($1234:$) and then when you 
dereference the pointer and try to access some record member, you're 
screwed.


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

Re: [fpc-devel] i8086 huge pointers

[Nikolay Nikolov]

On 04/07/2014 12:10 PM, Tomas Hajny wrote:

On Mon, April 7, 2014 10:56, Nikolay Nikolov wrote:
  .
  .

Ok, I just added this constant to the msdos rtl (r27497). However, as
far as BP7 compatibility is concerned, it doesn't really matter which
huge pointer model we use, because BP7 doesn't have a huge pointer type
and in fact, it doesn't even offer any kind of pointer arithmetic as far
as I know.

  .
  .

BP7 already provided pointer arithmetics for PChars.
You're right, I didn't know that. However, I just checked and it only 
increments/decrements the offset, so it's normal far pointer arithmetic, 
not huge pointer arithmetic.


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

[fpc-devel] i8086 huge pointers

[Nikolay Nikolov]

I started investigating huge pointer support in 16-bit C compilers and 
discovered there are at least two different implementations:



Borland C++ 3.1:

Huge pointers aren't changed when converting from a far pointer. They 
are normalized as soon as some pointer arithmetic is performed on them. 
Normalization means changing the segment and the offset in such a way 
that it still points to the same linear address ( =segment*16+offset ), 
but the offset is always between $ and $000F. So:


HugePointer(Ptr($1234,$5678)) = $1234:$5678
HugePointer(Ptr($1234,$5678))+1 = $179B:$0009
HugePointer(Ptr($1234,$5678))-1 = $179B:$0007


Microsoft C/C++ 7.0 and Open Watcom 1.9:

Huge pointers aren't changed when converting from a far pointer (same as 
Borland). However, during pointer arithmetic, they aren't normalized 
like in Borland, but the segment is changed only when the offset 
overflows, i.e.:


HugePointer(Ptr($1234,$5678)) = $1234:$5678
HugePointer(Ptr($1234,$5678))+1 = $1234:$5679
HugePointer(Ptr($1234,$5678))-1 = $1234:$5677
HugePointer(Ptr($1234,$))+1 = $2234:$
HugePointer(Ptr($1234,$))-1 = $0234:$


Back in the old days, I never used huge pointers, because I wrote in 
Turbo Pascal, which didn't have them, so I don't have an opinion which 
way is better. So, which way should FPC for i8086 follow?


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

Re: [fpc-devel] FPC and Windows Phone 8

[Nikolay Nikolov]

On 03/10/2014 03:03 PM, Sven Barth wrote:

Am 10.03.2014 13:52, schrieb Vsevolod Alekseyev:


I don't now remember the exact history behind each
replacement, but here they are.

  - DGROUP is a problem; I comment it out
  - So is ASSUME
  - The syntax of SEGMENT is different
  - Instead of .386p I want .686p
  - Instead of _CODE I want _TEXT

The first three might be bugs in the assembler writer...
These sound more like a DOS thing. DGROUP is usually used in DOS 
programs to specify which object file segments have to be merged in a 
single physical segment (pointed by DS). See:


http://www.nasm.us/doc/nasmdoc7.html#section-7.4.2

(I know this is NASM's and not MASM's documentation, but it explains 
what DGROUP is)


Also it would be possible to couple the generation of .386p/.686p to 
the selected target processor. Is there a list of valid options 
somewhere?
I did this for NASM for the i8086 target, see compiler/x86/agx86nsm.pas, 
lines 1187..1199. Pretty sure it's just as easy to do for the MASM writer.

What's the difference between _CODE and _TEXT in MASM?
I don't know much about MASM (both the old DOS versions and the new 
ones), because I used TASM back in the old days and then later switched 
to NASM, but maybe it's another DOS thing?


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

Re: [fpc-devel] optimizing the peephole optimizer?

[Nikolay Nikolov]

On 01/22/2014 11:25 PM, Florian Klämpfl wrote:

Am 22.01.2014 02:17, schrieb Nikolay Nikolov:

On 01/21/2014 11:20 PM, Florian Klämpfl wrote:

It is still on my todo list though to update the peephole optimizer and
make a common one for i386 and x86_64 ...

And don't forget i8086 :)


I think there is little to share that's why I didn't mention it :)
Well, x86 is x86 is x86. Most of the x86 code generator is already 
shared in x86/cgx86.pas and that code is common for i8086, i386 and 
x86_64. IMHO, most of the peephole optimizations can be shared across 
all x86. Only the 'lea'-related stuff wouldn't work on i8086 (because of 
the register restrictions of 16-bit references) and there are some 
optimizations, which are specific to i8086 (like converting certain 
sequences of movs to lds/les). Of course, I could be wrong, but that was 
my opinion from looking at popt386.pas. It just looked to me that most 
optimizations done there apply equally well to i8086 as well as x86_64 
and it was in my TODO list to eventually cleanup and unify the peephole 
optimizer across all x86 (or if that turns out to be impractical, at 
least write one for i8086).


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

Re: [fpc-devel] optimizing the peephole optimizer?

[Nikolay Nikolov]

On 01/21/2014 11:20 PM, Florian Klämpfl wrote:

It is still on my todo list though to update the peephole optimizer and
make a common one for i386 and x86_64 ...

And don't forget i8086 :)

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

Re: [fpc-devel] DOS GUI

[Nikolay Nikolov]

On 01/16/2014 05:17 PM, Jonas Maebe wrote:


On 16 Jan 2014, at 16:11, Travis Siegel wrote:

The only problem with the whole public domain thing is that it's not 
as easy to donate things to public domain as one thinks.  Beats me 
why, but there's a whole legal thing, apparently, you can't just say 
I donate this code to the public domain, and then folks can do what 
they like with it. You'd think they could, but I've seen legal 
arguments, entire discussion groups, and even whole web sites devoted 
to the issue of what constitutes public domain, and apparently, 
things that are still in copyright (regardless of author intent) 
can't actually be given to the public domain (go figure).


You can always use the CC0 license: 
https://creativecommons.org/choose/zero/

...or WTFPL :)

http://www.wtfpl.net/about/

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

Re: [fpc-devel] Improving i8086 performance..

[Nikolay Nikolov]

On 01/01/2014 05:35 PM, Max Nazhalov wrote:

Date: Tue, 31 Dec 2013 19:42:44 +0200
From: Nikolay Nikolov nick...@gmail.com

I got my PSU fixed and now I have results from my 10 MHz PS/2 Model 30 286:
32pas: ticks = 814
32asm: ticks = 30
~27x faster

64pas: ticks = 1130
64asm: ticks = 30
~38x faster

Thanks for follow-up, Nikolay!
I'm still looking for performance bottlenecks of the current float-ascii 
conversion. Can You run the attached benchmark to make it clear how the uint32|uint64 
multiplication affects this?


Ok, I compiled it with the latest fpc trunk, with -O2 -WmMedium. Here 
are the binaries:


http://debian.fmi.uni-sofia.bg/~nickysn/fpc-8086/testf80/

Here are the results from my 286:


testf80p.exe:

Seed: 0x004A0020
Predefs: 0

Input count and press ENTER (blank to use the default=100) 1000
Count: 1000

[normal] null:  7.799 s
[normal] f2a: 129.510 s (t-null)
[normal] a2f:  89.703 s (t-f2a-null)
[subnormal] null:   4.771 s
[subnormal] f2a:  163.248 s (t-null)
[subnormal] a2f:   96.229 s (t-f2a-null)

Next seed: 0xFFB5FFDF

Note:
  Small count of numers will lead to arbitrarily imprecise/random timings.


testf80a.exe:

Seed: 0x2601002E
Predefs: 0

Input count and press ENTER (blank to use the default=100) 1000
Count: 1000

[normal] null:  4.500 s
[normal] f2a:  22.580 s (t-null)
[normal] a2f:  17.749 s (t-f2a-null)
[subnormal] null:   4.071 s
[subnormal] f2a:   27.558 s (t-null)
[subnormal] a2f:   18.730 s (t-f2a-null)

Next seed: 0xD9FEFFD1

Note:
  Small count of numers will lead to arbitrarily imprecise/random timings.

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

Re: [fpc-devel] Improving i8086 performance..

[Nikolay Nikolov]

I got my PSU fixed and now I have results from my 10 MHz PS/2 Model 30 286:

32pas: ticks = 814
32asm: ticks = 30
~27x faster

64pas: ticks = 1130
64asm: ticks = 30
~38x faster

The 286 is a speed monster! :)

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

Re: [fpc-devel] Improving i8086 performance..

[Nikolay Nikolov]

On 12/28/2013 04:52 PM, Max Nazhalov wrote:

On Sat, 28 Dec 2013 01:15:41 +0200, Nikolay Nikolov wrote:

It looks correct, but I still haven't reviewed the overflow checking part of 
the 64-bit multiplication routine. I'll commit the patch when I finish that.

Thanks for the effort, Nikolay!
To help with the understanding of data/decision flow with overflow checking, 
below is the primary scheme used to construct the assembler code.

WBR, Max.

...


Ok, commited in r26306. I also added your comments to the source.

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

Re: [fpc-devel] Improving i8086 performance..

[Nikolay Nikolov]

On 12/23/2013 03:34 PM, Max Nazhalov wrote:

Hello, Everybody!

Can anyone having the real i8086 hardware check attached MUL-helpers?
I've tested them on a modern Intel CPU -- mul_dword is about 4.5..5
times faster comparing to the generic FPC implementation, and
mul_qword is about 18..20, but these numbers surely should be quite
different for the real i8086 due to the progress in the today's ALU design.
Just curious how fast they can be in the silicon of those days..

I made a small benchmark:

http://debian.fmi.uni-sofia.bg/~nickysn/fpc-8086/mul-benchmark/

The generic pascal version is compiled with -O2 for 8086/8088 (so, it 
doesn't use any 186+ instructions).


I ran it on my HP 200LX, which has a 7.91 MHz Intel Hornet 80186 CPU. 
Here are the results:


32-bit multiplication, N=10 (40960 multiplications)

mul32pas: 1902 ticks
mul32asm: 71 ticks

Or, in other words, 26.8 times faster. Not bad at all! :)

64-bit multiplication, N=10 (20480 multiplications)

mul64pas: 2704 ticks
mul64asm: 77 ticks

So the 64-bit multiplication got 35.1 times faster!

However, due to holidays, I'm not at home, where I have an IBM 5150 with 
an 8088 and a NEC V20 CPU (both CPUs are pin compatible, but the NEC is 
slightly faster at the same clockspeed, especially its mul and div 
instructions are faster, so it'd be interesting to test both). In about 
2 weeks I'll be back home and I'll be able to test it on these CPUs. But 
it'd be nice if Jim could run the test on his 8088 machine, because 
we'll know the results sooner and because it'll save me from having to 
swap processors on the 5150, since it currently has the NEC installed.


Also, where I currently am, I have access to a 286 machine with a broken 
PSU, so in the next few days, I'm planning to replace the PSU and run 
the test on a 286 as well :)


As for correctness, I ran the fpc testsuite with no regressions and 
reviewed the asm code (and checked the math). It looks correct, but I 
still haven't reviewed the overflow checking part of the 64-bit 
multiplication routine. I'll commit the patch when I finish that.


Anyway, thanks for the patch, it looks great so far and the speed up 
seems to be even greater on old processors, compared to the modern ones.


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

Re: [fpc-devel] State of i8086 generation?

[Nikolay Nikolov]

On 11/30/2013 12:33 AM, Jim Leonard wrote:

On 11/29/2013 3:45 PM, Nikolay Nikolov wrote:

It should be functional, although it does break occasionally, so you
should always keep the latest working version if you plan on using it. I
run the testsuite weekly and try to fix any regressions, but
occasionally it may take longer if I'm busy. There's a wiki page
dedicated to the i8086 port here with more details:

http://wiki.freepascal.org/DOS


Thanks, I look forward to playing with this.  I'm curious if the 
optimizations in FPC beat those in TP (my guess is very likely, since 
the optimizations in TP were only those that could be implemented in a 
single pass, with no peephole optimization).
Note that right now FPC is still usually slower than TP, mainly because 
TP's RTL is written mostly in optimized asm, while the FPC RTL is mostly 
written in pascal. But, of course, you can always help with patches :) 
Also, there's still no peephole optimizer for i8086 (there's a jump 
optimizer, though) and regvars don't yet work (they produce wrong code 
for a reason I've not discovered yet, so they're disabled from -O2. They 
also cause problems with the register allocator). But eventually, in the 
long run, FPC should be able to produce much better code than TP. 
However, I'm still not done with all the memory models yet, so I'm still 
focusing mostly on testing for correctness, getting more code to 
compile, fixing bugs, etc. and not so much on optimization. Getting the 
medium memory model to work was much harder than I expected and I expect 
that large  compact will be even harder (although, the good part is 
that we'll probably get both of them working at the same time, since the 
actual new feature is support for far data; far code is already 
supported), so my current plan is this:


1) get as much code working under the medium memory model, e.g. get free 
vision working
2) improve the far pointer support, until it becomes stable enough to be 
the default pointer type, so we can start the large  compact memory models

3) get the large  compact memory models working and stabilize them

If I'm the only person working on the i8086 port, I'm guessing this will 
take anything between 6 months to a year, so I'll probably not have much 
time to work on the optimizer. But then, again, I may get distracted 
while trying to get something to work and do some work on optimization, 
so I can get it working fast enough on a vintage machine or to get 
something to fit in 64kb.


Another distraction I currently have is fixing the 8087 support, since I 
got one from eBay and installed it on my IBM 5150. The bad thing about 
8087, though, is the fact that we cannot easily run automated tests on 
it. Normally, I run the FPC testsuite with dosbox, which emulates a 387+.


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

Re: [fpc-devel] Multithreading under DOS

[Nikolay Nikolov]

On 09/27/2013 11:15 AM, Marco van de Voort wrote:

In our previous episode, Nikolay Nikolov said:

if you aim to use 32-bit anyway, I see no reason to use an DOS
extender over a real multitasking OS.

Low resource usage perhaps. How well does Linux run on a 386 with 4 MB
of RAM? What about 2 MB? :)

Where can I buy machines with 4MB RAM?  It will be hard to find a sub 256MB
machine.

Here:

http://www.ebay.com/sch/Vintage-Computing-/11189/i.html?_from=R40_nkw=vintage+computing

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

Re: [fpc-devel] Multithreading under DOS

[Nikolay Nikolov]

On 09/25/2013 08:13 PM, Tomas Hajny wrote:


Anyway, interesting thread. ;-) Still, the overall goal (or set of goals)
is not clear for me from the limited context included:


Ok, here's my point:

Since the FPC RTL offers pluggable thread manager support, we can offer 
multiple implementations. Just like Linux has cthreads, we can have 
several threading options.


1) One that requires DR-DOS and its multitasker. This one would be the 
easiest to implement for both i8086-msdos and i386-go32v2 and may be a 
good enough reason enough not to disable the threading support for DOS 
(i.e. to not treat threadvar as regular var).
2) Cooperative multithreading, which requires each thread to call .yield 
periodically. This can also be implemented in both i8086-msdos and 
i386-go32v2 and should also be easy and compatible.
3) Preemptive multitasking, implemented in the RTL. This will be the 
hardest one to implement, but is certainly possible at least in 
i8086-msdos. For i386-go32v2 I'm not so sure. As I said, I believe it 
would require extensions to the DPMI host. This can be done by extending 
cwsdpmi or some other open source DPMI host and I guess it would be hard 
to stabilize, but it's still quite possible. And, if done correctly, 
would work under regular DOS under real mode or even a VCPI host like 
emm386.exe, but will certainly not work under a windows dos prompt or 
while some other dos extender/dpmi host/multitasker is used.


Ideally, all 3 can be implemented, but any of the three would be an 
improvement to the current situation under DOS, which is no threading at 
all. And none of the 3 would be good enough to be put as the default 
thread manager, because each one has some drawbacks, that have to be 
considered carefully by the programmer, so it should be left to the 
programmer to choose. The drawbacks for each one are the following:


1) requirement of DR-DOS
2) the need to add calls to .yield
3) stability and compatibility issues with certain dos boxes (including 
the windows command prompt) and perhaps drivers


Nikolay

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

Re: [fpc-devel] Multithreading under DOS

[Nikolay Nikolov]

On 09/26/2013 08:24 PM, Leif Ekblad wrote:
DOS extenders are even worse candidates for multitasking than DOS. And 
if you aim to use 32-bit anyway, I see no reason to use an DOS 
extender over a real multitasking OS.
Low resource usage perhaps. How well does Linux run on a 386 with 4 MB 
of RAM? What about 2 MB? :)


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

Re: [fpc-devel] Multithreading under DOS

[Nikolay Nikolov]

On 09/26/2013 09:25 PM, Sven Barth wrote:

On 26.09.2013 19:48, Nikolay Nikolov wrote:

On 09/26/2013 08:24 PM, Leif Ekblad wrote:

DOS extenders are even worse candidates for multitasking than DOS. And
if you aim to use 32-bit anyway, I see no reason to use an DOS
extender over a real multitasking OS.

Low resource usage perhaps. How well does Linux run on a 386 with 4 MB
of RAM? What about 2 MB? :)


See here: 
http://hackaday.com/2011/08/12/installing-linux-on-a-386-laptop/ (with 
4 MB)

Cool :) But DOS is still more fun :)


Please note that 386 support was completely dropped recently from the 
kernel: 
http://www.zdnet.com/good-bye-386-linux-to-drop-support-for-i386-chips-with-next-major-release-708772/
Yes, I know that, but I intentionally didn't mention it, because then 
people would point out the fact that you could use old versions, which 
would run just fine.


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

Re: [fpc-devel] Multithreading under DOS

[Nikolay Nikolov]

On 09/26/2013 09:41 PM, Hans-Peter Diettrich wrote:

Nikolay Nikolov schrieb:

On 09/26/2013 08:24 PM, Leif Ekblad wrote:
DOS extenders are even worse candidates for multitasking than DOS. 
And if you aim to use 32-bit anyway, I see no reason to use an DOS 
extender over a real multitasking OS.
Low resource usage perhaps. How well does Linux run on a 386 with 4 
MB of RAM? What about 2 MB? :)


My first notebook had 4 MB RAM, and Win3.1 and Word 1.0 worked very 
well on it :-)

Yes, but windows 3.1 is a DOS extender :)

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

Re: [fpc-devel] Multithreading under DOS

[Nikolay Nikolov]

On 09/26/2013 11:33 PM, Tomas Hajny wrote:

On Thu, September 26, 2013 21:03, Nikolay Nikolov wrote:

On 09/26/2013 09:41 PM, Hans-Peter Diettrich wrote:

Nikolay Nikolov schrieb:

On 09/26/2013 08:24 PM, Leif Ekblad wrote:

DOS extenders are even worse candidates for multitasking than DOS.
And if you aim to use 32-bit anyway, I see no reason to use an DOS
extender over a real multitasking OS.

Low resource usage perhaps. How well does Linux run on a 386 with 4
MB of RAM? What about 2 MB? :)

How much does the 386 CPU with 2 MB of appropriate RAM cost today? How
much power and cooling does it need? How much reliable would be the HW
compared to more up to date alternatives (let's say ARM or MIPS with 512
MB RAM and an SSD running Linux)?

Anyway, as I mentioned - I can imagine that it may be fun (similarly to my
attempts to keep and improve the OS/2 support which is also used very
rarely by others at best ;-) ), I just wanted to understand if there was
any idea how it would be used in reality.
Well, if you go into details, there's not much use in using DOS at all, 
even without multithreading and multitasking. I'm using it for the fun 
factor mostly.

My first notebook had 4 MB RAM, and Win3.1 and Word 1.0 worked very
well on it :-)

Yes, but windows 3.1 is a DOS extender :)

Yes. Moreover, an extender not featuring multi-threading and even the
multitasking wasn't preemptive if I remember correctly.
Actually, in 386 enhanced mode the multitasking was preemptive for DOS 
applications, but Win16 applications used cooperative multitasking. But 
Microsoft later made a DOS extender that supported full preemptive 
multitasking and multithreading. They called it Windows 95 :)


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

[fpc-devel] Multithreading under DOS (was: [Lazarus] Why development remains constant for msdos?)

[Nikolay Nikolov]

On 09/25/2013 01:45 PM, Mark Morgan Lloyd wrote:

Nikolay Nikolov wrote:

On 09/25/2013 11:26 AM, Michael Schnell wrote:

On 09/24/2013 10:58 AM, Nikolay Nikolov wrote:


When you try to create a thread, your program terminates and writes 
a message that threading is not supported.


While this absolutely does make sense, one could think about 
alternatives.


AFAIK, (at least for some archs) there is a variant of the pthread 
(=POSIX thread) library, that internally does user-land 
multithreading. IIRC, the original POSIX definition was done with 
exactly this in mind and, regarding Linux, the original Linux 
implementations (aka Linux Threads)  was not fully compatible with 
POSIX. Only some years ago, the Linux changed it's way of 
Kernel-based thread handling to the POSIX compatible NPTL 
implementation.


Thus it should be possible to link fpc projects to a user-land 
thread enabled version of pthreadlib and allow for working with 
TThread in DOS.


I've actually thought about implementing some sort of multithreading 
for DOS for a long time. The problems are the following:


1) DOS functions are not reetrant and are thus not safe to call from 
different threads. There's an undocumented InDOS flag that indicates 
whether a DOS function is safe to call:


http://stanislavs.org/helppc/int_21-34.html

But the RTL currently doesn't check it before every call and normally 
it's only used when writing TSRs.


It's more complex than that: there's undocumented provision in DOS for 
context switching under certain well-defined conditions, and each 
context can invoke int 21h irrespective of other contexts' states. 
That sort of thing was used fairly extensively by- for example- IBM 
real-time control executives (RIC card etc.) but it wasn't until the 
1990s that it leaked to general knowledge see Ralph Brown's list).
Interesting. I didn't know that. That makes it even more feasible to try 
to implement multithreading under real mode DOS.


2) In DPMI protected mode applications (such as go32v2), you cannot 
modify the return address from within an interrupt handler, which 
means you cannot implement your task scheduler as a timer interrupt 
handler, because you won't be able to switch to a different context 
from there. Doing this would require modifications to the DPMI host 
(cwsdpmi.exe) and will not work if another DPMI host is active (such 
as when running in a windows dos prompt, etc.)


3) Even if you solve 2), DPMI requires that all code and data touched 
from an interrupt handler to be locked, so that it cannot be swapped 
out. This is a tedious and error prone task to do from a high level 
language such as pascal. You should ensure that your entire 
scheduler's code and data are locked. An alternative option is to 
switch to a DPMI host, that doesn't support swapping (i.e. 
cwsdpr0.exe), but then you lose the virtual memory support (and thus 
the ability to run on machines that don't have enough memory).


2) and 3) do not apply to 16-bit MS-DOS.

Another option is to implement cooperative multitasking, which would 
require each thread to call periodically an yield function. This 
solves 1), 2) and 3), but threaded code written for other OSes will 
require modifications to run under DOS. However, that's still better 
than not running at all.


The DPMI issue sounds... interesting, but if I recall correctly what 
you do is provide a per-thread entry point analogous to a unix signal. 
A preemption interrupt transfers control to this, and then a coroutine 
mechanism- outside the ISR- transfers control to the most deserving 
thread.


Sorry if that's a bit vague, it's been many years since I played with 
this. Implementation left as an exercise :-)
Yes, but the problem is, when the ISR occurs, you cannot transfer 
control to this per-thread entry point, because when a hardware 
interrupt occurs, the return address is actually in a hidden ring 0 
stack and you don't have access to it. You can probably do it with a 
known DPMI host, that runs your program in ring 0, such as cwsdpr0.exe.




Whether it's really worth tackling, and whether any implementation can 
be really reliable, are questions to be considered.


It's worth for the fun factor for me at least :) As for reliability, I 
bet you can make it as reliable as Windows 98 was at the time, which is 
not that great, as we all know, but still quite usable.


Oh, and before I forget, later versions of DR-DOS have a version of 
emm386.exe which supports multitasking and has an API that supports 
creating processes and threads (from both real and dpmi protected mode) :


http://www.drdos.net/documentation/multtask/

This should be easy to implement under both i386-go32v2 and i8086-msdos. 
Since the FPC rtl has support for pluggable thread managers, it can be 
put in a unit like cthreads.


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

Re: [fpc-devel] Please include gmp.dll in Win32 distribution of FPC 2.6.2 and later

[Nikolay Nikolov]

As an ex-competitive programmer and multiple IOI and BOI medalist, let 
me try to explain, although I realize it might be difficult for normal 
programmers to understand, but let's just say that:


- the people who setup the programming environment for these 
competitions are not the same people who compete in them. and the people 
who compete have no control over what programming tools are installed, 
because they don't have any kind of internet connection, nor are they 
allowed to install any packages, etc, during the competition. So it's 
all about making it easy for people who don't have a clue about pascal 
to setup a pascal environment easily so that the actual pascal 
programmers can use their language to the full extent without any 
disadvantages compared to the C++ (for example) programmers. In other 
words, the more these people need to take special care about setting 
about the pascal environment, i.e. installing extra dlls, etc, etc, the 
more likely it is that they'll:


1) hate the language
2) not bother installing the extra dlls and thus putting the Pascal 
programmers at a disadvantage

 and even
3) push for dropping any kind of pascal support, because it's an 
outdated language.


Just to make it clear how these people usually think, I was part of the 
IOI2009 technical committee and I was responsible for setting up the 
pascal environment (fpc  lazarus under ubuntu) to work. In that year, 
Henadzi Karatkevitch from Belarus won the competition and I boasted 
about it on the fpc mailing list, because he wrote his solutions in 
pascal and his achievements are unique in the history of the IOI:


http://www.eng.chula.ac.th/index.php?q=en/node/4368

It even made it to the FPC front page. However, in that very same year 
something else happened that I didn't mention and that wasn't very nice 
news for the Pascal language at all. Pascal was *banned* from the 
Bulgarian National Olympiad in Informatics, which means that people who 
want to make it to the national team are required to write in C++ even 
though Pascal is officially supported in the actual International 
Olympiad. This is all because people here believe strongly that C++ and 
its STL give you a tremendous advantage in these competitions and Pascal 
(obviously) is a dead language and nobody should be taking it seriously 
and should be discouraged of writing any code in it. Yes, it's all 
driven by ignorance, but we must combat it.


I'm writing all of this because I've seen the writing on the wall and 
this has already happened in Bulgaria, so I'd be sad to see this happen 
in Russia too (which is btw one of the countries in the world with a 
significant number of Pascal programmers, including FPC contributors).


Having a library for arbitrary-precision arithmetic like gmp is a huge 
advantage in these competitions and making it easy to setup by people 
who are clueless idiots and know only how to press next, next, 
next so people who chose to compete and write their solutions in 
Pascal can use it is a must if we want to keep Pascal as a serious 
option for these competitions. And we want to keep Pascal as a serious 
option at least in the countries where it still is, because without 
that, Pascal would be dropped even as a teaching language and FPC 
contributors would eventually dry up and in the long run FPC cannot 
survive without contributors. It's great that we have old people 
contributing to FPC and keeping it alive (no offence about age to 
anybody, including me ;-) ), but we must also think about the future 
generations, otherwise we are doomed :)


So I'm all for adding a simple dll in the default windows install for 
political reasons, even though it might not seem to be the right thing 
to do to people who aren't involved in competitive programming.

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

[fpc-devel] How are Makefile and Makefile.fpc regenerated in fpc trunk?

[Nikolay Nikolov]

Hi,

I'd like to update hermes and ptcpas to the latest version in the fpc 
trunk, but I don't know how to regenerate the Makefile and Makefile.fpc 
files. I'm new to fpmake, I've only used fpcmake before.


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

Re: [fpc-devel] Bounty for MIPS

[Nikolay Nikolov]

On 01/29/2012 02:21 PM, Florian Klämpfl wrote:

Main problem with MIPS is to get hands on a reasonable development
system (full fledged unix like Debian Linux, *BSD, CPU in the range of 1
GHz, 128 MB or more RAM, at least 1 GB of HD/SSD). Cross compiling is
possible of course, but it makes testing and bug fixing very tedious. If
ssh to such a system is available, I'll look into fixing the MIPS port
without any bounty.

FYI, the Lemote Yeeloong is a nice MIPS netbook designed for hardcore 
free/opensource geeks:


 http://www.amazon.com/Screen-Lemote-Yeeloong-8089_B-Netbook/dp/B005SYBJYE

It has: Loongson 2f 64-bit MIPS-compatible processor, 1GB RAM, 160GB 
Hard Drive


Disclaimer: I don't have it, I just know that it exists and sounds like 
a great option for doing a FPC port.

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

Re: [fpc-devel] Free Pascal 2.4.4 available

[Nikolay Nikolov]

On 05/28/2011 12:13 AM, Marco van de Voort wrote:

In our previous episode, Nikolay Nikolov said:

The go32v2 download links are broken:

http://freepascal.org/down/i386/go32v2-ftp.freepascal.org.var

The file names should be dos244.zip and dos244full.zip, not dos242.zip
and dos242full.zip

Thanks, fixed in SVN, visible tomorrow.
The dos244full.zip link is still broken - it should be 
dos244full.zip without a space between dos244 and full.

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

Re: [fpc-devel] Free Pascal 2.4.4 available

[Nikolay Nikolov]

The go32v2 download links are broken:

http://freepascal.org/down/i386/go32v2-ftp.freepascal.org.var

The file names should be dos244.zip and dos244full.zip, not dos242.zip 
and dos242full.zip


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

Re: [fpc-devel] New language feature suggestion (probably not existing in Delphi)

[Nikolay Nikolov]

On 11/26/2010 10:42 AM, Max Vlasov wrote:


Is anyone aware of similar concept in any other OOP language?

Yes, C++ has it:
http://duramecho.com/ComputerInformation/WhyHowCppConst.html

It's true that it's a little bit messy, but that's pretty much the norm 
with everything in C++ ;-)

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

Re: [fpc-devel] proposal for palette-related graph unit interface changes

[Nikolay Nikolov]

 On 09/17/2010 04:32 PM, Florian Klaempfl wrote:

Am 15.09.2010 17:05, schrieb Nikolay Nikolov:

  On 09/15/2010 05:48 PM, Florian Klaempfl wrote:

Am 15.09.2010 16:39, schrieb Nikolay Nikolov:

and then introduce TP7-compatible MaxColors, PaletteType and
procedures/functions. They'll be made optionally hookable (so the go32v2
implementation will be able to implement them with the real EGA palette
registers for maximum compatibility), with a default implementation that
works on top of SetRGBPalette (similar to the way SetPalette is
implemented now)

What do you think?

But this will break existing FPC code, right? I'am also not sure if the
palettes as they are done were invented for other OSes e.g. Amiga or
Atari

Yes, it'll break existing FPC code (but will also improve TP7
compatibility),

I guess most people depend now on FPC compatibility so I'd prefer to
leave it as it is.

Ok then, what about adding the ExtendedRGBPaletteRange (or some similar 
name - BGICompatibleRGBPaletteRange?) global variable, that allows using 
0..63 range in SetRGBPalette, when set to false (or true, if it's called 
BGICompatibleRGBPaletteRange)? We can still make FPC compatibility 
(0..255) the default, so existing FPC applications won't break and TP7 
applications would be able to easily enable the TP7-compatible range 
0..63. At least in the case of 256-colour modes (SVGA256.bgi) this means 
pretty much 100% TP7 palette compatibility (when porting code from TP7 
to FPC, all the other palette differences only affect 16-colour modes, 
because TP7's PaletteType, SetPalette, SetAllPalette, etc. have no 
effect in 256-colour modes).

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

[fpc-devel] proposal for palette-related graph unit interface changes

[Nikolay Nikolov]

 Currently, the following palette-related things from the fpc graph 
unit aren't TP7 compatible:


MaxColors (constant)
PaletteType (record)

procedure SetAllPalette(const Palette: PaletteType);
procedure GetPalette(var Palette: PaletteType);
function GetPaletteSize: smallint;
procedure GetDefaultPalette(var Palette: PaletteType);

the most notable difference is the definition of PaletteType, which is 
defined as:


in fpc:

const
  MaxColors = 255;

type
  RGBRec = packed record
Red, Green, Blue: smallint;
  end;
  PaletteType = record
Size: longint;
Colors: array [0..MaxColors] of RGBRec;
  end;

in TP7:

const
  MaxColors = 15;

type
  PaletteType = record
Size: byte;
Colors: array [0..MaxColors] of shortint;
  end;

so the main difference is that fpc's PaletteType represents a VGA 256 to 
RGB colour palette, while TP7's represents EGA's 16-64 palette. My 
proposal is to rename:


MaxColor - RGBPaletteMaxColor
PaletteType - RGBPaletteType
SetAllPalette - SetAllRGBPalette
GetPalette - GetAllRGBPalette
GetDefaultPalette - GetDefaultRGBPalette
GetPaletteSize - GetRGBPaletteSize (this one might be unnecessary - 
will have to check if GetPaletteSize already returns the same values as 
TP7; we might still introduce GetRGBPaletteSize for consistency with the 
other RGBPalette procedures/functions, though)


and then introduce TP7-compatible MaxColors, PaletteType and 
procedures/functions. They'll be made optionally hookable (so the go32v2 
implementation will be able to implement them with the real EGA palette 
registers for maximum compatibility), with a default implementation that 
works on top of SetRGBPalette (similar to the way SetPalette is 
implemented now)


What do you think?
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] proposal for palette-related graph unit interface changes

[Nikolay Nikolov]

 On 09/15/2010 05:48 PM, Florian Klaempfl wrote:

Am 15.09.2010 16:39, schrieb Nikolay Nikolov:

and then introduce TP7-compatible MaxColors, PaletteType and
procedures/functions. They'll be made optionally hookable (so the go32v2
implementation will be able to implement them with the real EGA palette
registers for maximum compatibility), with a default implementation that
works on top of SetRGBPalette (similar to the way SetPalette is
implemented now)

What do you think?

But this will break existing FPC code, right? I'am also not sure if the
palettes as they are done were invented for other OSes e.g. Amiga or Atari
Yes, it'll break existing FPC code (but will also improve TP7 
compatibility), that's why I want to discuss it with you, before making 
these changes. Regarding Amiga and Atari - I already checked: Atari 
doesn't seem to have a graph unit implementation; Amiga defines it's own 
PaletteType and does not include graphh.inc at all, so it should not be 
affected by the changes at all. All the other platforms use the palettes 
in graphh.inc and will be affected. Yes, existing fpc code will have to 
be fixed, but I suspect in most cases it would be doable with a simple 
find/replace, because we'll keep all the current VGA palette 
functionality, it'll only have different names.

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

Re: [fpc-devel] proposal for palette-related graph unit interface changes

[Nikolay Nikolov]

 On 09/15/2010 06:27 PM, Tomas Hajny wrote:

On Wed, September 15, 2010 16:39, Nikolay Nikolov wrote:

   Currently, the following palette-related things from the fpc graph
unit aren't TP7 compatible:

MaxColors (constant)
PaletteType (record)

procedure SetAllPalette(const Palette: PaletteType);
procedure GetPalette(var Palette: PaletteType);
function GetPaletteSize: smallint;
procedure GetDefaultPalette(var Palette: PaletteType);

  .
  .

so the main difference is that fpc's PaletteType represents a VGA 256 to
RGB colour palette, while TP7's represents EGA's 16-64 palette. My
proposal is to rename:

MaxColor -  RGBPaletteMaxColor
PaletteType -  RGBPaletteType
SetAllPalette -  SetAllRGBPalette
GetPalette -  GetAllRGBPalette
GetDefaultPalette -  GetDefaultRGBPalette
GetPaletteSize -  GetRGBPaletteSize (this one might be unnecessary -
will have to check if GetPaletteSize already returns the same values as
TP7; we might still introduce GetRGBPaletteSize for consistency with the
other RGBPalette procedures/functions, though)

  .
  .

Regardless of outcomes of discussion whether some change would be
appropriate at all or not, I believe that it may be better not to rename
the existing procedures and functions using the PaletteType but rather
provide overloaded versions of those calls.
This could work for some of the functions, but not all of them. The 
problematic one is SetAllPalette, which is defined in TP7 as:


procedure SetAllPalette(var Palette);

which is, unfortunately, very evil, because it won't catch the error at 
compile time if you pass the wrong type :(


But it might not be necessary to introduce it exactly like that. Using a 
typed variable will probably work with 99.9% of the TP7 code?

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

Re: [fpc-devel] proposal for palette-related graph unit interface changes

[Nikolay Nikolov]

 On 09/15/2010 05:39 PM, Nikolay Nikolov wrote:
 Currently, the following palette-related things from the fpc graph 
unit aren't TP7 compatible:


...

What do you think?
There are also 2 other palette-related incompatibilities, that I'd also 
like to fix. They're relatively independent from the 
PaletteType/RGBPaletteType issue.


1. SetRGBPalette's range of values for RedValue, GreenValue and 
BlueValue is 0..63 in TP7 and 0..255 in FPC. So to set the background to 
bright red, in TP7 you would use:


SetRGBPalette(0, 63, 0, 0)

but this would set it to only dark red in FPC, where you have to use:

SetRGBPalette(0, 255, 0, 0)

this could be supported with a global boolean variable, that enables or 
disables the extended DAC range. E.g:


ExtendedRGBPaletteRange := true; { use 0..255 range }
ExtendedRGBPaletteRange := false; { use 0..63 range }

This can be implemented without any change to the platform-specific 
drivers, i.e. TModeInfo.SetRGBPalette and TModeInfo.GetRGBPalette will 
continue to only support the range 0..255 and not care about the 
ExtendedRGBPaletteRange flag. However, we'll add new front-end wrapper 
functions, that'll check the flag and convert the data, if necessary, 
before calling the internal Set/GetRGBPalette functions:


procedure SetRGBPalette(ColorNum, RedValue, GreenValue, BlueValue: 
smallint);

begin
  if not ExtendedRGBPaletteRange then
  begin
RedValue := (RedValue and 63) shl 2;
GreenValue := (RedValue and 63) shl 2;
BlueValue := (RedValue and 63) shl 2;
  end;
  InternalSetRGBPalette(ColorNum, RedValue, GreenValue, BlueValue);
end;

2. The second one's trickier and affects SetRGBPalette in 16-colour 
modes. In FPC, to set the RGB palette value of a colour number ColorNum 
(in [0..15]) you simply use:


SetRGBPalette(ColorNum, R, G, B)

in TP7, you have to do something like:

SetRGBPalette(DefaultEGAPalette[ColorNum], R, G, B)

where DefaultEGAPalette is (0, 1, 2, 3, 4, 5, 20, 7, 56, 57, 58, 59, 60, 
61, 62, 63) for most EGA/VGA and VESA 16-colour modes, with the 
exception of modes 0Dh - 320x200x16 (not supported by BGI or FPC as of 
now) and 0Eh - 640x200x16 (supported by both BGI and FPC - driver VGA, 
mode VGALo), where DefaultEGAPalette is (0, 1, 2, 3, 4, 5, 6, 7, 16, 17, 
18, 19, 20, 21, 22, 23). These EGA palettes can be obtained in TP7, 
using GetDefaultPalette or GetPalette. You can also decide to combine 
SetPalette and SetRGBPalette to produce all sorts of tricks.


This could also be emulated in front-end wrapper functions and we could 
also add a flag to turn the EGA palettes off, but the code would be 
trickier.

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

Re: [fpc-devel] UTF-8 patch for the video unit

[Nikolay Nikolov]

On 09/19/2009 05:16 PM, Olivier Coursiere wrote:
Nice ! What used to be a hack for the limited BeOS terminal now become 
a feature.
Well, initially I was just trying to fix the feature that switched the 
linux console out of UTF-8 mode, which caused most non-ascii characters 
to look wrong (if your locale uses UTF-8 encoding, which most modern 
linux distros use) after you've run the IDE and then exited it. So I 
tried to figure out how to detect whether the console was in UTF-8 mode, 
so that it can be restored on exit, but found out there's no other way, 
besides looking at the LANG environment variable. So, while figuring 
this out, I saw that beos used utf-8 output, so I decided to try to 
adapt this feature to linux and other unices and see how it looks. So no 
switching in/out of utf-8 mode, no switching between normal and 
graphical character sets, no redefining the low 32 special ascii 
characters, no modes of any kind, etc... And it turned out perfect, 
especially on graphical terminals (xterm, gnome-terminal, konsole). :)
I will probably tune the new TerminalSupportsHighIntensityColors and 
TerminalSupportsBold variable later this weekend to achieve the best 
results under BeOS and Haiku.
Yep, I intentionally made it flexible, so it can be tuned for different 
terminals.


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


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

[fpc-devel] fpsignal broken on linux-x86_64 (+patch)

[Nikolay Nikolov]

Hi

On linux-x86_64, programs have odd behaviour after a signal handler, 
installed with fpsignal is invoked. The handler executes fine and after 
it finishes, the program either crashes or terminates. Attached program 
demonstrates this, when run on linux-x86_64. After some debugging, I 
found out the cause - the fpsignal function in rtl/unix/bunxovl.inc sets 
sa.sa_flags to (SA_SIGINFO or SA_RESTORER); (SA_RESTORER is $400). 
Then fpsigaction (in rtl/linux/ossysc.inc) is called, which checks 
whether both SA_RESTORER and SA_ONSTACK flags are 0. If they are, on 
certain architectures (ifdef NEED_USER_TRAMPOLINE) fpsigaction sets the 
SA_RESTORER flag to 1 and sets new_action^.sa_restorer to a restorer 
trampoline procedure which calls sigreturn or rt_sigreturn (depending on 
arch and SA_RESTORER flag). However, on x86_64, SA_RESTORER is already 
set by the caller (fpsignal), which causes the check inside fpsigaction 
(whether both SA_RESTORER _and_ SA_ONSTACK bits are zero) to return 
false and the trampoline isn't installed. Still the SA_RESTORER flag is 
passed to the kernel, but the new_action^.sa_restorer address is not 
initialized, leading to crashes or odd behaviour. My patch removes all 
the ifdefs in fpsignal, since they're IMHO meaningless now. I'm not 100% 
sure what are they trying to achieve, but I guess it was written before 
fpsigaction was changed to install its own restorer trampolines. 
SA_SIGINFO is IMHO also not needed, since it doesn't change the 
trampoline used (on x86_64  and i386; on i386 it does, but then the 
caller fpsignal doesn't set SA_SIGINFO; on x86_64, the trampoline is 
only one and is not affected by SA_SIGINFO; on arm - I'm not 100% sure; 
on sparc - no trampolines). To summarize, here's the impact of the patch:


it only affects the fpsignal function and not fpsigaction

linux-i386 - no change and works - tested on Fedora 11 
(2.6.29.6-217.2.16.fc11.i686.PAE) and Debian 5.0.2 (2.6.26-2-xen-amd64 - 
32-bit binary, under a 64-bit kernel)
linux-x86_64 - was previously broken, now fixed; tested on Fedora 11 
(2.6.29.6-217.2.16.fc11.x86_64) and Debian 5.0.2 (2.6.26-2-xen-amd64)

linux-ppc - no change (in theory)
linux-ppc64 - no change (in theory)
linux-arm - needs testing; might break something
linux-sparc - needs testing; might break something

other unices - i386, ppc, ppc64 - no change (in theory)
other unices - x86_64, arm, sparc (are there any?) - also need testing

I've also attached a C program, that does the same thing as the pascal 
test program, so both can be run with strace and the syscalls called 
from glibc and fpc's rtl can be compared.
program TestSignal;

uses
  BaseUnix;

{$MODE objfpc}

var
  Ok: Boolean;

procedure signal_handler(sig: LongInt); cdecl;
begin
  Writeln('4');
  Ok := True;
end;

var
  Pid: pid_t;
begin
  Ok := False;
  Writeln('1');
  fpsignal(SIGUSR1, @signal_handler);
  Writeln('2');
  Pid := fpgetpid;
  Writeln('3');
  fpkill(Pid, SIGUSR1);

  repeat
  until Ok;

  Writeln('5');
  Writeln('done');
end.
Index: rtl/unix/bunxovl.inc
===
--- rtl/unix/bunxovl.inc	(revision 13645)
+++ rtl/unix/bunxovl.inc	(working copy)
@@ -13,10 +13,6 @@
 
  **}
 
-{$if defined(CPUARM) or defined(CPUX86_64) or defined(CPUSPARC)}
-  {$define RTSIGACTION}
-{$endif}
-
 {$I textrec.inc}
 {$I filerec.inc}
 
@@ -161,13 +157,6 @@
  {restart behaviour needs libc}
   sa.sa_flags :=sa.sa_flags or SA_RESTART;
 }
-{$ifdef RTSIGACTION}
-  sa.sa_flags:=SA_SIGINFO
-{$ifdef cpux86_64}
- or $400
-{$endif cpux86_64}
-  ;
-{$endif RTSIGACTION}
  FPSigaction(signum,@sa,@osa);
  if fpgetErrNo0 then
fpsignal:=NIL
#include stdio.h
#include signal.h
#include unistd.h

int Ok;

void signal_handler(int sig)
{
	printf(4\n);
	Ok = 1;
}

int main()
{
	Ok = 0;
	printf(1\n);
	signal(SIGUSR1, signal_handler);
	printf(2\n);
	pid_t pid = getpid();
	printf(3\n);
	kill(pid, SIGUSR1);
	
	while (!Ok) { }

	printf(5\n);
printf(done\n);
}
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] fpsignal broken on linux-x86_64 (+patch)

[Nikolay Nikolov]

Submitted a bug report:

http://bugs.freepascal.org/view.php?id=14514
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] UTF-8 patch for the video unit

[Nikolay Nikolov]

Hi all,

spent some time today, trying to make the text mode IDE look pretty 
under modern Linuxes and here's the result - a patch for UTF-8 console 
output. Previously, only BeOS used UTF-8. Tested with:


- the linux console
- xterm
- gnome-terminal
- konsole
- rxvt-unicode

all under Fedora 11. Known features:

- high intensity colours were actually normal intensity, with a bold 
attribute set. This worked fine under gnome-terminal, but xterm didn't 
have bold versions of all cp437 characters, which screwed up the window 
borders in the IDE. And although konsole had them, I didn't like the 
font - it converted all the double window borders to a very thick 
single-line border. So I disabled the bolding of high intensity colours 
in all X11 terminals (TERM=xterm) and replaced it with another ANSI 
attribute, that actually sets high intensity colours, but is not (in 
theory) supported by all terminals. The linux console doesn't support it 
- it actually wants a bold attribute, to set high intensity, so that's 
why I enabled it only for X11 terminals. All the ones, that I tried, 
worked fine (xterm, gnome-terminal, konsole, rxvt-unicode, also the 
plain old rxvt, with a non-UTF-8 locale).
- Fedora 11 by default uses a 512-characters font, called 
latarcyrheb-sun16 for the linux text mode console, which disables the 
high intensity colours, effectively reducing the set of available 
colours to only 8. This is a hardware limitation of the VGA hardware and 
can be avoided by using a 256-character font. It does not need to be 
cp437, but it has to have an unicode mapping.
- I haven't tried other linux distros (and unix-like OSes, i.e. FreeBSD 
and Mac OS X) - although they should work in theory, they might look 
bad, due to different fonts, etc.
Index: rtl/unix/video.pp
===
--- rtl/unix/video.pp	(revision 13607)
+++ rtl/unix/video.pp	(working copy)
@@ -41,7 +41,8 @@
  iso10, {ISO 8859-10}
  iso13, {ISO 8859-13}
  iso14, {ISO 8859-14}
- iso15);{ISO 8859-15}
+ iso15, {ISO 8859-15}
+ utf8); {UTF-8}
 
 const  {Contains all code pages that can be considered a normal vga font.
 Note: KOI8-R has line drawing characters in wrong place. Support
@@ -245,6 +246,9 @@
   ACSOut : string = '';
   in_ACS : boolean =false;
 
+  TerminalSupportsHighIntensityColors: boolean = false;
+  TerminalSupportsBold: boolean = true;
+
 function convert_vga_to_acs(ch:char):word;
 
 {Ch contains a character in the VGA character set (i.e. codepage 437).
@@ -453,16 +457,17 @@
   OFg:=OAttr and $f;
   OBg:=OAttr shr 4;
   attr2ansi:=#27'[';
-  if fg and 80 then
-begin
-  {Enable bold if not yet on.}
-  if ofg and 8=0 then
-attr2ansi:=attr2ansi+'1;';
-end
-  else
-{Disable bold if on.}
-if ofg and 80 then
-  attr2ansi:=attr2ansi+'22;';
+  if TerminalSupportsBold then
+if fg and 80 then
+  begin
+{Enable bold if not yet on.}
+if ofg and 8=0 then
+  attr2ansi:=attr2ansi+'1;';
+  end
+else
+  {Disable bold if on.}
+  if ofg and 80 then
+attr2ansi:=attr2ansi+'22;';
   if bg and 80 then
 begin
   {Enable bold if not yet on.}
@@ -474,8 +479,19 @@
 if obg and 80 then
   attr2ansi:=attr2ansi+'25;';
 
-  if fg and 7ofg and 7 then
- attr2ansi:=attr2ansi+'3'+ansitbl[fg and 7]+';';
+  if TerminalSupportsHighIntensityColors then
+  begin
+if fg and 15ofg and 15 then
+  if fg and 80 then
+attr2ansi:=attr2ansi+'9'+ansitbl[fg and 7]+';'
+  else
+attr2ansi:=attr2ansi+'3'+ansitbl[fg and 7]+';';
+  end
+  else
+  begin
+if fg and 7ofg and 7 then
+  attr2ansi:=attr2ansi+'3'+ansitbl[fg and 7]+';';
+  end;
   if bg and 7obg and 7 then
  attr2ansi:=attr2ansi+'4'+ansitbl[bg and 7]+';';
 
@@ -624,7 +640,7 @@
 case c of
   #0..#31:
 converted:=convert_lowascii_to_UTF8[c];
-  #128..#255:
+  #127..#255:
 converted:=convert_cp437_to_UTF8[c];
   else
   begin
@@ -942,6 +958,18 @@
   TCSetAttr(1,TCSANOW,tio);
 end;
 
+function UTF8Enabled: Boolean;
+var
+  lang:string;
+begin
+  {$ifdef BEOS}
+  UTF8Enabled := true;
+  exit;
+  {$endif}
+  lang:=upcase(fpgetenv('LANG'));
+  UTF8Enabled := (Pos('.UTF-8', lang)  0) or (Pos('.UTF8', lang)  0);
+end;
+
 procedure decide_codepages;
 
 var s:string;
@@ -970,6 +998,11 @@
   internal_codepage:=cp852;
 iso05:   {Cyrillic}
   internal_codepage:=cp866;
+utf8:
+  begin
+internal_codepage:=cp437;
+convert:=cv_cp437_to_UTF8;
+  end;
 else
   if internal_codepage in vga_codepages then
 internal_codepage:=external_codepage
@@ -978,9 +1011,6 @@
  437 in the hope that the actual font has similarity to codepage 437.}
 

Re: [fpc-devel] patch to call DoneKeyboard in the exitproc of the drivers unit

[Nikolay Nikolov]

On 08/16/2009 04:29 PM, Daniël Mantione wrote:
I can see the issue with abnormal program exits, but I disabled it 
because calling it twice had unintended effects. So we need to verify 
we don't break anything.

Well, I can think of 2 thing that could go wrong:

- DoneKeyboard is called _after_ DoneVideo (not before) in 
TApplication.Done. I'm not sure if the order matters. We can switch them 
in the Drivers unit ExitProc also.
- If DoneKeyboard blows up with a run time error, during a normal 
TApplication.Done call, then the ExitProc of the Drivers unit will call 
DoneKeyboard again, which in turn will call SysDoneKeyboard again, 
because the previous SysDoneKeyboard didn't finish and the 
KeyboardInitialized flag wasn't set to false. I don't know if this might 
have unintended side effects. This is all in rtl/inc/keyboard.inc:


procedure DoneKeyboard;

begin

  If KeyboardInitialized then

begin

If Assigned(CurrentKeyBoardDriver.DoneDriver) Then

  CurrentKeyBoardDriver.DoneDriver();

KeyboardInitialized:=False;

end;

end;


If that's the case, we can add a flag KeyboardInitialized in Drivers, 
add a check inside Drivers.DoneKeyboard and set it to false _before_ the 
actual call to Keyboard.DoneKeyboard.

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

[fpc-devel] patch to call DoneKeyboard in the exitproc of the drivers unit

[Nikolay Nikolov]

Does anyone have an idea why the call to DoneKeyboard was previously 
commented? It leaves the keyboard in a bad state if the IDE crashes.
Index: packages/fv/src/drivers.pas
===
--- packages/fv/src/drivers.pas	(revision 13526)
+++ packages/fv/src/drivers.pas	(working copy)
@@ -855,7 +855,7 @@
 BEGIN
DoneSysError;  { Relase error trap }
DoneEvents;{ Close event driver }
-{   DoneKeyboard;}
+   DoneKeyboard;
DoneVideo;
ExitProc := SaveExit;  { Restore old exit }
 END;
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] patch to call DoneKeyboard in the exitproc of the drivers unit

[Nikolay Nikolov]

On 08/16/2009 03:22 PM, Daniël Mantione wrote:



Op Sun, 16 Aug 2009, schreef Jonas Maebe:



On 16 Aug 2009, at 12:15, Nikolay Nikolov wrote:

Does anyone have an idea why the call to DoneKeyboard was previously 
commented? It leaves the keyboard in a bad state if the IDE crashes.


It was changed in revision 3443, whose log message says:

r3443 | daniel | 2006-05-07 00:57:20 +0200 (Sun, 07 May 2006) | 3 lines
Changed paths:
 M /trunk/fv/app.pas
 M /trunk/fv/drivers.pas
 M /trunk/fv/validate.pas
 M /trunk/ide/fp.pas
 M /trunk/ide/fpide.pas

* Video and keyboard initialization spaghetti organized and hopefully 
fixed.

- Remove useless function from validate.pas

Maybe Daniel knows.


In Turbo Vision, it is the task of Tapplication to initialize drivers 
and the task of Tprogram to detect how it was initialized. This was 
totally messed up; i.e. Tprogram.initscreen is supposed to detect the 
current screen, but people had inserted code into it that did change 
the screen, so they also invented a donescreen. This caused a lot of 
bugs inside FV applications.


With this patch, I brought things back as they should be, all 
intialization/finalization back to Tapplication and Tprogram just 
detects how things are initialized.
This is all cool, but IMHO DoneKeyboard should also be called in the 
ExitProc to clean things up in case a runtime error occurs, since then 
the TApplication destructor isn't (usually) called. Is there a reason 
not to do that? Calling DoneKeyboard twice on normal exit should be 
safe, as it checks a flag and does nothing when you call it the second time.

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

[fpc-devel] Microsoft Game API header translation for Windows CE

[Nikolay Nikolov]

For more information about GAPI:
http://msdn2.microsoft.com/en-us/library/aa459123.aspx

You may add this unit to the fpc wince rtl, if you want.
Unit gx;

{$MODE objfpc}

{ convention is cdecl for WinCE API}
{$calling cdecl}

Interface

Uses
  Windows;

Const
  GXDLL = 'gx';

Type
  GXDisplayProperties = Record
cxWidth : DWord;
cyHeight : DWord;// notice lack of 'th' in the word height.
cbxPitch : LONG; // number of bytes to move right one x pixel - 
can be negative.
cbyPitch : LONG; // number of bytes to move down one y pixel - 
can be negative.
cBPP : LONG; // # of bits in each pixel
ffFormat : DWord;// format flags.
  End;

  GXKeyList = Record
vkUp : SHORT; // key for up
ptUp : POINT; // x,y position of key/button.  Not on screen but 
in screen coordinates.
vkDown : SHORT;
ptDown : POINT;
vkLeft : SHORT;
ptLeft : POINT;
vkRight : SHORT;
ptRight : POINT;
vkA : SHORT;
ptA : POINT;
vkB : SHORT;
ptB : POINT;
vkC : SHORT;
ptC : POINT;
vkStart : SHORT;
ptStart : POINT;
  End;

Function GXOpenDisplay(AhWnd : HWND; dwFlags : DWORD) : Integer; External GXDLL 
Name '?GXOpenDisplay@@YAHPAUHWND__@@[EMAIL PROTECTED]';
Function GXCloseDisplay : Integer; External GXDLL Name '?GXCloseDisplay@@YAHXZ';
Function GXBeginDraw : Pointer; External GXDLL Name '?GXBeginDraw@@YAPAXXZ';
Function GXEndDraw : Integer; External GXDLL Name '?GXEndDraw@@YAHXZ';
Function GXOpenInput : Integer; External GXDLL Name '?GXOpenInput@@YAHXZ';
Function GXCloseInput : Integer; External GXDLL Name '?GXCloseInput@@YAHXZ';
Function GXGetDisplayProperties : GXDisplayProperties; External GXDLL Name 
'?GXGetDisplayProperties@@YA?AUGXDisplayProperties@@XZ';
Function GXGetDefaultKeys(iOptions : Integer) : GXKeyList; External GXDLL Name 
'?GXGetDefaultKeys@@YA?AUGXKeyList@@[EMAIL PROTECTED]';
Function GXSuspend : Integer; External GXDLL Name '?GXSuspend@@YAHXZ';
Function GXResume : Integer; External GXDLL Name '?GXResume@@YAHXZ';
Function GXSetViewport(dwTop, dwHeight, dwReserved1, dwReserved2 : DWORD) : 
Integer; External GXDLL Name '?GXSetViewport@@[EMAIL PROTECTED]';
Function GXIsDisplayDRAMBuffer : BOOL; External GXDLL Name 
'?GXIsDisplayDRAMBuffer@@YAHXZ';


// Although these flags can be unrelated they still
// have unique values.

Const
  GX_FULLSCREEN= $01;// for OpenDisplay()
  GX_NORMALKEYS= $02;
  GX_LANDSCAPEKEYS = $03;

  kfLandscape  = $8;// Screen is rotated 270 degrees
  kfPalette= $10;   // Pixel values are indexes into a palette
  kfDirect = $20;   // Pixel values contain actual level information
  kfDirect555  = $40;   // 5 bits each for red, green and blue values 
in a pixel.
  kfDirect565  = $80;   // 5 red bits, 6 green bits and 5 blue bits per 
pixel
  kfDirect888  = $100;  // 8 bits each for red, green and blue values 
in a pixel.
  kfDirect444  = $200;  // 4 red, 4 green, 4 blue
  kfDirectInverted = $400;

  GETRAWFRAMEBUFFER = $00020001;

Type
  RawFrameBufferInfo = Record
wFormat : WORD;
wBPP : WORD;
pFramePointer : Pointer;
cxStride : Integer;
cyStride : Integer;
cxPixels : Integer;
cyPixels : Integer;
  End;

Const
  FORMAT_565   = 1;
  FORMAT_555   = 2;
  FORMAT_OTHER = 3;

Implementation

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

[fpc-devel] patch for unit sockets

[Nikolay Nikolov]

SocketError should be a threadvar, I think
Index: rtl/inc/socketsh.inc
===
--- rtl/inc/socketsh.inc(revision 2308)
+++ rtl/inc/socketsh.inc(working copy)
@@ -152,7 +152,7 @@
   TSockArray = Array[1..2] of Longint;  //legacy
 
 
-Var
+threadvar
   SocketError:cint;
 
 function  fpsocket  (domain:cint; xtype:cint; protocol: cint):cint;
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] patch for unit sockets

[Nikolay Nikolov]

Marco van de Voort wrote:


SocketError should be a threadvar, I think
   



Socketerror is legacy. Use fpgeterrno (or errno) to get the error.

1.0.x had no threadsupport


Yes, but there's no fpgeterrno in win32 :)

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

Re: [fpc-devel] PR advancement

[Nikolay Nikolov]

Adriaan van Os wrote:


P.S.
Here is a text, specially for managers, applicable for any tech project:

Blah blah ... de facto standard ... Blah blah ... highly committed ... 
Blah bah ... industrial strength ... Blah blah ... world class support 
... Blah blah ... handholding ... Blah blah ... support contract  
Blah blah ... even more handholding ... Blah blah  cutting edge 
technology  Blah blah  etcetera.


You forgot 'scalable enterprise solutions' :)

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

[fpc-devel] X11/cursorfont.h header translation

[Nikolay Nikolov]

X11/cursorfont.h header translation. Yes, it's one of the standard 
headers of the official Xlib :)
{ $Xorg: cursorfont.h,v 1.4 2001/02/09 02:03:39 xorgcvs Exp $ }
{

Copyright 1987, 1998  The Open Group

Permission to use, copy, modify, distribute, and sell this software and its
documentation for any purpose is hereby granted without fee, provided that
the above copyright notice appear in all copies and that both that
copyright notice and this permission notice appear in supporting
documentation.

The above copyright notice and this permission notice shall be included
in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
IN NO EVENT SHALL THE OPEN GROUP BE LIABLE FOR ANY CLAIM, DAMAGES OR
OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
OTHER DEALINGS IN THE SOFTWARE.

Except as contained in this notice, the name of The Open Group shall
not be used in advertising or otherwise to promote the sale, use or
other dealings in this Software without prior written authorization
from The Open Group.

}

unit cursorfont;

interface

const
  XC_num_glyphs = 154;
  XC_X_cursor = 0;
  XC_arrow = 2;
  XC_based_arrow_down = 4;
  XC_based_arrow_up = 6;
  XC_boat = 8;
  XC_bogosity = 10;
  XC_bottom_left_corner = 12;
  XC_bottom_right_corner = 14;
  XC_bottom_side = 16;
  XC_bottom_tee = 18;
  XC_box_spiral = 20;
  XC_center_ptr = 22;
  XC_circle = 24;
  XC_clock = 26;
  XC_coffee_mug = 28;
  XC_cross = 30;
  XC_cross_reverse = 32;
  XC_crosshair = 34;
  XC_diamond_cross = 36;
  XC_dot = 38;
  XC_dotbox = 40;
  XC_double_arrow = 42;
  XC_draft_large = 44;
  XC_draft_small = 46;
  XC_draped_box = 48;
  XC_exchange = 50;
  XC_fleur = 52;
  XC_gobbler = 54;
  XC_gumby = 56;
  XC_hand1 = 58;
  XC_hand2 = 60;
  XC_heart = 62;
  XC_icon = 64;
  XC_iron_cross = 66;
  XC_left_ptr = 68;
  XC_left_side = 70;
  XC_left_tee = 72;
  XC_leftbutton = 74;
  XC_ll_angle = 76;
  XC_lr_angle = 78;
  XC_man = 80;
  XC_middlebutton = 82;
  XC_mouse = 84;
  XC_pencil = 86;
  XC_pirate = 88;
  XC_plus = 90;
  XC_question_arrow = 92;
  XC_right_ptr = 94;
  XC_right_side = 96;
  XC_right_tee = 98;
  XC_rightbutton = 100;
  XC_rtl_logo = 102;
  XC_sailboat = 104;
  XC_sb_down_arrow = 106;
  XC_sb_h_double_arrow = 108;
  XC_sb_left_arrow = 110;
  XC_sb_right_arrow = 112;
  XC_sb_up_arrow = 114;
  XC_sb_v_double_arrow = 116;
  XC_shuttle = 118;
  XC_sizing = 120;
  XC_spider = 122;
  XC_spraycan = 124;
  XC_star = 126;
  XC_target = 128;
  XC_tcross = 130;
  XC_top_left_arrow = 132;
  XC_top_left_corner = 134;
  XC_top_right_corner = 136;
  XC_top_side = 138;
  XC_top_tee = 140;
  XC_trek = 142;
  XC_ul_angle = 144;
  XC_umbrella = 146;
  XC_ur_angle = 148;
  XC_watch = 150;
  XC_xterm = 152;

implementation

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

Re: [fpc-devel] broken shmat on x86_64-linux

[Nikolay Nikolov]

Jonas Maebe wrote:



On 29 sep 2005, at 22:35, Florian Klaempfl wrote:

Can anybody who understand the patch, apply it ;)? Does ir work for  
i386

too?



Patch looks ok according to what I see in the man page of shmat on a  
x86-64 box here. It just seems error checking (via errno) is missing  
(but that was already the casein the original function as well).


Error checking is done in do_syscall.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] broken shmat on x86_64-linux

[Nikolay Nikolov]

The 'shmat' function from the 'ipc' unit seems to be broken on 
x86_64-linux. This patch seems to fix it.

(Apply to rtl/linux/ipcsys.inc)
35,36d34
 Var raddr : pointer;
 error : ptrint;
38,42c36
   error:=do_syscall(syscall_nr_SHMAT,TSysParam(shmid),TSysParam(shmflg),TSysParam(@raddr),TSysParam(shmaddr));
   If Error0 then
 shmat:=pointer(error)
   else
 shmat:=raddr;
---
   shmat:=pointer(do_syscall(syscall_nr_SHMAT,TSysParam(shmid),TSysParam(shmaddr),TSysParam(shmflg)));
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

[fpc-devel] header translation for the X Window System video extension

[Nikolay Nikolov]

you may add it to packages/extra/x11


x11.tar.gz
Description: GNU Zip compressed data
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] PPC64 port

[Nikolay Nikolov]

Florian Klaempfl wrote:
I think it depends if other people are working on it as well.
 

How many people are working on it?
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] integer, cardinal

[Nikolay Nikolov]

Ales Katona wrote:
I think that pascal typesystem requires a bit overhaul when it comes 
to integers.

First of all Integer should be size independent, that is, xy bits 
depending on the platform. All others should be specific.

Second, we should force people in a friendly way to use more 
readible names like:
sint32, uint64, etc. than cardinal
In a few years when 64 bits are normal, what will cardinal become? who 
knows..

just one big IMHO
Ales
I like the way it is:
unsigned integers:
byte (8-bit)
word (16-bit)
dword (32-bit)
qword (64-bit)
and signed:
shortint (8-bit)
smallint (16-bit)
longint (32-bit)
int64 (64-bit)
The unsigned versions have either 'byte' or 'word' in their name, and 
the signed have 'int'. (I prefer to use 'dword' instead of 'cardinal') 
Even on 64-bit systems always using 64-bit integers is a waste of 
memory. The problem with the 16-bit int was that the range 
-32768..+32767 was too small, and people often needed to use 32-bit, 
even though it was slower. Nowadays numbers outside the range of longint 
are rarely needed, and when needed, one can always use int64/qword or 
even redefine integer to be 64-bit :)

Also using mode  objfpc and delphi should be only for compatibility 
reasons. The overhead in using mode objfpc is almost nil. (only unit 
objfpc is included, and it is rather small) Now if you add uses sysutils 
or classes, then the program gets larger, but that has nothing to do 
with mode objfpc.

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