[M3devel] m3cg.i3 reduction?

[Jay K]

There is no such mode currently for m3back. I think.
 At least it doesn't operate that way normally.
 It keeps very little in memory, going fairly directly from function calls to file output.
 Not entirely, but largely.
 Not a bad idea though.
 
 
But maybe I'm wrong here. Maybe the thing to write/read to the gcc backend can also drive m3back? And then I can start with m3front output but edit in variations? That could be handy.
 
 
Still, these things are give and take.
You theorize as to what you might need.
Then you write the consumer.
Then you discover you might have missed some things and might have put in some unnecessary things. Not all generalizations should be kept. Interfaces should be reviewed for areas that ended up not needed.
And you also write the producer and find some things to be easy or difficult.
"Build it and they will come", to some extent yes, to some extent no.
sign extension was "so easy" that the original authors wrote it, including for non-constants, but I don't think it works for count=0 for example, which the current front end never exercises..not even with constants..
 
 
Given my current implementation strategy, which produces less efficient but clear and dependency-free code, it is perhaps easier to extend things back.
(still waiting to hear if the larger size bothers anyone, though the tables are gone, that is a reduction; not sure clarity is so important at the assembly level, it is assembly after all)
 
 
 - Jay



----------------------------------------
> From: hosking at cs.purdue.edu
> Date: Mon, 8 Mar 2010 14:32:53 -0500
> To: rodney_bates at lcwb.coop
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] m3cg.i3 reduction?
>
> On 8 Mar 2010, at 12:42, Rodney M. Bates wrote:
>
>> It is never realistic to try to thoroughly test a later (than the first) phase of
>> any compiler solely by pumping source code through the earlier phases. Every
>> compiler I have ever worked on had tools to allow hand-coded input to later
>> phases, either already, or else I wrote one, if I had significant responsibility
>> for testing. Sometimes it can be done with a plain old text editor, if the
>> intermediate stream is character-encoded.
>
> Indeed.
>
>> Similarly, you need to be able dump the intermediate forms of output from earlier
>> phases in human-readable form. Don't we already have at least some of this?
>
> Yes, m3cgcat and friends...
>
>>
>> Jay K wrote:
>>> The backend interface has a few aspects that the frontend does not use.
>>> Implementations of these are therefore /extremely/ difficult to test and therefore probably don't work.
>>>
>