1) big+1 for a bitselect. Whilst not ideal i think a 3-register version would still be useful and fits in 16 bits.
2) exponent modifier for float and fix. they already seem to have spare bits for rm for this.
3) fcmpCC and cmpCC instructions which send results to all bits of a register, as here: viewtopic.php?f=43&t=1550#p9621 or vcmp from ARMv7. Ideally 3 reg + Cx bits but this doesn't fit the instruction layout and wouldn't support 16-bit opcodes. Even a 2-reg version would help.
fcmp could use the same mode-selection mechanism as in 6) below so also handle integers but a separate single-cycle version that runs on the ialu pipeline would also be useful.
4) small immediate size/shift multiplier for register-indexed/pm load/stores using bits [19:16]. i.e. ldr r0,[r1,r2*4]
5) immediate and/orr/eor with sign-extended immediates. It doesn't cover the whole range but covers a lot of very useful sizes and includes a unary 'not' operation. Only if there is room in the instruction selector space though.
6) Add the rounding and integer mode bits to the 32-bit versions of fadd/fsub/fmul/fmadd/fmsub/float/fix within [22:20] which completely override the ones in the config register. Mode switches are extremely expensive in time and code-size and there's no reason to 'parameterise' it. The one bit left could (future) select double-mode, or for the i* equivalents, 64-bit output.
6a) 16-bit immediate mode instruction for setting the fpu mode bits for 16-bit f* instructions that operates with no cycle penalty and doesn't need to read/modify/write anything to set the mode. fmode #i3 (with various aliases). 3 bits being integer/float, rounding/truncate, (future) double/single to mirror the 3-bits available in 32-bit f* opcodes.
6b) other ways to save/restore the fp modes. Obvious easiest solution is an alias of the config register which only includes round/truncate and integer/float so it can be written to without reading first. Actually the same goes for almost every functional group of bits in CONFIG.
7) load/store multiple?
8) Drop movCC for cmpCC + selb + "mov rd,rn" or if possible "mov[d][e] rd,rn". Where the 'd' bit indicates double (register pair), and 'e' indicates 'exchange' (swap).
1 and 3 are for better branchless algorithms. Good for performance and critical for using the hardware-loop to it's fullest. Together they could replace movCC as in 8) - I'd go so far as to suggest that if it's a question of movCC or cmpCC, then movCC should be removed, but adapteva may not want to break backward binary compatibility (cost of doing so seems low mind you).
2, 4, 5 would help with code-size, fixed-point algorithms, and array indexing and seem to me to be pretty low-hanging fruit.
6 is pretty critical to general performance - it would have a big time/space impact on most types of code. Right now the i* "instructions" are essentially worthless outside of full integer/fixed-point code due to the mode-switching cost. Even innocuous statements like "i=(int)f" or "f=foo[j*k]*3.0f" can turn into a couple of dozen lost cycles due to mode switching. The compiler optimiser doesn't seem to like it at all either.Statistics: Posted by notzed — Wed Jul 30, 2014 12:39 pm
]]>