Re: [fpc-devel] Standard generic classes

[J. Gareth Moreton]

Still, the theory's there just in case... if the arguments are constant 
(but unknown) and the pure function is called multiple times, then it 
can be optimised to only be called once.


Gareth aka. Kit

On 06/06/2019 01:08, J. Gareth Moreton wrote:


Ah, fair enough.  I didn't think to study the for-loop that closely 
yet since I haven't really found a need to check its code.  Sometimes 
I feel silly blurting out my ideas like this, but at least you stopped 
me from doing a fool's errand.  Thanks.


Gareth aka. Kit

On 05/06/2019 22:38, Sven Barth via fpc-devel wrote:
J. Gareth Moreton > schrieb am Mi., 5. Juni 2019, 18:06:



*for *X := 0 *to *Min(BUFFER_SIZE, DataLeft) *- 1 do*
*begin*
  { Do some work that doesn't modify DataLeft }
*end*;

Say that Min is given the *pure *directive, BUFFER_SIZE is a
*const *and DataLeft is a property or some non-local variable. 
Since no volatile intrinsic is used to safeguard multi-threading
issues, and DataLeft isn't modified by the for-loop, DataLeft can
be promoted to the stack or a register.  Even though its exact
value is not known, DataLeft is determined to be constant within
the confines of the for-loop, hence since both arguments in
"Min(BUFFER_SIZE, DataLeft)" are constants, the result must also
be constant, since it's a pure function, therefore the function
only has to be called once and its result be stored on the stack,
recalled during each iteration of the for-loop.  At least that's
the theory.  Of course, you can just store the result yourself in
a local variable and use that as part of the for-loop, but it's
just a thought where pure functions could be used that doesn't
involve computing their result at compile-time.


With properties or global variables you can't guarantee that DataLeft 
is constant as the for loop might call some routine that more or less 
indirectly might change what DataLeft returns.
That said: the end-expression of a for-loop is specified to be 
evaluated only once anyway (in contrast to C-like languages).


Regards,
Sven


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


 
	Virus-free. www.avast.com 
 



<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

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



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Standard generic classes

[J. Gareth Moreton]

Ah, fair enough.  I didn't think to study the for-loop that closely yet 
since I haven't really found a need to check its code.  Sometimes I feel 
silly blurting out my ideas like this, but at least you stopped me from 
doing a fool's errand.  Thanks.


Gareth aka. Kit

On 05/06/2019 22:38, Sven Barth via fpc-devel wrote:
J. Gareth Moreton > schrieb am Mi., 5. Juni 2019, 18:06:



*for *X := 0 *to *Min(BUFFER_SIZE, DataLeft) *- 1 do*
*begin*
  { Do some work that doesn't modify DataLeft }
*end*;

Say that Min is given the *pure *directive, BUFFER_SIZE is a
*const *and DataLeft is a property or some non-local variable. 
Since no volatile intrinsic is used to safeguard multi-threading
issues, and DataLeft isn't modified by the for-loop, DataLeft can
be promoted to the stack or a register.  Even though its exact
value is not known, DataLeft is determined to be constant within
the confines of the for-loop, hence since both arguments in
"Min(BUFFER_SIZE, DataLeft)" are constants, the result must also
be constant, since it's a pure function, therefore the function
only has to be called once and its result be stored on the stack,
recalled during each iteration of the for-loop.  At least that's
the theory.  Of course, you can just store the result yourself in
a local variable and use that as part of the for-loop, but it's
just a thought where pure functions could be used that doesn't
involve computing their result at compile-time.


With properties or global variables you can't guarantee that DataLeft 
is constant as the for loop might call some routine that more or less 
indirectly might change what DataLeft returns.
That said: the end-expression of a for-loop is specified to be 
evaluated only once anyway (in contrast to C-like languages).


Regards,
Sven


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



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Standard generic classes

[Sven Barth via fpc-devel]

J. Gareth Moreton  schrieb am Mi., 5. Juni 2019,
18:06:

>
> *for *X := 0 *to *Min(BUFFER_SIZE, DataLeft) *- 1 do*
> *begin*
>   { Do some work that doesn't modify DataLeft }
> *end*;
>
> Say that Min is given the *pure *directive, BUFFER_SIZE is a *const *and
> DataLeft is a property or some non-local variable.  Since no volatile
> intrinsic is used to safeguard multi-threading issues, and DataLeft isn't
> modified by the for-loop, DataLeft can be promoted to the stack or a
> register.  Even though its exact value is not known, DataLeft is determined
> to be constant within the confines of the for-loop, hence since both
> arguments in "Min(BUFFER_SIZE, DataLeft)" are constants, the result must
> also be constant, since it's a pure function, therefore the function only
> has to be called once and its result be stored on the stack, recalled
> during each iteration of the for-loop.  At least that's the theory.  Of
> course, you can just store the result yourself in a local variable and use
> that as part of the for-loop, but it's just a thought where pure functions
> could be used that doesn't involve computing their result at compile-time.
>

With properties or global variables you can't guarantee that DataLeft is
constant as the for loop might call some routine that more or less
indirectly might change what DataLeft returns.
That said: the end-expression of a for-loop is specified to be evaluated
only once anyway (in contrast to C-like languages).

Regards,
Sven

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

Re: [fpc-devel] Standard generic classes

[J. Gareth Moreton]

Sounds fun.  I'm currently working on a personal project to put into my 
online Github in order to show off to prospective employers, so it might 
be a while before I get around to that.


On another note, I'm also still waiting on Pierre to approve my XML node 
dump, since he and I have been doing a kind of iterative improvement 
with each patch we make.  It's been about a week now though since he's 
responded.  I do hope that gets implemented soon because using that to 
help implement pure functions will be very useful.  I have thought about 
another place where pure functions in particular have an advantage when 
coupled with a smart compiler - for example:


*for *X := 0 *to *Min(BUFFER_SIZE, DataLeft) *- 1 do*
*begin*
  { Do some work that doesn't modify DataLeft }
*end*;

Say that Min is given the *pure *directive, BUFFER_SIZE is a *const *and 
DataLeft is a property or some non-local variable.  Since no volatile 
intrinsic is used to safeguard multi-threading issues, and DataLeft 
isn't modified by the for-loop, DataLeft can be promoted to the stack or 
a register. Even though its exact value is not known, DataLeft is 
determined to be constant within the confines of the for-loop, hence 
since both arguments in "Min(BUFFER_SIZE, DataLeft)" are constants, the 
result must also be constant, since it's a pure function, therefore the 
function only has to be called once and its result be stored on the 
stack, recalled during each iteration of the for-loop.  At least that's 
the theory.  Of course, you can just store the result yourself in a 
local variable and use that as part of the for-loop, but it's just a 
thought where pure functions could be used that doesn't involve 
computing their result at compile-time.


Gareth aka. Kit


On 05/06/2019 16:11, Sven Barth via fpc-devel wrote:
J. Gareth Moreton > schrieb am Mi., 5. Juni 2019, 14:52:


Sounds fair.  I would be trying for a refactoring approach, in
that the API and outward behaviour is identical to before (i.e. a
black box), but the inner workings are better.  I noticed that one
potential source of improvement is changing the Quicksort
algorithm, used in most of the sorting, for Introsort

You could try to adjust the FGL unit to use the pluggable sorting 
system introduced here: 
https://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revision=41167


It's currently only used for the non generic TList and TFPList.

You could then add a IntroSort implementation.

Regards,
Sven


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



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Standard generic classes

[Sven Barth via fpc-devel]

J. Gareth Moreton  schrieb am Mi., 5. Juni 2019,
14:52:

> Sounds fair.  I would be trying for a refactoring approach, in that the
> API and outward behaviour is identical to before (i.e. a black box), but
> the inner workings are better.  I noticed that one potential source of
> improvement is changing the Quicksort algorithm, used in most of the
> sorting, for Introsort
>
You could try to adjust the FGL unit to use the pluggable sorting system
introduced here:
https://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revision=41167

It's currently only used for the non generic TList and TFPList.

You could then add a IntroSort implementation.

Regards,
Sven

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

Re: [fpc-devel] [fpc-pascal] ENC28J60 Ethernet Controller AVR/ARM Driver

[Jeppe Johansen]

On 6/5/19 8:21 AM, Dimitrios Chr. Ioannidis via fpc-devel wrote:

Hi Jeppe,

Στις 2/6/2019 5:46 μ.μ., ο Jeppe Johansen έγραψε:

On 6/1/19 3:37 PM, Dimitrios Chr. Ioannidis via fpc-pascal wrote:


< snip >

  As I'm not a compiler guy, isthe "volatile" intrinsic supported in 
AVR platform ( I didn't find it in intrinsics unit ) ?


It's supported, but it does not do anything at all. At least not now, 
and I don't think that will change. All global variable or pointer 
accesses are considered volatile to my knowledge.


But volatile in FPC does not guarantee any atomic access. So this 
would need to be by you. If what you need is just atomic access, then 
simple functions like these generate optimal code:


procedure AtomicWnrite(var value: word; new_value: word); inline;
var
  b: Byte;
begin
  b:=avr_save;
  value:=new_value;
  avr_restore(b);
end;

function AtomicRead(var value: word): word; inline;
var
  b: Byte;
begin
  b:=avr_save;
  AtomicRead:=value;
  avr_restore(b);
end;


Can I use those inside an interrupt handler ? What about nested 
interrupts ?


regards,

Yes, avr_save returns the initial state of SREG, and then disables 
interrupts.

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

Re: [fpc-devel] Standard generic classes

[J. Gareth Moreton]

Sounds fair.  I would be trying for a refactoring approach, in that the 
API and outward behaviour is identical to before (i.e. a black box), but 
the inner workings are better.  I noticed that one potential source of 
improvement is changing the Quicksort algorithm, used in most of the 
sorting, for Introsort.


To explain Introsort, it is Quicksort most of the time, but switches to 
Heapsort if the depth level gets degenerate (usually set to "2 log n", 
where n is the list size - this tends to only happen if the list is 
carefully crafted to defeat Quicksort), and switches to Insertion Sort 
when a sublist gets to about 16 entries in size, since while Insertion 
Sort is O(n²), it has much lower overhead than Quicksort at this size 
and is hence faster.  Unlike the implementation in C++'s std::sort, I've 
noticed that it's better to do the insertion sort right there and then 
because the sublist will more likely still be in the cache; doing it as 
an end step like std::sort I found is slower in Object Pascal, possibly 
due to all the cache misses.  I don't know if this is specific to Object 
Pascal though.  Something to make a benchmark for though.


Gareth aka. Kit

P.S. Because Quicksort, Heapsort and Insertion Sort are all comparison 
sort algorithms, Introsort is also a comparison algorithm overall, so it 
is still compatible with classes that have a custom compare routine.



On 05/06/2019 13:33, Michael Van Canneyt wrote:



On Wed, 5 Jun 2019, J. Gareth Moreton wrote:

Still, saying all that, maybe there's room for improvement in 
rtl-generics in the form of refactoring, like I've found in the 
compiler itself in a few places.  When you say 'heavyweight', do you 
mean it's a little slow sometimes or just very bulky when it comes to 
code size? (Taking a brief look at rtl-generics, there are a lot of 
classes!)



rtl-generics is meant to be Delphi compatible, so be careful.
Also, Maciej did his best to make it as fast as possible. I doubt you can
improve his code.

If you want to make improvements, I think fcl-stl and fgl units are 
more amenable to that.


Michael.

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



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Standard generic classes

[Michael Van Canneyt]

On Wed, 5 Jun 2019, J. Gareth Moreton wrote:

Still, saying all that, maybe there's room for improvement in rtl-generics in 
the form of refactoring, like I've found in the compiler itself in a few 
places.  When you say 'heavyweight', do you mean it's a little slow sometimes 
or just very bulky when it comes to code size? (Taking a brief look at 
rtl-generics, there are a lot of classes!)



rtl-generics is meant to be Delphi compatible, so be careful.
Also, Maciej did his best to make it as fast as possible. I doubt you can
improve his code.

If you want to make improvements, I think fcl-stl and fgl units are more 
amenable to that.

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

Re: [fpc-devel] Standard generic classes

[Sven Barth via fpc-devel]

J. Gareth Moreton  schrieb am Mi., 5. Juni 2019,
14:27:

> Still, saying all that, maybe there's room for improvement in rtl-generics
> in the form of refactoring, like I've found in the compiler itself in a few
> places.  When you say 'heavyweight', do you mean it's a little slow
> sometimes or just very bulky when it comes to code size? (Taking a brief
> look at rtl-generics, there are a lot of classes!)
>

The latter. That's the price to pay for the flexibility to work with any
type.

As said the performance is often better than the other collections (see the
comparison site I linked).

Regards,
Sven

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

Re: [fpc-devel] Standard generic classes

[Sven Barth via fpc-devel]

J. Gareth Moreton  schrieb am Mi., 5. Juni 2019,
11:54:

> Hah, oh that sounds fun!
>
> I would develop something more lightweight and efficient, but that would
> just make a 4th poison to choose from.
>

As Ben mentioned there is also LGenerics which is a third party library, so
there already is a fourth poison, so yours would be a fifth :P

Regards,
Sven

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

Re: [fpc-devel] Standard generic classes

[J. Gareth Moreton]

Still, saying all that, maybe there's room for improvement in 
rtl-generics in the form of refactoring, like I've found in the compiler 
itself in a few places.  When you say 'heavyweight', do you mean it's a 
little slow sometimes or just very bulky when it comes to code size? 
(Taking a brief look at rtl-generics, there are a lot of classes!)


Gareth aka. Kit


On 05/06/2019 10:53, J. Gareth Moreton wrote:


Hah, oh that sounds fun!

I would develop something more lightweight and efficient, but that 
would just make a 4th poison to choose from.


Gareth aka. Kit


On 05/06/2019 08:01, Sven Barth via fpc-devel wrote:
J. Gareth Moreton > schrieb am Di., 4. Juni 2019, 22:40:


Hi everyone,

I may be missing the obvious here, but I've noticed that there
are some
notable absences in the Free Generics Library.  While there's a
standard
list and a map and the like, there aren't any of the special
lists like
a stack and a queue and the like.  It proved slightly problematic
while
in a mentoring session with another programmer whom I was
introducing to
Free Pascal, because our sample project required a stack.  The
standard
TStack uses pointers, which is not exactly portable.

If not present, can I request the addition of TFPGStack and
TFPGQueue to
the Free Generics Library? They should be simple descendants of of
TFPGList unless I'm missing something painfully obvious.  Or am I
missing something even more obvious in that they are defined
elsewhere?


Just to add a bit to the other answer: FPC has three generic 
libraries: fgl, fcl-stl and rtl-generics.
fgl is the oldest and also served as a testbed for the generics. It 
cycles together with the compiler and is comparatively lightweight 
(at least to the other two), but has some requirements when using 
records as parameters and the performance isn't as good as that if 
rtl-generics.
fcl-stl had been a contribution by a third party developer for a 
C++-STL-like generics library.
rtl-generics was also contributed by a third party developer for 
Delphi compatibility, is rather performant, but also rather heavy 
weight.


You can also see a speed comparison here: 
http://www.benibela.de/fpc-map-benchmark_en.html


In the end (if you don't need specific functionality like a stack ;) 
), it's a "pick your own poison" problem :P


Regards,
Sven


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


 
	Virus-free. www.avast.com 
 



<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

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



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] [fpc-pascal] ENC28J60 Ethernet Controller AVR/ARM Driver

[Christo Crause]

On Wed, Jun 5, 2019 at 8:21 AM Dimitrios Chr. Ioannidis via fpc-devel <
fpc-devel@lists.freepascal.org> wrote:

>
> Στις 2/6/2019 5:46 μ.μ., ο Jeppe Johansen έγραψε:
> > On 6/1/19 3:37 PM, Dimitrios Chr. Ioannidis via fpc-pascal wrote:
> > procedure AtomicWnrite(var value: word; new_value: word); inline;
> > var
> >   b: Byte;
> > begin
> >   b:=avr_save;
> >   value:=new_value;
> >   avr_restore(b);
> > end;
> >
> > function AtomicRead(var value: word): word; inline;
> > var
> >   b: Byte;
> > begin
> >   b:=avr_save;
> >   AtomicRead:=value;
> >   avr_restore(b);
> > end;
>
> Can I use those inside an interrupt handler ? What about nested interrupts
> ?
>

In my opinion not required for a normal ISR, since the global interrupt
flag is disabled anyway. Obviously if you enable the global interrupt flag
inside an ISR tor nesting interrupts then you would need the above
functions for atomic access to variables.

For new architectures such as tinyAVR1 or megaAVR0 series the interrupt
systems are a bit more involved (not sure how one would ensure atomic
access if a normal ISR is interrupted by a non-maskable interrupt).
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Standard generic classes

[J. Gareth Moreton]

Hah, oh that sounds fun!

I would develop something more lightweight and efficient, but that would 
just make a 4th poison to choose from.


Gareth aka. Kit


On 05/06/2019 08:01, Sven Barth via fpc-devel wrote:
J. Gareth Moreton > schrieb am Di., 4. Juni 2019, 22:40:


Hi everyone,

I may be missing the obvious here, but I've noticed that there are
some
notable absences in the Free Generics Library.  While there's a
standard
list and a map and the like, there aren't any of the special lists
like
a stack and a queue and the like.  It proved slightly problematic
while
in a mentoring session with another programmer whom I was
introducing to
Free Pascal, because our sample project required a stack. The
standard
TStack uses pointers, which is not exactly portable.

If not present, can I request the addition of TFPGStack and
TFPGQueue to
the Free Generics Library? They should be simple descendants of of
TFPGList unless I'm missing something painfully obvious. Or am I
missing something even more obvious in that they are defined
elsewhere?


Just to add a bit to the other answer: FPC has three generic 
libraries: fgl, fcl-stl and rtl-generics.
fgl is the oldest and also served as a testbed for the generics. It 
cycles together with the compiler and is comparatively lightweight (at 
least to the other two), but has some requirements when using records 
as parameters and the performance isn't as good as that if rtl-generics.
fcl-stl had been a contribution by a third party developer for a 
C++-STL-like generics library.
rtl-generics was also contributed by a third party developer for 
Delphi compatibility, is rather performant, but also rather heavy weight.


You can also see a speed comparison here: 
http://www.benibela.de/fpc-map-benchmark_en.html


In the end (if you don't need specific functionality like a stack ;) 
), it's a "pick your own poison" problem :P


Regards,
Sven


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



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Standard generic classes

[Sven Barth via fpc-devel]

J. Gareth Moreton  schrieb am Di., 4. Juni 2019,
22:40:

> Hi everyone,
>
> I may be missing the obvious here, but I've noticed that there are some
> notable absences in the Free Generics Library.  While there's a standard
> list and a map and the like, there aren't any of the special lists like
> a stack and a queue and the like.  It proved slightly problematic while
> in a mentoring session with another programmer whom I was introducing to
> Free Pascal, because our sample project required a stack.  The standard
> TStack uses pointers, which is not exactly portable.
>
> If not present, can I request the addition of TFPGStack and TFPGQueue to
> the Free Generics Library? They should be simple descendants of of
> TFPGList unless I'm missing something painfully obvious.  Or am I
> missing something even more obvious in that they are defined elsewhere?
>

Just to add a bit to the other answer: FPC has three generic libraries:
fgl, fcl-stl and rtl-generics.
fgl is the oldest and also served as a testbed for the generics. It cycles
together with the compiler and is comparatively lightweight (at least to
the other two), but has some requirements when using records as parameters
and the performance isn't as good as that if rtl-generics.
fcl-stl had been a contribution by a third party developer for a
C++-STL-like generics library.
rtl-generics was also contributed by a third party developer for Delphi
compatibility, is rather performant, but also rather heavy weight.

You can also see a speed comparison here:
http://www.benibela.de/fpc-map-benchmark_en.html

In the end (if you don't need specific functionality like a stack ;) ),
it's a "pick your own poison" problem :P

Regards,
Sven

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

Re: [fpc-devel] [fpc-pascal] ENC28J60 Ethernet Controller AVR/ARM Driver

[Dimitrios Chr. Ioannidis via fpc-devel]

Hi Jeppe,

Στις 2/6/2019 5:46 μ.μ., ο Jeppe Johansen έγραψε:

On 6/1/19 3:37 PM, Dimitrios Chr. Ioannidis via fpc-pascal wrote:


< snip >

  As I'm not a compiler guy, isthe "volatile" intrinsic supported in 
AVR platform ( I didn't find it in intrinsics unit ) ?


It's supported, but it does not do anything at all. At least not now, 
and I don't think that will change. All global variable or pointer 
accesses are considered volatile to my knowledge.


But volatile in FPC does not guarantee any atomic access. So this 
would need to be by you. If what you need is just atomic access, then 
simple functions like these generate optimal code:


procedure AtomicWnrite(var value: word; new_value: word); inline;
var
  b: Byte;
begin
  b:=avr_save;
  value:=new_value;
  avr_restore(b);
end;

function AtomicRead(var value: word): word; inline;
var
  b: Byte;
begin
  b:=avr_save;
  AtomicRead:=value;
  avr_restore(b);
end;


Can I use those inside an interrupt handler ? What about nested interrupts ?

regards,

--

Dimitrios Chr. Ioannidis

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