Coldfire | Golang malware development library | Dataset library

My guess was wrong. Modern x86 microarchitectures really are different in this way from some (most?) other ISAs.

There can be a penalty for cached narrow stores even on high-performance non-x86 CPUs. The reduction in cache footprint can still make int8_t arrays worth using, though. (And on some ISAs like MIPS, not needing to scale an index for an addressing mode helps).

Merging / coalescing in the store buffer between byte stores instructions to the same word before actual commit to L1d can also reduce or remove the penalty. (x86 sometimes can't do as much of this because its strong memory model requires all stores to commit in program order.)

ARM's documentation for Cortex-A15 MPCore (from ~2012) says it uses 32-bit ECC granularity in L1d, and does in fact do a word-RMW for narrow stores to update the data.

The L1 data cache supports optional single bit correct and double bit detect error correction logic in both the tag and data arrays. The ECC granularity for the tag array is the tag for a single cache line and the ECC granularity for the data array is a 32-bit word.

Because of the ECC granularity in the data array, a write to the array cannot update a portion of a 4-byte aligned memory location because there is not enough information to calculate the new ECC value. This is the case for any store instruction that does not write one or more aligned 4-byte regions of memory. In this case, the L1 data memory system reads the existing data in the cache, merges in the modified bytes, and calculates the ECC from the merged value. The L1 memory system attempts to merge multiple stores together to meet the aligned 4-byte ECC granularity and to avoid the read-modify-write requirement.

(When they say "the L1 memory system", I think they mean the store buffer, if you have contiguous byte stores that haven't yet committed to L1d.)

Note that the RMW is atomic, and only involves the exclusively-owned cache line being modified. This is an implementation detail that doesn't affect the memory model. So my conclusion on Can modern x86 hardware not store a single byte to memory? is still (probably) correct that x86 can, and so can every other ISA that provides byte store instructions.

Cortex-A15 MPCore is a 3-way out-of-order execution CPU, so it's not a minimal power / simple ARM design, yet they chose to spend transistors on OoO exec but not efficient byte stores.

Presumably without the need to support efficient unaligned stores (which x86 software is more likely to assume / take advantage of), having slower byte stores was deemed worth it for the higher reliability of ECC for L1d without excessive overhead.

Cortex-A15 is probably not the only, and not the most recent, ARM core to work this way.

Other examples (found by @HadiBrais in comments):

1. Alpha 21264 (see Table 8-1 of Chapter 8 of this doc) has 8-byte ECC granularity for its L1d cache. Narrower stores (including 32-bit) result in a RMW when they commit to L1d, if they aren't merged in the store buffer first. The doc explains full details of what L1d can do per clock. And specifically documents that the store buffer does coalesce stores.

2. PowerPC RS64-II and RS64-III (see the section on errors in this doc). According to this abstract, L1 of the RS/6000 processor has 7 bits of ECC for each 32-bits of data.

Alpha was aggressively 64-bit from the ground up, so 8-byte granularity makes some sense, especially if the RMW cost can mostly be hidden / absorbed by the store buffer. (e.g. maybe the normal bottlenecks were elsewhere for most code on that CPU; its multi-ported cache could normally handle 2 operations per clock.)

POWER / PowerPC64 grew out of 32-bit PowerPC and probably cares about running 32-bit code with 32-bit integers and pointers. (So more likely to do non-contiguous 32-bit stores to data structures that couldn't be coalesced.) So 32-bit ECC granularity makes a lot of sense there.

The MCF5271 manual discusses the external interface of the processor in Chapter 17. The processor implements a byte-addressable address space with a 32-bit external data bus. The D[31:0] signals represent the data bus, the A[23:0] signals represent the address bus, and the BS[3:0] (active low) signals represent the byte enable signals. Even though the the data bus 32-bit wide, the memory module connected to it can be 32-bit, 16-bit, or 8-bit wide. This is referred to as the memory port size. Figure 17-2 from that chapter shows how all of these signals are related to each other.

Table 17-2 from the same chapter shows the supported transfer sizes (Specified by a signal called TSIZ[1:0]).

The A[0] and A1 address signals specify the alignment of the transfer. Memory alignment is defined in Section 17.7 of the same chapter.

Because operands can reside at any byte boundary, unlike opcodes, they are allowed to be misaligned. A byte operand is properly aligned at any address, a word operand is misaligned at an odd address, and a longword is misaligned at an address not a multiple of four. Although the MCF5271 enforces no alignment restrictions for data operands (including program counter (PC) relative data addressing), additional bus cycles are required for misaligned operands.

Putting all of that information together, we can easily determine how many cycles are required to transfer a 1-byte, 2-byte, 4-byte datum to any memory location (aligned or misaligned) through a memory port of size 1-byte, 2-byte, or 4-byte.

Let's consider the example from the image you've attached. How to store a longword at address 0x0000003 through a 32-bit memory port? Focus on the rows where the port size is 32-bit. We have A[1:0] = 11. So first a single-byte transfer must be performed with BS[3:0] = 1110. The other three bytes need to be transferred to locations 0x0000004 (A[1:0] = 00), 0x0000005 (A[1:0] = 01), and 0x0000006 (A[1:0] = 10). This can be done using either three single-byte transfers (which would take three cycles) or using a single two-byte transfer followed by a single one-byte transfer (which would take two cycles).

The 1st message spi_coldfire: master is unqueued, this is deprecated is not an error. This just a warning that the registering SPI controller has its own message transfer callback master->transfer. It is deprecated but still supported in kernel 4.12.5. Look at drivers/spi/spi.c:1993.

The 2nd message: I suspect, that your flash doesn't have JEDEC ID at all (reads 0,0,0), but your flash_info has. So to avoid calling spi_nor_read_id() just let info->id_len to be 0. id_len calculates as .id_len = (!(_jedec_id) ? 0 : (3 + ((_ext_id) ? 2 : 0))), so the possible solution is simply to let jedec_id be 0. Like:

The normal way to do this for debugging purposes is something like