Proposal/question for GPC
"scott andrew franco" <[email protected]> Mon, 02 Nov 2020 13:32:52 -0700
| Newsgroups | gmane.comp.compilers.gpc |
|---|---|
| Message-ID | <20201102133252.6c61c97e98fe7bb02193b2d6dca4a85a.822ee8da3f.mailapi@email15.godaddy.com> |
--===============1541117925392191487== Content-Type: multipart/alternative; boundary="=_76cb8244dfc9abbaa491c5c3fe4815c4" --=_76cb8244dfc9abbaa491c5c3fe4815c4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 For the GPC authors =20 So this could be considered either a proposal or a question, your choice. =20 Recently, for various reasons I have been studying the LLVM project (mainly= because I am now forced to use LLVM on the Mac OS X). As I am sure you know, LLVM is bec= oming popular as a backend. For example, I believe FPC now uses it. =20 An interesting thing about LLVM is that they bent over backwards to make su= re it was as compatible as possible with previous GCC methods, components and front-ends= , with an eye to making it easy to port existing front ends to LLVM. =20 So I think you can guess where I am going with this. The GPC group dropped = the GPC project mainly because GCC had changed and the requirements to meet the new GCC backend were too large to meet for the GPC group (WRT: Quo vas GPC). =20 Might that have changed with the introduction of LLVM? It would seem that t= he GPC front end would be a perfect match for LLVM, and the problems with upgrading to t= he current GCC backend may be solved with using LLVM as backend? =20 I looked at porting one of my compilers to LLVM, and decided that it would = be more of a complete translation to meet the requirements of the LLVM intermediate fo= rmat. Its a good/very good IR, but it has its own ideas about stack framing, calling co= nventions, etc. It would need a front end rewrite specifically to target that IR. =20 However, GPC, combined with the support LLVM provides for GCC legacy front = ends, might be a different story. =20 A discussion, perhaps? =20 Scott Franco. --=_76cb8244dfc9abbaa491c5c3fe4815c4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <div>For the GPC authors</div> <div> </div> <div>So this could be considered either a proposal or a question, your choi= ce.</div> <div> </div> <div>Recently, for various reasons I have been studying the LLVM project (m= ainly because I am</div> <div>now forced to use LLVM on the Mac OS X). As I am sure you know, LLVM i= s becoming</div> <div>popular as a backend. For example, I believe FPC now uses it.</div> <div> </div> <div>An interesting thing about LLVM is that they bent over backwards to ma= ke sure it was as</div> <div>compatible as possible with previous GCC methods, components and front= -ends, with</div> <div>an eye to making it easy to port existing front ends to LLVM.</div> <div> </div> <div>So I think you can guess where I am going with this. The GPC group dro= pped the GPC</div> <div>project mainly because GCC had changed and the requirements to meet th= e new</div> <div>GCC backend were too large to meet for the GPC group (WRT: Quo vas GPC= ).</div> <div> </div> <div>Might that have changed with the introduction of LLVM? It would seem t= hat the GPC front</div> <div>end would be a perfect match for LLVM, and the problems with upgrading= to the current</div> <div>GCC backend may be solved with using LLVM as backend?</div> <div> </div> <div>I looked at porting one of my compilers to LLVM, and decided that it w= ould be more of</div> <div>a complete translation to meet the requirements of the LLVM intermedia= te format. Its a</div> <div>good/very good IR, but it has its own ideas about stack framing, calli= ng conventions,</div> <div>etc. It would need a front end rewrite specifically to target that IR= =2E</div> <div> </div> <div>However, GPC, combined with the support LLVM provides for GCC legacy f= ront ends,</div> <div>might be a different story.</div> <div> </div> <div>A discussion, perhaps?</div> <div> </div> <div>Scott Franco.</div> --=_76cb8244dfc9abbaa491c5c3fe4815c4-- --===============1541117925392191487== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Gpc mailing list [email protected] https://www.g-n-u.de/mailman/listinfo/gpc --===============1541117925392191487==--