From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24430 invoked by alias); 11 Jun 2003 17:23:24 -0000 Mailing-List: contact cgen-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cgen-owner@sources.redhat.com Received: (qmail 24326 invoked from network); 11 Jun 2003 17:23:23 -0000 Received: from unknown (HELO mail.sebabeach.org) (64.165.110.50) by sources.redhat.com with SMTP; 11 Jun 2003 17:23:23 -0000 Received: by mail.sebabeach.org (Postfix, from userid 42) id A98E3B536; Wed, 11 Jun 2003 10:26:10 -0700 (PDT) From: Doug Evans To: brolley@redhat.com Cc: cgen@sources.redhat.com In-reply-to: <3EE74E11.1040700@redhat.com> (message from Dave Brolley on Wed, 11 Jun 2003 11:43:13 -0400) Subject: frv suggestions References: <20030611080838.A848BB536@mail.sebabeach.org> <3EE74E11.1040700@redhat.com> Message-Id: <20030611172610.A98E3B536@mail.sebabeach.org> Date: Wed, 11 Jun 2003 17:23:00 -0000 X-SW-Source: 2003-q2/txt/msg00096.txt.bz2 Here's a couple of suggestions for the frv port. 1) I don't know if anyone maintaining it uses emacs, but I'd highly recommend using ^L to delimit groups of instructions. When skimming through source files, I find the following extremely useful. ; one-liner describing this section mumble ... ^L ; one-liner describing this section mumble ... ^L ; one-liner describing this section mumble ... ... and so on ... If something is small enough one sometimes needn't bother. But methinks frv.cpu is big enough that the above would be helpful. frv.cpu already does this for hardware vs operands vs insns, etc. But the "Instruction definitions" section is large enough that I wonder if adding some more ^L's would make traversing it easier. Just a thought. I only browse it rarely, so I don't know if going to the trouble will pay off or not. In emacs I can then do C-x [ and C-x ] to quickly traverse through each section of the file and with the one-liner I can quickly see where I am. 2) To make the generated html more useful, you might want to redefine the IDOC attribute to be something more resembling the frv, and add the attribute to each instruction. This lets the html generator categorize instructions and makes the instruction set more accessible to the human reader. I added some simple heuristics to make the result semi-usable in the absence of explicitly provided IDOC attributes, but it breaks down, for example, if all memory accesses are done via c-call's. :-) It also breaks down on the arm when every alu op can set the pc. Blech.