On 18/10/2020 13:34, J. Gareth Moreton via fpc-devel wrote:
> I've just seen the change you've made Sven (just looking it via diff,
> not actually testing the code)... do the standard Pascal comments
> seriously cause a problem in AArch64 assembly blocks? Do the braces
> have an actual syntactic
On 16/10/2020 10:14, J. Gareth Moreton via fpc-devel wrote:
> Before I go optimising the wrong thing, I have a question to ask.
> What's the policy on platform-specific assembly language in the
> compiler, or any code designed to run on a specific (source) platform
> (and using a more generic
On 07/10/2020 13:02, Marģers . via fpc-devel wrote:
> found total 4300+
> 1001 error number has to be changed to make all error number unique
>
> as there are so huge number of changes to make i have question
> 1) would it be desirable to change all (or most) duplicate error
> numbers in one
On 03/10/2020 18:43, J. Gareth Moreton via fpc-devel wrote:
> Sounds like a fun thing to research, that's for sure. Thanks Jonas.
>
> I'm under the impression that exception code tends to be separated
> anyway, so it can't easily be separated much further.
Implicit exception code, yes, but
On 01/10/2020 18:37, J. Gareth Moreton via fpc-devel wrote:
> On a similar topic, one person mentioned that GCC and other compilers
> sometimes 'outline' conditional branches by effectively moving the
> branch into a nested procedure in order to help with caching.by giving
> the main procedure a
On 19/09/2020 14:11, Ryan Joseph via fpc-devel wrote:
>> On Sep 19, 2020, at 5:43 PM, Jonas Maebe via fpc-devel
>> wrote:
>>
>> It will work if you start your build with FPC 3.2.0 instead of 3.0.4.
> yes, that worked. thanks. 3.0.4 is officially not possible to use f
On 19/09/2020 04:23, Ryan Joseph via fpc-devel wrote:
> I was just going to test the applied patch
> https://bugs.freepascal.org/view.php?id=36909 with revision 46894 and I got
> this error. Any ideas?
It will work if you start your build with FPC 3.2.0 instead of 3.0.4.
Jonas
On 28/08/2020 10:20, Ryan Joseph via fpc-devel wrote:
> Boian just today I made a little patch for a bug in the compiler
> (https://bugs.freepascal.org/view.php?id=37650) and I recorded a short 8 min
> video showing the process. I'm admittedly pretty terrible at making videos
> but it may be
On 26/08/2020 02:57, Boian Mitov via fpc-devel wrote:
> I have been planning for long time to try to add support for advanced
> RTTI to FPC, but never had the chance to work on it.
> I don’t even know how to start. Is there any information on how to setup
> for recompiling the compiler sources and
On 24/08/2020 19:20, Jonas Maebe via fpc-devel wrote:
> It's not paranoid, it is the only correct way to write the code.
* if you don't want to use regular synchronisation primitives, like
mutexes/signals/events/...
Jonas
___
fpc-devel maill
On 24/08/2020 02:11, Martin via fpc-devel wrote:
> Assuming the following
> (and not counting on Interlocked... doing any Barriers itself)
>
> Thread 1
> Foo := val; // normal assign
> WriteBarrier; // make sure above write to Foo is executed, before the
> next write to flag
>
Hi,
The latest FPC trunk can now generate code that targets macOS/AArch64.
The testsuite results are good and Lazarus also works when compiled with
this backend (although I haven't extensively tested it).
Like for other targets, most additional testsuite failures compared to
using the built-in
On 23/08/2020 12:48, J. Gareth Moreton via fpc-devel wrote:
> I've found a pretty big optimisation that benefits most ARM platforms,
> including AArch64, but I'm getting a few random test failures. My
> investigations suggest that functions like "fpc_chararray_to_unicodestr" and
> other string
On 22/08/2020 17:39, Martin Frb via fpc-devel wrote:
> I guess the "Terminate" field is actually about cache coherency.
Yes, but as mentioned earlier it's in general completely useless to
force the overhead of cache coherency for it. By design it's not
something that will be checked immediately
On 22/08/2020 17:39, Martin Frb via fpc-devel wrote:
> Is there some really good article (better than the wikipedia
> https://en.wikipedia.org/wiki/Memory_barrier) on
>
> - memory barrier
> vs
> - cache coherency
> vs
> interlocked
> ?
I think
On 22/08/2020 16:09, Martin via fpc-devel wrote:
> procedure TThread.Terminate;
> begin
> FTerminated := True;
> end;
>
> Should that not in some way deal with memory barriers? E.g.
> InterlockedExchange or similar?
Very important: InterlockedExchange is not a memory barrier, except on x86.
>
On 19/08/2020 20:01, Martin via fpc-devel wrote:
> I just noted (testing with 3.3.1 from 2 or 3days ago) that -gw adds 3
> variables for result
> "result"
> "FUNCTIONNAME"
> "RESULT"
>
> Why an upper, and lowercase result?
"result" is the actual function result parameter.
"FUNCTIONNAME" is an
On 18/08/2020 15:39, Florian Klämpfl via fpc-devel wrote:
> Best is to use an existing backend and ask questions here.
The AArch64 backend should be fairly clean as a starting point.
Jonas
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
On 14/08/2020 11:39, C Western wrote:
> I am not able to compile the current trunk for 32 bits on Mac OS High
> Sierra - some details below. (The 64 bit version compiles and runs
> fine.) Is this a specific issue with my setup, or something more general?
Fixed.
Jonas
101 - 119 of 119 matches
Mail list logo
