On 6/20/19 12:52 AM, Peter Zijlstra wrote: > > With everything little endian, everything seems just fine. If you load > the first 2 byte at offset 0, you get the first 2 bytes of the > instruction. It has to do with the instruction encoding scheme and what part of instruction has the major opcode/subopcode etc. For a canonical 4 byte instruction they happen to be in the upper 16 bits (for some hardware efficiency reasons unknown to me). So when a 2 byte insn follows a 4 byte, a 4 byte fetch already tells it what the 2nd instruction opcode is and whether it is a 2, 4, 6 or 8 byte insn. > > If OTOH your arch big endian, and you were to load the first two bytes > at offset 0, you get the top two. > > So this middle endian scheme, only seems to make sense if you're > otherwise big endian. Insn encoding is always middl eendina - irrespective of endianness. > But AFAICT ARC is bi-endian and the jump-label > patch under condsideration is explicitly !CPU_ENDIAN_BE32 -- which > suggests the instruction stream is sensitive to the endian selection. Nope they are not directly related. Likely the difference is when we patch the instruction to memory it is written as data so might need some endian swap. Not really rocket science. Perhaps it saves some testing effort etc. Also we don't seem to have any customers interested in BE these days. > Anyway, I was just 'surprised' at seeing middle endian mentioned, > curiosity killed the cat and all that :-) Curiosity may certainly kill cats, but on lkml curiosity is almost always a good thing both for the enquirer and enquiree ;-) _______________________________________________ linux-snps-arc mailing list linux-snps-arc@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/linux-snps-arc
