[fpc-devel] no exceptions from arithmetical operations on AArch64
Looking through the tests that fail on aarch64-linux I found ten that
depend on an arithmetical operation causing an exception, usually
division by zero:
tbs/tb0262
test/texception4
test/units/math/tmask
test/units/math/tmask2
webtbs/tw3157
webtbs/tw3160a
webtbs/tw3160b
webtbs/tw3160c
webtbs/tw3161
webtbs/tw4100
In AArch64 the instruction for integer division never causes an
exception, and floating-point arithmetic can only cause an exception
if an optional part of the architecture is enabled; most hardware
doesn't even have the option. Clearly the compiler could generate code
to check for exceptions but it would be very inefficient when those
exceptions are not required.
I can't find an explicit statement in the documentation but this
example suggests that exceptions from arithmetical operations are not
required by the language definition:
http://www.freepascal.org/docs-html/ref/refse101.html#x212-22200017.1
So, can those tests be disabled on AArch64, by adding
{ %skipcpu=aarch64 }?
Edmund
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linux assembler start-up: rtl/linux/*/*.as
- Would there be four separate Pascal entry points, one for each assembler file? (Each could take arguments: fini, argc, argv, envp.) Presumably various symbols undefined in *prt0.o, defined in the C library, would have to be additional arguments. (Or is there another way of doing it?) Currently these are undefined in gprt0.as on aarch64-linux: U PASCALMAIN U __libc_start_main U __monstartup U _etext U _mcleanup U abort U atexit Edmund ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linux assembler start-up: rtl/linux/*/*.as
In our previous episode, Edmund Grimley Evans said: Is there a good reason why the Linux start-up is implemented with so much assembler code? It is meant to be as close as possible to decompiled assembler code. Or at least that is what I did for *BSD(compile with a not too high optimization that only eliminates redundant loads but keeps it readable) Note that Linux i386 and amd64 have attempts at runtime code in freepascal instead of AS (using inline assembler mostly, but it would allow to spin out pascal) I tried to mimic that in FreeBSD but got stuck on the reliance weak symbols iirc. There are lots of inexplicable differences between the corresponding files for different architectures, and there are also inexplicable differences between cprt0.as and gprt0.as on some architectures, or between prt0.as and dllprt0.as. When implementing aarch64-linux I spent a lot of time wondering which architecture I should take as a model. dllprt and gprt might not be as up to date as the other two. As far as I can tell very little in those files has to be implemented in assembler: perhaps just the initial argument marshalling and initialising the frame pointer. The rest could be done in Pascal, presumably, with the code shared between architectures. It would be a lot easier to maintain that way. It would be harder to diff against a new decompiled code. Some questions to answer if one were going to rewrite that stuff in Pascal: - In which source file would the Pascal code go? - Would there be four separate Pascal entry points, one for each assembler file? (Each could take arguments: fini, argc, argv, envp.) Start studying si_* and their includes in i386/ and x86_64. - How to do the equivalent of C longjmp in Pascal, used in x86_64/gprt0.as, for example? There are fpc_longjmp and fpc_setjmp symbols but they are related to exception handling. In an emergency, simply asm jmp $x end; ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Future of FPCUP tool
On 19.05.2015 09:19, Alfred wrote: I must say its not easy to maintain/understand code without possibility to consult the author. Hello, that reminded me; there is one more forum/list member who worked with Reinier on fpcup, Ludo Brands. I'm not sure for how long have he been involved in the project, but he worked on it at least in the beginning. Perhaps he could provide some insight, if he's available? -- Arny (TurboRascal on the forum) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Linux assembler start-up: rtl/linux/*/*.as
28.05.2015 10:49, Marco van de Voort пишет: In our previous episode, Edmund Grimley Evans said: - How to do the equivalent of C longjmp in Pascal, used in x86_64/gprt0.as, for example? There are fpc_longjmp and fpc_setjmp symbols but they are related to exception handling. In an emergency, simply asm jmp $x end; It is not an emergency case. Libc expects 'main' to return and then executes finalization code. FPC's PASCALMAIN terminates the process and does not return. So in order to get correct library finalization (including profiling with grpof) we have to simulate a return using something like longjmp. It's basically a dirty hack. A much cleaner solution could be to change code generation so it calls FPC_LIB_EXIT instead of FPC_EXIT at the end of PASCALMAIN (so that _haltproc is not called and PASCALMAIN normally returns), and call _haltproc explicitly in code of prt0.as. But whoever goes for that will have to change and test all startup files for all targets, which is pretty time-consuming. Regards, Sergei ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Teensy (no OS) programmed with Free Pascal Embedded ARM
Wow, yesterday I started this new message: http://forum.lazarus.freepascal.org/index.php/topic,28561.0.html And today Laksen says it's committed to SVN trunk. That was fast! Thanks to all the FPC developers! ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
