[fpc-pascal] Trouble integrating examples into fpcdoc

[Noel Duffy via fpc-pascal]

In the fpcdocs subversion project, there are a number of example 
directories each containing one or more small programs and a Makefile. 
My question is, is that Makefile automatically generated, or is it 
hand-crafted?


I'm writing documentation for the netdb module and want to add some 
example programs. I've created the first program and used an example tag 
to reference it within netdb.xml, and this works to show the example 
code in the generated html. But the example program isn't compiled.


Taking the fpcdocs/linuxex example directory, the Makefile references 
the single defined example, ex64.pp, at line 54:


OBJECTS=ex64

This line occurs after this warning:

###
# No need to edit after this line.
###

Which suggests to me that the Makefiles are generated. But if so, how? I 
can't find anything in the Makefile.fpc at the fpcdocs root to reference 
them.


On the other hand, the Makefiles are committed to the repository, which 
does somewhat suggest that they're not generated.



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

Re: [fpc-pascal] Usage of FieldAddress

[Ryan Joseph via fpc-pascal]

> On Apr 4, 2021, at 2:36 PM, Sven Barth via fpc-pascal 
>  wrote:
> 
> The RTTI streaming relies on *published properties* (and published methods 
> for the event handlers).

Sorry Sven, I'm not understand what I'm doing wrong. From original example 
"scale" is a published property right? So FieldAddress only works on published 
fields, which are not supported unless they are classes/interfaces.

type
 TSomething = class(TPersistent)
   private
 m_scale: integer;
   published
 property scale: integer read m_scale write m_scale;
 end;

I have used published properties like this for JSON streaming, i.e.:

type
  TVectorObject = class(TPersistent)
private
  components: array[0..2] of integer;
published
  property x: integer read components[0] write components[0];
  property y: integer read components[1] write components[1];
  property z: integer read components[2] write components[2];
  end;

which works just fine so I assume I can use the RTTI functions, just not 
FieldAddress.

Regards,
Ryan Joseph

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

Re: [fpc-pascal] Usage of FieldAddress

[Sven Barth via fpc-pascal]

Am 04.04.2021 um 22:19 schrieb Ryan Joseph via fpc-pascal:



On Apr 4, 2021, at 1:07 PM, Sven Barth via fpc-pascal 
 wrote:

Only classes or interfaces are supported as published *fields*.

And the visibility of the *property* does not change the visibility of the 
*field*, after all the property could be provided by a method.


I know FPC can deserialize JSON with TJSONDeStreamer so maybe I need to use the 
RTTI functions in TypInfo.pas?
The RTTI streaming relies on *published properties* (and published 
methods for the event handlers).


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

Re: [fpc-pascal] Usage of FieldAddress

[Ryan Joseph via fpc-pascal]

> On Apr 4, 2021, at 1:07 PM, Sven Barth via fpc-pascal 
>  wrote:
> 
> Only classes or interfaces are supported as published *fields*.
> 
> And the visibility of the *property* does not change the visibility of the 
> *field*, after all the property could be provided by a method.
> 

I know FPC can deserialize JSON with TJSONDeStreamer so maybe I need to use the 
RTTI functions in TypInfo.pas? 

Regards,
Ryan Joseph

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

Re: [fpc-pascal] Usage of FieldAddress

[Sven Barth via fpc-pascal]

Am 04.04.2021 um 20:15 schrieb Ryan Joseph via fpc-pascal:



On Apr 4, 2021, at 12:10 PM, Sven Barth via fpc-pascal 
 wrote:

FieldAddress only works on published fields. Just like MethodAddress only works 
on published methods.

For private fields extended RTTI is required which is not yet implemented.

I don't understand this at all I guess. I thought the properties made them published and 
I get a "Symbol cannot be published, can be only a class" if I put the field 
itself in the published section.

Just trying to do this:

PInteger(theClass.FieldAddress('foo'))^ := 10;


Only classes or interfaces are supported as published *fields*.

And the visibility of the *property* does not change the visibility of 
the *field*, after all the property could be provided by a method.


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

Re: [fpc-pascal] Usage of FieldAddress

[Ryan Joseph via fpc-pascal]

> On Apr 4, 2021, at 12:10 PM, Sven Barth via fpc-pascal 
>  wrote:
> 
> FieldAddress only works on published fields. Just like MethodAddress only 
> works on published methods.
> 
> For private fields extended RTTI is required which is not yet implemented.

I don't understand this at all I guess. I thought the properties made them 
published and I get a "Symbol cannot be published, can be only a class" if I 
put the field itself in the published section.

Just trying to do this:

PInteger(theClass.FieldAddress('foo'))^ := 10;

Regards,
Ryan Joseph

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

Re: [fpc-pascal] Usage of FieldAddress

[Sven Barth via fpc-pascal]

Am 04.04.2021 um 19:12 schrieb Ryan Joseph via fpc-pascal:

I'm trying to see fields by name but TObject.FieldAddress doesn't seem to be 
working. Do I have that correct I should be using FieldAddress to return the 
pointer of the published property? Some how I can't seem to find an example of 
FieldAddress on Google

type
   TSomething = class(TPersistent)
 private
   m_scale: integer;
 published
   property scale: integer read m_scale write m_scale;
   end;
FieldAddress only works on published fields. Just like MethodAddress 
only works on published methods.


For private fields extended RTTI is required which is not yet implemented.

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

[fpc-pascal] Usage of FieldAddress

[Ryan Joseph via fpc-pascal]

I'm trying to see fields by name but TObject.FieldAddress doesn't seem to be 
working. Do I have that correct I should be using FieldAddress to return the 
pointer of the published property? Some how I can't seem to find an example of 
FieldAddress on Google

type
  TSomething = class(TPersistent)
private
  m_scale: integer;
published
  property scale: integer read m_scale write m_scale;
  end;


Regards,
Ryan Joseph

___
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

[Florian Klämpfl via fpc-pascal]

>>> 
>>> 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?

Well, thinking about it, maybe yes with some hacky approach. The issue is: only 
after register allocation it is known if temps. for spilling are needed. If any 
local data is used (local vars, temps, temps for spilling etc) then a frame 
pointer is needed, and if spilling temps are needed is only known when register 
allocation is complete.___
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] Formatting Question

[James Richters via fpc-pascal]

  0.5  
  2.53 
 12.5  
 
Thanks!  That’s exactly that I was looking for.  Thank you for sharing your 
code!
 
James
 
___
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

[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?

___
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] Formatting Question

[James Richters via fpc-pascal]

That looks almost perfect.. can I suppress the trailing zeros with the format 
command without losing the alignment? 
 
James  Richters

  www.productionautomation.net 
  ja...@productionautomation.net
  (813)-763-1110
 
From: fpc-pascal  On Behalf Of Jean 
SUZINEAU via fpc-pascal
Sent: Saturday, April 3, 2021 4:41 PM
To: fpc-pascal@lists.freepascal.org
Cc: Jean SUZINEAU 
Subject: Re: [fpc-pascal] Formatting Question
 
Normally something like this should do the trick (here 3 decimals and 7 
characters for total width):
program Format_Example;
uses
sysutils;
procedure F( _d: double);
var
   S: String;
begin
 S:= Format('%7.3f',[_d]);
 WriteLn( S);
end;

begin
 F(0.5);
 F(2.53);
 F(12.5);
end.
-- Output 
  0.500
  2.530
 12.500
 
 
___
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

[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.

But tracking the use of Z is indeed something I would like to implement already 
for a longer time.

___
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

[Jonas Maebe via fpc-pascal]

On 04/04/2021 12:50, Joost van der Sluis via fpc-pascal wrote:
> 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)

No, but you would need to add support to the compiler for keeping a
symbolic representation of typed constants.


Jonas
___
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] Formatting Question

[Jean SUZINEAU via fpc-pascal]

Le 04/04/2021 à 02:41, James Richters a écrit :
That looks almost perfect.. can I suppress the trailing zeros with the 
format command without losing the alignment? 


As far as I know, no ...

Not  with just the RTL.
Anyway I have personal code for this, you can extract and customize it 
to yours needs, it's released under LGPL :


program Format_Example;
uses
    sysutils,uReal_Formatter,uuStrings;
procedure FF( _d: double);
var
   S: String;
begin
 S:= Fixe_MinE( Format_Float(_d, True, 3), 7);
 WriteLn( S);
end;

begin
 FF(0.5);
 FF(2.53);
 FF(12.5);
end.

--- Output -

  0.5
  2.53
 12.5

You can find  the used units there:

https://github.com/jsuzineau/pascal_o_r_mapping/blob/TjsDataContexte/pascal_o_r_mapping/02_Units/uReal_Formatter.pas

https://github.com/jsuzineau/pascal_o_r_mapping/blob/TjsDataContexte/pascal_o_r_mapping/02_Units/uuStrings.pas 
(just extract functions  Fixe_MinE / Fixe_Min0 or you will have to use a 
bunch of other units from the same directory 
https://github.com/jsuzineau/pascal_o_r_mapping/blob/TjsDataContexte/pascal_o_r_mapping/02_Units/)


https://github.com/jsuzineau/pascal_o_r_mapping/blob/TjsDataContexte/pascal_o_r_mapping/02_Units/u_sys_.pas

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