Serguei TARASSOV wrote on Thu, 03 Mar 2016:
If I understood correctly, the FPC programmer in 2016 always should include
{$MODE DELPHI} or {$MODE ObjFPC} to avoid TurboPascal legacy that I use in
earlies 1990?
FPC mode started in those same early 1990s. The first code that was
written for this mode dates from that period as well.
Ok, it's not so important, only a rhetorical question.
On the contrary, it is fundamental. Changing defaults in existing
language modes, or changing the default language mode that is used,
would break existing code with as only reason that we wouldn't want to
look bad when people use the compiler for the first time and don't
realise what the default mode is/entails. We're not about projecting a
particular image, we're about trying not to break things that already
work as far as the language is concerned.
Look at how Inprise/CodeGear/... alienated many developers by (a.o.)
breaking backwards compatibility all the time and pushing what was
supposed to be the next greatest thing instead. It's just not fair to
existing users, who mainly don't want their code to break (just like
you with the with/property problem earlier on). Any improvements on
top of that is gravy, but it's not the most important.
So the default FPC mode seems to be significantly more slow than Delphi-mode
and ObjFPC-mode.
It's unrelated to the compiler mode. However, performing 16 bit
integer arithmetical instructions on a processor that is very
inefficient at doing so (such as 32 and 64 bit Intel x86 processors
running in 32 or 64 bit mode -- I don't know about AMD) can indeed be
quite slow. Ideally, the compiler would internally "upgrade" those
operations to 32/64 bit where possible, but it doesn't do so. The
amount of 16 bit integer code that should run as fast as possible on
32/64 bit x86 Intel processors is probably not that big either.
Jonas
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
