[M3devel] "C-generating backend progress report, that nobody asked for" :)

[Dragiša Durić]

Got this Ramsey paper.. My first thought was - why wait for gdb, why reinvent debugging..? In my book, debugger is one more reason to jump over to LLVM bandwagon.

I really like what GCC people did and do. Great minds, great hackers. And no less people than anybody else. And I am perfectly aware just how bad they (RMS for sure, probably others) feel about Modula-3. It is logical thing to do - shrug these problems off. After two decades of catching up with their cryptic changes, ever changing undocumented behavior, rewriting of specific support modules…  

C backend is good thing to have, and kudos to Jay for it. But… LLVM is what we really need.

TIA

--
Divided by a common language

Dragiša Durić
dragisha at m3w.org




On Sep 11, 2012, at 2:07 AM, Antony Hosking wrote:

> Stock gdb won’t ever parse M3 expressions nor print M3 values.
> So, there will always have to be some M3 support added.
> I would much prefer providing M3 library support for source debuggers to parse and print.
> I have no idea whether gdb has ever considered some of the extensibility support I pointed at in the link below.
> 
> Antony Hosking | Associate Professor | Computer Science | Purdue University
> 305 N. University Street | West Lafayette | IN 47907 | USA
> Mobile +1 765 427 5484
> 
> 
> 
> 
> 
> On Sep 10, 2012, at 1:47 AM, Jay K <jay.krell at cornell.edu> wrote:
> 
>> Please, no.
>> 
>> Stock gdb and stock Visual C++ and stock cdb/ntsd/windbg ought to work well with Modula-3.
>> I expect they will pretty good pretty soon, and we should try to make them even better maybe...
>> by making globals visible in a reasonable fashion.
>> 
>> 
>> m3gdb isn't supported on Darwin and HP-UX (no stabs), at least.
>> If the gcc backend becomes obsolete and deleted...m3gdb would be the last of the
>> forked always-going-stale never-merging GPL stuff... i.e. another ripe target...
>> 
>> 
>> 
>>  - Jay
>> 
>> Subject: Re: [M3devel] "C-generating backend progress report, that nobody asked for" :)
>> From: hosking at cs.purdue.edu
>> Date: Sun, 9 Sep 2012 20:54:12 -0400
>> CC: dragisha at m3w.org; m3devel at elegosoft.com
>> To: jay.krell at cornell.edu
>> 
>> Stock debuggers are designed for C.  They generally will not be able to grok M3.  Better to use M3 run-time type information as per m3gdb.  See 10.1145/143103.143112.
>> 
>> 
>> On Sep 9, 2012, at 4:07 PM, Jay <jay.krell at cornell.edu> wrote:
>> 
>> The current method stinks for stock debugging. As I understand, globals are combined into structs & the fields all have generated names, & global records are flattened therein.
>> 
>> 
>> It works. But stock debuggers see garbage.
>> 
>> 
>>  - Jay (briefly/pocket-sized-computer-aka-phone)
>> 
>> On Sep 9, 2012, at 12:22 PM, Antony Hosking <hosking at cs.purdue.edu> wrote:
>> 
>> I mis-spoke.  I think LLVM can cope with much the same as we currently have.  Front-end will continue to compute alignments and layouts.  We can assert the front-end's datalayout by passing it to LLVM explicitly, which will complain if it does not match the actual target.  This is a rather nice feature of LLVM in that it allows us to retain control while having LLVM optimize accordingly.
>> 
>> On Sep 9, 2012, at 11:05 AM, Antony Hosking <hosking at cs.purdue.edu> wrote:
>> 
>> Yes, agreed, these need to be properly typed too.
>> First step will be to lift the M3CG interface.
>> Problem: The compiler needs to control layout so that the run-time system knows where to find things.  This means that we need to assert alignments and layouts produced by the backend are the same as those in the front-end.  LLVM has nice ways to do this.  How will we do it in the C backend?  Does C have sufficient control over alignment?
>> 
>> On Sep 9, 2012, at 10:53 AM, Jay <jay.krell at cornell.edu> wrote:
>> 
>> Btw, can this include "segment"/globals? Can they each be separate named variables? At least some of them?
>> 
>> 
>>  - Jay (briefly/pocket-sized-computer-aka-phone)
>> 
>> On Sep 9, 2012, at 7:48 AM, Antony Hosking <hosking at cs.purdue.edu> wrote:
>> 
>> I'm looking at it...
>> 
>> First step is to lift slightly the level of M3CG to use properly typed memory access, instead of untyped address + offset.
>> 
>> On Sep 9, 2012, at 2:32 AM, Dragiša Durić <dragisha at m3w.org> wrote:
>> 
>> I hope somebody will take on LLVM :).
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120914/48a24393/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120914/48a24393/attachment-0002.sig>