From: Alan Lehotsky <qsmgmt@earthlink.net>
To: cgen@sourceware.org
Subject: problems with 48 bit instruction architecture...
Date: Sat, 26 Nov 2011 19:44:00 -0000 [thread overview]
Message-ID: <EB43DFA3-8932-4C1A-A294-B0361A10D9C8@earthlink.net> (raw)
I'm looking at a machine with 48 bit instructions (fixed length). I'm hosting on Ubuntu x86 linux.
The target architecture is little-endian, and I've described the machine with
(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
oxfc0000000000
which won't fit into the CGEN_INSN_INT type field (because that's defined as 'int' in cgen.h. If I change cgen.h to have CGEN_INSN_INT defined as uint64, 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
0000 0400c200 0000
where the first '0000' is the address in the text section. 'od -t x1' confirms 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 separate address spaces on this machine - but the missing opcode is a non-starter.
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 should be using the byte-string representation.
reply other threads:[~2011-11-26 19:44 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=EB43DFA3-8932-4C1A-A294-B0361A10D9C8@earthlink.net \
--to=qsmgmt@earthlink.net \
--cc=apl@alum.mit.edu \
--cc=cgen@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).