It was thus said that the Great ben via cctalk once stated: What CPUs did it correctly? And how did they handle signed vs. unsigned promotion? unsigned char *ufoo; unsigned long ubar; ufoobar = *ufoo + ubar; signed char *foo; signed long bar; foobar = *foo + bar; -spc

When signed and unsigned values (variables or literals) of the same size are combined the compiler assumes that all of the values are signed.  This can yield a problem if the unsigned integer is large enough that the most significant bit is set because this bit indicates sign. for example: uint8_t bValue = 128; int8_t   bValue1 = -128 Both have the same value in memory (0x80). On 8/15/2024 3:52 PM, Paul Koning via cctalk wrote:

More likely the language designers, assuming the compiler doesn't have a standards violation in its code. In the case of C, the type promotion rules that were just explained are rather bizarre and surprising. Other languages do it differently, with perhaps fewer surprises. Some define it very carefully (ALGOL 68 comes to mind), some not so much. paul

Fred, That is true, Order of expression is undefined between execution points that is why the following statement can produce different results on different compilers: A = 1; F = A++ * A++; Without the use of parenthesis the is no way for the user to know beforehand what the value of F will be.  The only guarantee is that when the before the next instruction is executed the all postfix operators will be evaluated prior to the start of the next C statement. As a general rule rvalue expressions are calculated by the pre-compiler and not the compiler.  So the line: ulDays  = ulSeconds / ( 60 * 60 * 24 ); Would be converted by the precompiler to: ulDay = ulSeconds / 86400; The calculation of the lvalue ulSeconds / 86400 will be handled at run time. However, if ulSeconds is defined as a const it is possible that a smart precompiler will do the entire calculation and only the assignment will be done at runtime. It is possible that the volatile keyword might cause the order of expression to be altered. uint32_t * volatile ulpDMAAddress = 0xffff0000;  // Note this is a volatile pointer and NOT a pointer to volatile data. uint32_t *ulpMyPointer; ulpMyPointer = *ulpDMAAddress++ + *ulpDMAAddress++; My mind is getting numb just looking at that code.  Suffice it to say that using multiple prefix/postfix operations in a single execution point is heavily deprecated because the actual results are implementation defined and my even be different depending upon what other math surrounds it. Another implementation specific feature of C is the order of bits in bit fields.  They can be assigned from most significant to least significant or vice-versa.  It is totally up to the compiler. As Allan Holub says C and  C++, in his book of the same name, gives the programmer "Enough Rope To Shoot Yourself in the Foot" On 8/15/2024 6:45 PM, Fred Cisin via cctalk wrote:

When I was teaching C, it was sometimes quite difficult to help students who had firm assumptions about things that you can'r assume. Such as the sequence of operations in the multiple iterations examples that we both used. I tried desperately to get them to do extensive commnets, and use typecasts even when they could have been left out.

On Thu, 15 Aug 2024, Mike Katz wrote: Advanced programming techniques don't help until they can actually successfully think about the problem. I had a guy working for me VERY briefly, with a UC Berkeley degree, but he couldn't figure out how to do 3-up mailing labels on a daisy wheel printer! (sequence not mattering becuse they were manually peele off and use for a mailing.) He couldn't figure out any way to do it other than needing a way to roll the paper back to get back to the top for the next column! not on THAT printer! (simple way - read three records into memory, print them side by side, and then advance the paper) He had a few other similar shortcomings. I let him stay around until he peeled and stuck all of the labels, and to give him time to find another job. I gave a final exam question on how to sort/sequence the records of a large file that was too big to fit into memory. Several students who had gotten their start at the university insisted that the only way it could be done was to add more memory. (simple way - read a memory sized block from the file and sort it; do that again, until you have a whole bunch of sorted shorter files, do a merge sort of those) Another: "A client has a large file that is in order. But each day/week/month, additional records are appended to it. What's the best sort algorithm to get the file back into order?" (simple 1: put the new records into a separate file, sort that; then do a merge sort between that and the main file. simple 2: (if it isn't too large to manage) a bubble sort, with each pass starting at the ENF of the file where the new records are, and working towards th beginning, or a "shaker sort" that alternates direction. The maximum nuber of passes is the number of records that were out of order. (a "shaker sort" is the best sort algorithm for taking advantage of any existing order, such as a few random records being in the wrong place) -- Grumpy Ol' Fred cisin(a)xenosoft.com

That is the reason for the stdint.h file.  Where you specify the width of the variable in bits int8_t, int16_t, uint16_t. etc. On 8/15/2024 8:39 PM, ben via cctalk wrote:

Ben, The purpose of the stdint.h file is to allow the programmer ti specify the size of the variables. On some systems is an int 32 bits or 64 bits (or even 16 bits on older systems or 16 bit micros).  The size of an int is not specifically defined in the C standard. Especially when doing embedded coding the size of a variable (or the size of the data pointed to by a pointer) is very important. The stdint.h file is created by the authors of the compiler so that the programmer can specify the size of the variable that he wants. /int A/ may or may not be 32 bits but /int32_t A/ will always be 32 bits. This is mostly not a problem on modern 32 bit microprocessors where an int is 32 bits  and a short is 16 bits. However, on that system is a long 32 bits or 64 bits?  By having the typedefs in the stdint.h file, the programmer can specify the exact size of the variable. On 8/16/2024 1:38 AM, ben wrote:

On Thu, 15 Aug 2024, Mike Katz wrote: I will readily concede that ANSI C has fewer problems with ambiguous code than the K&R C that I learned. But, for example, in: X = foo() + bar(); has it been defined which order the functions of foo() and bar() are evaluated? Consider the possibility that either or both alter variable that the other function also uses. (Stupidly simpe example, one function increments a variable, and the other one doubles it) As another example of code that I would avoid, int x=1,y=1; x = x++ + x++; y = ++y + ++Y; give 2, 3, 4, or 5? is heavily dependent on exactly when the increments get done. But, thorough careful typecasting, use of intermediate variables, etc. can eliminate all such problems. 'course "optimizing compilers" can (but shouldn't) alter your code. If you don't explicitly specify exactly what you want, "C gives you enough rope to shoot yourself in the foot" (as Holub titled one of his books) But, I've always loved how easily C will get out of the way when you want to get closer to the hardware. -- Grumpy Ol' Fred cisin(a)xenosoft.com

On 8/15/2024 3:41 PM, Sean Conner via cctalk wrote:

I'm pretty certain you are wrong about the byte case below. The C standard says something about no math will be done smaller than a short. I don't have it handy so can't quote exactly. But what that means is before the two bytes are added, they are promoted to short / uint16_t and then added. ... In this program segment: uint8_t a = 255; uint8_t b = 255; uint16_t c = 0; c = a + b; printf("c: %d \n", c); it will print 510 instead of the 254 that would result if it were added as bytes. Will Grownups never understand anything by themselves and it is tiresome for children to be always and forever explaining things to them, Antoine de Saint-Exupery in The Little Prince

On Thu, Aug 15, 2024 at 01:41:20PM -0600, ben via cctalk wrote: [...] This makes them a perfect match for a brain-dead language. But what does it even *mean* to "automaticaly promote smaller data types to larger ones"? That's a rhetorical question, because your answer will probably disagree with what the C standard actually says :) Widening of integers is normally done through left-extending the sign bit. For unsigned values, the sign bit is implicitly zero although we usually say "sign extend" or "zero extend" to be clearer about whether we're dealing with signed or unsigned values. C will typically do one or the other of these, but not always the one you expected. For sign-extension, m68k has the EXT instruction, and x86 has CBW/CWDE. For zero-extension, pre-clear the register before loading a smaller value into a subregister. From the 386 onwards, there are MOVZX/MOVSX which do load-and-extend in a single operation. If the result of a calculation is then truncated when written back to memory, then the upper bits of the register may have never had an effect on the result and did not need to be set to a known value, so this palaver is quite unnecessary. The thing was only extended in the first place because C's promotion rules required it to be, and the compiler backend has had to prove otherwise to eliminate it again. As it happens, it's not unnessary on modern out-of-order CPUs, so there's a lot more use of MOVZX etc on code compiled for x86-64. Loading into a subregister without clearing the full register first introduces a false dependency on the old value of the upper bits, resulting in a pipeline stall and performance hit. However, this is "just" for performance rather than correctness. Said performance hit is likely the main reason why x86-64 automatically zero-extends when loading a 32-bit value into a register, and so MOVZX is no longer required for that operation. So in fact x86 *does* "automaticaly promote smaller data types to larger ones". Not doing so would cause an unacceptable performance hit when running 32-bit code (which was basically all of it back in 2003 when the first Opteron was released) or 64-bit code making heavy use of 32-bit data. Now, what kind of badly-written code and/or braindead programming language would go out of its way to be inefficient and use 32-bit arithmetic instead of the native register width? I'm sure you can "C" where I'm going here. `int` is extremely special to it. C really wants to do everything with 32-bit values. Smaller values are widened, larger values are very grudgingly tolerated. C programmers habitually use `int` as array indices rather than `size_t`, particularly in `for` loops. Apparently everything is *still* a VAX. So on 64-bit platforms, the index needs to be widened before adding to the pointer, and there's so much terrible C code out there -- as if there is any other kind -- that the CPUs need hardware mitigations to defend against it. It's not just modern hardware which is a poor fit for C: classic hardware is too. Because of a lot of architectural assumptions in the C model, it is hard to generate efficient code for the 6502 or Z80, for example. But please, feel free to tell me how C is just fine and it's the CPUs which are at fault, even those which are heavily-optimised to run typical C code.

On Fri, Aug 16, 2024 at 04:00:40PM -0600, ben via cctalk wrote: [...] Google "N3096.PDF". You're welcome. [...] The GNU tools work fine for me for cross-compiling to bare-metal m68k. I use it on Unix systems, but you can probably get it working on Windows if you must. I even maintain a set of patches for GCC to do register parameters, although unless you specifically need that functionality, upstream GCC is just fine. [...] They'd have had to be fairly blinkered to not notice the S/360 series which had been around for years before the PDP-11 came out. It doesn't take a particularly large crystal ball to realise that computers got smaller and cheaper over time and features from larger machines such as wider registers would filter down into minicomputers and microcomputers. But C also seems to ignore a lot of the stuff we already knew in the 1960s about how to design languages to avoid programmers making various common mistakes, so those were quite large blinkers. They've never been taken off either: when Rob and Ken went to work for Google they came up with a "new" C-like language which makes many of the same mistakes, plus some new ones, and it is also more bloated and can't even be used to write bare-metal stuff which is one of the few things one might reasonably need C for in the first place. [...] That'd be the AT&T Hobbit, "optimized for running code compiled from the C programming language". It's basically an early RISC design which spent too much time in development and the released product was buggy, slow, expensive, and had some unconventional design decisions which would have scared off potential users. Had it come out earlier it may have had a chance, but then ARM came along and that was that. Complex subroutine nesting can be done just fine on a CPU "optimised for" running C. For example, you can synthesise an anonymous structure to hold pointers to or copies of the outer variables used in the inner function, and have the inner function take that as its first parameter. This is perfectly doable in C itself, but nobody would bother because it's a lot of error-prone boilerplate. But if the compiler does it automatically, it suddenly opens up a lot more design options which result in cleaner code. A "computer system" today is a network of multiple CPUs running autonomously, and are merely co-ordinated by the main CPU. Adding a faster disk to my system does not per se make the main CPU slower, although of course the improved performance means that the CPU load may go up purely because it is not being held back on I/O and can achieve higher throughput. Graphics cards are a very extreme form of moving things off the main CPU. They are special-purpose parallel CPUs which can number-crunch certain problems (such as making Tamriel beautiful) many orders of magnitude faster than the main CPU. And did I write "main CPU"? A typical PC today has four "main" CPUs on one die. There's even a network between those CPUs, and each CPU really does see the others as mere I/O devices onto which they can offload work. This is very much not the zero-sum game you imply. While general-purpose high-performance CPUs have rather uneven performance, the sheer brute force overcomes a lot of latency concerns. If I can perform a peak of 50 additions per nanosecond, but there are occasional microsecond-long stalls bringing the performance down to 90% of that, that's still more than good enough for general-purpose computing. If I need hard realtime performance with sub-microsecond accuracy, I've got a box of microcontrollers. A simple RISC CPU with a two-stage pipeline and zero wait state SRAM rather than a CPU cache, meaning all instructions have predictable timing, generally 1 or 2 cycles. Oh, and it is rated to go at up to 133MHz and costs €3 each in the retail version packaged up nicely on a PCB resembling a DIP40 chip and ready to plug into a breadboard, or $1 each if I'm buying the bare microcontrollers wholesale. In fact it contains *two* CPUs, although since they share the same RAM banks this can introduce contention which will affect execution time. There are two fixes for that problem: program it carefully such that contention does not happen, or just spend another dollar and add a second microcontroller. It can emulate that PDP-8 just fine, with exactly the same instruction timing, mostly because it can execute 100-200 instructions in 1.5 microseconds, so it'll spend much of its time twiddling its thumbs waiting for the next emulated clock tick. Twiddling its Thumb-2, in fact, so you have probably already worked out which microcontroller I'm referring to. That's venturing into the "premature optimisation" which Knuth warns about. In anything but the most trivial of systems, there are enough unknown unknowns that pontificating about what should be slow does not reliably deliver the correct answer, and just running the code and measuring it to see which parts are taking too long is a much more productive use of one's time.