From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15730 invoked by alias); 26 Nov 2011 19:44:50 -0000 Received: (qmail 15719 invoked by uid 22791); 26 Nov 2011 19:44:48 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,TW_XF X-Spam-Check-By: sourceware.org Received: from elasmtp-banded.atl.sa.earthlink.net (HELO elasmtp-banded.atl.sa.earthlink.net) (209.86.89.70) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 26 Nov 2011 19:44:34 +0000 Received: from [24.41.5.239] (helo=[192.168.1.107]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1RUOAr-0001Rv-Kq for cgen@sourceware.org; Sat, 26 Nov 2011 14:44:33 -0500 From: Alan Lehotsky Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Reply-To: apl@alum.mit.edu Subject: problems with 48 bit instruction architecture... Date: Sat, 26 Nov 2011 19:44:00 -0000 Message-Id: To: cgen@sourceware.org Mime-Version: 1.0 (Apple Message framework v1251.1) X-ELNK-Trace: 9e0cfd4f457cc6ab94f5150ab1c16ac0809d4cb36e9c09f429f6a5d64b006a7c1bb73d71818cd0e4350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c Mailing-List: contact cgen-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cgen-owner@sourceware.org X-SW-Source: 2011-q4/txt/msg00007.txt.bz2 I'm looking at a machine with 48 bit instructions (fixed length). I'm host= ing on Ubuntu x86 linux. The target architecture is little-endian, and I've described the machine w= ith (define-arch .... (default-alignment aligned) (insn-lsb0? #t) (machs xyz) (isas xyz)) (define-isa (name xyz) (default-insn-word-bitsize 48) (default-insn-bitsize 48) (base-insn-bitsize 48)) and then defined the fields of the instruction beginning at bit 47, the MSB= of what should be byte 0 of a 6 byte instruction. BUT, when I run cgen, I find that my xyz-opc.c file gets compilation errors= because the CGEN_IFMT entries are being given hex literals like=20 oxfc0000000000 which won't fit into the CGEN_INSN_INT type field (because that's defined a= s 'int' in cgen.h. If I change cgen.h to have CGEN_INSN_INT defined as uin= t64, then my opcodes stuff all compiles and the assembler builds. But the = generated .o file has the instruction bytes output (according to objdump) for a "ret 4" = instruction comes out as =20=20=20=20 0000 0400c200 0000=20=20=20=20 where the first '0000' is the address in the text section. 'od -t x1' conf= irms that the 0x04 is the first byte which is exactly backwards AND missing the opcode. Based on my instruction= definitions, I would expect to see 1c00002c 0004 where 0x1c is the primary opcode. I could live with the bytes being out-of= -order - it would be easy to flip them since instructions and data are sepa= rate address spaces on this machine - but the missing opcode is a non-start= er. So, I imagine I'm doing something stupid, but I don't see what it is... I've checked that CGEN_INT_INSN_P is defined as 0 in xyz-desc.h, so I shoul= d be using the byte-string representation.