Announcement

Collapse
No announcement yet.

Initial Apple M1 SoC Support Aims For Linux 5.13 Kernel

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #41
    Originally posted by Boland View Post

    They just made it EASIER to run alternative operating systems with the latest OS update. If they didn’t want people to run Linux they wouldn’t have put in features that let that happen.
    As good as Mac OS on M1 is everyone including Apple knows that it isn't even finished yet. I actually expect to see further hardware improvements before it is feature complete. M1 is just a very advance Beta in my mine. Hauntingly good for a gen one device but both the hardware and the OS is not completely there yet.

    Comment


    • #42
      Originally posted by AdrianBc View Post
      Then the 8-bit ISA was extended in 1974 in the Intel 8080, then in 1976 in the Zilog Z-80.

      Then the 8-bit ISA was extended to 16-bit in 1978, in the Intel 8086.
      The 16-bit ISA was extended again in 1980, with Intel 8087, then in 1982, in Intel 80186 and Intel 80286.
      Just to nitpick on minute details, but no Intel did not extend its 8-bit ISA to 16bits (like the later 16->32 or 32->64 (x86_64/AMD64's, not IA-64's) shifts).
      8086 and 8088 got a (not so) entirely new ISA.
      This ISA just happens to be on purpose designed in a way that looks very close to 8080's and Z80's, with the specific design goal that it shouldn't be difficult to port source code from 8080 to 8088 using automated tool, instead of needing to rewrite everything.

      But a 8088 cannot run machine code compiled for 8080*.

      This was mostly done because 8080 and Z80 were immensely popular back then (e.g.: see MSX computers in Japan) and the idea was to make the large software collections made for thos easy to port (e.g.: Intel's hope was that all the software that existed for CP/M 8080/Z80 could be easily be ported to CP/M-86).

      It's one of the reasons that IBM picked up 8088 for their IBM PC.

      Except that in practice, there weren't as many ports of CP/M software targetting some CP/M-86 by Digital Research as expected. Instead the PC ended up shipping with PC-DOS - Microsoft's own derivative of a "stolen CP/M" - and most software developers jumped straight to targetting the IBM PC "because nobody got ever fired for going IBM (tm)". IBM could have picked any processor (and OS), and simply by slapping an "IBM" logo on the box everyone and their dog would have started writing software for it, no matter pre-existing codebases, just because of the success of the brand in businesses and with big iron.

      (The other reason include good volume parts availability for the CPU by 1981. And the fact that IBM wanted to have the machine exclusively made out of "off-the-shelf" parts -- as they were very late in the personal/micro computer space and needed to move fast to catch up. That's why they specifically picked up the 8088 as it had an external 8bit memory and IO bus, very similar to the one used by 8080 and Z80 and could interface and use any of the already existing 8bit support chips, no need to develop custom chipsets. IBM *did* consider other CPUs, including then more recent m68k, but eventually rejected these alternatives mostly on CPU volume availability, and large choice of ready-to-use 8bit support chips -- e.g.: 68008 didn't exist, yet.
      That's the reason why the PC compatible platform won as a whole: any clone manufacturer could just pick the same parts out of the same metaphorical shelf.
      At the end of the day backward "source-code" compatibility with 8080/Z80 and CP/M played zilch, parts availability was the critical element).

      ---

      * - On the other hand, NEC's V20 could. Again, Z80's popularity in Japan probably played a role.

      Comment


      • #43
        Originally posted by DrYak View Post

        Just to nitpick on minute details, but no Intel did not extend its 8-bit ISA to 16bits (like the later 16->32 or 32->64 (x86_64/AMD64's, not IA-64's) shifts).
        8086 and 8088 got a (not so) entirely new ISA.
        This ISA just happens to be on purpose designed in a way that looks very close to 8080's and Z80's, with the specific design goal that it shouldn't be difficult to port source code from 8080 to 8088 using automated tool, instead of needing to rewrite everything.

        But a 8088 cannot run machine code compiled for 8080*.

        ---

        You did not contradict in any way what I have said, because you used a different definition of the word "ISA extension".

        By "ISA extension", I mean that the extended instruction set includes as a subset the original instruction subset.

        Obviously, the set difference between the new instruction set and the old instruction set is a subset composed of instructions that are by definition completely new, i.e. they do not have equivalents in the old instruction set.

        When extending an ISA to wider data sizes it is very frequent the case that the subset of new instructions contains much more instructions than the subset of old instructions, so the original ISA remains as a small part of the extended ISA, but this does not mean that the extended ISA is not an extension of the original ISA,

        It is an extension because it still includes as a subset the original ISA.

        Also, by including the original ISA as a subset, I mean that the original instructions can be used freely, anywhere in a program, interspersed between new instructions.

        When the CPU can be switched between different modes in which it can execute different instruction sets, then I do not consider that an alternative instruction set is a subset of the main ISA.

        Therefore, by my definition ARM has not extended the 32-bit ARM ISA to a 64-bit ARM ISA. The 32-bit ARM ISA and the 64-bit ARM ISA are 2 completely distinct ISAs, even if many CPUs can execute either of them, by switching between execution modes.

        On the contrary, by my definition the Intel 8086 ISA is really an extension of the Intel 8085 ISA, because almost all Intel 8085 instructions still exist, with completely identical behavior, among the instructions of the Intel 8086 ISA.

        Only a very small number of 8080/8085 instructions have been eliminated from the 8086 ISA, e.g. the restart instructions and a couple of instruction mask handling instructions, which were used only inside the operating system or device drivers, and also the conditional call/return instructions, which were redundant, being equivalent with a pair of instructions (conditional jump + unconditional call/return).


        What is true that the case of the Intel 8086 ISA differed from most cases of ISA extension because the binary encoding of the original instructions has been changed.
        This is something that I have already mentioned in my first post, but what is essential for an instruction is its meaning, not its binary encoding.
        There are many CPUs which can execute different binary encodings of their ISA, e.g. a non-compressed encoding and a compressed encoding. That does not mean that they execute different ISAs, they just are able to decode different encodings of the same ISA.

        While you are right that an 8086 cannot execute directly a binary executable file meant for 8080 or Z80, for most 8080/Z80 programs it is possible to use an automatic transcoder that will generate the binary executable for 8086 from an 8080 or Z80 executable by just using a mapping table between the old ISA and the new ISA.

        The only tricky part of the 8080-to-8086 transcoding is that the translation program must identify correctly which parts of the original file are instructions and which are data and it must also take care to adjust all addresses, e.g. jump destinations for the cases when the new instructions have another length than the original instructions.

        This can be easily achieved by doing the transcoding of an instruction sequence at the first execution attempt and then reusing the result, like in JIT compilers, but with the difference that the transcoding is a trivial operation, unlike the compilation from a different programming language or the translation from another ISA, where the instructions have different meanings, so that the equivalent of an original instruction sequence in new instructions is not unique, but it is dependent on the context.
















        Comment


        • #44
          Originally posted by AdrianBc View Post
          While you are right that an 8086 cannot execute directly a binary executable file meant for 8080 or Z80, for most 8080/Z80 programs it is possible to use an automatic transcoder that will generate the binary executable for 8086 from an 8080 or Z80 executable by just using a mapping table between the old ISA and the new ISA.
          That's my whole point (and the point of most assembly guide I've read back in the days).
          The same instructions aren't as is in 8080 as in 8086.

          BUT it's possible to keep some conventions, e.g.: If you map certain 8bit register pairs to certain 16bit register halves, it's possible to obtain roughly the same funtionnality.
          Porting code from 8080/Z80/8085 to 8086/8088 boils done to one giant glorified sed script that substitutes a lot of things around (register name, missing instuction to instruction series, some addressing modes) and the result should be valid source code that could be assembled for the 16bit descendant.

          At that point you aren't that far from tool-assisted port of other completely different un-related ISA (m68k, ppc, etc.)
          The only key difference being that the available set of instructions on 8086 is on purpose designed to have comparable features, so it is not extremely difficult to port.
          You can't straigh run 8080 code as-is, but it's close enough that there close enough equivalents to make the porting easier (as opposed to, say a m68k or 6502).

          Comment

          Working...
          X