Am 27.12.2017 00:54 schrieb "Giuliano Colla" <giuliano.co...@fastwebnet.it>:
Il 26/12/2017 18:26, Sven Barth via fpc-devel ha scritto: Am 26.12.2017 13:33 schrieb "Giuliano Colla" <giuliano.co...@fastwebnet.it>: If the idea is not rejected, then a number of refinements (which I'm ready to implement) are required to make the feature generally available: My following remarks are independent of an eventual acceptance of the feature : - All architectures should be supported (now it's only for x86_64 - symcpu.pas). It might be possible to implement this in a platform independent way that might simply need to expand the capabilites of "absolute". The feature in itself is platform independent. The only catch is that in pdecvar.pas (where variable declaration is handled) there's a per platform hook for each symbol type, in order to allow for special handling of some features. For consistency I did follow the same rule, which is used for all the other declarations, disregarding whether they're platform independent or not. As a consequence, for each supported platform you must add in its specific symcpu.pas a type entry: tcpubasedvarsym = class(tbasedvarsym) end; tcpubasedvarsymclass = class of tcpubasedvarsym; and a line of code: cbasedvarsym:=tcpubasedvarsym; As this is tedious, I've only done it for the platform I'm using (x86_64/symcpu.pas). To deploy the feature, the same lines must be added in each platform symcpu.pas unit. There's no more that that. No matter the syntax that might be chosen for this it will likely be sufficient to handle that feature by an absolutevarsym with a boolean flag or something like that. The difference to an ordinary absolute variable appears to be too small to warrant a new sym type. - It should be decided if internal error # which currently keep the same number of the nearby ABSOLUTE internal error should be given new values. Internal errors shall always be unique as they are used to find the error location, even for copy pasted code. What's the rule to avoiding clashes? I gathered sort of YYYYMMDD## is it correct? Correct. Regards, Sven
_______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel