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>&nbsp;</div>
<div>So this could be considered either a proposal or a question, your choi=
ce.</div>
<div>&nbsp;</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>&nbsp;</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>&nbsp;</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>&nbsp;</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>&nbsp;</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>&nbsp;</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>&nbsp;</div>
<div>A discussion, perhaps?</div>
<div>&nbsp;</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==--