Fixed variable storage

[HughBanton]

I recently wondered how 'fixed' variables are stored in assembler, and if they involve ram access or not. Maybe someone can offer some insight...

I'm thinking of the situation where in DSP I write e.g ( x>336 ) ... When converted to assem it allocates a float, gives it a name, such as 'F_336', and makes F_336 = 336. And somewhere there will be cmpps xmm0, F_336, etc. etc.

But presumably I could equally write cmpps xmm0, 336, etc. ; without involving the variable.

Doing that, does that save the extra overhead of a ram access to a stored varable, or does assem make it work the same either way?

One of those many things I muse over

[trogluddite]

Yes, you're exactly right about the memory access. DSP "constants" are stored and accessed in exactly the same way as variables (the only exceptions that I can think of are the values for hopping and loop counts, which are always hard-coded).

Unfortunately, however, it's not usually possible to replace this with hard-coded values in ASM - because there aren't ASM instructions for doing it! This might seem strange, given that such instructions would seem equivalent at first glance. However, to the CPU, assembly instructions which read from memory, those which use registers (e.g the "xmms"), and those which use hard-coded values are completely distinct from each other, as they use different logic circuits on the chip. Any similarity of naming is purely to help coders remember that they do similar things (within the program-memory/CPU, they don't even have names, they're each represented by a number).

Unfortunately, the four-channel SSE instruction set that we mostly use in DSP/ASM doesn't include many opcodes which can use hard-coded values - presumably because of the need to always have "four channel wide" values, which might make the number of bytes per-instruction longer than the CPU's circuitry can handle (i.e. it's determined by hardware limitations of the CPU chip, not by software.)

But is this less efficient? After all, values are always going to have to be read from somewhere in memory. But yes, there will be a penalty, because hard-coded values are right there in the list of program instructions, whereas when a variable is used, the "right there" value is just a memory address in some other random place, which then has to be looked up.

There are sometimes little tricks which can be used to avoid this. For example, an xmm register can be made zero on all channels by subtracting it from itself (so long as it's a valid number, not a NaN!), or (more safely) by bit-shifting it far enough for all the bits to "drop off the end" (e.g. in ASM; "pslld xmm0, 32"). However, most of the time, there's no choice other than to use a variable.

[HughBanton]

Most enlightening; many thanks once again trog.

It's sometimes easy to imagine that once any program is running in a PC its cpu immediately 'knows' everything it has to do! I well know that the reality is entirely different, and that the cpu is constantly being fed instruction after instruction after instruction, and that the entireity of that is ultimately coming from Ram. Plus all the to-ing and fro-ing of all the data it's dealing with.

Positively mindblowing when you consider the rate it achieves all of this (But never quite fast enough, hoho ... )

Anyway, today I'm finally back in the organ loft again, I can get on to the ideas I was looking at last week

Cheers.

[trogluddite]

It's sometimes easy to imagine that once any program is running in a PC its cpu immediately 'knows' everything it has to do! I well know that the reality is entirely different

I can't help but think of that very old programmers' joke: Never anthropomorphise computers... - they hate it when you do that!

I remember reading years ago about some research into why otherwise top-performing computer-science students often found learning to write code very difficult (it's a common meme among professional coders that computer-science theoreticians can't write code for toffee.) The conclusion was much as you described - the poor coders were those who couldn't quite let go of the "theory of mind" that's sub-consciously involved in most human interactions. My own experience of mentoring novices suggests the same thing, and it seems to be a distinct ability, quite separate from a person's intelligence - and possibly the most fundamental principle of coding.

This may not be a new phenomenon. It's said that when Charles Babbage was applying to the UK Parliament for R&D funding for his mechanical calculating engines (mid 19th century), he was asked in all seriousness by the politicians whether the machines would be able to produce the correct answer if they were fed erroneous input data! And that was long before Robbie the Robot, C3PO, HAL, Lt-Cdr. Data, and their friends made the "thinking machine" trope so ubiquitous!

Positively mindblowing when you consider the rate it achieves all of this (But never quite fast enough, hoho ... )

Whenever I get frustrated with my PC's performance, I fire up an emulator for one of the 1980's 8-bit kilo-byte BASIC machines that I started out on - it reminds me how greedy I've become since my "tween-age" years!

[tulamide]

Positively mindblowing when you consider the rate it achieves all of this

This reminds me of the pre-internet era as we know it now. Back in the 90s I was working for a big media company, and we needed a stable and fast connection from the central office in Hamburg to a branch office in New York. We already had established a few laserlink connections between several offices in Hamburg. And so we came up with a final setting of a pumped up laserlink (reducing bitrate, but getting further) directed at a satellite (and the same on the New York end). Remember, that was the time where modems still were a thing!

Then we did the first test. Our Unix server sent a ping (a short data packet with a timestamp, that's received and then automatically sent back) to the server in New York. When it arrived back at our server it had travelled 13,000 km in total and did it in 3 ms. I just sat there stunned and slowly realized that I'm about to witness a whole new era of communication.

Of course, a generation born around 2000 won't be able to feel the amazement, but I take pride in having been among the pioneers that made possible, what today is considered normal.

[Spogg]

Great story tulamide!

I remember as a child watching the first satellite TV broadcast from the USA. 405 lines monochrome (naturally) and dreadful quality.
This was a Big Thing at the time but I had no idea of where this would go. In fact I thought “Well, that’s pretty rubbish”.

Cheers

Spogg

[Duckett]

I can't claim to remember the days of Altair 8800 home kits, but I do remember when seeing TI BASIC READY on my TV at home was exciting stuff..

[deraudrl]

Whenever I get frustrated with my PC's performance, I fire up an emulator for one of the 1980's 8-bit kilo-byte BASIC machines that I started out on - it reminds me how greedy I've become since my "tween-age" years!

I spent several years working with what was then a state-of-the-art array processor. It was optimized for FFTs and FIR filters: did two multiplies and a three-way add every cycle. But the multiply was 16x16-bit fixed-point and the add was 32-bit fixed-point, and a cycle was 100ns (10MHz). So a 1024-point complex FFT took just a tick over a millisecond...which my current PC does in about 20ns...in double-precision floating-point.

In a way it's a bit depressing how hard we worked in those days to get the required processing out of that box.

[tulamide]

Whenever I get frustrated with my PC's performance, I fire up an emulator for one of the 1980's 8-bit kilo-byte BASIC machines that I started out on - it reminds me how greedy I've become since my "tween-age" years!

I spent several years working with what was then a state-of-the-art array processor. It was optimized for FFTs and FIR filters: did two multiplies and a three-way add every cycle. But the multiply was 16x16-bit fixed-point and the add was 32-bit fixed-point, and a cycle was 100ns (10MHz). So a 1024-point complex FFT took just a tick over a millisecond...which my current PC does in about 20ns...in double-precision floating-point.

In a way it's a bit depressing how hard we worked in those days to get the required processing out of that box.

I started with BASIC on a Commodore PET. I remember having been so proud of my first horse race game. What sounds so impressive, was on a tiny green/black monitor that could only display letters, and you could bet on a horse, then you saw letters in several rows moving from left to right, controlled by prng. The first letter to arrive on the right was the winner. Whenever I bet on the right "horse", I had a big smile on my face! Those were the times.

Later on the Atari 520 I already was using a function-driven basic (way ahead of its time, but forgot the name), but learned to save on RAM (using nibbles instead of bytes and bitmasks and such weird stuff) to realize a full-featured 3-track "Tracker", that used the in-built OSCs to create the sounds. 3 mono tracks of realtime processed sounds! Who would even spend a second on something like that today?

Very early I was into 3D-imagery. I used the then barely known Cinema 4D on a Mac in 1996. I created scenes with its software graphic engine (no 3D cards for the consumer market existed back then), and weeks later, when finished, I rendered it to a picture, using Cinema 4Ds remarkable raytracing engine. Usually the rendering of a 1280x960 image took about 50 to 70 hours! Nowadays the first steps of integrating at least a bit of light and shadow raytracing into realtime graphics running at 60 fps have been taken (NVidia's RTX cards), and the same image rendered nowadays with Cinema 4D at the same settings would take just a few seconds.

But I wouldn't want to miss any of these experiences. I consider my generation as the driving force for what is available today. The kids playing Gears 4 on a 144 Hz gaming monitor sync'd to a high performance raytracing graphics card with 7.2 surround sound and interactive music owe this to nerds like us.

[trogluddite]

In a way it's a bit depressing how hard we worked in those days to get the required processing out of that box.

I must admit, I still feel a slight sense of "cheating" whenever I'm using high-level languages, and I think that's partly where my obsession with delving under the hood of the platforms I use comes from - I'm never quite satisfied unless I have some idea what's going on at the CPU level.

Coincidentally, only a few years back in my last job, I worked with a colleague on some fixed-point FFT routines. The company I was working for made flowchart-based software for microcontroller programming; everything from ARMs down to the most basic of 8-bit PICs. So there are still a few little pockets, even in the commercial world, where that kind of optimisation is still done; which I find oddly pleasing.

Usually the rendering of a 1280x960 image took about 50 to 70 hours!

That brings back memories for me. It was fractals that were my imagery obsession, and I'd quite often be on the computer before breakfast to set a Mandelbrot Set render running during the school-day. I can remember getting rather cross one day because my Mum had unplugged the computer while I was at school so that she could plug in the vaccum cleaner! (to be fair, I'd turned the screen (i.e. TV) off, so there wasn't any way for her to know that the computer was still running.)

But I wouldn't want to miss any of these experiences. I consider my generation as the driving force for what is available today.

Likewise. I can't say that I contributed anything of any value myself, but I have no doubt that having that generation who had computers at home from a young age, but were forced to understand things at a machine level just to get anything useful done at all, has made a huge difference to the technology that we have available to us now.