Xref: csiph.com comp.arch:44359 Newsgroups: comp.arch Path: csiph.com!news.redatomik.org!aioe.org!news.etla.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!usenet-its.stanford.edu!usenet.stanford.edu!kithrup.com!mrs From: mrs@kithrup.com (Mike Stump) Subject: Re: A right alternative to IEEE-754's format Message-ID: Date: Sun, 22 Apr 2018 18:55:33 GMT References: <0d4dc7f8-1819-43e5-8082-6ff7aee5f41b@googlegroups.com> Organization: Kithrup Enterprises, Ld. X-Newsreader: trn 4.0-test77 (Sep 1, 2010) In article , David Brown wrote: >On 09/04/18 13:30, Walter Banks wrote: >Still, you are clearly correct that gcc is designed for a certain style >of processor. Targets should have registers able to hold an "int", No such requirement exists. You're confused. >and preferably have a fair number of general-purpose registers, Again, no such requirement exists. >an orthogonal instruction set, Nope, not really that necessary either, though, it does help speed porting. >and few special registers or odd cases. Again, no such requirement exists. These do impact porting speed, but, writting a compiler from scratch would be hard on such a platform anyway. Odd cases, tend to waste money unless there is a compelling need for them. >flat memory addressing :-) You don't get out much if you haven't seen a gcc port with 20 or more memory spaces. Again, this is a property of the target, not of gcc. Hint, gcc can have a ton of memory spaces. If you overflow, you might have to change the number of bits in gcc for such purposes, but that's usually a small change. >These assumptions are fine for a large number of processors - indeed, >cpus that don't fit them are getting pushed out more and more to niche >areas. I'd prhase it this way, if you want a large number of customers, giving them something which is easy to use it useful. You can invent a cpu with 30 bit integers, but expect to sink in a ton of money and not ever make it back. This is a property of the enconomics of the space, and a bit less to with with gcc per se. clang for example, you might characterize in a similar way. All my comments above apply equally well to clang.