Announcement

Collapse
No announcement yet.

Libre-SOC Still Persevering To Be A Hybrid CPU/GPU That's 100% Open-Source

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

  • Originally posted by WorBlux View Post
    Which kind of make you wonder how much performance is being left on the table by clogging your caches with code rather than data...
    indeed. with a hybrid design we are in a tricky situation of context switching between two different workloads, CPU and GPU. the point of SV is to "conpactify" the vector opcodes to minimise cache thrashing.

    I'm fairly sure on mill that the load specifies width, and the instruction provides type (and that pointer is a hardware type distinct from unsigned integer) http://millcomputing.com/wiki/Instruction_Set
    i'm reasonably sure i saw a talk in which Ivan said that the ISA is small and compact. which would tend to suggest that those are pseudo ops. don't know.

    One advantage of working for yourself, I suppose.
    ah we do have to be careful that things are not so radical that adoption does not happen. however in speaking with Mendy from the OpenPOWER Foundation she very kindly clarified how the new (v3.1B) Platforms work.

    the misunderstanding in the open source community is that the platforms are defined by what is in IBM POWERnn processors. the code for glibc6 for example specifically has "#ifdef POWER9...."

    Mendy explained to me that the "Embedded Floating Point" platform is a *minimum* requirement not a *hard and only* requirement. therefore we can classify our processor as "Embedded FP", thus avoid adding VSX, yet then go on to add a RADIX MMU which is not specifically required for the Embedded Platform.

    the problem comes in making sure that the glibc6 and GNU/Linux Distros are aware that there are more linux-capable processors out there than IBM POWER9 and POWER10.



    Comment


    • Originally posted by lkcl View Post
      i'm reasonably sure i saw a talk in which Ivan said that the ISA is small and compact. which would tend to suggest that those are pseudo ops. don't know.
      Yes, the encoding is very compact, the ISA itself though isn't so much so.

      http://millcomputing.com/wiki/Cores/Gold
      http://millcomputing.com/wiki/Cores/Gold/Encoding

      23 bits for the exu slot that can handle floating point ops, 19 for the slots that can't. The need to address at most 2 sources, 5 bits each. Leaving 13/9 bits to encode the instruction, and at an optimal packing that's still quite a few instructions, with immediate cutting down the space some. And of course the whole thing is still in development and with their specification process, the final number of ops is still to be determined. And the wiki is way behind current development.


      Originally posted by lkcl View Post
      ah we do have to be careful that things are not so radical that adoption does not happen. however in speaking with Mendy from the OpenPOWER Foundation she very kindly clarified how the new (v3.1B) Platforms work.

      the misunderstanding in the open source community is that the platforms are defined by what is in IBM POWERnn processors. the code for glibc6 for example specifically has "#ifdef POWER9...."

      Mendy explained to me that the "Embedded Floating Point" platform is a *minimum* requirement not a *hard and only* requirement. therefore we can classify our processor as "Embedded FP", thus avoid adding VSX, yet then go on to add a RADIX MMU which is not specifically required for the Embedded Platform.

      the problem comes in making sure that the glibc6 and GNU/Linux Distros are aware that there are more linux-capable processors out there than IBM POWER9 and POWER10.
      Well that's all well and good. and it wouldn't be the first processor that required a little finer slice of #ifdef.

      This sent me on a rabbit-whole of reading about the radix-mmu's and hypervisor page tables. , and trying to figure out if you had nailed down the endian mode yet. Looks like the POWER transition really tossed a lot of things in the air. Hopefully your final design won't take as long as the mill.

      BTW. I did send you a pm.

      Comment


      • Originally posted by WorBlux View Post
        And the wiki is way behind current development.
        that's a great sign! it means they have engineers who focus on what they're doing and getting that right.


        This sent me on a rabbit-whole of reading about the radix-mmu's and hypervisor page tables.
        i strongly recommend looking at microwatt's source code, here, in this case mmu.vhdl. it's pretty readable.


        , and trying to figure out if you had nailed down the endian mode yet.
        ah turns out endian (both) is ridiculously simple to implement. Paul Mackerras added dual endianness in about 80 lines of VHDL because the infrastructure was already there. LOADs in OpenPOWER ISA are byte-reversible so it was a trivial matter of hooking in there. he also added 32 bit in about 80 lines as well!

        BTW. I did send you a pm.
        thanks the reminder, got it.

        Comment


        • Originally posted by lkcl View Post
          that's a great sign! it means they have engineers who focus on what they're doing and getting that right.


          i strongly recommend looking at microwatt's source code, here, in this case mmu.vhdl. it's pretty readable.



          ah turns out endian (both) is ridiculously simple to implement. Paul Mackerras added dual endianness in about 80 lines of VHDL because the infrastructure was already there. LOADs in OpenPOWER ISA are byte-reversible so it was a trivial matter of hooking in there. he also added 32 bit in about 80 lines as well!


          thanks the reminder, got it.
          The micro-watt mmu is surprisingly readable. Still only following about a 1/3 of it (it was a help to look up what a radix tree was, i'm not particularly a maths guy). The note about the (unimplemented) hypervisor capability just being *this* times 2 was interesting. As I said i've got a lot of reading and learning to do before I can make full sense of lower-level microarchetectural details. I can tell it's interacting with the TLB and doing a lot of shifts to pull a physical address out of a process layer table (that's actually laid out as a multi-level radix tree in memory).

          And the endianess win is good news, if only that they were all that simple (though you'd risk getting bored I suppose)

          Comment


          • [QUOTE=WorBlux;n1214831]

            The micro-watt mmu is surprisingly readable. Still only following about a 1/3 of it (it was a help to look up what a radix tree was, i'm not particularly a maths guy). The note about the (unimplemented) hypervisor capability just being *this* times 2 was interesting. As I said i've got a lot of reading and learning to do before I can make full sense of lower-level microarchetectural details. I can tell it's interacting with the TLB and doing a lot of shifts to pull a physical address out of a process layer table (that's actually laid out as a multi-level radix tree in memory).
            [quote]

            microwatt's code is... stunning. it's actually an exercise in mastery of programming and communication. its developers have been world-leading experts and contributors to powerpc for 25 years: Paul Mackerras amusingly freaked out an Apple store employee around 1995 by pressing the well-known BSD boot key combinations when the first cyan iMacs came out, to put it into verbose console debug logging mode, and finding that it worked

            you may find this useful:

            https://github.com/power-gem5/gem5/b...lk_example.txt

            there's not many up-to-date OpenPOWER ISA simulators out there [dolphin, pearpc and others remain 32bit and do not boot modern 32-bit linux distros]) that can boot a modern ppc64le kernel (not "and readable source code as well" by which i mean qemu's ppc64 source is excluded from that list due to its focus on JIT compilation), whereas the (experimental) POWER port of the cycle-accurate gem5 simulator by contrast is pretty readable.

            Comment

            Working...
            X