IRC channel logs

<vagrantc>hrm. having troubles building mes on 32-bit arm systems

<vagrantc>segfaults ... both with mes 0.24.2 and 0.26

<vagrantc>er, 0.25 ... 0.24.2 seemed to build fine

<vagrantc>this is building using an existing gcc, rather than starting from m2-planet or whatnot

<matrix_bridge><Andrius Štikonas> vagrantc: I think janneke is away, maybe report later

<vagrantc>i'll send to the list ...

<stikonas>something stupind is happening when I'm trying to implement execve... Though not sure where the bug might be

<stikonas>I seem to be passing non-zero pointer to return comment in fopen function. However, on the caller side I seem to be getting back 0 in QEMU and 4 my baremetal machine...

<stikonas>s/4 my/4 on my/

<stikonas>hmm, must be some M2-Planet bug...

<stikonas>FILE* file_in = fopen(file_name, "r");

<stikonas>doesn't work but the following seems to work

<stikonas>FILE* file_in;

<stikonas>file_in = fopen(file_name, "r");

<Googulator>I'd be surprised if mes's arm32 code worked on anything modern

<Googulator>it targets armv4

<Googulator>which IIRC is not a subset of armv7/8/9

<Googulator>v5 is

<muurkha>I think it's pretty easy to write armv4 code that works fine on armv7/8/9

<muurkha>as I understand it, armv4 already (optionally) supported unaligned loads in the modern way and (optionally) a full 32-bit memory space (and the consequent segregation of flags into a separate register from the pc)

<muurkha>those are the main incompatibilities that come to mind for user code (as opposed to operating system context switching and interrupt handling)

<muurkha>Cortex-M* won't be able to run armv4 code because Cortex-M* only supports Thumb instructions, but lots of "anything modern" (like Cortex-A*) does support the uncompressed (32-bit-wide) ARM instruction set

<muurkha>ARM7TDMI was ARMv4, and I think a lot of current chips are still actually ARM7TDMI

<muurkha>somewhere around here I have a tube of LPC2100 chips

<muurkha>and there are a lot of people who still play games on a Game Boy Advance

<muurkha>what kinds of incompatibilities are you thinking of, Googulator?

<Googulator>I guess I misremembered then

<Googulator>was it actually v4 that had a completely redesigned instruction encoding?

<muurkha>well, ARMv4T introduced Thumb, which is a completely redesigned instruction encoding, but continued to support the old encoding

<muurkha>and ARMv8 introduced a completely different 64-bit instruction set with 32 registers instead of 16, but I think all current ARMv8 chips also continue to support the arm32 instruction set

<muurkha>you can switch between Thumb and the uncompressed instruction set on an almost instruction-by-instruction basis (you need one extra instruction to switch modes) which can introduce some compatibility problems

<muurkha>this is so-called "interworking", where Thumb code can call uncompressed code and vice versa

<Googulator>I wasn't thinking of Thumb

<Googulator>but IIRC early ARM CPUs had a completely different (32-bit) instruction encoding than the classic 32-bit ARM we have todaxy

<muurkha>there does exist uncompressed ARM code that is compiled without support for interworking, so that if you return from it into Thumb code, it doesn't restore the T bit properly

<muurkha>I think

<muurkha>no, early ARM CPUs have the same bit fields in their 32-bit instruction encoding as 32-bit ARM CPUs today

<muurkha>you can in many cases run ARMv2 code on a current ARMv8 chip. in theory you could do that with ARMv1 code if you could find some

<muurkha>the CPSR separation, 26-bit PC, and different interrupt model are the incompatibilities I know about, and most code doesn't care about them

<muurkha>there were a variety of really hairy things you could do in early ARM chips before the publication of the Architecture Reference Manual though

<muurkha>which might have different results today because they do things that have now been declared illegal

<muurkha>like, what happens if you ldmfd r3!, {r0-r7}

<muurkha>that overwrites r3 twice, once with the value fetched from memory and once with an incremented version of its old value. what happens? but most code doesn't do things like that

<Googulator>but wasn't there a version of ARM that was a complete clean break, reshuffling all instruction opcodes to break away from Berkeley RISC heritage for IP reasons?

<Googulator>I do remember reading about that

<muurkha>no. the difference from v1 to v2 was that they added a multiply instruction. v3 was the same as v2 but fabricated in a smaller process

<muurkha>iirc?

<muurkha>oh, no, v3 was actually when they added the 32-bit mode. I was confusing ARM3 (which was ARMv2) with ARMv3

<Googulator>hmm, so ARMv1 was already not binary compatible with Berkeley RISC?

<muurkha>the complete clean break was ARMv8, but that was announced in 02011, long after any Berkeley RISC patents had expired. the reason for it was to break the 32-bit memory addressing barrier

<muurkha>ARMv1 was not binary compatible with Berkeley RISC, no, not even close

<Googulator>well, now I have absolutely no idea...

<muurkha>it used a lot of RISC ideas but also already had significant non-RISC features like ldm/stm, a small register set and the pc as a GPR, and (arguably) pervasive predication and the barrel shifter

<muurkha>also it has base-offset and pre/postincrement addressing modes that are heretical deviations from RISC dogma

IRC channel logs

2023-12-30.log