Am 01.07.2018 um 20:49 schrieb Jonas Maebe:
> On 01/07/18 20:27, Florian Klaempfl wrote:
>> Am 23.06.2018 um 10:48 schrieb Jonas Maebe:
>>> I doubt this is a major contributor to that fact (especially since
>>> implicit exception frames are disabled for the compiler binary, so
>>> ansistrings don't
On 01/07/18 20:27, Florian Klaempfl wrote:
Am 23.06.2018 um 10:48 schrieb Jonas Maebe:
I doubt this is a major contributor to that fact (especially since
implicit exception frames are disabled for the compiler binary, so
ansistrings don't result in extra exception frames).
I tested on x86_64-l
Am 23.06.2018 um 10:48 schrieb Jonas Maebe:
>> Personally, if I had any stake in this, I would be against it. I mean,
>> FPC is already slower than DCC.
>
> I doubt this is a major contributor to that fact (especially since
> implicit exception frames are disabled for the compiler binary, so
> ans
2018-06-22 20:42 GMT+02:00 Jonas Maebe :
> I would propose to switch all targets to use use ansistrings for symbol
> names.
+1
I was asking for this some time ago in core mailing list... As temporary
solution compiler can be compiled with
OPT="-dsymansistr"
Even without something special like
On Sat, 2018-06-23 at 11:19 +0200, Sven Barth via fpc-devel wrote:
> Am 23.06.2018 um 10:48 schrieb Jonas Maebe:
> >
> > > > I would propose to switch all targets to use use ansistrings
> > > > for
> > > > symbol names.
> > >
> > > Is this the consensus?
> > >
> > > Personally, if I had any sta
On 23/06/18 11:19, Sven Barth via fpc-devel wrote:
But aren't there output formats that do have length restrictions for
symbol names? I take it that ELF and PE/COFF won't be problematic, but
what about those used for OS/2, DOS, etc.?
If needed somewhere, symbol names could be shortened in the
Am 23.06.2018 um 10:48 schrieb Jonas Maebe:
I would propose to switch all targets to use use ansistrings for
symbol names.
Is this the consensus?
Personally, if I had any stake in this, I would be against it. I
mean, FPC is already slower than DCC.
I doubt this is a major contributor to t
On 22/06/18 22:49, bla...@blaise.ru wrote:
On 22.06.2018 21:42, Jonas Maebe wrote:
The rationale for the above is that they need symbols that are longer
than 255 characters.
And such symbols could not be shortened by hashing heads or tails?
The type information must be fully encoded in the
On 22.06.2018 21:42, Jonas Maebe wrote:
The rationale for the above is that they need symbols that are longer than 255
characters.
And such symbols could not be shortened by hashing heads or tails?
The reason the rest uses shortstrings is this is assumed to be faster.
I see that overloade
On 22/06/18 17:19, bla...@blaise.ru wrote:
On 15.06.2018 11:54, Blaise wrote:
Side question: I see that the define "symansistr" is used for JVM and
LLVM. What was the rationale?
Anyone?
The rationale for the above is that they need symbols that are longer
than 255 characters. The reason th
On 15.06.2018 11:54, Blaise wrote:
What is the official maximum symbol length? If it is 255, as the definition "TSymStr
= ShortString" suggests, then FPC does not always take proper care of it.
In particular, TGNUAssembler.WriteTree has plenty of concatenations similar to
this one
writer.
11 matches
Mail list logo
