Teongot

> To be cynical, there's probably a lot of corporate spin - Seagate is a HDD company after all.

applause

I'd love to see this combined with the author's fork()-less implementation of ps to make a (almost) fork()-free implementation of psDoom.

Seriously though, this is really cool

If you can get a suid root binary into the chroot, then you can control its configuration files to bypass security restrictions.

   $ ln /usr/bin/sudo ./my-chroot
   $ echo "$USER ALL=(ALL) NOPASSWD: ALL" > ./my-chroot/etc/sudoers.d/01-oops
   $ chroot ./my-chroot
   $ sudo bash

modern Linux distributions prevent creation of hard links to suid binaries, but the restrictions on chroot came years before that.

It so much that JITs became feasible, it's that bigger CPUs were less suitable for Jazelle's approach because of the behaviour of the in-order CPU pipeline.

Because Jazelle converted Java bytecodes into ARM instructions in sequence, there is no opportunity for any instruction scheduling. So a bytecode sequence like:

  // public static int get_x(int x, T a, T b) { return a.x+b.x; }
  aload_1
  getfield #N
  aload_2
  getfield #N
  iadd

would go down the pipeline as something like:

    LDR r1, [r0, #4]   // a_load1
  * LDR r1, [r1]       // getfield
    LDR r2, [r0, #8]   // aload_2
  * LDR r2, [r2]       // getfield
  * ADD r1, r1, r2     // iadd

There would be a pipeline stall before each instruction marked with a *.

On the first ARM 9 CPUs with Jazelle, the pipeline is fairly similar to the standard 5 stage RISC pipeline (Fetch-Decode-Execute-MemoryAccess-Writeback) so this stall would be 1 cycle. That wasn't too bad - you could just accept that loads took usally 2 cycles, and it would still be pretty fast.

However, on later CPUs with a longer pipeline the load-use delay was increased. By ARM11, it was 2 cycles - so now the CPU is spending more time waiting for pipeline stalls that it spends actually executing instructions.

In contrast, even a basic JIT can implement instruction scheduling and find some independent instructions to do between a load and the use of the result, which makes the JIT much more performant than Jazelle could be.

From the article

> When it started testing simulations of early Pentium prototypes, Intel discovered that a lot of game designers had found that they could shave one instruction off a hot loop by relying on a bug in the flag-setting behavior of Intel's 486 microprocessor. This bug had to be made part of the architecture: If the Pentium didn't run popular 486 games, customers would blame Intel, not the game authors.

Does anybody know the details of this?

Thumb-2 was internally codenamed Wrist. Because it's between ARM and Thumb

There's a good write up of it here https://social.treehouse.systems/@marcan/109917995005981968

An excellent bug report for a compiler would

* have reduced source code for the example, preferably a single source file, in a form which can be compiled

* have the exact command line used to build it

* have the exact compiler version being used

* apply to a supported version of the compiler (GCC 5 is from 2015...)

* include an accurate explanation of what is wrong with the generated code

Maybe the last one is covered by this blog post, but things like

> I can maybe understand the subtraction of constant 0, if there’s another code path that jumps to 7ba6

suggests that the author hasn't fully analysed the generated code.

The analysis is OK though and with source code it would be a pretty good bug report.

What was the origin of the idea that the Unix philosophy is "do one thing and do it well"?

If anything, the UNIX philosophy is more like "do one thing, and do it to a text file".

> Isn't it surprising that modulo arithmetic, as already employed successfully in TCP sequence numbers and the like, still seems to be incorrectly implemented today

Even in TCP sequence numbers, it can be implemented incorrectly.

https://engineering.skroutz.gr/blog/uncovering-a-24-year-old...

Because "don't" is easier to read than 'don\'t'

Arm's marketing department doesn't consider it an abbreviation any more.

The progression of the Arm brand goes something like this:

* ARM (abbreviation for Advanced RISC Machines)

* ARM (not an abbreviation for anything, but looks like one)

* Arm (current name, still not an abbreviation, now looks like a word)

* arm (what the current logo looks like, even though the company name has a capital letter)

I find Samsung much more reliable than Sandisk in my pis

The corollary to that is, of course, that any technology which is distinguishable from magic is insufficiently advanced

Your book is set in racist times and appears to be about a racist protagonist. If you aren't careful you can allow those sentiments to propagate into the overall message of the novel.

Try to be less defensive, the editor has taken the time to give you feedback - you can take the opportunity to learn why he might have interpreted your work in that way. Even if not every reader does, you now know that some readers do.

If all the companies doing custom AArch64 microarchitectures had spent the effort building systems around ARM's designs instead, we'd probably have a thriving ARM server ecosystem by now.

Neoverse-N2 will have SVE2 (source https://github.com/gcc-mirror/gcc/blob/master/gcc/config/aar... )

There's a tidy mathematical progression in Apple CPU architectures.

6502 (Apple 1,2,3): 1976

68k (Mac): 1984 (+8 years)

PPC: 1994 (+10 years)

x86: 2006 (+12 years)

ARM: 2020 (+14 years)

If the trend continues, we will see Apple's next architecture in 2036.

The cost of simulating 32-bit ARM on 64-bit ARM is nothing like 10x if you try hard enough

https://www.research.manchester.ac.uk/portal/files/56078084/...