Am 24.01.2016 um 00:00 schrieb Simon Ameis:
> Would it be possible to issue a hint why a procedure can't be inlined at
> a specific call?
> This could change with the compiler and the user knows what to change
> for inlining.
The compiler tries to do this as debug info (-vd), see also
fpc/compile
Would it be possible to issue a hint why a procedure can't be inlined at
a specific call?
This could change with the compiler and the user knows what to change
for inlining.
Where do I find documentation/examples on how to define a compiler
intrinsic procedure?
Am 23.01.2016 um 11:53 schrieb Flor
Am 23.01.2016 um 14:17 schrieb Marc Santhoff:
> On Sa, 2016-01-23 at 11:53 +0100, Florian Klaempfl wrote:
>
>> IMO the only proper solution is to implement delaying as compiler
>> intrinsics as it is done by gcc as well.
>
> Besides using a hardware timer on embedded platforms. Older µC like AVR
On Sa, 2016-01-23 at 11:53 +0100, Florian Klaempfl wrote:
> IMO the only proper solution is to implement delaying as compiler
> intrinsics as it is done by gcc as well.
Besides using a hardware timer on embedded platforms. Older µC like AVR
do not have too much hardware timers, but modern ones no
Am 18.01.2016 um 23:04 schrieb Simon Ameis:
> Thanks for the hint! I've had declared delay_loop_1 and delay_loop_2
> just inside the implementation section.
>
> Maybe these points should be added to documentation for inlining?
I am against documenting this:
- inline is only a hint to the compiler
Thanks for the hint! I've had declared delay_loop_1 and delay_loop_2
just inside the implementation section.
Maybe these points should be added to documentation for inlining?
- assembler procecedure currently can't be inlined (may change)
- all procedures called by the procedure and all types used
On 01/17/2016 11:15 PM, Florian Klämpfl wrote:
Am 17.01.2016 um 22:01 schrieb Simon Ameis:
I've now come up with the code below.
The main problem is, that FPC doesn't inline the procedure _delay_ms.
Thus the calculation of the required ticks is done at runtime wich
timing is merely unpredicta
Am 17.01.2016 um 22:01 schrieb Simon Ameis:
> I've now come up with the code below.
>
> The main problem is, that FPC doesn't inline the procedure _delay_ms.
> Thus the calculation of the required ticks is done at runtime wich
> timing is merely unpredictable.
>
> What must be done to get this pr
I've now come up with the code below.
The main problem is, that FPC doesn't inline the procedure _delay_ms.
Thus the calculation of the required ticks is done at runtime wich
timing is merely unpredictable.
What must be done to get this procedure inlined?
The documentation isn't very extensive o
On Sa, 2016-01-16 at 01:26 +0100, Simon Ameis wrote:
> Am 14.01.2016 um 23:57 schrieb Marc Santhoff:
> > On Do, 2016-01-14 at 21:33 +0100, Simon Ameis wrote:
> >> In general I already know these documents; what I'm looking for is an
> >> implementation of a busy wait, not how to use it.
> >> For C/
Am 15.01.2016 um 10:38 schrieb Michael Schnell:
> The Linux sleep system call provides a microsecond "busy" wait ,but
> only when used with root privilege .
Nice to know, but I asked for an AVR implementation.
Although I've seen a report describing an ARM emulation on AVR running
Linux I don't thin
Am 14.01.2016 um 23:57 schrieb Marc Santhoff:
> On Do, 2016-01-14 at 21:33 +0100, Simon Ameis wrote:
>> In general I already know these documents; what I'm looking for is an
>> implementation of a busy wait, not how to use it.
>> For C/C++ it's easy to get the code files. But I don't know where to
Am 15.01.2016 18:10 schrieb "Michael Schnell" :
>
> On 01/15/2016 07:48 AM, Christo Crause wrote:
>>
>>
>> The focus of the code is to get accurate delays down to a few cpu cycles.
>>
> This is impossible when running in any normal OS.(Of course you can run
an fpc project "bare bone" without an OS)
On Fr, 2016-01-15 at 12:55 +0100, Michael Schnell wrote:
> On 01/15/2016 07:48 AM, Christo Crause wrote:
> >
> > The focus of the code is to get accurate delays down to a few cpu cycles.
> >
> This is impossible when running in any normal OS.(Of course you can run
> an fpc project "bare bone" with
The Linux sleep system call provides a microsecond "busy" wait ,but only
when used with root privilege .
-Michael
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
On 01/15/2016 07:48 AM, Christo Crause wrote:
The focus of the code is to get accurate delays down to a few cpu cycles.
This is impossible when running in any normal OS.(Of course you can run
an fpc project "bare bone" without an OS),
-Michael
___
On Fr, 2016-01-15 at 08:48 +0200, Christo Crause wrote:
> There is a lot of useful information in avr-gcc code, once you can see past
> the peculiarities of C.
I agrre, but normally I don't need such precision. If working in a
millisecond range it's really overkill to use less than 100 nanosecond
There is a lot of useful information in avr-gcc code, once you can see past
the peculiarities of C. See the implementation of avr-gcc's delay here:
cvs.savannah.gnu.org/viewvc/avr-libc/include/util/delay.h and delay_basic.h
in the same folder. Basically they use op codes with fixed cpu cycles to
co
On Do, 2016-01-14 at 21:33 +0100, Simon Ameis wrote:
> In general I already know these documents; what I'm looking for is an
> implementation of a busy wait, not how to use it.
> For C/C++ it's easy to get the code files. But I don't know where to get
> compiler built-in procedures for gcc or other
In general I already know these documents; what I'm looking for is an
implementation of a busy wait, not how to use it.
For C/C++ it's easy to get the code files. But I don't know where to get
compiler built-in procedures for gcc or other language's compilers.
The algorithm itself isn't that compl
On Mo, 2016-01-11 at 23:19 +0100, Simon Ameis wrote:
> Hello,
>
> has anyone already written a busy wait procedure for AVR or any other
> embedded processors?
> I'm currently facing issues converting Arduino's calculation of time
> (millisecons/microseconds) to cpu cycles as they rely on compile t
Hello,
has anyone already written a busy wait procedure for AVR or any other
embedded processors?
I'm currently facing issues converting Arduino's calculation of time
(millisecons/microseconds) to cpu cycles as they rely on compile time
elimination of floating point calculation.
Kind regards
Simo
22 matches
Mail list logo
