From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17034 invoked by alias); 15 Nov 2001 20:42:46 -0000 Mailing-List: contact cgen-help@sourceware.cygnus.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cgen-owner@sourceware.cygnus.com Received: (qmail 16991 invoked from network); 15 Nov 2001 20:42:40 -0000 X-Authentication-Warning: toenail.toronto.redhat.com: fche set sender to fche@redhat.com using -f To: dje@transmeta.com (Doug Evans) Cc: , cgen@sources.redhat.com Subject: Re: [patch][rfa] Ordering insns in hash chain for cgen disassemblers References: <3BF3F9AE.8070907@redhat.com> <15348.168.750723.846784.cygnus.local.cgen@casey.transmeta.com> Content-Type: text/plain; charset=US-ASCII From: fche@redhat.com (Frank Ch. Eigler) Date: Sat, 13 Oct 2001 02:39:00 -0000 In-Reply-To: <15348.168.750723.846784.cygnus.local.cgen@casey.transmeta.com> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 X-SW-Source: 2001-q4/txt/msg00009.txt.bz2 dje wrote: : [...] : I'm not going to argue for it's removal but fwiw it slightly bothers me. : I worry it's just going to cause headaches. Yeah, I worried too, for a little while. : [While not being the only cause of the worry, question: how will this : sort play with ifield assertion support when it's added, What value do you see for the ifield-assertion mechanism (the "(andif (eq FOO 0) ...)" clauses in derived-operands, right?), beyond what the encoding fields ("+ (f-FOO 0) ...") can/should provide? As it is, RTL-rich code appears legal in too many contexts. : and the user's expectation that things are picked based on order in : the file. [...] IMO, such expectations are just desperate measures to try to get around some cgen limitations. As those limitations start to disappear (and brolley is going to work on one of the most annoying: insn encoding special cases), these measures will no longer be needed. (Thanks for still keeping an eye on cgen!) - FChE From mboxrd@z Thu Jan 1 00:00:00 1970 From: fche@redhat.com (Frank Ch. Eigler) To: dje@transmeta.com (Doug Evans) Cc: , cgen@sources.redhat.com Subject: Re: [patch][rfa] Ordering insns in hash chain for cgen disassemblers Date: Thu, 15 Nov 2001 12:42:00 -0000 Message-ID: References: <3BF3F9AE.8070907@redhat.com> <15348.168.750723.846784.cygnus.local.cgen@casey.transmeta.com> X-SW-Source: 2001-q4/msg00034.html Message-ID: <20011115124200.jipMPmR980TNImrpATWP4vf_w_N8ZhRAmpwiY8nQGnA@z> dje wrote: : [...] : I'm not going to argue for it's removal but fwiw it slightly bothers me. : I worry it's just going to cause headaches. Yeah, I worried too, for a little while. : [While not being the only cause of the worry, question: how will this : sort play with ifield assertion support when it's added, What value do you see for the ifield-assertion mechanism (the "(andif (eq FOO 0) ...)" clauses in derived-operands, right?), beyond what the encoding fields ("+ (f-FOO 0) ...") can/should provide? As it is, RTL-rich code appears legal in too many contexts. : and the user's expectation that things are picked based on order in : the file. [...] IMO, such expectations are just desperate measures to try to get around some cgen limitations. As those limitations start to disappear (and brolley is going to work on one of the most annoying: insn encoding special cases), these measures will no longer be needed. (Thanks for still keeping an eye on cgen!) - FChE