|
Re: storage; it's "one variable".
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
Well,
Gerry Schmitz wrote: In some cases, their loop variable is an int; in others a short; in others a long. Modern compilers will promote those loop variables to 32/64 bit depending on target architecture. If you are looking at old code... there were reasons to use integer BOOL for performance and 8 bit bool for smaller code-size many years ago. Optimizing compilers today make most of that pointless.
I am finally getting around to reviewing that json library @code-witch keeps obsessing over. First thing I noticed was the liberal use of bool. But in the end... it does't really matter the compiler should promote some of these.
Best Wishes,
-David Delaune
|
|
|
|
|
I expect promotion. The reason I use things like bytes and half words is so they fit better on 8bit. I am expecting a lot out of it in terms optimization on a 32 or 64 bit machine. My code favors 8bit it as a result
Real programmers use butterflies
|
|
|
|
|
Oh Well,
I wish you would have commented sooner. I found a bug in your json parser but didn't want to tarnish your article comment section.
Let me know if you want to discuss it here and I'll go over and delete it.
|
|
|
|
|
I'm about to fix it. I was at sister's yesterday so I couldn't.
Real programmers use butterflies
|
|
|
|
|
I have the whole application up and running and have gone through all the code and docs.
They use random access binary files containing millions of doubles.
Storage is / was not a problem.
I thought it was an interesting mental exercise in light of some of the "performance" discussions going on.
Nothing more. We can all stop "thinking" now.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
Working in industrial sector... there are still devices that struggle with memory and therefore I use BYTES for counters when I can, same for the states machine controller variable...
So for me it's a yes.
|
|
|
|
|
I worked with PLC's, etc.
Never had to sweat 1 or 2 bytes; getting the storage architecture right was more important.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
Lucky you.
If I choose the material to be used I never have to... but when the customer gives me the material then everything can happen.
|
|
|
|
|
The customer ordered it, the hardware company built it, I had to program it (contract). There were no choices.
The hardware company used my software to debug their firmware. (Only way to avoid finger pointing).
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
I'm glad you've been so lucky.
Congratulations.
|
|
|
|
|
I have always preferred the 2 bytes distribution for variables (WORD or INT) due to the endian changes, it is already painful enough to deal with it without having to increase the difficulty messing with more than a variable in the "same space"
On the other hand, when staying in the PLC I have used a lot of BYTE variables. Specially when grouping bits to be masked or moved from one place to another.
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Depends on the processor: a lot of NASA stuff was for seriously old processors - for example the US military did use some Z80 based stuff right up to the end of the century, so it's possible NASA did as well.
And like many other processors of it's age, the Z80 had eight bit and sixteen bit registers: a "tight loop" could optimise to a DJNZ operation (using an 8 bit register) or an LDI / LDD / LDIR / LDDR (using sixteen bit). If your loop needed a 32 bit integer, then machine code got a lot more complex.
So variable size choice could easily have a bit effect on performance - and given the old processors ran as speed we would consider unacceptable for a digital watch these days every little helped!
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
It was ported from Fortran to C in 1993; not exactly the dark ages.
"High performance" update (double doubles) around 2013.
JPL Planetary and Lunar Ephemerides
(This whole thing started because I made a solar calendar and said it was "accurate"; which begged the question "how accurate", etc. Anyway, I do a lot of calcs in real-time for a simulation; ergo...)
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
Only when targeting (a) an extremely memory-limited system, or (b) a 16-bit or less processor.
(a) may be the case with industrial controllers or the first stage of a bool loader (it is an advantage if the code can run in the processor's internal memory)
(b) may be the case for some embedded devices
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Yes. My first job was an IBM installation. Little signboards around the office, and all they said was "Think". One of the few joys left in life when you can.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
More so now because of winter my legs are shockingly white.
I'm not sure how many cookies it makes to be happy, but so far it's not 27.
JaxCoder.com
|
|
|
|
|
It depends on the target environment. I work on HPC stuff using CUDA and GPUs and with them using a short instead of an int can make a significant difference in performance and Nvidia includes this point in their documentation. With CUDA, using an signed value is almost always preferred over an unsigned value for performance reasons also. They have quite a number of odd, little quirks regarding optimal performance. For standard desktop CPUs I rarely concern myself with that issue. The only other environment I work in these days is embedded code in scanning cameras and I don't care there either.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
This morning I took my dog out for a romp. it was -18 out.
I remembered how I used to wear shorts at the same time of day in the summer.
|
|
|
|
|
original Apollo 11 guidance computer was 16bit
someone said this was a rework from FORTRAN to C
maybe this is indeed for 16bit hardware
|
|
|
|
|
NASA spacecraft still run on 286 instruction sets, so it would depend on where the code is being run. Space center code would be a different architecture.
EDIT: PowerPC
modified 31-Dec-20 9:29am.
|
|
|
|
|
I don't, I just grab the first pair out of the drawer.
Oh, shorts, Keystone cops? Pink Panther?
--NASA they could be using an 8 bit CPU. More likely a 16 bit, but probably not something that's not 16 bit word directly addressable. Shorts may be faster access. When and for what was the code written?
|
|
|
|
|
Quote: In some cases, their loop variable is an int; in others a short; in others a long.
Given a choice which is best?
Use a size_t, unless you have a specific reason that needs negative numbers. The reason is because the compiler can warn you if you are writing a loop that may never terminate (checking for <=0 zero, for example).
For fast execution reasons, use unsigned int or int as they are guaranteed to be the natural word size of the platform.
For space reasons using 8 bit and 16 bit integers make sense, but don't use 'short' or 'long' etc, they are not guaranteed to have any specific width. If you need a specific bit width use uint8_t/int8_t/int_least8_t/uint_least8_t and their 16, 32 and 64 counterparts.
Using 'short' and writing code that assumes it is 16-bit or using 'int' and writing code that operates on it as a 32 bit integer is guaranteed to break on some platform; those are latent bugs because overflows are undefined behaviour and the compiler is allowed to generate code that crashes when you overflow a signed integer type (yes, that's happened to me on at least one ARM platform when compiled with clang and -O3).
In general, avoid using bare int/short/long long/long because the compiler cannot warn you if you are writing bugs.
|
|
|
|
|
In the old days we had to worry about every byte of memory and every tick of the clock, but with modern computers, it goes without saying that memory and speed are rarely limiting, unless: you were looping objects or something large, or you were designing a real-time app like a missile-tracking system. Some coders opt for 'better performance' even when it actually makes no significant difference, simply because they can.
|
|
|
|
|
Stop being bullied by this Johnny-Come-Lately Event[^] !
🎉 🕰 🎉
Ravings en masse^ |
---|
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|