Bug 916 - re-evaluate rewriting pseudo-code parser as part of making it ingest latex and generate c/python
Summary: re-evaluate rewriting pseudo-code parser as part of making it ingest latex an...
Status: RESOLVED INVALID
Alias: None
Product: Libre-SOC's first SoC
Classification: Unclassified
Component: Source Code (show other bugs)
Version: unspecified
Hardware: PC Linux
: --- enhancement
Assignee: Jacob Lifshay
URL:
Depends on:
Blocks:
 
Reported: 2022-08-31 06:17 BST by Jacob Lifshay
Modified: 2022-08-31 15:31 BST (History)
4 users (show)

See Also:
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:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jacob Lifshay 2022-08-31 06:17:34 BST
This task is delayed until new nlnet grants are available, or RED Semi. wants to fund it, at which point we can re-evaluate if we want to do it then.

toshaan seemed to think it was a good idea to have libre-soc's simulator work on becoming an official OPF reference simulator (though not necessarily the only one, others are also working on stuff like this).

The parser/compiler needs to be rewritten (preferably in c++ or maybe rust (has lots of useful features for writing compilers), as a recursive-descent parser) to generate proper error messages, and do proper type checking, and other checks.

The end goal is such that the parser/compiler will always either error or the generated output code will work -- the existing parser/compiler is not very good with nearly undecipherable error messages and often generating code that won't run correctly. This will make it much easier to use for others who are developing their own instructions -- all they have to do is write pseudo-code and they can test their implementation against the simulated pseudo-code they wrote.

The output will be switchable between outputting C and outputting python. Outputting C is preferred since C is much easier to interface with other programming languages than python is.

The input will be the latex version of the PowerISA spec (not embedded or included in the parser/compiler, since it might still be under OPF NDA and can't be released yet).

If OPF takes too long to release the latex source, it might be worth it to figure out some way to generate latex from their released pdf (pdftohtml and a bit of translation? it just needs to be sufficient to run the pseudo-code, it doesn't have to look nice or be complete).
Comment 1 Luke Kenneth Casson Leighton 2022-08-31 08:41:23 BST
no.

extract the pseudocode from latex into the exact same format.

i will not be wasting NLnet grant money on unnecessary work.

if they spot frivolous waste of money they may reject the
grant.
Comment 2 Jacob Lifshay 2022-08-31 08:46:27 BST
(In reply to Luke Kenneth Casson Leighton from comment #1)
> no.
> 
> extract the pseudocode from latex into the exact same format.
> 
> i will not be wasting NLnet grant money on unnecessary work.

it is not a waste because the current parser is insufficient, even assuming we wrote code to convert latex to the current format (which would basically be another compiler and nearly as hard as just rewriting the parser to accept latex to begin with).
> 
> if they spot frivolous waste of money they may reject the
> grant.

it is not frivolous nor a waste.
Comment 3 Jacob Lifshay 2022-08-31 09:13:10 BST
luke, please just leave this as deferred, it is not frivolous nor a waste (and i'm apparently not the only one who apparently thinks this is useful, markos and toshaan both responded positively) and we can discuss again in a few months -- which is what this bug is for.
Comment 4 Luke Kenneth Casson Leighton 2022-08-31 15:31:50 BST
as proposed this concept is invalid.
please do not reopen.