Re: [fpc-pascal] Dynamic array question

[Joost van der Sluis via fpc-pascal]

Vojtěch Čihák via fpc-pascal schreef op wo 11-01-2023 om 23:38 [+0100]:
> is there a way how to have dynamic array "inside" another dynamic
> array?

Not in the way you want.

You could define an 'array of array', though. Or an array of records
that contain an array.
 
> program project1;
> {$mode objfpc}{$H+}
>  
> uses
>   {$IFDEF UNIX}
>   cthreads,
>   {$ENDIF}
>   Classes, SysUtils
>   { you can add units after this };
>  
> {$R *.res}
> type
>   TDynArray = array of Integer;
>   PTDynArray = ^TDynArray;
>  
> var aArray, aNewArray: TDynArray;
>     aNewStart: Integer;
> begin
>   SetLength(aArray, 300);
>   writeln('Length of aArray ', length(aArray));
>   aNewStart:=100;
>   aArray[aNewStart+5]:=42;
>   aNewArray:=@aArray[aNewStart];
>   aNewArray[5]:=42;
>   writeln('Length of aNewArray ', length(aNewArray));
> end.      
>  
> So aNewArray begin at aArray[100] and have length=200 and I could
> write
> NewArray[5]:=42; instead of aArray[aNewStart+5]:=42;
> After all, memory is allocated correctly.
> Code above gives "Invalid pointer operation" while this code
>  
>   aNewArray:=PTDynArray(@aArray[aNewStart])^;
>  
>   aNewArray[5]:=42; 
>  
> gives "Range check error".

The problem is that you make all kind of assumptions about the memory-
layout of these arrays, which may not always be valid. Code that works
this way might work coincidentally, but may break when switching to
another compiler version or by enabling an optimization. 

So.. you must really, really have a good reason why you should try
this.  And if you do so, don't use dynamic types for tricks like this.
They are not meant to be used as a a way to map directly into a memory
location.

And, in your case, one of the assumptions is wrong. At the start of a
dynamic array it's length is stored. That will destroy your memory-
layout.

And te compiler will try to allocate/deallocate memory for the second
array. One big mess.

You could use a static array for the 'inside' array.

Regards,

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

Re: [fpc-pascal] Link on another host - how to collect and copy all files?

[Joost van der Sluis via fpc-pascal]

Op 13-12-2021 om 18:27 schreef Jonas Maebe via fpc-pascal:

On 13/12/2021 18:02, Joost van der Sluis via fpc-pascal wrote:
I've got into troubles with a dynamic library on Linux. It uses 
pthreads but on the target system glibc 2.24 is used, while on my 
development machine 2.34 is being used. I've tried to copy the 
libc-libraries from the target system to my host and uxe -Xr -Xd, but 
it does not work.


You'd mainly need -XR in that case.


I'll try that one as well..

Does someone has a tool of other good trick to copy everything to the 
target machine, and link there?


(I almost started to add a separate option to the compiler to create a 
script do this, but there must be some other way to do this)


There is already an option for this: -st . I don't know how well it 
works though.


I've tried -sT but it didn't do much, except for fixing the path-names 
for the target. But -st does more. Good to know that it is for exactly 
this purpose. I'll see if I can manage to get it to work.


Regards,

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

[fpc-pascal] Link on another host - how to collect and copy all files?

[Joost van der Sluis via fpc-pascal]

Hi all,

I've got into troubles with a dynamic library on Linux. It uses pthreads 
but on the target system glibc 2.24 is used, while on my development 
machine 2.34 is being used. I've tried to copy the libc-libraries from 
the target system to my host and uxe -Xr -Xd, but it does not work.


I guess that it is getting complicated because in the old glibc version 
applications are linked to pthreads, while in this newer version the 
link is made against libc itself.


Now I want to copy all files that are used by the link-script to the 
target, and link there. But.. there are really a lot of files involved. 
(And the paths in ppas.sh and link.res are absolute paths?)


Does someone has a tool of other good trick to copy everything to the 
target machine, and link there?


(I almost started to add a separate option to the compiler to create a 
script do this, but there must be some other way to do this)


Regards,

Joost.

ps: I can also compile on the target, but my goal is to try different 
compiler versions. I can not install those on the target machine.

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

Re: [fpc-pascal] Pascal Ardiono (avr) library

[Joost van der Sluis via fpc-pascal]

Op 04-04-2021 om 15:43 schreef Florian Klämpfl via fpc-pascal:




Am 04.04.2021 um 15:36 schrieb Joost van der Sluis via fpc-pascal 
:



Op 04-04-2021 om 13:33 schreef Florian Klämpfl via fpc-pascal:

Am 04.04.2021 um 12:50 schrieb Joost van der Sluis via fpc-pascal 
:

Isn't it at least a good practice to store self at Y. So we have Z free for 
other calculations and can access members directly using ldd (),y+().

But maybe that's difficult?

Using Y might be indeed difficult as the compiler knows only after register 
allocation that it does not need Y for other purposes. It would basically 
require the ability to redo code generation.


In my head I've been thinking a lot about another register-allocator:

During the code-generation the code-generation only asks the register-allocator 
'I need a register now that cas capabilities X,Y and Z). Or: give me the same 
register as I used last time.

And then, afterwards, once code has been generated for the whole 'block', the 
register-allocator fills in the registers. And store/restores them when needed. 
This can be done using an algorithm that uses a tree to 'peel-down' (is this 
English?) all the solutions. Just like is done with a regular-expression parser.

Just dreaming. I don't have the time to work on it, and I don't even know how 
it works at the moment. But that would seem to be the ideal solution to me.


But this is how it is basically currently done?


But why do you need to redo the code generation? At the moment the real 
registers are assigned, you do know if you need the y register for some 
specific task, no?


Regards,

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

Re: [fpc-pascal] Pascal Ardiono (avr) library

[Joost van der Sluis via fpc-pascal]

Op 04-04-2021 om 13:33 schreef Florian Klämpfl via fpc-pascal:




Am 04.04.2021 um 12:50 schrieb Joost van der Sluis via fpc-pascal 
:

Isn't it at least a good practice to store self at Y. So we have Z free for 
other calculations and can access members directly using ldd (),y+().

But maybe that's difficult?


Using Y might be indeed difficult as the compiler knows only after register 
allocation that it does not need Y for other purposes. It would basically 
require the ability to redo code generation.


In my head I've been thinking a lot about another register-allocator:

During the code-generation the code-generation only asks the 
register-allocator 'I need a register now that cas capabilities X,Y and 
Z). Or: give me the same register as I used last time.


And then, afterwards, once code has been generated for the whole 
'block', the register-allocator fills in the registers. And 
store/restores them when needed. This can be done using an algorithm 
that uses a tree to 'peel-down' (is this English?) all the solutions. 
Just like is done with a regular-expression parser.


Just dreaming. I don't have the time to work on it, and I don't even 
know how it works at the moment. But that would seem to be the ideal 
solution to me.


Regards,

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

Re: [fpc-pascal] Pascal Ardiono (avr) library

[Joost van der Sluis via fpc-pascal]

Op 04-04-2021 om 12:50 schreef Joost van der Sluis via fpc-pascal:
I came across some issues while doing this, but I can not remember all 
of them.


Another one: (Also constant propagation)

-O4, {$WRITEABLECONST OFF}

# [19] a := DigitalPinToBitMask[5];
lds r18,(TC_sARDUINO_ss_DIGITALPINTOBITMASK+5)
# Var a located in register r18
# Register r18 allocated
# Register r18 released
# [20] a := 32;
ldi r18,32

First, the compiler could remove line 19 completely.

Secondly, (TC_sARDUINO_ss_DIGITALPINTOBITMASK+5) is a constant with 
value 32. So why the lds, and not ldi? (ie: line 19 and 20 are exactly 
the same!)


btw: the value of a was not used in this example, so a warning was 
raised. But the compiler could also throw this piece of code away 
altogether


Regards,

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

Re: [fpc-pascal] Pascal Ardiono (avr) library

[Joost van der Sluis via fpc-pascal]

Op 03-04-2021 om 20:42 schreef Florian Klämpfl via fpc-pascal:




Am 03.04.2021 um 19:49 schrieb Joost van der Sluis via fpc-pascal 
:

Hi all,

During some spare free time I've ported parts of the Arduino AVR library to 
Free Pascal. So now it is possible to use things like 'DigitalWrite' and 
'Delay'.

More info here: 
https://lazarussupport.com/introducing-pasduino-the-pascal-avr-arduino-library/


You write that the assembler is far from ideal. Did you notice any problems in 
particular? Because in general it’s not that bad as long as one keeps in mind 
that one is working on a 8 bit systems where e.g. 32 bit integers hurt.


I came across some issues while doing this, but I can not remember all 
of them.


One thing is constant-propagation in combination with auto-inlining. It 
would be really nice when calling PinMode with two constant parameters, 
would only lead to setting the constant value at two memory locations. 
(Between avr_save and avr_restore) Yes, then I have to change the 
parameters to const, and add {$WRITEABLECONST OFF} to the Arduino unit.


I doubt many (if any) compiler will/can do this. But that would be 
ideal. (I think we need the concept Gareth calls 'pure functions' for this)


Another thing is the less-then-ideal use of registers, at least in my 
eyes, but it could be that I miss something.


Take this function:

procedure THardwareSerial.SerialEnd;
begin
  // wait for transmission of outgoing data
  //Flush();

  Fucsrb^ := Fucsrb^ and not (1 shl RXEN0);
  Fucsrb^ := Fucsrb^ and not (1 shl TXEN0);
  Fucsrb^ := Fucsrb^ and not (1 shl RXCIE0);
  Fucsrb^ := Fucsrb^ and not (1 shl UDRIE0);

  // clear any received data
  //FRXBufferHead := FRXBufferTail;
end;

The 4 statements could be converted into 1. But I agree with the 
compiler that this is not done, as reading and writing to a memory 
location this way should be considered 'volatile'.


Leads to this, my comments prefixed with JvdS:

.section .text.n_hardwareserials_sthardwareserial_s__ss_serialend,"ax"
.globl  HARDWARESERIALs_sTHARDWARESERIAL_s__ss_SERIALEND
HARDWARESERIALs_sTHARDWARESERIAL_s__ss_SERIALEND:
# Register r24,r25,r18 allocated
# [224] begin
mov r18,r24
# Register r24 released
# Var $self located in register r18:r25

JvdS: self in r18:r25? Strange combination?

# Register r30 allocated
mov r30,r18
# Register r31 allocated
mov r31,r25

# Now self is in Z.

# Register r19 allocated
ldd r19,Z+18
# Register r20 allocated
ldd r20,Z+19
# Register r31 released
# [228] Fucsrb^ := Fucsrb^ and not (1 shl RXEN0);

JvdS: Here we override Z. After this is points to Fucsrb^

mov r30,r19
# Register r31 allocated
mov r31,r20
# Register r21 allocated
ld  r21,Z
andir21,-17
# Register r19,r20 released
st  Z,r21
# Register r21,r31 released

JvdS: Now we do exactly the same again? This could all be skipped!

mov r30,r18
# Register r31 allocated
mov r31,r25
# Register r19 allocated
ldd r19,Z+18
# Register r20 allocated
ldd r20,Z+19
# Register r31 released
# [229] Fucsrb^ := Fucsrb^ and not (1 shl TXEN0);
mov r30,r19
# Register r31 allocated
mov r31,r20
# Register r21 allocated
ld  r21,Z
andir21,-9
# Register r19,r20 released
st  Z,r21

JvdS: And again.

# Register r21,r31 released
mov r30,r18
# Register r31 allocated
mov r31,r25
# Register r19 allocated
ldd r19,Z+18
# Register r20 allocated
ldd r20,Z+19
# Register r31 released
# [230] Fucsrb^ := Fucsrb^ and not (1 shl RXCIE0);
mov r30,r19
# Register r31 allocated
mov r31,r20

<>

Isn't it at least a good practice to store self at Y. So we have Z free 
for other calculations and can access members directly using ldd (),y+().


But maybe that's difficult?

Regards,

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

Re: [fpc-pascal] Pascal Ardiono (avr) library

[Joost van der Sluis via fpc-pascal]

Op 03-04-2021 om 21:14 schreef Dimitrios Chr. Ioannidis via fpc-pascal:

Στις 3/4/2021 8:49 μ.μ., ο/η Joost van der Sluis via fpc-pascal έγραψε:
During some spare free time I've ported parts of the Arduino AVR 
library to Free Pascal. So now it is possible to use things like 
'DigitalWrite' and 'Delay'.


   BTW, IMHO, porting Arduino wiring code is not the way to go. Their 
libraries are written with an ease of use philosophy and they try to 
optimize them with the use of a lot of linker and preprocessor trickery, 
which are not easy to port.


I would say that it was not that difficult to port. Although I could not 
port all the 'trickery' literally.


And it was my intention to follow the 'ease of use philosophy'. That is 
exactly what was missing at the Freepascal side of Arduino development.


When you are more experienced, you might not need this, and you are 
better of writing to the corresponding addresses, instead of using 
'DigitalWrite'. This is for beginners and simple proof-of-concepts. (The 
developers of the original Arduino software also state this)


   IMHO, if you want to use library or framework I'll recommend to take 
a look to Michael Ring's Microcontroller Board Framework MBF ( 
https://github.com/michael-ring/mbf ). I think that has support for AVR.


Could be a good tip, I didn't know about it's existence.

   One question off topic, can anyone register and use the gitlab scm 
server ( gitlab.freepascal.org ) ? Is it open for Free Pascal / Lazarus 
projects ?


Michael can tell you more. But as I understood it it is more a 
proof-of-concept at the moment. A playground to get more familiar 
hosting git, in preparation of the switch from Subversion to Git for the 
Free Pascal sources.


But at this moment nothing has been decided. Especially if we are gonna 
host fpc on Gitlab itself or host it on our on.


Regards,

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

[fpc-pascal] Pascal Ardiono (avr) library

[Joost van der Sluis via fpc-pascal]

Hi all,

During some spare free time I've ported parts of the Arduino AVR library 
to Free Pascal. So now it is possible to use things like 'DigitalWrite' 
and 'Delay'.


More info here: 
https://lazarussupport.com/introducing-pasduino-the-pascal-avr-arduino-library/


The library itself is at: https://gitlab.freepascal.org/Joost/pasduino

Regards,

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

Re: [fpc-pascal] Lazarus complains that it cannot find a dependency, why?

[Joost van der Sluis via fpc-pascal]

Op 02-09-2020 om 00:21 schreef Bo Berglund via fpc-pascal:

On Tue, 01 Sep 2020 23:55:08 +0200, Tomas Hajny via fpc-pascal
 wrote:


Well, I believe that this supposed mystery may be resolved easily. ;-)
First of all - have you tried to find out what does the displayed error
number (232) mean? Quick searching reveals that runtime error 232 may
signalize that you try to use threads without having a thread manager

Hope this helps



Yes it does!



This is how it looks like in the dpr file:

program SerialTest;

{$mode objfpc}{$H+}

uses
   {$IFDEF UNIX}{$IFDEF UseCThreads}
   cthreads,
   {$ENDIF}{$ENDIF}


It's an old message, but maybe I can shine some light onto the issue. A 
Lazarus package can add a define. So by adding a dependency on the 
LazSerial package, the UseCThreads define is added to your project.


That is why adding a dependency solved the problem. And apperently 
LazSerial also uses the cthreads unit. When that happens, and the unit 
is not also the first used unit, you do not get rhe runtime-error 232, 
but 211.


Regards,

Joost.



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

[fpc-pascal] New package to evaluate Pascal-expressions

[Joost van der Sluis via fpc-pascal]

Hi all,

Working on fpDebug, I've got onto a side-track and created an 
expression-evaluator based on fcl-passrc 
. So that you can 
evaluate Pascal-expressions at runtime.


Regards,

Joost.

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