Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic
Am 14.07.2019 um 04:08 schrieb J. Gareth Moreton: Just a thought that I'd chuck in on this... I did wonder how practical it would be to store checksums of all compiled procedures and the like and to look for collisions. When studying how the compiler is built, I noticed a lot of the internal methods, due to conditional defines, would compile into identical code, so merging them would reduce the binary size if the linker is able to strip out procedures that are never called. Granted, I haven't done research on how Free Pascal does Whole Program Optimisation yet, especially as it requiring a separate compilation pass has always put me off. I would have thought that the linker should be able to handle it right there and then because it has all the information it needs. That would be a possible approach to use if the output format does not support combining equal sections. PE/COFF's COMDAT sections do have a flag that says that they need to have equal content (there are also other possibilities). Don't know right now whether ELF does. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Deeper problem with Internal Error 200309201
Am 14.07.2019 um 04:25 schrieb J. Gareth Moreton: On another note, I do think pass_2 (pass_generate_code) could use some refactoring. I don't like how "flowcontrol" is a global variable. Though it's unlikely to happen, such a state variable not being tied to a management object (e.g. current_procinfo) prevents the compiler from being multi-threaded, at least for that pass. There are many other global variables that prevent that as well... That said I welcome work that changes that (though of course it needs to handle exception/finally handlers that are outside of the containing procedure (like is the case for x86_64-win64) as well). Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Deeper problem with Internal Error 200309201
So what's the verdict so far? Do I have your blessing to start work on this? Because of its complexity, I'll do one of my PDF design specs as well. Admittedly my mind is drifting a little bit because I want to see how much optimisation can be done at the node level (e.g. converting "x * 1" to just "x") so as to take some strain off the peephole optimizer, but got to do the framework first. Gareth aka. Kit P.S. Still waiting for further feedback on the x86_64 optimizer overhaul. Granted it's a hard one to evaluate because of its complexity. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic
On 14/07/2019 00:12, Martok wrote:
>
>> In Delphi's type system (and in C, C++, and C#), the valid values for an
>> enum are always all values that fit within its storage size, and that
>> storage size is fixed.
>>
>> In FPC's type system (and in Ada and Java), the valid values for an an
>> enum are only the values between the lowest and the highest declared
>> enum element (in Java it's even more strict, in that when you have
>> "enums with holes", the holes are also invalid), regardless of the
>> storage size. Moreover, this storage size can vary depending on whether
>> or not the item is in bitpacked storage.
>
> Side note: if this was done 100% consistently (and it does make sense!), the
> PACKENUM directive would be completely useless. There is no point in being
> able
> to specify the storage size of an enum when it can be and is ignored at will.
It is not ignored at will. It is only ignored when an enumeration is put
in a bitpacked array/record, i.e., when the programmer explicitly
instructs the compiler to ignore it. In other cases, the requested
storage size is reserved.
However, while storage size and valid values are related (you have to
have enough storage size to store the valid values), the fact that a
particular type can store a particular bitpattern does not mean that
this bitpattern is a valid value for the type. Just take an ansistring:
you can put any bitpattern in it that fits in a PtrSInt, yet most of
them are invalid and will result in undefined behaviour.
The most common cases to specify a storage size would be alignment, and
the ability to add more valid values in the future without having to
change the layout of a data structure.
> C# and C++ do the same with explicitly sized enumerations. Who would I have to
> bribe to get that in FPC?
>
> {$mode objfpc}
> type
> tmyenum : Byte = (ea, eb, ec);
>
> That would solve literally all problems we ever discussed:
It would solve nothing, and rather demonstrates the disconnect that
apparently still exists in this discussion: the ability to bitpack enums
(and hence reduce their storage size) is a mere side effect of the fact
that their valid range only goes from the lowest to the highest declared
value. You could reserve 4KB for an enum with as only valid value
"enumX" and it would not change a thing as far as the valid values or
the compiler behaviour are concerned.
The issue with a modifier or directive that would change the definition
of which values are vali for an enumerations with this modifier/within
this directive, is (besides the inconsistent low/high and range checking
behaviour from Delphi this would require, especially when subranges also
enter the picture) explained in the post I linked near the beginning of
the thread:
https://forum.lazarus.freepascal.org/index.php/topic,45507.msg322059.html#msg322059
Jonas
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic
On 14/07/2019 04:08, J. Gareth Moreton wrote:
> Just a thought that I'd chuck in on this... I did wonder how practical
> it would be to store checksums of all compiled procedures and the like
> and to look for collisions. When studying how the compiler is built, I
> noticed a lot of the internal methods, due to conditional defines, would
> compile into identical code, so merging them would reduce the binary
> size if the linker is able to strip out procedures that are never
> called. Granted, I haven't done research on how Free Pascal does Whole
> Program Optimisation yet, especially as it requiring a separate
> compilation pass has always put me off. I would have thought that the
> linker should be able to handle it right there and then because it has
> all the information it needs.
Optimising linkers that do this exist. However, it's tricky to do it in
a safe way because programs may compare addresses of functions to
determine what to do. If those addresses become equal, program behaviour
can change. E.g.
procedure test1;
begin
end;
procedure test2;
begin
end;
procedure doit(proc: tprocedure);
begin
if proc=@test1 then
writeln('test1')
else
writeln('test2');
end;
begin
doit(@test1);
doit(@test2);
end.
Jonas
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Move operator
On 13/07/2019 15:13, Ryan Joseph wrote: > > >> On Jul 13, 2019, at 8:21 AM, Jonas Maebe wrote: >> >> In which scenarios do you need such a custom "move" operator, rather >> than simply allowing the compiler to just copy the data from one place >> to the other without calling a destructor on the old instance? > > Not sure off the top of my head what would happen if the user simply wasn’t > informed about the operation but it makes me nervous. :) It may be the case > though that inside the move operator the most common thing is just to call > System.Move anyways. Also if the operator isn’t there then there’s no way to > know without a modeswitch or some other syntax that the user wants to calls > system.move instead of the Copy operator. The question then still remains: why would a user want to call a copy operator when the data is just moved from a temp to another place? Having an explicit copy operator when there is no use case for it only requires programmers to write extra code that can contain bugs. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic
Am 14.07.2019 um 14:18 schrieb Jonas Maebe:
>> Side note: if this was done 100% consistently (and it does make sense!), the
>> PACKENUM directive would be completely useless. There is no point in being
>> able
>> to specify the storage size of an enum when it can be and is ignored at will.
>
> In other cases, the requested storage size is reserved.
Oh please, don't troll. I know that you know that "is reserved" and "is used"
are not the same thing.
> The most common cases to specify a storage size would be alignment, and
> the ability to add more valid values in the future without having to
> change the layout of a data structure.
... the only reasonable application of which is some kind of IO or an ABI that
shouldn't change, for which enums must not be used directly in the first place.
> It would solve nothing, and rather demonstrates the disconnect that
> apparently still exists in this discussion: the ability to bitpack enums
> (and hence reduce their storage size) is a mere side effect of the fact
> that their valid range only goes from the lowest to the highest declared
> value. You could reserve 4KB for an enum
No, you couldn't. The largest ordinal type is QWORD.
> The issue with a modifier or directive that would change the definition
> of which values are valid for an enumerations with this modifier/within
> this directive, is (besides the inconsistent low/high and range checking
> behaviour from Delphi this would require,
This is easy, enums already have separate min/max and a basedef. Make the
basedef a type that can hold an orddef, modify calcsavesize and packedbitsize
accordingly, done.
Low/High will continue to provide the named range.
Arrays of such a type should not be allowed (as for enums with jumps right now)
(* although they could be without surprises, Array[tmyenum] would simply be
Array[Byte] *).
On Subranges, that's also simple and obvious. That's the beauty of it, explicit
sizes would be explicit. They are not "inherited":
tmyenum : Byte = (ea, eb, ec);
tsubenum = eb..ec;
//^ basedef=tmyenum, no explicit type, "fpc-style" enum,
// inherited symtable with ordinals $01 and $02
tsubwenum: Word = eb..ec;
//^ basedef=u16inttype, new symtable with ordinals $0001 and $0002
While the first example looks inconsistent, it is the same as what we already
have:
{$PACKENUM 1}
tmyenum = (ea, eb, ec);
{$PACKENUM DEFAULT}
tsubenum = eb..ec;
tsubenum will be 4-bytes, tmyenum is 1 byte, same as with the new syntax.
tsubenum remains assignment compatible to tmyenum.
In contrast tmyenum.eb and tsubwenum.eb are not compatible, as the obviously
cannot be, since they have different _explicit_ sizes. I can't think of a
usecase for the second declaration in the first place, but getting correct
behaviour as a side effect is always a good sign.
> the post I linked near the beginning of
> the thread:
> https://forum.lazarus.freepascal.org/index.php/topic,45507.msg322059.html#msg322059
As I wrote in the last message, those points would be fully addressed by this
proposal. Choosing at declaration time is the only valid solution, all modes
will behave exactly the same once the type is defined.
Best,
Martok
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Move operator
> On Jul 14, 2019, at 8:55 AM, Jonas Maebe wrote: > > The question then still remains: why would a user want to call a copy > operator when the data is just moved from a temp to another place? > Having an explicit copy operator when there is no use case for it only > requires programmers to write extra code that can contain bugs. Your point is well taken but I really don’t have any better answer than it doesn’t feel balanced with the copy operator in that same level of control to the user. Using the management operators it feels like your opting into having the compiler tell you when it’s performing certain operations on the record so it feels wrong that the move operation is happening without telling you. Just my feelings though. :) Do you have another proposal then? If there’s no move operator then there’s no way to signal that a move is going to override the usual copy operator call which happens every time. I guess the only other viable option would be a modeswitch or some other compiler directive to toggle on/off. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic
On 14/07/2019 15:53, Martok wrote:
> Am 14.07.2019 um 14:18 schrieb Jonas Maebe:
>>> Side note: if this was done 100% consistently (and it does make sense!), the
>>> PACKENUM directive would be completely useless. There is no point in being
>>> able
>>> to specify the storage size of an enum when it can be and is ignored at
>>> will.
>>
>> In other cases, the requested storage size is reserved.
>
> Oh please, don't troll.
Please refrain from throwing around insults.
> I know that you know that "is reserved" and "is used"
> are not the same thing.
If you want to nitpick, the compiler will perform 1/2/4 byte writes for
enums of those sizes, so the full reserved data is in fact
used/initialised. Again: the only relevant part in this discussion is
the valid values. The reserved/used/accessed/written/... storage size is
unrelated to that to the extent explained in my previous message.
>> The issue with a modifier or directive that would change the definition
>> of which values are valid for an enumerations with this modifier/within
>> this directive, is (besides the inconsistent low/high and range checking
>> behaviour from Delphi this would require,
> This is easy, enums already have separate min/max and a basedef. Make the
> basedef a type that can hold an orddef, modify calcsavesize and packedbitsize
> accordingly, done.
> Low/High will continue to provide the named range.
This inconsistency would mean that we at least need two versions of
defutils.getrange() in the compiler: one for (some) range checks (using
the named range), and one for other reasoning (which must use the
basedef range). There may be other such places that need modifications.
> Arrays of such a type should not be allowed (as for enums with jumps right
> now)
> (* although they could be without surprises, Array[tmyenum] would simply be
> Array[Byte] *).
The whole point of a directive/modifier would be to get
Delphi-compatible enums, not to add a third variant.
> On Subranges, that's also simple and obvious.
I meant that Delphi's range checking for enums/subranges doesn't make
any sense due to the inconsistency between the "valid" and "declared" range.
E.g., take this Delphi program (tested with Kylix 3; YMMV with modern
Delphi versions, to which I don't have access)
{$z1}
type
tenum = (ea, eb, ec, ed);
tsubenum = eb..ed;
tsubsubenum = ec..ed;
var
enum, enum2: tenum;
subenum: tsubenum;
subsubenum: tsubsubenum;
arr: array[tenum] of byte;
begin
{$r+}
// no problem
enum:=tenum(255);
// no problem
enum2:=enum;
// segmentation fault
arr[enum]:=2;
// range error
subenum:=enum;
// no problem
subenum:=tsubenum(255);
// no problem
enum:=subenum;
// segmentation fault
arr[subenum]:=2;
// range error
subsubenum:=subenum;
// no problem
subsubenum:=tsubsubenum(255);
// no problem (!)
subenum:=subsubenum;
// no problem
enum:=subsubenum;
// segmentation fault
arr[subsubenum]:=2;
end.
This is both 100% inconsistent and 100% logical.
It is logical because according to the (Delphi and FPC) type system
rules tsubsubenum <= tsubenum <= tenum, and hence every tsubsubenum by
definition is a valid subenum and a valid tenum, every tsubenum is a
valid tenum (and every valid t(sub)(sub)enum is a valid
t(sub)(sub)enum). As a result, you don't need any range checks when
converting them in that direction (an array indexation is also a type
conversion to the index type, hence the segmentation fault rather than
range error). However, the other way round does not necessarily hold,
and hence there are range checks when going in the other direction.
On the other hand, you have this whole inconsistency where 255 is both a
valid and an invalid value. So when a range check happens to be
inserted, you get a range check error, and when it isn't, you don't.
The only way to implement consistent range checking in this scenario is
by having range checks for every single enumeration type conversion,
even between the same type. Although then you get the curious situation
where 255 is at the same time both valid and triggering range check
errors all over the place as soon as you dare to use it. Plus you get a
whole bunch of unnecessary range check operations in code unless you add
a separate optimisation pass to remove them.
I completely understand the practical use case of this type of enums,
but from a type/correctness checking point of view it's utter nonsense.
>> the post I linked near the beginning of
>> the thread:
>> https://forum.lazarus.freepascal.org/index.php/topic,45507.msg322059.html#msg322059
>
> As I wrote in the last message, those points would be fully addressed by this
> proposal. Choosing at declaration time is the only valid solution, all modes
> will behave exactly the same once the type is defined.
As described in that post, the issue is that the default FPC units
declare various enumeration types without any specific modifiers. Even
if all default FPC units would be changed to
Re: [fpc-devel] Move operator
On Sun, 14 Jul 2019, Ryan Joseph wrote: On Jul 14, 2019, at 8:55 AM, Jonas Maebe wrote: The question then still remains: why would a user want to call a copy operator when the data is just moved from a temp to another place? Having an explicit copy operator when there is no use case for it only requires programmers to write extra code that can contain bugs. Your point is well taken but I really don’t have any better answer than it doesn’t feel balanced with the copy operator in that same level of control to the user. Using the management operators it feels like your opting into having the compiler tell you when it’s performing certain operations on the record so it feels wrong that the move operation is happening without telling you. Just my feelings though. :) Do you have another proposal then? If there’s no move operator then there’s no way to signal that a move is going to override the usual copy operator call which happens every time. I guess the only other viable option would be a modeswitch or some other compiler directive to toggle on/off. You are assuming here that there is a problem. Has it occurred to you that maybe there is no problem and that a solution is simply not needed? Sounds to me like you're simply needlessly complicating simple things: moving data from one location in memory to another. Michael.___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic
> If you want to nitpick, the compiler will perform 1/2/4 byte writes for
> enums of those sizes, so the full reserved data is in fact
> used/initialised. Again: the only relevant part in this discussion is
> the valid values. The reserved/used/accessed/written/... storage size is
> unrelated to that to the extent explained in my previous message.
That was exactly my point!
The storage size is unrelated to the "used"/"valid" size, therefore there is
little point in being able to set it.
I can tell the compiler "this type is 4 bytes wide", but it will still only ever
consider the lowest byte if that's how many elements there are.
> This inconsistency would mean that we at least need two versions of
> defutils.getrange() in the compiler: one for (some) range checks (using
> the named range), and one for other reasoning (which must use the
> basedef range). There may be other such places that need modifications.
Interestingly, that's not the case, I checked.
There are like 2 major places that need adjustment, everything else already
correctly uses getrange for the type range and min/max for label range. It
almost looks as if most of the compiler was written assuming these two are not
the same.
The JVM class generator is the only real challenge. These days, one could
probably take a look at .Net Core to see how a managed language does this.
>> Arrays of such a type should not be allowed (as for enums with jumps right
>> now)
>> (* although they could be without surprises, Array[tmyenum] would simply be
>> Array[Byte] *).
>
> The whole point of a directive/modifier would be to get
> Delphi-compatible enums, not to add a third variant.
Where do you see a third variant? If you think this is anything but a
"Hejlsberg-Enum", I seriously failed to explain it.
The proposed syntax would be a shorthand for what Delphi does when you write
{$Zn} tenum = (ea,eb,ec,ed);
With n:=sizeof(basetype).
Nothing else, nothing more.
> I meant that Delphi's range checking for enums/subranges doesn't make
> any sense due to the inconsistency between the "valid" and "declared" range.
The thing about $R and Delphi: a) it is purely ancillary and not part of the
type system. A *lot* of stuff is not rangechecked there at all. This has not a
lot to do with the nesting of type ranges.
b) only pred/succ, literal assignment without hard cast and assignment from
larger to smaller type are guaranteed to check if a subrange type is exceeded by
an action. Nothing else does - anything(!!) that fits in the same storage is a
valid value.
Both of that is documented behaviour, and has been for decades.
> E.g., take this Delphi program (tested with Kylix 3; YMMV with modern
> Delphi versions, to which I don't have access)
> [snip]
> This is both 100% inconsistent and 100% logical.
> On the other hand, you have this whole inconsistency where 255 is both a
> valid and an invalid value. So when a range check happens to be
> inserted, you get a range check error, and when it isn't, you don't.
One might argue that it is 100% consistent as well. Compile in {$R-} (remember,
in TP and Delphi it's a debugging aid, not a
thing-you-have-to-do-to-get-somehwat-safe-results like in FPC), and only the out
of bounds array accesses remain. And those are 100% equivalent to our old
friend, the unchecked jumptable access.
> As described in that post, the issue is that the default FPC units
> declare various enumeration types without any specific modifiers. Even
> if all default FPC units would be changed to Delphi-compatible enums,
> then you would still get issues when mixing and matching units declared
> with differently declared enumeration types, since there is no obvious
> way to know how a particular enumeration type has been declared.
Except, you know, looking at the source?
That's like arguing that there is no way to know if a record is packed or not.
Of course there is, it's a keyword right in the declaration.
Or, actually, more like asking what the calling convention of a function could
be. Usually you don't need to know, but when you do, it's either a keyword at
declaration site, or a {$CALLING} setting is in effect. No ambiguity at all.
That's why I say the decision must be clear at declaration point, not for every
access (as was previously suggested).
Best,
Sebastian
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Deeper problem with Internal Error 200309201
Looks like we have a deal then! Break away code from "pass_1" into "pass_semantic". Thanks for your support Florian - I'll start making plans. Gareth aka. Kit On 14/07/2019 19:45, Florian Klämpfl wrote: Am 14.07.2019 um 04:25 schrieb J. Gareth Moreton: So having a long think over the past day, I'm starting to turn against the second idea I had because it would require complex state variable tracking and is just asking for a new bug to be introduced, not to mention that the additional overhead will probably offset any potential speed gains, so the cleaner, simple solution sounds far more appealing now. Also, when it comes to dead nodes (an except section that gets removed or any code following "Exit" in the same block), there's nothing to stop the compiler from deleting the nodes completely, since semantics have already been checked (and maybe chucking in an extra "unreachable code" warning if needs be), thus pruning the tree and making the process faster for pass_generate_code. I do wonder why 'simplify' is a distinct method though, because a lot of the time one can simply put its code at the end of 'pass_1' and there wouldn't be any difference in functionality (plus what counts as 'pass_1' and what counts as 'simplify' is often left to the programmer's discretion) while nodes that have more complex simplification, like taddnode, could use their own private methods. It might be something for me to experiment with on the side. The idea is to keep passes distinct. It makes maintainace easier. Besides this, Simplify is made to be run multiply times, pass_1 not. So the node parsing overhaul, so far... - pass_semantic Yes. - pass_transform (what was "pass_1") I wouldn't change this in one patch. Step by step ... - simplify (if not merged into the above) - pass_generate_code (I won't touch this for now) On another note, I do think pass_2 (pass_generate_code) could use some refactoring. I don't like how "flowcontrol" is a global variable. Though it's unlikely to happen, such a state variable not being tied to a management object (e.g. current_procinfo) prevents the compiler from being multi-threaded, at least for that pass. Gareth aka. Kit P.S. Anyone got a better name for "pass_transform"? pass_1 was for years, I wouldn't change it for the time being. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Move operator
> On Jul 14, 2019, at 11:58 AM, Michael Van Canneyt > wrote: > > You are assuming here that there is a problem. Has it occurred to you that > maybe there is no problem and that a solution is simply not needed? How is this not a problem? Sorry I don’t follow you. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Deeper problem with Internal Error 200309201
Am 14.07.2019 um 04:25 schrieb J. Gareth Moreton: > So having a long think over the past day, I'm starting to turn against the > second idea I had because it would require > complex state variable tracking and is just asking for a new bug to be > introduced, not to mention that the additional > overhead will probably offset any potential speed gains, so the cleaner, > simple solution sounds far more appealing now. > Also, when it comes to dead nodes (an except section that gets removed or any > code following "Exit" in the same block), > there's nothing to stop the compiler from deleting the nodes completely, > since semantics have already been checked (and > maybe chucking in an extra "unreachable code" warning if needs be), thus > pruning the tree and making the process faster > for pass_generate_code. > > I do wonder why 'simplify' is a distinct method though, because a lot of the > time one can simply put its code at the end > of 'pass_1' and there wouldn't be any difference in functionality (plus what > counts as 'pass_1' and what counts as > 'simplify' is often left to the programmer's discretion) while nodes that > have more complex simplification, like > taddnode, could use their own private methods. It might be something for me > to experiment with on the side. The idea is to keep passes distinct. It makes maintainace easier. Besides this, Simplify is made to be run multiply times, pass_1 not. > > So the node parsing overhaul, so far... > > - pass_semantic Yes. > - pass_transform (what was "pass_1") I wouldn't change this in one patch. Step by step ... > - simplify (if not merged into the above) > - pass_generate_code (I won't touch this for now) > > On another note, I do think pass_2 (pass_generate_code) could use some > refactoring. I don't like how "flowcontrol" is a > global variable. Though it's unlikely to happen, such a state variable not > being tied to a management object (e.g. > current_procinfo) prevents the compiler from being multi-threaded, at least > for that pass. > > Gareth aka. Kit > > P.S. Anyone got a better name for "pass_transform"? pass_1 was for years, I wouldn't change it for the time being. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Move operator
On Sun, 14 Jul 2019, Ryan Joseph wrote: On Jul 14, 2019, at 11:58 AM, Michael Van Canneyt wrote: You are assuming here that there is a problem. Has it occurred to you that maybe there is no problem and that a solution is simply not needed? How is this not a problem? Sorry I don’t follow you. You propose a new operator: a move operator. Maybe there is no need for a move operator ? I have not seen any argument that makes the need for this operator crystal clear. When I read your proposal, my first thought was: "solution looking for a problem." Michael.___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Move operator
> On Jul 14, 2019, at 12:40 PM, Michael Van Canneyt > wrote: > > Maybe there is no need for a move operator ? I have not seen any argument > that makes the need for this operator crystal clear. > > When I read your proposal, my first thought was: "solution looking for a > problem." Look at my bug report for some examples. The problem is if you implement the copy operator it MUST be called for all assignments and this results in double, triple etc… copies of the underlying data even though a simple move would be sufficient. It’s an efficiency thing and it should be improved. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
