Re: [fpc-devel] *** GMX Spamverdacht *** An extension of fpc language: the BASED construct
Il 26/12/2017 18:43, Karoly Balogh (Charlie/SGR) ha scritto: As far as I understand (I did not try) this was once supported, but explicitly removed by FPC 2.4.0 from Absolute keyword dereferencing is no longer allowed: http://wiki.freepascal.org/User_Changes_2.4.0#Absolute_variable_declarations As the reasoning there shows, it's a very slippery slope this, which could open a can of worms, so careful people.:) What was allowed before 2.4.0 was *implicit* keyword dereferencing, while explicit dereferencing has never been allowed. This was rather inconsistent, and rightfully suppressed. Giuliano ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] An extension of fpc language: the BASED construct
Il 26/12/2017 18:26, Sven Barth via fpc-devel ha scritto: Am 26.12.2017 13:33 schrieb "Giuliano Colla">: 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. - It should be decided if to make the feature generally available, or conditioned by an {$IFDEF FPCHASBASED} - It should be decided if the feature should be available in all modes or only in a selected number of modes (what of TurboPascal Mode or Delphi Mode?). Rule of thumb: new features added as a separate mode switch, no FPC_HAS_* define necessary as by definition this can be done with version checks (there is only one trunk version, namely the current one). - It should be decided if error messages should be specific for the BASED construct or common to the ABSOLUTE one, slightly rephrasing the error message. Might be one or the other depending on the message. - 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 MMDD## is it correct? Giuliano ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] *** GMX Spamverdacht *** An extension of fpc language: the BASED construct
Il 26/12/2017 18:43, Karoly Balogh (Charlie/SGR) ha scritto: HI, On Tue, 26 Dec 2017, Thorsten Engler wrote: Item: BYTE BASED ItemPtr; Ignoring any other considerations for now, I would have at least used a logical extension derived from already supported syntax: Item: Byte absolute ItemPtr^; As far as I understand (I did not try) this was once supported, but explicitly removed by FPC 2.4.0 from Absolute keyword dereferencing is no longer allowed: http://wiki.freepascal.org/User_Changes_2.4.0#Absolute_variable_declarations As the reasoning there shows, it's a very slippery slope this, which could open a can of worms, so careful people. :) I'd not be in favour of using the same syntax for two quite different beasts. Although the practice implementation is similar, the semantics is completely different: ABSOLUTE declares a variable whose storage is known and assigned at compile time. BASED declares a variable whose storage is unknown, and will only be instantiated at run time. Mixing the two things may cause a lot of troubles, and most likely that's the reason why it was removed from fpc 2.4.0. Giuliano ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] An extension of fpc language: the BASED construct
Il 26/12/2017 14:27, Mark Morgan Lloyd ha scritto: What does gdb (and possibly other debuggers) make of this? What currently gdb tells (and any other debugger would tell) is : No symbol "Item" in current context. Once the appropriate entries are implemented in the debugger symbol table, it will behave like it does in similar conditions, i.e. displaying a value referenced by a pointer. I didn't mention in my ToDo list because I'm a bit lazy, but this too has to be done. Is it really appropriate to declare Item as a variable, when it's really more akin to a macro? It's not different from the declarations: myString: string; myObject: TObject; where your declaration only reserves a pointer, while the actual string or object will be instantiated only at run time. Item is a variable, whose location isn't known at compile time, but will be known only at run time. Giuliano ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] An extension of fpc language: the BASED construct
In that case, if the functionality is going to be included, the best course of action might be to restore pre 2.4.0 behaviour, add the ability to use explicit dereference, and bind it to a separate mode switch. Binding it to a mode switch solves the Delphi compatibility reason for removing it. Allowing both explicit and implicit dereference solves the consistency reason for removing it. And as Sven said, allowing absolute with expressions would be preferable to introducing a new keyword. > -Original Message- > From: fpc-devel [mailto:fpc-devel-boun...@lists.freepascal.org] On > Behalf Of Karoly Balogh (Charlie/SGR) > Sent: Wednesday, 27 December 2017 03:43 > To: FPC developers' list> Subject: Re: [fpc-devel] *** GMX Spamverdacht *** An extension of > fpc language: the BASED construct > > HI, > > On Tue, 26 Dec 2017, Thorsten Engler wrote: > > > > Item: BYTE BASED ItemPtr; > > > > Ignoring any other considerations for now, I would have at least > used > > a logical extension derived from already supported syntax: > > > > Item: Byte absolute ItemPtr^; > > As far as I understand (I did not try) this was once supported, but > explicitly removed by FPC 2.4.0 from Absolute keyword dereferencing > is no longer allowed: > > http://wiki.freepascal.org/User_Changes_2.4.0#Absolute_variable_decl > arations > > As the reasoning there shows, it's a very slippery slope this, which > could open a can of worms, so careful people. :) > > Charlie > ___ > fpc-devel maillist - fpc-devel@lists.freepascal.org > http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] *** GMX Spamverdacht *** An extension of fpc language: the BASED construct
HI, On Tue, 26 Dec 2017, Thorsten Engler wrote: > > Item: BYTE BASED ItemPtr; > > Ignoring any other considerations for now, I would have at least used a > logical extension derived from already supported syntax: > > Item: Byte absolute ItemPtr^; As far as I understand (I did not try) this was once supported, but explicitly removed by FPC 2.4.0 from Absolute keyword dereferencing is no longer allowed: http://wiki.freepascal.org/User_Changes_2.4.0#Absolute_variable_declarations As the reasoning there shows, it's a very slippery slope this, which could open a can of worms, so careful people. :) Charlie ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] An extension of fpc language: the BASED construct
Am 26.12.2017 13:33 schrieb "Giuliano Colla": 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". - It should be decided if to make the feature generally available, or conditioned by an {$IFDEF FPCHASBASED} - It should be decided if the feature should be available in all modes or only in a selected number of modes (what of TurboPascal Mode or Delphi Mode?). Rule of thumb: new features added as a separate mode switch, no FPC_HAS_* define necessary as by definition this can be done with version checks (there is only one trunk version, namely the current one). - It should be decided if error messages should be specific for the BASED construct or common to the ABSOLUTE one, slightly rephrasing the error message. Might be one or the other depending on the message. - 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. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] *** GMX Spamverdacht *** An extension of fpc language: the BASED construct
Am 26.12.2017 14:44 schrieb "Thorsten Engler": > Item: BYTE BASED ItemPtr; Ignoring any other considerations for now, I would have at least used a logical extension derived from already supported syntax: Item: Byte absolute ItemPtr^; I agree, as it avoids adding a new keyword (even if it is context specific). Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] An extension of fpc language: the BASED construct
See: http://tutorial.modernpascal.com/?DataTypes I implemented INTEGER as 32bit, but, if FPC makes it 16bit only, I will go make the change right now. My end-users all know *DO NOT USE INTEGER* it's even in the license agreement. "It is only there for make code compatible w/ Delphi and FPC." I am still spending all my spare time to get MPC's tutorial site up to par with FPC - as I promote MPC as FPC's Script Engine. On Tue, Dec 26, 2017 at 8:50 AM, Ozz Nixonwrote: > I like the concept, I would like to ask that we do not support INTEGER as > a type, and be more specific by limiting to SHORTINT, SMALLINT, LONGINT, > INT64. That way code snippets are not confusing when you implement 16bit > INT logic on a 32bit INT environment. Because I do a lot of documentation > for n00bs in Pascal - the interchangeable INTEGER is probably one of > Borland's biggest mistakes with the grammar! I would love to see FPC make > the statement that the type INTEGER is 16bit only - deal with people > freaking out for a year or two, and move the language forward. Even the > INTEGER example here is assuming 16bit - which would be incorrect on 32bit > platforms in specific $MODE. (may have picked wrong wording, however, I > think everyone see's the point). > > Other than that, if FPC adds this, I will add it to Modern Pascal, so at > least the two products are supporting "BASED". > > On Tue, Dec 26, 2017 at 8:27 AM, Mark Morgan Lloyd < > markmll.fpc-de...@telemetry.co.uk> wrote: > >> On 26/12/17 12:45, Giuliano Colla wrote: >> >> /In short the BASED construct makes the C-style dereferencing operator >>> unnecessary, by moving dereferencing from code to declaration. >>> >>> In fpc this translates into code looking like this, in this trivial >>> example: >>> >>> var >>>I: BYTE; >>>I1: INTEGER; >>>ItemPtr: Pointer; >>>Item: BYTE BASED ItemPtr; >>>IntegerItem: INTEGER BASED ItemPtr; >>> >>>ItemPtr := @I; >>>Item := $41; >>> >>>ItemPtr := @I1; >>>IntegerItem := -32767; >>> >>> This code will load the BYTE value $41 into the variable I, and the >>> INTEGER value -32767 into the variable I1. >>> >> >> What does gdb (and possibly other debuggers) make of this? Is it really >> appropriate to declare Item as a variable, when it's really more akin to a >> macro? >> >> -- >> Mark Morgan Lloyd >> markMLl .AT. telemetry.co .DOT. uk >> >> [Opinions above are the author's, not those of his employers or >> colleagues] >> ___ >> fpc-devel maillist - fpc-devel@lists.freepascal.org >> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel >> > > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] An extension of fpc language: the BASED construct
I like the concept, I would like to ask that we do not support INTEGER as a type, and be more specific by limiting to SHORTINT, SMALLINT, LONGINT, INT64. That way code snippets are not confusing when you implement 16bit INT logic on a 32bit INT environment. Because I do a lot of documentation for n00bs in Pascal - the interchangeable INTEGER is probably one of Borland's biggest mistakes with the grammar! I would love to see FPC make the statement that the type INTEGER is 16bit only - deal with people freaking out for a year or two, and move the language forward. Even the INTEGER example here is assuming 16bit - which would be incorrect on 32bit platforms in specific $MODE. (may have picked wrong wording, however, I think everyone see's the point). Other than that, if FPC adds this, I will add it to Modern Pascal, so at least the two products are supporting "BASED". On Tue, Dec 26, 2017 at 8:27 AM, Mark Morgan Lloyd < markmll.fpc-de...@telemetry.co.uk> wrote: > On 26/12/17 12:45, Giuliano Colla wrote: > > /In short the BASED construct makes the C-style dereferencing operator >> unnecessary, by moving dereferencing from code to declaration. >> >> In fpc this translates into code looking like this, in this trivial >> example: >> >> var >>I: BYTE; >>I1: INTEGER; >>ItemPtr: Pointer; >>Item: BYTE BASED ItemPtr; >>IntegerItem: INTEGER BASED ItemPtr; >> >>ItemPtr := @I; >>Item := $41; >> >>ItemPtr := @I1; >>IntegerItem := -32767; >> >> This code will load the BYTE value $41 into the variable I, and the >> INTEGER value -32767 into the variable I1. >> > > What does gdb (and possibly other debuggers) make of this? Is it really > appropriate to declare Item as a variable, when it's really more akin to a > macro? > > -- > Mark Morgan Lloyd > markMLl .AT. telemetry.co .DOT. uk > > [Opinions above are the author's, not those of his employers or colleagues] > ___ > fpc-devel maillist - fpc-devel@lists.freepascal.org > http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] *** GMX Spamverdacht *** An extension of fpc language: the BASED construct
> Item: BYTE BASED ItemPtr; Ignoring any other considerations for now, I would have at least used a logical extension derived from already supported syntax: Item: Byte absolute ItemPtr^; ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] An extension of fpc language: the BASED construct
On 26/12/17 12:45, Giuliano Colla wrote: /In short the BASED construct makes the C-style dereferencing operator unnecessary, by moving dereferencing from code to declaration. In fpc this translates into code looking like this, in this trivial example: var I: BYTE; I1: INTEGER; ItemPtr: Pointer; Item: BYTE BASED ItemPtr; IntegerItem: INTEGER BASED ItemPtr; ItemPtr := @I; Item := $41; ItemPtr := @I1; IntegerItem := -32767; This code will load the BYTE value $41 into the variable I, and the INTEGER value -32767 into the variable I1. What does gdb (and possibly other debuggers) make of this? Is it really appropriate to declare Item as a variable, when it's really more akin to a macro? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] An extension of fpc language: the BASED construct
Hi fpc developers, here enclosed a patch to the compiler (and ppudump) to support the BASED construct (PL/1 and PL/M style), together with a patch to Lazarus codetools in order to be able to use it with Lazarus IDE. For those unfamiliar with the BASED construct, here's a short description taken from Intel's PL/M-86 manual: Based Variables Sometimes a direct reference to a PL/M-86 data element is either impossible or inconvenient. This happens for example, when the location of a data element must remain unknown until it is computed ad run time. In such cases, it may be necessary to write PL/M-86 code to manipulate the locations of data elements themselves. To permit this type of manipulation PL/M-86 uses "based variables". A based variable is one that is pointed to by another variable called its "base". This means the base contains the address of the desired (based) variable. In short the BASED construct makes the C-style dereferencing operator unnecessary, by moving dereferencing from code to declaration. In fpc this translates into code looking like this, in this trivial example: var I: BYTE; I1: INTEGER; ItemPtr: Pointer; Item: BYTE BASED ItemPtr; IntegerItem: INTEGER BASED ItemPtr; ItemPtr := @I; Item := $41; ItemPtr := @I1; IntegerItem := -32767; This code will load the BYTE value $41 into the variable I, and the INTEGER value -32767 into the variable I1. In more formal terms, the Declaration section of the fpc manual should include a new path: >--Variable modifiers -- based -- pointer --> | | | | | | -- PUint _expression_ ---| | etc.. The main points are: It doesn't break anything. - I have thoroughly tested it in my private fpc versions since fpc 2.2.4 Nobody is forced to use it: whoever doesn't like it can simply ignore its existence. It provides a feature consistent with the general Pascal approach, to avoid whenever possible redundant dereferencing and typecasting, moving the tedious jobs from the developer to the compiler. It saves a number of C-style declarations, dereferencing and typecasting, and it provides a better type checking, making the code less error prone and much more readable and more "Pascalish". It's very useful in message passing techniques, where different message types are funnelled to a single endpoint. Typically such messages are records composed by a fixed header which tells about the message type, followed by a variable content. They can be found everywhere, from IPC to X11 interface to tcp/ip packets. I found it also useful in data entry applications, where different fields require different data types. The implementation is rather trivial: a BASED declaration is nothing else than an ABSOLUTE declaration with an added dereferencing. Therefore I've simply duplicated the code for the ABSOLUTE, with a minimal change in pexpr.pas, and minimal adaptations elsewhere. The enclosed patches are provided just to permit testing, evaluation and scrutiny from fpc maintainers. They only contain what is required for my personal usage. 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: - All architectures should be supported (now it's only for x86_64 - symcpu.pas). - It should be decided if to make the feature generally available, or conditioned by an {$IFDEF FPCHASBASED} - It should be decided if the feature should be available in all modes or only in a selected number of modes (what of TurboPascal Mode or Delphi Mode?). - It should be decided if error messages should be specific for the BASED construct or common to the ABSOLUTE one, slightly rephrasing the error message. - It should be decided if internal error # which currently keep the same number of the nearby ABSOLUTE internal error should be given new values. - Maybe something else which I failed to notice. I'd love to see my favourite programming language enriched by such a feature! Giuliano Index: nld.pas === --- nld.pas (revisione 37753) +++ nld.pas (copia locale) @@ -292,6 +292,8 @@ case symtableentry.typ of absolutevarsym :