interesting really ! It reminds me to my first "wrapping cabling" the 6800 ... time ago to build a C.A.M.A.C compatible micro for data acquisition !!!! ( transition from programming on ibm360 with triodes pentodes as room heater )
On jeu., 2014-10-23 at 01:16 +0100, Owen Shepherd wrote: > > > > > Rob Landley > > 22 October 2014 17:42 > > On 10/22/14 09:25, James McMechan wrote: > > > I was trying to do a multi-architecture buildall and it blew up on the > > > 2nd architecture on both sparc and ppc it seems the toybox md5sum sha1sum > > > are not big endian safe, i have not puzzled out the logic yet. > > > > Sigh. It _was_ bigendian safe, before I applied the unroll patch to > > speed it up back in may. > > > > I have a second unroll patch applied to my local tree that speeds it up > > further, but it's just too ugly for words. I've been meaning to poke at > > this and try to clean up the faster version, but getting it to be both > > simple and fast is _hard_, and haven't made a big enough block of time > > to sit down and stare at it yet. > > > > I hadn't done a proper retest because I wasn't done changing it. My bad, > > sorry. I'll build a fresh powerpc test image here and at least fix the > > big endian failure today. > > > > > Seagate GoFlex Home ARM 1.2GHz kirkwood 5te 128MB works > > > required chmod 666 /dev/null and then 'ln -s libc-2.18.so libc.so.0' so > > > native > > > compiler would build under arch linux > > > > Um, did you make this change _to_ arch linux? (Confused, the aboriginal > > linux system image I have lying around already has /dev/null chmod 666, > > and libc.so.0 is a symlink to libuClibc-0.9.33.2.so. Linking glibc to > > libc.so.0 is... ouch? > > > > > took 287m for a single arch compile > > > > > > > > > my other systems are still in need of work > > > AMD Athlon64 - power supply replacement > > > Intel P75 24MB - networking problems > > > hp sh3 32MB - have not yet got aboriginal to build for sh3 > > > > Oh wow, you have an sh3 test system? > > > > I'm currently trying to get aboriginal to build for sh2, which is nommu > > and thus weird. (I've got a little xylinx fpga here with an sh2 > > bitstream, and an old code sourcery sh2 toolchain hooked into a > > buildroot fork with a kernel and such.) I've already got sh4 working in > > aboriginal, so collecting the whole set would be nice on general principles. > > > > Adding sh2 and sh3 support to qemu is also on the todo list. I _think_ > > it's mostly a question of chopping sh4 down to the earlier/smaller > > instruction sets (and disabling the mmu for sh2), but I have a giant PDF > > to read through to see what the actual differences are... > > > > > TP-Link mr3020 - aboriginal will build MIPS, but static binaries do not > > > run on openwrt kernel > > > hoo-too Tripmate Elite - also MIPS not yet tested > > > > mips has a sort of oabi/eabi thing going on, where the old mipsr4k > > binaries I'm building (with the hard 256 meg memory constraint) are > > being replaced by "mips32" which is some confusing thing I need to read > > up on and has some kind of "kernel space code and userspace code aren't > > the same thing" weirdness going on that I got half an explanation of and > > don't understand. > > > > If anybody has a decent explanation of that lying around, I'd love to > > add it to the link collection. I never properly finished: > > > > http://landley.net/aboriginal/architectures.html > > > > Because I don't _know_ this information, and what research I did do is a > > bit stale now... > > > > Rob > I don't have any info on MIPS ABI transitions, but I do have a few > comments and corrections to make to that page (mostly regarding ARM, > but a few other historical trivia): > * ARMv5 didn't make Thumb mandatory (hence ARMv5T); that was > ARMv6 > * Thumb-2 was actually an ARMv6 extension (ARMv6T2) > * ARMv7-M also have a completely different exception model > (ARMv6-M is a further stripped down version of ARMv7-M, not > actually a predecessor). The M stands for microcontroller > (much like the v7-R variant stands for Realtime, of the hard > realtime sort). Being a microcontroller arch, backwards > compatibility is pretty unimportant. > * Big vs Little endian is a runtime distinction as well (APSR > contains two bits - BE8 and BE32 - which can be used to switch > into one of the two big endian modes, depending upon which > your processor supports. BE8 is the one all modern processors > support, BE32 is the one all older processors support, IIRC). > Nobody that I know of would use "armv4tl" as an architecture > designator > * The ABI commonly called "OABI" is actually an old, deprecated > version of the EABI (it was deprecated because it didnt' > interwork with Thumb code, or indeed work with Thumb very well > at all). Linux took the opportunity to rework its' system call > ABI at the same time. You can run EABI software on ARMv4 (no > Thumb), with some caveats (you need to translate all BX > instructions into MOV PC instructions) > * Motorola didn't get their engineers back in their lawsuit > against MOS Technologies. The eventual settlement was that MOS > would discontinue the 6501, a 6800 pin-compatible variant of > the 6502 > * Following on from this, the 68000 was the successor to (and > designed by the same team as) the 6809, Motorola's "6800 v2", > done after the engineers left to found MOS (several of which > would later move to the Western Design Center, which produced > the 65816. WDC are an interesting example of did something two > decades ago, still living entirely on the results of that > thing) > * The Acorn BBC Micro was a 6502 based machine. ARM was > developed for its' 32-bit successor. > * AArch64 is a completely revised architecture. In particular, > it has a new, cleaner instruction set; the system register set > has been redesigned; the whole privilege level and hypervisor > functionality has been redone; the general purpose register > file has been enlarged and all special purpose registers > removed (SP is no longer in the register file, for one). I > wouldn't be so sure of a merge. > _______________________________________________ > Aboriginal mailing list > [email protected] > http://lists.landley.net/listinfo.cgi/aboriginal-landley.net _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
