Re: [fpc-devel] Aligned dynamic arrays

2019-03-27 Thread Ryan Joseph 


> On Mar 27, 2019, at 9:13 PM, Martin Frb  wrote:
> 
> 2 Ideas, well 1 Idea, 1comment...
> 
> The Idea:
> Would it not be easier to:
> - allocate mem, with extra space for align, unless memmanager can handle 
> align.
> - return the alligned pointer for the array, so all array ops will work 
> exactly as they currently do
> - prefix/extend the array header by a field "OffsetToMemAlloc" (that is the 
> reverse, of what I understand your padding would do, but still can be a 
> positive number, the code knows to subtract it where needed)
> 
> This field would allow to correctly get the memory for re-alloc/free 
> operations.

I think we’re basically talking about the same thing but it’s hard to know 
without seeing code. The biggest challenge is that in order to get the array 
header you need to subtract from the “head" (the start of the elements). Right 
now it’s easy because you just subtract the size of the header but if the head 
is now aligned and 100’s of bytes away from the start of the header then you 
need to subtract that amount also. In fact technically speaking the offset 
field is adjacent to the start of elements and could be many bytes away from 
the actual header.

Here’s the basic structure:

[header][padding][offset][head]

[head] being the start of the elements (the pointer to the first element of the 
array) and aligned to the requested amount. Keep in mind the head is the 
pointer which is passed around so we need to subtract back from that in order 
to access the header, which contains the array high value and the refcount.

Look at the dynarr.inc in the /rtl directory to see what I’m talking about. 
Pretty hard to explain without seeing how Sven did things. :)

> 
> The comment:
> As for extending the array header, maybe introduce a new data type "aligned 
> array".
> So normal arrays do not have that field in there header.

The plan was to make a “SetLengthAligned” or add an extra parameter to 
“SetLength”, i.e, SetLength(arr,100,true). I have no preference, what ever the 
compiler team wants.

Regards,
Ryan Joseph

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

Re: [fpc-devel] Packed record integers and x86_86

2019-03-27 Thread J. Gareth Moreton 
 I think the official unsigned 32-bit integer type in Pascal is "LongWord".
 As others have said, be aware that pointers are 64-bit under x64... that's
kind of why it's called x64!  If you absolutely must have a packed record
with 32-bit types, I recommend changing Sender and Target to indices that
are added to a base address.
 Similar to what Pierre said, change your Pointer code to something like
this:
 for Indx := 0 to SizeOf(TTCPPackageHeader) - 1 do
Dec(Byte(Pointer(PtrUInt(@x) + Indx)^), ARollCount);

 So similarly with your record, instead of directly derefencing Sender and
Target - since I assume your record type must stay fixed at 15 bytes - have
something akin to "Pointer(PtrUInt(@BaseAddr) + Sender)".

 The first rule, first and foremost... don't assume the Pointer is a fixed
size.  Hope all of this helps.

 Gareth aka. Kit
 P.S. I would recommend adding a "Filler" or "Reserved" byte at the end of
your record type to make it 16 bytes long - such a size is more efficient
when it's part of an array in memory.

 On Wed 27/03/19 21:11 , Pierre Muller pie...@freepascal.org sent:

 > ___ 
 > fpc-devel maillist  -  fpc-devel@lists.freepascal.org  
 > http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[2]">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel 
 > 
 > 
 > Pointer arithmetic: 
 > *for Indx := 0 to SizeOf(TTCPPackageHeader) - 1 do
Dec(Byte(Pointer(Cardinal(@x) + Indx)^), ARollCount);* 
 the error has nothing to do with your record, 
 its that part: 
 Pointer(Cardinal(@x) + Indx)^) 

 The problem is that Cardinale is an unsigned 32-bit integer, 
 while on 64-bit, you will need UINT64, 

 You should use PtrUInt type that is an unsigned type 
 that always have the size of an address instead of cardinal here! 

 Pierre 
 ___ 
 fpc-devel maillist - fpc-devel@lists.freepascal.org [3] 
 http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[4]">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel 

 

Links:
--
[1] mailto:fpc-devel@lists.freepascal.org
[2] http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[3] mailto:fpc-devel@lists.freepascal.org
[4] 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] Programming in Pascal .

2019-03-27 Thread Carsten Bager 
Hi
If you download FPC and source, then I think it can be done.
I have tried to do this test program on my Pi.
Below is a description of the installation of Lazarus, you can skip the lazarus 
part.
Carsten


Program Test1;
{$RANGECHECKS ON}
{$OVERFLOWCHECKS ON}
{$S+ STACK CHECKING ON}
{$SMARTLINK ON}
{$TYPEINFO ON}
{$LONGSTRINGS ON}
{$VARSTRINGCHECKS Off}

Uses
  cthreads,
  classes,
  sysutils,
  PtcMouse,
  PtcCrt,
  PtcGraph;

Begin
  Writeln('Test');
End.

Compiled with
/pp/Fpc/bin/fpc -gl -XX -FU"Ppu" -Fu"/pp/fpcsrc/packages/graph/src/ptcgraph" 
-Fi"/pp/fpcsrc/packages/graph/src/inc" Test1.pp

This is done on a Pi
Free Pascal Compiler version 3.0.4 [2017/10/11] for arm
Copyright (c) 1993-2017 by Florian Klaempfl and others
Target OS: Linux for ARMHF
Compiling Test1.pp
Assembling test1
Linking Test1
Test1.pp(19,17) Warning: "crtbegin.o" not found, this will probably cause a 
linking failure
Test1.pp(19,17) Warning: "crtend.o" not found, this will probably cause a 
linking failure
/usr/bin/ld: warning: link.res contains output sections; did you forget -T?
19 lines compiled, 3.4 sec
2 warning(s) issued



If you want the newest Lazarus IDE on a PI, do the following (I use Midnight 
Commander on the Pi (sudo apt-get -y install mc) when unpacking tgz files etc).



  1.  Download FPC for Pi (Everything in 1 big package for eabihf ABI for 
raspberry)
  2.  Download FPC source 
(fpc-3.0.4.source.tar.gz)
  3.  Download Lazarus source (lazarus-1.8.4.tar.gz) or 
(lazarus-2.0.0.tar.gz)
  4.  Create a folder /pp that belongs to the pi user and the pi group. (sudo 
install -d -o pi -g pi -m 0770 /pp)
Install Fpc in /pp/fpc folder
Create a /pp/fpcsrc folder
Place the downloaded fpc source in /pp/fpcsrc
Create a /pp/lazarus
Place the downloaded lazarus source /pp/lazarus
  5.  Place the make-lazarus-first.sh script in /pp/lazarus
  6.  Run the make-lazarus-first.sh script
  7.  Place the make-lazarus.sh script in /pp/lazarus
  8.  Run the make-lazarus.sh script
  9.  Create link in /bin to fpcres (sudo ln -sf /pp/fpc/bin/fpcres 
/bin/fpcres).
  10. To create a Menu Programming short cut, go to
Menu -> Preferences-> Main Menu Editor
  11. To create a Desktop short cut, place the text file "Lazarus" in the 
folder "/home/pi/Desktop/"



  *   Filename = "Lazarus"
[Desktop Entry]
Type=Application
Encoding=UTF-8
Name=Lazarus
Comment=Pascal IDE
Icon=/pp/lazarus/ide/lazarus.ico
Exec=/pp/lazarus/startlazarus
Terminal=false
Categories=X-Debian-Applications-Editors;



  *   Filename = "make-lazarus-first.sh"
#!/bin/sh
#sudo apt-get update
sudo apt-get install -y libx11-dev libgdk-pixbuf2.0-dev libcairo2-dev 
gir1.2-coglpango-1.0 libpangox-1.0-dev xorg-dev libgtk2.0-dev libpango1.0-dev



  *   Filename = "make-lazarus.sh"
#!/bin/sh
export PATH=/pp/fpc/bin:$PATH
make all OPT=-dFPC_ARMHF
sleep 60
make install OPT=-dFPC_ARMHF PREFIX=/pp/lazarus



  *   Links
Lazarus on Raspberry Pi




On 26 Mar 2019 at 9:07, Yves Boudeville wrote:

> Bonjour.
> I am asking questions on the art of scientific computing from 1966.
> After Algol and Modula,
> the U.C.S.D. Pascal system has been the touchstone of the scientific
> computing. This has
> been devoted by Niklaus Wirth book and applied in Borland TP7 software.
> The only thing
> scientists need is a strongly typed language with pixel access on a
> single graphical windows.
>   This is needed, for instance, by Monte-Carlo simulations. We need the
> full power of the
> computer with the pixel definition of the result because the eyes are
> the  best investigators
> for scientific bugs. TP7 with graph was the best tool for that. For less
> mathematical
> approaches, like 3D models it was sufficient to use Borland Delphi-7.
> Now, in 2019, it was
> possible to use FPC compiler with Fp-IDE to make in laboratories good
> simulations of
> scientific equations, very clean in FPC Pascal, with the Graphical tools
> PtcGraph, PtcCrt, etc
> ... It is far more useful than old Seymour Cray Fortran or C// on
> Connection Machines CM1 / CM2
> of Hillis : Theses need M.I.T. gourous in big National Laboratories.
> Some years ago, it was possible with the good job of Nikolay Nikolov on
> Ptc Pascal Units, to do
> clean-proof use of computer to visualize physics in HDMI 1920 x 1080 x
> 65536c under Windows.
> With lesser resolution, a work in Pascal was running without
> adding/changing a word under
> Windows_Intel / Ubuntu_Linux / or Raspbian_Raspberry Rpi3. Now, for
> scientific use, it is not
> possible because  ptcgraph etc... are not included in latest versions,
> for instance of Raspbian.
> So, in order to use software in Physics, we are compelled use old

Re: [fpc-devel] Aligned dynamic arrays

2019-03-27 Thread Martin Frb 

On 28/03/2019 00:43, Ryan Joseph wrote:

I would like to attempt to implement this feature request 
(https://bugs.freepascal.org/view.php?id=34031 for my boss) which has the 
SetLength intrinsic return aligned memory. We need this for the Metal framework 
which requires all vertex buffer memory to aligned on 4k boundaries so we can’t 
use dynamic arrays in their current form (see the bug report for example code).

I’ve looked at the dynamic array implementation (dynarr.inc) and it appears 
that I could over allocate and extend the header (tdynarray) to include an 
extra field which stores the amount of padding until the actual array elements 
start (which is aligned). It would complicit the code to some extent however 
because the current design relies on lots of pointer math.

Is this ok that I add this? Marco said in the comments there was a need so I 
assume this is a go but I wanted to ask first.


2 Ideas, well 1 Idea, 1comment...

The Idea:
Would it not be easier to:
- allocate mem, with extra space for align, unless memmanager can handle 
align.
- return the alligned pointer for the array, so all array ops will work 
exactly as they currently do
- prefix/extend the array header by a field "OffsetToMemAlloc" (that is 
the reverse, of what I understand your padding would do, but still can 
be a positive number, the code knows to subtract it where needed)


This field would allow to correctly get the memory for re-alloc/free 
operations.


The comment:
As for extending the array header, maybe introduce a new data type 
"aligned array".

So normal arrays do not have that field in there header.

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

[fpc-devel] Aligned dynamic arrays

2019-03-27 Thread Ryan Joseph 
I would like to attempt to implement this feature request 
(https://bugs.freepascal.org/view.php?id=34031 for my boss) which has the 
SetLength intrinsic return aligned memory. We need this for the Metal framework 
which requires all vertex buffer memory to aligned on 4k boundaries so we can’t 
use dynamic arrays in their current form (see the bug report for example code).

I’ve looked at the dynamic array implementation (dynarr.inc) and it appears 
that I could over allocate and extend the header (tdynarray) to include an 
extra field which stores the amount of padding until the actual array elements 
start (which is aligned). It would complicit the code to some extent however 
because the current design relies on lots of pointer math.

Is this ok that I add this? Marco said in the comments there was a need so I 
assume this is a go but I wanted to ask first.

Regards,
Ryan Joseph

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

Re: [fpc-devel] Packed record integers and x86_86

2019-03-27 Thread Pierre Muller 

> ___
> fpc-devel maillist  -  fpc-devel@lists.freepascal.org 
> 
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
> 
> 
> Pointer arithmetic:
> *for Indx := 0 to SizeOf(TTCPPackageHeader) - 1 do 
> Dec(Byte(Pointer(Cardinal(@x) + Indx)^), ARollCount);*
the error has nothing to do with your record,
its that part:
Pointer(Cardinal(@x) + Indx)^)

The problem is that Cardinale is an unsigned 32-bit integer,
while on 64-bit, you will need UINT64,

  You should use PtrUInt type that is an unsigned type
that always have the size of an address instead of cardinal here!


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

Re: [fpc-devel] Packed record integers and x86_86

2019-03-27 Thread DJ Coertzen 
On Wed, Mar 27, 2019 at 7:47 PM Sven Barth via fpc-devel <
fpc-devel@lists.freepascal.org> wrote:

> DJ Coertzen  schrieb am Mi., 27. März 2019,
> 18:27:
>
>> Hi there,
>>
>> I need a solution for a packed record containing 4-byte 32-bit integers
>> and cardinals, and other byte 8 bit and word 16 bit sized variables to
>> overlay over a stream.
>>
>> Example:
>> *type*
>> *  TMyBinaryHeader = packed record*
>> *Sender: Cardinal;*
>>
>> *Target: Cardinal;*
>>
>> *Reference : Integer;*
>>
>> *Flags : Word;*
>> *CheckByte : Byte;*
>> *  end;*
>>
>> So on 32 bit systems, SizeOf(TMyBinaryHeader) will report 15 bytes. How
>> do I accomplish this on 64 bit platform and avoiding
>> "myprotocollib.pas(x,y) Error: Typecast has different size (4 -> 8) in
>> assignment" without having to port to ugly byte copy operations.
>>
>
> Would you show the code at/around the error location, please? I suspect
> that it isn't the record that's the problem, but how you use it.
>
> Regards,
> Sven
>
>> ___
> fpc-devel maillist  -  fpc-devel@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Pointer arithmetic:
*for Indx := 0 to SizeOf(TTCPPackageHeader) - 1 do
Dec(Byte(Pointer(Cardinal(@x) + Indx)^), ARollCount);*
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Packed record integers and x86_86

2019-03-27 Thread DJ Coertzen 
On Wed, Mar 27, 2019 at 7:48 PM Christo Crause 
wrote:

>
>
> On Wed, 27 Mar 2019, 19:27 DJ Coertzen, 
> wrote:
>
>> Hi there,
>>
>> I need a solution for a packed record containing 4-byte 32-bit integers
>> and cardinals, and other byte 8 bit and word 16 bit sized variables to
>> overlay over a stream.
>>
>> Example:
>> *type*
>> *  TMyBinaryHeader = packed record*
>> *Sender: Cardinal;*
>>
>> *Target: Cardinal;*
>>
>> *Reference : Integer;*
>>
>> *Flags : Word;*
>> *CheckByte : Byte;*
>> *  end;*
>>
>> So on 32 bit systems, SizeOf(TMyBinaryHeader) will report 15 bytes. How
>> do I accomplish this on 64 bit platform and avoiding
>> "myprotocollib.pas(x,y) Error: Typecast has different size (4 -> 8) in
>> assignment" without having to port to ugly byte copy operations.
>>
>
> Perhaps use size explicit types such as uint32 and int32?
> ___
> fpc-devel maillist  -  fpc-devel@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


I discovered UInt32 in the meanwhile . Thanks. I replied on the wrong
response about pointer arithmetic
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Packed record integers and x86_86

2019-03-27 Thread DJ Coertzen 
On Wed, Mar 27, 2019 at 7:48 PM Christo Crause 
wrote:

>
>
> On Wed, 27 Mar 2019, 19:27 DJ Coertzen, 
> wrote:
>
>> Hi there,
>>
>> I need a solution for a packed record containing 4-byte 32-bit integers
>> and cardinals, and other byte 8 bit and word 16 bit sized variables to
>> overlay over a stream.
>>
>> Example:
>> *type*
>> *  TMyBinaryHeader = packed record*
>> *Sender: Cardinal;*
>>
>> *Target: Cardinal;*
>>
>> *Reference : Integer;*
>>
>> *Flags : Word;*
>> *CheckByte : Byte;*
>> *  end;*
>>
>> So on 32 bit systems, SizeOf(TMyBinaryHeader) will report 15 bytes. How
>> do I accomplish this on 64 bit platform and avoiding
>> "myprotocollib.pas(x,y) Error: Typecast has different size (4 -> 8) in
>> assignment" without having to port to ugly byte copy operations.
>>
>
> Perhaps use size explicit types such as uint32 and int32?
> ___
> fpc-devel maillist  -  fpc-devel@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
>

Pointer arithmetic:
*for Indx := 0 to SizeOf(TTCPPackageHeader) - 1 do
Dec(Byte(Pointer(Cardinal(@x) + Indx)^), ARollCount);*
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Packed record integers and x86_86

2019-03-27 Thread Christo Crause 
On Wed, 27 Mar 2019, 19:27 DJ Coertzen,  wrote:

> Hi there,
>
> I need a solution for a packed record containing 4-byte 32-bit integers
> and cardinals, and other byte 8 bit and word 16 bit sized variables to
> overlay over a stream.
>
> Example:
> *type*
> *  TMyBinaryHeader = packed record*
> *Sender: Cardinal;*
>
> *Target: Cardinal;*
>
> *Reference : Integer;*
>
> *Flags : Word;*
> *CheckByte : Byte;*
> *  end;*
>
> So on 32 bit systems, SizeOf(TMyBinaryHeader) will report 15 bytes. How do
> I accomplish this on 64 bit platform and avoiding "myprotocollib.pas(x,y)
> Error: Typecast has different size (4 -> 8) in assignment" without having
> to port to ugly byte copy operations.
>

Perhaps use size explicit types such as uint32 and int32?
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Packed record integers and x86_86

2019-03-27 Thread Sven Barth via fpc-devel 
DJ Coertzen  schrieb am Mi., 27. März 2019,
18:27:

> Hi there,
>
> I need a solution for a packed record containing 4-byte 32-bit integers
> and cardinals, and other byte 8 bit and word 16 bit sized variables to
> overlay over a stream.
>
> Example:
> *type*
> *  TMyBinaryHeader = packed record*
> *Sender: Cardinal;*
>
> *Target: Cardinal;*
>
> *Reference : Integer;*
>
> *Flags : Word;*
> *CheckByte : Byte;*
> *  end;*
>
> So on 32 bit systems, SizeOf(TMyBinaryHeader) will report 15 bytes. How do
> I accomplish this on 64 bit platform and avoiding "myprotocollib.pas(x,y)
> Error: Typecast has different size (4 -> 8) in assignment" without having
> to port to ugly byte copy operations.
>

Would you show the code at/around the error location, please? I suspect
that it isn't the record that's the problem, but how you use it.

Regards,
Sven

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

[fpc-devel] Packed record integers and x86_86

2019-03-27 Thread DJ Coertzen 
Hi there,

I need a solution for a packed record containing 4-byte 32-bit integers and
cardinals, and other byte 8 bit and word 16 bit sized variables to overlay
over a stream.

Example:
*type*
*  TMyBinaryHeader = packed record*
*Sender: Cardinal;*

*Target: Cardinal;*

*Reference : Integer;*

*Flags : Word;*
*CheckByte : Byte;*
*  end;*

So on 32 bit systems, SizeOf(TMyBinaryHeader) will report 15 bytes. How do
I accomplish this on 64 bit platform and avoiding "myprotocollib.pas(x,y)
Error: Typecast has different size (4 -> 8) in assignment" without having
to port to ugly byte copy operations.

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

[fpc-devel] Vectorisation, optimisation etc.

2019-03-27 Thread J. Gareth Moreton 
 Hi everyone,
 So with the false start that was pure inline assembly, I like to talk
about how to move forward with FPC, or at least with x86_64.  To Florian
in particular, what is the current state of the compiler's support of the
256-bit YMM registers? I remember you telling me not to enable support of
them when I was implementing vectorcall, since you were still working on
it.  I ask because if that was my next big optimisation of x86_64, it
would be vectorisation of things like for-loops and making use of FMA
instructions if allowed, for example.
 One thing to note with vectorcall is that it's not just for floating-point
parameters, but it can pass integer-type vectors too.  I'll have to
double-check my code, but it may require a bit of metadata for vectorcall
procedures so it uses the correct move command ((V)MOVAPS = single,
(V)MOVAPD = double, (V)MOVDQA = integer) - using the wrong one invokes a
notable performance penalty.
 For something more cross-platform, I think pure functions are still on the
books, but like with a few things, including some node-level optimisations,
the XML node dump would need merging so I and others can more easily study
the generated nodes for debugging and development purposes.
 By the way, is there any progress about the whole register virtualisation
thing? The part where virtual registers are changed into real ones occurs
before the peephole optimizer, while moving it to after that point will
allow for better register usage, but when I blindly tried it myself I just
got a load of segmentation faults, so it's presumably not that
straightforward, although when programming my prototype Deep Optimizer
(utilises assembly-level data flow analysis), I was able to remove required
registers completely, but because it was after virtual registers were
changed to real ones, said registers were already allocated on the stack.

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

Re: [fpc-devel] Programming in Pascal .

2019-03-27 Thread Paul Breneman 

On 3/27/2019 10:28 AM, Tomas Hajny wrote:

On Wed, March 27, 2019 14:53, Yves Boudeville wrote:



Merci Tomas pour votre sympathique aide sur le Free Pascal.


Pas de quoi / you're welcome. :-)


  .
  .

I absolutely agree with you Tomas, I can do very interesting simulations
1920 x 1080 in using only Windows 10 / 64 bits for Fpc/Ptc and also I am
conviced that Raspberry Rpi3 B+ ( 33.85 Euros) is a fantastic tool to
do cheap scientific models. This is the reason why I am a little

  .
  .

To develop my scientific stuff, I have been helped very kindly by
Nikolay Nikolov who, I hope, shall develop new PtcGraph modes
in FpcPASCAL to reach in light programs the full HDMI capacity 1920 x
1080  x 65536c of the Rpi3 with the latest OS under Raspbian "stretch".

  .
  .

Admittedly, FPC doesn't seem to support the resolution 1920x1080
(hi-colour or true colour) on Unix platforms at the moment. I believe that
Nikolay is subscribed to this list, he might be able to respond himself
whether he sees possibility to extend the list of supported modes there.

Tomas


I am also *very* interested to see if www.Ultibo.org will support PTC!

http://wiki.freepascal.org/ptc

http://wiki.freepascal.org/Textmode_IDE_development

Regards,
Paul
www.ControlPascal.com
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Programming in Pascal .

2019-03-27 Thread Tomas Hajny 
On Wed, March 27, 2019 14:53, Yves Boudeville wrote:


> Merci Tomas pour votre sympathique aide sur le Free Pascal.

Pas de quoi / you're welcome. :-)


 .
 .
> I absolutely agree with you Tomas, I can do very interesting simulations
> 1920 x 1080 in using only Windows 10 / 64 bits for Fpc/Ptc and also I am
> conviced that Raspberry Rpi3 B+ ( 33.85 Euros) is a fantastic tool to
> do cheap scientific models. This is the reason why I am a little
 .
 .
> To develop my scientific stuff, I have been helped very kindly by
> Nikolay Nikolov who, I hope, shall develop new PtcGraph modes
> in FpcPASCAL to reach in light programs the full HDMI capacity 1920 x
> 1080  x 65536c of the Rpi3 with the latest OS under Raspbian "stretch".
 .
 .

Admittedly, FPC doesn't seem to support the resolution 1920x1080
(hi-colour or true colour) on Unix platforms at the moment. I believe that
Nikolay is subscribed to this list, he might be able to respond himself
whether he sees possibility to extend the list of supported modes there.

Tomas


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

Re: [fpc-devel] Programming in Pascal .

2019-03-27 Thread Tomas Hajny 
Hello,

Please note that the original poster isn't subscribed to the list
apparently, you may better include him in Cc: when responding (doing that
myself now).

As far as I can tell, the issue may be more likely related to the
packaging of a particular Linux distribution (Raspbian in this case?) than
FPC itself. Obviously, it should be possible to build either just the
required packages with the FPC version distributed there, or the complete
latest release of FPC there, but that obviously needs some additional
effort. In any case, questions about not having PTC included with Raspbian
might be better sent to the respective maintainer of Raspbian.

Tomas


 Original Message 
Subject: Re: [fpc-devel] Programming in Pascal .
From:"J. Gareth Moreton" 
Date:Wed, March 27, 2019 09:56
To:  "FPC developers' list" 


 Hello there Yves Boudeville,
 That's great to hear that Pascal has served you well with scientific
programming and the like.  I confess unfortunately I'm not familiar with
the units, but I will be happy to see if I can help optimise them in
places, either by writing platform-specific assembly language (with a
Pascal fallback if it's not Intel x86_64), kind of my speciality, or
compiler improvements.
 Are you sure that PtcGraph isn't stil available? I just checked with the
development version and it seems to be present.
 Gareth aka Kit.

 On Tue 26/03/19 08:07 , Yves Boudeville yves.boudevi...@free.fr sent:
 Bonjour.
 I am asking questions on the art of scientific computing from 1966.
 After Algol and Modula,
 the U.C.S.D. Pascal system has been the touchstone of the scientific
 computing. This has
 been devoted by Niklaus Wirth book and applied in Borland TP7 software.
 The only thing
 scientists need is a strongly typed language with pixel access on a
 single graphical windows.
  This is needed, for instance, by Monte-Carlo simulations. We need the
 full power of the
 computer with the pixel definition of the result because the eyes are
 the  best investigators
 for scientific bugs. TP7 with graph was the best tool for that. For less
 mathematical
 approaches, like 3D models it was sufficient to use Borland Delphi-7.
 Now, in 2019, it was
 possible to use FPC compiler with Fp-IDE to make in laboratories good
 simulations of
 scientific equations, very clean in FPC Pascal, with the Graphical tools
 PtcGraph, PtcCrt, etc
 ... It is far more useful than old Seymour Cray Fortran or C// on
 Connection Machines CM1 / CM2
 of Hillis : Theses need M.I.T. gourous in big National Laboratories.
 Some years ago, it was possible with the good job of Nikolay Nikolov on 
 Ptc Pascal Units, to do
 clean-proof use of computer to visualize physics in HDMI 1920 x 1080 x
 65536c under Windows.
 With lesser resolution, a work in Pascal was running without
 adding/changing a word under
 Windows_Intel / Ubuntu_Linux / or Raspbian_Raspberry Rpi3. Now, for
 scientific use, it is not
 possible because  ptcgraph etc... are not included in latest versions,
 for instance of Raspbian.
 So, in order to use software in Physics, we are compelled use old
 versions of OS  2.6.4 Fpc
 systems instead of 3.0.0 on /usr/lib/fpc to use our programs. It is a
 big problem for us because
 we are interested by easy Pascal simulations of physics and we are
 newbie in systems. Will it be
 an hope to have again under Fpc : PtcGraph, PtcCrt, PtcMouse... to do
 good job in physics ?

 Friendly Yours.

 P.S. I beg your pardon for my desesperately rusty English language
 because Classrooms are very

 far from me in time ... ( I am 73 ) .

 --
 +---+
 I Mr ou Mme BOUDEVILLE, Yves I
 I "Le Jardin des Arts", 28, Rue Leon FABRE I
 I 69100, VILLEURBANNE. FRANCE. I
 I Tel Domicile : 04.78.93.67.95 (Repondeur) I
 I Courriel: yves.boudevi...@free.fr [1] I
 +---+

 ---
 L'absence de virus dans ce courrier électronique a été vérifiée par
le logiciel antivirus Avast.
 https://www.avast.com/antivirus [2]

 ___
 fpc-devel maillist - fpc-devel@lists.freepascal.org [3]
 http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[4]">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel



Links:
--
[1] mailto:yves.boudevi...@free.fr
[2] https://www.avast.com/antivirus
[3] mailto:fpc-devel@lists.freepascal.org
[4] 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
<<< text/html; name="untitled-[1.2].html": Unrecognized >>>
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Programming in Pascal .

2019-03-27 Thread J. Gareth Moreton 
 Hello there Yves Boudeville,
 That's great to hear that Pascal has served you well with scientific
programming and the like.  I confess unfortunately I'm not familiar with
the units, but I will be happy to see if I can help optimise them in
places, either by writing platform-specific assembly language (with a
Pascal fallback if it's not Intel x86_64), kind of my speciality, or
compiler improvements.
 Are you sure that PtcGraph isn't stil available? I just checked with the
development version and it seems to be present.
 Gareth aka Kit.

 On Tue 26/03/19 08:07 , Yves Boudeville yves.boudevi...@free.fr sent:
 Bonjour. 
 I am asking questions on the art of scientific computing from 1966. 
 After Algol and Modula, 
 the U.C.S.D. Pascal system has been the touchstone of the scientific 
 computing. This has 
 been devoted by Niklaus Wirth book and applied in Borland TP7 software. 
 The only thing 
 scientists need is a strongly typed language with pixel access on a 
 single graphical windows. 
  This is needed, for instance, by Monte-Carlo simulations. We need the 
 full power of the 
 computer with the pixel definition of the result because the eyes are 
 the  best investigators 
 for scientific bugs. TP7 with graph was the best tool for that. For less 
 mathematical 
 approaches, like 3D models it was sufficient to use Borland Delphi-7. 
 Now, in 2019, it was 
 possible to use FPC compiler with Fp-IDE to make in laboratories good 
 simulations of 
 scientific equations, very clean in FPC Pascal, with the Graphical tools 
 PtcGraph, PtcCrt, etc 
 ... It is far more useful than old Seymour Cray Fortran or C// on 
 Connection Machines CM1 / CM2 
 of Hillis : Theses need M.I.T. gourous in big National Laboratories. 
 Some years ago, it was possible with the good job of Nikolay Nikolov on  
 Ptc Pascal Units, to do 
 clean-proof use of computer to visualize physics in HDMI 1920 x 1080 x 
 65536c under Windows. 
 With lesser resolution, a work in Pascal was running without 
 adding/changing a word under 
 Windows_Intel / Ubuntu_Linux / or Raspbian_Raspberry Rpi3. Now, for 
 scientific use, it is not 
 possible because  ptcgraph etc... are not included in latest versions, 
 for instance of Raspbian. 
 So, in order to use software in Physics, we are compelled use old 
 versions of OS  2.6.4 Fpc 
 systems instead of 3.0.0 on /usr/lib/fpc to use our programs. It is a 
 big problem for us because 
 we are interested by easy Pascal simulations of physics and we are 
 newbie in systems. Will it be 
 an hope to have again under Fpc : PtcGraph, PtcCrt, PtcMouse... to do 
 good job in physics ? 

 Friendly Yours. 

 P.S. I beg your pardon for my desesperately rusty English language 
 because Classrooms are very 

 far from me in time ... ( I am 73 ) . 

 -- 
 +---+ 
 I Mr ou Mme BOUDEVILLE, Yves I 
 I "Le Jardin des Arts", 28, Rue Leon FABRE I 
 I 69100, VILLEURBANNE. FRANCE. I 
 I Tel Domicile : 04.78.93.67.95 (Repondeur) I 
 I Courriel: yves.boudevi...@free.fr [1] I 
 +---+ 

 --- 
 L'absence de virus dans ce courrier électronique a été vérifiée par
le logiciel antivirus Avast. 
 https://www.avast.com/antivirus [2] 

 ___ 
 fpc-devel maillist - fpc-devel@lists.freepascal.org [3] 
 http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[4]">http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel 

 

Links:
--
[1] mailto:yves.boudevi...@free.fr
[2] https://www.avast.com/antivirus
[3] mailto:fpc-devel@lists.freepascal.org
[4] 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] Programming in Pascal .

2019-03-27 Thread Yves Boudeville 

Bonjour.
I am asking questions on the art of scientific computing from 1966. 
After Algol and Modula,
the U.C.S.D. Pascal system has been the touchstone of the scientific 
computing. This has
been devoted by Niklaus Wirth book and applied in Borland TP7 software. 
The only thing
scientists need is a strongly typed language with pixel access on a 
single graphical windows.
 This is needed, for instance, by Monte-Carlo simulations. We need the 
full power of the
computer with the pixel definition of the result because the eyes are 
the  best investigators
for scientific bugs. TP7 with graph was the best tool for that. For less 
mathematical
approaches, like 3D models it was sufficient to use Borland Delphi-7. 
Now, in 2019, it was
possible to use FPC compiler with Fp-IDE to make in laboratories good 
simulations of
scientific equations, very clean in FPC Pascal, with the Graphical tools 
PtcGraph, PtcCrt, etc
... It is far more useful than old Seymour Cray Fortran or C// on 
Connection Machines CM1 / CM2

of Hillis : Theses need M.I.T. gourous in big National Laboratories.
Some years ago, it was possible with the good job of Nikolay Nikolov on  
Ptc Pascal Units, to do
clean-proof use of computer to visualize physics in HDMI 1920 x 1080 x 
65536c under Windows.
With lesser resolution, a work in Pascal was running without 
adding/changing a word under
Windows_Intel / Ubuntu_Linux / or Raspbian_Raspberry Rpi3. Now, for 
scientific use, it is not
possible because  ptcgraph etc... are not included in latest versions, 
for instance of Raspbian.
So, in order to use software in Physics, we are compelled use old 
versions of OS  2.6.4 Fpc
systems instead of 3.0.0 on /usr/lib/fpc to use our programs. It is a 
big problem for us because
we are interested by easy Pascal simulations of physics and we are 
newbie in systems. Will it be
an hope to have again under Fpc : PtcGraph, PtcCrt, PtcMouse... to do 
good job in physics ?


Friendly Yours.

P.S. I beg your pardon for my desesperately rusty English language 
because Classrooms are very


far from me in time ... ( I am 73 ) .

--
+---+
I Mr ou Mme BOUDEVILLE, Yves & Nicole ; I
I "Le Jardin des Arts", 28, Rue Leon FABRE  I
I 69100, VILLEURBANNE. FRANCE.  I
I Tel Domicile : 04.78.93.67.95 (Repondeur) I
I Courriel: yves.boudevi...@free.fr I
+---+


---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus

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