FW: [sdcc-devel]Using movc to read xram

[Sandeep D. <sa...@dd...>]

-----Original Message-----
From: Sandeep Dutta [mailto:sa...@dd...]
Sent: Tuesday, May 08, 2001 9:09 AM
To: 'sdc...@li...'
Subject: RE: [sdcc-devel]Using movc to read xram


Paul,

Have you thought of using the peephole optimizer to replace the 
movx instructions. The you can add your own peephole optimization
rules during the compilation process using the --peep-file option
the file will contain something like
replace {
	movx	a,@dptr
} by {
	clr	a
	movc	a,@a+dptr
}

This option was provided specifically for these situations. Let me
know if this works for you. 
Sandeep

-----Original Message-----
From: sdc...@li...
[mailto:sdc...@li...]On Behalf Of Kevin Vigor
Sent: Tuesday, May 08, 2001 9:03 AM
To: sdc...@li...
Cc: pa...@pj...
Subject: Re: [sdcc-devel]Using movc to read xram



On 08-May-2001 pa...@pj... wrote:
> Oh no, I was worried that these changes might seem too intrusive to the
> project.  The burden to the code is eleven "if (options.xram_movc)"
> inside
> mcs51/gen.c, and two inside SDCCmain.c.  I'll explain why the "wierd"
> hardware in a moment.

Sandeep should obviously have the final say, since this is still his
baby, but I would say that this doesn't look too intrusive to me, with
the possible exception of adding the smallc and largec models to the
default library build; I'd prefer to see them added to an optional build
target (like the existing tini target (*)). I do also think it might be
slightly better if you wrote a MOVX macro that expanded to either movx a,
@dptr or clr a/movc a,@a+dptr rather than putting the test in 11 places
in gen.c; it's a little cleaner, and you'd probably also have a better
chance of future tinkerers getting it right that way. But neither of
these things are huge problems.

So I'd vote it goes in (and Paul gets CVS access so that he can maintain
his work, which will undoubtedly be broken by one of us with less-weird
hardware sooner or later).

        Peace,
                Kevin

(*) actually, the tini target is a bad example because it's a subset of
the default build rather than an optional superset, but it's the only one
available to crib from.


_______________________________________________
sdcc-devel mailing list
sdc...@li...
http://lists.sourceforge.net/lists/listinfo/sdcc-devel