- std::hexfloat - 19 Updates
- neos - the universal compiler that can compile any programming language - 1 Update
- Tarski undefinability totally refuted by junior high school logic - 1 Update
- [Jesus Loves You] How'd we become so depraved? - 3 Updates
- neos strikes again! - 1 Update
| Keith Thompson <kst-u@mib.org>: May 22 05:20PM -0700 > wider than object pointers, that the mismatch ceases to be a real problem. > Although it would be better if the workaround was implemented in the > compiler, to give the impression that function pointers were a normal size. A workaround for what problem? Assuming a CPU on which function addresses are naturally bigger than object addresses, I don't see much advantage in adding a level of indirection just to let C++ function pointers be the same size as C++ object pointers. The language is carefully designed so that it *doesn't* require different pointer types to have the same size -- even different object pointer types. -- Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst> Will write code for food. void Void(void) { Void(); } /* The recursive call of the void */ |
| James Kuyper <jameskuyper@alumni.caltech.edu>: May 22 09:12PM -0400 On 5/22/19 5:40 PM, David Brown wrote: > There are a number of small microcontrollers where data space pointers > are 16-bit, but full function pointers are longer as they support more > than 64K of code flash. ... This is a valid example of pointers of different types having different sizes. However, he's asking about pointers to a location where something with a "C type is stored". Functions aren't stored in a location, not in that sense, not as far as C++ is concerned. > flash areas and are 24-bit long. There are smaller microcontrollers > which use 8-bit pointers for "local page" addresses, and bigger pointers > for when paging is used. ... Those are pointers whose sizes are different depending upon the location where they point, not depending upon the type of data stored in that location. C++ doesn't allow for that possibility - it could only be provided as an extension to C++. > pointers" with larger lengths than byte pointers. There are DSP's with > 16-bit and 32-bit "char" that have support for "octet pointers" that are > longer, because they encode the octet number within the C "byte". The smallest addressable location in C++ is a byte, and char must be exactly one byte long. Again, those could only be provided as an extension to C++. The example I always use is an implementation targeting a platform with a small amount of memory, and a word size that is large enough that the implementors decide to define CHAR_BIT to be smaller than the word size. Objects of most types with sizeof(T) > word_size will usually have _Alignof(T) be a multiple of the word size, and pointers to such types need only point at a particular word. Pointers at types smaller than the word size need to also identify the particular byte within a word, which requires them to be longer. These are similar in terms of implementation to the "octet pointers" you describe above, but if they point at a single octet, then CHAR_BIT muxt be 8, not 16 or 32 as in the implementations you describe. Unfortunately, I don't have specific examples of such implementations saved up. |
| Ian Collins <ian-news@hotmail.com>: May 23 04:49PM +1200 >> It is not true at the moment either. There are more processors around > So which architectures have a variable number of memory addressing bits > depending on what C type is stored at the address then? Google "Harvard Architecture". -- Ian. |
| blt_naqv25mlmM@xl5ztir5.gov.uk: May 23 08:41AM On Wed, 22 May 2019 18:09:11 GMT >Some (now basically extinct) burroughs systems, for example, have 80-bit >function pointers, but 32-bit data pointers. Not uncommon for segmented >architectures (a la 80286). Fine, if we're moving away from von neumann architectures then you can obviously have different sized instruction and data pointers. But even then a float and and int would have the same sized pointer. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 23 10:50AM +0200 > So which architectures have a variable number of memory addressing > bits depending on what C type is stored at the address then? Although ne near and far keyword's weren't standard C, their pointer -types had different sizes. But you can safely assume that something like this will never happen again. |
| blt_0j9@davzrs835rlrkb6xh3sx7j.edu: May 23 08:52AM On Wed, 22 May 2019 20:16:06 +0100 >> >strict aliasing. >> How about finding one that acually proves your point. >What a fine display. Even capital letters and exclamation marks!! Well it got your attention which was the point. >aliasing effects it produces and presumably therefore without actually >running it at all. You have, in fact, completely missed the point >about aliasing. I compiled as is. >it produces: > 0 > 1 All that proves is what we already know - optimisers occasionally try to be too clever and get it wrong. Is that it? |
| David Brown <david.brown@hesbynett.no>: May 23 10:56AM +0200 On 22/05/2019 23:55, Bart wrote: >> pointer-to-object sized. (Why do you even need to ask that?) > Because it is such an obvious workaround when function pointers are much > wider than object pointers, that the mismatch ceases to be a real problem. A mismatch is not a problem, so no workaround is needed. > Although it would be better if the workaround was implemented in the > compiler, to give the impression that function pointers were a normal size. Why would it matter what size function pointers are, and if they are the same size as data pointers? (Note that C11 also has support for atomic pointers-to-objects, and atomic pointers-to-functions, neither of which has to match the size of the non-atomic versions. This is because the compiler can attach extra data to an object to handle atomic locking, if it needs to. I expect that in most C11 implementations, atomic objects are the same size as non-atomic objects - I know of no exceptions. But that may just be my lack of knowledge in the area.) This is c.l.c++. In C++, there are many more types of pointers. (You can make them in C too, of course, but you don't get the convenient syntax and language support.) In the basic language, you have pointers to class members and pointers to class methods, each of which can be bigger. In the standard library and in common use, there are all kinds of smart pointers, unique pointers, shared pointers, etc., with wildly different sizes. Different pointers have different purposes. You don't mix function pointers and data pointers - they do very different things. So there is no need for a common size. |
| David Brown <david.brown@hesbynett.no>: May 23 10:58AM +0200 On 23/05/2019 02:20, Keith Thompson wrote: > C++ object pointers. The language is carefully designed so that it > *doesn't* require different pointer types to have the same size -- > even different object pointer types. Exactly. A compiler implementation might use indirect jump targets, vectors, or whatever to make function pointers more efficient (smaller and/or faster). But it is the efficiency that is important, not a match in size with other pointers. |
| David Brown <david.brown@hesbynett.no>: May 23 11:04AM +0200 > Fine, if we're moving away from von neumann architectures then you can > obviously have different sized instruction and data pointers. But even then > a float and and int would have the same sized pointer. The distinction between "von Neumann" and "Harvard" architectures has long ago lost much of its meaning in computer architecture. And it is not a particularly relevant point here. (For example, the 80286 would be classified as von Neumann, but you could use it with different memory models and different sizes for data and function pointers.) In C, pointers to float and int (and any other object type, and void) are the same size. Some implementations have extensions with different pointer types of different sizes. |
| David Brown <david.brown@hesbynett.no>: May 23 11:13AM +0200 On 23/05/2019 03:12, James Kuyper wrote: > The smallest addressable location in C++ is a byte, and char must be > exactly one byte long. Again, those could only be provided as an > extension to C++. Yes, these things are extensions to C or C++. Blt was asking if they existed in real implementations - they do. > These are similar in terms of implementation to the "octet pointers" you > describe above, but if they point at a single octet, then CHAR_BIT muxt > be 8, not 16 or 32 as in the implementations you describe. 6.3.2.3p7 says that pointers to one object type can be converted to a pointer of another object type and back again, giving the original value unchanged. I had thought that implied that all pointers to object types are the same size (except for implementation extensions, which is what I have been considering so far, and which I have seen in real tools). But the conversions are only valid if alignments are valid - this would, I think, allow a system such as you describe to have longer pointers to char (and void) than pointers to larger objects. |
| David Brown <david.brown@hesbynett.no>: May 23 11:18AM +0200 On 23/05/2019 10:50, Bonita Montero wrote: > Although ne near and far keyword's weren't standard C, their pointer > -types had different sizes. But you can safely assume that something > like this will never happen again. No, you can't assume that. You can assume we are unlikely to see segmented architectures again on PC's, but there are lots of small microcontrollers with paged memory, near and far pointers, and pointers to different types of memory. There are also lots of other possibilities for alternative pointer types which may carry extra information, as compiler extensions (or pointer classes in C++). |
| David Brown <david.brown@hesbynett.no>: May 23 11:24AM +0200 >> 1 > All that proves is what we already know - optimisers occasionally try to be > too clever and get it wrong. Is that it? No, it proves that some /programmers/ get things wrong - especially when they stick blindly on incorrect assumptions rather than learning the language. And then they suffer from it, when their programs are unreliable, buggy, and inconsistent. Good programmers make mistakes too, of course, but they try to learn from them - and from information they are given by other people. |
| blt_xm6vl8@7eqf07tkhq310_7tni0.gov.uk: May 23 09:27AM On Thu, 23 May 2019 11:24:09 +0200 >> All that proves is what we already know - optimisers occasionally try to be >> too clever and get it wrong. Is that it? >No, it proves that some /programmers/ get things wrong - especially when No, it proves optimisers get things wrong. If you actually dump the memory at the pointer address you'll see it is zero so the optimiser is actually putting the value 1 aside and returning that instead of returning the deferenced memory value. That is incorrect behaviour. >they stick blindly on incorrect assumptions rather than learning the >language. And then they suffer from it, when their programs are >unreliable, buggy, and inconsistent. Oh spare me, I was probably programming assembly when you were still learning what PRINT "Hello world" did. >Good programmers make mistakes too, of course, but they try to learn >from them - and from information they are given by other people. If you say so. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 23 11:27AM +0200 > segmented architectures again on PC's, but there are lots of small > microcontrollers with paged memory, near and far pointers, and pointers > to different types of memory. ... Name some of them. |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: May 23 10:36AM +0100 On Thu, 23 May 2019 08:52:02 +0000 (UTC) blt_0j9@davzrs835rlrkb6xh3sx7j.edu wrote: [snip] > All that proves is what we already know - optimisers occasionally try to be > too clever and get it wrong. Is that it? No, it proves that some programmers try to be too clever and get it wrong. Or more to the point, to go back to what I said at the outset: "What is a lot more frightening is incompetent programmers writing code which depends on pointer casts without realising that their code (a) gives undefined behaviour, and (ii) is total crap, and might break on a compiler upgrade or on a change of optimization level." I cannot understand why you are so slow on the uptake. It has been pointed out a number of times on this thread that the compiler is entitled to carry out type-based alias analysis relying on C or C++'s strict aliasing rules. That is what happens here. And working examples have been given of this elsewhere on this thread. |
| blt_f8p38@rzfsxp7t4lu5qy8v1mfu13yps1.edu: May 23 11:03AM On Thu, 23 May 2019 10:36:49 +0100 >> too clever and get it wrong. Is that it? >No, it proves that some programmers try to be too clever and get it >wrong. No, its optimisers being too clever and getting it wrong. As I said in a reply to someone else - dump the memory at the address just before the return and you'll find that it is zero yet the opimised code incorrectly returns the value of 1. The compiler obviously did a look ahead and got it wrong. >depends on pointer casts without realising that their code (a) gives >undefined behaviour, and (ii) is total crap, and might break on a >compiler upgrade or on a change of optimization level." Its not my problem if the people who wrote the compiler made a cock up. >entitled to carry out type-based alias analysis relying on C or C++'s >strict aliasing rules. That is what happens here. And working >examples have been given of this elsewhere on this thread. Yes, thats what it did and it got it wrong. It its naively assuming the value returned should be 1 whereas the correct dereferenced value is zero. Its things like this that make using optimisation a trial and error process. |
| Ian Collins <ian-news@hotmail.com>: May 23 11:17PM +1200 >> No, it proves that some programmers try to be too clever and get it >> wrong. > No, its optimisers being too clever and getting it wrong. How can the compiler get undefined behaviour wrong? It will try and warn you if you ask it: g++ -O2 a.cc -Wstrict-aliasing=1 a.cc: In function 'int main()': a.cc:14:42: warning: dereferencing type-punned pointer might break strict-aliasing rules [-Wstrict-aliasing] x = foo(reinterpret_cast<float*>(&x), &x); -- Ian. |
| blt_4zlek_0g@ivbo5ok_l3.ac.uk: May 23 11:27AM On Thu, 23 May 2019 23:17:08 +1200 >>> wrong. >> No, its optimisers being too clever and getting it wrong. >How can the compiler get undefined behaviour wrong? Since when is deferencing a memory address undefined behaviour? The memory value is zero yet the binary is returning 1. The compiler fucked up. |
| Ian Collins <ian-news@hotmail.com>: May 23 11:32PM +1200 >> How can the compiler get undefined behaviour wrong? > Since when is deferencing a memory address undefined behaviour? The memory > value is zero yet the binary is returning 1. The compiler fucked up. Read the bit you snipped. -- Ian. |
| Ike Naar <ike@sdf.lonestar.org>: May 23 06:14AM > else > return add(fib(x-1), fib(x-2)); > } What will fib(2) do? |
| peteolcott <Here@Home>: May 22 10:15PM -0500 Sound deductive inference necessitates true conclusions therefore sound deductive inference applied to formal proofs of mathematical logic necessitates true consequences. The above sentence is 100% of totally all that is needed to define the True(x) the Tarski "proved" to be impossible to define. -- Copyright 2019 Pete Olcott All rights reserved "Great spirits have always encountered violent opposition from mediocre minds." Albert Einstein |
| Daniel <danielaparker@gmail.com>: May 22 06:37PM -0700 On Wednesday, May 22, 2019 at 6:05:40 PM UTC-4, Rick C. Hodgin wrote: > The founding fathers of America, those men who were intimately in- > volved with the establishment of the United States and its U.S. > Contitution and Bill of Rights, provide insight "The day will come when the mystical generation of Jesus by the Supreme Being in the womb of a virgin, will be classed with the fable of the generation of Minerva in the brain of Jupiter. ... But we may hope that the dawn of reason and freedom of thought in these United States will do away with all this artificial scaffolding...." — Thomas Jefferson in an April 11, 1823, letter to John Adams: "The government of the United States is not, in any sense, founded on the Christian religion." — John Adams |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: May 22 06:58PM -0700 On Wednesday, May 22, 2019 at 9:37:51 PM UTC-4, Daniel wrote: > "The government of the United States is not, in any sense, founded on the Christian religion." > — John Adams A superseding treaty (the Treaty of Peace and Amity) signed on July 4, 1805, omitted that phrase. What Adams wrote was that the U.S. is not like England, which forced a religion upon its citizens as a specific state-sponsored religion. The U.S. was not founded to be Catholic, or Baptist, or any other Christian religion. It was, however, founded upon Christian ideals, by Christians whose ancestors left their parent nation to practice religion freely. That's what the link shows. Even people like Thomas Paine later repented, saying a prayer in his later life wishing the Age of Reason had never been written. Time aids in breaking down the rebellious wails of youth. God continues to tug at you, and many find faith later in life. -- Rick C. Hodgin |
| "Rick C. Hodgin" <rick.c.hodgin@gmail.com>: May 22 07:05PM -0700 On Wednesday, May 22, 2019 at 9:37:51 PM UTC-4, Daniel wrote: > "The government of the United States is not, in any sense, founded on the Christian religion." > — John Adams You have to put things in whole perspective: John Adams wrote these quotes: SIGNER OF THE DECLARATION OF INDEPENDENCE; JUDGE; DIPLOMAT; ONE OF TWO SIGNERS OF THE BILL OF RIGHTS; SECOND PRESIDENT OF THE UNITED STATES "The general principles on which the fathers achieved independence were the general principles of Christianity. I will avow that I then believed, and now believe, that those general principles of Christianity are as eternal and immutable as the existence and attributes of God." "Without religion, this world would be something not fit to be mentioned in polite company: I mean hell." "The Christian religion is, above all the religions that ever prevailed or existed in ancient or modern times, the religion of wisdom, virtue, equity and humanity." "Suppose a nation in some distant region should take the Bible for their only law book and every member should regulate his conduct by the precepts there exhibited. . . . What a Eutopia – what a Paradise would this region be!" "I have examined all religions, and the result is that the Bible is the best book in the world." It's a matter of history and record people living in our modern culture would like to do away with, just like the Confederate Flag and the true purpose of the Civil War (states rights vs. federal rights). The southern states wanted to be more self-governing, less centralized governing (as per the federal government), hence their use of the word "Confederate" instead of "United." So much is lost when people forget history. -- Rick C. Hodgin |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: May 23 12:38AM +0100 > language of my own design. neoscript aside the first two languages I > currently plan to implement are Java and Haskell which couldn't be any > more different. Hmmm... As different as COLBOL and APL? As different as Fortran and Occam? As different as Common Lisp and Algol 68? I'm not so sure. Fortran has a notoriously fussy syntax. Algol 68 has various concrete forms that are just optional representations of the abstract language. Lisp has very sophisticated macros... Java and Haskell as not adjacent in the language space but I would not put them at opposite ends of the universe. -- Ben. |
| 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