The original GameBoy had a hardware LFSR that could be used to generate white-noise-like sounds. It was often used for "whooshing" effects and also cymbal sounds, such as in the famous Super Mario Land theme: https://www.youtube.com/watch?v=Gb33Qnbw520
FizzleFade
61–70 of 182 posts
Re: FizzleFade
#62I have the feeling that knowledge about bits is lacking by a lot of younger coders. And I also think this is what causes bloatware. CPUs are powerful enough to use a naive fade transition. But coders who are aware of the internal workings can make it even faster on todays hardware. Great article and imho still relevant on todays much more powerful computers.
Why? I mean if you look at the majority of work that programmers do today - frontend/backend web development and apps, there is no need to have knowledge about bits. In fact, if I see someone using binary operators in languages such as Java,JS,Ruby etc... I'll immediately consider it bad code, regardless of context - it's just not the right tool for the level of abstraction in these languages. The fact is that in the…
> using binary operators [...] bad code, regardless of context
> the performance profile is dominated by bad algorithms, wrong data structures
Do you know how you often implement good algorithms and data structures? You wouldn't implement a bloom filter as a high level array of 1/0 integers, would you?
Re: FizzleFade
#63Earlier quoted context omitted.
Recently, I started helping out data engineering teams improve performance of their big data processing pipelines. Man, was I shocked. Very smart, highly educated, mid-level and even senior software engineers seem to know very little about bits these days. When they'd run into a memory issue, their natural response was to just spin up a few more servers and throw another terabyte of memory at the problem. Makes sense…
And did knowledge of bits help solve the memory issue?
I've done stuff where memory usage shrank from 30-60GB to under 2GB, and load times went from many minutes to essentially instant (mmap on the bits Vs needing to build objects).
Re: FizzleFade
#64Earlier quoted context omitted.
> I have the feeling that knowledge > about bits is lacking by a lot of > younger coders. And I also think > this is what causes bloatware From a management perspective, I wonder if people find older developers miss obvious solutions that involve throwing small amounts of money and/or hardware at business problems, and instead turn to "clever" solutions that are costly in terms of extra developer time needed for deve…
Managers often think throwing more hardware at the problem will fix things. But hardware scales sub-linearly. Solving the actual underlying problems can easily get you exponential payoffs. Anecdote: One of my managers once spent €70000¹ worth of hardware to speed up an application because he believed it would be cheaper than to optimize the code. Naturally, no-one had done any kind of performance analysis, so while t…
> Managers often think throwing more
> hardware at the problem will fix things
> no-one had done any kind of performance
> analysis
Re: FizzleFade
#65Earlier quoted context omitted.
So many simple things are only easy if you know bits. Interpreting a packet capture, poking at memory, designing cache friendly data structures, ... It is like second nature to me. If it isn't required (obviously it isn't, it must at least be a strong competitive advantage). I am not that old. I don't have get off my lawn moments. I grew up (really learned at least) on a processor (P133) where bits started mattering…
What are some good resources to learn about bits?
There are some quite good pages, I don't remember the exact titles, but the first results are quite ok:
https://www.google.de/search?q=bit%20hacks
Re: FizzleFade
#66Earlier quoted context omitted.
I'm a low-level programmer and it's the first time I come across the linear-feedback shift register. I would say it's rather a part of digital circuits design. Now, when FPGAs become more and more popular, people will be forced to learn VHDL languages and then different lesser-known techniques will surface. (It's a naive prediction, I know.)
>Now, when FPGAs become more and more popular, people will be forced to learn VHDL languages and then different lesser-known techniques will surface. Isn't that already part of a normal CS degree? We needed to learn VHDL to program a Atmel ATTiny for class.
Are you sure you learnt VHDL? As I understood it, the ATTiny isn't an FPGA but an 8-bit microcontroller.
Learning some form of assembly language at university is (probably) reasonably common.
Learning VHDL (for programming FPGAs) is less common - I did for my Computer Science degree, but this was about 15 years ago, so I don't know if it's still common.
Re: FizzleFade
#67Note that you can (quite obviously) use this to fade from one image to an other by writing the color of the next image instead of just "red".
Re: FizzleFade
#68I have the feeling that knowledge about bits is lacking by a lot of younger coders. And I also think this is what causes bloatware. CPUs are powerful enough to use a naive fade transition. But coders who are aware of the internal workings can make it even faster on todays hardware. Great article and imho still relevant on todays much more powerful computers.
Why? I mean if you look at the majority of work that programmers do today - frontend/backend web development and apps, there is no need to have knowledge about bits. In fact, if I see someone using binary operators in languages such as Java,JS,Ruby etc... I'll immediately consider it bad code, regardless of context - it's just not the right tool for the level of abstraction in these languages. The fact is that in the…
> In fact, if I see someone using binary operators in languages such as Java,JS,Ruby etc... I'll immediately consider it bad code, regardless of context - it's just not the right tool for the level of abstraction in these languages.
Clojure is written in java (and clojure). It uses bit operations to implement Software Transactional Memory and persistent collections. Is it a bad code?
You seem to think a programmer should always code on the same level of abstraction. I'd argue in many applications often you find no suitable abstraction, and have to implement it yourself.
Also linear feedback shift registers can be used without any knowledge about bits other than the fact that integers loop over when they reach maximum value (and every programmer should know that anyways). And these registers are useful for some very nice algorithms (like in-place pseudorandom permutations' generators - for example for shuffling songs in a media player, or for some ai algorithms).
Re: FizzleFade
#69I have the feeling that knowledge about bits is lacking by a lot of younger coders. And I also think this is what causes bloatware. CPUs are powerful enough to use a naive fade transition. But coders who are aware of the internal workings can make it even faster on todays hardware. Great article and imho still relevant on todays much more powerful computers.
> I have the feeling that knowledge > about bits is lacking by a lot of > younger coders. And I also think > this is what causes bloatware From a management perspective, I wonder if people find older developers miss obvious solutions that involve throwing small amounts of money and/or hardware at business problems, and instead turn to "clever" solutions that are costly in terms of extra developer time needed for deve…
[deleted]
Re: FizzleFade
#70> asm mov ax ,[ WORD PTR rndval ]
> asm mov dx ,[ WORD PTR rndval +2]
> asm mov bx , ax
> asm dec bl
> asm mov [ BYTE PTR y ], bl // low 8 bits - 1 = y
> asm mov bx , ax
> asm mov cx , dx
> asm mov [ BYTE PTR x ], ah // next 9 bits = x
> asm mov [ BYTE PTR x +1] , dl
I don't understand the need for the second asm mov bx , ax : BX is not used afterwards. Same for CX, it is never used.
> uint32_t rndval = 1;
> uint16_t x,y;
> do
> {
> y = rndval & 0x00F; // Y = low 8 bits
> x = rndval & 0x1F0; // X = High 9 bits
Er... no, if you do that, you only get the lowest 4 bits in y, and then you only get 5 bits in x (and not the right ones, of course).
It should be:
y = rndval & 0x000000FF; // Y = low 8 bits
x = rndval & 0x0001FF00; // X = bits 8 to... 16 > 15, irk
x = rndval >> 8; // X = bits 8 to 17, in their right place