[M3devel] "C-generating backend progress report, that nobody asked for" :)
Antony Hosking
hosking at cs.purdue.edu
Mon Sep 10 02:54:12 CEST 2012
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/20120909/aff32e65/attachment-0002.html>
More information about the M3devel
mailing list