Re: How to clean up i386 machine description?

[Colin Douglas Howell <howell at cs dot stanford dot edu>]

Jeffrey A Law writes:
> 
>   In message <19981026203605.C25151@dot.cygnus.com>you write:
>   > Running a very close second in importance is to give the scheduler
>   > an accurate description of how the instruction to be emitted should
>   > be scheduled.  It does little good to tell the scheduler that the
>   > instruction is of one type when for some case something entirely
>   > different is emitted.

> Very true.  One of the other major problems in the x86 port.

I've noticed this too.

>   > One of Jan's patches attempts to add issue information for the
>   > pentium to the paterns.  However, the approach he took is not
>   > particularly accurate, and I fear not to be scalable to even 3 
>   > ia32 variants -- there are probably at least 7 extant now, and
>   > more to come.  I hadn't had the heart to tell Jan eariler, since
>   > I didn't know what to do about it.
> 
> Same as we're doing elsewhere, only uglier.  Instead of using constraints to
> drive reload, use them to drive attribute characteristics.  It's not going to
> be pretty though.

The x86 architecture is far from pretty, so we can't exactly expect an
accurate description of it to look nice.

>   > As a consequence of a bit of nagging from some quarters, I've been
>   > thinking about this a lot recently.  The only way I can see to get
>   > this right is to move all of the final instruction selection logic
>   > out of the large output code blocks, and put it somewhere visible
>   > to the scheduler -- namely, tied to attribute type.  Furthermore,
>   > the instruction output patterns must be based exclusively on the
>   > external selection code.  Otherwise we can't prove convergance and
>   > will have lost out on that hard work.
> 
> Yup.

OK, I'm not exactly clear on how the solution you're describing would
work, much less why it is the best solution.  But being a naive
newbie, that's to be expected.  Are there any machine descriptions you
can point to as sterling examples of The Right Way To Do It?  :-)

>   > This is a huge amount of work, amounting to a near complete rewrite
>   > of the .md file.  I can't see that anything less will result in
>   > anything other than mass confusion though.
> 
> Yup, and that's precisely what we're going to need to do in the end...  The
> x86 port just was never written with a scheduler in mind.  Converting it to
> be scheduler aware is going to be a major pain in the ass.

Yes, I figured getting this machine description to work well would be
a whole lot of work.  All the more reason to get started.

Do you have any ideas on how we could break down this task and decide
in what order to do things?

-- 
Colin Douglas Howell                    Systems Administrator
e-mail:  howell@cs.stanford.edu         Computer Facilities Group
office:  (650) 723-2491                 Computer Science Department
                                        Stanford University