Open jnk0le opened 1 year ago
What does a complete example look like? I don't understand what you are suggesting with your test.
.short
?That's assembly only
.2byte
one, so went with this one.
It should be also possible to do it by .insn
directive but that requires preprocessing of immediate by a macro of some sort.added stores. Should be enough to finish usb code
I still don't understand how to apply this code. I.e. can you show me an example of what I would include in my .S file and where to, for instance use xw.c.lbu a3, 3(a4)
?
Specifically, I can't figure out how to use this:
{reg:[
{ bits: 2, name: 0x0, attr: ['xw.c.lbu'] },
{ bits: 3, name: 'rd\'' },
{ bits: 2, name: `uimm[2:1]` },
{ bits: 3, name: 'rs1\'' },
{ bits: 3, name: `uimm[0|4:3]` },
{ bits: 3, name: 0x1, attr: ['xw.c.lbu'] },
]}
I've never seen any syntax like it before. Is it only for creating a pretty instruction map on wavedrom?
Is the idea I just use .word 0xblah
? (Also I still don't understand .2byte
)
ALSO! Have you found encodings of any other not-in-base C instructions?
Here's what I've found. I haven't tested any of the immediate multipliers, is that something you can provide insight into? I assume they are 1B for byte and 2B for half.
https://github.com/CaiB/CH32V003-Architecture-Exploration/blob/main/Analysis/NewInstructionNotes.md
I've never seen any syntax like it before. Is it only for creating a pretty instruction map on wavedrom?
yes, just the documentation purposes
Is the idea I just use .word 0xblah? (Also I still don't understand .2byte)
.word
is 4 bytes. To emit 16 bit data you can use .2byte
or .half
or .short
Here it doesn't matter wihich one you choose but often it is not obvious what is size of those "words", "shorts" etc.
ie. this: https://github.com/cnlohr/rv003usb/blob/master/rv003usb/rv003usb.S#L328
could be replaced with:
.2byte (0x2000 | (3 << 7) | (2 << 2)) //lbu a0, 0(a1)
There is actually something a little more crucial than byte-oriented loads.
Unaligned 2-byte oriented loads.
Do you have any idea how that could be possible? Right now, my send code is noncompliant, in that when sending the CRC, the first byte of the CRC has an extra 6 cycle delay and then a 4 cycle delay toward the end :(.
It's because I can only do 1-byte reads. I heard there was unaligned-ok multi-byte reads. Do you know anything of this?
half loads need to be at least 2 byte aligned.
Do you have any idea how that could be possible? Right now, my send code is noncompliant, in that when sending the CRC, the first byte of the CRC has an extra 6 cycle delay and then a 4 cycle delay toward the end :(.
looking at the send code, I think you can do branch nesting on the path that has the most nop delay required
e.g. https://github.com/cnlohr/rv003usb/blob/master/rv003usb/rv003usb.S#L744
invert this branch so it jumps to not_done_sending_data
(hoist rest of the code from here) and the rest of this "function" populated with content from done_sending_data
.
load_next_byte
should get faster after shrinking those 2 instructions. (sign extension on load doesn't matter here, does it?)
If optimizations won't work, the CRC16 in IN transactions can be done "offline" (when filling buffer), like on many soft usb implementations.
also send_zero_bit
will fall through one implicit nop (5 compressed insns + .balign 4)
@jnk0le is there any way I can mail you a free devkit so you can play with this and test it more yourself? I will try to apply your suggestion above to the code.
Thanks, but I can work fine with the wch devboard/tssop adapters. (especially when shipping from 'murica is more expensive than literally buing stuff on ali) Currently I'm limited by other factors.
made a wavedroms of some of those wch instructions (you can use https://wavedrom.com/editor.html for quick preview)
xw.c.lbu
toolchain agnostic solution/workaround for 0 offset:
xw.c.lhu
toolchain agnostic solution/workaround for 0 offset:
xw.c.sb
toolchain agnostic solution/workaround for 0 offset:
xw.c.sh
toolchain agnostic solution/workaround for 0 offset:
notes
immediate positions were tested out in just 12 SLOC: