Skip to main content
Retrocomputing

Return to Answer

Spelling fixes
Source Link
Toby Speight
Toby Speight
  • 1.7k
  • 1
  • 14
  • 31

After the 8 bit processors (6510, Z80 & so on), the decode units tend to do one of 2 things. They either map illegal op-codes to become NOP instructions (as the 65C816 did) or trigger an exception. The ARM processors actually have a CPU mode that is reserved for managing illegal instructions. The number of gates to do this became, in relative to the total number of gates on the processor, trivial.

The ARM solution is ACTAUALLYACTUALLY very clever because it makes it possible to create your own instructions. They wouldn't be very fast but they would work.

As for Thumb specifically, well as others have noted, the ARM7 simply converts each 16-bit thumbThumb instruction into an ARM 32 bit instruction. On the other hand, the Cortex series of processors actually work using the raw 16 (and occasionally 32) bit instructions. I did perform a test and the M0 & M0+ processors indeed cause an exception.

What is MORE intriguing about thumbThumb is that theirthere are a few instructions that can produce unpredictable results. The ones that spring to mind are:

RORS Rd,Rd - i.e. rotate Rd by the value in bits 0-7 of Rd. WHY it uses bits 0-7 I do not know since 32 is the maximum one would generally use. The other shift instructions also use bits 0-7.

I am a HUGE fan of Sophie Wilson and her decision to use bits 0-7 WILL have had a logical foundation but nobody else is aware of it.

Another Thumb instruction that intrigues me is the MULS which multiplies together two registers i.e. 32-bit x 32-bit & returns the bottom 32 bits. Now, on earlier versions, the Z & N flags were set based on the result but the C & V flags were corrupted. I can only guess`guess WHY the flags were corrupted but more importantly, I could never figure out any use for the flags that were returned. So many people mistakenly thought that C flagged the result being >32 bits.... but it doesn't.

Finally, I think that the SVC (formally SWI i.e. software interrupt) instruction baresbaers some investigation. It allows an immediate 8 bit-bit value to be moved to and from the processor status. I strongly suspect that the control(s) that this instruction support are chosen by the maker orof each specific ARM Cortex based design. I don't know if you have come across any M0 implementations that have a cache. The one I saw was only 32 bytes & was direct mapped but it meant that a CPU performing a copy wouldn't tie up the bus if DMA or such also needed RAM access.

I don't know how familiar you are with ARMs TCM but I for one would have much preferred a 64 byte-byte scratch pad to a 32 byte-byte cache. MY personal reason is that it would be big enough to store a 32-bit x 32-bit ---> 64-bit signed multiply. I'm writing an MP2/MP2.5/MP3/MP4/MELP/ACELP audio decode suite and the KEY presumption in their designs is that the host CPU has a fast multiply. As it is, I've managed to get the code into 17 instructions & 17 cycles. If my MULSHIFT32 (it actually returns the top 32 bits of the 64 bit result) left the bus free, it would quickly be used by the DMA....

After the 8 bit processors (6510, Z80 & so on), the decode units tend to do one of 2 things. They either map illegal op-codes to become NOP instructions (as the 65C816 did) or trigger an exception. The ARM processors actually have a CPU mode that is reserved for managing illegal instructions. The number of gates to do this became, in relative to the total number of gates on the processor, trivial.

The ARM solution is ACTAUALLY very clever because it makes it possible to create your own instructions. They wouldn't be very fast but they would work.

As for Thumb specifically, well as others have noted, the ARM7 simply converts each 16-bit thumb instruction into an ARM 32 bit instruction. On the other hand, the Cortex series of processors actually work using the raw 16 (and occasionally 32) bit instructions. I did perform a test and the M0 & M0+ processors indeed cause an exception.

What is MORE intriguing about thumb is that their are a few instructions that can produce unpredictable results. The ones that spring to mind are:

RORS Rd,Rd - i.e. rotate Rd by the value in bits 0-7 of Rd. WHY it uses bits 0-7 I do not know since 32 is the maximum one would generally use. The other shift instructions also use bits 0-7.

I am a HUGE fan of Sophie Wilson and her decision to use bits 0-7 WILL have had a logical foundation but nobody else is aware of it.

Another Thumb instruction that intrigues me is the MULS which multiplies together two registers i.e. 32-bit x 32-bit & returns the bottom 32 bits. Now, on earlier versions, the Z & N flags were set based on the result but the C & V flags were corrupted. I can only guess` WHY the flags were corrupted but more importantly, I could never figure out any use for the flags that were returned. So many people mistakenly thought that C flagged the result being >32 bits.... but it doesn't.

Finally, I think that the SVC (formally SWI i.e. software interrupt) instruction bares some investigation. It allows an immediate 8 bit value to be moved to and from the processor status. I strongly suspect that the control(s) that this instruction support are chosen by the maker or each specific ARM Cortex based design. I don't know if you have come across any M0 implementations that have a cache. The one I saw was only 32 bytes & was direct mapped but it meant that a CPU performing a copy wouldn't tie up the bus if DMA or such also needed RAM access.

I don't know how familiar you are with ARMs TCM but I for one would have much preferred a 64 byte scratch pad to a 32 byte cache. MY personal reason is that it would be big enough to store a 32-bit x 32-bit ---> 64-bit signed multiply. I'm writing an MP2/MP2.5/MP3/MP4/MELP/ACELP audio decode suite and the KEY presumption in their designs is that the host CPU has a fast multiply. As it is, I've managed to get the code into 17 instructions & 17 cycles. If my MULSHIFT32 (it actually returns the top 32 bits of the 64 bit result) left the bus free, it would quickly be used by the DMA....

After the 8 bit processors (6510, Z80 & so on), the decode units tend to do one of 2 things. They either map illegal op-codes to become NOP instructions (as the 65C816 did) or trigger an exception. The ARM processors actually have a CPU mode that is reserved for managing illegal instructions. The number of gates to do this became, in relative to the total number of gates on the processor, trivial.

The ARM solution is ACTUALLY very clever because it makes it possible to create your own instructions. They wouldn't be very fast but they would work.

As for Thumb specifically, well as others have noted, the ARM7 simply converts each 16-bit Thumb instruction into an ARM 32 bit instruction. On the other hand, the Cortex series of processors actually work using the raw 16 (and occasionally 32) bit instructions. I did perform a test and the M0 & M0+ processors indeed cause an exception.

What is MORE intriguing about Thumb is that there are a few instructions that can produce unpredictable results. The ones that spring to mind are:

RORS Rd,Rd - i.e. rotate Rd by the value in bits 0-7 of Rd. WHY it uses bits 0-7 I do not know since 32 is the maximum one would generally use. The other shift instructions also use bits 0-7.

I am a HUGE fan of Sophie Wilson and her decision to use bits 0-7 WILL have had a logical foundation but nobody else is aware of it.

Another Thumb instruction that intrigues me is the MULS which multiplies together two registers i.e. 32-bit x 32-bit & returns the bottom 32 bits. Now, on earlier versions, the Z & N flags were set based on the result but the C & V flags were corrupted. I can only guess WHY the flags were corrupted but more importantly, I could never figure out any use for the flags that were returned. So many people mistakenly thought that C flagged the result being >32 bits.... but it doesn't.

Finally, I think that the SVC (formally SWI i.e. software interrupt) instruction baers some investigation. It allows an immediate 8-bit value to be moved to and from the processor status. I strongly suspect that the control(s) that this instruction support are chosen by the maker of each specific ARM Cortex based design. I don't know if you have come across any M0 implementations that have a cache. The one I saw was only 32 bytes & was direct mapped but it meant that a CPU performing a copy wouldn't tie up the bus if DMA or such also needed RAM access.

I don't know how familiar you are with ARMs TCM but I for one would have much preferred a 64-byte scratch pad to a 32-byte cache. MY personal reason is that it would be big enough to store a 32-bit x 32-bit ---> 64-bit signed multiply. I'm writing an MP2/MP2.5/MP3/MP4/MELP/ACELP audio decode suite and the KEY presumption in their designs is that the host CPU has a fast multiply. As it is, I've managed to get the code into 17 instructions & 17 cycles. If my MULSHIFT32 (it actually returns the top 32 bits of the 64 bit result) left the bus free, it would quickly be used by the DMA....

Source Link
Sean
Sean
  • 71
  • 1

After the 8 bit processors (6510, Z80 & so on), the decode units tend to do one of 2 things. They either map illegal op-codes to become NOP instructions (as the 65C816 did) or trigger an exception. The ARM processors actually have a CPU mode that is reserved for managing illegal instructions. The number of gates to do this became, in relative to the total number of gates on the processor, trivial.

The ARM solution is ACTAUALLY very clever because it makes it possible to create your own instructions. They wouldn't be very fast but they would work.

As for Thumb specifically, well as others have noted, the ARM7 simply converts each 16-bit thumb instruction into an ARM 32 bit instruction. On the other hand, the Cortex series of processors actually work using the raw 16 (and occasionally 32) bit instructions. I did perform a test and the M0 & M0+ processors indeed cause an exception.

What is MORE intriguing about thumb is that their are a few instructions that can produce unpredictable results. The ones that spring to mind are:

RORS Rd,Rd - i.e. rotate Rd by the value in bits 0-7 of Rd. WHY it uses bits 0-7 I do not know since 32 is the maximum one would generally use. The other shift instructions also use bits 0-7.

I am a HUGE fan of Sophie Wilson and her decision to use bits 0-7 WILL have had a logical foundation but nobody else is aware of it.

Another Thumb instruction that intrigues me is the MULS which multiplies together two registers i.e. 32-bit x 32-bit & returns the bottom 32 bits. Now, on earlier versions, the Z & N flags were set based on the result but the C & V flags were corrupted. I can only guess` WHY the flags were corrupted but more importantly, I could never figure out any use for the flags that were returned. So many people mistakenly thought that C flagged the result being >32 bits.... but it doesn't.

Finally, I think that the SVC (formally SWI i.e. software interrupt) instruction bares some investigation. It allows an immediate 8 bit value to be moved to and from the processor status. I strongly suspect that the control(s) that this instruction support are chosen by the maker or each specific ARM Cortex based design. I don't know if you have come across any M0 implementations that have a cache. The one I saw was only 32 bytes & was direct mapped but it meant that a CPU performing a copy wouldn't tie up the bus if DMA or such also needed RAM access.

I don't know how familiar you are with ARMs TCM but I for one would have much preferred a 64 byte scratch pad to a 32 byte cache. MY personal reason is that it would be big enough to store a 32-bit x 32-bit ---> 64-bit signed multiply. I'm writing an MP2/MP2.5/MP3/MP4/MELP/ACELP audio decode suite and the KEY presumption in their designs is that the host CPU has a fast multiply. As it is, I've managed to get the code into 17 instructions & 17 cycles. If my MULSHIFT32 (it actually returns the top 32 bits of the 64 bit result) left the bus free, it would quickly be used by the DMA....