Re: [fpc-devel] AVR assembler code consistency checking
Am 22.01.2018 um 21:35 schrieb Christo: > On Sat, 2018-01-06 at 16:03 +0100, Florian Klämpfl wrote: >> Am 05.01.2018 um 11:24 schrieb Christo: >>> >>> On Wed, 2018-01-03 at 18:10 +0100, Florian Klämpfl wrote: Am 03.01.2018 um 15:48 schrieb Christo: > Is there a better location in the compiler to implement some assembler > consistency > checks? fpc/compiler/avr/raavar.pas:TAVRInstruction.ConcatInstruction > > Attached please find a patch for implementing some assembler validity checks > for review. I'm > sure I've missed some tricks to optimize and reduce the code, but at least I > would appreciate a > check to see whether the logic of the different checks is sound. Particularly > the bit that > checks whether address registers are used correctly. To me it looks good. I propose to commit if it breaks no existing code, time will tell if the checks are ok :) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Data alignment feature
Am 19.01.2018 um 21:08 schrieb J. Gareth Moreton: > Hi everyone, > > So unless anyone has any objections, I would like to start experimenting to > implement a feature that allows > for per-type data alignment. The main purpose for this is to better support > x86-64 SIMD extensions, where > aligned data is far faster to process. While there is a compiler directive > that enforces byte alignment, > this risks causing conflicts with third party units and is a bit much of a > demand for a programmer wishing > to use an SIMD-tuned unit, say. > > Bug/feature details: https://bugs.freepascal.org/view.php?id=32780 > > The format would be as follows: > > type TypeName = TypeInfo [align ByteAmount]; > > The syntax for declaring a type is exactly the same, with a new optional > "align" keyword before the > terminating semicolon. "ByteAmount" has to be a power of 2, which I will > probably limit to 128 currently, > just so it doesn't cause ridiculous or malicious memory usage. There will > probably have to be a minimum > alignment as well, although this will probably just be automatically enforced > (e.g. Single is always aligned > on a 4-byte boundary minimum). > > The intention here is that this feature will be a stepping stone for properly > supporting vectorisation, > implementing some form of the "M128" and "M256" types, and the "vectorcall" > compiler directive for Windows. In r38020 I committed a fix and an example tm128 how these records (m128/m256) can be implemented properly without any additional suffix. Please give it a try. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] AVR assembler code consistency checking
On Sat, 2018-01-06 at 16:03 +0100, Florian Klämpfl wrote: > Am 05.01.2018 um 11:24 schrieb Christo: > > > > On Wed, 2018-01-03 at 18:10 +0100, Florian Klämpfl wrote: > > > > > > Am 03.01.2018 um 15:48 schrieb Christo: > > > > Is there a better location in the compiler to implement some assembler > > > > consistency > > > > checks? > > > > > > fpc/compiler/avr/raavar.pas:TAVRInstruction.ConcatInstruction Attached please find a patch for implementing some assembler validity checks for review. I'm sure I've missed some tricks to optimize and reduce the code, but at least I would appreciate a check to see whether the logic of the different checks is sound. Particularly the bit that checks whether address registers are used correctly.Index: compiler/avr/raavr.pas === --- compiler/avr/raavr.pas (revision 37977) +++ compiler/avr/raavr.pas (working copy) @@ -28,7 +28,8 @@ uses cpubase, aasmtai,aasmdata, - rautils; + rautils, + globtype; type TAVROperand=class(TOperand) @@ -38,15 +39,343 @@ function ConcatInstruction(p:TAsmList) : tai;override; end; + TRegType = (rt_all, rt_even, rt_16_31, rt_even_24_30, rt_16_23, rt_XYZ, rt_YZ, rt_X, rt_Y, rt_Z); + + // To handle different op types for same instruction, e.g. LPM Z or Z+ + // where the parser assings op_reg to the first version and op_ref to the second + +// TRefOpType = (rot_none, rot_predec, rot_postinc); + // A generic record of operand constraints + TAVROpConstraint = record +case typ : toptype of + top_none : (); + top_reg: (rt: TRegType; am: set of taddressmode; minconst, maxconst: tcgint); + top_ref, + top_const : (max, min: tcgint); + end; + + // Constraints of operands per opcode + // Encode variable number of operands by bit position, e.g. + // 2 operands = 1 shl 2 = 4 + // 1 or 2 operands = 1 shl 1 + 1 shl 2 = 6 + + TAVRInstrConstraint = record +numOperands: byte; +Operands: array[0..max_operands-1] of TAVROpConstraint; + end; + + const +AVRInstrConstraint: array[TAsmOp] of TAVRInstrConstraint = + // A_NONE + ((numOperands: 0; Operands: ((typ: top_none), (typ: top_none), (typ: top_none), (typ: top_none))), + // A_ADD + (numOperands: (1 shl 2); Operands: ((typ: top_reg; rt: rt_all), (typ: top_reg; rt: rt_all), (typ: top_none), (typ: top_none))), + // A_ADC + (numOperands: (1 shl 2); Operands: ((typ: top_reg; rt: rt_all), (typ: top_reg; rt: rt_all), (typ: top_none), (typ: top_none))), + // A_ADIW + (numOperands: (1 shl 2); Operands: ((typ: top_reg; rt: rt_even_24_30), (typ: top_const; max: 63; min: 0), (typ: top_none), (typ: top_none))), + // A_SUB + (numOperands: (1 shl 2); Operands: ((typ: top_reg; rt: rt_all), (typ: top_reg; rt: rt_all), (typ: top_none), (typ: top_none))), + // A_SUBI + (numOperands: (1 shl 2); Operands: ((typ: top_reg; rt: rt_16_31), (typ: top_const; max: 255; min: 0), (typ: top_none), (typ: top_none))), + // A_SBC + (numOperands: (1 shl 2); Operands: ((typ: top_reg; rt: rt_all), (typ: top_reg; rt: rt_all), (typ: top_none), (typ: top_none))), + // A_SBCI + (numOperands: (1 shl 2); Operands: ((typ: top_reg; rt: rt_16_31), (typ: top_const; max: 255; min: 0), (typ: top_none), (typ: top_none))), + // A_SBRC + (numOperands: (1 shl 2); Operands: ((typ: top_reg; rt: rt_all), (typ: top_const; max: 7; min: 0), (typ: top_none), (typ: top_none))), + // A_SBRS + (numOperands: (1 shl 2); Operands: ((typ: top_reg; rt: rt_all), (typ: top_const; max: 7; min: 0), (typ: top_none), (typ: top_none))), + // A_SBIW + (numOperands: (1 shl 2); Operands: ((typ: top_reg; rt: rt_even_24_30), (typ: top_const; max: 63; min: 0), (typ: top_none), (typ: top_none))), + // A_AND + (numOperands: (1 shl 2); Operands: ((typ: top_reg; rt: rt_all), (typ: top_reg; rt: rt_all), (typ: top_none), (typ: top_none))), + // A_ANDI + (numOperands: (1 shl 2); Operands: ((typ: top_reg; rt: rt_16_31), (typ: top_const; max: 255; min: 0), (typ: top_none), (typ: top_none))), + // A_OR + (numOperands: (1 shl 2); Operands: ((typ: top_reg; rt: rt_all), (typ: top_reg; rt: rt_all), (typ: top_none), (typ: top_none))), + // A_ORI + (numOperands: (1 shl 2); Operands: ((typ: top_reg; rt: rt_16_31), (typ: top_const; max: 255; min: 0), (typ: top_none), (typ: top_none))), + // A_EOR + (numOperands: (1 shl 2); Operands: ((typ: top_reg; rt: rt_all), (typ: top_reg; rt: rt_all), (typ: top_none), (typ: top_none))), + // A_COM + (numOperands: (1 shl 1); Operands: ((typ: top_reg; rt: rt_all), (typ: top_none), (typ: top_none), (typ: top_none))), + // A_NEG + (numOperands: (1 shl 1); Operands: ((typ: top_reg; rt: rt_all), (typ:
Re: [fpc-devel] Static class methods can or cannot be virtual?
2018-01-22 18:48 GMT+01:00 Mattias Gaertner : > On Mon, 22 Jan 2018 18:45:57 +0100 > Maciej Izak wrote: > > Correct. There was some topic about "static class methods" and "class > > property" some time ago on fpc-devel or in fpc-pascal. For example static > > class methods can be used as callback procedure for external > APIs/Libraries. > > Can you explain what external APIs/Libraries have to do with class > properties? > "Class property" was not mentioned in the part about "external APIs/Libraries". -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Static class methods can or cannot be virtual?
On Mon, 22 Jan 2018 18:45:57 +0100 Maciej Izak wrote: > 2018-01-22 18:25 GMT+01:00 Denis Kozlov : > > > I presume then there is no way for having a class property who's returned > > value can be dynamically changed in child classes? In other words, class > > property getters/setters can only be implemented by the class that declared > > the property. > > > > Correct. There was some topic about "static class methods" and "class > property" some time ago on fpc-devel or in fpc-pascal. For example static > class methods can be used as callback procedure for external APIs/Libraries. Can you explain what external APIs/Libraries have to do with class properties? Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Static class methods can or cannot be virtual?
2018-01-22 18:25 GMT+01:00 Denis Kozlov : > I presume then there is no way for having a class property who's returned > value can be dynamically changed in child classes? In other words, class > property getters/setters can only be implemented by the class that declared > the property. > Correct. There was some topic about "static class methods" and "class property" some time ago on fpc-devel or in fpc-pascal. For example static class methods can be used as callback procedure for external APIs/Libraries. -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Static class methods can or cannot be virtual?
On 22/01/2018 17:09, Maciej Izak wrote: This was bug, fixed in trunk (see my rev. 35724) Thank you for pointing that out. I presume then there is no way for having a class property who's returned value can be dynamically changed in child classes? In other words, class property getters/setters can only be implemented by the class that declared the property. Thanks, Denis ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Static class methods can or cannot be virtual?
2018-01-22 18:00 GMT+01:00 Denis Kozlov : > Can static class methods be virtual? > This was bug, fixed in trunk (see my rev. 35724) -- Best regards, Maciej Izak ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Static class methods can or cannot be virtual?
Hello, Can static class methods be virtual? According to the FPC documentation, static class methods cannot be virtual, as stated here: https://www.freepascal.org/docs-html/ref/refsu30.html But in practice, FPC compiles and executes virtual and overridden static class methods just fine. The following code prints "AB" with FPC 3.0.4 and 2.6.4. === type TTestA = class protected class function GetName: String; virtual; static; public class property Name: String read GetName; end; type TTestB = class(TTestA) protected class function GetName: String; override; static; end; class function TTestA.GetName: String; begin Result := 'A'; end; class function TTestB.GetName: String; begin Result := 'B'; end; begin WriteLn(TTestA.Name, TTestB.Name); end. === Thanks, Denis ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
