> rav1d is transpiled c-to-rust version of dav1d

Sounds like a bad way to port. Completely different languages. It took me some time to learn that one cannot simply write C code in Rust and expect the result to be any good. Should've started from scratch.

It's more likely they will end up shotgunning sloppy AI PRs.

... in the way of writing code with undefined behaviour. "You don't tell me how to live! Maybe I want to shoot myself in the foot sometimes! I already shot myself in the head, and it was awesome, instantly made me an old fart that refuses to learn. Ignorance is bliss!"

I've used the 2013 algorithm, it's fast, simple enough and easy to implement in Rust.

I wonder what's the point. 8 bits is not enough to store most values for most applications, it's bad for timers and multiplication, it's just a big waste of CPU cycles in general. The more work CPU has to do, the less time it spends sleeping, which is bad for battery-powered embedded devices. Perhaps, it has its place somewhere, but realistically, an 8-bit CPU these days is very niche at best. Imho, it's not going to take off in mainstream embedded.

Personally I'm a fan of AVR-8 which has 32 8-bit registers so if you want to do 16-bit or 24-bit or 32-bit or 40-bit math you can do it just fine, it just takes longer. The biggest AVR-8 device has about 8k of RAM and about 240k of rewritable program ROM. Those are on different buses so it can suck down an instruction at the same time it transfers data, and clocked at 16 MHz it beats the pants off any of the 8-bit micros of 1980.

You're not going to create really large systems for it, but if you want to work a gas pump or a hot water heater or make a tester for 74xx chips or a display controller for persistence of vision displays it is great.

You can code for it in C but I feel like I'm strangling puppies when I do it because it is moving the stack pointer around and doing things to support C calling conventions that I don't really need for the programs I write [1] AVR-8 assembly is fun but I still write C for it because if I need a bigger device I can recompile it for ESP32 or ARM.

Something weird about AVR-8 is that it does not have a unified address space, so in the case of that display controller, it is easy to spool graphic data out of the ROM, not so easy to upload a small amount into RAM (via serial port) and combine that with data from the ROM. I've had the crazy idea of making a AVR-8 on AVR-8 emulator (would get me to A-rank if not S-rank on AVR-8 assembly) which would make it possible to upload tiny programs into RAM but that probably requires software emulation of unified pointers for program memory.

[1] https://betterembsw.blogspot.com/2014/07/dont-overflow-stack...

I've looked at F8's ISA reference and it has lots of instructions to support 16-bit numbers, including all the basic arithmetic and bitwise operations, plus loads/stores/pushes and pops. It's almost a 16-bit ISA, actually.

Which is just bizarre since, again, we have 8086, we have MSP430. And if you are fine with most of your data being 8-bit (which is not that uncommon), there is e.g. 8051 which is still quite popular.

This seems to be meant as pretty much 8051 replacement. 8051 cores are duct-tape of the modern computing and in almost anything, while 8051 is not exactly C-friendly architecture.

OTH 8-bit floating point types are so hot right now in the GPU world:

https://developer.nvidia.com/blog/nvidia-arm-and-intel-publi...

Also, a simple 8-bit CPU like the 6502 is just 3.5k transistors while simple 16-bit CPUs like the x86 or 68k are somewhere between 30k and 70k transitors (e.g. I wonder if a 6502 running at full throttle still requires less energy than an x86 or 68k doing the same work in the same time).

A minimal 16 bit system is something like a XAP [0] at 3,000 transistors. Incidentally, also a terrible architecture to program for.

I don't think any "real" x86 processor from the 286 onwards had under 100k transistors.

[0] https://en.wikipedia.org/wiki/XAP_processor

It's a 9 billion market, projected to grow at 5-6% per year.

And flipping/storing more bits also use more power, it is a trade off.

I haven't use these in a long time but fairly certain the memory address is more like 16 bit (otherwise, yeah how could you do anything). Still with 8 bit instructions many ops require several instructions. If that doesn't matter and it needs to be super cheap / small / etc., I think that is why these exist.

One day I needed to parse and generate RISC-V instructions. I wrote a custom bitfield implementation, nothing fancy: no derive macros or any crap like that, only u32 bitfields specified by an array — [(RangeInclusive<u32> /src/, usize /length/, RangeInclusive<u32> /dst/]. One function + a bunch of tests. It worked great. Then I tried the `bitfield` crate, which claims to be as fast as code I would've written by hand. It had dependencies and was two orders of magnitude slower. Basically, it was as fast as code that I would've written by hand in Python.

At least, we can assume that after a few weeks, he became not quite that depressed.

Why it's always the borrow checker that bugs the haters? You don't even see it work most of the time, because instead of using references everywhere, like most C++ers are conditioned to do, not only you can move values (doesn't necessarily mean actually performing memory operations), but also the compiler checks that you don't use the variable from which the value has been moved. And even if you do use references everywhere, they don't usually cause any problems, unless you decide to put more than one reference in a often used struct. I often use both shared (RO) and exclusive (RW) references as function arguments and rarely have to specify lifetimes manually, because automatic lifetime elision done by the compiler is sufficient in most cases.

Who said I’m a hater? That was a very aggressive response. All I said is that I think Rust is not a good language for a scripting system. In scripting, I’m not always writing something “correct”, but good enough. Mutability everywhere helps do so, but the borrow checker gets in the way of that.

Exactly the same experience : my toy compiler project has 10477 lines of Rust code, and there is only one line with unsafe:

  let is_tty = unsafe { libc::isatty(libc::STDERR_FILENO) } != 0; 

Here's the source, just in case: https://github.com/burjui/rambo/

In fact, there are exactly two "unsafe" blocks in all of my Rust projects, and the second one is not even needed anymore because of the language and ecosystem improvements, but the project is basically abandoned, so I'm probably not gonna fix it. There's just no need for unsafe in the vast majority of code.

I don't know where Rust critics get their statistics; probably from picking their noses, judging by their arguments. Most don't seem to even have read the official docs, the bare minimum required to form any conclusions at all about the language. I guess they don't read much Rust code and think there is no way we can write even semi-decently performing high-level code without resorting to unsafe hacks or calling C, because that's the way it's done in other languages.

It's literally THE unsafe part of the code. It's the only part of code that can invoke UB.

  fn do_something() {
      unsafe { ... }
  }

  // Somewhere in the program
  do_something();

Doesn't matter where "do_something" is used and how much. The only possibly problematic part of this code is the unsafe block. You only audit it.