Xref: csiph.com comp.arch:44362 Newsgroups: comp.arch Path: csiph.com!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 19:52:57 GMT References: <0d4dc7f8-1819-43e5-8082-6ff7aee5f41b@googlegroups.com> <04e76b45-029e-406f-9cd3-1e8f88d31fc5@googlegroups.com> <00f57960-d344-4e58-bd88-e197ceb656a5@googlegroups.com> Organization: Kithrup Enterprises, Ld. X-Newsreader: trn 4.0-test77 (Sep 1, 2010) In article , Walter Banks wrote: >It is worth looking at processor families that have some members that >have left shift and some members that do not. It opens up a whole lot of >potential problems. These are not problems. They are just the facts on the ground when doing a port. >How do different assemblers and compilers deal with this? There are only two solutions. First, the nice one, and second, the not nice one. All the nice ones behave identically. A port to gcc/clang, to be specific can be nice, or not-nice, as the port writter wishes. This is a property of the port, not the compiler. Some other compilations systems might only feature non-nice solutions, but I'm ignorant of those systems. >Do they know which family member they are dealing with That is one way to do it. I would say this is the preferred solution method I've seen. >It is a significant two copy problem. Weird, I'd not call that a problem at all. >It affects fundamental optimization. Compilers that actually know >about the instruction set that they are using instead of a safe >subset are capable of generating better code. > >This is one of the reasons that Byte Craft compilers for more than 40 >years compile directly to machine code and not through an assembler. This is irrelevant to the above mentioned problem. No compiler that knows what it is doing has any problem with this, regardless if they generate assembly or machine code, unless the asm is really deficient. I suppose the later could happen, but usually would be predicated on using a third party broken assembler. In the open source world, this can't happen. One can always generate a non-broken assembler, if they wish. Again, this would be a porting issue.