For a hypothetical Evil Project(tm), I would like to do a LLVM backend
for a virtual machine that does not use 8-bit bytes. Does LLVM support
this sort of thing?
The details are: each addressing unit in the virtual machine can store a
single value of any type, except for data pointers, which are stored as
pairs (handle and offset). As such, sizeof(char) == sizeof(int) =sizeof(long
long) == sizeof(float) == sizeof(double) =sizeof(void(*)()) == 1, and
sizeof(void*) == 2.
I did achieve success with another compiler framework a while back ---
but I did have to fix some bugs in it first. This isn't something people
tend to want to do much!
On a related note, I remember seeing compile-time flags to clang to tell
it the sizes of the various primitive types, but I can't find them any
more. Do they still exist or will I need to do a custom clang build to
change them?
--
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ─────
│
│ life←{ ↑1 ⍵∨.^3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵ }
│ --- Conway's Game Of Life, in one line of APL
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20110128/1a32080a/attachment.sig>
On Fri, Jan 28, 2011 at 6:29 AM, David Given <dg at cowlark.com> wrote:> For a hypothetical Evil Project(tm), I would like to do a LLVM backend > for a virtual machine that does not use 8-bit bytes. Does LLVM support > this sort of thing?Not without some modification. I've developed an LLVM back end for a DSP with 24-bit word-addressable memory, basically by defining the alignment of i8 to be the word size of the machine. So it _is_ possible. There are a bunch of places in clang/llvm that assume that the alignment of i8 is 8, and these all need to be generalized to respect the specified alignment. Then in your instruction lowering code you need to convert all the offsets in memory accesses from 8-bit units to word-sized ones so that addressing is correct. Of course, this approach only works if you are willing to specify chars as i8 in clang. FWIW, I'm working towards properly generalizing the size of char in clang in my spare time, but that work is not nearly complete. I plan to someday extend that work into llvm. I can send you a patch of the changes that I made to clang/llvm release 2.8, if you'd like. Be warned that it also contains support for non-power-of-2 machine types. -Ken
On 28/01/11 14:14, Ken Dyck wrote: [...]> I've developed an LLVM back end for a DSP with 24-bit word-addressable > memory, basically by defining the alignment of i8 to be the word size > of the machine. So it _is_ possible.I think I might have an easier job of it, as I don't want to use any of the standard C sizes at all --- my char will be ~64 bits wide (in fact, my hypothetical VM stores all values as doubles) and will occupy one complete storage cell, so I don't need to do anything as weird as storing values of one size in a storage cell of another size. From what you've said it sounds like all I need to do is to do the right thing when lowering getelementptr, and it will all Just Work. Unfortunately I know from experience that clang doesn't always use getelementptr when doing point arithmetic --- how can I stop it trying to advance a pointer by one (64-bit) char by adding eight to it? (Also, how do I change the size of the built-in types in clang? I could swear I once saw some command-line options to do this, but can't find them now. And I can't find any documentation for clang's -cc1 mode...) -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ───── │ │ "I have a mind like a steel trap. It's rusty and full of dead mice." │ --- Anonymous, on rasfc -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110128/7806e67b/attachment.sig>