- mixing compilers (g++ but Intel others)? - 12 Updates
| David Brown <david.brown@hesbynett.no>: May 01 10:16PM +0200 On 01/05/16 17:24, Jerry Stuckle wrote: >> such a method. I certainly know of two compilers I have used that don't >> have such support. > And exactly which compilers don't? Two that I have used are Imagecraft's AVR compiler, and National Semiconductor's HPC40000 compiler. These are tools for embedded microcontrollers, both of which are quite old. I doubt if anyone here has heard of either of them (some will know of the AVR, but it is unlikely that they are familiar with Imagecraft's tools). That's just two examples. I have used perhaps a dozen different compilers, not including gcc ports, for embedded devices over the years - and many of these are very different from the sort of tools /you/ are used to. (And yes, I know that you have used tools that are unfamiliar to me.) > fact, I dare you to show ANY compilation which is completely > independent. Not every one uses "gcc" as the compiler command, for > instance. And not all of them use -o for output. I did not ask for a compilation - I asked for C code. (Technically, I asked for a "method" using nothing but the features required in one of the C or C++ standards. But since these do not cover any methods of running programs, merely of how to write C code and what that code should do, "solutions" dependent on running extra programs are invalid.) |
| David Brown <david.brown@hesbynett.no>: May 01 10:21PM +0200 On 01/05/16 21:23, Jerry Stuckle wrote: >> It's certainly true of the Piccolo DSP with TI's CCS compiler suite. > So, if it's a single byte, then there is no difference between big > endian and little endian, is there? They're the same thing. <spoonfeed mode> For the TI C2000 with 16-bit chars, there is no difference for 16-bit values, but there /is/ a difference for 32-bit values. And for those DSPs like the SHARC that have 32-bit chars, endianness is relevant for 64-bit values. </spoonfeed mode> |
| Gareth Owen <gwowen@gmail.com>: May 01 09:28PM +0100 > So, if it's a single byte, then there is no difference between big > endian and little endian, is there? They're the same thing. And how would you describe the two different ways in which a 32-bit value might be stored - LSWord:MSWord vs MSWord:LSWord? |
| Jerry Stuckle <jstucklex@attglobal.net>: May 01 05:07PM -0400 On 5/1/2016 4:21 PM, David Brown wrote: > <spoonfeed mode> > For the TI C2000 with 16-bit chars, there is no difference for 16-bit > values, but there /is/ a difference for 32-bit values. <anti-troll mode> Then you use int or long instead of short, as I said in an earlier post. But I already know you can't read - and won't admit you're wrong. > And for those DSPs like the SHARC that have 32-bit chars, endianness is > relevant for 64-bit values. > </spoonfeed mode> The same can be said for 32 vs. 64 bit values </anti-troll mode> -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: May 01 05:07PM -0400 On 5/1/2016 4:28 PM, Gareth Owen wrote: >> endian and little endian, is there? They're the same thing. > And how would you describe the two different ways in which a 32-bit > value might be stored - LSWord:MSWord vs MSWord:LSWord? Which is going to be used by the hardware? -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: May 01 05:14PM -0400 On 5/1/2016 4:16 PM, David Brown wrote: > microcontrollers, both of which are quite old. I doubt if anyone here > has heard of either of them (some will know of the AVR, but it is > unlikely that they are familiar with Imagecraft's tools). Gee, antiquated compilers which aren't even used any more. Can you drag up any other red herrings? And if you insist on those, then it's simple - a script which uses the output of endian.c to create a header file with the #define and include it in the compiled file. > - and many of these are very different from the sort of tools /you/ are > used to. (And yes, I know that you have used tools that are unfamiliar > to me.) Yes, I have used compilers for embedded devices, also. And every one of them has had the ability to define precompiler constants in the command line. > any methods of running programs, merely of how to write C code and what > that code should do, "solutions" dependent on running extra programs are > invalid.) And I provided a method. And running the programs is not part of the C standard - it is part of the compiler operation. That is not defined by the standard. But if you need to be thoroughly pedantic about it, just use the program to create a header file, which is then included. Now you have something that is standard and determines endianness at compile time. >> So once again you are trying to change the rules rather than admit you >> are wrong. >> It doesn't work. You keep trying to change the rules. It doesn't work. But I know you'll keep trying instead of admitting I showed you how to do something you claimed couldn't be done. And that's why you'd never make it as a consultant. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Jerry Stuckle <jstucklex@attglobal.net>: May 01 05:21PM -0400 On 5/1/2016 3:45 PM, David Brown wrote: >> replace short with int, long, long long... > Others have already mentioned such systems - but as usual, you are > unaware of any processors outside your limited experience. And I mentioned how the technique can be adapted to work for them. > limitations render it totally useless (since whenever you have these > limitations, there are other ways to figure out endianness). And you > failed to solve the stated problem. Within YOUR REQUIREMENTS the concept works and solved the problem. But rather than admit you're wrong, you try to change the rules. It doesn't work. > That is why I wrote "it is not portable". I can appreciate that you are > unable to remember what was written a few posts back, but hopefully you > can read a couple of lines before losing track. Yes, your "requirements" are bullshit because they aren't portable. My solution is just as "portable" (actually even more so) than your so-called "practical needs". > programming - perhaps most C programming these days - is > cross-compilation for embedded systems. Clearly your suggestion fails > there. Your requirements said nothing about cross-compilation. So once again you're trying to change the rules. It doesn't work. > Checking __BYTE_ORDER__ works on a fair number of practical systems, and > many compilers that don't have that particular pre-defined macro have > similar ones. Which means it is not dependent on pre-defined macros - and is more portable. >> big endian or little endian. There were no other restrictions placed on >> it. This satisfies that requirement. > Read again. I did. And you can't change the rules after being given the solution. > As I said, I would have liked to have had a real solution - but a > limited form of autoconfig is not particularly useful to anyone. > (Admittedly your solution is a lot easier to use that autoconfig!) No, you have a "real solution". But you won't admit you are wrong and I showed you how to do something you claimed couldn't be done. You just keep trying to change the rules. >> employees just say "it can't be done". > It's a problem that can't be solved as stated - but perhaps that won't > stop some consultants from selling their "services" nonetheless. It's a problem which was solved AS STATED. If you don't like the solution, you should have made the requirements more clear. But you can't change the rules after being provided with the solution. >>> reliable solution. >> Once again you are changing the rules. It doesn't work. > Again, please re-read the requirements. I did. And again, you are changing the rules. It doesn't work. > innovative or imaginative solution - it's just that /if/ that had been > at all useful, then it would have been better to have the first program > generate an include file for the second program. Again, it solved YOUR REQUIREMENTS. If those are wrong, that's YOUR problem. But you can't change the rules after being provided the solution. However, again, I know you will never admit I showed you how to do something you claimed couldn't be done. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: May 01 10:57PM +0100 Jerry Stuckle <jstucklex@attglobal.net> writes: <snip> > There are no implementation dependent assumptions. It is a technique > which works. Yes, it works in those systems that meet the assumptions made about the C implementation -- that short is large enough to determine the endianness and that short integers have no padding bits. > But you just can't admit I showed you something you said couldn't be > done. It doesn't matter what you showed 5 years ago. I'd ask you to say where I said that it can't be done but I image that would be as pointless as the rest of this exchange. You are not keen on citing evidence. -- Ben. |
| David Brown <david.brown@hesbynett.no>: May 02 12:15AM +0200 On 01/05/16 23:14, Jerry Stuckle wrote: >> unlikely that they are familiar with Imagecraft's tools). > Gee, antiquated compilers which aren't even used any more. Can you drag > up any other red herrings? You claimed /every/ compiler supports defining preprocessor macros on the command line, I told you that is not true. You asked for counter-examples, I gave you two. That's not a red herring, it's simply proving you wrong. And both these compilers /are/ used - /I/ use them, if I need to make changes to the old programs written using them. Last year I did have to make a minor change to a 20 year old program for the HPC. As another sample point, at least twice in the last ten years I have been asked by Usenet posters if I could supply a copy of the HPC compiler (I couldn't, as I was unable to get a response from the copyright holders when I asked for permission). > And if you insist on those, then it's simple - a script which uses the > output of endian.c to create a header file with the #define and include > it in the compiled file. Now you are beginning to get the hang of it! However, the endian.c program is totally irrelevant for cross-compiling. One day, perhaps, you will open your mind enough to learn something new. > Yes, I have used compilers for embedded devices, also. And every one of > them has had the ability to define precompiler constants in the command > line. Most do, especially modern ones, - but some don't. It's really quite simple. And of course you "solution" wouldn't work on any of them. > And I provided a method. And running the programs is not part of the C > standard - it is part of the compiler operation. That is not defined by > the standard. Correct - and thus your method fails to fulfil the challenge. > But if you need to be thoroughly pedantic about it, just use the program > to create a header file, which is then included. Now you have something > that is standard and determines endianness at compile time. And how are you going to "use" the program, in a completely implementation-independent way using nothing but what is required by the standards? After all, you agree that running programs is not defined by the standard. I suppose it would have been helpful if I had made this clearer in the challenge - I thought it was obvious. |
| Jerry Stuckle <jstucklex@attglobal.net>: May 01 07:04PM -0400 On 5/1/2016 5:57 PM, Ben Bacarisse wrote: > I'd ask you to say where I said that it can't be done but I image that > would be as pointless as the rest of this exchange. You are not keen on > citing evidence. And you are not keen on admitting you're wrong. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ================== |
| Ian Collins <ian-news@hotmail.com>: May 02 11:08AM +1200 On 05/02/16 11:04, Jerry Stuckle wrote: >> would be as pointless as the rest of this exchange. You are not keen on >> citing evidence. > And you are not keen on admitting you're wrong. Where was he wrong? -- Ian Collins |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: May 02 12:11AM +0100 On Sun, 01 May 2016 01:17:54 +0100 > > easier option. > Why is it undefined in C++? (I'm, not that familiar with the C++ > standard.) I don't know why. The recommended way of doing it in C++ is to use std::memcpy(), and rely on the optimizer to optimize out the copy where it is not in fact needed. I read some analysis some time ago which showed that this actually happens with common compilers. However gcc and clang are fine with type punning through unions in C++ (and specify that it works). As an implementation technique, in practice it is fine. Unions do not excuse you from the aliasing rules for pointer members (§3.10/10 of C++11, §6.5/7 of C11), but that is of no relevance here. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment