Re: [fpc-devel] FPC for Coldfire and 68K derivatives
On 02/14/2013 03:57 AM, Mike Salish wrote: At the moment the 68K versions still in production are all for control applications in embedded systems. These chips use the CPU32 and more recently the MCF5 Coldfire architecture. For MCF there are some sources of small and cheap demo boards (netgear, Arcturus I know of). IMO Coldfire is the only viable path for future development that can see any practical use. And I think MCF code should run on the CPU32 as well even though it will not use all the addressing modes of the CPU32. I am using a "Fido" chip by Innovasic. Same is a really interesting upgrade to an 68332: - 66 MHz clock (4 times the 332) - full CPU 32 instruction set (plus a few extensions) with 5hardware threads (5 register sets and appropriate mechanism to switch between them) - four 8 bit I/O-coprocssors (code in dedicated RAM, not ROM) - internal fast execution RAM with mapping - a decent amount of internal RAM - 16 bit external bus usable for static RAM/ROM/IO and DDR - "endless" life cycle by the guaranteed by Innovasic It does have some queer glitches (e.g. the dbcc instruction does not work correctly in the internal execution RAM), but this usually can be overcome. So 68K in CPU 32 flavor is not dead at all. I'll be happy to test the fpc compiler (and RTL) output on our board done with this chip, once it is able to to CPU32 code. -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC for Coldfire and 68K derivatives
On 02/15/2013 11:45 AM, Sven Barth wrote: Nevertheless I'm currently mostly working on Coldfire support. While this obviously is viable, I (understanding that the Coldfire ISA is a subset of CPU32), do hope that the final version is able to optionally work for both flavors (plus the "big" 68 K chips). If the "dbcc" instruction is used in the CPU32 variant (very useful for CPU32 due to hardware optimization, I suppose dbcc does not exist for Coldfire), it would be good to support a "Fido" flavor that avoids dbcc (in the very unlikely case you want to use fpc code in the "rapid Execution Ram" if a Fido chip. Thanks for you work ! -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Is target mips-embedded possible / planned?
On 02/17/2013 03:11 PM, Michel Catudal wrote: the PIC32 is high on my list. GREAT ! fpc really is a model of a vivid community project. Thanks, -Michael ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] State of extended RTTI
Can I help? Info about good implementation of TValue - http://www.cromis.net/blog/2013/02/tanyvalue-an-attempt-to-make-the-best-variable-data-container/ Has FPC some equivalent of invoke from rtti.pas (dynamically invoking a methods and procedures/functions)? If not - I have my own basic implementation (for stdcall, register and cdecl) based on PascalScript calling engine. Regards, HNB 2013/2/10 Sven Barth : > On 10.02.2013 14:19, Maciej Izak wrote: >> >> Hi, >> >> What is the state of Extended RTTI (like in Delphi 2010 and up)? >> >> You can read in the comment by Sven >> >> "One of the developers has started to implement class attributes and >> I’m rather sure that the enhanced RTTI will come sooner or later as >> well" >> http://www.deltics.co.nz/blog/?p=1129 >> >> How's he doing? > > > Class attributes is still being worked on in a branch (by Joost). I > personally plan to work on generics the next time (fixing bugs and adding > support for generic methods). After that I plan to tackle extended RTTI if > no one implements it before me. > > Regards, > Sven > > ___ > fpc-devel maillist - fpc-devel@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] State of extended RTTI
Hi All, We have developed an advanced RTTI API that replaces the Embarcadero RTTI API and provides much more powerful and easy to use when accessing the RTTI. We developed it as we ware running into huge number of issues and bugs when trying to use the Embarcadero implementation, and we needed stable, robust and very easy to use implementation, since we have started to rely very heavily on the new RTTI in our development. It also offers additional functionalities not currently available in the Embarcadero extended RTTI, as well as we are doing some work around for critical bugs in the Delphi RTTI unit. If there is interest in adding extended RTTI support in FPC, i am willing to donate the API, and its implementation to the effort if it is deemed a good fit. Who is working on the RTTI at the moment? I can send him/her/them the RTTI unit for evaluation. With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Maciej Izak Sent: Monday, February 18, 2013 9:04 AM To: FPC developers' list Subject: Re: [fpc-devel] State of extended RTTI Can I help? Info about good implementation of TValue - http://www.cromis.net/blog/2013/02/tanyvalue-an-attempt-to-make-the-best-variable-data-container/ Has FPC some equivalent of invoke from rtti.pas (dynamically invoking a methods and procedures/functions)? If not - I have my own basic implementation (for stdcall, register and cdecl) based on PascalScript calling engine. Regards, HNB 2013/2/10 Sven Barth : On 10.02.2013 14:19, Maciej Izak wrote: Hi, What is the state of Extended RTTI (like in Delphi 2010 and up)? You can read in the comment by Sven "One of the developers has started to implement class attributes and I’m rather sure that the enhanced RTTI will come sooner or later as well" http://www.deltics.co.nz/blog/?p=1129 How's he doing? Class attributes is still being worked on in a branch (by Joost). I personally plan to work on generics the next time (fixing bugs and adding support for generic methods). After that I plan to tackle extended RTTI if no one implements it before me. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] State of extended RTTI
On 18.02.2013 20:30, Boian Mitov wrote: Hi All, We have developed an advanced RTTI API that replaces the Embarcadero RTTI API and provides much more powerful and easy to use when accessing the RTTI. We developed it as we ware running into huge number of issues and bugs when trying to use the Embarcadero implementation, and we needed stable, robust and very easy to use implementation, since we have started to rely very heavily on the new RTTI in our development. It also offers additional functionalities not currently available in the Embarcadero extended RTTI, as well as we are doing some work around for critical bugs in the Delphi RTTI unit. If there is interest in adding extended RTTI support in FPC, i am willing to donate the API, and its implementation to the effort if it is deemed a good fit. Who is working on the RTTI at the moment? I can send him/her/them the RTTI unit for evaluation. No one is currently working on the RTTI itself. Attributes are currently being worked on, but without support through the RTTI unit (procedural access is provided through the TypInfo unit). How compatible to Delphi's API is your API? If it is not compatible, then it would not be of much use to us. Please note that we would in any case only use the API itself, as we might not implement the binary layout of the RTTI necessarily the same as Delphi did. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] State of extended RTTI
> > From: Boian Mitov >To: FPC developers' list >Sent: Monday, February 18, 2013 4:30 PM >Subject: Re: [fpc-devel] State of extended RTTI > > Hi All, > >We have developed an advanced RTTI API that replaces the Embarcadero RTTI API >and provides much more powerful and easy to use when accessing the RTTI. >We developed it as we ware running into huge number of issues and bugs when >trying to use the Embarcadero implementation, and we needed stable, robust and >very easy to use implementation, since we have started to rely very heavily on >the new RTTI in our development. It also offers additional functionalities not >currently available in the Embarcadero extended RTTI, as well as we are doing >some work around for critical bugs in the Delphi RTTI unit. >If there is interest in adding extended RTTI support in FPC, i am willing to >donate the API, and its implementation to the effort if it is deemed a good >fit. >Who is working on the RTTI at the moment? I can send him/her/them the RTTI >unit for evaluation. > >With best regards, >Boian Mitov > Hi Boian, did you have to modify/patch the compiler, or it is implemented as a set of classes?. Leonardo M. Ramé http://leonardorame.blogspot.com ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] State of extended RTTI
On 18.02.2013 18:04, Maciej Izak wrote: Can I help? The generation of the extended RTTI data is currently missing which needs corresponding knowledge in the compiler. And I'm also waiting for the finishing of the attributes implementation which will pave some way for the extended RTTI data. Also Joost (who implements the attributes) stated that he's also working on a primitive RTTI unit, so that needs to be checked first. Additionally support for generic methods needs to be added (this is on my own near term todo list). After that ground work you would principially be free to implement the RTTI unit. Info about good implementation of TValue - http://www.cromis.net/blog/2013/02/tanyvalue-an-attempt-to-make-the-best-variable-data-container/ Please note that the interface needs to be implemented in a way compatible to Delphi's RTTI.TValue. Has FPC some equivalent of invoke from rtti.pas (dynamically invoking a methods and procedures/functions)? If not - I have my own basic implementation (for stdcall, register and cdecl) based on PascalScript calling engine. We currently don't have an Invoke function. Please note that we also have additional calling conventions (oldfpccall, cppdecl) and that the conventions used on other platforms (especially other CPUs) are different. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] State of extended RTTI
Hi Sven, It is an abstraction API that on the low side is 100% compatible with the Delphi API, as it uses it to access the information, but on the user side presents extremely easy to use API. It is probably better than anything available in the world at the moment, and light years ahead of both the Microsoft .NET RTTI API and the Embarcadero RTTI API. Being abstraction layer it also can be hooked on anything you have on the back end without breaking the code. With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Sven Barth Sent: Monday, February 18, 2013 11:37 AM To: fpc-devel@lists.freepascal.org Subject: Re: [fpc-devel] State of extended RTTI On 18.02.2013 20:30, Boian Mitov wrote: How compatible to Delphi's API is your API? If it is not compatible, then it would not be of much use to us. Please note that we would in any case only use the API itself, as we might not implement the binary layout of the RTTI necessarily the same as Delphi did. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] State of extended RTTI
Hi Leonardo, At the moment we are only replacing some of the buggy parts of the catching in the Emb. RTTI. We are also working to get it to perform faster than the Delphi RTTI by implementing our own caching mechanisms. With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Leonardo M. Ramé Sent: Monday, February 18, 2013 11:39 AM To: FPC developers' list Subject: Re: [fpc-devel] State of extended RTTI Hi Boian, did you have to modify/patch the compiler, or it is implemented as a set of classes?. Leonardo M. Ramé http://leonardorame.blogspot.com ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] State of extended RTTI
On 18.02.2013 20:49, Boian Mitov wrote: Hi Sven, It is an abstraction API that on the low side is 100% compatible with the Delphi API, as it uses it to access the information, but on the user side presents extremely easy to use API. It is probably better than anything available in the world at the moment, and light years ahead of both the Microsoft .NET RTTI API and the Embarcadero RTTI API. Being abstraction layer it also can be hooked on anything you have on the back end without breaking the code. In that case it might be a viable addition to the Delphi compatible API. If we'd use your API we could also adjust its implementation in such a way that it directly uses FPC's yet-to-be-implemented RTTI data (which would improve performance). If you want you could send me a version of your unit so that I can take a look at it. Just in case: If we should integrate the API as part of the RTL would you be willing to publish it under our modified-LGPL license? If you prefer a different license we could provide your API either as an additional package bundled with FPC's distribution or provided through the FPPKG system. [of course only once we've implemented extended RTTI at all ;) ] Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] State of extended RTTI
As example this enumerates all attributes of certain type for any public or published member (function, field, or property) for a component: for LMember in TRTRtti.GetType( Component.ClassType() ).GetMembers( [mvPublic, mvPublished] ) do for LAtrribute in LMember.GetAttributes( TMyCustomAttributeType, True ) do You can see how much can be achieved with almost no code :-D and this is just the tip of the iceberg ;-) . It supports filtering with lambdas, and in general is designed in the principles of functional programming, so you can as example filter like this: AAttributes := TRTRtti.GetType( Component.ClassType() ).GetCustomAttributes( TVLCommonFilterHostedPreviewAttribute, True ); for AAttribute in AAttributes do if( AAttribute is TLPComponentEditorAttribute ) then begin AAttrItem := GComponentEditorAttributeList.Find( function( AItem : IComponentEditorAttributeItem ) : Boolean var AAttributes : IRTAttributes; AAttributeClass : TCustomAttributeClass; begin AAttributeClass := AItem.GetInstance().AttributeClass; AAttributes := TRTRtti.GetType( Component.ClassType() ).GetCustomAttributes( TLPSuppressAttributeAttribute, True ); if( AAttributes.Find( function ( ASupressAttribute : TCustomAttribute ) : Boolean begin Result := ( AAttributeClass = TLPSuppressAttributeAttribute( ASupressAttribute ).Attribute ); end ) <> NIL ) then Exit( False ); Result := ( AAttribute is AAttributeClass ); end ); Exit( AAttrItem.GetInstance().ComponentEditor.Create( Component, Designer )); end; This actually is a real piece of code from a place we use the new RTTI ;-) With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Boian Mitov Sent: Monday, February 18, 2013 11:49 AM To: FPC developers' list Subject: Re: [fpc-devel] State of extended RTTI Hi Sven, It is an abstraction API that on the low side is 100% compatible with the Delphi API, as it uses it to access the information, but on the user side presents extremely easy to use API. It is probably better than anything available in the world at the moment, and light years ahead of both the Microsoft .NET RTTI API and the Embarcadero RTTI API. Being abstraction layer it also can be hooked on anything you have on the back end without breaking the code. With best regards, Boian Mitov --- Mitov Software www.mitov.com --- -Original Message- From: Sven Barth Sent: Monday, February 18, 2013 11:37 AM To: fpc-devel@lists.freepascal.org Subject: Re: [fpc-devel] State of extended RTTI On 18.02.2013 20:30, Boian Mitov wrote: How compatible to Delphi's API is your API? If it is not compatible, then it would not be of much use to us. Please note that we would in any case only use the API itself, as we might not implement the binary layout of the RTTI necessarily the same as Delphi did. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
