Re: [fpc-pascal] TurboVision is reborn as FOSS (again)

[Karoly Balogh (Charlie/SGR) via fpc-pascal]

Hi,

On Mon, 21 Dec 2020, Sven Barth via fpc-pascal wrote:

> As long as one knows why a certain temporal construct is used there is
> no problem and at least in Germany (or more specifically Bavaria) we
> were taught that in masses. 

As a native speaker of a language which only has three tenses and no
grammatical gender, it's difficult to decide if the twelve tenses of
English, or the three genders of German are the more confusing. :P
(Probably still the latter, tho'... ;) )

Anyway, any interest to develop Free Vision further is very welcome one,
so we can move it from past tense to a future one. I still think text mode
UI for console and terminals still has a place, but sadly the current FV
implementation doesn't necessarily plays well on some Un*x terminals (it's
highly dependent on the font, and many other factors), also a mono mode is
sorely missing, which is a problem for both some modern and retro use
cases. And yeah, on the high-end, Unicode would be needed.

Charlie___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Error compiling on AROS/m68k: 1980-0-0 is not a valid date specification

[Karoly Balogh (Charlie/SGR) via fpc-pascal]

Hi Charlie,

On Fri, 18 Dec 2020, Karoly Balogh (Charlie/SGR) via fpc-pascal wrote:

> > I also see that the pre-installed version was installed with the clock
> > in the system was set to the start of the Amiga Time (1.1.1978). Might
> > that create a problem?
>
> Actually, yes. If I reset the timestamp of the system unit to 1978-1-1,
> 00:00:00 (the start of the Amiga Epoch), I can reproduce the issue on my
> system and installation (which is a real '060 + AmigaOS 3.1).

So the root cause is, Amiga follows the non-Unix codepath for
DateTimeToFileDate inside the sysutils unit, which is artificially limited
to dates between 1980 and 2099:

https://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/rtl/objpas/sysutils/dati.inc?annotate=47808#l1260

This is super old code, it was already there 15 years ago, at the time of
the SVN import... I guess the original intention was to keep us
compatibile with MSDOS/old FAT file timestamps, which can actually
represent dates between 1980 and 2107. (So no idea where 2099 comes
from... Because Windows actually counts file dates from 1601 (fix me?),
and more modern FSes no longer have the limitation mentioned above
anyway.)

Anyway, this means FileAge function for Amiga will return zero for dates
before 1980, which then causes various havoc down the line. More
specifically, later the compiler calls FileDateToDateTime from (see
globals.pas filetimestring()) to print a debug message into the verbose
log (normally thrown away, actually, but available as fpcdebug.txt with
the -vv parameter), which then blows up in sysutils/EncodeTime, because
zero is an invalid file timestamp actually as far s the MSDOS timestamp
format is concerned, because you get zero as day and month (and year too,
just the code adds 1980 anyway... :) )

Yuck. :P What a nice juicy can of worms... Found just because someone used
a buggy LhA to decompress Free Pascal on Amiga... :D

I'm not touching this for any other platform, because ... Just no. :D But
as the FileAge return value and the FileDate format should be OS specific,
on the mid-run I'll migrate the Amiga code away from the non-Unix
codepath, to something custom. Probably to something very similar to the
Unix codepath, but counting the Epoch from 1978-01-01 instead of
1970-01-01... Or a packed/smaller version of the AmigaOS DateStamp
structure. This has other advantages, for example the Amiga RTL will no
longer be limited to 2 seconds resolution when working with file
timestamps, another MS-DOS/FAT legacy coming from the generic code paths.

Thanks Carsten, for this report. As much as we usually get invalid reports
regarding the Vampire, this was genuinely useful.

For now, please use the workaround I mentioned in my previous e-mail,
because this will take a while to fix. I'll also try to get a quick fix
into the compiler, to make it not blow up with an exception at least,
because the compiler code seems to be prepared to work with invalid
timestamps otherwise.

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

Re: [fpc-pascal] Error compiling on AROS/m68k: 1980-0-0 is not a valid date specification

[Karoly Balogh (Charlie/SGR) via fpc-pascal]

Hi Carsten,

> > I also see that the pre-installed version was installed with the clock
> > in the system was set to the start of the Amiga Time (1.1.1978). Might
> > that create a problem?
>
> Actually, yes. If I reset the timestamp of the system unit to 1978-1-1,
> 00:00:00 (the start of the Amiga Epoch), I can reproduce the issue on my
> system and installation (which is a real '060 + AmigaOS 3.1). So this
> needs a two layer fix, first we need to fix it in our RTL, and second, it
> would be nice if the Apollo people could not screw up the timestamps as
> they install FPC into their distro. (They probably used a broken, older
> version of LHA to extract the package, which is know to cause exactly this
> issue. Or some Unix tool to package the OS install/image, which freaked
> out from the Amiga timestamps.)

As a workaround/local fix on your system, you can try to just reset all
file dates under the units/m68k-amiga/ to the current date. You can do
this with the "SetDate" command. If you don't give it a date argument,
only a file name (which can be a wildcard) it will reset the files'
timestamp to the current time/date.

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

Re: [fpc-pascal] Error compiling on AROS/m68k: 1980-0-0 is not a valid date specification

[Karoly Balogh (Charlie/SGR) via fpc-pascal]

Hi Carsten,

On Fri, 18 Dec 2020, Carsten Strotmann via fpc-pascal wrote:

> >> I've trying FPC on an Vampire 4 SA machine with ApolloOS/AROS
> >> m68k.
> >
> > Which version of FPC are you trying? Trunk, 3.2.0 stable, you built
> > your own, or you downloaded one of the official Amiga releases?
>
> it's the one that comes pre-installed with the Vampire 4 SA. I really
> like the fact that FPC comes pre-installed. It identifies itself as
> 3.2.0 (2020/06/13) (fpc binary is 112808 bytes)

The "fpc" binary is just a compiler frontend. The actual binary is called
"ppc68k", it must be hiding in there somewhere. The question is, is the
compiler binary uses the FPU or not. It's nice that they preinstalled FPC,
but it hardly got tested it seems.

> > No, this is most likely the Vampire 4 or more specifically its FPGA
> > CPU implementation ("Apollo core") being incompatible with a true
> > m68k. Are you trying to use the SoftFPU or the hardware FPU version?
>
> is there a way to get this information from the installed binaries? As
> FPC was pre-installed, I have no idea which version the Apollo developer
> used.

I think judging by the date, it's probably the 3.2.0 release, which should
be with the SoftFPU actually. But there's no way to tell without
disassembling the binary and see if there are FPU instructions in it... Or
trying to execute with the FPU disabled.

> I've downloaded 3.2.0a (SoftFPU) from the FreePascal website, and that
> version works fine. So it might be a HardFPU version.

Or might be not. See below.

> I also see that the pre-installed version was installed with the clock
> in the system was set to the start of the Amiga Time (1.1.1978). Might
> that create a problem?

Actually, yes. If I reset the timestamp of the system unit to 1978-1-1,
00:00:00 (the start of the Amiga Epoch), I can reproduce the issue on my
system and installation (which is a real '060 + AmigaOS 3.1). So this
needs a two layer fix, first we need to fix it in our RTL, and second, it
would be nice if the Apollo people could not screw up the timestamps as
they install FPC into their distro. (They probably used a broken, older
version of LHA to extract the package, which is know to cause exactly this
issue. Or some Unix tool to package the OS install/image, which freaked
out from the Amiga timestamps.)

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

Re: [fpc-pascal] Error compiling on AROS/m68k: 1980-0-0 is not a valid date specification

[Karoly Balogh (Charlie/SGR) via fpc-pascal]

Hi Carsten,

On Thu, 17 Dec 2020, Carsten Strotmann via fpc-pascal wrote:

> I've trying FPC on an Vampire 4 SA machine with ApolloOS/AROS
> m68k.

Which version of FPC are you trying? Trunk, 3.2.0 stable, you built your
own, or you downloaded one of the official Amiga releases?

> Whenever I try to compile a pascal program (simple "Hello World" style)
> the compiler stopps with an interal error message "Error: 1980-0-0 is
> not a valid date specification".
>
> My guess this is something between the OS (AROS/ApolloOS) and FPC.

No, this is most likely the Vampire 4 or more specifically its FPGA CPU
implementation ("Apollo core") being incompatible with a true m68k. Are
you trying to use the SoftFPU or the hardware FPU version? This matters,
because the TDateTime type maps to "Double" (64bit float) in the run time
library, and the most problematic part of that CPU core is known to be the
FPU, especially with higher precisions. The error you're getting is
definitely coming from one of the TDateTime helper functions in the
sysutils unit. (Search in rtl/objpas/sysutils/dati.inc.)

> Can anyone give me a clue how to debug this issue?

It's entirely a speculation from my part, but if I can judge it by my past
experiences trying to investigate issues reported by Vampire users, I
doubt there's anything to debug in FPC in this regard.

If you're using the hardware FPU version, try using the SoftFPU version
(which should be the default on m68k-amiga, actually).

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

Re: [fpc-pascal] FPC for FreeBSD/PowerPC64

[Karoly Balogh (Charlie/SGR) via fpc-pascal]

Hi,

On Sat, 12 Sep 2020, Curtis Hamilton via fpc-pascal wrote:

> I'm attempting to port FPC to Freebsd/PowerPC64  and need some help. 
>
> I've added initial code to get started.  However, when trying to cross 
> compile I'm getting an internal error message when the newly
> created cross compiler (ppcrossppc64) executes.
>
> /root/Downloads/fpc-3.2.0/compiler/ppcrossppc64 -Ur -Ppowerpc64 
> -XPpowerpc64-unknown-freebsd11.2- -Xr -XX -CX -Ur -Xs -O2 -n -Fi../inc
> -Fi../powerpc64 -Fi../unix -Fi../bsd -Fi../bsd/powerpc64 
> -Fi../freebsd/powerpc64 -FE.
> -FU/root/Downloads/fpc-3.2.0/rtl/units/powerpc64-freebsd -dpowerpc64 
> -dRELEASE -CaDEFAULT  -Us -Sg ../bsd/system.pp
> sysos.inc(69,12) Fatal: Internal error 2015021001
> Fatal: Compilation aborted
>
> Can someone help me decipher this? I've attached the fpc debug file, if that 
> will help.

You can just search the source for that IE number as string. It will
reveal, that you failed to specify a default ABI for the target system.
This error seems to be PPC64 specific.

See systems/t_linux.pas for an example, and do something similar in the
PPC64 FreeBSD port.

Cheers,
--
Charlie___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] ExecuteProcess problem

[Karoly Balogh (Charlie/SGR) via fpc-pascal]

Hi,

On Tue, 25 Aug 2020, Koenraad Lelong via fpc-pascal wrote:

> I'm extending an old daemon so it writes the data to MQTT, using
> mosquitto_pub.
>
> To have a correct message (-m ...) I need to include double-quotes. But
> it seems ExecuteProcess(exec,cmdline) splits the cmdline according some
> rules if it's a single string.
> When I tried to do it in a single string :
> -h 127.0.0.1 -t solartopic -u user -P secret -i clientid -m "{\"Pac\":
> 458.00}"
> I got :
> Error: Unknown option 'Pac\":'.
> So I need to make cmdline an array. How I do that ?
> I tried :
>   MQTTStr : array [0..5] of ansistring;
> ...
>   MQTTStr[0]:='-h '+MQTTBroker;
>   MQTTStr[1]:='-t '+MQTTTopic;
>   MQTTStr[2]:='-u '+MQTTUser;
>   MQTTStr[3]:='-P '+MQTTPassw;
>   MQTTStr[4]:='-i '+MQTTClientID;
>   MQTTStr[5]:='-m "{\"'+ChanName+'\": '+TextValue+'}"';
>   ExecuteProcess(MQTTExec,MQTTStr));
> But then :
> Error: Unknown option '-h 127.0.0.1'.
> Use 'mosquitto_pub --help' to see usage.
>
> Thanks in advance

Just a guess, but I think you need to do:

MQTTStr[0]:='-h';
MQTTStr[1]:=MQTTBroker;
MQTTStr[2]:='-t';
MQTTStr[3]:=MQTTTopic;

... etc.
MQTTStr[n]:='-m';
MQTTStr[n+1]:=MQTTMessage;


Like this. It's maybe a bit counter intuitive, but you have to think from
the perspective of the other app, everything which you put into 1 string
will go into 1 "slot" of its "ParamStr(x)". And then it's maybe more
obvious how you need to split your arguments.

BTW, shameless plug, but this is a very very hacky way to talk to an MQTT
broker I think, I've made a raw C header conversion, and a Pascal-style
multithreaded OOP wrapper for libmosquitto, so you can properly integrate
MQTT communication in your Free Pascal app (tested on Linux, MacOS and
Windows):

https://github.com/chainq/mosquitto-p

I'm not sure of the complexity of what you want to do, but for anything
remotely more complex, than sending 1 message every minute or so, this
might be a better solution than trying to squeeze things through
mosquitto_pub's arguments.

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

Re: [fpc-pascal] Bugs in StrToHostAddr6 in sockets unit

[Karoly Balogh (Charlie/SGR)]

Hi,

On Wed, 6 May 2020, Noel Duffy via fpc-pascal wrote:

> Testing would also have to be fairly rigorous to make sure all the
> different formats are handled correctly. I've already done some  work to
> make it easy to compare StrToHostAddr6's output to that of inet_pton in
> the C library, so this would at least provide a good method to quickly
> spot problems.
>
> So I guess the question is, is it worth the effort to make
> StrToHostAddr6 RFC4291 compliant? Is that something the FPC team would
> want,

Definitely yes. FPC is not a commercial "product", it's an open source
project, and contributions like this are the whole idea behind open
source, and makes projects like FPC actually viable. Note that the code
you're looking into is very old (almost 15 years old), and was a
contributed code in the first place, not written by the FPC team (see SVN
r939). And this also means it actually predates the RFC you refer to. :)
So it definitely needs an overhaul.

> or do they just not use the sockets unit?

As much as we use the compiler and associated libraries ourselves, we
can't cover every use case, or find every bug. A lot of packages are there
for completeness, or because someone submitted it, or for compatibility
with Delphi, not because we necessarily use it ourselves. So if you find
weak spots like this where you feel you can do better, do it and submit
it!

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

Re: [fpc-pascal] StrToHostAddr in sockets unit accepts negative octets

[Karoly Balogh (Charlie/SGR)]

Hi,

On Mon, 20 Apr 2020, Noel Duffy via fpc-pascal wrote:

> > I have already fixed it, with a simplistic fix, I think. Committed as
> > SVN r44845.
> >
> Great, good to know it's fixed. Not having the SVN repo to hand, I can't
> tell how recent that revision is. Has this change made it to any
> released version of the compiler?

No. I just fixed it yesterday. :) So the fix is new. I'll probably get it
merged to the soon-to-be released 3.2, if no one objects.

> If it hasn't then I will have to either roll a custom function or look
> to falling back on the system native libc's inet_pton function.

You can compile yourself a custom version of the sockets unit from current
trunk too in the mean time. Or you can even patch 3.0.4, if you want.
Here's what's changed:

https://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/packages/rtl-extra/src/inc/sockets.inc?r1=44845=44844=44845

Falling back to inet_pton() is also an option indeed, if your program
already links against libc (for threading or other reasons), that might be
the easiest option.

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

Re: [fpc-pascal] StrToHostAddr in sockets unit accepts negative octets

[Karoly Balogh (Charlie/SGR)]

Hi,

On Sun, 19 Apr 2020, Michael Van Canneyt wrote:

> > The StrToHostAddr function in the sockets unit accepts negative octets
> > in the source ip address. Consider this program:
>
> This should indeed be ckecked.
> Please report this in the bugtracker, so we don't forget to look at it!

I have already fixed it, with a simplistic fix, I think. Committed as SVN
r44845.

Basically it was wrapping everything in the longint number range silently
to a byte. So for example a string saying '172.300.32.14' was accepted as
IP 172.44.32.14. My patch fixes this too, not just the negatives, but
please feel free to verify, or improve on it if you feel like.

This was an ancient bug, the code in question was unchanged since SVN rev
1, so 2005 at least, but probably longer.

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

Re: [fpc-pascal] Wine + Unsupported ioctl

[Karoly Balogh (Charlie/SGR)]

Hi,

On Sat, 4 Apr 2020, Juha Manninen via fpc-pascal wrote:

> I installed FPC 3.2RC1 Win32 version under Wine in Linux Manjaro 64-bit.
> Wine version is a recent 5.5-1. Compiling a hello.lpr program works.
> (...)
 > Has anybody built Lazarus under Wine? Should I test with FPC 3.0.4? Is
> this somehow related to the new version? Or is it about 32 / 64 bits? I
> remember building Lazarus under Wine some years ago but then I installed
> from Lazarus installer and later created a symlink for trunk sources.

Sorry for my ignorance, but why do you add an extra emulation layer?

If you want a compiler under Linux, which can produce Win32 executables,
you can just use a normal Linux native ppc386 compiler. With FPC, the
compiler binaries are only target CPU specific but not target OS specific,
therefore all OSes for the given CPU target target are supported by all
compilers, regardless of which OS they run on.

So you can tell the Linux ppc386 to target Windows (-Twin32), then specify
the Win32 unit files via -Fu and you should
get a Windows exe as result, without going through Wine during the
compilation process. (Yes, the unit files between the Linux ppc386 and the
Windows ppc386.exe are compatible too.)

Of course, your 64bit Linux has to be prepared to run 32bit Linux
binaries, but as the Linux ppc386 doesn't even link against libc, this
should be pretty easy.

If you don't want to use FPC's internal linker or assembler for some
reason, I'm sure most Linux distros supply mingw cross-win32-binutils as
well.

Charlie

(Ps: of course you could compile an x64 hosted ppc386 as well, but that
would require your own crosscompiler builds, probably. What I described
can be achieved by just downg pre-baked FPC binaries, and cherry picking
what you need.)
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Best start point for adding new FPC target

[Karoly Balogh (Charlie/SGR)]

Hi,

On Tue, 28 Jan 2020, Florian Kl?mpfl wrote:

> > The primary goal of a startup code is to get pointers to the command
> > line parameters and the environment block. If arm-freebsd uses the stack
> > to pass these pointers (the same way as i386-freebsd), then you need
> > just to convert the i386 startup assembly to the arm assembly.
> > For start you need only the prt0.as file.
>
> I strongly recommend to create pascal startup files for newly added targets.

There was some extra section on BSDs identifying which syscall version the
binary uses, and some other stuff, IIRC. Which makes it difficult to add a
Pascal startup code. But the assembly part can be minimized indeed. Not
sure if that can be added by the internal assembler. Probably it can be
generated by the compiler though?

Also there was some other thing with weak references I don't remember.

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

Re: [fpc-pascal] Best start point for adding new FPC target

[Karoly Balogh (Charlie/SGR)]

Hi,

On Tue, 28 Jan 2020, Fabio Luis Girardi via fpc-pascal wrote:

> I was thinking of starting with armhf-netbsd, that can I suppose to be
> the closest to the armhf-freebsd target. I'm right? Someone experienced
> adding new targets for FPC has another suggestion?

Well, you don't need to clone the entire RTL for just porting the thing to
a different CPU architecture, if the OS support is already there, so I
wouldn't follow that advice. And I'd just extend the existing FreeBSD RTL
and for that, I could use the NetBSD one. They're heavily overlap anyway.

However, you need to add the new target it to the build system, and the
compiler, which is quite complicated, as a system ID and various
properties have to be added to quite a few places (compiler,
/systems/t_bsd.pas, systems.pas, ppudump, FPMake and FPCMake, then
regenerate all the Makefiles...) So it's quite an undertaking, not really
feasible for submitting a simple patch. However, if you want I can assist
in that part, so you can just iterate on the RTL, by having a working
compiler already.

BTW the NetBSD/ARMHF port (by me, if I'm correct), was never really
working fully, because I was too lazy to figure out some things, like the
usual "always broken on BSD" differences in the stat structure, and how
some syscalls have changed.

But maybe it's a time to figure out what's up with that. I still have the
required NetBSD setup for that anyway.

Charlie___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Static linking to C library on Linux

[Karoly Balogh (Charlie/SGR)]

Hi,

On Wed, 27 Nov 2019, Ryan Joseph via fpc-pascal wrote:

> > On Nov 27, 2019, at 11:25 AM, Karoly Balogh (Charlie/SGR) 
> >  wrote:
> >
> > Yes. By Default, FPC doesn't link against libc on Linux by default, only
> > when some more advanced things, say, threading is used. To the contrary on
> > Darwin (macOS), we always link against libc. There comes your difference
> > from. You can just try to add {$LINKLIB C} to your code, and see if that
> > helps.
>
> Thanks that makes sense now. {$LINKLIB C} did help some of the errors
> but I'm still getting others. I'm aware of 'ldd' to show dependancies
> for dynamic libraries but how can I do this for static libraries on
> Linux? I'm getting defined references for math functions like pow, cos
> etc.. and some pthread ones also. There's probably more but how can I
> know?

I don't know anything like that for static libs... But maybe it exist
somehow. You probably also need libm (for pow/cos), and then for the
pthreads I'd just include "uses cthreads" in my uses clause, as that will
take care of pthreads, and integrating FPC into whatever threading going
properly.

There is no silver bullet, if you Google the missing symbols you can work
your way through what library is needed. Or if you look at some C example
from the static library you're trying to use, its makefile will probably
list the additional libraries it depends on.

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

Re: [fpc-pascal] Static linking to C library on Linux

[Karoly Balogh (Charlie/SGR)]

Hi,

On Wed, 27 Nov 2019, Ryan Joseph via fpc-pascal wrote:

> I'm trying to link to a static library (built from Python sources) in
> Pascal and having troubles on Linux. On Mac where I have experience I
> successfully link and every works as expected but on Linux I get slews
> of linker errors in what appear to be standard C library functions.
> (snipp)
> Do I need to link to other system libraries when building on Linux?

Yes. By Default, FPC doesn't link against libc on Linux by default, only
when some more advanced things, say, threading is used. To the contrary on
Darwin (macOS), we always link against libc. There comes your difference
from. You can just try to add {$LINKLIB C} to your code, and see if that
helps.

> I'm also confused because I thought the purpose of the static libraries
> was to contain all the code they needed to run and thus these system
> functions like "memcpy" would be present also.

That's not true. Static libs can depend on other static libs, just the
resulting final executable won't depend on anything if statically linked.

Hope this helps,
--
Charlie
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] DirectoryExists on FreeBSD , problem

[Karoly Balogh (Charlie/SGR)]

Hi Alexey,

On Mon, 14 Oct 2019, Alexey Tor. wrote:

>  FPC 3.3.1-r43118 [2019/10/04], on Linux x64, cross compiling to
> FreeBSD x64 12.0 (TrueOS).
> Smth is broken in DirectoryExistsUTF8() on FreeBSD. After this FPC
> update CudaText cannot see that folder (in subdir of home dir, access
> rights ok) exists. After removing this check in app, app now cannot see
> that another dir (also in home dir) exists.
>
> I removed VM with freebsd so cannot check in small demo.

If I can have a random guess, it's probably the stat structure being
outdated with the C equivalent, therefore whatever tests are being made on
the result of fstat() or fpstat() call, is not working properly. The BSDs
were notorius for changing their stat structures, or changing the type of
some fields in the structure (which totally changes the alignment), maybe
even several times during the past years... Decades... :P I had to adapt
the NetBSD one too to make it work on recent NetBSD versions a while back,
when I brought the NetBSD port to be somewhat up to date.

The structure in question is in rtl/bsd/ostypes.inc.

Sadly I know very little about FreeBSD, and I don't have it in any form,
and never had it, so I'd pass on attempting to reproduce and fix this.

Charlie___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Errors on cross-compile from Linux x64 to NetBSD x64

[Karoly Balogh (Charlie/SGR)]

Hi,

On Fri, 4 Oct 2019, Alexey Tor. wrote:

> FPC 3.3 trunk from today. Lazarus trunk from today. Project CudaText.
> Cross compilers installed via fpcupdeluxe 1.6.2y
>
> ...
> Compile package atsynedit_cmp_package 1.1: Success
> Compile package atsynedit_ex_package 1.3: Success
> Compile Project, Mode: netbsd x64, OS: netbsd, Target:
> builds/netbsd-x64-gtk2/cudatext: Success, Errors: 2
> Error: /home/user/fpcupdeluxe/cross/bin/x86_64-netbsd/x86_64-netbsd-ld:
> /home/user/fpcupdeluxe/fpc/units/x86_64-netbsd/rtl/cwstring.o: in
> function `CWSTRING_$$_init$':
> Error: cwstring.pp:(.text.n_cwstring_$$_init$+0x10): warning: warning:
> reference to compatibility __setlocale_mb_len_max_32();include
>  for correct reference
>
> The final binary is made, but with errors. Since i cannot run it (i
> cannot install NetBSD gui), I want to know what these errors mean?
> Binary is invalid?

Can you retry with SVN r43118 and newer?

Apparently, as usual with BSDs, they sometimes break their libc naming
compatibility, which is a problem as we link against it, but we don't use
their C headers obviously. They renamed the reference to
__setlocal_mb_len_max_32 to __setlocale50 in NetBSD 6, which shipped in
2012... I changed it now in our trunk, but this means NetBSD releases
earlier than 6 won't be supported. As NetBSD 5 EoL'd in 2014, I don't see
this as a problem, necessarily.

BTW, as a testcase, you could build a test-app which uses widestrings and
links against libc. It doesn't have to be a GUI app to reporduce this
issue.

Charlie

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

Re: [fpc-pascal] It's alive !

[Karoly Balogh (Charlie/SGR)]

Hi,

On Sat, 21 Sep 2019, Michael Van Canneyt wrote:

> Finally, the moment has come:
>
> Following up on a bounty offered, Dmitry Boyarintsev has accomplished
> milestone one in the implementation of FPC's webassembly backend.
>
> And: It's alive ! :-)

Very cool! I'm so sorry I couldn't tackle this, as I even started working
on it at some point, but when finally it was time to do it, life steered
me elsewhere. I'm very happy someone else picked up the idea and brought
it to first light at least.

Looking forward to contribute to the backend (independent from any bounty)
and help with the trunk integration if you need it.

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

Re: [fpc-pascal] Calculating Pixels to represent 3D coordinates

[Karoly Balogh (Charlie/SGR)]

Hi,

On Tue, 17 Sep 2019, James Richters wrote:

> What I'm trying to do is much simpler than rendering a 3D object..  All
> I'm trying to do is display a 3D line drawing or wireframe on the
> screen.  I don't need it to dynamically rotate or anything, and it
> doesn't need to show any surfaces, textures, lighting, reflections, or
> shadows, just give a representation of the XYZ points and lines
> connecting 2 pair of XYZ coordinates on the screen.  The purpose of this
> is to show a 3D representation of a CNC tool path including the Z
> movements.

Well, it all boils down to the projection you want to make while you
transform from your coordinates from 3D to 2D. For the most simple
"isometric" projection with no perspective, you just throw away one of the
XYZ coordinates, and use the other two - this will result in a simple
"camera" which views at your object from either the front (XY), side (YZ)
or from the top (XZ). (Actually, this also depends on wether in your
coordinate system Y or Z represents depth, 3D editors/engines don't even
agree on this one, the code below assumes "Z" is depth.)

For a simple "perspective" projection, you can use a simplistic formula,
something like:

{ untested pseudocode }
procedure perspective_vertex(const v: T3DVertex; ZCenter: single;
  out X, Y: single);
var
  rdist1: single;
begin
  zdist1:=1.0 / (v.z - zcenter);
  X:=(v.x * zcenter) * zdist1;
  Y:=(v.y * zcenter) * zdist1;
end;

This will put some sort of "perspective" on your 3D vertex, depending on
its Z coordinate. The ZCenter should be larger than the maximum dimension
of your object facing the "camera". Note that this formula is massively
simplified, but serves as the most simple perspective projection.

After this, you can use x/y coordinates to feed the wireframe drawer using
whatever drawing unit you see fit. You might need to do inc(x,width/2);
and inc(y,height/2); and/or multiply your values with a certain
scale-factor, depending on the size of your object, and how its
coordinates map to your 2D resolution.

All of the above methods assume that your object's 3D center resides at
the origo (center of the coordinate system). Anything more complicated
would require some proper matrices to be set up and calculate a full
series of model, view, and projection matrices, as others have already
mentioned, or would require pre-processing your 3D coordinates in a
certain way, so this simplistic formula can work.

Hope this helps,
--
Charlie

(Ps: actually, the FPC Packages contain two similar examples of a rotating
3D cube, for PalmOS and Atari, both written by me, to showcase the m68k
code generator and the units for these retro/niche OSes. They're at (SVN
trunk):

- packages/tosunits/examples/gemcube.pas
- packages/palmunits/examples/palmcube.pas

Showcased here (with video):
https://twitter.com/chainq/status/945010617672523777
https://twitter.com/chainq/status/948865605209387010

These show this most simplistic form of 3D calculation, and they also use
fixed point math, as that fit the only a few mhz fast 68000 CPUs in these
machines. But the basic algo and formula is the same with float and on
faster platforms. Now I'm quite tempted to make a ptc-graph version. :) )
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] wiki and mailing lists are moved

[Karoly Balogh (Charlie/SGR)]

Hi,

On Wed, 12 Jun 2019, Mattias Gaertner via fpc-pascal wrote:

> > So after the too long period of the wiki and mailing lists in limbo,
> > and facing danger of data corruption/los they've been moved to a
> > brand new cloud hosted server.
>
> Thank You!
>
> > Additionally, HTTPS has been enabled for the wiki and the ML web
> > interface. The wiki engine was also updated to the latest Mediawiki
> > LTS version.
> >
> > Please report anything still not working, or out of the ordinary.
>
> I get "Unable to connect" on https://wiki.freepascal.org.

Your DNS probably still resolves then to the old machine, because it was
redirected last morning, and it has 24 hours TTL. (And the services on the
old machine are now stopped.)

Now wiki.freepascal.org has address 159.69.249.166, make sure your system
resolves to that correctly. (Same with lists.freepascal.org.)

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

[fpc-pascal] wiki and mailing lists are moved

[Karoly Balogh (Charlie/SGR)]

Hi,

So after the too long period of the wiki and mailing lists in limbo, and
facing danger of data corruption/los they've been moved to a brand new
cloud hosted server.

Additionally, HTTPS has been enabled for the wiki and the ML web
interface. The wiki engine was also updated to the latest Mediawiki LTS
version.

Please report anything still not working, or out of the ordinary.

The FTP site is still pending migration from the old server. Fingers
crossed...

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

Re: [fpc-pascal] wiki.freepascal.org is down?

[Karoly Balogh (Charlie/SGR)]

Hi,

On Mon, 10 Jun 2019, Mattias Gaertner via fpc-pascal wrote:

> > It should happen in the next days tho'. I will keep this list posted.
>
> Any updates?
> The database is still locked.

The wiki won't come up from the same machine in R/W mode again. I tried,
but it started throwing filesystem errors again. I already migrated the DB
elsewhere, now moving the rest of the files. Afterwards, the mailing lists
have to move too.

I'm working on it as we speak.

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

Re: [fpc-pascal] wiki.freepascal.org is down?

[Karoly Balogh (Charlie/SGR)]

Hi,

On Wed, 5 Jun 2019, Dmitry Boyarintsev wrote:

> It's in maintenance mode now.You can actually open a sub page.
> I.e.: http://wiki.freepascal.org/Lazarus_Faq
>
> Yet the main page seems to be affected.

Sorry guys, the filesystem on the machine got corrupted so we put it into
maintenance mode. The database seems intact (fingers crossed) and we have
some relatively recent backups... We're also migrating the lists and the
wiki off that machine in the short-run. I was just burried under office
work this week, and was much slower at this task then I hoped.

It should happen in the next days tho'. I will keep this list posted.

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

Re: [fpc-pascal] unexpected termination with no errors

[Karoly Balogh (Charlie/SGR)]

Hi,

On Wed, 15 May 2019, Sven Barth via fpc-pascal wrote:

>> (Sidenote: I've been pondering for a while if I should report this as a
>> bug. I think the RTL should put a try-except around there, to show a
>> stacktrace on unhandled exceptions, just like the main thread dying
>> does, but who knows which Delphi de-facto standard behavior would that
>> violate, so meh...)
>
> That is already the case at least for TThread descendants as can be seen
> in rtl/unix/tthread.inc, ThreadFunc. This is needed for the
> FatalException field. 

Hmm, I see, indeed. Should have checked the source code, but I never
cared... -.-' Well, the stacktrace is stilly only printed on DEBUG_MT, if
i'm correct?, so from the developer's perspective, the thread is still
dying 'silently', and sometimes it's hard to identify if your thread went
away or just blocked, when seeing an issue... Anyway, not important and
unrelated here.

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

Re: [fpc-pascal] unexpected termination with no errors

[Karoly Balogh (Charlie/SGR)]

Hi,

On Wed, 15 May 2019, James Richters wrote:

> Has anyone encountered anything like this before or know how I can make
> sure I always get the maximum amount of debugging info when my program
> crashes?

Is it a subthreaded app?

The only case when I noticed something similar (under Linux though), when
a certain subthread throws an exception, it just silently disappears
without any further handling. It doesn't throw any exception, unless you
wrap the entire Execute method in a try-except.

(Sidenote: I've been pondering for a while if I should report this as a
bug. I think the RTL should put a try-except around there, to show a
stacktrace on unhandled exceptions, just like the main thread dying does,
but who knows which Delphi de-facto standard behavior would that violate,
so meh...)

In Linux/Darwin (on x64/ARM at least), only the thread causing the problem
dies, no clue what happens under Windows. Maybe this helps.

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

Re: [fpc-pascal] libmosquitto headers for FPC

[Karoly Balogh (Charlie/SGR)]

Hi,

On Thu, 14 Mar 2019, Marcos Douglas B. Santos wrote:

> > So in case anyone needs this:
> >
> > http://github.com/chainq/mosquitto-p
>
> Good job.
>
> I'm thinking use some like that to split a big desktop application
> code into few other applications, maintaining a communication among
> them.

Well, MQTT is more like a cross-host messaging protocol, like your swarm
of devices can trivally connect to a broker, and send messages, which then
can be subscribed to and processed, also with higher QoS levels it can
retain messages until a certain client connects (for configuration
updates, etc), has quaranteed delivery, etc.

You can use it as an interprocess messaging bus (and we have some projects
where we actually do that, because of reasons), but there are better tools
for that maybe... :)

> Is it a good case to use mosquitto? If so, I can help you on Windows,
> testing and etc.

Well, we use it in production and works well (on Linux). Although older
versions of the library (still distributed in some older 'stable' Linux
distros) had some issues regarding memory leaks, but at least the very
core functionality seems to be quite stable these days. And you can always
compile your own version anyway.

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

[fpc-pascal] libmosquitto headers for FPC

[Karoly Balogh (Charlie/SGR)]

Hi,

Not sure if anyone have done this already, but I converted the
libmosquitto (which is a C-written MQTT client library) header
(mosquitto.h) to Free Pascal, so it allows using libmosquitto from Pascal
code. I work on some IoT projects lately which transfers data over MQTT,
and I wanted to write some of the code in Pascal (after some other
languages failed to meet expectations, business as usual), so I just did
it. I know some Pascal MQTT libraries exist, but all I encountered seemed
to have some limitations, or things I didn't like (being too Delphi
centric, or something) and libmosquitto just seems to be much more used.

Note this is only a pure conversion of the C header file using ctypes,
with some pascalisms added (like proper callback function types). I have
an additional class-layer on top of it planned, but so far I only got the
headers converted, but they work in our internal project. I want to add
some examples later too.

So in case anyone needs this:

http://github.com/chainq/mosquitto-p

As we hopefully will soon use this in production, I sort of committed
to keep the headers up-to-date.

I tested it on Darwin (x86_64) and Linux (x86_64 and arm), but adding
Windows support should be trivial. (Probably only needs the right .dll
name added as linklib, or something.)

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

Re: [fpc-pascal] Error: Local variables size exceeds supported limit

[Karoly Balogh (Charlie/SGR)]

Hi,

On Sun, 10 Mar 2019, Jonas Maebe wrote:

> It's always possible to add a hint about efficiency in case the size of
> the locals grows beyond offsets that can be embedded in a single
> instruction, although this hint would trigger already at 32KB of locals
> on e.g. PowerPC.

I'm all for such a hint in any case, even if that limit is quite low on
many archs. It's useful also on m68k, where the "efficiency limit" is also
32K. One who ports code across many CPU archs, especially slower ones
(embedded anyone?) such hint could be important to discover inefficiency
hotspots.

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

Re: [fpc-pascal] Candidate for crowd-funding

[Karoly Balogh (Charlie/SGR)]

Hi,

On Wed, 19 Dec 2018, Ryan Joseph wrote:

> > (After reading that old thread we had...)
> >
> > Actually, it can. The only thing you need to do is to allocate a stack
> > first, then make the "coroutine" functions use it, which is basically
> > boils down to how you pass your arguments and self instance to the
> > coroutine on initializatin, while you change the stack pointer register,
> > and then how you restore it in the end.
>
> And how is a stack allocated? I assume we’re talking assembly here? The
> link I posted (http://www.festra.com/wwwboard/messages/12899.html) seems
> to do this but I don’t know assembly so I’m just guessing.

No, that assembly function just does swapping of the stack and storing the
caller's stack settings and setting up the coroutine's stack instead. The
actual stack is allocated with the Win32 API function VirtualAlloc(), the
rest is just structure copy to/from the coroutine function and setting
up/restoring the stack. The stack is just a memory area, where the
stackpointer points (plus on some archs it has to respect certain
alignment requirements, but that's easy enough to deal with), and until
your stackpointer register points to that memory area, the rest just
works, due to how the CPU works, the compiled code just uses it... The
compiler doesn't handle it normally on the "allocation" level, as usually
the OS takes care of it.

> Even if you allocated a stack frame doesn’t it need to be populated with
> all local variables in the current scope? In my short time working on
> the compiler I haven’t looked at the actual code generator so I don’t
> know how the stack works. However, in theory you should be able to make
> a compiler intrinsic that wraps this process for you.

Well, this is quite a complex code, so most likely would end up as a
helper in the RTL anyway...

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

Re: [fpc-pascal] Candidate for crowd-funding

[Karoly Balogh (Charlie/SGR)]

Hi,

On Wed, 19 Dec 2018, Ryan Joseph wrote:

> > On Dec 19, 2018, at 5:23 PM, Sven Barth via fpc-pascal
> >  wrote:
> >
> > A library as first step would be more useful. Later on one can think
> > about integrating it into the language itself.
> >
>
> How does that work? I’ve been interested in coroutines for a while now
> but I don’t understand how they function in the language. They would
> need to manage stack states and push/restore stacks, which is something
> a library can’t do right?

(After reading that old thread we had...)

Actually, it can. The only thing you need to do is to allocate a stack
first, then make the "coroutine" functions use it, which is basically
boils down to how you pass your arguments and self instance to the
coroutine on initializatin, while you change the stack pointer register,
and then how you restore it in the end. It might be messy, with small bits
in platform-specific assembly - actually the compiler or the RTL could
indeed help a bit there, but this is not a requirement - but theoretically
possible, on the other hand I have absolutely no clue from the top of my
head how that would interfere with any sort of debug info generation,
and/or exception handling.

Actually, if you check the Amiga startup code in the RTL, that already
does this, as AmigaOS and similar systems have a single address space
approach, with a limited size stack, so the RTL startup code checks if the
stack is big enough, and allocates a new one if it is too limited for the
application to run. The OS provides the necessary stack-swap functionality
there, while storing the old stack values for reuse in a small structure,
but this code could just as well be in the application, or your library in
this case. Then the code utilizes setjmp/longjmp to restore register state
on exit, before it quits and restores the old stack.

https://github.com/graemeg/freepascal/blob/master/rtl/morphos/si_prc.pp#L47

https://github.com/graemeg/freepascal/blob/master/rtl/amiga/m68k/si_prc.pp#L60

So to sum it up, after you set up a separate stack and stack pointer
register to your coroutine, the previously discussed setjmp/longjmp method
should work for switching between them.

(Also, if you set up some example-library framework, I might be able to
help with getting the stackswap thing running, if you are not too
comfortable with that. Even if I think this entire coroutine idea is just
a too big of a can of worms to integrate into a compiler/language and a
standard library, but as a separate library it might have its uses
indeed.)

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

Re: [fpc-pascal] A new fpc desirable feature

[Karoly Balogh (Charlie/SGR)]

Hi,

On Tue, 17 Jul 2018, Giuliano Colla wrote:

> As everybody is suggesting new fpc features, I feel it right to add my
> own proposal, to make the language more useful and user friendly.
>
> I propose the support for the keyword "please".
>
> The syntax is quite simple: "please:", followed by the explanation in
> plain English (or whatever locale is selected) of what you want the
> compiler to do, makes the compiler generate the appropriate code.

Great idea! I also propose that if you do not write "please" often enough,
the compiler would error out, claiming the user being too rude. But if
it's used too often, the source can be rejected for being excessively
polite.

Also maybe it could TRY to a hint an info and warning about this EXCEPT if
the code is bogus anyway, before FINALLY erroring out. :-)

Charlie

(Ps: https://en.wikipedia.org/wiki/INTERCAL )
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Default record fields

[Karoly Balogh (Charlie/SGR)]

Hi,

On Fri, 22 Jun 2018, Joost van der Sluis wrote:

> >> I want to do a pivot away from the macro stuff to ask another question.
> >> Since I’ve wanted to contribute to the compiler for so long and I
> >> finally have a little understanding I’d like to know if there’s anything
> >> minor I could do, that isn’t offensive to the compiler team.
> >
> > It's not about the compiler team. It's about the integrity of a
> > programming language, which doesn't matter these days a lot, when all
> > languages turned into a feature race to provide the same broken concepts,
> > but with slightly different syntax. Nevermind. I sometimes do not even
> > understand how people did stuff for 50 years without
> > TObjectClassAdvancedTemplateGenericRecordRTTI...
>
> I read Ryan's mail as an attempt to get involved in some
> compiler-development. And he's wondering what a nice task could be.
>
> Can't we think of something? Maybe he can help with the last parts of
> the modules-support from Sven.

Well, true. Sorry if I sounded too rude. But both threads he started
sounded a bit like "this is broken in the language, so lets fix it", where
I beg to differ.

There are plenty of things to implement indeed. I think we are mostly
lacking on high-level optimizations, but that's a very tedious job, and
hardly helps the use case Ryan was working on, which seemed to be clearly
his driving force in this.

About the really high level generics, RTTI, & whatever topics I'm probably
not the right person to consult indeed. :)

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

Re: [fpc-pascal] Default record fields

[Karoly Balogh (Charlie/SGR)]

Hi,

On Fri, 22 Jun 2018, Ryan Joseph wrote:

> I want to do a pivot away from the macro stuff to ask another question.
> Since I’ve wanted to contribute to the compiler for so long and I
> finally have a little understanding I’d like to know if there’s anything
> minor I could do, that isn’t offensive to the compiler team.

It's not about the compiler team. It's about the integrity of a
programming language, which doesn't matter these days a lot, when all
languages turned into a feature race to provide the same broken concepts,
but with slightly different syntax. Nevermind. I sometimes do not even
understand how people did stuff for 50 years without
TObjectClassAdvancedTemplateGenericRecordRTTI...

> What comes to mind first as being minor (or not, I don’t know) and
> important are default record fields. Is there are reason this never
> existed in Pascal? It’s in C++, C#, Swift etc…. and I use it often.

Because C# and Shift are managed languages, and C++ just includes
everything for no good reason. And this is actually major, with far
fetching implications. C++ is an utter mess for this, with the default
initializer sometimes called and sometimes not, when you declare a
variable of this type. Because if you pull the way computers work into the
equation, it complicates things a lot. It matters where you define a
variable of this type. On the heap, on the stack or on the global variable
list, you have to compile different code for this, and you are probably
won't be able to cover all corner cases. (Eg. what if you allocate this
type with GetMem(sizeof(type))?)

> The compiler added advanced records but making a static class method
> which is hidden down in the implementation is annoying boiler plate I’m
> sick of doing (plus calling it, or forgetting to). The new initialize
> operator is the best alternative but again it’s boiler plate and adds
> methods in the implementation.
>
> Is there any reason we can’t do that? Is it a design choice?

It's a design choice.

In general, could you stop trying turning Pascal into C/C++? What C++
provides is mostly what is provided by advanced records (the useful
subset). Except C++ allows writing the default initializer into the type
declaration which then may or may not get executed, because C++ is a
godforsaken mess.

What you can also do is, to declare the type, then declare a set of
defaults with "const", which you can also write into the interface
section. Then if you need a certain initialization for that type, just do
it with an assignment.

var
  myvar: mytype;

const
  myvardefault: mytype = ;

begin
  myvar:=myvardefault;
end;

In this case the compiler will even warn you, if you A., forgot to
initialize the variable B., forgot to initialize a field in the
initializer. I'm using similar pattern in my 3D engine, where I have
various set of default vertices and matrices defined as consts, which are
still the same type, and i can initialize them this way to whichever
default I need..

If you need huge amounts of this construct, I would advise you to generate
it as Michael said, which is what you would do with extended preprocessing
or similar syntax sugar, like this one. It's just implicit code
generation.

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

Re: [fpc-pascal] record alignment

[Karoly Balogh (Charlie/SGR)]

Hi,

On Fri, 15 Jun 2018, Ryan Joseph wrote:

> I have a struct I need to port from C but the size I’m getting in Pascal
> is wrong. From C sizeof(AAPLVertex) = 32 but in Pascal
> sizeof(AAPLVertex) = 24.
>
> The alignment of the struct is on 32 bit bounds I think but how do I
> replicate this in Pascal so it behaves exactly like c? I tried using
> $align but it didn’t seem to have any effect.
>
> {$align 32}
> type
>   TAAPLVertex = packed record
>   position: vector_float2;
>   color: vector_float4;
>   end;

The whole idea of a packed record is to ignore alignment and "pack" the
fields ignoring padding and alignment. Use a normal record without
"packed", or add the padding fields manually, if you still have to use a
packed record for whatever reason.

BTW, $align specifies the alignment in *BYTES* not in bits. So to align to
32bits you need {$align 4}. But Free Pascal also supports {$packrecords
C}, where it will try to mimic the C compiler's alignment as native to the
target platform. In any unit which needs to interface to a C library, I'd
use {$packrecords C} and no {$align}

This is all documented BTW at the respective directives...

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

Re: [fpc-pascal] The unfortunate deprecation of GetTickCount

[Karoly Balogh (Charlie/SGR)]

Hi,

On Wed, 11 Apr 2018, Alexander Grotewohl wrote:

> Just to be clear, the 64 in GetTickCount64 has nothing to do with
> whether a machine is 32bit or 64bit.

The call itself, doesn't. Except, on a 32bit machine, when you have to do
64bit arithmetic/value handling, it's usually less optimal/more
instructions. In this case it's really minor, but still, on some platforms
we support, it still counts.

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

Re: [fpc-pascal] The unfortunate deprecation of GetTickCount

[Karoly Balogh (Charlie/SGR)]

Hi,

On Wed, 11 Apr 2018, Michael Van Canneyt wrote:

> >> personally I use this 64 bit emulation:
> >
> > For my purpose I'm perfectly happy with GetTickCount. I'd understand the
> > deprecation if GetTickCount64 would be a reliable substitute. It isn't.
>
> Only on XP. On all other platforms, it is the better solution.

Actually... I kinda disklike this depreciation too. Better is just such a
bad word for software engineering. (Almost) everything has its purpose.

GetTickCount is clearly a Windows API function, does not directly exist in
Delphi itself, so this is an FPC addition to the Sysutils unit for
Delphi-compatible platform idependence - and to my knowledge, Microsoft
did not deprecate the 32bit variant, instead it documented that it rolls
over after 49.7 days, which we could also do just fine.

Especially because extending the result to 64bit is *NOT* the only way to
get around the 32bit overflow problem of a timer, and for a lot of
purposes it's perfectly fine, especially on 32bit systems, which are still
numerous.

Which means, the workaround for the deprecation message on Windows is
actually using the GetTickCount from Windows unit directly, which is
supported everywhere and even Delphi compatible (no GetTickCount/64 in
sysutils there, according to the docs I can find, but fix me?).

BTW, for additional fun, the Windows RTL system unit itself still uses
the 32bit Windows API GetTickCount to initialize its RandSeed...

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

Re: [fpc-pascal] libc and math.h on Linux

[Karoly Balogh (Charlie/SGR)]

Hi,

On Fri, 2 Feb 2018, Adriaan van Os wrote:

> I have to import the math.h libc functions listed here
> . What is the
> recommended way to do this for general Linux compatibility ? Simply
> declare them external ? Load them from libc dynamically ? Anything else
> ? I know that the FPC runtime lib itself jumps through some hoops to be
> as independent of libc (or a specific version of libc) as possible.

We actually link against libc and pthreads when multithreading is involved
on Unices. You need to declare all functions cdecl; external;

See the cmem unit in the RTL for example, which provides simple
link-against-C examples for a number of platforms, both dynamic and static
linking case (pick the option which fits best your usecase):

https://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/rtl/inc/cmem.pp?view=markup

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

Re: [fpc-pascal] Sleep(30) is not reliable?

[Karoly Balogh (Charlie/SGR)]

Hi,

On Wed, 24 Jan 2018, AlexeyT wrote:

> Details:
> Ubuntu 17.4 x64; Lazarus 1.9 trunk, fpc 3.0.2.
> I see IDE call stack like this  when i pause app (during loop forever)
>
Can you run strace on your app, to discover what are the nanosleep
syscalls entry values and what are the return values? That should reveal
if there's a flaw in that SysUtils sleep code loop.

But the other possibility would be that your code never sets FBusy to
false, if it calls Sleep() in a loop?

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

Re: [fpc-pascal] issue when enabling -O2

[Karoly Balogh (Charlie/SGR)]

Hi,

On Wed, 10 Jan 2018, Matias Vara wrote:

> BTW, this only applies to inline assembler functions rigth? In the case
> of normal procedures that contains a block asm end; there is no problem,
> Am I right?

No, it applies to *ALL* assembler code. Also inline blocks. The only
difference is, for blocks you can hint the compiler which registers you
use, so the compiler can also tailor code which improves the interaction
with your assembler code:

https://www.freepascal.org/docs-html/ref/refse87.html

This is not true for pure assembler functions tho', for performance
reasons among others.

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

Re: [fpc-pascal] issue when enabling -O2

[Karoly Balogh (Charlie/SGR)]

Hi,

On Wed, 10 Jan 2018, Matias Vara wrote:

> Thank you very much Karol, I completly missed this point during the
> development of my kernel (Or maybe I had in mind sometime ago but I
> forgot it)It was only when I decided to play with -02 that all these
> issues arrised. 

BTW, your code (as shown by the parameter passing in your assembler dumps)
seems to use the Microsoft x64 calling convention, which declares RSI
value as callee-saved, and then your code overwrites that without saving.

So the fact that your code overwrites it, could be the culprit. (And then
the OUTSD instruction also increases RSI by 4, so even if that MOV
wouldn't be there, you'd still need to save it.)

Also note that the 64bit x86-64 ABI is very different between Linux and
Windows, for example.

BTW, developing a kernel in Pascal is cool... ;)

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

Re: [fpc-pascal] issue when enabling -O2

[Karoly Balogh (Charlie/SGR)]

Hi,

On Wed, 10 Jan 2018, Matias Vara wrote:

> Hi Karol and thanks you very much! I got confused with the function
> names, I feel very sorry.As I said in my previous email, I fixed by
> rewriting the assembler function. However, I don't why it worked. 

By accident. Simply the register/stack/memory layout being different upon
entry, and it worked by pure luck.

> So I understand you correctly, if I use assembler in my procedures there
> could be a risk that I trash a variable that the compiler is using.

Yes. All operating systems and CPU architectures define a so called ABI or
calling convention, which functions must respect. This details which
registers are the parameters to be passed on, and which registers are free
to destroy in a function and which ones *MUST* be saved/preserved (usually
on the stack). There's no way around this. The compiler will expect that
your assembly subfunctions play by the rules.

See here, for example, for x86:
https://en.wikipedia.org/wiki/X86_calling_conventions

> Is  the compiler warning me about this? 

No. Assembly is quite a minefield in this regard. If you use assembler,
the compiler assumes you know what you're doing, and doesn't analyze the
assembler function. You have to respect the ABI of your CPU *AND* target
platform by hand, and save the nonvolatile registers.

(This is BTW, not Free Pascal specific. Delphi does the same, or more or
less any other language which supports inline assembly.)

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

Re: [fpc-pascal] issue when enabling -O2

[Karoly Balogh (Charlie/SGR)]

Hi,

On Wed, 10 Jan 2018, Matias Vara wrote:

> I am getting an exception when I enable the -O2 optimization. More
> precisaily, the line that stars with write_portd is corrupting the
> data section. This is the pascal code: 
>
> function PciReadDword(const bus, device, func, regnum: UInt32): UInt32;
> var
>   Send: DWORD;
> begin
>   Send := $8000 or (bus shl 16) or (device shl 11) or (func shl 8) or 
> (regnum shl 2);
>   write_portd(@Send, PCI_CONF_PORT_INDEX);
>   read_portd(@Send, PCI_CONF_PORT_DATA);
>   Result := Send;
> end;  
>
> which generates (without -02):
>
> .section 
> .text.n_arch_$$_pcireaddword$longword$longword$longword$longword$$longword,"x"
> .balign 16,0x90
> .globl ARCH_$$_PCIREADDWORD$LONGWORD$LONGWORD$LONGWORD$LONGWORD$$LONGWORD
> ARCH_$$_PCIREADDWORD$LONGWORD$LONGWORD$LONGWORD$LONGWORD$$LONGWORD:
>
> (***shipp***)
>
> and with -O2:
>
> .section .text.n_arch_$$_pciwriteword$word$word$word$word$word,"x"
> .balign 16,0x90
> .globl ARCH_$$_PCIWRITEWORD$WORD$WORD$WORD$WORD$WORD
> ARCH_$$_PCIWRITEWORD$WORD$WORD$WORD$WORD$WORD:
>
> The first thing that I realize was the the optimized version is not
> generating the correct source when is exiting since it should return
> "Send", but am I right? The assembler code of write_portd remains the
> same, Am I missing something? 

The -O2 version of the function you sent is from a different one, it's
from a Write function, not a Read... So no wonder it doesn't return
anything... :)

BTW, -O2 uses register variables, while -O- doesn't. If your assembler
trashes one of them without preserving one, it can lead to crashes...
But there could be many other reasons.

Without seeing the actual assembler functions it's hard to tell.

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

Re: [fpc-pascal] Translate C code

[Karoly Balogh (Charlie/SGR)]

Hi,

On Sat, 6 Jan 2018, Ryan Joseph wrote:

> Also why does @(PMyStruct(nil)^.next not crash? Dereferencing and taking
> the addressing of a nil pointer sounds like a bad idea.

Because it doesn't do the actual dereferencing, because next's *VALUE* is
never used, only it's address (due to the @ operator). Which is basically
a fixed address of zero (nil) + a constant added together.

So it doesn't crash, because it never loads from this "invalid" address it
calculates.

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

Re: [fpc-pascal] Translate C code

[Karoly Balogh (Charlie/SGR)]

Hi,

On Sat, 6 Jan 2018, Darius Blaszyk wrote:

> Again I would like to ask some support on a piece C code that I need to
> translate to pascal. The code in question is:
>
> #define MEMNEXT(x) ((MyStruct *)(((char *) x) - ((char *) & (((MyStruct 
> *)0)->next
>
> What exactly is going on here? Where does the result point to? It seems
> like it starts with the pointer x and subtracts the size of the offset
> of the beginning of MyStruct up to the "next" variable. At least that's
> what I think is happening.

Yes, it looks like it. It simply substracts the offset of the "next" field
from the value of X; This is a better solution than hardwiring the offset
of next, which could change depending on the target platform's structure
padding, or other reasons (and sometimes could be hard to calculate by
hand anyway).

> Does anyone has an idea how to translate this into working pascal code?

Well, not sure why one needs to do this abomination, without knowing the
data structure it operates on, but nevertheless, you can do the same in
Free Pascal, but you better turn the macro into a function:

type
  PMyStruct = ^TMyStruct;
  TMyStruct = record
some, fields: integer;
next: PMyStruct;
  end;

function MEMNEXT(x: Pointer): PMyStruct;
begin
  MEMNEXT:=PMyStruct(PByte(x)-PByte(@(PMyStruct(nil)^.next)));
end;

If this function is used often, you can mark it as inline; So the compiler
can inline it, whenever necessary. If you want to avoid pointermath for
whatever reason, the same works if you cast the pointers to PtrUInt
instead of a PByte.

If the input value of X is other than a pointer, you can either overloaded
methods, or define a var parameter without type, for example.

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

Re: [fpc-pascal] System call ABI problem on ppc Linux

[Karoly Balogh (Charlie/SGR)]

Hi,

On Tue, 5 Dec 2017, tobiasgie...@gmail.com wrote:

> I think the only problem is with fpmake, which doesn't include
> FPC_ABI_EABI for powerpc 32-bit processors.
>
> My use case is running my software on a Synology DS-413 NAS, which has a
> PowerPC processor. It's only a few years old. Nowadays they use only
> Intel and ARM.

Please note that your NAS has a Freescale P1022 CPU, which has an e500v2
CPU core. In Linux architecture terms, this isn't a regular PowerPC but
PowerPCSPE, as it has a non-standard FPU. This means that classic PowerPC
FPU instructions are not supported, or supported only with kernel
emulation. It's also entirely incompatible with regular applications using
Altivec or VMX SIMD, as the instruction encoding overlaps. It could also
mean that the syscall ABI *could* be different to regular PowerPCs. I
don't know if it is, but could be.

Free Pascal doesn't support PPCSPE CPUs officially (we always generate
classic FPU code for memory copies for example, and the PPC code generator
doesn't support the SPE FPU or the softfpu at this point), so at least we
should verify if your patch doesn't cause problems on regular PPC Linux
installations, or if this bug also exist there.

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

Re: [fpc-pascal] [fpc-devel] FPC 3.0.4 released!

[Karoly Balogh (Charlie/SGR)]

Hi,

On Thu, 30 Nov 2017, Marco van de Voort wrote:

> For Downloads, please use the FTP server at
>
> ftp://freepascal.stack.nl/pub/fpc/dist/3.0.4/

Not sure why Marco decided to redirect everything to the stack.nl mirror
as primary source in his announcement, but everything should be on
ftpmaster, so:

ftp://ftp.freepascal.org/pub/fpc/dist/3.0.4/

Or the right mirror URL for the stack.nl mirror is:

ftp://freepascal.stack.nl/pub/mirrors/fpc/dist/3.0.4/

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

Re: [fpc-pascal] installing cross fpc in parallel to systems fpc

[Karoly Balogh (Charlie/SGR)]

Hi,

On Fri, 10 Nov 2017, Marc Santhoff wrote:

> What is that, is ppc used for bootstrapping the cross compiler
> regardless of any other fpc maybe installed?

Yes. First that ppc gets built with the "other FPC" installed. Or you can
specify a startup compiler explicitly with FPC= argument to the make. It
doesn't even need the rtl or anything, just the "ppcXXX" native compiler.

During the first round it builds this new native compiler + rtl which will
be used to bootstrap the actual crosscompiler then.

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

Re: [fpc-pascal] -O2 internal compiler errors

[Karoly Balogh (Charlie/SGR)]

Hi,

On Wed, 8 Nov 2017, Ryan Joseph wrote:

> When I turn on -O2 I get a never ending stream of internal error
> 2009112601 which I think is from various inlined operator overloads
> (didn’t do much testing though). Is this a bug or are they not
> compatible?

Example code to trigger it please, if possible, also which CPU
architecture and OS?  An internal error is always a compiler bug which
we'd like to fix. If with nothing else, but with a more user readable
error message.

BTW, yes, it's possible that it has something to do with the inlining.
(More specifically, how the inlining interacts with some SIMD register
load/store, probably, but this is speculation.)

If you're using 3.0.2 you could also try if it still occurs with the
SVN trunk version.

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

Re: [fpc-pascal] Float packing

[Karoly Balogh (Charlie/SGR)]

Hi,

On Mon, 6 Nov 2017, Ryan Joseph wrote:

> I actually got the problem wrong and still haven’t figured it out so
> here’s another go.
>
> I have a number which I need to encode as an RGB value each component
> being 4 bytes (12 bytes total) so I need to extract each digit as a byte
> (and then each byte back to a digit). It’s basic low level computer
> science stuff I never learned well. The old version of GLSL I’m using
> (1.2) doesn’t support bit shifting (which I think I could use) so I need
> to do this using arithmetic.
>
> On Google I found a good method to have the compiler convert a word to
> an array of bytes using variant records such as:

I'm not particularly fond of this method, because this is not endian safe.
It won't work on bigendian CPUs (which are marginal, and a thing of the
past, sort of, but their heritage is still with us thanks to the network
byte order, which is bigendian, and some languages like Java, which use
bigendian internally).

> type
>   TBytes = record
>   case byte of
>   0: (i : word);
>   1: (u : array[0..3] of byte);
>   2: (r, g, b, a: byte);
>   end;
>
>
> so for the number 1234:
>
> var
>  c: TBytes;
> FillChar(c, sizeof(c), 0);
> c.i := 300;
> writeln(c.r, ' ', c.g, ' ', c.b, ' ', c.a);
>
> I  get: 44 1 0 0

A Word in Pascal is always two bytes. So I don't understand what you want
here.

> How do I convert this back to 300 using arithmetic? I see you can add
> 255 to first value plus the next value (1) to get 300 but what’s the
> correct method to use I could make into a function?

You're seeing the bytes of a two byte "word" value in little endian, which
is the endianness of x86 and ARM CPUs by default. If you need to process
the data byte by byte, you need to swap the order of bytes around.

In your example:

writeln((c.g shl 8) + c.r);

should print "300";

If you change "i" to dword, For a 32bit value this would be:

writeln((c.a shl 24) + (c.b shl 16) + (c.g shl 8) + c.a;

But you cannot apply this method to floats, such byte-magic only works on
integers (well, you need to also swap around bytes of a float if you
process them as bytes, but that's beside the point here). You also cannot
extract the 10-base digits of an integer value like this (unless we're
talking about BCD numbers, which is again, an entirely different topic).

I still not entirely understand what you want to achieve, but to extract
the digits of a fractional number, you could simply do the following:

var
  a: single;

begin
  a:=1234.5678;
  // integer part
  writeln(trunc(a) mod 1 div 1000);
  writeln(trunc(a) mod 1000 div 100);
  writeln(trunc(a) mod 100 div 10);
  writeln(trunc(a) mod 10 div 1);
  // fractional part
  writeln(trunc(a*10) mod 10);
  writeln(trunc(a*100) mod 10);
  writeln(trunc(a*1000) mod 10);
  writeln(trunc(a*1) mod 10);
end.

But anyway, I guess this is not so useful for you any more. So if you can
tell what *actually* you want to do, like convert a vec4 of GLSL float to
Pascal, or convert a 32bit RGBA value to a GLSL vec4, maybe that would be
more easy to help you with.

Also, are you trying to generate GLSL source with this, or you're
processing binary data returned by your shader code in a buffer?

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

Re: [fpc-pascal] cpu_relax() in freepascal

[Karoly Balogh (Charlie/SGR)]

Hi,

On Fri, 3 Nov 2017, Matias Vara wrote:

> Hello,  I think it would be better if I put my question in context. In
> order to tell the processor that we are in a loop, the pause instruction
> could be used (also I think the "rep nop" produces the same opcode).
> This tells the processor that we are in a loop so it improves the access
> to the cache and the branching mechanism. My question is if the compiler
> is doing any improvement of this kind in a loop or I should write my own
> "pause" procedure/macro. For more info
>
> https://software.intel.com/en-us/articles/benefitting-power-and-performance-sleep-loops

This feature seems to be a compiler intrinsic at least in the Intel C
compiler. We don't have anything similar, so you have to fall back either
to an asm procedure or a line of inline assembler. The compiler is also
not doing an optimization similar to this. Free Pascal's inline assembler
supports the PAUSE instruction though.

But unless you plan to use this in a multithreaded spinloop because you're
loading multiple cores of the CPU, it's better to let the operating system
handle the wait. This instruction is certainly not the way to fix a "my
app uses 100% CPU" scenario, just saying.

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

Re: [fpc-pascal] alternative name fpc cross

[Karoly Balogh (Charlie/SGR)]

Hi,

On Tue, 10 Oct 2017, Michael Van Canneyt wrote:

> > I used to be maintainer on Wine AppDB for several years. Nothing ever
> > worked from one release to the next.  WINE spent 10y  as an alpha
> > release and it started to get embarrassing so they called it beta.
> > Everything still, broke , it is still an alpha produce in all but name.
> >
> > Sadly the target is moving faster than their ability to emulate it.
> >
> > As for attempting to run a stable and secure  OS inside an insecure and
> > unstable one, that's a great way to combine all the disadvantages of
> > both. Probably clinically certifiable behaviour or at least "autistic
> > spectrum".
>
> LOL :)
>
> My point of view since 15+ years...
> Don't mix the 2 environments. Frustration and disappointment guaranteed.
> It used to work more or less with VMWare and Virtualbox, but even this is
> now becoming more a source of frustration than of satisfaction...

Although this is getting off topic now, it's a mater of use case I guess.
For once, I was pretty happy WINE existed, because I could run a bunch of
Windows (and binary) only tools on Linux and Mac OS with it already. I'm
pretty sure an FPC binary would also work fine in both directions, which
is where the whole discussion started.

I for example was glad I could run the ancient and Windows only POSE Palm
emulator on macOS, and I even used it for some retro FPC stuff...
(https://twitter.com/chainq/status/908439601630629888) Or I used the Amiga
emulator WinUAE a lot under WINE, before FS UAE matured, etc.

Nothing is a silver bullet and there are a lot of caveats. But
nevertheless, the state of interoperability between platforms is much
better than most people think, and care to admit. (And reach almost the
state of running a MacOS VM under AmigaOS 20 years ago, but that's a whole
different story... ;) )

Charlie

Ps:
http://charlie.amigaspirit.hu/screenshots/a2000/A2000-FPCvsThinkPascal.png

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

Re: [fpc-pascal] alternative name fpc cross

[Karoly Balogh (Charlie/SGR)]

Hi,

On Tue, 10 Oct 2017, pasc...@piments.com wrote:

> > The compiler is *NOT* OS/platform specific, only CPU specific. Use any for
> > both, and specify the right target using -Tandroid or -Tembedded when
> > invoking.
>
> Maybe you meant the compiler is not TARGET OS specific in that it can
> compiler for any target ( that does seem to be the point the OP was
> missing).

Yes.

> It is specific to what HOST it is built to run on. I don't think you
> will get far running a linux x64 fpc on win64 and vice versa.

While I understand what you mean, I'd recommend taking a look on WINE and
the Linux Subsystem for Windows. You might be surprised... ;)

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

Re: [fpc-pascal] alternative name fpc cross

[Karoly Balogh (Charlie/SGR)]

Hi,

On Tue, 10 Oct 2017, turro75 wrote:

> when I create the cross compiler to arm-android and arm-embedded I get the
> same compiler name so unable to have both running in the same system.
> any workaround?

The compiler is *NOT* OS/platform specific, only CPU specific. Use any for
both, and specify the right target using -Tandroid or -Tembedded when
invoking.

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

Re: [fpc-pascal] getting cross with the cross compiler

[Karoly Balogh (Charlie/SGR)]

Hi,

On Sat, 7 Oct 2017, Sven Barth via fpc-pascal wrote:

> > So where is my cross compiler ??
> >
> > Thanks for any help and suggestions.
>
> A single compiler binary can always compile for all supported targets of
> that processor. So as long as all the units are available you simply
> need to pass "-Twin64" as additional parameter to compile for
> x86_64-win64.

Sigh. :) Any reason why Windows is different? No other OS has different
target arguments for different CPUs, because the CPU type already
specifies if its for 32 or 64bit... (fix me?)

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

Re: [fpc-pascal] getting cross with the cross compiler

[Karoly Balogh (Charlie/SGR)]

Hi,

On Fri, 6 Oct 2017, pasc...@piments.com wrote:

> This builds fine using the stock fpc 3.0.2 with linux target.  However,
> the supposed cross-compiler seems to be trying to build for linux.

The cross compiler binary itself is only CPU specific, not OS specific.
And because for the cross CPU target the same OS exist which is the host
platform,it tries to use that, which is Linux in your case.

You need to specify the target platform with -Twin, at least. Depending on
if you have the right config in fpc.cfg, you might also need to point the
compiler to the right unit directories using some -Fu parameters.

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

Re: [fpc-pascal] FCL-WEB and PostgreSQL Support: Current Status

[Karoly Balogh (Charlie/SGR)]

Hi,

On Wed, 27 Sep 2017, Michael Van Canneyt wrote:

> > 2 - Are they recommended for use in production environments?
>
> Absolutely.
> I use them in very high-load (and we're talking VERY high load)
> environments, with 24/7 availability.

Can you ellaborate a bit more on this Michael? Like how and where it is
used? (Not mentioning company names, if it's a problem.) I was thinking
about using it in various places, but as I don't know how widely they're
tested and used and under what conditions, I didn't had the balls to offer
this as viable alternative against competing technology X.

We definitely need more use case studies...

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

Re: [fpc-pascal] TP compatibility: procedural type

[Karoly Balogh (Charlie/SGR)]

Hi,

On Tue, 29 Aug 2017, Anton Shepelev wrote:

> >>  To be used as procedural values, procedures  and
> >>  functions  must  be declared with a 'far' direc-
> >>  tive or compiled in the '{$F+}' state.
> >>
> >>whereas Free Pascal in -Mtp seems  to  accept  any
> >>non-system  procedure  or function as a value of a
> >>procedural type.  Is it an instance of  TP  incom-
> >>patibilty or am I missing something?
> >
> >That  would probably be only relevant on i8086. All
> >the other targets don't  have  the  distinction  in
> >"near"  and "far", so it's not necessary to artifi-
> >cially restrict everything.
>
> But this is from the  Language  guide -- a  document
> that  descrbes  the  language in a platform-agnostic
> way, except when the contrary is  explicitly  inidi-
> cated.   Where  Turbo Pascal did not accept a proce-
> dure without the 'far' modifier, one  should  expect
> Free Pascal to reject it also in 'TP' mode.

It's documented, that Free Pascal ignores far and near directives because
they were for 16bit code, and have no meaning in 32bit or 64bit code:

https://www.freepascal.org/docs-html/user/usersu82.html

Therefore it's logical that the compiler also ignores their absence.

Although this documentation should probably be updated, because we now
support some 16bit and 8bit systems as well. But I'm pretty sure you can
find a bunch of other things, which FPC allows even in TP mode, but TP
disallows/doesn't support, just because the amount of extra features in
the language since TP was out...

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

Re: [fpc-pascal] Inline ASM code

[Karoly Balogh (Charlie/SGR)]

Hi,

On Thu, 24 Aug 2017, LacaK wrote:

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

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

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

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

Re: [fpc-pascal] BlockWrite() version 2.6.4

[Karoly Balogh (Charlie/SGR)]

Hi,

On Mon, 14 Aug 2017, Brian wrote:

> Thanks Charlie.
>
> I notice the Do_Write() uses  repeat .. until where fpWrite() does a direct
> call.
>
> What was the reasoning for the repeat..until in Do_Write() ?

Because FpWrite() is just the direct Unix OS call, so the RTL doesn't add
extra behavior there. While Do_Write() which integrates this OS call into
the FPC RTL has to do some error handling. In this case, if the system
reports EAGAIN or EINTR errors, the write call will be attempted again,
without returning an error to the program calling BlockWrite().

There are several reasons why an Unix write() might return EAGAIN or
EINTR. These are documented in the Unix manpage for write:

https://linux.die.net/man/2/write

The RTL just tries to handle these recoverable error cases in the
Do_Write() function, until the write() fails irrecoverably or it succeeds.
Hence the repeat...until.

Charlie

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

Re: [fpc-pascal] BlockWrite() version 2.6.4

[Karoly Balogh (Charlie/SGR)]

Hi,

On Sat, 5 Aug 2017, Michael Van Canneyt wrote:

> > In which file can the source code specific to BlockWrite() version 2.6.4 be
> > found ?
>
> Headers are in rtl/inc/systemh.inc
> actual routines are in rtl/inc/file.inc

Just an addition, BlockWrite() actually calls the internal RTL function
Do_Write(), which is the write function implemented for all platforms in a
platform specific way in the RTL. On Un*x, it calls FpWrite, which calls
the kernel syscall directly.

Do_Write for all Unix (including Linux) is implemented in
rtl/unix/sysfile.inc

FpWrite is implemented for Linux in:
rtl/linux/ossysc.inc

But this later function is just a direct call to the syscall. That's the
entire code path then, more or less.

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

Re: [fpc-pascal] Semaphores removed from the rtl?

[Karoly Balogh (Charlie/SGR)]

Hi,

On Wed, 19 Jul 2017, Anthony Walter wrote:

> Thanks for that bit of information Charlie. I should have searched the
> svn logs.
>
> (...)
>
> It just seems to me like the concept of a semaphore has been well
> established in CS for decades and it's a bit weird to remove them from
> the rtl. They are native to all platforms (I just checked). Sure they we
> not used by any rtl internal functions/objects (in TThread for example),
> but I don't believe that should have been reason enough to get rid of
> them.

They weren't implemented for all platforms in our RTL. Among others, using
FPC's Semaphore functions on Windows were resulting in no-ops or Runtime
errors (probably the later, I don't have Windows at hand to verify). This
is what I mean. I'm not saying they were impossible to implement, just
that they never were implemented in FPC RTL, for any platforms except
Unices. And they were never intended to appear in the System unit public
interface either. (Sadly they have, but that's a different story.)

> In other words, just because a one group of developers don't use a tool,
> that shouldn't dictate its removal.

In this case, those tools were incomplete and unfinished. But I am not
arguing against Semaphores as a concept. You are free to implement
Semaphore-alike behavior using CriticalSections for example, which are
implemented on all platforms which support Threading in the FPC RTL.

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

Re: [fpc-pascal] Semaphores removed from the rtl?

[Karoly Balogh (Charlie/SGR)]

Hi,

On Wed, 19 Jul 2017, Anthony Walter wrote:

> When and why were semaphores removed from the rtl?

They are removed from trunk since Sept 2016, and I think they were
deprecated for a while now, although I cannot confirm this. But what's
sure, they were only implemented and used interally for Unix. Affected
revisions:

https://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revision=28965
https://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revision=34542

The commit messages should explain the whys, I think.

Although the code still has some leftovers here and there, and what's
sure, they weren't deprecated with a warning period :(, although I'm not
sure they were ever intended for public use... The documentation knows
about them at least, and they were public since 2014, but I think even
back then this was debated.

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

Re: [fpc-pascal] Food for thought - language string improvement

[Karoly Balogh (Charlie/SGR)]

Hi,

On Thu, 6 Jul 2017, Graeme Geldenhuys wrote:

> On 2017-07-06 15:35, Karoly Balogh (Charlie/SGR) wrote:
> > But sure, web devs are well known for their productivity... :P
>
> Just in case you thought I was a web developer - far from it!
>
> Anyway, the idea was just that - an idea (and possibly an improvement)
> on an age old problem. I have no means or skills to implement something
> like that in FPC. But I thought it might be worth a discussion. I like
> to think outside the box every now and again - most of my projects show
> that.

Sure, we should be free to discuss such proposals, nothing wrong with
that. I just stated my opinion, but that shouldn't stop discussion in any
way. :)

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

Re: [fpc-pascal] Food for thought - language string improvement

[Karoly Balogh (Charlie/SGR)]

Hi,

On Thu, 6 Jul 2017, Graeme Geldenhuys wrote:

> Imagine if FPC had type inference and multi-line strings, neither very
> exotic features. The code then becomes:
>
> =
> var query := '''SELECT Customers.CustomerName, Orders.OrderID
> FROM Customers
> FULL OUTER JOIN Orders
> ON Customers.CustomerID = Orders.CustomerID
> ORDER BY Customers.CustomerName;'''
>
> FDQuery1.SQL.Add(query);
> =
>
> Easier to read, easier to edit, no need for a IDE wizard or external
> tools.
>
> Language features like this is what increases productivity.

Stuff like this looks almost as bad to me, as PHP intermixed with HTML and
Javascript. But sure, web devs are well known for their productivity... :P

(And I'm quite conservative on such things, so ignore me. :) )

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

Re: [fpc-pascal] for loops performance problems?

[Karoly Balogh (Charlie/SGR)]

Hi,

On Wed, 5 Jul 2017, Anthony Walter wrote:

> I replaced the calls to World.Vertex/.TexCoord/.Color with a local
> vertex buffer (an array of TColorTexVertex) eliminating the function
> calls you mentioned. The frames per seconds with vsync off is identical,
> so I'm pretty sure that's not causing the slow down. It's either that
> the addition/multiplication of floats given the font map (heights/widths
> stored in an array) is inefficient or that there is something about the
> nature of a for..loop that is causing it to be slow.

If you still think that loop causes the slowdown, can you post the
generated assembly of it with -al? Otherwise it's really just guesswork.

Also, since you're compiling for ARM if I'm correct, make sure that you

A., using the hardfloat target, and not actually using the softfpu...

B., your data strutures are properly aligned, and any underlying records
are *NOT* declared as packed.

C., you're actually doing aligned accesses indeed, so there are no hidden
exceptions involved from the kernel side, handling the load/store of your
values.

The other example which bubles up again and again, is down to the fact,
that FPC doesn't do autovectorization of that example, while other
compilers, mainly LLVM does. With scalar code, FPC is not that far behind,
if at all.

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

Re: [fpc-pascal] for loops performance problems?

[Karoly Balogh (Charlie/SGR)]

Hi,

On Wed, 5 Jul 2017, fredvs wrote:

> Please take a look at this:
>
> https://www.mail-archive.com/fpc-pascal%40lists.freepascal.org/msg46162.html
>
> and this:
>
> http://www.mail-archive.com/mseide-msegui-talk@lists.sourceforge.net/msg11078.html
>
> fpc has a huge problem for float calculation.
>
> It makes fpc not competitive for audio libraries/programs that use DSP.
> Decent today's audio stuffs do use float 32 résolution for samples.

This problem has nothing to do with the topic. No, the asker's posted code
is not slow because of this or similar problem, but because it does 10+
function calls inside a tightloop.

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

Re: [fpc-pascal] for loops performance problems?

[Karoly Balogh (Charlie/SGR)]

Hi,

On Tue, 4 Jul 2017, Anthony Walter wrote:

> I think the code to generate the geometry each frame isn't that complex,
> and I pre-allocate room in my buffer for all the geometry just once, so
> it seems doing to calculations for the geometry is what's killing the
> performance. The calculations are simple multiplication of "Single"
> type, and I am thinking maybe the "for looping" part is what's degrading
> performance. 
>
> Here is the gist of the loop that generates the text vertex buffer:
>
> https://gist.github.com/sysrpl/8af6e5a9d62cc2f2a1c40f9a9ae13b64

Well, first, please provide a compilable and runnable example for further
investigation.

> I can convert to static buffers and get good performance (if I know the
> text isn't changing), but I'm now curious if this specific performance
> issue is related to fpc's for loop code generation. 

No, it's probably the fact that you're doing 10 function calls per glyph
setup in the "World." part of your for loop, each involving their own set
of register/save restore, etc. I'd say that's probably much slower than
any performance degratation which might arise from the fact that fpc
doesn't do SSA in for loops.

But because the example you provided is not compilable, I cannot give
further hints, and the above is just speculation.

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

Re: [fpc-pascal] Running Freepascal programs on other computers

[Karoly Balogh (Charlie/SGR)]

Hi,

On Wed, 28 Jun 2017, James Richters wrote:

> Does anyone know how this is normally achieved, and how to implement
> this with my freepascal console applications?

I'm not a Windows developer, but You have to code sign your executable,
probably, just like any normal Windows app you'd release. Does this
Stackoverflow link provide any help?

https://stackoverflow.com/questions/252226/signing-a-windows-exe-file

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

Re: [fpc-pascal] FPC for AVR

[Karoly Balogh (Charlie/SGR)]

Hi,

On Thu, 15 Jun 2017, Mark Morgan Lloyd wrote:

> At the risk of making myself unpopular: because right now I /don't/ have
> time.

Sorry, I didn't mean this personal to you. I was just a bit triggered on
the fact that people offer competing products on FPC status requests,
because I've seen it more than once that people just ask for the Status of
X, regarding FPC, and when it's not there right now, they just move on to
something else. And we have to "compete" with a whole range of commercial
products, where this attitude doesn't help.

> > Especially with a project as young and specialized as FPC's AVR backend.
>
> "Young and specialised"... exactly. Which is why I was interested in any
> light that people currently working on AVR could throw on it, since
> what's in the Wiki is roughly 9 months old (apart from recently-added
> links etc.) and that's a long time for something which people are
> actively working on.

You are right, of course.

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

Re: [fpc-pascal] FPC for AVR

[Karoly Balogh (Charlie/SGR)]

Hi,

On Thu, 15 Jun 2017, Mark Morgan Lloyd wrote:

> > mikroPascal (not free) supports AVR and many other chips.
> > https://shop.mikroe.com/compilers/mikropascal/avr-electronic-license
> > Brian
>
> Yes, but I was asking about the FPC situation. I'm desperately resisting
> local pressure to write code that might end up non-trivial in C/C++.

Well, FPC is an open source project, which means without community
feedback and contribution, it won't improve, or would, but much slower. :)

So if you have time, how about you try if it works for your
usecase/platform/etc, and at least give feedback on it? Even if it didn't
work, if you run into issues you're unable to solve, and share them, it
might be helpful for the developers. And I'm sure some of the issues you'd
encounter could be fixed overnight, if the devs would know it's a blocker
for someone's actual usecase.

Especially with a project as young and specialized as FPC's AVR backend.

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

[fpc-pascal] Mantis/Bugtracker registrations fixed

[Karoly Balogh (Charlie/SGR)]

Hi,

We had numerous reports over the past few weeks, that the FPC/Lazarus
Bugtracker registration verification was broken. Thanks to the work of
Michael van Canneyt, it should be fixed now.

If you had trouble creating a bugtracker account in the last few weeks,
please try again now.

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

Re: [fpc-pascal] FPC Graphics options?

[Karoly Balogh (Charlie/SGR)]

Hi,

On Mon, 22 May 2017, Nikolay Nikolov wrote:

> Today, I checked whether we can take advantage of this optimization for
> floats, but I didn't see any load-modify-store instructions in the x86
> instruction set (neither x87, nor SSE/AVX). Are there any floating point
> instructions on any architecture, that we support, that does
> load-modify-store (i.e. modify-in-place) of a memory operand?

No, but wouldn't it also cover cases like:

move.l d1,d0
op.l   d2,d0
move.l d0,d1

to

op.l d2,d1

I'm pretty sure it "fixed" a lot of those for m68k.

This doesn't contain memory ops, still, the difference is significant both
in code size and performance. (Of course on the other hand it might not be
ideal for CPUs with 3 operants, if one of the source and the target is the
same, but that's a different case...)

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

Re: [fpc-pascal] FPC Graphics options?

[Karoly Balogh (Charlie/SGR)]

Hi,

On Fri, 19 May 2017, Sven Barth via fpc-pascal wrote:

> I think Jeppe wanted to add vector support. Though the question here is
> whether one wants to optimize/detect this at the AST level and convert
> that to implicit vectors or at the CSE level.

I think the higher level you can do an optimization/simplification, the
higher you should do it. Otherwise the lower layers get really messy, as
they already are in some cases. Well, in general, we should up our
floating point game. For example if Nikolay's recent load-modify-store
optimization would work on floats, that would already a nice step forward
in this case. ;) (Sorry for my ignorance, if it already works, missed that
then.)

> By the way: I think my commit today of a SSE Frac() implementation sped
> up the framerate by a third on Win64 compared to the one without it :D

Cool, but shouldn't this be an inline node instead for real speed++...? ;)
I mean if Trunc() and Round() are...

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

Re: [fpc-pascal] FPC Graphics options?

[Karoly Balogh (Charlie/SGR)]

Hi,

On Fri, 19 May 2017, Reimar Grabowski wrote:

> Final: The render function takes about 90%, the cast-to-int about 5%. No
> other interesting functions shown. So the missing time must be spent
> doing floating point math and branching (ifs), as that's all the render
> function does.

Well, if I comment out the three additions where the ray is actually
traced and the tex := line, it's actually 60fps on my macbook. But
actually the real difference is made with the additions. If i comment out
everything, but those 3 (4 in fact) additions are in still there, it's
still slow.

Which made me thinking. I think you can vectorize that quite easily, and
use some packed SIMD instruction, maybe that will make a difference. C/C++
has some compiler intrinsics for that. I can't remember from the top of my
head if it's doable with FPC. Someone who feels like fiddling with this,
might want to try some assembly magic there, if it's possible somehow...

And actually, when looking at the generated code, it's a typical code
which suffers from the fact that FPC's SSA is switched off in loops right
now. So the registers are reused in a way, which are a recipe for a
pipeline stall, especially with SIMD, plus it has a few unnecessary moves.
So guess what. See my previous mail.

Charlie

(Ps: Yeah, talking about code generated with fastmath optimizations on,
and SSE3.)
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC Graphics options?

[Karoly Balogh (Charlie/SGR)]

Hi,

On Fri, 19 May 2017, Graeme Geldenhuys wrote:

> Bottom line is, with the exact same code, NO work-arounds is required
> for GCC or Java! So why must we have work-arounds for FPC? It's a
> compiler or RTL issue - not being able to understand the code good
> enough to generate more efficient binaries.

It's not about that. There's no black magic, or not because FPC people are
stupid.

It's well known that modern compilers do two tricks: common subexpression
elimination (CSE), for example to move as many parts of the code inside of
a loop to outside a loop as possible of the actual loop, even down to
things like simplifying addressing modes and so on, and SSA - static
single assignment, which allows CSE to act more efficently.

Basically some compilers will rewrite your code to fix it and make it more
efficient. Not on the assembler level, but on the high level. What FPC
compiles mimics the high level code much closer. (FPC has both of the
above, but in a quite limited form.)

Sadly, these are not easy to implement with the current architecture of
FPC, which is not going away anytime soon. There are works going in that
way though.

Also, the difference is usually nowhere as dramatic if you don't measure
tight loops, because other code is heavily penalized by cache misses for
example, and also function calls are just slow, doesn't matter the
compiler. Yes, a software rendering loop is a tight loop.

> And no, I don?t agree that this is a ?special case?. It?s a g*d d*mn
> game engine I tried to implement. If the FPC team wants to keep thinking
> like that, then they should list in big bold letters (on the Free Pascal
> homepage) what type of applications they deem fit for FPC, and what type
> of applications you shouldn?t bother writing with FPC.

Fortunately, there are still people who know what the hell they do, so
they can still write fast multimedia and graphics code with FPC. Look
around in the demoscene for examples.

Charlie

Ps: can someone direct me to the right code you are discussing? I looked
around in the lazarus forum, but found several examples of the code, one i
fixed up for SDL2, and then it ran on my MacBook with minor tweaks at
22-24 fps... Which is not great, but not that terrible. But I'm not sure
if this is the actual code I should be looking at. And I even know how to
make it 2x as fast, but that's an algorithmic change...
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Coroutines and VirtualAlloc

[Karoly Balogh (Charlie/SGR)]

Hi,

On Wed, 19 Apr 2017, Ryan Joseph wrote:

> yes, I?d like to see that so I know why my example doesn?t work as I
> expected. Everything I?m hearing makes me think ?i? should keep
> incrementing after I call SetJmp and then return with JongJmp but
> there?s something I?m missing obviously.

Your example is simply broken. A few points:

First, When you're LongJmp'ing to entry state in Resume, you're expecting
the Start stack state (and with that, your "i" variable's state) to be
intact. This is not the case. After the Start method returns (stepped out)
it's stack contents are destroyed, and even get overwritten by the next
'writeln' method call, so the next time Resume is called, you get
unpredictable behavior by jumping into the stack state of Start, which no
longer exist and was overwritten since. For example, it simply crashes
with Runtime Error 216 on Mac OS X 32 bit. For you, it just uses some
"random" value on the stack (or register), which happens to be 1. I get
this even without register variables, so I doubt it has anything to do
with that... (Sorry Michael/Sven... ;)

Basically, you can only jump to a "higher" level on the stack, not equal
(from a different function) and not to a "deeper" level.

Second, if you really want to use SetJmp/LongJmp states you can use SetJmp
return value for that. If SetJmp returns 0, it wasn't returning from a
LongJmp. If it returns 1, it was returning from a LongJmp. You don't need
external state to track that.

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

Re: [fpc-pascal] Threading vs Parallelism ?

[Karoly Balogh (Charlie/SGR)]

Hi,

On Wed, 29 Mar 2017, fredvs wrote:

> > besides hardware parallelism,
>
> Is it possible, with fpc, to assign one processor (if multi) for a
> thread and say to the system to use this one only for the thread ? But
> maybe it will gives more problems than solutions.

Yes, it's called thread/process affinity, and most operating systems have
a specific API for it. But one should treat such things extremely
carefully, otherwise with badly designed data access concurrency you end
up with potentially hard to identify structural problems like false
sharing (see Wikipedia on this) and others. This can be especially bad for
for example on NUMA architectures, or others, where data storage locality
to a given core is not obvious. (Just think about clusters, etc.)

In other words, as the OS knows best your hardware's layout and how it can
best provide performance, energy, bandwith, etc, it's usually very wise to
rely on the OS to solve the thread to CPU core assignments for you.

Bottom line: parallelism and threading is a very complex problem and very
diverse area, and anyone laughing at any approach is just shows how little
they know about true depth of the whole topic, IMO. Thinking about any
technical solution, or way of implementation as a silver bullet for
everything is a very "expert beginner" approach.

My 2 cents.

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

Re: [fpc-pascal] Delphi RTTI vs Free Pascal RTTI

[Karoly Balogh (Charlie/SGR)]

Hi,

On Fri, 24 Mar 2017, Graeme Geldenhuys wrote:

> On 2017-03-24 18:55, Michael Van Canneyt wrote:
> > They are. There is one dereference on Delphi which is not present in fpc,
> > although in fpc trunk
>
> Another minor difference is data types. From what I remember (and as can
> be seen in tiOPF's code. eg: tiRTTI.pas) FPC has a few more data types
> than Delphi. eg: FPC had tkBool, whereas Delphi didn't. There were also
> some differences with string types like tkAString, tkUChar and such. Not
> a big difference though.

FPC also has tkQWord, among others. Just for the record, here's the FPC
version:

http://www.freepascal.org/docs-html/rtl/typinfo/ttypekinds.html

plus a few aliases:

http://www.freepascal.org/docs-html/rtl/typinfo/index-2.html

vs. Delphi version:

http://docwiki.embarcadero.com/Libraries/Seattle/en/System.TTypeKind

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

Re: [fpc-pascal] Delphi for Linux is out

[Karoly Balogh (Charlie/SGR)]

Hi,

On Thu, 23 Mar 2017, Mattias Gaertner wrote:

> > > When did FPC start to run on Linux? 1999?
> >
> > I got the first "hello world" around 1995-1996, I think,
> > together with Mark May. (if memory serves well)
>
> Well, Delphi didn't start with a "Hello World". So that would be a
> little unfair as comparison. What about the time when FPC was able to
> compile itself?

Well, there was Kylix anyway around 2001 or so, wasn't it? So not like
supporting Linux is a rocket science, although FPC was definitely first.

My remark was more about, I still remember, Kylix had his own LibC unit,
but because of (un)portability reasons, FPC never supported that anywhere
but on i386. And that was already a source of massive whining, when people
started to use x86_64 and other platforms, and they tried to compile their
i386-only Kylix code elsewhere with FPC, and of course FPC was stupid and
ugly for not supporting the LibC unit elsewhere.

So if this Delphi for Linux sticks around for a while, I predict the same
happening all over again (just with feature X)... And I "pray" to be wrong
on this.

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

Re: [fpc-pascal] Delphi for Linux is out

[Karoly Balogh (Charlie/SGR)]

Hi,

On Thu, 23 Mar 2017, Graeme Geldenhuys wrote:

> Just thought I would mention, yesterday Delphi 10.2 was released which
> includes Linux support (I assume a cross-compiler). It is only available
> in the Enterprise edition product line though, and only Linux Server
> style apps are supported (no GUI/desktop apps).

I can't wait until we get the blame that Free Pascal on Linux is now
incompatible with Delphi on Linux...

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

Re: [fpc-pascal] FreePascal Windows - Force files to write to disk

[Karoly Balogh (Charlie/SGR)]

Hi,

On Wed, 22 Mar 2017, Giuliano Colla wrote:

> Il 22/03/2017 13:20, James Richters ha scritto:
> > No, it is not only freepascal, but not every program either.
>
> A wild guess. The vilain could be the journal logic.

Wild indeed. :)

> You might try overwriting the old file instead of clearing it. Something
> like:
>
> Assign.
> Seek to the beginning of the file. (instead of rewrite)
> Write whatever you need.
> Truncate.
> Close.
>
> This will give the journal a different story to cope with. Maybe it will
> help.

Even if this would work (no idea), it builds completely on assumptions and
the behavior might be different depending on the underlying storage
system. It's not atomic as well, because if you get a power loss during
the above process, you could still end up with a broken file with random
contents. So it is dangerous, and could be very hard to reproduce if it
causes problems.

See my other mails about the documented way, and what Microsoft seem to
suggest.

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

Re: [fpc-pascal] FreePascal Windows - Force files to write to disk

[Karoly Balogh (Charlie/SGR)]

Hi,

On Wed, 22 Mar 2017, Karoly Balogh (Charlie/SGR) wrote:

> However, please note that transactional file handling on power loss is a
> quite delicate scenario, so you might not be able to solve all the related
> problems with this - what happens exactly when you get a power loss during
> a write, might be matter of pure luck.
>
> The usual way to work this problem around on Linux systems at least, is to
> write a new file, then do an overwriting rename to the old file name.
> There rename is an "atomic" operation, which will be either committed to
> the disk or not, but if it was unsuccessful, you won't end up with
> half-written files. But IIRC Windows didn't support atomic renames. Maybe
> someone with more Windows knowledge will fix me. You definitely don't want
> to implement a copy though, and that's anything but atomic.

Actually, this blogpost which I've just found also details the algorithm
how you should do it, from a Windows perspective:

https://blogs.msdn.microsoft.com/adioltean/2005/12/28/how-to-do-atomic-writes-in-a-file/

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

Re: [fpc-pascal] FreePascal Windows - Force files to write to disk

[Karoly Balogh (Charlie/SGR)]

Hi,

On Wed, 22 Mar 2017, James Richters wrote:

> No, it is not only freepascal, but not every program either.

I'm no Windows expert, but Windows API seems to have a way do to this
directly. CreateFile() API seems to have a flag, which has a value
FILE_FLAG_WRITE_THROUGH, which will cause the file not go through the
write cache, but gets written directly to the underlying disk, without
delays.

However, this obviously has performance implications on write (will be a
lot slower), and as the documentation notes, it's not supported on every
hardware or file system. Also, I'm not sure if you can do this somehow
together with Free Pascal's file handling API, or you have to restrict
yourself to using direct Windows API calls entirely for writing this file.

Relevant MSDN page:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa363858(v=vs.85).aspx#caching_behavior

However, please note that transactional file handling on power loss is a
quite delicate scenario, so you might not be able to solve all the related
problems with this - what happens exactly when you get a power loss during
a write, might be matter of pure luck.

The usual way to work this problem around on Linux systems at least, is to
write a new file, then do an overwriting rename to the old file name.
There rename is an "atomic" operation, which will be either committed to
the disk or not, but if it was unsuccessful, you won't end up with
half-written files. But IIRC Windows didn't support atomic renames. Maybe
someone with more Windows knowledge will fix me. You definitely don't want
to implement a copy though, and that's anything but atomic.

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

Re: [fpc-pascal] Threadvar member field

[Karoly Balogh (Charlie/SGR)]

Hi,

On Fri, 17 Mar 2017, Michael Schnell wrote:

> Accessing threadvars (in fpc) costs a lot more CPU cycles (i.e. involves
> an OS call) than accessing normal variables.

This is actually entirely platform specific. The underlying implementation
of threadvars is very different for each platform, and highly depends both
on the CPU arch and the OS. On some platforms, threadvars are barely
slower than normal ones, other platforms have the large penalty you're
talking about. I agree though that it's still wise to count on the worst
case scenario though.

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

Re: [fpc-pascal] WebAssembly Target

[Karoly Balogh (Charlie/SGR)]

Hi,

On Fri, 17 Mar 2017, Michael Van Canneyt wrote:

> In fact, there is an alternate approach, transpiling pascal to Javascript.
>
> It's much farther ahead than the webassembly target, already produces
> programs running in the browser and the first web-based components are
> already being developed using this approach.

I believe these will be complimentary solutions in the end, one will be
better for certain things than the other, with a lot of overlap, of
course. I think the transpiler might be better for developing unique
front-end solutions in Pascal for the web, the WebAssembly compiler might
be better to bring existing large chunks of code to run on the web, with
minimal modifications, and for performance critical things.

But only time will tell. :)

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

Re: [fpc-pascal] WebAssembly Target

[Karoly Balogh (Charlie/SGR)]

Hi,

On Thu, 16 Mar 2017, Graeme Geldenhuys wrote:

> And this brings me to my next worry. As far as I understand, WebAssembly
> is C (for now - other languages to follow) compiled into WebAssembly
> bytecode. So now we have C code with all its pointer access, buffer
> overflow issues etc running in the web browser space - at least Java
> Applets were a lot safer in that regards, and Java Applets require
> explicit signed executables and granted permission by the end-user (per
> app, per domain etc). WebAssembly just runs - no questions asked.

Yes. Much like your average Javascript snipet. But even if it's compiled
from C (or Pascal, eventually... :P), it doesn't mean it can just poke
pointers whereever it feels like, there are several protection layers
between the bytecode and the native code, the JIT engine itself, the
browser, and the OS. Also, most browsers run most pages in isolation
anyway. I agree though that some kind of code signing would be benefical.

Also, the major problem with Java and other plugins security faults were,
that the organizations behind them moved with glacial speed, and sometimes
(Flash, Silverlight) they were even closed source, which made it
impossible for browser vendors to act quickly and patch things up. None of
this is true for WebAssembly.

> Then we have the issue of code being obfuscated when compiled into
> bytecode. So now it is even harder to detect malicious code.

There are already decompiler tools for WebAssembly, which translate the
bytecode back into the AST or even some JS-alike syntax. It's not that
much less human readable, than a deobfuscated JS code, which someone ran
through an obfuscator before, IMO.

> It seems I am not alone in thinking this way. Just read the comments
> posted at the link listed in the first message of this thread.

I think there's still a master switch to disable this in the browsers. I'm
sure there'll be tricky attacks, but these happen with normal JS anyway.
But I don't think it'll be such a disaster as people predict. (And I'm
usually quite pessimistic about such things.)

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

Re: [fpc-pascal] WebAssembly Target

[Karoly Balogh (Charlie/SGR)]

Hi,

On Thu, 16 Mar 2017, Mattias Gaertner wrote:

> > which was basically striped down Javascript with some integer/pointer
> > type tagging. As far as I know, the main problem with JS from a
> > computing point of view, that it handles all numbers as floats for
> > "simplicity", but with some code in other languages, this can have
> > real side effects (for example some integers cannot be exactly
> > expressed as floats,
>
> JS uses Double, which can express integers correctly from
> -$10 to $f.
> That should be enough for most browser programs, don't you think?

No, to be honest, I don't think so. I already tracked down bugs in native
client side software caused by this, because of stupid NodeJS backends.
Because someone thought it will be "good enough". It wasn't. Not to
mention the cases I got "NaN" string as value in an integer field, but
that's just JS in general for fun.

Although NodeJS wasn't running in the browser, admittedly. But I think the
more complex apps you bring to the web, on top of JS, the more such issues
will appear, and the harder it will be to track it down.

Bottom line: It's not good enough if you want to guarantee the same
results as on other platforms, for all integer arithmetics with all
standard types, including 64bit ones. Which is a must for any self
respecting multiplatform compiler, IMO. (There are ways to do it
nevertheless even w/o WebAssembly, but with a clear performance hit.)

But I guess this is drifting away from the WebAssembly target itself, so
we should continue on fpc-other. :)

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

Re: [fpc-pascal] WebAssembly Target

[Karoly Balogh (Charlie/SGR)]

Hi,

On Thu, 16 Mar 2017, Graeme Geldenhuys wrote:

> I love how they say multiple times in the video:
>
>"... and completely secure."
>
> Umm, didn't they say the exact same thing about Java Applets, Flash,
> Silverlight etc. :)  I guess time will tell, but if history is anything
> to go buy, security issues *will* pop up.

Yes, but it is important to know there's a difference with Java Applets,
Flash and Silverlight - WebAssembly is not a plugin. It runs in the same
VM which runs everything Javascript in the browser. So the browser vendors
have full control on the code which runs there.

Also, WebAssembly is a descendant of asm.js, which was basically striped
down Javascript with some integer/pointer type tagging. As far as I know,
the main problem with JS from a computing point of view, that it handles
all numbers as floats for "simplicity", but with some code in other
languages, this can have real side effects (for example some integers
cannot be exactly expressed as floats, which means slight differences in
computation results accumulate over time, etc), and it's much slower on
most CPUs. This is why I'm a bit relucant to accept High Level language
translators to JS - there could be too many sideeffects hidden in any
algorithm, just because of this one thing.

This is the main problem asm.js, and now WebAssembly is addressing. It can
work with the same integer and float types the hardware underneath is
using, and can avoid all the float handling and various range/index etc
checks. This is what provides the performance part. And obvously a lot of
other "shortcuts" to work around JS language requirements, which another
language might not need.

And it fits in the process, how they gradually opened up the underlying
hardware to the browser. Another great example is WebGL, which is also a
very thin layer on top of the hardware, to skip through the billion "who
cares about that" CSS and JS canvas layers, and go directly to the GPU, to
get some decent performance...

So all in all, despite its problems, it's still the best effort to provide
some sane bytecode standard for the web. (If a web bytecode can be
anywhere near sane, that is.)

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

Re: [fpc-pascal] WebAssembly Target

[Karoly Balogh (Charlie/SGR)]

Hi,

On Sun, 12 Mar 2017, Michael Van Canneyt wrote:

> >   Is there something planned in this matter for FPC?
> >
> >   I was reading about the new Firefox making WebAssembly publicly
> > available ("On Tuesday Firefox 52 became the first browser to support
> > WebAssembly
> >
> <https://www.bleepingcomputer.com/news/software/mozilla-releases-firefox-52-the-first-browser-to-support-webassembly/>")
> > [1] .
>
> Karoly Balogh (Charlie/SGR) is working on this, and as far as I know has
> already some degree of success. There is a bounty for initial
> webassembly support..

Well, "degree of success" is relative, I have added WASM target to the
compiler so it compiles at least. I even made it output 1 single
instruction... :)

It's based largely on gutted JVM codegenerator code, although since
WebAssembly itself is still a moving target, many things are still
uncertain. There's also the problem, that despite it's name, WebAssembly
is not really an assembly format, but just a stack based bytecode (much
like JVM), and the official textual representation is not yet accepted,
plus the reference compiler LLVM outputs something entirely different to
the semi-official textual formats. And these official textual formats are
quite painful for the traditional structured compiler layers like FPC has.

But the LLVM-style output would be good, but it's undocumented, and as
they say it will go away, and LLVM will output the binary bytecode
directly... (Which is stupid IMO, but hey, a comittee decided, so it must
be right.)

Also, any "assembler" or toolchain is still in its infancy. (I made both
binaryen and wabt segfault in several funny ways already.) So I wouldn't
expect fast results with this whole target. But I will keep working on it
as time allows, so "eventually"... Of course if someone thinks he can
proceed faster and wants to jump in, it's very welcomed.

It's now committed to the webassembly branch in FPC SVN, the compiler
itself should build at least as "wasm" target, but don't expect much.

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

Re: [fpc-pascal] Pointer hashing

[Karoly Balogh (Charlie/SGR)]

Hi,

On Mon, 30 Jan 2017, Ryan Joseph wrote:

> I?m trying to hash a pointer value and found some example of hash
> function but not sure about translations and the process in general.
>
> 1) Should I cast ?pointer? as PtrUInt to get an integer from a pointer?
> I?m looking for the memory address I guess and casting seems to return a
> unique value. Btw, these functions are for a 32 bit integer but I?m
> building for 64 bit. How do I deal with that? Can I remove the upper
> 32bits which are typically not used.

This hash function doesn't deal with the upper 32bit, therefore it's
probably unsuitable to properly hash 64bit pointers. You need to find an
alternative hash function which does that, if you need 64bit. (Googling
reveals some relevant pages for a 64bit version, if you search that magic
hex number in there...)

> 2) I?m getting incompatible type errors on my translation. What did I do
> wrong there? The fact the function is 32 bit may be the problem?
>
> unsigned int hash(unsigned int x) {
> x = ((x >> 16) ^ x) * 0x45d9f3b;
> x = ((x >> 16) ^ x) * 0x45d9f3b;
> x = (x >> 16) ^ x;
> return x;
> }
>
> function Hash (x: PtrUInt): PtrUInt;
> begin
>   x := (Power((x shr 16), x)) * $45d9f3b;
>   x := (Power((x shr 16), x)) * $45d9f3b;
>   x := Power((x shr 16), x);
>   result := x;
> end;
>
> Thanks for any ideas you have.

The "^" operator in C simply doesn't translate to "Power" in Pascal. It's
"exclusive or", a.k.a. xor. So that line in C translates to:

x:=((x shr 16) xor x) * $45d9f3b;

Furthermore the Power() function in Math unit seems to deal with Floats
and returns Float, where your type errors might come. But since you don't
need Power() there anyway, that should be an easy fix...

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

Re: [fpc-pascal] JSON parser error due to my data values.

[Karoly Balogh (Charlie/SGR)]

Hi,

On Thu, 26 Jan 2017, Graeme Geldenhuys wrote:

> It seems like it is trying to interpret the field data value like a
> C/C++ escape sequence. eg: \n meaning NewLine
>
> I such escape sequence processing a JSON standard?

Yes. See:
http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf

Figure 5.

> Can I tell the JSON parser to treat data as-is, without any
> interpretation?

That is probably a bad idea, as it goes against JSON standards. Basically
the JSON you're trying to feed it is invalid. Fix the JSON, don't try to
force the parser to work it around.

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

Re: [fpc-pascal] FPC 3.0.0 seed compiler for Rasperry Pi ARM?

[Karoly Balogh (Charlie/SGR)]

Hi

On Sat, 7 Jan 2017, Bo Berglund wrote:

> I went ahead and tried the command but it failed miserably...
>
> pi@rpi3-jessie:~/dev/fpc/3.0.2RC1 $ make all install
> FPC="/home/pi/bin/fpc/3.0.0"
> INSTALL_PREFIX="/home/pi/bin/fpc/3.0.2RC1" OPT="-dFPC_ARMHF"

With FPC, You need to specify the whole path to the ppcarm binary, not the
directory you installed 3.0 into. As I said, you need nothing in fact from
3.0, but ppcarm.

Charlie

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

Re: [fpc-pascal] FPC 3.0.0 seed compiler for Rasperry Pi ARM?

[Karoly Balogh (Charlie/SGR)]

Hi,

On Thu, 5 Jan 2017, Bo Berglund wrote:

> I just need the seed compiler to be able to build FPC from sources.
> And build Lazarus of course.

Then you need "ppcarm" from that archive, and nothing else. Just copy it
whereever you want, in your home dir, or something and do:

make all install FPC= INSTALL_PREFIX=

in the root of the SVN tree.

FPC works from pretty much anywhere. You can have multiple copies in your
home easily. It doesn't have to be installed at a certain location.

Lazarus I don't know, but I imagine it's similar.

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

Re: [fpc-pascal] FPC clean room project

[Karoly Balogh (Charlie/SGR)]

Hi,

On Mon, 2 Jan 2017, Santiago A. wrote:

> Well, I think it's evident  that Freepascal and lazarus tries to be
> delphi compatible, and that means that must look close to delphi to
> imitate it's behavior and syntax.
>
> Is that reverse engineering? Well, I'm not a lawyer, I don't know where
> "finding a similar solution for the same problem" ends and "Reverse
> engineering" starts. Nowadays it looks like painting a line is patented.

I'd like to point out, that reverse engineering is not illegal, in most
countries. As in, investigate the workings of some software or computer
system in general, then document how it works, and then write a
replacement based on that. Neither is implementing a documented and well
defined API.

Heavily regulated it can be, and there are cases where it has to be done
with great care, but just the fact that some information was obtained by
some reverse engineering process doesn't make it immediately illegal. For
example, writing unit tests to an API and then reimplement the API pass
the same unit tests is a form of reverse engineering, but still it's an
everyday practice in software engineering. And it has to be, otherwise
most software would be illegal, really, especially in OOP where your class
just extends the functionality of an object it inherits, and in overriden
methods it has to reproduce some functionality... And so on.

Looking at Delphi source code (or it's RTL's source code) and then
implement similar feature *by the same person* in FPC would be illegal.
But looking at the source cose is not reverse engineering, is it?

So such accusations without any evidence is spreading FUD at best.

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

Re: [fpc-pascal] FPC 3.0 deb packages?

[Karoly Balogh (Charlie/SGR)]

Hi,

On Mon, 5 Sep 2016, Jon Foster wrote:

> After I banged on it for many hours applying several crude patches it
> finally makes packages again. But all of this leads me to believe that
> Debian packages for FPC are no longer maintained / supported? If so
> what's the story? Maybe my crude hacks could be put to use or I could
> help out some way?

Well, I guess the main issue is, Debian splits the FPC "packages" into
separate packages. :) Because it not only installs the package, but all of
its dependencies (for example C static link libs), therefore a global FPC
"packages" package with all its dependencies would be *HUGE*. But maybe
for 3.0 that decision should have been modified, and Debian should have
bundled a 'set of packages' as a .deb package, instead of each package as
a separate .deb alone... I mean the various FCL or the various RTL
packages are certainly just one "package" from the user PoV...

And yes, I'm not sure if the .deb packaging is still maintained in FPC's
own build system. Maybe the people doing the actual packaging for Debian
could help you there?

 > My current need is the StrUtils unit, which I must say I'm shocked to
> find is not part of the core RTL but is in a package?!?! I don't get
> that but that's your decision.

Again, that's because FPC doesn't think about "packages" the way Debian
and Linux distributions in general think. Remember, we deploy the same
structure on all of our supported platforms. We even provide Linux binary
builds, where "packages" is just one archive, with a specific directory
structure and that's it.

So we moved out large chunks from the RTL (including strutils) to separate
packages, because it reduces compiler build times and therefore speeds up
development. Also, it's makes easier the maintenance of some RTL features,
which are in fact separate from the rest of the RTL really. I guess the
Debian packaging situation was simply not considered while making that
decision, given most FPC developers themselves don't use distribution
provided packages.

Anyway, packages not finding a given unit in another package could be
probably fixed by adding additional dependencies to that other package.

That said, if anyone feels like helping out with the current packaging
situation on whatever platform, he's certainly very welcomed to do so. :)

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

Re: [fpc-pascal] LLVM Backend Support

[Karoly Balogh (Charlie/SGR)]

Hi,

On Wed, 31 Aug 2016, African Wild Dog wrote:

> > The code optimizers, yes. The rest, not so much.
> >
> >> Will the FPC team, somewhere in the future, adopt the LLVM as the
> >> backend on all platforms ?
> >
> > No, for various reasons:
>
> Again,thanks for the detailed explanation. As this is a recurrent
> topic,maybe it would be a good ideia to create a wiki page with all
> these points.
>
> And about GCC? It supports a wide variety of processors and OS.

90% of the same as for the LLVM backend applies. Also, it doesn't support
all the systems we do, not in mainline, or in current versions anyway.
Granted, these are usually smaller, less significant, or legacy systems,
but still...

I know these are the days of going Easy instead of staying Simple, but for
a lot of us the fact that FPC doesn't depend on any kind of other
monster-framework and backend of a competing product and language is
pretty much *the* killer feature...

But anyway, if someone wants to see a GCC-backend in FPC, he is welcomed
to work on it. But as a team-policy to migrate to it - no thanks.

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

Re: [fpc-pascal] LLVM Backend Support

[Karoly Balogh (Charlie/SGR)]

Hi,

On Wed, 31 Aug 2016, Anthony Walter wrote:

> I'm not too familiar with LLVM so I'll ask, is it at all likely that an
> LLVM compiler would produce significantly better/faster optimizations
> than FPC as it stand currently? What range would be talking about 100%
> faster? Less? More?

We just had a C vs. Rust vs. FPC showdown with a colleague at work. He
wrote a small tight loop example with float maths, we ported it to three
languages, and we looked at the results.

C (clang/llvm) came first, Rust was closely behind, FPC was about 2x as
slow as Rust (which is llvm based as well). But it turned out, that if I
did some hand optimization by moving unchanging parts of some expressions
outside the innermost loop, plus enabled SSE42 for floating pointinstead
of x87, the speed matched the Rust implementation (which is again, LLVM
based). And no, no inline assembly was involved.

The big tricks in compilers are still Common Subexpression Elimination and
Single Static Assignment. Especially the later. Only if we could have a
good one of that...

But again, as Jonas said, this was an artificial benchmark of an abusive,
badly written tight loop, and with thousands of iterations, we're talking
about the ms range for results, on modern CPUs.

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

Re: [fpc-pascal] reference-counted function results not initialized to nil

[Karoly Balogh (Charlie/SGR)]

Hi,

On Sun, 26 Jun 2016, Jürgen Hestermann wrote:

> Am 2016-06-26 um 14:27 schrieb Karoly Balogh (Charlie/SGR):
> > There's no exception. At least not specifically for Result. It is simply
> > variable passed by reference from the caller side, therefore it's not
> > initialized inside the function.
>
> You mean when I have the following:
>
> --
> function X : ansistring;
> begin
> end;
>
> var S : ansistring;
>
> S := X;
> --
>
> Then S is a dangling pointer to nowhere?

No. In this case, S was initialized (to nil), because it's a global var.
This just won't be changed by the X function call. If you had S:='test';
Before S:=X; then it would still contain 'test' after it.

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

Re: [fpc-pascal] reference-counted function results not initialized to nil

[Karoly Balogh (Charlie/SGR)]

Hi,

On Sun, 26 Jun 2016, Jürgen Hestermann wrote:

Ok, scrap what I wrote before... :|

You are right about the managed types initialization. But then the
documentation needs to be corrected there too. But actually, result is not
a local var, but in fact a "special" parameter of the function. My bad.
See below.

> The only exception (at least since FPC 3) is the function result
> which is totally unexpected.
> Why such an exception?

There's no exception. At least not specifically for Result. It is simply
variable passed by reference from the caller side, therefore it's not
initialized inside the function. And this is A., consistent with other var
parameters B., apparently also how Delphi does it. Actually, since managed
types are always passed by reference, this is not really a surprise, nor
an exception.

Actually, I tend to agree that it is very misleading. Also, you are also
right that this is new behavior in current compiler. At least 2.6.2 (I
don't have 2.6.4 at hand) decreased the reference to the result parameter
before handing it to the called function, which no longer seems to happen.
(I'm looking at the generated code.)

I have vague memories of a lengthy thread related to this, which changed
the refcounting behavior of reference passed managed types/strings, maybe
we're observing a sideeffect of this? (I think it was related to what
happens if the same reference counted variable is passed to multiple var
types and/or results, maybe also out parameters were involved. It's a
pretty grey area, which is not really documented anywhere...)

To show the problem, what happens with:

var
  a: ansistring;
a:=some_function(a);

If the caller code destroys the result variable (by decreasing the
reference count, because it's a result, so lets initialize it) it won't be
valid by the time you pass it as parameter "a', because only the function
itself will increase its reference then... Also, depending on the order of
parameter passing, you might get different results on different CPU
platforms... (Fix me?) Of course the function itself could also initialize
the result, but we're back to square one with that, if result and one of
the parameters are the same, weird things might happen.

I wish someone with real clue of calling conventions would comment. Jonas
maybe?

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

Re: [fpc-pascal] reference-counted function results not initialized to nil

[Karoly Balogh (Charlie/SGR)]

Hi,

On Sat, 25 Jun 2016, Jürgen Hestermann wrote:

> This has definitely changed with Free Pascal 3 as my programs suddenly
> did not work anymore and I had to add Setlength() all over my code.
> Before we could rely on that managed types where always initialized
> (well, that's the purpose of managed types, no?).

No. Local variables are not initialized by default. Managed type or not,
doesn't make a difference. Result is just another local variable in this
case. I think the compiler will even warn about using uninitialized local
variables, at least with -O3 and above (or when Data Flow Analysis is
enabled).

> It took me quite a while to find out why my programs failed as I did not
> expect such a (hidden) change.

It wasn't an intentional change for sure. However, the generated code
might have changed (hopefully it became more optimal) which simply exposed
some of these issues within the compiled code.

Actually, such issues are much easier to notice on other architectures,
aside from i386, because of the different calling convention and register
layout they use. I spent the better part of the last 3 years fixing code
which was originally intended for i386, to get it working better on ARM
(and others), where I ran into this exact "result remains uninitialized"
issue, along with many other "my code is good, fix your compiler" issues,
where it turned out the code was basically working accidentally, and it
was built on false assumptions...

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