From: Alexandre Oliva Date: Sun, 24 Jan 2021 17:01:29 +0000 (-0300) Subject: updates for the last three weeks X-Git-Tag: convert-csv-opcode-to-binary~350 X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=6fa19a0826aa51dac85c9ed1239bcbee2f94a662;p=libreriscv.git updates for the last three weeks --- diff --git a/lxo/ChangeLog b/lxo/ChangeLog index bc446cd5c..f327fc8f5 100644 --- a/lxo/ChangeLog +++ b/lxo/ChangeLog @@ -1,3 +1,75 @@ +2021-01-24 + + * GCC: Introduced vector modes, registers, classes, constraints, + renumbered and remapped registers, went over literals referring to + register numbers, and started implementation of move/load/store + and add for the V*DI integral types. Still have to test that the + compiler still works after the renumbering. The new insns are not + generated yet, I haven't made the new registers usable for + anything yet. (12:13) + +2021-01-22 + + * 578: Specifying and debating the task with luke and, later, + jacob. Difficulties in conveying the requirements and overcoming + the complexities involved in figuring out how to parse each asm + operand in Python, underspecification of the input language, + disagreement as to the complexity and the amount of work required + to duplicate existing binutils functionality in python, and then + duplicate this work one more time into binutils later, led Luke to + take it upon himself. + * 579: Talked to Jacob a bit about potential implementation + strategies. The need to build an immediate constant to use as the + operand to .long/svp64 makes for plenty of complexity, even in + C++. I'm again unhappy with a plan that involves so much + intentional waste of effort. I'm also very surprised with the + estimated amount of work involved in this task, compared with + 578, that is a much bigger one with all the rewriting of an asm + parser, and likely more rewriting as the extended asm syntax + evolves. And thus pretty much a full workday ends up wasted, + most of it complaining about planning to waste work. (8:29) + +2021-01-19 + + * Virtual Coffe (1:39) + +2021-01-13 + + * Microwatts meeting (1:08) + +2021-01-07 + + * 572: New, split out of 570, on what .[sv], elwidth, subvl + affect in load/store ops: the address [vector] or the in-memory + [vector]? + +2021-01-06 + + * 570: New. It's not specified whether selection of elwidth + sub-dword bytes get byte-reversed into LE before or after the + selection. The specs say we convert loaded words to LE as quickly + as possible, so that all internal operations are LE, but this + would lead to reversal of sub-register vector elements when + loading, even when using svp64 loads with the correct elwidth_src. + * 569: New. Also concerned about how to get bit arrays properly + loaded into predicate registers so that the *bits* are reversed to + match LE requirements. + * 568: New. After gotting clarification from Jacob about setvl's + behavior: VL gets set to MIN(VL, MAXVL), you can count on its not + being a smaller value. This is documented only in pseudocode, it + could be made more self-evident. (3:13) + +2021-01-05 + + * 567: Cesar filed it for me; I clarified it a bit further. + +2021-01-04 + + * 560: Tried to show I understand the effects of loads and + byte-swapping loads in both endiannesses, and restated my + suggestion of iteration order matching the natural memory layout + of arrays/vectors. (1:46) + 2021-01-03 * 560: Pointed out the circular reasoning in assuming LE in