Whatever happend to 65T32(Terbium)?

[BigDumbDinosaur]

ElEctric_EyE wrote:

DMA would take precedence over FPU.

Although I haven't tried it, I think you could cobble together a single channel DMA controller with a CPLD or FPGA. I've entertained thoughts about it (DMA would speed up my POC's SCSI I/O loops by a factor of 8 at least), but am already monkeying with a lot of stuff.

[Arlet]

ElEctric_EyE wrote:

DMA would take precedence over FPU.

On an FPGA, DMA is a trivial exercise compared to an FPU

[enso]

Having done a lot of low-level work with ARM chips, I have to say that I am not at all happy with the instruction set. While it's pretty entrenched at this point, it would not be that hard to compete on technical ground anyway. ARM instruction set is bloated and big, thumb is too limited (and still big), thumb2 is just crazy complicated and stupid. And newer chips have picked up additional instruction sets and co-processors not unlike x86. The whole thing is a big disaster. I'd love to see a 65xxx alternative, hopefully simple and at least a little less stupid than the ARM.

[Arlet]

I did lots of ARM assembly programming, and I liked it a lot. Only took a few days to get reasonably fluent in it. I also did some Thumb programming, but never liked it as much. Thumb-2 is even worse for a human programmer.

But you have to realize these instruction sets are not designed to be elegant or simple. They are designed to get the job done efficiently, and they are intended to be used with a compiler for a higher level language. Thumb-2 does a very good job of packing a lot of power in small space.

[enso]

The original ARM instruction set is OK, but the new Cortex chips don't even support it. Thumb2 requires keeping track of too much state for my liking, as in the conditional bitmap that covers the next 4 instructions...

[Arlet]

I agree, Thumb2 isn't pretty. But that was never the design goal. It was designed to be able to write programs in C, rather than assembly, and they've extended that even to reset handlers and interrupt routines, which can be written in straight C, without special compiler tricks or assembly helpers. On top of that, Thumb2 is fast and dense.

Of course, the result is hard to write for humans, but very few people ever need to do that, so it's a good trade off.

[BigEd]

I wrote just a little Thumb2 for my a6502 emulator: it turns out I didn't use many predicated instructions, and when I did I only had a single one, so the 'ifthen' opcode only appears once, with a single suffix, right before the affected instruction. It wasn't tricky, just a bit of syntax.

Cheers
Ed

[enso]

I guess I am just a grouch.

[GARTHWILSON]

Quote:

It was designed to be able to write programs in C, rather than assembly

I don't have any problem with different processors being for different applications, and that the 32-bit 4GHz one is not always best.  I was just watching a YouTube video last night about a 32-bit 80MHz PIC32 where the man was demonstrating the speed, but he programmed it in C and a loop to flash an LED only got about a million flashes per second.  I thought, "Wow, in assembly, I could get that speed out of an 8-bit 20MHz PIC16!  In fact, with I/O in ZP, a 9MHz 6502 could do it, and the program is shorter than what he had in C, IIRC.  I maintain that one of the beauties of 6502/816 is the ease of writing in assembly.

[Arlet]

That probably doesn't have much to do with C vs assembler, but more with the way the hardware works (some hardware doesn't have fast access to I/O or runs from slow flash memory), or how the program was written.

On a recent project I did 250000 I/O switches per second, each switch setting one bit, and clearing another, using variable patterns read from a linked list. This was on a 112MHz ARM, written in C, using a timer interrupt. However, I had to move the interrupt handler to SRAM, because flash was too slow and too variable.

[Arlet]

GARTHWILSON wrote:

I was just watching a YouTube video last night about a 32-bit 80MHz PIC32 where the man was demonstrating the speed, but he programmed it in C and a loop to flash an LED only got about a million flashes per second.

I think I found the video here. The guy isn't really making any sense. I tried it myself. The C code is just this:

Code: Select all

while( 1 )
    PORTFINV = (1 << 3);

The PORTFINV register is the 'invert' register for PORT F, and writing a '1' inverts the corresponding bit. Despite the man's explanation that this is a C compiler, and writing to the port is translated to "a bunch of code", the C compiler turns this into minimal code:

Code: Select all

9fc00114:   da80        sw  a0,0(v0)
9fc00116:   17fe        b   9fc00114 

The reason this executes so slowly is probably because he used the default settings for the chip, which is to run with cache disabled, and 7 wait states on the flash. With cache enabled, speed is about 17M toggles/sec, including the loop overhead.

And if you unroll the loop, and use SET/CLR registers instead of INV, it will run at a full 80M changes/sec.

[BitWise]

Code: Select all

9fc00114:   da80        sw  a0,0(v0)
9fc00116:   17fe        b   9fc00114

The core will be executing a nop after the branch so there are 3 instructions per loop plus the flash delay cycles.

With cache enabled and the code reorganized to

Code: Select all

b $
sw a0,0(v0)

to put the invert in the delay slot it should be much faster.

[Arlet]

Actually, in the MIPS16 ISA, there are no branch delay slots. Only MIPS32 has those.