Ronald Guilmet on 3 Jan 2018 11:11:28 -0800


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PLUG] The mysterious case of the Linux Page Table Isolation patches


That makes sense. I studied Assembly a long time ago, and I think it was the RISC approach:

Stanford has a page on it.

http://cs.stanford.edu/people/eroberts/courses/soco/projects/risc/risccisc/

Ron

On 1/3/2018 2:00 PM, Rich Freeman wrote:
On Wed, Jan 3, 2018 at 1:37 PM, Ronald Guilmet <ronpguilmet@gmail.com> wrote:
My first thought was that hardware is cheap today. I think CISC has shorting
instructions, but uses more memory. When the hardware (RAM) was the cost of
a car, they pushed the software to take some of the burden, right?

Well, the original driver was hand-written assembly, which is way
easier to do with CISC.  This is valid on x86: mov edx, [esi+4*ebx].
That is obviously pretty useful if you're working with an array, but
obviously it is a bunch of work for the processor to handle every one
of those indexing modes, especially since it means that MOV
instruction has 14 different opcodes, and I couldn't even quickly find
anything on line that indicates how the instruction sizes vary.
Granted, to the degree that different opcodes are used to the CPU
they're really different instructions.

Oh, and I found this gem:
https://www.cl.cam.ac.uk/~sd601/papers/mov.pdf

And this even bigger gem:
https://github.com/xoreaxeaxeax/movfuscator

Seriously, thanks for this thread because that last link made my whole day.

Maybe memory or memory bandwidth was a benefit, but I have to wonder
how much was lost in inefficiencies with the cache/etc since
instruction size is variable.


___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug