Bug 1133

Summary: use insndb to insert correct "Form" into mdwn instruction files
Product: Libre-SOC's first SoC Reporter: Luke Kenneth Casson Leighton <lkcl>
Component: SpecificationAssignee: Luke Kenneth Casson Leighton <lkcl>
Status: CONFIRMED ---    
Severity: enhancement CC: libre-soc-isa, programmerjake
Priority: ---    
Version: unspecified   
Hardware: Other   
OS: Linux   
See Also: https://bugs.libre-soc.org/show_bug.cgi?id=1125
NLnet milestone: --- total budget (EUR) for completion of task and all subtasks: 0
budget (EUR) for this task, excluding subtasks' budget: 0 parent task for budget allocation:
child tasks for budget allocation: The table of payments (in EUR) for this task; TOML format:

Description Luke Kenneth Casson Leighton 2023-08-06 08:34:08 BST
the mdwn files need to contain all information necessary to convert
to latex for inclusion in the Power ISA spec.  missing at the moment
is the "Fields" specifications, currently listed in fields.text.

fields.text ultimately should be autogenerated from the information
in the mdwn files but a step-by-step migration path is needed.

the first task is therefore to modify the mdwn parser so that it
can support reading Field-format 

the second task is to write a script (not a shell script unless
it calls insndb) that inserts Field-format into the mdwn file.

the third subtask is to autogenerate the first section of fields.text
likely by first splitting it into fields.text and forms.text
Comment 1 Jacob Lifshay 2023-08-06 17:11:47 BST
(In reply to Luke Kenneth Casson Leighton from comment #0)
> the third subtask is to autogenerate the first section of fields.text
> likely by first splitting it into fields.text and forms.text

one major caveat is that the v3.1B pdf has forms without corresponding fields and/or instructions without corresponding entries in forms/fields, so those need to manually be added if we're hoping to autogenerate that whole section of the pdf. additionally, we'll need hidden fields for at least some of the unnamed bits since iirc they can be more than just /// tokens.
Comment 2 Luke Kenneth Casson Leighton 2023-08-06 17:21:17 BST
(In reply to Jacob Lifshay from comment #1)

> one major caveat is that the v3.1B pdf has forms without corresponding
> fields and/or instructions without corresponding entries in forms/fields, 

not our problem. and i cannot say more about what v3.1D or v3.2
might look like.

> so
> those need to manually be added if we're hoping to autogenerate that whole
> section of the pdf. 

no - just enough so that the ISA WG can get on with adding them in
manually.  if they (i mean IBM) choose to use our automated tools GREAT,
they can pay their own way doing that.
Comment 3 Jacob Lifshay 2023-08-06 17:25:41 BST
(In reply to Luke Kenneth Casson Leighton from comment #2)
> (In reply to Jacob Lifshay from comment #1)
> > so
> > those need to manually be added if we're hoping to autogenerate that whole
> > section of the pdf. 
> 
> no - just enough so that the ISA WG can get on with adding them in
> manually.

if you're also referring to the hidden fields, we'll need them too if our parser cares about the /// vs. something else distinction.