By: Wilco (Wilco.dijkstra.delete@this.ntlworld.com),
Room: Moderated Discussions
dmcq (dmcq.delete@this.fano.co.uk) on February 20, 2019 2:16 pm wrote:
> Wilco (Wilco.dijkstra.delete@this.ntlworld.com) on February 20, 2019 1:31 pm wrote:
> > dmcq (dmcq.delete@this.fano.co.uk) on February 20, 2019 1:01 pm wrote:
> > > Michael S (already5chosen.delete@this.yahoo.com) on February 20, 2019 12:21 pm wrote:
> > > > dmcq (dmcq.delete@this.fano.co.uk) on February 20, 2019 11:49 am wrote:
> > > > > Michael S (already5chosen.delete@this.yahoo.com) on February 20, 2019 9:41 am wrote:
> > > > > > dmcq (dmcq.delete@this.fano.co.uk) on February 20, 2019 9:03 am wrote:
> > > > > > >
> > > > > > > And their ARMv8,1-M architecture
> > > > > > > for Cortex-M microcontrollers totally abandons any pretence of a RISC architecture!
> > > > > > >
> > > > > >
> > > > > > WTF are you talking about?!
> > > > >
> > > > > The stuff in this from The Register
> > > > > The Lance Arm-strong of performance-enhanced CPUs: Armv8.1-M
> > > > > arch jams vector math into super-microcontrollers
> > > > > No fuck is necessary in asking a question like that.
> > > >
> > > > It is necessary because, unlike you, I actually read introduction whitepaper
> > > > and took a brief look into draft of 8.1M reference manual. There is absolutely
> > > > nothing less RISCy than what was here since introduction of Thumb2.
> > > > It's still load-store and still only 2 variants of instruction width.
> > > > Unless you consider scatter-gather unRISCy. But than even Alpha is unRISCy, because of Tarantula proposal.
> > > > In ARM world scatter/gather is already in SVE which is optional, but standardized part of v8-A.
> > > >
> > > > If anything, new synchronization facilities in 8.1-A are less RISCy than anything found in Helium.
> > >
> > > You did not have enough evidence to assume I had not read
> > > that material and you were wrong in your assumption.
> > >
> > > Well I think of RISC as something where one has a set of
> > > registers and instructions and the instructions work
> > > cleanly to do one thing without having a load of status registers
> > > except perhaps some condition codes. ARM went
> > > a bit beyond that originally with load and store multiple
> > > instructions. And then Thumb had a conditional execution
> > > instruction that affected the next few instruction plus of course two lengths of instructions.
> > >
> > > This goes beyond that with lots more status with vector
> > > instruction beats and overlapping and more conditional
> > > control instructions and instructions to delimit loops.
> > > And it can interrupt anywhere and restart at any beat
> > > within a vector instruction. I think that all qualifies as not being what people think of as RISC.
> >
> > RISC is about the ISA, ie. load/store architecture, many
> > orthogonal registers, fast decode, simple addressing
> > modes, and instructions which are mostly single cycle.
> > This still ticks all those boxes. Having instructions
> > that affect state (such as changing rounding modes, setting flags etc) does not equal CISC. You could think
> > of the beats as a traditional vector processor, it enables
> > overlapping computations without hardware interlocks.
> > The DSP-style looping instructions enable zero-overhead loops using minimal hardware. So it's all aimed at
> > making implementations simpler and faster. How could that possibly be interpreted as a CISC ISA?
> >
> > Wilco
>
> Even if this can have complex loads and stores, has registers are overlaid in different ways, the
> decode must be a bit strange by now, the addressing is not simple in comparison to other machines,
Adding a new extension always increases complexity, that's a given. It's all about minimizing that so the gain is worth the cost. Tell me which Arm addressing modes are not simple? Base + offset with optional write back or base + index * scale are not complex and standard across various RISC ISAs.
> and the instructions are not single cycle, your criteria, you still say how could I possibly interpret
> this as a CISC ISA?
Which instructions are not single cycle? The white paper showed how instructions are pipelined so they do not need multiple cycles, and a dependent vector operation can start in the next cycle.
Wilco
> Wilco (Wilco.dijkstra.delete@this.ntlworld.com) on February 20, 2019 1:31 pm wrote:
> > dmcq (dmcq.delete@this.fano.co.uk) on February 20, 2019 1:01 pm wrote:
> > > Michael S (already5chosen.delete@this.yahoo.com) on February 20, 2019 12:21 pm wrote:
> > > > dmcq (dmcq.delete@this.fano.co.uk) on February 20, 2019 11:49 am wrote:
> > > > > Michael S (already5chosen.delete@this.yahoo.com) on February 20, 2019 9:41 am wrote:
> > > > > > dmcq (dmcq.delete@this.fano.co.uk) on February 20, 2019 9:03 am wrote:
> > > > > > >
> > > > > > > And their ARMv8,1-M architecture
> > > > > > > for Cortex-M microcontrollers totally abandons any pretence of a RISC architecture!
> > > > > > >
> > > > > >
> > > > > > WTF are you talking about?!
> > > > >
> > > > > The stuff in this from The Register
> > > > > The Lance Arm-strong of performance-enhanced CPUs: Armv8.1-M
> > > > > arch jams vector math into super-microcontrollers
> > > > > No fuck is necessary in asking a question like that.
> > > >
> > > > It is necessary because, unlike you, I actually read introduction whitepaper
> > > > and took a brief look into draft of 8.1M reference manual. There is absolutely
> > > > nothing less RISCy than what was here since introduction of Thumb2.
> > > > It's still load-store and still only 2 variants of instruction width.
> > > > Unless you consider scatter-gather unRISCy. But than even Alpha is unRISCy, because of Tarantula proposal.
> > > > In ARM world scatter/gather is already in SVE which is optional, but standardized part of v8-A.
> > > >
> > > > If anything, new synchronization facilities in 8.1-A are less RISCy than anything found in Helium.
> > >
> > > You did not have enough evidence to assume I had not read
> > > that material and you were wrong in your assumption.
> > >
> > > Well I think of RISC as something where one has a set of
> > > registers and instructions and the instructions work
> > > cleanly to do one thing without having a load of status registers
> > > except perhaps some condition codes. ARM went
> > > a bit beyond that originally with load and store multiple
> > > instructions. And then Thumb had a conditional execution
> > > instruction that affected the next few instruction plus of course two lengths of instructions.
> > >
> > > This goes beyond that with lots more status with vector
> > > instruction beats and overlapping and more conditional
> > > control instructions and instructions to delimit loops.
> > > And it can interrupt anywhere and restart at any beat
> > > within a vector instruction. I think that all qualifies as not being what people think of as RISC.
> >
> > RISC is about the ISA, ie. load/store architecture, many
> > orthogonal registers, fast decode, simple addressing
> > modes, and instructions which are mostly single cycle.
> > This still ticks all those boxes. Having instructions
> > that affect state (such as changing rounding modes, setting flags etc) does not equal CISC. You could think
> > of the beats as a traditional vector processor, it enables
> > overlapping computations without hardware interlocks.
> > The DSP-style looping instructions enable zero-overhead loops using minimal hardware. So it's all aimed at
> > making implementations simpler and faster. How could that possibly be interpreted as a CISC ISA?
> >
> > Wilco
>
> Even if this can have complex loads and stores, has registers are overlaid in different ways, the
> decode must be a bit strange by now, the addressing is not simple in comparison to other machines,
Adding a new extension always increases complexity, that's a given. It's all about minimizing that so the gain is worth the cost. Tell me which Arm addressing modes are not simple? Base + offset with optional write back or base + index * scale are not complex and standard across various RISC ISAs.
> and the instructions are not single cycle, your criteria, you still say how could I possibly interpret
> this as a CISC ISA?
Which instructions are not single cycle? The white paper showed how instructions are pipelined so they do not need multiple cycles, and a dependent vector operation can start in the next cycle.
Wilco



