Re: [fpc-pascal] FileAge() issue?
Am 16.01.2016 01:43 schrieb "silvioprog" :
>
> On Fri, Jan 15, 2016 at 4:15 AM, Michael Van Canneyt <
mich...@freepascal.org> wrote:
>>
>> On Thu, 14 Jan 2016, silvioprog wrote:
>>>
>>> Hello,
>>>
>>> I'm trying to get the datetime from a file, but it seems that the
FileAge()
>>> function doesn't work properly. See only the second from the results
below:
>>>
>>> FPC: 20/05/2014 10:33:*50*
>>
>>
>> It seems like a rounding difference.
>>
>> home: >ls -l --time-style=+'%Y-%m-%d %H:%M:%S' COPYING.txt -rw-r--r-- 1
michael michael 1579 2014-05-20 10:33:50 COPYING.txt
>
>
> Hm... now I did another test avoiding the formater function:
>
> begin
> WriteLn(FileAge('COPYING.txt'));
> WriteLn('Press [ENTER] to exit ...');
> ReadLn;
> end
>
> I got the same integer result on FPC and Delphi, so the FileAge()
function works fine.
>
>>
>> home: >./testfpc
>> 20-5-14 09:33:50
>> Press [ENTER] to exit ...
>>
>> So the actual timestamp is probably a border case value.
>
>
> You are right, and it seems more related to the datetime formater
function, so I did this change:
>
> FPC/Delphi:
>
> var
> VDt: TDateTime;
> begin
> FileAge('COPYING.txt', VDt);
> WriteLn(FormatDateTime('mm/dd/ hh:nn:ss.zzz', VDt));
> WriteLn('Press [ENTER] to exit ...');
> ReadLn;
> end
>
> FPC (3.1.1 - trunk): 05/20/2014 10:33:50.000
>
> Comparing it with Delphi (using same FPC code) and Node
(console.log(stat.mtime.toISOString()):
>
> Delphi (Seattle): 05/20/2014 10:33:49.646
>
> Node: 2014-05-20T13:33:49.646Z
I have not looked at the code, but from your results I'd say that we round
the value while others truncate them. At least in this context truncate
appears more correct though... (don't know if there is one where rounding
would be more correct)
Regards,
Sven
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Can I compile MASM code/file in FPC?
Am 16.01.2016 04:45 schrieb "silvioprog" : > > Hello, > > Can I compile MASM code (or files) in FPC? If so, how to declare some MASM directives like .code, .data?, .const etc.?: You can't. FPC's assembler readers only support a default syntax (usually that what GNU as supports by default) and on x86 platforms also the Intel syntax. If you want to use MASM you need to assemble it yourself and then $link the resulting file in a unit which also provides access to the functions in the object file using "external". Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Writing floating points to steams
Sven Barth wrote: >>> Should writing binary floating point to a stream note that it's IEEE format, just in case anybody ever tries to process it on a platform that supports alternatives? >>> >> It would be great if storing floating point could be in IEEE, to have a standard as reference. > > > I'm not at all sure about this, but I think I've seen something that suggested that byte ordering in external representations was covered by the standard. I've checked recently due to big endian problems in the Castle game engine and found out that endianess isn't really covered for floating points... Regards, Sven Do you imply that, unlike floating point, endianess for integers are handled automatically by TStream? Dennis ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] AVR Busy Wait implementation
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/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.
> > If you want to write Pascal code and don not need nano seconds accuracy,
> > you have no need to now compiler internals. Only use time values and the
> > divider factors.
> I don't talk of FPC compiler internals but of gcc compiler internals.
> E.g. the C implementation uses a compiler specific procedure
> __builtin_avr_delay_cycles; I can't find a source to get known how it is
> inlined in the resulting assembler code.
> Please see for reference:
> https://gcc.gnu.org/onlinedocs/gcc-4.7.1/gcc/AVR-Built_002din-Functions.html
Well, this is the fpc mailing list ...
How about asking the gcc guys that question?
You could also easily fetch the gcc source code and 'grep' it.
$ cd gcc-src
$ grep -r * "_builtin_avr_delay_cycles"
And if that doesn't help, write a short C code snippet using that
function and then call the compiler like this:
$ arm-gcc -nostdinc -c -S yoursnippet.c
That will leave the asm (.s or .S) file for you to look at.
> >> For point 3 there is a very good explanation in German at
> >> http://www.avr-asm-tutorial.net/avr_de/zeitschleifen/index.html.
> >>
> >> The wicked thing is the calculation of the cpu cycles. The C
> >> implementation uses floating point arithmetics wich is evaluated at
> >> compile time. It doesn't work with wait times which are calculated at
> >> runtime.
> > Why not use calculated constants? The compiler can evaluate simple
> > arithmetics at compile time:
> >
> > const
> > sclk = int(round(SYSTEM_CLOCK / 42));
> >
> > The resulting number will be as close to the float value as possible.
> FPC doesn't support floating point on AVR; thus no floating point
> constants are allowed, even if they can be evaluated to an integer
> expression at compile time. FPC obviously first checks types and then
> does optimization on known types.
>
> Thus only this code is valid on AVR:
> const
> sclk = SYSTEM_CLOCK div 42;
OK, good to know.
> The question isn't how to calculate this but how to fit it into a word
> boundary for function call without loosing required accuracy.
I don't understand. Fitting in a word boundary would be done using a
compiler switch in code, IIRC "{$align 2}" or similar. If that's true
for function implementations isn't clear, I cannot image it is. If you
want to use Assembler code in Pascal there is documentation in the
programmers manual, chapter 3.
--
Marc Santhoff
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Writing floating points to steams
Am 16.01.2016 10:30 schrieb "Dennis" : > > > > Sven Barth wrote: >> >> >>> Should writing binary floating point to a stream note that it's IEEE format, just in case anybody ever tries to process it on a platform that supports alternatives? >> >> >>> >> >> It would be great if storing floating point could be in IEEE, to have a standard as reference. >> > >> > >> > I'm not at all sure about this, but I think I've seen something that suggested that byte ordering in external representations was covered by the standard. >> >> I've checked recently due to big endian problems in the Castle game engine and found out that endianess isn't really covered for floating points... >> >> Regards, >> Sven >> >> > Do you imply that, unlike floating point, endianess for integers are handled automatically by TStream? Not at all, but it could have been that IEEE floating points are defined to be always little endian for example. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Somebody raised another issue on the FPC Github mirror
Hi, If somebody wants to follow up, feel free. https://github.com/graemeg/freepascal/commit/2924efbb06d376af73c271babe4fe3c11702f3a2#commitcomment-15491388 Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
