Sorry about the orphan page, but I know there are other RecentChangesJunkie''''''s out there.

I'm hoping someone will AnswerMe on a somewhat odd question. I'm looking for a relatively easily retargetable C compiler that does NOT assume EightBitBytes. In particular, I will be using 23 bit bytes, with
    sizeof(char) = sizeof(short) = sizeof(int) = sizeof(void*) = 1
    sizeof(long) = 2
Performance does not particularly matter, although good is always good. And, needless to say, this is entirely for my own enjoyment on a personal project, not anything the rest of the world will ever need to endure, so practicality is not a particularly big deal.

If I can't find something along the lines of LCC but without that horrible 8-bit assumption, I'll probably give up on C for this machine entirely, which would be a bit of a pity, but not the end of the world. Still, before I give up, I'd love to hear some ideas!

-- AdamBerger

Um.  Why?  --BenAveling

For a personal project that, if I were to start going into it, I'd go into in such a depth that people would die of boredom. Postulate a system designed for purposes other than running C code that has evolved to use 24-bit words, word addressable, with 23 bits of data per word and a single tag bit per word. In order to enable such a system to run C, there are various approaches, but I think the one described above is a good compromise; it fits the standard and it has the potential to be reasonably quick, at the cost of not allowing C to access the tag bit.

Now, the next "why" is "why does such a system exist"; the answer to that, I'm afraid, is "purely for my own amusement."

(Note that today is May 23, 2006. To avoid this clutter from staying around, if you encounter this page after July 1, 2006, and it doesn't seem to have gotten any more interesting, it would probably be a good idea to delete it.) --AB

''When C was first becoming portable (see its history to see what that meant) there were many systems with characters and words that were not powers of two (for instance, 36 bit word systems with 5 or 7 bit characters like the DEC 10), and as far as I saw at the time, no such system ever supported a full-fledged C compiler even given the not-yet-standardized nature of C at the time. I think you are SOL.''

My understanding (rather than recollection, as it was before my time) is that there were several 36-bit systems that used 6-bit or 9-bit bytes, regardless of the actual character size, in order to fill the C requirement that bytes span the memory space completely. I even seem to recall systems where char*s were bigger than int*s, since int*s were word addresses, while char*s had to have additional offset information.

''Yes, that's the entire point of the CHAR_BIT macro (sometimes called the BITS_PER_UNIT ). It tells you how many bits are in a "char" on this machine, emphasizing that it is not 8 on some machines. See the C FAQ http://www.parashift.com/c++-faq-lite/intrinsic-types.html .''

''My understanding is that a full-fledged C cross-compiler exists for lots of systems where 8 != CHAR_BIT. Mostly they are DSPs and some supercomputers.''

* compiling lwIP (written in C) to run on a TMS320 DSP (which has a 16 bit "char"): http://lists.nongnu.org/archive/html/lwip-users/2003-01/msg00083.html . I suspect they use the GCC GnuCompilerCollection, which supports the TMS320 and a few other DSPs. http://gcc.gnu.org/install/specific.html

Going a bit further off-topic,
* Froth is a language specifically designed for non-byte-addressible DSP (tms320c50) http://sourceforge.net/projects/froth . I suspect that porting such a ForthLanguage-like language might be quicker than porting a C compiler.

''Yep, I already have forth running, and self is on its way as well. I just wouldn't mind nethack. --AB''