<div dir="ltr">The 2nd approach does seem nicer: separates concerns, makes it easier to extend (especially important given RISC-V's modular ISA). Although, as David said, both seem pretty clean. One thing I would add is not too worry about the conciseness too much initially: I have been "too clever" before when trying to write concise tablegen definitions, only to find that it needlessly complicated making changes and made it difficult to follow. Refactoring it to be more concise from a clear base is easier than the opposite IMHO.<div><br></div><div>Best,</div><div><br></div><div>Jacques</div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Aug 18, 2017 at 6:11 AM Alex Bradbury <<a href="mailto:asb@asbradbury.org">asb@asbradbury.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 18 August 2017 at 13:02, John Leidel <<a href="mailto:john.leidel@gmail.com" target="_blank">john.leidel@gmail.com</a>> wrote:<br>
> I agree with David's sentiment.  The second method appears to be easier to<br>
> follow.  IMHO, this would be easier for external users that desire to modify<br>
> the backend for their own custom extensions/instructions.<br>
<br>
Hi David and John, thanks for the feedback. I realise I didn't express<br>
my view in the original email - I also feel that the second approach<br>
works out as cleaner. As you say, it seems plausible that the<br>
separation will make it easier to add new custom<br>
extensions/instructions and we expect that to be a common activity.<br>
The main reason I'm sharing for wider feedback is to ensure there<br>
aren't further options that haven't been considered, as it's not going<br>
to be painful to introduce such refactorings further down the line.<br>
<br>
Best,<br>
<br>
Alex<br>
</blockquote></div>