Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do ...

[Nikolai Zhubr via fpc-devel]

Hi!

19.12.2021 19:28, J. Gareth Moreton via fpc-devel:

To throw my hat into the ring, I'd be willing to help out with
developing some library routines.  I did experiment once with using a
truncated and factorised MacLaurin series to calculate Double-precision
sin and cos simultaneously in native SSE2 (with sin and cos filling two
elements of the same register), mainly so one wouldn't be forced to use
the floating-point stack on 64-bit (the speed was about the same).  For
128-bit though, I imagine it would have to be fully emulated, down to
how the mantissa and exponent are interpreted.  I admit I haven't
studied the sfpu128 unit yet.  If you need "log" and "exp" implmented in
software, if you can give me the exact requirements and specifications,
I'll see what I can do.


Well x87 does include log and exp (kind of), so bochs does too. It is 
known to successfully run lots of ancient 86/87 software, so I'd suppose 
this x87 emulation should be pretty much stable.
Apparently, x87 implementation in bochs is not tied to any sort of 
host-side floating-point capabilities, so it is portable. IIRC some 
people reported they used it on ARM.



Regards,
Nikolai



Gareth aka. Kit



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

Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do ...

[Nikolai Zhubr via fpc-devel]

Hi!

19.12.2021 12:33, Florian Klämpfl via fpc-devel:

And the main obstacle for 80 bit softfloat support are the library
routines (log, exp etc.).


Just out of curiosity, couldn't bochs' x87 fpu implementation be of some 
use here?
It is approx 12k of C code and it is LGPL. Supposedly it is not fast but 
conformant.

Or does it need to be (re-)implemented in Pascal itself?
(Not implying it would be easy anyway, but still)


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

Re: [fpc-devel] Building trunk of today fails on Windows: Error: Invalid DLL C:\WINDOWS\system32\common.dll, invalid header size

[Nikolai Zhubr via fpc-devel]

Hi,

23.08.2021 0:46, Bart via fpc-devel:

I have now finally resorted to that.
Wrote a simple program to do that for me (no sed on windows).


Just in case:

http://gnuwin32.sourceforge.net/packages/sed.htm


Regards,
Nikolai


Then adjusted my build script to run that program, build fpc, then do
a "git restore".

This, of course is an insane and stupid solution.

It would be very much appreciated if anybody can explain why this
(building trunk) worked before, but does not anymore.
Also can anybody explain why all the other {$linklib xxx} lines do NOT
cause compilation and linking to fail??



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

Re: [fpc-devel] (ref types / circles) Re: Defer keyword

[Nikolai Zhubr via fpc-devel]

Hi Martin,

07.05.2021 2:41, Martin Frb via fpc-devel:

On 07/05/2021 01:36, Nikolai Zhubr via fpc-devel wrote:


Indeed. However, unfortunately classes are substantially different in
that they can cause reference circles,

You can already cause ref circles, no classes needed.


Yes, records and objects are the same as classes in this respect. You 
cannot do circles with any other types, AFAIK.



Regards,
Nikolai


type
   TR = record
 a: array of TR;
   end;

var
   x: TR;
begin
   SetLength(x.a,99);
   x.a[0] := x;
end.


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


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

Re: [fpc-devel] Defer keyword

[Nikolai Zhubr via fpc-devel]

Hi,

07.05.2021 1:32, Ryan Joseph via fpc-devel:
[...]

it's kind of frustrating that we have ref counted types but that isn't extended 
to classes.


Indeed. However, unfortunately classes are substantially different in 
that they can cause reference circles, which then cause damage to ref 
counting, unless some severe complications are implemented, and then it 
will probably get close to garbage collection. Well, AFAIU.



Regards,
Nikolai



Regards,
Ryan Joseph


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

Re: [fpc-devel] Compiler message colour scheme

[Nikolai Zhubr via fpc-devel]

Hi!

25.11.2020 1:52, Tomas Hajny via fpc-devel:

On 2020-11-24 19:17, J. Gareth Moreton via fpc-devel wrote:

Sorry for being a bit slow - I've been doing my own work on x86. I
gave your patch (and new file) a test run on x86_64-win64, and that
seems to work fine.  At least the warning messages in the packages
appear magenta.  I'll give arm-linux a test next.


No problem, thanks for testing. Unfortunately, it doesn't work for me
under Windows (Win 10 Pro 64-bit) either with the original version or


Have you also checked with this registry trick for win10:

[HKEY_CURRENT_USER\Console]
"VirtualTerminalLevel"=dword:0001

(As per https://superuser.com/a/1300251/109090)

HTH,

Regards,
Nikolai


with my modifications (i.e. hopefully unrelated to my changes). It could
be some configuration of the used Windows installation, whatever, no
idea. I'll probably commit my changes now hoping that I didn't break
anything for anybody for whom it worked correctly previously. The GO32v2
version was not compilable in the sent version, fixed now and tested to
work properly (apparently, coloured output using ANSI escape codes works
more reliably with 16-bit MS-DOS/PC DOS/... than with 64-bit MS Windows
10 Pro ;-) ). And BTW, no, it doesn't work under DOSBox, because DOSBox
supports ANSI escape codes out of the box without signalizing that such
support is available in a way compatible to the real DOS. I could add a
specific check for running under DOSBox if somebody wants it (it's just
a few more lines of code, no difficulties).

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


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

Re: [fpc-devel] Minor heads-up

[Nikolai Zhubr via fpc-devel]

Hi,

09.08.2020 20:03, J. Gareth Moreton:

Hmmm, that's a good idea!  Silly question... what does OSS mean?!


Open-Source Software, presumbly? :)


Regards,
Nikolai



Gareth aka. Kit


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

Re: [fpc-devel] reference/pointer to class function/constructor ?

[Nikolai Zhubr via fpc-devel]

Hi,
20.02.2020 10:21, Harald Houppermans via fpc-devel:
[...]

Now I need a type to the initialize function which is a class function,
I simply tried:

type
Tinitializer = class function; // this don't work in Delphi

I also tried:

Tinitializer = ^class function; // this don't work in Delphi.


I'd guess your initializer function in fact does not need to be a class 
member. Actually, a class function is a rather "weak" memeber already. 
So then you just declare a regular function type and some few regular 
functions as initializers. Now, from within such regular function, you 
may call some class functions if you need so. Not very elegant but 
supposedly should work.


HTH

Regards,
Nikolai


Since writing TsomeObject.Initializer is weird might initialize thought
was to use a constructor which is a little bit more strange/inefficient
maybe but keeps code consistent in case class functions or turned into
method functions.

Tinitializer = constructor;

Tinitializer = ^constructor;

Tinitializer = class constructor;

Tinitializer = ^class constructor;

None of this seems possible ?!?

So it seems that my fair that I require some language feature that is
not available might be true.

If so try and understand it and try and create a plugin system for
units, to automatically initialize via arrays and plugin tables and
constructors and such in an object orientated way where inheritance and
order also plays a roll to some degree. If you can prove to me that this
can be done with new language features that would be great !

Otherwise "Houston we have a problem" and we need more powerfull
language extensions/features.

In case you agree with this then my hope is that if Free Pascal
implements it maybe Delphi will some day too ! ;) =D

Bye for now,
Skybuck =D


*** Shorter version / less explanation ***:
(Alternative shorter version):

I want/have the need to do the following, I want one unit as follows:

UnitVersion:

type
TVersion =
(
v1,
v2,
v3
)

I want to create some kind of pluggeable/plugin array to c;ass functions
like so:

(class functions can be called without creating an object like so
TSomeObject.ClassFunction;)

TInitializer = class function;

// could also be a constructor maybe
TInitialize = class constructor;

TInitializerArray = array[TVersion] of TIntializer;

var
InitializerArray : TInitializerArray;

Then the user can add certain units to the project yes or no... certain
versions.
For example version v1 and v2, but not v3.

Version1 and Version2 should "plug themselfes into this array" like so:

unit version 1

type
Tversion1 = class
class function Initialize;
end;

initialization

UnitVersion.InitializerArray[v1] := TVersion1.Initializer;

unit version 2

type
Tversion2 = class
class function Initialize;
end;

initialization

UnitVersion.InitializerArray[v2] := TVersion2.Initializer;


The idea is then that user code can use

UnitVersion.pas and include only version 1 and version 2.

And other code can then automate the initialization without breaking code.

If version 3 were added it would break code, cause version3.pas might
not be present or included in project.

So automation code should work even if a certain unit is not present.

Currently initialization is done with class functions.

Not sure if it's possible to make pointers to class functions.

With method pointers this would be easy/doable.

But now I am not sure if this is possible.

It's getting late... tomorrow I will do more re-search into this.

But perhaps somebody already knows how to solve this.

Bye for now,
Skybuck.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


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

Re: [fpc-devel] Linux Binary - Socket Output affected by SystemCtl, HELP!

[Nikolai Zhubr via fpc-devel]

Hi!

29.01.2020 19:04, Ozz Nixon via fpc-devel:

cat /etc/test.txt

ls -alrt /etc/test.txt
-rw-r--r-- 1 root root 0 Jan 29 10:54 /tmp/test.txt


Make sure there is no naming confusion (such as e.g. /tmp/test.txt and 
/etc/test.txt unintentionally intermixed)


Another point is that a binary running from systemd context might have 
somewhat different access rights as compared to running from an 
interactive shell, so that might lead to some files being unreadable and 
that might potentially also lead to changed behaviour.
Actually systemd allows you to set a user and group you want for the 
service, like e.g.:


[Service]
User=root
Group=root


A don't remember what it sets by default.
(And certaily, root/root is generally not a safe practice, but just for 
a test...)



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

Re: [fpc-devel] Linux Binary - Socket Output affected by SystemCtl, HELP!

[Nikolai Zhubr via fpc-devel]

Hi!

29.01.2020 18:07, Ozz Nixon via fpc-devel:

1. My code does not directly interact with any environment variables.


Ok.


ExecStart=/usr/local/bin/coderunner2


I'd suggest, as a quick and horrible temporary hack/test, replace this 
direct binary call with a shell wrapper, lets name it e.g. 
coderunner2.sh, containing something like:


#!/bin/sh
echo "LANG=$LANG" >>/tmp/test.txt
echo "LOCALE=$LOCALE" >>/tmp/test.txt
export LC_ALL=C
/usr/local/bin/coderunner2

(Put it into /usr/local/bin/ as otherwise systemd might refuse it; I 
suppose the script is simple enough to be self-explanatory)



3. I do not see anything in that file that would override socket output.


Sure.


5. per wireshark, tcpdump (if the same) - it shows '?' is being sent
when the daemon is managed by systemctl, and the expected 8bit is sent
when ran at the shell prompt.


That proves the problem is unrelated to sockets. Is is related to 
string/encoding handling.



HTH...

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

Re: [fpc-devel] inline... and philosophy

[Nikolai Zhubr via fpc-devel]

08.11.2019 16:28, J. Gareth Moreton:
[...]

No gain? Wow, is whole-program optimisation that underperforming? Given
the bloated size of FPC's binaries compared to, say, what a mainstream
C++ compiler than do, I would have thought that there could be a lot


Keep in mind that pretty much any tiny MSVC application would these days 
push a (few-megabytes-sized) vcredist package in front of it. Similarly, 
gcc would typically dynamically link against some-megabytes-sized libc 
and other system libraries. On the other hand, FPC typically produces 
self-contained binaries with all required RTL code built-in. Whether it 
is good or not depends on your usage context, but application binary 
size comparison should at least take this into account to be of some use.


--
Regards,
Nikolai


that could be stripped out in regards to unused functions and the like.
Or am I missing something?  The large binary sizes feel like an elephant
in the room that no-one talks about.  What causes them?

Gareth aka. Kit

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


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

Re: [fpc-devel] moved project from CentOS to a new install of CentOS...

[Nikolai Zhubr]

Hi Ozz,

28.07.2019 22:02, Ozz Nixon:

/usr/bin/ld: BFD version 2.20.51.0.2-5.42.el6 20100205 internal error,


This binutils version is likely too old, and because C6 is getting close 
to EOL, I'd not count on someone fixing this ld bug. I recently had to 
update 2.24 to 2.30 (on opensuse) to get rid of (another) ld error. And 
as Centos7 now uses binutils 2.27, maybe consider trying it? (I do 
compile on C7 with no issue, but still using FPC 2.6.4 there, so no 
promices w.r.t. your specific issue)


HTH,

Regards,
Nikolai


aborting at reloc.c line 443 in bfd_get_reloc_size
/usr/bin/ld: Please report this bug.

 From this point forward, nothing I do will fix ld. I had ran into this
2 weeks ago - thought it was from a yum update, but, obviously its
binutil and glibc-2.12 are not compatible. Any ideas how to resolve
this? Researching this for 2 weeks, everything always results in
reinstall the OS. :-(

On Sun, Jul 28, 2019 at 5:40 AM Jonas Maebe mailto:jo...@freepascal.org>> wrote:

On 28/07/2019 04:08, Ozz Nixon wrote:
 > ld is complaining it cannot -ldl
 >
 > I have read on reddit, this is a glibc update... is that all I
need to
 > yum so FPC can compile my project?

You have to install the glibc-devel package.


Jonas
___
fpc-devel maillist  - fpc-devel@lists.freepascal.org

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



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


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

Re: [fpc-devel] FPC 3.0.4 ld error on opensuse 13.2

[Nikolai Zhubr]

Hi,

09.07.2019 22:32, Florian Klämpfl:

/usr/bin/ld: /usr/lib64/fpc/3.0.4/units/x86_64-linux/rtl/prt0.o: unrecognized 
relocation (0x2a) in section `.text'

[...]

As windows uses a different binary format, it is not possible to judge from 
windows to linux. I am pretty convinced, a
newer ld might help.


Indeed.
Updating binutils from ver 2.24 to 2.30 eliminated the ld error.

Thank you,

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

[fpc-devel] FPC 3.0.4 ld error on opensuse 13.2

[Nikolai Zhubr]

Hi all,

I've just discovered fpc-3.0.4-1.x86_64.rpm does not quite work on 
opensuse 13.2. That is, linking helloworld fails with:


fpc hello.pas
Free Pascal Compiler version 3.0.4 [2017/10/02] for x86_64
Copyright (c) 1993-2017 by Florian Klaempfl and others
Target OS: Linux for x86-64
Compiling hello.pas
Linking hello
/usr/bin/ld: warning: link.res contains output sections; did you forget -T?
/usr/bin/ld: /usr/lib64/fpc/3.0.4/units/x86_64-linux/rtl/prt0.o: 
unrecognized relocation (0x2a) in section `.text'

/usr/bin/ld: final link failed: Bad value
hello.pas(7,1) Error: Error while linking
hello.pas(7,1) Fatal: There were 1 errors compiling module, stopping
Fatal: Compilation aborted
Error: /usr/bin/ppcx64 returned an error exitcode

Meanwhile, fpc-2.6.4-1.x86_64.rpm does work fine.

/usr/bin/ld --version
GNU ld (GNU Binutils; openSUSE 13.2) 2.24.0.20140403-6.1

Of course this ld is pretty old, so my first thought was that I need 
some newer binutils. However, I've found fpcbuild-3.0.4.zip contains 
2.22 version (for windows, but anyway), and also on windows I use 
cross-binutils 2.16 and 2.31 (and they work fine and produce perfectly 
valid linux-i386 and linux-arm executables), so now I'm somewhat 
confused about what to do next. AFAICS docs does not explicitely mention 
any particular binutils requirement. I could repackage/patch/replace 
stock binutils package, but because I don't understand the exact reason 
for the error, I thought I'd ask for advice first.


Thank you,

Regards,
Nikolai

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

Re: [fpc-devel] "Blank slate" next version of FPC

[Nikolai Zhubr]

Hi,

09.03.2019 21:06, Anton Shepelev:
[...]

Pascal is a language where declaration and use of
variables is separated.  It makes it easy to see what

[...]

   a := a + Func1( b );
   int b := Func2( a );
   a := a - Func3( b );

Also worth reference are Bart's thoughts on the subject, in
two parts:

   http://al.howardknight.net/msgid.cgi?ID=155215407800
   http://al.howardknight.net/msgid.cgi?ID=155215418300


In short, if you let me, the all so lengthy and endless reasons boil 
down to approx these simple 3:


1. It might let people write ugly, horid, unreadable, unreliable code.
2. It might require you to scan some lines up to see the declaration.
3. Name clashes are possible (if implemented and/or used incorrectly).

And regarding all these: yes, as it is now, no much more, no much less.

No one would decide to declare "x", "y" in a declaration section and 
separately "z" somewhere deep in the body if "x, y, z" are actually 
coordinates of a point, unless s/he does that on a sole purpose of 
intentionally mocking colleagues and producing LOLs.


Its pretty odd to deny nowadays that block-local declarations do have 
their valid use and work just fine, if used reasonably. I'll certainly 
continue using them, where appropiate (in Java). Also I'll certainly 
continue using FPC because it is an absolutely brilliant and efficient 
product anyway with apparently no real-world alternative except just 
Java. On the other hand, Java's syntax is not as descriptive and has 
some ugliness in parts (and it hurts my eyes plenty). Therefore, my 
initial question was out of a (real-world motivated) curiosity regarding 
how (and why) declarations would ideally be better arranged so as to 
achive readability and reliability in various cases, considering both 
C's approach, Java's approach and maybe Embarcadero's approach, however 
as just a reference, not a requirement for immediate implementation 
"just because they all have it". So far I've only got the abovementioned 
cases 1-3 which are in fact irrelevant. Plus a general "declaration and 
use is separated" mantra which I fail to find sufficiently enlightening 
either. Well, ok. It is not a showstopper. At least not until a typical 
function gets 1 lines long (which I try to resist :) ).



Thank you,

Regards,
Nikolai



Please, do not turn Pascal into another C# or Java.



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

Re: [fpc-devel] Regressions on i386-win32 and x86_64-win64

[Nikolai Zhubr]

Hi,

02.03.2019 19:59, J. Gareth Moreton:

It might need double-checking, but I'm getting a couple of regressions
on the trunk for i386-win32 and x86_64-win64:

Failed, compilation successful webtbf/tw4893d.pp 2018/12/06 07:01:14
Failed, compilation successful webtbf/tw4893e.pp 2018/12/06 07:01:14

Both these tests seem to be label/goto tests for {$mode fpc} and {$mode
objfpc) - can anyone confirm, or do I have a faulty set-up?


Testsuite buildbots do not seem to list them as faulty currently, so if 
you really meant the results against current svn repository then the 
answer is probably the latter. You can check it yourself anytime, 
although I'd refrain from advertising the URL of testsuite database 
publicly (Instead, please ask Florian or some core developer to tell you 
in private).



Regards,
Nikolai



Gareth aka. Kit



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


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

Re: [fpc-devel] fpc-devel Digest, Vol 178, Issue 38

[Nikolai Zhubr]

Hi,

21.02.2019 17:41, Martin Frb:

On 20/02/2019 19:31, Franz Müller wrote:

It's a nice example why scoped variables would be in fact better,
because the value of i is undefined if the for loop is exited
normally. So even the original code wouln't work as expected, you
cannot rely on i>High(arr) in that case, it depends on the way the for
loop is implemented.
Using only the variable local to the loop would cause a compiler error, while 
using only the variable defined in the function body would not even cause a 
warning but leed to unwanted results.


That does not need inlined variables.

The compiler already has a warning about uninitialized vars. If not
detected after a for loop, this should be improved (rather than adding
some other workaround).

And there is a command line switch to tread warnings as errors. So that
problem is perfectly solve-able.


Actually no. Inline declarations (where implemented) are not limited to 
a loop index and not even limited to a loop. If you have an option to 
declare some few variables locally to some code block (e.g. FOR, as well 
as IF, CASE, WHILE, etc), in case you know for sure from their meaning 
that their values just make no sense outside of this very block, you 
would know they do not leak out accidentally. This is certainly not the 
same as detecting uninitialized variables. A variable might be 
technically initialized, but at the same time its value might make no 
sense outside of some scope (for the reasons of your business logic or 
whatever else considerations).



Thank you,

Regards,
Nikolai





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


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

Re: [fpc-devel] "Blank slate" next version of FPC

[Nikolai Zhubr]

Hi,

20.02.2019 23:33, Florian Klämpfl:

Am 20.02.19 um 08:36 schrieb Paul van Helden:
 > As a big

fan of the Pascal language, I'd rather break compatibility and see the
language evolve than the stoic attitude of the core devs as seen on
this list.


People could change this attitude by contributing to FPC. But very few
do constantly with high quality patches. The current FPC devs are simply
overloaded with the areas they have to maintain so it is pretty clear
that excitement about new features is very low.


Now this is fair and reasonable, indeed.

I didn't actually intended to trigger such a blowup, just was curious 
about some possible specific technical reasons for avoiding inline 
declarations altogether.



Thank you,

Regards,
Nikolai


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


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

Re: [fpc-devel] "Blank slate" next version of FPC

[Nikolai Zhubr]

20.02.2019 21:28, Giuliano Colla:
[...]

Moreover, using a modern tool such as Lazarus, you never need to scroll
1000 lines to find a declaration: you just press alt+Up to go to the
declaration of the symbol over the cursor, and Ctrl+H to go back to the
line of code.


It's a bit like car manufacturer saying, "we've arranged a steering 
wheel in the trunk but you need not worry, there are third-party 
extenders allowing to also access it from a driver's seat."



Keeping all declarations separated from code is just good programming
practice. Mixing declaration and code is bad programming practice, IMO,
and I appreciate Pascal for not supporting it.


Are you really sure? What about:

procedure Test;
var
  a: integer;
  function b(c: integer): integer;
  begin
b := 10 + 5 * c;
  end;
var
  d: integer;
begin
  d := b(1); a := 2;
end;

What is it if not mixing declaration and code?


Thank you,

Regards,
Nikolai



Giuliano



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

Re: [fpc-devel] "Blank slate" next version of FPC

[Nikolai Zhubr]

Hi,

20.02.2019 23:56, wkitt...@windstream.net:
[...]

How this example is different from e.g. using normally declared "I, J:
Integer" and employing "J" as a loop variable? Wouldn't it do the same
error anyway?



i think he's pointing out the two instances of

var I

in the code... one at the top and one in the loop... at best that would
be a redeclaration defect in the code to me...


I'd suppose inline redeclaration of an already existing local variable 
or parameter name should be prohibited. If Embarcadero allows that then 
they must be quite crazy...



Thank you,

Regards,
Nikolai






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

Re: [fpc-devel] "Blank slate" next version of FPC

[Nikolai Zhubr]

Hi,
20.02.2019 21:28, Giuliano Colla:
[...]

I have just met such a situation: I ported from C++ to Pascal an
algorithm for the computation of the kinematics of a Delta Robot, and I
was badly bitten.
In that case you are just dealing with X,Y,Z coordinates, and
Theta0,Theta1,and Theta2 angles, and you find, in the body of a
procedure, some X,Y,Z or Theta which have global scope, and some which
are just local to some smaller (but not too small) block and which are
redeclared inline. Rather hard to tell them apart.


Excellent! Such redeclarations should obviously be borbidden. Otherwise 
it would loose almost the whole point. Java certainly rejects them.
And, it is easy to identify and reject such name clashes in this case, 
because the offending statement (declaration) can clearly be located.


On the other hand, I've been biten plenty by the already existing name 
clashes like:


  with Button1 do
  begin
Left := ClientWidth div 2;
.

and here nothing can probably be done to help at compiler part, because 
the statement is perfectly valid despite so obviously erroneous. I've 
seen some people even prepending "self." to almost any identifier in a 
desperate attempt to eliminate ambiguities. (And yes, it looked 
disgusting enough)



Thank you,

Regards,
Nikolai


Redeclaring inline an index I, which you'll be then using a lot of
times, is the best way to shoot you in the feet. Pascal encourages you
to use I,J,K at first, then ii,jj,kk etc.

Moreover, using a modern tool such as Lazarus, you never need to scroll
1000 lines to find a declaration: you just press alt+Up to go to the
declaration of the symbol over the cursor, and Ctrl+H to go back to the
line of code.

Keeping all declarations separated from code is just good programming
practice. Mixing declaration and code is bad programming practice, IMO,
and I appreciate Pascal for not supporting it.

Giuliano



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

Re: [fpc-devel] "Blank slate" next version of FPC

[Nikolai Zhubr]

Hi,

20.02.2019 18:24, Dimitrios Chr. Ioannidis via fpc-devel:
[...]

 I'd like to see an example how this is less safe.


Well one of the answer in the Cantu blog has this ( which I changed to
lets say a "real world" relative big function ) :


How this example is different from e.g. using normally declared "I, J: 
Integer" and employing "J" as a loop variable? Wouldn't it do the same 
error anyway?



Thank you,

Regards,
Nikolai


var arr: array...

function Fuckup: boolean;
var I: Integer;
begin



<>  20 lines of code



   for var I := Low(arr) to High(arr) do
 if arr[I]. then
   break;



   <>  20 lines of code



   Result := (I<= High(arr));
end;

regards,
--
Dimitrios Chr. Ioannidis



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


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

Re: [fpc-devel] "Blank slate" next version of FPC

[Nikolai Zhubr]

Hi,

20.02.2019 17:56, Martin Frb:

1) "for" (and other) loops with a long body also exist.
So the problem is still there, if I encounter "i" in the middle of a


This is correct. Inline declaration will not be able to solve all 
problems in the galaxy, it could just help to relieve some of them.



1000 line for-loop, I still do not see its declaration. So far, no loss,
but no gain either.

2) Nested loops exist. If in the middle of such a 1000 line for-loop, I
want to declare another loop, then I need to find a free identifier for
that variable.  Today, I can do that by looking at the declaration on top of the
procedure (and afaik depending on context, the class fields).
With inline declaration, I have to find each of the 10 surrounding
for-loops, scattered over a 1000 lines (And that is ignoring any
variables declared inline, but not as part of a for-loop). I would say
that is definitely worse.


You've probably missed that inline declartaion syntax is optional, not 
mandatory, and is intended to only be used where appropriate.



But just my 2 cents.

Now do not tell me that those loops should be refactored, because they
are based on your statement that this is not always sensible.

3) As for duck typing:
for var i:= Func1 to Func2 do;


I think it is totally different from "normal" inline declarations and I 
don't like it actually.



Thank you,

Regards,
Nikolai


What if that is "QWord to int64(or at some future points changes to that)?
What will "i" then be? And why?
Or should that be a compile error? (Probably the best)



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


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

Re: [fpc-devel] "Blank slate" next version of FPC

[Nikolai Zhubr]

Hi Sven,

20.02.2019 16:51, Sven Barth via fpc-devel:
[...]

Pascal is a language where declaration and use of variables is
separated.


I can understand that a language can (and should) try to follow some 
aesthetic tradition (which, btw, has already been horribly broken many 
times, imho, although it is not an excuse for further damage).
I can also understand that some immature syntactic sugar might introduce 
e.g. some ambiguities in parsing valid pascal code or some other 
specific unwanted problems, and if so, it can probably be demonstrated 
(to some extent at least, by an example or anyhow), and in such case 
indeed such new syntax should better be avoided.


However, the above statement about "Pascal as a language..." feels 
somehow strange. I'd say instead, that "Pascal as a language" was 
designed to be a tool to get job done efficiently, quickly, with 
confort, elegance, and superiority.



It makes it easy to see what variables are declared and what
type they are. Inline variables mess this up as a variable can be
declared somewhere inside the code.


Thats exactly what inline declaration does (when used reasonably): it 
makes it easy to see what variables are declared and what type they are. 
Well, at least, I see it as the intended purpose.



I use C++ to earn my living. I know why I'm not a fan of inline
variables as I've been biten by them often enough already.


Now it is getting even more curious. Admittedly I don't use C too much 
(and C++ even less so, approximately never), maybe that is why I do not 
understand your reasoning. Could you maybe give an example of such 
problematic inline declaration and its negative effect, in C++ at least? 
Honestly I can't imagine any.



Thank you,

Regards,
Nikolai



Regards,
Sven



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


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

Re: [fpc-devel] "Blank slate" next version of FPC

[Nikolai Zhubr]

Hi all,

20.02.2019 13:21, Sven Barth via fpc-devel:
[...]

And we don't agree here. For us inline variables is one of the most
horrid if not *the* most horrid thing Embarcadero could have done to
Object Pascal.


Could you elaborate a bit about it?
While I'm not really sure what they have done exactly (not using latest 
Delphi and probably not going to), I've somehow got very used to (and 
confortable with) Java's inline declarations, especially "for (int i = 
0; )" and similar constructs, and now I find myself doing this way 
all the time, because:


1. it makes it easier to see the whole picture just looking at the loop 
body, no need to scroll up; (The loop body might be just 10 lines of 
code, whereas the whole containing function sometimes has 1000s)


2. it isoltates the scope of such variable(s), therefore preventing some 
sorts of accidental misuse outside of e.g. the containing loop (which 
still do happen to me ocasionally in Pascal).


So I'm just wondering, what is wrong with such approach that it is 
considered so harmfull for Pascal? (Not talking here about possible 
excessive complexity of actual implementation in compiler, and not 
talking about the exact syntax chosen for that, just the idea as a whole)



Thank you,

Regards,
Nikolai


Regards,
Sven



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


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

Re: [fpc-devel] ref count types / threadsave question

[Nikolai Zhubr]

Hi,

03.01.2019 15:25, Benito van der Zander:

The ref count is stored in the same memory block as the string itself.

If core 2 could not see the new ref count, it could not see what is in
the string and thus not use the string for anything .


If string content modification is supposed to be possible and the said 
string is accessible by 2 or more threads, then some sort of explicite 
syncronization will need to be used (like with many other cases of data 
sharing across multiple threads). Pascal does not provide complete 
automatic thread-safety for strings (AFAIK). It does provide automatic 
lifecycle management (refcounting) only.



Regards,
Nikolai



Bye,
Benito

Am 02.01.19 um 21:52 schrieb Jonas Maebe:

On 02/01/19 21:46, Martin Frb wrote:

On 02/01/2019 21:22, Benito van der Zander wrote:

Hi,

but if another core can do anything to the string, the refcount
should already be 2, one for this core and one for the other core,
should it not?

No:

// global var
var
   Foo: String;

// main thread
Foo := getsomestring_with_refcount_1();
TMyThread.Create(false); // not suspended / start

Foo := ''; // de-ref

//TMyThread.Execute
LocalFoo := Foo; // copy from the global var


This is a different issue. Managed types are indeed only threadsafe as
long as there is no race condition that could cause their refcount to
become zero at some point.

The issue I was talking about is the fact that atomic operations do
function as global memory synchronisation operations across all cores
(at least not on all architectures). If core 1 atomatically increases
refcount to two and you "then" load the same refcount normally
(without an atomic read-modify-exchange oepration) on another core,
this other core may still see the old value.

The reason "then" is between quotes is because there is no forced
ordering between these two operations (since there is no
synchronisation/memory barrier linking the the two), which is also the
basis of the problem.

See e.g.
https://homes.cs.washington.edu/~bornholt/post/memory-models.html for
more information.


Jonas
___
fpc-devel maillist  - fpc-devel@lists.freepascal.org

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



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


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

Re: [fpc-devel] Building cross-compiler for arm-linux on win32

[Nikolai Zhubr]

16.12.2018 22:44, Florian Klämpfl:

Well, problem is a little bit that arm is really a moving target.


Yes, I know.
Besides, the exact difference between the "arm-linux" target and 
"armv7-linux-gnueabi" target is afaics just nowhere explicitely 
documented.(Though, binutils is opensource, one can read through and 
hopefully understand it... I tried a bit, but gave up soon.)



Thank you!

Regards,
Nikolai


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


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

Re: [fpc-devel] Building cross-compiler for arm-linux on win32

[Nikolai Zhubr]

Hi,

Yes, "armv7-linux-gnueabi" did the trick for cross-compiling on windows 
as well. I just had to manually rename binary files of binutils so that 
thay match the naming pattern fpc build system expacts. I can provide my 
ready-to-use win32-to-arm binutils 2.31.1 zip if someone is interested.


Besides, I employed the "mkbinutils" script from contribs on the 
website, and I like it quite a lot, although it needed some little 
updating too. Its a pity this script is not mentioned anywhere in 
official recommendations.


I'd like to note that apart from this binutils target pitfall, 
cross-compiling appeared to be surprisingly easy even when both cpu and 
os of the target differ from the host ones. Really fantastic thing. But, 
the documentaion is horribly lacking/incomplete/outdated, and in the 
absence of fine official manual/howto, there are lots of unofficial 
"manuals" floating around, full of wrong/random/irrelevant instructions.


Anyway, this is a great success, thanks to all!


Regards,
Nikolai


16.12.2018 21:01, I wrote:

Hi,

It seems I've finally cracked this puzzle, somewhat.

My self-built binutils were initially configured for "arm-linux" (That
is, configure --target="arm-linux"). As soon as I changed this to
"armv7-linux-gnueabi" (basically as a random guesswork) and rebuilt it
all including the cross-fpc and my helloworld test on host x86_64-linux
box again, I do not get much complaints from the build process anymore
and the resulting executable appeared runnable on the arm device!

Now going to retry it on windows again...


Thank you!

Regards,
Nikolai




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

Re: [fpc-devel] Building cross-compiler for arm-linux on win32

[Nikolai Zhubr]

Hi,

It seems I've finally cracked this puzzle, somewhat.

My self-built binutils were initially configured for "arm-linux" (That 
is, configure --target="arm-linux"). As soon as I changed this to 
"armv7-linux-gnueabi" (basically as a random guesswork) and rebuilt it 
all including the cross-fpc and my helloworld test on host x86_64-linux 
box again, I do not get much complaints from the build process anymore 
and the resulting executable appeared runnable on the arm device!


Now going to retry it on windows again...


Thank you!

Regards,
Nikolai


16.12.2018 20:20, Nikolai Zhubr:

Not exactly true. There is a release named "for raspberry" which is
3.0.4 and actually it seems usable for my board as well. Just installed
it there, tested that same helloworld, and it worked!
Wierd.


Thank you!

Regards,
Nikolai


download link goes to 3.0.2 version instead. Why is that? Is there any
known problem with 3.0.4 on arm or rather it is supposed to be
functionally identical to 3.0.2 ?


Thank you!

Regards,
Nikolai





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


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

Re: [fpc-devel] Building cross-compiler for arm-linux on win32

[Nikolai Zhubr]

16.12.2018 20:01, I wrote:

Hi,

16.12.2018 17:10, I wrote:

I'm wondering what version of binutils was used to release fpc 3.0.4 for
arm?


I've suddenly noticed that there is apparently no binary 3.0.4 release
for arm! Well, at least not officially presented on fpc website. The


Not exactly true. There is a release named "for raspberry" which is 
3.0.4 and actually it seems usable for my board as well. Just installed 
it there, tested that same helloworld, and it worked!

Wierd.


Thank you!

Regards,
Nikolai


download link goes to 3.0.2 version instead. Why is that? Is there any
known problem with 3.0.4 on arm or rather it is supposed to be
functionally identical to 3.0.2 ?


Thank you!

Regards,
Nikolai





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

Re: [fpc-devel] Building cross-compiler for arm-linux on win32

[Nikolai Zhubr]

Hi,

16.12.2018 17:10, I wrote:

I'm wondering what version of binutils was used to release fpc 3.0.4 for
arm?


I've suddenly noticed that there is apparently no binary 3.0.4 release 
for arm! Well, at least not officially presented on fpc website. The 
download link goes to 3.0.2 version instead. Why is that? Is there any 
known problem with 3.0.4 on arm or rather it is supposed to be 
functionally identical to 3.0.2 ?



Thank you!

Regards,
Nikolai




Thank you,

Regards,
Nikolai

16.12.2018 14:01, I wrote:

Hi,

16.12.2018 13:51, I wrote:
[...]

So inserting
ASTARGET+=-mfpu=softvfp
allowed full cross-build to succeed. I have yet to see if the generated
binaries are actually usable.


Ok, now the resulting elf executable has this (supposedly correct) flag:
private flags = 600: [APCS-32] [VFP float format] [software FP]

And, helloworld still fails to run:
Illegal instruction

And, I still see tons of "ARM BLX instruction ..." warnings from ld of
this kind:

C:\FPC\3.0.4\bin\i386-Win32\arm-linux-ld.exe:
arm\units\arm-linux\rautils.o: warning: ARM BLX instruction targets ARM
function 'SYSTEM_$$_POS$CHAR$SHORTSTRING$$LONGINT'
C:\FPC\3.0.4\bin\i386-Win32\arm-linux-ld.exe:
arm\units\arm-linux\rautils.o: warning: ARM BLX instruction targets ARM
function 'fpc_shortstr_copy'
C:\FPC\3.0.4\bin\i386-Win32\arm-linux-ld.exe:
arm\units\arm-linux\rautils.o: warning: ARM BLX instruction targets ARM
function 'fpc_shortstr_to_shortstr'
C:\FPC\3.0.4\bin\i386-Win32\arm-linux-ld.exe:
arm\units\arm-linux\rautils.o: warning: ARM BLX instruction targets ARM
function 'SYSTEM_$$_DELETE$OPENSTRING$LONGINT$LONGINT'

Currently, my build command is:
make OS_TARGET=linux CPU_TARGET=arm NOGDB=1 CROSSCOMPILE=1
CROSSOPT="-CpARMV6 -Cfsoft" all

Any hints?


Thank you!

Regards,
Nikolai




Thank you!

Regards,
Nikolai




Thank you!

Regards,
Nikolai


Thing is, object files compiled from pascal (like system.o) still get
this suspicious VFP flag even after I started using CROSSOPT="-CpARMV6
-Cfsoft". However, object files compiled from assembler sources (like
prt0.o) does not. I'm trying to find where it comes from.

arm-linux-objdump.exe -p prt0.o
prt0.o: file format elf32-littlearm
private flags = 0: [APCS-32] [FPA float format]

arm-linux-objdump.exe -p system.o
system.o: file format elf32-littlearm
private flags = 600: [APCS-32] [VFP float format] [software FP]

As a side note, I suddenly realised that I don't need any specially
crafted version of binutils as long as I target linux and build
binutils
from source. Standard binutils source tar compiles with almost zero
effort on modern mingw, at least for linux target.


Thank you!

Regards,
Nikolai


15.12.2018 23:23, I wrote:

Still can not understand this ".o uses VFP instructions, whereas .\pp
does not", but because I build binutils myself I've found and
disabled
the ld error exit on (in_flags & EF_ARM_VFP_FLOAT) != (out_flags &
EF_ARM_VFP_FLOAT), and then with such "fixed" binutils crossfpc build
completed somehow. I can now produce arm-linux executables, but
probably
something is wrong anyway because this "VFP float format" is
present in
.o files but not in final elf executables:

arm-linux-objdump.exe -p t.o
t.o: file format elf32-littlearm
private flags = 400: [APCS-32] [VFP float format]

arm-linux-objdump.exe -p t
t: file format elf32-littlearm
Program Header:
..
private flags = 0: [APCS-32] [FPA float format]

(t.pas is a helloworld one-liner.)

Besides, I get tons of warning from ld like this:
C:\FPC\3.0.4\bin\i386-Win32\arm-linux-ld.exe:
C:\FPC\3.0.4\units\arm-linux\rtl\system.o: Warning: Arm BLX
instruction
targets Arm function 'SYSTEM_$$_SYSINITSTDIO'.

It looks like literally every function in every unit produce such a
"Arm
BLX instruction" warning. Seems suspicious.

And finally, on the target board, the executable totally fails with:

"Illegal instruction"

Any hints?


Thank you!

Regards,
Nikolai


It successfully produced object files, but ld refsuses to link them.
Again, the message is:
pp.o uses VFP instructions, whereas .\pp does not
(lots of these repeated)

I'm guessing is that either some option is missing for ld to
actually
accept that VFP is present, or rather I need to rebuild my binutils
for
a different (hard fp) target?

(The exact call that fails now is arm-linux-ld.exe -s -L. -o .\pp
.\link.res)


Thank you!

Regards,
Nikolai





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


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


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




___
fpc-devel maillist - fpc-devel@lists.freepascal.org

Re: [fpc-devel] Building cross-compiler for arm-linux on win32

[Nikolai Zhubr]

16.12.2018 18:13, Jonas Maebe:

Which instructions does it show if you run the program in gdb and do
"x/2i $pc-4" when it crashes?


I made some additional steps in gdb in order to check if the program in 
question actually starts executing anything at all. Looks like it does:


GNU gdb (GDB; openSUSE Leap 42.3) 8.0
.
Reading symbols from t-bad...(no debugging symbols found)...done.
(gdb) info files
Symbols from "/root/personal/t-bad".
Local exec file:
`/root/personal/t-bad', file type elf32-littlearm.
Entry point: 0x100ec
0x000100c0 - 0x000100e0 is .note.ABI-tag
0x000100e0 - 0x0003dff4 is .text
0x0003dff8 - 0x00042cf8 is .rodata
0x00053000 - 0x00053c5e is .data
0x00053c60 - 0x00055c18 is .bss
(gdb) break *0x100ec
Breakpoint 1 at 0x100ec
(gdb) run
Starting program: /root/personal/t-bad

Breakpoint 1, 0x000100ec in ?? ()
(gdb) x/2i $pc
=> 0x100ec: mov r11, #0
   0x100f0: ldmfd   sp!, {r1}
(gdb) stepi
0x000100f0 in ?? ()
(gdb) stepi
0x000100f4 in ?? ()
(gdb) x/2i $pc-4
   0x100f0: ldmfd   sp!, {r1}
=> 0x100f4: ldr r12, [pc, #92]  ; 0x10158
(gdb) cont
Continuing.

Program received signal SIGILL, Illegal instruction.
0x0003155a in ?? ()
(gdb) x/2i $pc-4
   0x31556:
stmdb   sp!, {r0, r1, r2, r3, r4, r6, r7, r8, r9, r10, r11, 
r12, pc}

=> 0x3155a: ;  instruction: 0xfaff0060
(gdb)


Thank you!

Regards,
Nikolai



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


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

Re: [fpc-devel] Building cross-compiler for arm-linux on win32

[Nikolai Zhubr]

16.12.2018 17:03, Florian Klämpfl:
[...]

https://svn.freepascal.org/svn/fpcbuild/binaries/i386-win32/
? They work for me with the command line you mentioned. However, we have to 
support newer ones, I'll look into this.


With binutils from svn, the cross-build itself succeeded for me out of 
the box, although still producing "Arm BLX instruction ..." warnings.


But, the generated binary still does not work on the target device, 
generating "Illegal instruction".


I've noticed though that the binary has now a different set of flags, 
namely "[has entry point]" as compared to the ones produced by newer 
binutils, I guess that could be important:


objdump -p t
t: file format elf32-littlearm
private flags = 602: [APCS-32] [VFP float format] [software FP] [has 
entry point]


Apparently I'm now going to arrange some normal development environment 
on the target board directly to get further...



Thank you!

Regards,
Nikolai


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


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

Re: [fpc-devel] Building cross-compiler for arm-linux on win32

[Nikolai Zhubr]

Hi Florian,

16.12.2018 16:41, Florian Klämpfl:

I followed the thread, but didn't find it: what binutils do you use?


I've tried 3 version so far:

* binutils-2.15.94 (prebuilt) from fpc website is unusable because 
assembler refuses some instructions (I've mentioned it earlier)


* binutils-2.28-src for mingw, built by myself on mingw.

* binutils-2.31.1 regular source release, built by myself on both mingw 
and linux.


The latter 2 versions seem to show similar behaviour, resulting in the 
abovementioned results.



Thank you!

Regards,
Nikolai



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


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

Re: [fpc-devel] Building cross-compiler for arm-linux on win32

[Nikolai Zhubr]

Hi all,

(Sorry for flooding so much, but I've done some more testing!)

In order to isolate any possible wierd windows-specific issues, I've 
redone everything on x86_64-linux as a host, with the same 3.0.4 version 
starting compiler, same fpcbuild-3.0.4.zip as a source for cross-build, 
same arm-linux target and same binutils 2.31.1 built from stock source 
tarball, and same CROSSOPT="-CpARMV6 -Cfsoft".


Result seems exactly the same:

1. Adding the abovementioned ASTARGET+=-mfpu=softvfp to 
rtl/linux/Makefile[.fpc] is necessary, otherwise build will just fail.


2. Lots of "ARM BLX instruction ..." warnings from ld.

3. The resulting elf binary does not run on target device, generating 
"Illegal instruction"


So there definitely must be a problem somewhere.
Either I'm doing something really-really stupid, or maybe fpc 3.0.4 is 
incompatible with at least binutils >= 2.28 for arm target?
I'm wondering what version of binutils was used to release fpc 3.0.4 for 
arm?



Thank you,

Regards,
Nikolai

16.12.2018 14:01, I wrote:

Hi,

16.12.2018 13:51, I wrote:
[...]

So inserting
ASTARGET+=-mfpu=softvfp
allowed full cross-build to succeed. I have yet to see if the generated
binaries are actually usable.


Ok, now the resulting elf executable has this (supposedly correct) flag:
private flags = 600: [APCS-32] [VFP float format] [software FP]

And, helloworld still fails to run:
Illegal instruction

And, I still see tons of "ARM BLX instruction ..." warnings from ld of
this kind:

C:\FPC\3.0.4\bin\i386-Win32\arm-linux-ld.exe:
arm\units\arm-linux\rautils.o: warning: ARM BLX instruction targets ARM
function 'SYSTEM_$$_POS$CHAR$SHORTSTRING$$LONGINT'
C:\FPC\3.0.4\bin\i386-Win32\arm-linux-ld.exe:
arm\units\arm-linux\rautils.o: warning: ARM BLX instruction targets ARM
function 'fpc_shortstr_copy'
C:\FPC\3.0.4\bin\i386-Win32\arm-linux-ld.exe:
arm\units\arm-linux\rautils.o: warning: ARM BLX instruction targets ARM
function 'fpc_shortstr_to_shortstr'
C:\FPC\3.0.4\bin\i386-Win32\arm-linux-ld.exe:
arm\units\arm-linux\rautils.o: warning: ARM BLX instruction targets ARM
function 'SYSTEM_$$_DELETE$OPENSTRING$LONGINT$LONGINT'

Currently, my build command is:
make OS_TARGET=linux CPU_TARGET=arm NOGDB=1 CROSSCOMPILE=1
CROSSOPT="-CpARMV6 -Cfsoft" all

Any hints?


Thank you!

Regards,
Nikolai




Thank you!

Regards,
Nikolai




Thank you!

Regards,
Nikolai


Thing is, object files compiled from pascal (like system.o) still get
this suspicious VFP flag even after I started using CROSSOPT="-CpARMV6
-Cfsoft". However, object files compiled from assembler sources (like
prt0.o) does not. I'm trying to find where it comes from.

arm-linux-objdump.exe -p prt0.o
prt0.o: file format elf32-littlearm
private flags = 0: [APCS-32] [FPA float format]

arm-linux-objdump.exe -p system.o
system.o: file format elf32-littlearm
private flags = 600: [APCS-32] [VFP float format] [software FP]

As a side note, I suddenly realised that I don't need any specially
crafted version of binutils as long as I target linux and build
binutils
from source. Standard binutils source tar compiles with almost zero
effort on modern mingw, at least for linux target.


Thank you!

Regards,
Nikolai


15.12.2018 23:23, I wrote:

Still can not understand this ".o uses VFP instructions, whereas .\pp
does not", but because I build binutils myself I've found and disabled
the ld error exit on (in_flags & EF_ARM_VFP_FLOAT) != (out_flags &
EF_ARM_VFP_FLOAT), and then with such "fixed" binutils crossfpc build
completed somehow. I can now produce arm-linux executables, but
probably
something is wrong anyway because this "VFP float format" is
present in
.o files but not in final elf executables:

arm-linux-objdump.exe -p t.o
t.o: file format elf32-littlearm
private flags = 400: [APCS-32] [VFP float format]

arm-linux-objdump.exe -p t
t: file format elf32-littlearm
Program Header:
..
private flags = 0: [APCS-32] [FPA float format]

(t.pas is a helloworld one-liner.)

Besides, I get tons of warning from ld like this:
C:\FPC\3.0.4\bin\i386-Win32\arm-linux-ld.exe:
C:\FPC\3.0.4\units\arm-linux\rtl\system.o: Warning: Arm BLX
instruction
targets Arm function 'SYSTEM_$$_SYSINITSTDIO'.

It looks like literally every function in every unit produce such a
"Arm
BLX instruction" warning. Seems suspicious.

And finally, on the target board, the executable totally fails with:

"Illegal instruction"

Any hints?


Thank you!

Regards,
Nikolai


It successfully produced object files, but ld refsuses to link them.
Again, the message is:
pp.o uses VFP instructions, whereas .\pp does not
(lots of these repeated)

I'm guessing is that either some option is missing for ld to actually
accept that VFP is present, or rather I need to rebuild my binutils
for
a different (hard fp) target?

(The exact call that fails now is arm-linux-ld.exe -s -L. -o .\pp
.\link.res)


Thank you!

Regards,
Nikolai





___
fpc-devel maillist - fpc-devel@lists.freepascal.org

Re: [fpc-devel] Building cross-compiler for arm-linux on win32

[Nikolai Zhubr]

Hi,

16.12.2018 13:51, I wrote:
[...]

So inserting
ASTARGET+=-mfpu=softvfp
allowed full cross-build to succeed. I have yet to see if the generated
binaries are actually usable.


Ok, now the resulting elf executable has this (supposedly correct) flag:
private flags = 600: [APCS-32] [VFP float format] [software FP]

And, helloworld still fails to run:
Illegal instruction

And, I still see tons of "ARM BLX instruction ..." warnings from ld of 
this kind:


C:\FPC\3.0.4\bin\i386-Win32\arm-linux-ld.exe: 
arm\units\arm-linux\rautils.o: warning: ARM BLX instruction targets ARM 
function 'SYSTEM_$$_POS$CHAR$SHORTSTRING$$LONGINT'
C:\FPC\3.0.4\bin\i386-Win32\arm-linux-ld.exe: 
arm\units\arm-linux\rautils.o: warning: ARM BLX instruction targets ARM 
function 'fpc_shortstr_copy'
C:\FPC\3.0.4\bin\i386-Win32\arm-linux-ld.exe: 
arm\units\arm-linux\rautils.o: warning: ARM BLX instruction targets ARM 
function 'fpc_shortstr_to_shortstr'
C:\FPC\3.0.4\bin\i386-Win32\arm-linux-ld.exe: 
arm\units\arm-linux\rautils.o: warning: ARM BLX instruction targets ARM 
function 'SYSTEM_$$_DELETE$OPENSTRING$LONGINT$LONGINT'


Currently, my build command is:
make OS_TARGET=linux CPU_TARGET=arm NOGDB=1 CROSSCOMPILE=1 
CROSSOPT="-CpARMV6 -Cfsoft" all


Any hints?


Thank you!

Regards,
Nikolai




Thank you!

Regards,
Nikolai




Thank you!

Regards,
Nikolai


Thing is, object files compiled from pascal (like system.o) still get
this suspicious VFP flag even after I started using CROSSOPT="-CpARMV6
-Cfsoft". However, object files compiled from assembler sources (like
prt0.o) does not. I'm trying to find where it comes from.

arm-linux-objdump.exe -p prt0.o
prt0.o: file format elf32-littlearm
private flags = 0: [APCS-32] [FPA float format]

arm-linux-objdump.exe -p system.o
system.o: file format elf32-littlearm
private flags = 600: [APCS-32] [VFP float format] [software FP]

As a side note, I suddenly realised that I don't need any specially
crafted version of binutils as long as I target linux and build binutils
from source. Standard binutils source tar compiles with almost zero
effort on modern mingw, at least for linux target.


Thank you!

Regards,
Nikolai


15.12.2018 23:23, I wrote:

Still can not understand this ".o uses VFP instructions, whereas .\pp
does not", but because I build binutils myself I've found and disabled
the ld error exit on (in_flags & EF_ARM_VFP_FLOAT) != (out_flags &
EF_ARM_VFP_FLOAT), and then with such "fixed" binutils crossfpc build
completed somehow. I can now produce arm-linux executables, but
probably
something is wrong anyway because this "VFP float format" is present in
.o files but not in final elf executables:

arm-linux-objdump.exe -p t.o
t.o: file format elf32-littlearm
private flags = 400: [APCS-32] [VFP float format]

arm-linux-objdump.exe -p t
t: file format elf32-littlearm
Program Header:
..
private flags = 0: [APCS-32] [FPA float format]

(t.pas is a helloworld one-liner.)

Besides, I get tons of warning from ld like this:
C:\FPC\3.0.4\bin\i386-Win32\arm-linux-ld.exe:
C:\FPC\3.0.4\units\arm-linux\rtl\system.o: Warning: Arm BLX instruction
targets Arm function 'SYSTEM_$$_SYSINITSTDIO'.

It looks like literally every function in every unit produce such a
"Arm
BLX instruction" warning. Seems suspicious.

And finally, on the target board, the executable totally fails with:

"Illegal instruction"

Any hints?


Thank you!

Regards,
Nikolai


It successfully produced object files, but ld refsuses to link them.
Again, the message is:
pp.o uses VFP instructions, whereas .\pp does not
(lots of these repeated)

I'm guessing is that either some option is missing for ld to actually
accept that VFP is present, or rather I need to rebuild my binutils
for
a different (hard fp) target?

(The exact call that fails now is arm-linux-ld.exe -s -L. -o .\pp
.\link.res)


Thank you!

Regards,
Nikolai





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


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


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




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


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


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

Re: [fpc-devel] Building cross-compiler for arm-linux on win32

[Nikolai Zhubr]

Hi all,
16.12.2018 3:44, I wrote:
[...]

Got it, somewhat:
-mfpu=softvfp is passed to arm-linux-as while compiling intermediate .s
files (when using -Cfsoft), not sure if it is correct and intentional,
and no special flags passed to arm-linux-as while compiling assembler
sources.
Hence the difference reported by objdump.

Now apparently, current binutils' ld wants that somehow fpu type is also
specified for linking output if it was specified when assembling input
and they probably need to match each other. I could not find such
option, but e.g. gcc apparently has some way to automagically do it.


And after looking some more into current binutils, it seems machine code 
with this "VFP float format" and machine code without it are considered 
by ld not interoperable whatsoever. Therefore, when building for 
arm-elf, -mfpu=softvfp option should be passed either for _all_ 
generated object files or for _none_. Otherwise, linking normally can 
not succeed. And probably it is for a reason.


Apparently there is no way to explicitely specify something like -mfpu 
to ld, but because the setting can not be mixed anyway, the value is 
just inherited by the output elf executable from some (first ?) input 
object file ld encounters, afaics.


Looking into e.g. rtl/linux/Makefile[.fpc] there is e.g. this:
$(AS) $(ASTARGET) -o $(UNITTARGETDIRPREFIX)prt0$(OEXT) $(ARCH)/prt0.as
So inserting
  ASTARGET+=-mfpu=softvfp
allowed full cross-build to succeed. I have yet to see if the generated 
binaries are actually usable.



Thank you!

Regards,
Nikolai




Thank you!

Regards,
Nikolai


Thing is, object files compiled from pascal (like system.o) still get
this suspicious VFP flag even after I started using CROSSOPT="-CpARMV6
-Cfsoft". However, object files compiled from assembler sources (like
prt0.o) does not. I'm trying to find where it comes from.

arm-linux-objdump.exe -p prt0.o
prt0.o: file format elf32-littlearm
private flags = 0: [APCS-32] [FPA float format]

arm-linux-objdump.exe -p system.o
system.o: file format elf32-littlearm
private flags = 600: [APCS-32] [VFP float format] [software FP]

As a side note, I suddenly realised that I don't need any specially
crafted version of binutils as long as I target linux and build binutils
from source. Standard binutils source tar compiles with almost zero
effort on modern mingw, at least for linux target.


Thank you!

Regards,
Nikolai


15.12.2018 23:23, I wrote:

Still can not understand this ".o uses VFP instructions, whereas .\pp
does not", but because I build binutils myself I've found and disabled
the ld error exit on (in_flags & EF_ARM_VFP_FLOAT) != (out_flags &
EF_ARM_VFP_FLOAT), and then with such "fixed" binutils crossfpc build
completed somehow. I can now produce arm-linux executables, but probably
something is wrong anyway because this "VFP float format" is present in
.o files but not in final elf executables:

arm-linux-objdump.exe -p t.o
t.o: file format elf32-littlearm
private flags = 400: [APCS-32] [VFP float format]

arm-linux-objdump.exe -p t
t: file format elf32-littlearm
Program Header:
..
private flags = 0: [APCS-32] [FPA float format]

(t.pas is a helloworld one-liner.)

Besides, I get tons of warning from ld like this:
C:\FPC\3.0.4\bin\i386-Win32\arm-linux-ld.exe:
C:\FPC\3.0.4\units\arm-linux\rtl\system.o: Warning: Arm BLX instruction
targets Arm function 'SYSTEM_$$_SYSINITSTDIO'.

It looks like literally every function in every unit produce such a "Arm
BLX instruction" warning. Seems suspicious.

And finally, on the target board, the executable totally fails with:

"Illegal instruction"

Any hints?


Thank you!

Regards,
Nikolai


It successfully produced object files, but ld refsuses to link them.
Again, the message is:
pp.o uses VFP instructions, whereas .\pp does not
(lots of these repeated)

I'm guessing is that either some option is missing for ld to actually
accept that VFP is present, or rather I need to rebuild my binutils for
a different (hard fp) target?

(The exact call that fails now is arm-linux-ld.exe -s -L. -o .\pp
.\link.res)


Thank you!

Regards,
Nikolai





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


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


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




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


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

Re: [fpc-devel] Building cross-compiler for arm-linux on win32

[Nikolai Zhubr]

Hi,
16.12.2018 2:13, I wrote:

Is there any easy way to see how exactly ppcrossarm.exe invokes
assembler (command-line arguments passed) during a cross-compiler build
and also to inspect intermediate .s files?


Got it, somewhat:
-mfpu=softvfp is passed to arm-linux-as while compiling intermediate .s 
files (when using -Cfsoft), not sure if it is correct and intentional,
and no special flags passed to arm-linux-as while compiling assembler 
sources.

Hence the difference reported by objdump.

Now apparently, current binutils' ld wants that somehow fpu type is also 
specified for linking output if it was specified when assembling input 
and they probably need to match each other. I could not find such 
option, but e.g. gcc apparently has some way to automagically do it.



Thank you!

Regards,
Nikolai


Thing is, object files compiled from pascal (like system.o) still get
this suspicious VFP flag even after I started using CROSSOPT="-CpARMV6
-Cfsoft". However, object files compiled from assembler sources (like
prt0.o) does not. I'm trying to find where it comes from.

arm-linux-objdump.exe -p prt0.o
prt0.o: file format elf32-littlearm
private flags = 0: [APCS-32] [FPA float format]

arm-linux-objdump.exe -p system.o
system.o: file format elf32-littlearm
private flags = 600: [APCS-32] [VFP float format] [software FP]

As a side note, I suddenly realised that I don't need any specially
crafted version of binutils as long as I target linux and build binutils
from source. Standard binutils source tar compiles with almost zero
effort on modern mingw, at least for linux target.


Thank you!

Regards,
Nikolai


15.12.2018 23:23, I wrote:

Still can not understand this ".o uses VFP instructions, whereas .\pp
does not", but because I build binutils myself I've found and disabled
the ld error exit on (in_flags & EF_ARM_VFP_FLOAT) != (out_flags &
EF_ARM_VFP_FLOAT), and then with such "fixed" binutils crossfpc build
completed somehow. I can now produce arm-linux executables, but probably
something is wrong anyway because this "VFP float format" is present in
.o files but not in final elf executables:

arm-linux-objdump.exe -p t.o
t.o: file format elf32-littlearm
private flags = 400: [APCS-32] [VFP float format]

arm-linux-objdump.exe -p t
t: file format elf32-littlearm
Program Header:
..
private flags = 0: [APCS-32] [FPA float format]

(t.pas is a helloworld one-liner.)

Besides, I get tons of warning from ld like this:
C:\FPC\3.0.4\bin\i386-Win32\arm-linux-ld.exe:
C:\FPC\3.0.4\units\arm-linux\rtl\system.o: Warning: Arm BLX instruction
targets Arm function 'SYSTEM_$$_SYSINITSTDIO'.

It looks like literally every function in every unit produce such a "Arm
BLX instruction" warning. Seems suspicious.

And finally, on the target board, the executable totally fails with:

"Illegal instruction"

Any hints?


Thank you!

Regards,
Nikolai


It successfully produced object files, but ld refsuses to link them.
Again, the message is:
pp.o uses VFP instructions, whereas .\pp does not
(lots of these repeated)

I'm guessing is that either some option is missing for ld to actually
accept that VFP is present, or rather I need to rebuild my binutils for
a different (hard fp) target?

(The exact call that fails now is arm-linux-ld.exe -s -L. -o .\pp
.\link.res)


Thank you!

Regards,
Nikolai





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


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


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




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

Re: [fpc-devel] Building cross-compiler for arm-linux on win32

[Nikolai Zhubr]

Hi,

Is there any easy way to see how exactly ppcrossarm.exe invokes 
assembler (command-line arguments passed) during a cross-compiler build 
and also to inspect intermediate .s files?


Thing is, object files compiled from pascal (like system.o) still get 
this suspicious VFP flag even after I started using CROSSOPT="-CpARMV6 
-Cfsoft". However, object files compiled from assembler sources (like 
prt0.o) does not. I'm trying to find where it comes from.


arm-linux-objdump.exe -p prt0.o
prt0.o: file format elf32-littlearm
private flags = 0: [APCS-32] [FPA float format]

arm-linux-objdump.exe -p system.o
system.o: file format elf32-littlearm
private flags = 600: [APCS-32] [VFP float format] [software FP]

As a side note, I suddenly realised that I don't need any specially 
crafted version of binutils as long as I target linux and build binutils 
from source. Standard binutils source tar compiles with almost zero 
effort on modern mingw, at least for linux target.



Thank you!

Regards,
Nikolai


15.12.2018 23:23, I wrote:

Still can not understand this ".o uses VFP instructions, whereas .\pp
does not", but because I build binutils myself I've found and disabled
the ld error exit on (in_flags & EF_ARM_VFP_FLOAT) != (out_flags &
EF_ARM_VFP_FLOAT), and then with such "fixed" binutils crossfpc build
completed somehow. I can now produce arm-linux executables, but probably
something is wrong anyway because this "VFP float format" is present in
.o files but not in final elf executables:

arm-linux-objdump.exe -p t.o
t.o: file format elf32-littlearm
private flags = 400: [APCS-32] [VFP float format]

arm-linux-objdump.exe -p t
t: file format elf32-littlearm
Program Header:
..
private flags = 0: [APCS-32] [FPA float format]

(t.pas is a helloworld one-liner.)

Besides, I get tons of warning from ld like this:
C:\FPC\3.0.4\bin\i386-Win32\arm-linux-ld.exe:
C:\FPC\3.0.4\units\arm-linux\rtl\system.o: Warning: Arm BLX instruction
targets Arm function 'SYSTEM_$$_SYSINITSTDIO'.

It looks like literally every function in every unit produce such a "Arm
BLX instruction" warning. Seems suspicious.

And finally, on the target board, the executable totally fails with:

"Illegal instruction"

Any hints?


Thank you!

Regards,
Nikolai


It successfully produced object files, but ld refsuses to link them.
Again, the message is:
pp.o uses VFP instructions, whereas .\pp does not
(lots of these repeated)

I'm guessing is that either some option is missing for ld to actually
accept that VFP is present, or rather I need to rebuild my binutils for
a different (hard fp) target?

(The exact call that fails now is arm-linux-ld.exe -s -L. -o .\pp
.\link.res)


Thank you!

Regards,
Nikolai





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


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


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


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

Re: [fpc-devel] Building cross-compiler for arm-linux on win32

[Nikolai Zhubr]

Hi again,

15.12.2018 19:52, Nikolai Zhubr:

15.12.2018 18:24, Florian Klämpfl:

Now, I'm targeting an A20-olinuxino-micro board, which is afaik
armv7a with VPFv4. The board is running either openwrt
or opensuse. (And actually, the binaries produced by the pre-built
native compiler have been tested in both environments
already)

So I suppose I should be using CROSSOPT="-CpARMV7A -CfFPV4_S16" ?


... and -dFPC_ARMHF. It is more important than the others.


So, apparently most close to success for now was:
CROSSOPT="-CpARMV7A -CfvFPV2 -dFPC_ARMHF"


I've got more results.

First, for completeness, here is my actual /proc/cpuinfo:
Processor   : ARMv7 Processor rev 4 (v7l)
processor   : 0
BogoMIPS: 1434.46
processor   : 1
BogoMIPS: 1439.63
Features: swp half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 
idiva idivt


Currently, I'm trying with CROSSOPT="-CpARMV7A -CfvFPV3 -dFPC_ARMHF"
(FPV4_S16 failed with some assembler complaints, posted earlier, so I 
then tried vFPV3 and it compiled, so I just stayed with it for now)


Still can not understand this ".o uses VFP instructions, whereas .\pp 
does not", but because I build binutils myself I've found and disabled 
the ld error exit on (in_flags & EF_ARM_VFP_FLOAT) != (out_flags & 
EF_ARM_VFP_FLOAT), and then with such "fixed" binutils crossfpc build 
completed somehow. I can now produce arm-linux executables, but probably 
something is wrong anyway because this "VFP float format" is present in 
.o files but not in final elf executables:


arm-linux-objdump.exe -p t.o
t.o: file format elf32-littlearm
private flags = 400: [APCS-32] [VFP float format]

arm-linux-objdump.exe -p t
t: file format elf32-littlearm
Program Header:
..
private flags = 0: [APCS-32] [FPA float format]

(t.pas is a helloworld one-liner.)

Besides, I get tons of warning from ld like this:
C:\FPC\3.0.4\bin\i386-Win32\arm-linux-ld.exe: 
C:\FPC\3.0.4\units\arm-linux\rtl\system.o: Warning: Arm BLX instruction 
targets Arm function 'SYSTEM_$$_SYSINITSTDIO'.


It looks like literally every function in every unit produce such a "Arm 
BLX instruction" warning. Seems suspicious.


And finally, on the target board, the executable totally fails with:

"Illegal instruction"

Any hints?


Thank you!

Regards,
Nikolai


It successfully produced object files, but ld refsuses to link them.
Again, the message is:
pp.o uses VFP instructions, whereas .\pp does not
(lots of these repeated)

I'm guessing is that either some option is missing for ld to actually
accept that VFP is present, or rather I need to rebuild my binutils for
a different (hard fp) target?

(The exact call that fails now is arm-linux-ld.exe -s -L. -o .\pp
.\link.res)


Thank you!

Regards,
Nikolai





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


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


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

Re: [fpc-devel] Building cross-compiler for arm-linux on win32

[Nikolai Zhubr]

15.12.2018 19:09, wkitt...@windstream.net:

On 12/15/18 10:36 AM, Nikolai Zhubr wrote:

So I suppose I should be using CROSSOPT="-CpARMV7A -CfFPV4_S16" ?



is this a typo? should it be -CfVPF4_S16 with F and V swapped?


No. From ppcrossarm.exe -i:

Supported FPU instruction sets:
  SOFT,LIBGCC,FPA,FPA10,FPA11,VFPV2,VFPV3,VFPV3_D16,FPV4_S16

(And yes, such kind of abbrevations is always a bit frustrating to type 
and check, although it is obviously not fpc's fault)



Thank you!

Regards,
Nikolai


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

Re: [fpc-devel] Building cross-compiler for arm-linux on win32

[Nikolai Zhubr]

15.12.2018 18:24, Florian Klämpfl:

Now, I'm targeting an A20-olinuxino-micro board, which is afaik armv7a with 
VPFv4. The board is running either openwrt
or opensuse. (And actually, the binaries produced by the pre-built native 
compiler have been tested in both environments
already)

So I suppose I should be using CROSSOPT="-CpARMV7A -CfFPV4_S16" ?


... and -dFPC_ARMHF. It is more important than the others.


So, apparently most close to success for now was:
CROSSOPT="-CpARMV7A -CfvFPV2 -dFPC_ARMHF"

It successfully produced object files, but ld refsuses to link them. 
Again, the message is:

pp.o uses VFP instructions, whereas .\pp does not
(lots of these repeated)

I'm guessing is that either some option is missing for ld to actually 
accept that VFP is present, or rather I need to rebuild my binutils for 
a different (hard fp) target?


(The exact call that fails now is arm-linux-ld.exe -s -L. -o .\pp 
.\link.res)



Thank you!

Regards,
Nikolai





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


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

Re: [fpc-devel] Building cross-compiler for arm-linux on win32

[Nikolai Zhubr]

15.12.2018 17:38, Jonas Maebe:

T:\...3.0.4\fpcsrc\rtl\units\arm-linux>arm-linux-objdump.exe -p system.o
system.o: file format elf32-littlearm
private flags = 600: [APCS-32] [VFP float format] [software FP]

I suspect this is an inintended flag set by my arm-linux-as.exe for
some reason... Probably have to get rid of it somehow...


It would be useful to know on which ARM/Linux platform you want to run
your code (board/processor, and if it's an ancient board and/or kernel,
whether it's ARMEL/EABI or not), and which command line options you are
using to build FPC.

There is no single ARM/Linux platform, but many different incompatible
ones (which is one of the reasons there are no provided FPC
cross-compilers for this "platform".


Right, this is what I overlooked indeed (Well, because a pre-built 
native compiler for ARM did work successfully out of the box, producing 
perfectly usable arm binaries for me)


Now, I'm targeting an A20-olinuxino-micro board, which is afaik armv7a 
with VPFv4. The board is running either openwrt or opensuse. (And 
actually, the binaries produced by the pre-built native compiler have 
been tested in both environments already)


So I suppose I should be using CROSSOPT="-CpARMV7A -CfFPV4_S16" ?
If I use it, I get the following errors:

T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\system.s: Assembler 
messages:
T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\system.s:12587: Error: 
selected processor does not support `rfs r0' in ARM mode
T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\system.s:12590: Error: 
selected processor does not support `wfs r0' in ARM mode
T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\system.s:19745: Error: 
selected processor does not support `fcpyd d0,d1' in ARM mode
T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\system.s:19746: Error: 
selected processor does not support `fcpyd d1,d0' in ARM mode

system.pp(379) Error: Error while assembling exitcode 1


Thank you!

Regards,
Nikolai




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


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

Re: [fpc-devel] Building cross-compiler for arm-linux on win32

[Nikolai Zhubr]

15.12.2018 16:58, I wrote:

C:\FPC\3.0.4\bin\i386-Win32\arm-linux-ld.exe: error:
T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\system.o uses VFP
instructions, whereas .\pp does not
C:\FPC\3.0.4\bin\i386-Win32\arm-linux-ld.exe: failed to merge target
specific data of file


Hm, indeed, objdump confirms this VFP thing:

T:\...3.0.4\fpcsrc\rtl\units\arm-linux>arm-linux-objdump.exe -p system.o
system.o: file format elf32-littlearm
private flags = 600: [APCS-32] [VFP float format] [software FP]

I suspect this is an inintended flag set by my arm-linux-as.exe for some 
reason... Probably have to get rid of it somehow...



Thank you!

Regards,
Nikolai



T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\system.o
C:\FPC\3.0.4\bin\i386-Win32\arm-linux-ld.exe: error:
T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\objpas.o uses VFP
instructions, whereas .\pp does not
. [lots of similar lines follow]

Any ideas?

Thank you!

Regards,
Nikolai


15.12.2018 3:24, I wrote:

Hi all,

I'm trying to build a cross-compiler for arm-linux target on a win32
host. It fails at assembling system.s (produced from system.pp) with the
following output:

T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\system.s: Assembler
messages:
T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\system.s:11309: Error:
bad instruction `it ls'
T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\system.s:11334: Error:
bad instruction `it ls'
T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\system.s:11360: Error:
bad instruction `it ls'
T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\system.s:11387: Error:
bad instruction `it ls'
T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\system.s:13271: Error:
garbage following instruction -- `ldrd r0,r1,[r0]'
make.EXE[6]: *** [system.ppu] Error 1

I'm using arm-linux-as.exe from the recommended
binutils-2.15.94-win32-arm-linux.zip package downloaded from fpc
download area:

arm-linux-as --version
GNU assembler 2.15.94 20050202
Copyright 2005 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms
of the GNU General Public License. This program has absolutely no
warranty.
This assembler was configured for a target of `arm-linux-elf'.

What could be the reason for these errors?


Thank you!

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


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


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

Re: [fpc-devel] Building cross-compiler for arm-linux on win32

[Nikolai Zhubr]

Hi all,

Ok, apparently the binutils-2.15.94-win32-arm-linux.zip (provided on the 
fpc website) is somewhat outdated to be really usable for arm target.
Retrying with (self-built) binutils-2.28 apparently solves the previous 
problem but now I have another: ld yells something about VFP instructions:


T:/_tmp/fpcbuild-3.0.4/fpcsrc/compiler/ppcrossarm.exe -Tlinux -Parm 
-XParm-linux- -Xr -Ur -Xs -O2 -n -Fuarm -Fusystems 
-FuT:/_tmp/fpcbuild-3.0.4/fpcsrc/rtl/units/arm-linux -Fiarm -FE. 
-FUarm/units/arm-linux -dRELEASE -darm -dGDB -dBROWSERLOG -Sew-darm 
-dGDB -dBROWSERLOG  -Sew pp.pas
C:\FPC\3.0.4\bin\i386-Win32\arm-linux-ld.exe: warning: .\link.res 
contains output sections; did you forget -T?
C:\FPC\3.0.4\bin\i386-Win32\arm-linux-ld.exe: error: 
arm\units\arm-linux\pp.o uses VFP instructions, whereas .\pp does not
C:\FPC\3.0.4\bin\i386-Win32\arm-linux-ld.exe: failed to merge target 
specific data of file arm\units\arm-linux\pp.o
C:\FPC\3.0.4\bin\i386-Win32\arm-linux-ld.exe: error: 
T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\system.o uses VFP 
instructions, whereas .\pp does not
C:\FPC\3.0.4\bin\i386-Win32\arm-linux-ld.exe: failed to merge target 
specific data of file 
T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\system.o
C:\FPC\3.0.4\bin\i386-Win32\arm-linux-ld.exe: error: 
T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\objpas.o uses VFP 
instructions, whereas .\pp does not

. [lots of similar lines follow]

Any ideas?

Thank you!

Regards,
Nikolai


15.12.2018 3:24, I wrote:

Hi all,

I'm trying to build a cross-compiler for arm-linux target on a win32
host. It fails at assembling system.s (produced from system.pp) with the
following output:

T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\system.s: Assembler
messages:
T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\system.s:11309: Error:
bad instruction `it ls'
T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\system.s:11334: Error:
bad instruction `it ls'
T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\system.s:11360: Error:
bad instruction `it ls'
T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\system.s:11387: Error:
bad instruction `it ls'
T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\system.s:13271: Error:
garbage following instruction -- `ldrd r0,r1,[r0]'
make.EXE[6]: *** [system.ppu] Error 1

I'm using arm-linux-as.exe from the recommended
binutils-2.15.94-win32-arm-linux.zip package downloaded from fpc
download area:

arm-linux-as --version
GNU assembler 2.15.94 20050202
Copyright 2005 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms
of the GNU General Public License. This program has absolutely no warranty.
This assembler was configured for a target of `arm-linux-elf'.

What could be the reason for these errors?


Thank you!

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


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

[fpc-devel] Building cross-compiler for arm-linux on win32

[Nikolai Zhubr]

Hi all,

I'm trying to build a cross-compiler for arm-linux target on a win32 
host. It fails at assembling system.s (produced from system.pp) with the 
following output:


T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\system.s: Assembler 
messages:
T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\system.s:11309: Error: 
bad instruction `it ls'
T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\system.s:11334: Error: 
bad instruction `it ls'
T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\system.s:11360: Error: 
bad instruction `it ls'
T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\system.s:11387: Error: 
bad instruction `it ls'
T:\_tmp\fpcbuild-3.0.4\fpcsrc\rtl\units\arm-linux\system.s:13271: Error: 
garbage following instruction -- `ldrd r0,r1,[r0]'

make.EXE[6]: *** [system.ppu] Error 1

I'm using arm-linux-as.exe from the recommended 
binutils-2.15.94-win32-arm-linux.zip package downloaded from fpc 
download area:


arm-linux-as --version
GNU assembler 2.15.94 20050202
Copyright 2005 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms 
of the GNU General Public License.  This program has absolutely no warranty.

This assembler was configured for a target of `arm-linux-elf'.

What could be the reason for these errors?


Thank you!

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

Re: [fpc-devel] @Gareth messages thread

[Nikolai Zhubr]

Hi,

31.07.2018 19:05, J. Gareth Moreton:

I can only apologise for that. I can only
send and receive emails through a webmail
system on this address, and it doesn't
seem to honour the threading of the
messages. I'm not sure what option I'm
missing if there is one.


Sorry if I sound dumb, but maybe create e.g. some new gmail.com account 
for this and just use Thunderbird mailer with it? Would require maybe 15 
minutes to arrange. (Unless you use some very unusual OS where 
Thuderbird is unavailable or some very ugly uplink provider which 
filters normal traffic horribly)



Regards,
Nikolai


Gareth aka. Kit


On Tue 31/07/18 11:10 , "Dimitrios Chr.
Ioannidis via fpc-devel" fpc-
de...@lists.freepascal.org sent:

Hi Gareth,



could you please try again to fix the

threading for your messages ?


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

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

[Nikolai Zhubr]

Hi,

05.04.2018 10:12, Ondrej Pokorny пишет:
[...]

1.) Global variables are initialized. (Why is simple global variables
initialization needed for internal bookkeeping of the compiler?)


IIRC this was historically introduced by Borland (ages ago) because it 
was very cheap and easy to ask an OS of their choice to zero-out .data 
segment upon executable module loading, effectively getting 
initialization for free, and at that time (ages ago!) speed was what 
they cared most about.



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


Here again, it was relatively cheap and easy to fillchar/memset object's 
body internally before use. Not competely free, but pretty efficient 
still. So essentially same reason, I'd say.



3.) Everything else is not initialized.


Apparently this was not so cheap and not so easy for Borland (at least 
at that time). So apparently they chose to ignore.



From my personal perspective, this indeed is implementation detail, 
however wildely abused (me included), and it is a rather unfortunate 
situation. E.g. I'd be in a huge disaster if implicitely initialized 
strings suddenly start to be '' instead of empty. 
So ideally, something clever should be done about it at some point. 
Maybe indeed declaring it as a guaranteed behaviour or something. I kind 
of doubt there is a realistic chance of changing it anyway, due to 
compatability reasons...



Thank you.

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

Re: [fpc-devel] BacktraceStrFunc on linux x86_64?

[Nikolai Zhubr]

01.05.2017 14:35, Bernd Mueller:

On 05/01/2017 11:36 AM, Michael Van Canneyt wrote:


Only 3.0.2 linux for i386 CPU has the problem. 64-bit is OK.


hmm, I don't get the lineinfo on x86-64 (Ubuntu 16.04/Mate, 64-Bit).
armel and armhf are affected too.


Personally, for now I'll stick to 2.6.4 -- it works as expected at least 
on x86_64 linux here.


Besides, I've found my own mistake: when building an rpm package (with 
pascal program in this case), by default rpmbuild would choose to 
automagically strip the resulting binaries too much so this behaviour 
has to be suppressed (E.g. by __os_install_post %{nil} or whatever)



Thank you,
Nikolai



Regards, Bernd.

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


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

Re: [fpc-devel] BacktraceStrFunc on linux x86_64?

[Nikolai Zhubr]

01.05.2017 11:46, Florian Klämpfl:
[...]

And I'm still getting just an address anyway...



3.0.x is broken in this regard (stack back trace on x86-64 elf targets), see 
other threads on the
fpc mailing lists regarding this. This is why we discussing a quick as 
possibile 3.0.4 release.


Ah, ok. Couldn't find any mentions of the issue (bad googling or 
whatever) but anyway I'll probably have to wait for 3.0.4 then.


Thank you,
Nikolai



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


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

Re: [fpc-devel] BacktraceStrFunc on linux x86_64?

[Nikolai Zhubr]

01.05.2017 11:21, Michael Van Canneyt:
[...]

No, but the units that we distribute do not have debug information
included.
So if the error is in the RTL, then there is no debug information.


Ok, right, but then I suppose it should show line number as soon as the 
example is modified like this:


procedure Test3;
var a, b: integer;
begin
  a := 1; b := 0;
  writeln(a/b);
end;

And I'm still getting just an address anyway...


Thank you,
Nikolai



If I run your program with a RTL compiled with debug info, I get:

home: >./st
Started...
Exception: $0046F571 CHECKINDEX, line 56 of
../objpas/classes/lists.inc
Done.

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


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

[fpc-devel] BacktraceStrFunc on linux x86_64?

[Nikolai Zhubr]

Hello all,

I'm having some trouble to get BacktraceStrFunc to find line numbers.
This is with fpc 3.0.0 on linux x86_64 (Centos 7 if it matters).
If I compile the following example with

#fpc -gl tt.pas

I only get this output:

Started...
Exception:   $00455540
Done.

Evidently line info is somehow not present here.
Am I doing smth wrong or maybe lineinfo is not yet implemented for x86_64?

Thank you,
Nikolai
==
program tt; {$mode delphi }

uses SysUtils, Classes;

procedure Test3;
var list: TList;
begin
  list := TList.Create;
  if list[10] = nil then
writeln('Wow?');
end;

procedure Test2;
begin
  Test3;
end;

procedure Test;
begin
  writeln('Started...');
  try
Test2;
  except
writeln('Exception: ', BackTraceStrFunc(ExceptAddr));
  end;
  writeln('Done.');
end;

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

[fpc-devel] Links to current .rpm packages are broken on download pages.

[Nikolai Zhubr]

Hi all,

I've noticed that (at least some) download links are slightly wrong 
currently, e.g.:


ftp://freepascal.stack.nl/pub/fpc/dist/3.0.2/x86_64-linux/rpm/fpc-3.0.2-1.x86_64.rpm

should instead read:

ftp://freepascal.stack.nl/pub/fpc/dist/3.0.2/x86_64-linux/fpc-3.0.2-1.x86_64.rpm

(The "/rpm" subdirectory does not exist now so it gives an FTP 550 
error) The affected page is e.g. 
http://freepascal.org/down/x86_64/linux-netherlands.var and others 
related to linux downloads.



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

Re: [fpc-devel] A generic function for (multicore) cache flush?

[Nikolai Zhubr]

31.10.2016 23:07, Vincent Snijders:

Is there any good generic (portable) function to ensure memory cache
flush for a thread on a multicore system?


Maybe: http://www.freepascal.org/docs-html/rtl/system/readwritebarrier.html


Oh yes! That's the thing!
Thanks a lot!


Nikolai



Vincent


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

Re: [fpc-devel] A generic function for (multicore) cache flush?

[Nikolai Zhubr]

31.10.2016 22:44, Jeppe Johansen:

Is there any good generic (portable) function to ensure memory cache
flush for a thread on a multicore system?

What I'm trying to do is essentially fetch some debugging counters
from multiple threads. They might happen to run on separate cores,
thus having something pending in local cache sometimes. I would like
to avoid EnterCriticalSection/ LeaveCriticalSection as such blocking
would be a huge overkill, however it is still desireable to fetch
reasonably current values. I'd like to avoid doing manual assembly as
well (for portability reasons etc.).


Thanks a lot!

Nikolai

Have you found this to be a problem in real environments?


No.


I can't imagine any of the mainstream processor architectures of FPC
where you wouldn't expect normal coherent bus operation when just
reading cached memory from other processors. If all you need is just
reasonably recent values that is..


Ok. Probably you are right.
Thanks!

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

[fpc-devel] A generic function for (multicore) cache flush?

[Nikolai Zhubr]

Hello all,

Is there any good generic (portable) function to ensure memory cache 
flush for a thread on a multicore system?


What I'm trying to do is essentially fetch some debugging counters from 
multiple threads. They might happen to run on separate cores, thus 
having something pending in local cache sometimes. I would like to avoid 
EnterCriticalSection/ LeaveCriticalSection as such blocking would be a 
huge overkill, however it is still desireable to fetch reasonably 
current values. I'd like to avoid doing manual assembly as well (for 
portability reasons etc.).



Thanks a lot!

Nikolai

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

Re: [fpc-devel] Ability to handle instance pointers as ordinal type.

[Nikolai Zhubr]

Hi,
21.02.2016 13:37, tha...@thaddy.com:
[...]

 x := (Sender As TComboBox);
   8.
   9.
  case x.Name of
  10.
  'ComboBox01':if x.ItemIndex = -1 then x.ItemIndex := PrjIndex else
  11.
  begin


And what's wrong with just this:

if Sender = Combobox1 then
 ...
else if Sender = Combobox2 then
 ...
else


Regards,
Nikolai


  12.
  end;
  13.
  'ComboBox02':if x.ItemIndex = -1 then x.ItemIndex := HubIndex else
  14.
  begin
  15.
  end;
  16.
  'ComboBox03':if x.ItemIndex = -1 then x.ItemIndex := RimIndex else
  17.
  begin
  18.
  end;
  19.
  'ComboBox04':if x.ItemIndex = -1 then x.ItemIndex := SpkIndex else
  20.
  begin
  21.
  end;
  22.
  end;
  23.
  End;
  24.
  end;
  25.
  26.

  Now how much nicer it would be if you could write someting along the
lines of:

   1.
  procedure TFrame00.ComboBoxChanged(Sender: TObject);
   2.
  begin
   3.
  If Sender Is TComboBox Then
   4.
  case TCombobox(sender) of
   5.
   Combobox1:;
   6.
   ComboBox2:;
   7.
   ComboBox3:;
   8.
  end;
   9.
  end;

In other words, use the instance pointer as an ordinal value.
It looks a lot more logical but as it stands it is of course invalid syntax.
Is it possible to implement?
If so, has it any value? To me at least it looks feasable and less like
syntactic sugar than some features.



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


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

Re: [fpc-devel] Fwd: While - Otherwise Statement

[Nikolai Zhubr]

Hi all,
14.10.2015 23:44, Walter Prins:



On 14 October 2015 at 07:28, Martin Schreiber > wrote:

On Tuesday 13 October 2015 23:25:03 Michael Van Canneyt wrote:
>  However, I seem to be one of the very few thinking this given the
>  enthousiasm with which people are discussing this.
>

We are at least two people. :-)

For what it's worth, with me that's at least 3.


Me too! Me too!
That's 4 already :-)


Thank you,
Nikolai






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

Re: [fpc-devel] Proof of Concept ARC implementation

[Nikolai Zhubr]

Hello Sven!

25.10.2014 0:23, Sven Barth:

Hello together!

I've now finished my Proof of Concept ARC implementation which is based
on the RFC I published a few weeks back:

[...]

Could you please elaborate a bit on what will happen to cyclic 
references? Is there autodetection in place already? And then, will it 
be usable for managing of e.g. 100M-long 2-way linked list?


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

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

[Nikolai Zhubr]

22.09.2014 0:28, Peter Popov:
[...]

So, for classes which are reference counted, store the reference count @
the highest two bytes of the class instance (which in practice is a
pointer to the VMT). This would let you ref-count up to 2^16. You need to
mask it out from the rest of the pointer when accessing VMT. No need for
additional changes to the RTTI, just mask the highest two bytes when using
the class.


This would look aesthetically horid at least. Somehow reminds of 
segment:offset ugliness of 8086 ;-)


Besides, thinking about a magnificent brand new pointer type, and as 
long as certain performance penalties can be tolerated, one might want 
to also consider providing some path for heap defragmentation, for the 
sake of completeness (Not that I know how to properly do it, but still 
my $0.02).


Regards,
Nikolai




Peter

On Sun, 21 Sep 2014 23:03:43 +0300, Boian Mitov mi...@mitov.com wrote:


This is not true. Ref pointer is exactly the same size as non ref
pointer. the counter is in the instance not in the pointer to the
instance ;-) .
You can study the interface implementations or the String
implementations they are done the same way.

With best regards,
Boian Mitov

---
Mitov Software
www.mitov.com
---
-Original Message- From: Peter Popov
Sent: Sunday, September 21, 2014 12:29 PM
To: fpc-devel@lists.freepascal.org ; Sven Barth
Subject: Re: [fpc-devel] Suggestion: reference counted objects

Sven,
based on your comments a bizarre thought came to me. Currently, class
instances are pointers. What you propose will somehow create a special
pointer type (referenced class).

Should this be done, I have a request: create a 4 byte compressed class
reference which expands into an 8 byte pointer type prior to usage:
1. Most architectures align data.
2. 64 bit comps align pointers on 8 byte boundaries, meaning that the 3
leftmost bits are 0.
3. You could store a class pointer as a 4 byte integer and, prior to
usage, expand it to 8 bytes a leftshift 3.

In this way you will have 64GB of data available to your program and your
pointers will occupy twice less. If, for example one uses large amount of
pointers, this could be ... aesthetically pleasing ...


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






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

Re: [fpc-devel] MIPS big-endian program starts but does nothing

[Nikolai Zhubr]

Hi,
09.09.2014 0:54, Sven Barth:
[...]

http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revisionrevision=28625 
http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revisionrevision=28625

Since you're compiling with -CfSOFT this might be the solution.


BTW, the kernel on the devel mips box has the option Algorithmics/MIPS 
Emulator enabled (as otherwise debian refused to run), this probably 
explains why testsuite mostly succeeded whereas FPU is actually not 
present there.
IIRC this is essentially the only relevant change from default openwrt 
kernel I had to make, so I'd bet you are right.


Nikolai



Regards,
Sven



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


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

Re: [fpc-devel] MIPS big-endian program starts but does nothing

[Nikolai Zhubr]

07.09.2014 15:50, Florian Klämpfl:

Am 07.09.2014 um 13:49 schrieb Sven Barth:

Indeed.

We have at least two testsuite runs on BigEndian that only have an overviewable 
amount of errors, so
this indeed seems like something specific to the system or the way you compiled 
it. Can't help any
further though, sorry. :(


Is gdb or strace available on this system?


Yes. Both strace and gdb packages are available in openwrt (at least in 
the latest official release), they are just not included in typical 
released images (reasonable enough). One have to manually do:


opkg update
opkg install strace
opkg install gdb

HTH
Nikolai



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




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

Re: [fpc-devel] MIPS big-endian program starts but does nothing

[Nikolai Zhubr]

Hi!

06.09.2014 14:53, Reinier Olislagers:
[...]

Ok. It's running openwrt (also so that may well be the case; however I


Prebuilt/preflashed openwrt images most definitely do not have normal 
glibc, which is supposedly expected by normal linux rtl. Although I 
haven't checked myself, I think you could either try to somehow remove 
glibc dependancy for your test, or rebuild (and reflash) openwrt 
yourself with glibc/eglibc enabled, which might in turn require some 
digging and patching, see e.g. 
https://forum.openwrt.org/viewtopic.php?id=31174


On the other hand, if you are going to do some fpc-related 
testing/development/etc on mips, I can create and account for you on one 
of my debian mips boxes for remote access (Those are only used for daily 
builds so are idle most time of day).


Nikolai


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

Re: [fpc-devel] MIPS64

[Nikolai Zhubr]

15.08.2014 21:07, Florian Klämpfl:

Am 13.08.2014 22:05, schrieb Nikolai Zhubr:


What do you think? Would someone be interested in remote access to such device 
with some sort of
linux environment?


I want to work on aarch64 first.


Ok. That is quite reasonable.


Thank you.
Nikolai





As an (mostly) unrelated note: fpc testsuite web access seems to be broken 
currently?


Yes, due to server movements.

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




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

[fpc-devel] MIPS64

[Nikolai Zhubr]

Hello devels,

I've recently discovered that some mips64 devices have become quite 
affordable. Namely, EdgeRouter Lite (Dual-core mips64 500MHz, 512Mb RAM) 
is roughly $100. Because I already run two older (32-bit) mips boxes for 
fpc tasks, I thought I could probably add yet this newer device, if it 
could make any use for fpc development. (Although unfortunately I 
wouldn't develop myself, as I know exactly nothing about mips 
architecture and am short of time anyway)


One evident problem is lack of (official) ports of normal linux 
distributions. EdgeRouter Lite comes with some kind of debian 6 out of 
the box, however it was released by Cavium not Debian and therefore 
could be messy. Gentoo claims to support it officially though 
(http://wiki.gentoo.org/wiki/MIPS/ERLite-3)


What do you think? Would someone be interested in remote access to such 
device with some sort of linux environment?


As an (mostly) unrelated note: fpc testsuite web access seems to be 
broken currently?


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

Re: [fpc-devel] Testsuite database

[Nikolai Zhubr]

Hi Pierre,

Sorry for late reply, my main computer (with mail) was temporarily out 
of order.
I'm happy to confirm that the problem no longer exists. I do not get any 
error messages anymore. Also, it looks like query results are produced 
much faster now. Good work!
Actually, I reported the issue not because I suffered much from it right 
now but more because I thought it was a dangerous sympthom. Anyway, its 
good that the problem has been solved.

Thanks.

Nikolai

02.02.2013 21:00, Pierre Free Pascal:

   Thanks to your email,
   Yuri Sidorov (member of the core team)
took the time to look at the problems of the
testsuite.cgi program and fixed several issues he found.

   Please test and report if you still find problems...

Pierre Muller


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

[fpc-devel] Testsuite database

[Nikolai Zhubr]

Hello devels,

Apparently the test suite database needs some love?

E.g. see this URL (generated automatically by webpage, not by me): 
http://www.freepascal.org/testsuite/cgi-bin/testsuite.cgi?os=1cpu=8version=44date=submitter=machine=comment=cond=Category=1action=View+history


The application encountered the following error:

* Error: : Error executing query: You have an error in your SQL 
syntax; check the manual that corresponds to your MySQL server version 
for the right syntax to use near ') AND (TU_VERSION_FK=44) AND 
(TU_OS_FK=1) ORDER BY TU_ID DESC LIMIT 50' at line 1

* Stack trace:
  $0049DDD4 line 2147 of fcl-db/src/base/db.pas

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

Re: [fpc-devel] mips-linux and mipsel-linux snapshots available

[Nikolai Zhubr]

Hi Sergei and Mark,
16.12.2012 12:41, Sergei Gorelkin:
[...]

This was caused by insufficient alignment of Double-typed temp
variables, fixed in r23146.
Moreover, it appeared that function UnixToWinAge wasn't doing anything
useful since year 2005, so it was removed in r23145, making
FindFirst/FindNext routines somewhat faster (and able to run without FPU).

Now I am able to run the big-endian MIPS compiler on QEMU. Hoping you'll
be able to reproduce it, too.


This is to remind you guys that if you wish to do some 
testing/debugging/etc on a real mips device via ssh, two debian mips 
boxes (big and little endian) with plenty of disk space are running here 
24/7 for exactly that purpose. They are not much loaded and I can create 
some account(s) for you any time.


Nikolai



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




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

Re: [fpc-devel] mips-linux and mipsel-linux snapshots available

[Nikolai Zhubr]

17.12.2012 19:12, michael.vancann...@wisa.be:
[...]


The FPC team has a MIPS device (longsoon?) available. It's currently
switched off, but can be switched on at any time.


Ah, ok. That's good news. If it is longsoon then it must be much faster 
than mine. (Though IIRC it only exists in little endian variant). 
Anyway, I'll still keep my boxes up for now.


Nikolai



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




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

Re: [fpc-devel] Testing MIPS: newbie questions

[Nikolai Zhubr]

Hi,
15.10.2012 23:57, Mark Morgan Lloyd:
[...]

So most of the problems described in
http://wiki.lazarus.freepascal.org/Native_MIPS_Systems
should not be present anymore...


I'll update that presently. What I want to try doing first is running
the compiler natively (hosted by Qemu), later I might try putting it on
real hardware but I anticipate the endianness issue will take some work.

In case you need something for testing/debugging/documenting/whatever 
and encounter any problems getting your SGI boxes running - I can create 
an account for you here for ssh access (both big and little endian, both 
are up approx 24/7 anyway). Just let me know (in private).


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

Re: [fpc-devel] Same 64bit assembly code compiles under windows but not in linux (fpc 260)

[Nikolai Zhubr]

Hi,
03.10.2012 5:29, luiz americo pereira camara:
[...]

The complete procedure:

{$ASMMODE INTEL}

procedure AlphaBlendLineConstant(Source, Destination: Pointer; Count:
Integer; ConstantAlpha, Bias: Integer);

asm

{$ifdef CPU64}
// RCX contains Source
// RDX contains Destination
// R8D contains Count
// R9D contains ConstantAlpha
// Bias is on the stack


The procedure declaration above is not specific enough for the assembler 
block listed below, because

- the size of integer generally may vary;
- calling convention generally may vary;
I'd suggest to
- replace integer by longint or word, according to what assembler 
code expects;
- specify some calling convention according to what assembler code 
expects (IIRC in this case it is cdecl but I'm not completely sure).


HTH
Nikolai



 //.NOFRAME

 // Load XMM3 with the constant alpha value (replicate it for
every component).
 // Expand it to word size.
 MOVDXMM3, R9D  // ConstantAlpha
 PUNPCKLWD   XMM3, XMM3
 PUNPCKLDQ   XMM3, XMM3

 // Load XMM5 with the bias value.
 MOVDXMM5, [Bias]
 PUNPCKLWD   XMM5, XMM5
 PUNPCKLDQ   XMM5, XMM5

 // Load XMM4 with 128 to allow for saturated biasing.
 MOV R10D, 128
 MOVDXMM4, R10D
 PUNPCKLWD   XMM4, XMM4
 PUNPCKLDQ   XMM4, XMM4

@1: // The pixel loop calculates an entire pixel in one run.
 // Note: The pixel byte values are expanded into the higher
bytes of a word due
 //   to the way unpacking works. We compensate for this
with an extra shift.
 MOVDXMM1, DWORD PTR [RCX]   // data is unaligned
 MOVDXMM2, DWORD PTR [RDX]   // data is unaligned
 PXORXMM0, XMM0// clear source pixel register for
unpacking
 PUNPCKLBW   XMM0, XMM1{[RCX]}// unpack source pixel byte
values into words
 PSRLW   XMM0, 8   // move higher bytes to lower bytes
 PXORXMM1, XMM1// clear target pixel register for
unpacking
 PUNPCKLBW   XMM1, XMM2{[RDX]}// unpack target pixel byte
values into words
 MOVQXMM2, XMM1// make a copy of the shifted values,
we need them again
 PSRLW   XMM1, 8   // move higher bytes to lower bytes

 // calculation is: target = (alpha * (source - target) + 256 *
target) / 256
 PSUBW   XMM0, XMM1// source - target
 PMULLW  XMM0, XMM3// alpha * (source - target)
 PADDW   XMM0, XMM2// add target (in shifted form)
 PSRLW   XMM0, 8   // divide by 256

 // Bias is accounted for by conversion of range 0..255 to
-128..127,
 // doing a saturated add and convert back to 0..255.
 PSUBW XMM0, XMM4
 PADDSWXMM0, XMM5
 PADDW XMM0, XMM4
 PACKUSWB  XMM0, XMM0  // convert words to bytes with saturation
 MOVD  DWORD PTR [RDX], XMM0 // store the result
@3:
 ADD   RCX, 4
 ADD   RDX, 4
 DEC   R8D
 JNZ   @1

{$endif}

end;




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


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

Re: [fpc-devel] progress of freepascal for mips

[Nikolai Zhubr]

Hi,
09.06.2012 5:27, Fuxin Zhang:

I get a copy from my colleague for N32 ABI, no N64 found yet.See
http://www.lemote.com/upfiles/mips-abi-n32.pdf. I put it here because no
confidential sign in the document. But I am not sure whether it comes from
MIPS as a material to licensee. Will check later.


BTW, I'd like to remind that there is some errata for 24k cpu. I've 
faild to find any relevant official document on mips site but see e.g. 
Lost Data on Stores During Refill in this patch:


http://cygwin.com/ml/binutils/2011-04/txt00020.txt

As far as I understand it, the problem was fixed on assembler level so 
it'd seem it should not bother FPC. Anyway, one of my mips boxes is 
exactly 24k (wndr3800), another one is 74k (asus n16). Supposedly 74k 
does not suffer this problem.


Nikolai



Thanks.




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

Re: [fpc-devel] about freepascal for mips

[Nikolai Zhubr]

Hi,
25.05.2012 23:04, Jeppe Græsdal Johansen:
[...]

When I tried to build from SVN trunk there would be an endless steam of
internalerrors related to fpu registers, no matter if compiled with MIPS
FPU or softfloat.

I managed to remove the errors with the following patch, such that
everything compiled, but I haven't been able to test it:
http://j-software.dk/fpc-mipsel.patch

Does anyone know if there's an easy way to set up an emulator for
testing? Been fighting with qemu for the last half hour without results.


If you wish, I can create an account for you on my debian MIPS box 
(which was configured for Florian and other developers and is accessible 
via ssh almost 24/7) There is enough disk space for all anyway.


Also, I have debain MIPSEL box essentially ready. Developers have not 
requested it yet, so it is not running at the moment, but I can make it 
accessible very quickly if necessary.


Nikolai



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



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

Re: [fpc-devel] Bounty for MIPS

[Nikolai Zhubr]

Hello Florian,
07.02.2012 1:49, Florian Klämpfl:

Am 03.02.2012 01:37, schrieb Nikolai Zhubr:

I can set up ssh
for any FPC developer(s) (though I'll need some time to fix cables etc
then) Let me know.


It would be nice to get an account, currently I'am still busy with
fixing compilation issue but I'd expect first compiled programs within a
few days.


Ok, sorry for delay, I'm now fighting to hook shutdown to front panel 
button, otherwise all seems ready, hopefully it will be online 
permanently starting this weekend, and I'll then mail you login info 
(off list).


Nikolai


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




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

Re: [fpc-devel] Bounty for MIPS

[Nikolai Zhubr]

03.02.2012 14:26, Florian Klaempfl:


How did you install debian? Or is it a chroot'ed debian?


No, it it not chrooted.

Basically I took kernel from openwrt 10.03.1 build tree (it is also 
2.6.32 but modified slightly to better support platform-specific 
peripherials), disabled NAND-related drivers, and enabled ehci, 
usb_storage, ext4, etc as built-in. Then I took debian net-based 
installer's initrd.gz for malta board 
(http://ftp.debian.org/debian/dists/stable/main/installer-mips/current/images/malta/netboot/initrd.gz), 
unpacked it into ext2-formatted 1st (small) partiton of USB hard disk, 
keeping the rest of the disk available for adding more partitions later. 
Then I plugged this disk into wndr3800 and booted my kernel via tftp 
pointing it to /dev/sda1 as root. The only issue was that by default, 
openwrt kernel does not include inotify support which debain wants 
desperately, so I had to enable it and recompile. Other than that, all 
the rest was pretty much regular net-based install over serial console.


One inconvenience for now is that manual intervention is needed upon 
power-on to interrupt uboot before it proceeds normally to openwrt. I 
think it might be possible to arrange kexec'ing from the running openwrt 
but didn't try yet.


Nikolai


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




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

Re: [fpc-devel] Bounty for MIPS

[Nikolai Zhubr]

03.02.2012 16:01, Nikolai Zhubr:

03.02.2012 14:26, Florian Klaempfl:


How did you install debian? Or is it a chroot'ed debian?


No, it it not chrooted.


And by the way. If you somehow obtain wndr3800 and want debian on it, I 
can probably prepare ready-to-use images for hard disk and internal 
flash (It will then be debian-only until reflashed through recovery)


Nikolai



Basically I took kernel from openwrt 10.03.1 build tree (it is also
2.6.32 but modified slightly to better support platform-specific
peripherials), disabled NAND-related drivers, and enabled ehci,
usb_storage, ext4, etc as built-in. Then I took debian net-based
installer's initrd.gz for malta board
(http://ftp.debian.org/debian/dists/stable/main/installer-mips/current/images/malta/netboot/initrd.gz),
unpacked it into ext2-formatted 1st (small) partiton of USB hard disk,
keeping the rest of the disk available for adding more partitions later.
Then I plugged this disk into wndr3800 and booted my kernel via tftp
pointing it to /dev/sda1 as root. The only issue was that by default,
openwrt kernel does not include inotify support which debain wants
desperately, so I had to enable it and recompile. Other than that, all
the rest was pretty much regular net-based install over serial console.

One inconvenience for now is that manual intervention is needed upon
power-on to interrupt uboot before it proceeds normally to openwrt. I
think it might be possible to arrange kexec'ing from the running openwrt
but didn't try yet.

Nikolai


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




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




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

Re: [fpc-devel] Bounty for MIPS

[Nikolai Zhubr]

Hi,
31.01.2012 0:08, Pierre Free Pascal:

Anyhow, I just discovered that
the /home directory is 99% full on that GCC compile farm machine,
meaning that only  remote tests will be possible ☹

It seems that lots of developers have the same issue about finding
MIPS machines for testing ….


Would you consider the NetGear WNDR3800 680Mhz, 128MB RAM with a USB Flash 
drive of 32GB to be good enough for the development of the FPC toolchain ?
(in this case, I can purchase and ship such device to your place),

or would you consider that only a qemu virtual MIPS machine which can handle 
more memory and more disk space to be suitable for the development ?


   I just googled a bit and read that the
USB flash drives are considered as having only a limited number of writes
before that fail... (http://en.wikipedia.org/wiki/USB_flash_drive)
So I wonder how long such a system like that would last (it probably also 
depends on
the USB key quality itself?) if I run the testsuite each night
on it...

  Would a small USB hard drive be better? But does the device
have enough power to support such an external drive?
Would the speed be significantly lower or is the USB 2.0
speed the real limitation?


Ok. Debian installer ran amazingly smooth and apparently debian is quite 
happy with openwrt's kernel. You can see some numbers etc below. I 
wouldn't say it is blazingly fast, yet it is probably close to the best 
one can get of consumer-grade MIPS device at the moment. There is 10G / 
and 100G /home, hdd read/write speed is around 25Mb/s. I can set up ssh 
for any FPC developer(s) (though I'll need some time to fix cables etc 
then) Let me know. But be aware, it is big endian.


Nikolai

Debian GNU/Linux 6.0 wndr3800 ttyS0

wndr3800 login: root
Password:
Last login: Thu Jan  1 03:02:01 MSK 1970 from zhubr.lan on pts/0
Linux wndr3800 2.6.32.27openwrt #6 Thu Feb 2 23:45:12 MSK 2012 mips
root@wndr3800:~# cat /proc/cpuinfo
system type : Atheros AR7161 rev 2
machine : NETGEAR WNDR3700v2
processor   : 0
cpu model   : MIPS 24Kc V7.4
BogoMIPS: 452.19
wait instruction: yes
microsecond timers  : yes
tlb_entries : 16
extra interrupt vector  : yes
hardware watchpoint : yes, count: 4, address/irw mask: [0x0ffc, 
0x0ffc, 0x0ffb, 0x0ffb]

ASEs implemented: mips16
shadow register sets: 1
core: 0
VCED exceptions : not available
VCEI exceptions : not available

root@wndr3800:~# free
 total   used   free sharedbuffers cached
Mem:126588  32884  93704  0   5376  19028
-/+ buffers/cache:   8480 118108
Swap:   522232  0 522232
root@wndr3800:~# df /
Filesystem   1K-blocks  Used Available Use% Mounted on
/dev/sda3 10317112674588   9118444   7% /
root@wndr3800:~# df /home
Filesystem   1K-blocks  Used Available Use% Mounted on
/dev/sda4103727360192132  98266188   1% /home
root@wndr3800:~# hdparm -tT /dev/sda

/dev/sda:
 Timing cached reads:   276 MB in  2.01 seconds = 137.35 MB/sec
 Timing buffered disk reads:  78 MB in  3.06 seconds =  25.48 MB/sec
root@wndr3800:~# ld --version
GNU ld (GNU Binutils for Debian) 2.20.1-system.20100303
Copyright 2009 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later 
version.

This program has absolutely no warranty.
root@wndr3800:~# gcc --version
gcc (Debian 4.4.5-8) 4.4.5
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

root@wndr3800:~# gdb --version
GNU gdb (GDB) 7.0.1-debian
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
http://gnu.org/licenses/gpl.html

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type show copying
and show warranty for details.
This GDB was configured as mips-linux-gnu.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/.
root@wndr3800:~#



  Pierre Muller


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




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

Re: [fpc-devel] bounty: FPC based debugger

[Nikolai Zhubr]

12.09.2011 11:08, Graeme Geldenhuys:
[...]

If anybody with the know how is interested in implementing a Object
Pascal based debugger (or extending Duby specifically for use with FPC),
please let me know. I am more than willing to pay a few hundred US
dollars (or Euros) towards this bounty.


I'd also happily contribute $300 or so (in case there is a reasonable 
chance to actually get it working at least on windows/linux/bsd)


However, the effort needed is probably much much more expensive 
(Supposedly some pretty skilled developer(s) would have to work hard for 
several months, therefore it would then cost several thousands $ or more...)


Nikolai



So consider this an official bounty. If others want to add to this
bounty, you are more than welcome.


Regards,
   - Graeme -



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

Re: [fpc-devel] bounty: FPC based debugger

[Nikolai Zhubr]

12.09.2011 15:01, Henry Vermaak:

On 12/09/11 12:00, Martin Schreiber wrote:

And a FPC only debugger can not debug linked c libraries which we can do


Good point. I've found this very handy in the past.


currently with gdb. And think of the remote debugging options gdb
provides
with many targets.


Another one very handy for embedded developers.


Well maybe this could be resolved by allowing to select either gdb or 
another hypothetical debugger at runtime, if designed as kind of plugin. 
No feature loss would then happen, compared to current state.


That would be even more work, though :(

Nikolai



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




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

Re: [fpc-devel] Server availability

[Nikolai Zhubr]

06.09.2011 15:24, Alexander Klenin:

On Tue, Sep 6, 2011 at 22:17, Jonas Maebejonas.ma...@elis.ugent.be  wrote:

For at least last few months, I write down bugs I encounter in the local
file,
since by the time the Report Issue page loads, I forget what I
wanted to report.
I suspect the server is severely overloaded.


In general, not really. It does run out of memory sometimes (we're not sure
of the cause; both mantis and mysql have been pointed at as potential
culprits), but right now it has a load of 0.14 and 4.8GB free memory (out of
8GB, with 1.8GB used as cache).



Hm. This may be an issue with my provider then.
However, the only site affected is freepascal.org, which is very strange.
Will try to call the provider to investigate.



Just checked: right now mantis seems rather quick for me, at least for 
reading. I'd say it shows up immediately. (St.Petersburg)


HTH

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

Re: [fpc-devel] New FPC target: JVM

[Nikolai Zhubr]

20.08.2011 19:02, Graeme Geldenhuys:

On 20 August 2011 13:30, Felipe Monteiro de Carvalho wrote:


I ask because Android does not use Java Bytecode, it has it's own,
completely different bytecode.


Why did Google do that? Why not stay with the standardized Java and
get the benefits of all existing Java and Mobile Java apps?


IIRC Google was unhappy with java's licensing and/or management and did 
not happen to arrange it all with Sun in peacefull and mutually 
acceptable manner so they (Google) then opted to step away and create a 
separate new product formally unrelated of java and not bearing Sun's 
copyrights (which still didn't prevent subsequent patent harassment from 
Oracle however)


Now, regarding mobile java, you might notice that while you still can do 
a checkout at svn.java.net/svn/phoneme~svn (and it will still mostly 
work), the project looks and feels like essentially abandoned (no 
bugfixes/cleanups around, links bringing you to 404 pages etc etc) Of 
course there might be some development going on at Oracle internally, 
but there is no visible sign of it AFAICS.



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

Re: [fpc-devel] New FPC target: JVM

[Nikolai Zhubr]

Hi,
20.08.2011 12:49, Jonas Maebe:

Hi,

There is a new branch in svn (branches/jvmbackend) that contains support for 
compiling Pascal code into Java virtual machine bytecode.


This is really amazing, even if functionality is somewhat limited at the 
moment.


Thanks for the great work!


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

Re: [fpc-devel] volatile variables

[Nikolai Zhubr]

30.06.2011 13:31, Hans-Peter Diettrich:

If so, would it help to enclose above instructions in e.g.
Synchronized begin
update the links...
end;
If by such hypothetical synchronized operator you mean just memory 
barriers and nothing else, then AFAICS this would not be of much use in 
practice, because in case of strictly one thread barriers are unneeded 
anyway, and in case of 2 or more threads barriers are typically 
insufficient (because most of the time threads would also need race 
protection, which is not provided by barriers alone).
If what you mean here is rather a full-blown critical section with just 
some more elegant and generic syntax (i.e. a replacement of 
EnterCriticalSection/LeaveCriticalSection a la java), then yes, it might 
be nice, but mostly aesthetic-wise.


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

Re: [fpc-devel] volatile variables

[Nikolai Zhubr]

29.06.2011 15:28, Hans-Peter Diettrich:

But if so, which variables (class fields...) can ever be treated as
non-volatile, when they can be used from threads other than the main
thread?


Without explicit synchronisation? Actually, none.


Do you understand the implication of your answer?

When it's up to every coder, to insert explicit synchronization whenever
required, how to determine the places where explicit code is required?


All places where any non-readonly data could be accessed by 2 or more 
threads should be protected. Thats it.

Main thread is no special in this regard.

In order to reduce potential collisions, different critical section 
objects (mutexes) can be used to protect different (think unrelated) 
blocks of data in more fine-grained way.


Nikolai



Aren't we then in the unpleasant situation, that *every* expression can
be evaluated using unsynchronized values, unless the compiler uses
synchronized read instructions to obtain *every* value [except from stack]?

DoDi

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




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

Re: [fpc-devel] volatile variables

[Nikolai Zhubr]

29.06.2011 18:31, Michael Schnell:
[...]

So this is not supposed to work:

Main thread:

myThread := TmyThread.Create(True);
while not myThread.Suspended sleep(0); //give up time slice to allow the
worker thread to start
myList := TThreadlist.Create; // set the variable in cache 1
myThread.Suspended := False;
sleep(100); // have the worker thread run



Worker Thread:

procedure TmyTherad.Execute;
begin
myList := NIL; // set the variable in the cache 2
Suspended := True;
myList.Add(. //has the variable been synchronized from the other
cache 


Here the variable myList is not protected.


I think this code will work fine (at least on win32) because your main 
thread issues Sleep() and (implicitely) ResumeThread(), and your worker 
thread issues Sleep() and (implicitely) SuspendThread(). I somehow doubt 
that passing these system calls could let something remain unflushed in 
the cache, as the OS will most probably have to do some synchronization 
inside these calls for internal bookkeeping, but this is IMHO kind of 
side-effect.


If it was my program I'd use critical section explicitely anyway to be 
sure.


Nikolai



As assigning a value to myList in one thread is only a very short time
before the other thread reads it, it's very likely that the wrong value
is still be in the cache of the worker thread's processor and make it
crash.

But is is just a very extreme example of a behavior that mostly is
assumed to work and according to your wording would be bound to fail.

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




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

Re: [fpc-devel] volatile variables

[Nikolai Zhubr]

29.06.2011 19:57, Hans-Peter Diettrich:
[...]

imply that in detail all application specific
objects must be either local to an thread, or must be protected against
concurrent access (shareable)?

IMHO yes.

[...]

Possibly the language could be extended to help in the determination of
thread-(un)safe procedures. E.g. references to shareable objects could
Well yes, but its probably hard to inject such safety into a general 
purpose language. After all, pointers are not quite safe even in a 
single-threaded application!


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

Re: [fpc-devel] volatile variables

[Nikolai Zhubr]

28.06.2011 19:42, Hans-Peter Diettrich wrote:

Jonas Maebe schrieb:


2.) Blocking access as described in 4.11 does not address execution
order.


It does guarantee that if T1 locks the mutex, changes the value,
unlocks the mutex [...]


Can you explain please, to what changes the value applies?

To some variable, not explicitly named here, but not to the mutex.



I could not find a definition of the mutex struct, to determine whether
it contains any user-alterable values. When the value is declared
outside the mutex struct, it will be accessible also *without* locking
the mutex first.
A mutex is usually treated as opaque. It is only used when 
entering/leaving critical section, not for storing any user-accessible data.




However I can imagine that some mutex derived *class* (TCriticalSection)
can have additional fields, that are inaccessible until some code
obtains the mutex (similar to TThreadList). Otherwise a mutex cannot
protect anything but itself.
It is responsibility of a programmer to ensure that all accesses to the 
variable in question is surrounded by proper enter/leave constructs 
involving some mutex. Such proper constructs are not enforced by pascal 
language automatically (like say in java), so mistakes are quite 
possible (and sometimes do happen).


Nikolai



DoDi

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




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

Re: [fpc-devel] volatile variables

[Nikolai Zhubr]

28.06.2011 22:38, Vinzent Höfler wrote:

involving some mutex. Such proper constructs are not enforced by
pascal language automatically (like say in java), so mistakes are
quite possible (and sometimes do happen).


JFTR, but they aren't /enforced/ in Java, neither.
Well, ok, I didn't mean that synchronize is enforced, but rather that 
it is provisioned with such (simple) syntax that enforces some sanity 
and hides most complications (so that one can not forget to leave the 
protected block, or try to use some invalid mutex or try to modify the 
mutex directly etc...)


(That said, I'm personally quite happy with pascal though)

Nikolai



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




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

Re: [fpc-devel] Extended type

[Nikolai Zhubr]

19.04.2011 13:43, Alexander Klenin:

2011/4/19 Nikolai Zhubrn-a-zh...@yandex.ru:

Now, with the
introduction of 64-bit processors IIRC AMD took care of this problem by
providing some means to execute floating-point operations without the need
for traditional FPU register space, thus allowing to avoid the need to
save/restore FPU state. IIRC these are some _new_ opcodes, unavailable on
earlier CPUs.


Very interesting -- can you provide further detail on this?
I could not find anything relevant neither in vol.1 ch.6 nor vol.5 ch.2 of
AMD's APM -- is there something I overlooked?


Sorry, I looked into it several years ago, I don't have any links by 
hand anymore.
However, Jonas seem to be more exact on this. I think he is right and 
AMD just pushed deprecation of x87 in favour of SSE(2).


Nikolai





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

Re: [fpc-devel] Extended type

[Nikolai Zhubr]

19.04.2011 14:12, Daniël Mantione:


MS does preserve FPU states between processes. You can use the x87 on
Windows, nothing prevents you from doing so. Maybe the calling


Yes it does for 32-bit processes on win64, guaranteed.
But do you have any evidence (tests/documents/links) proving it also 
does so for 64-bit processes on win64?



convention, but even that you can extend with x87.

It's just that the documentation tells you not to use the x87.

Daniël



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


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

Re: [fpc-devel] Linux Signals

[Nikolai Zhubr]

02.01.2011 13:43, Michael Van Canneyt:


On Sat, 1 Jan 2011, Andrew Brunner wrote:


Thanks, Nikolai. epoll looks like the silver bullet (for linux) and
very promising. I can dump a bunch of sockets into it and get the
kernel to let me know which ones get notifications for
reset/read/write.


...Which is what I suggested in the first reply to your original question.

Do note that you're back to polling, which I understood you wanted to
avoid in the first place ?


Formally yes maybe, but Andrew probably meant just avoiding some 
horrible CPU-burning busy-loop.


Despite of the similar name (epoll), substantial shortcomings of 
classical polling scheme are gone. Say, you need not use a timeout to be 
able to handle any non-socket events like you were forced with select(), 
you can wait on descriptors of different types if you wish to, and you 
don't have to pass huge arrays all the way.



Nikolai



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




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

Re: [fpc-devel] Linux Signals

[Nikolai Zhubr]

01.01.2011 20:27, Andrew Brunner:

I'm trying to get signals to work with sockets under x64 Ubuntu 10.10
(all updates)

I installed two handlers for two events SIGIO, and SIGHUP uising
fpsigaction(SIGIO, @saAct, nil) .  I was expecting to get a byte by
byte signal under telnet to my server instance (110-pop3) on the IO
but had only received the signal on CRLF.  Firefox on the HTTP has the
same problem but I suspect a problem since it is impossible to ever
receive a signal for binary protocols having no CRLFs for as kernel
triggers to signal applications. Perhaps this particular issue is
better directed at Debian?

[...]

What are you trying to achieve ultimately? People tend to avoid using 
signals as much as possible nowadays (for anything beyond some nice 
handling of forced/fatal program termination and such) at least on 
linux. I'm not guru, just somewhat curious (because some time ago I had 
to re-engineer some small networking app, originating from windows, to 
be cross-platform and resource-friendly)


Nikolai

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

Re: [fpc-devel] Linux Signals

[Nikolai Zhubr]

02.01.2011 2:51, Andrew Brunner:

Hi Nikolai,

I'm trying to build a cross platform *event* driven socket signaling

Ok, now its more clear :)


mechanism that does not employ polling algorithms.

Then use epoll (linux-specific invention, BSDs have kqueue instead).

There is no exact match between linux and win32 for any non-trivial 
sockets IO, but creating OOP abstractions helps mitigate this.


When you say

resource-friendly... Do you mean CPU or memory?  I'm looking for

CPU was the biggest concern in our case.


something to work as advertised in the Linux man pages for signals.
If it turns out that signal information is missing via the Kernel - I
have no qualms with submitting a few requests to the proper
channels...
I've written some abstraction layer which employs epoll on linux and 
FD_xxx message notifications on win32. The typical use is serving up to 
several thousands of slow low-traffic connections concurrently with as 
low resources consumed as possible. Unfortunately I can't pull it out to 
publish as a library right now, though I planned to, eventually.


Nikolai


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




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

Re: [fpc-devel] pqconnection.pp Code Review Needed Int64 data types not supported in PostgreSQL

[Nikolai Zhubr]

22.10.2010 1:19, Andrew Brunner:

  As of right now the PostgreSQL component does not handle Int64
dataype and is crippling any use of the DBMS.  If MySQL and PostgreSQL
are broken - I just don't see the point of supporting SQL DBMSes.


Just in case: also have a look at zeosdbo library. I'm not sure about 
int64 specifically (as we do not use it in out database yet), but 
generally all things that we ever needed worked just fine there. (We've 
been happily running an FPC application with a Postgresql database for 
approx 2 years now almost 24/7)


Nikolai



Is there a massive reworking in the SQL area of FPC underway causing
the lack of quality for the diverse versions of the most popular sql
servers available?
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel




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

Re: [fpc-devel] threadvar implementation

[Nikolai Zhubr]

26.07.2010 13:04, Michael Schnell:

On 07/24/2010 06:55 PM, Nikolai Zhubr wrote:


I think only FS selector (and/or descriptor) varies across threads.

Seemingly not the selector value (the FS content seems to stay constant
among the threads), but the table entry it selects.


You are right. Just verified here too. Seems a bit illogical, especially 
as 3B is a GDT (not LDT) selector, therefore it's not subject to 
automatic substitution upon task switch. The scheduler patching GDT 
entry on every task switch is IMHO too crazy. It might be that FS's 
(descriptor) base points to some non-shared region of linear address 
space, so that different threads have different paging tables (It might 
be alpha's relict, whatever)


Anyway. MS designed it in those ancient times when they still cared that 
their NT OS was technically good. Both delphi and gcc use this 
mechanism. Therefore, I'd suppose it probably makes some sense. (I don't 
have time to get deep into it right now myself, and not that I'm going 
to push anyone, especially developers, but I still don't see a reason 
why it couldn't be employed in FPC eventually)


Nikolai


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



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

Re: [fpc-devel] is that intended? private type section in classes versus visibility

[Nikolai Zhubr]

27.07.2010 0:15, Graeme Geldenhuys:

On 26 July 2010 18:30, Marco van de Voortmar...@stack.nl  wrote:


If your idea was really so great, and this was really a solution, why don't
you simply describe it?


Yeah, yeah, we all know you have a terrible time maintaining FPC. Most
people can maintain legacy software, and still see chance for adding
and improving it.

[sorry, could not resist]


IMHO this is somewhat unfair. And generally, it's not like free software 
usually work. The core devlopers AFAIK are not on salary (at least not 
for implementing our wishes!). Proper development is quite 
time-consuming, I'm sure you know this very well. So, wouldn't it be 
better to first prepare a consistent formal proposal/description (like 
Marco suggested) or even a patch - and then if it is clearly good for 
all and is nevertheless rejected for no reason - only after that start 
flaming :)


Sorry, for off-topic, could not resist :(

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

Re: [fpc-devel] OO rewrite - technical questions

[Nikolai Zhubr]

24.07.2010 6:55, Hans-Peter Diettrich:


IMO the segment register is used implicitly in thread API calls, with
no further use by application code.


Exactly the opposite (at least delphi on windows). See delphi's RTL.

In the Using Thread Local Storage entry in the MSDN library this 
value is the handle of a memory block, created with LocalAlloc.



FS and GS may be used for special (OS, SEH and TLS) management, they are
useless in application code.


fs and gs whould indeed hardly ever be touched by application programmer 
directly (by hand), however (as it was already metioned several times 
earlier) delphi (on windows) and gcc (supposedly both windows and linux) 
use them to implement this special management so as exceptions and 
threadvars can be actually used without explicitely using OS APIs.


In such case of course fs/gs will not map to the same flat address 
segment (as cs, ds, es, ss) common for the whole process and all of its 
threads. Instead, it will map so a special segment created by OS for a 
specific thread. This segment might also be accessible as some other 
offset in the flat address space, or might not, but it isn't the point. 
Point is that a thread's code basically just needs to do a segment 
override (add 1-byte opcode modifier on x86 AFAIK) each time it wishes 
to get into its instance-unique data block, and this is supposed to be 
very inexpensive compared to OS syscalls. Also note, that fs/gs are not 
much usefull for anything else in an application (can not do any 
arithmetics, can not index flat offsets directly, etc etc), so they 
would otherwise be most probably totally unused (wasted) which is kind 
of pity.


As long as the base values are immutable, the equivalent absolute 
addresses can be used instead (in contrast to PIC).


Sure. But, as discussed before, all threads share the same code (i.e. 
the offset can not be hardcoded). Therefore, you'll need some register 
to access the instance-specific value (unless you are going to make OS 
calls every time). Probably on any arcitecture some general-purpose 
register capable of holding address offsets can be used for that. Such 
register would then have to be mostly excluded from normal use in the 
application (in other words - mostly wasted). Now, on x86/x86_64 there 
is yet additional tricky option: imploy a segment register, which would 
otherwise be unused. This way no general-purpose register is wasted and 
no OS syscalls are necessary either.



Consider a threadvar as a field of a related thread object (instance).


This might be fine most of the time (for end user in particular), 
however there still might be some non-OO code which it is 
impossible/impractical to convert into object-oriented model. See FPC RTL.


HTH.
Nikolai

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

Re: [fpc-devel] OO rewrite - technical questions

[Nikolai Zhubr]

24.07.2010 17:16, Florian Klämpfl:

Am 24.07.2010 13:42, schrieb Nikolai Zhubr:

use them to implement this special management so as exceptions and
threadvars can be actually used without explicitely using OS APIs.


Delphi does not use a segment register for threadvar handling but OS calls.


For a library - yes, you are right (My memory doesn't serve me good)
However, for an ordinary application - no:

var
  a: longint;
threadvar
  b: longint;
begin
[...]
  a := 1;
movebx,0001
  b := a;
call   @GetTls
mov[eax+0004],ebx
[...]
end.

where GetTls in case of an ordinary application (not dll) is just this:

MOV EAX,TlsIndex
MOV EDX,FS:tlsArray
MOV EAX,[EDX+EAX*4]


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



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

Re: [fpc-devel] OO rewrite - technical questions

[Nikolai Zhubr]

24.07.2010 19:12, Hans-Peter Diettrich пишет:
[...]

I doubt that this address range really is excluded from the 4GB app
address space, accessible through the other segment registers.


IMHO the question is not how to avoid using FS trick altogether (which 
is of course possible, right), but on the contrary, how to reliably 
employ it in order to avoid wasting some more usefull registers and 
excessive OS calls.


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

Re: [fpc-devel] OO rewrite - technical questions

[Nikolai Zhubr]

24.07.2010 19:46, Hans-Peter Diettrich:

MOV EAX,TlsIndex
MOV EDX,FS:tlsArray
MOV EAX,[EDX+EAX*4]


I wonder what TlsIndex here is?


tlsArray = $2C;
IIRC for an application (not a dll) TlsIndex is always 0
(But I might be wrong here though)


Also FS:tlsArray seems to contain an address in the general address
space, so that only the tlsArray seems to vary across threads? I had
thought that TlsIndex also should vary accross threads.


I think only FS selector (and/or descriptor) varies across threads.


DoDi

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



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