Hacker News Reader

Comment by sroussey | Hacker News Reader

Why stop there? Move the ALU to the RAM

There are some proposals of that form: basically if you have a RAM interface that can support commands like "fill this range of memory with this pattern" or "add this constant to all values in this range" it can help speed up a decent amount of code, but also drastically reduce power consumption, as the memory interface is a pretty significant source of power drain on mobile systems. It does significantly complicate the interfaces involved, though, so it would require a lot of effort to implement.

https://www.tomshardware.com/tech-industry/neo-semiconductor...

There's already an x86-64 extension for this: RAO-INT (remote atomics).

We've been doing the reverse and bringing the RAM to the ALU.

This has been tried. I think the IBM System/360 could do arithmetic directly in RAM.

err, any refs for that? I really doubt it but could well be wrong. I'm not aware of any mainstream arch that can/could do that, that I can think of.

At least the IBM System/370 (not 360 as I said above) had assembly instructions that took memory addresses directly without a register or immediate being in the instruction.

Here is an example of such an instruction from the

"AP, Add Packed (Decimal) The data string located at the storage address specified by operand-2 (b2+d2) is added to the data string located at the storage address specified by operand-1 (b1+d1). Operand-2 remains unchanged."

http://www.simotime.com/asmins01.htm#AP

Now, how this was actually done in hardware I don't know, but I would not be surprised if hidden registers were involved. So, maybe this is not really an example that fits the original premise of this subthread, but I think it is interesting nevertheless.

Reply on news.ycombinator.com