[Libre-soc-dev] Task 939 and its subtasks

[Jacob Lifshay]

On Fri, Nov 25, 2022, 06:16 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

>
>
> On Thursday, November 24, 2022, Jacob Lifshay <programmerjake at gmail.com>
> wrote:
>
> > I keep pushing for getting better error checking and more maintainable
> code because I consider my sanity valuable, I do not want to have to spend
> an extra 5hr debugging every time I try to change something even remotely
> complex in the pseudocode.
>
> get over it!
>
> suck it up and get on with it!
>
> >>
> >> Please respect when i say "no", and think "why has he said no,
> >> what factors did I miss". you are intelligent enough to
> >> work them out, and I simply do not have the time to explain
> >> them. it is therefore your responsibility to work through
> >> "why did he say no" so that i am not burdened with explaining.
> >>
> >> Dimitry, yes an expression is quite a high threshold, an
> >> even simpler one is just to return the incoming register.
> >> don't even add to it, not even a constant.
> >>
> >> there is only one type: a fixed-bit-length integer.
> >
> > that's wrong, there is also Python int (e.g. XLEN and the output of all
> MASK() calls)
>
> converts to fixed-bit-length integer.
>

yes, but i was referring to the types in the input pseudocode, where it
*does* behave differently because it isn't a fixed-bit-length integer, e.g.
`MASK(a, b)[32:63]` will not work because `MASK` returns a Python int, not
a fixed-bit-length integer. I'm assuming the compiler is designed such that
current pseudocode semantics are unchanged, therefore we need to have logic
to account for that, that logic is exactly what type tracking is.

>
> >and maybe str too, icr for sure.
>
> no, there is no string.
>
> > also fixed-bit-length integer is not one type, it is many different
> types: one for each different length.
>
> macros take care of that.
>

but the input types (what I meant by types) still need to be tracked in the
compiler in order to correctly generate the output C, unless you are
instead dynamically tracking them in the generated output C like
SelectableInt does in Python -- the compiler/C-runtime combination needs
some way to know what bits to extract when evaluating `(a * b)[32:63]` --
that depends on the type of `a * b` -- specifically how wide `a * b` is.

This is solved by my proposed type propagation pass.

>
> everything you are stating is false objections as a deliberate
> tactic.
>
> you are not providing solutions, you are bringing up obstacles
> and problems.
>
> please wake up

that's rude. I'm sorry I was rude but that doesn't excuse you also being
rude.

and start providing solutions and working within
> the parameters set.
>
My issue is that it seems like you effectively unilaterally defined the not
explicitly stated and agreed on parameters to only allow your proposed
solution of code morphing the current Python backend into a C backend with
it seems as little design effort as possible and I think that will make our
problems worse with the code being poorly understandable and poorly
maintainable (those last two were also pointed out by ghostmansd) and hard
to use correctly (hard to write correct pseudocode for reasons already
explained),
therefore I proposed multiple solutions:

rewrite the compiler -- rejected a few months ago.

split the frontend and backend apart, adding an AST in-between, this mostly
fixes the understandability and maintainability problems and easily allows
having the Python and C backends be separated making the code that much
clearer -- rejected a few days ago, though you keep describing "analyzing
the AST" and stuff so this makes me think you're unconsciously going for
this idea anyway...

track pseudocode types -- rejected even though you are planning on doing
the same kind of thing just described in different words (so you don't seem
to realize that's what your doing) -- because it *is* a correctness
requirement.

Note all of the above proposals I made with the implication that I would be
doing the work.

>
> > 1. insufficient as described to generate correct C, expressions have
> types too, also you have to keep track of variables' and functions' types
> (which may be generic) so you can look-up variables and functions later and
> know exactly what types expressions using them have.
>
> this is once again a false objection because there is only
> one type.
>
> > 2. exactly (in spirit) the type deduction and checking you repeatedly
> objected to me adding.
> >>
> >> the only tricky bit is EXTS() and undefined() both of which
> >
> > EXTS simply returns a 256-bit integer (since that kludge seems to work)
>
> the length 256 is detected inside operators which set it to
> the size of input parameters.

I did not realize that.

 determining the length of the
> sign-extended return result is thus "deferred".



Jacob everything you wrote was extreme confrontational


sorry, I just want to end up with better code at the end and your proposed
solution seems like it will make the problems worse and you were rejecting
everything I proposed that would help solve that problem.

and

"false objections".
>
> please cease doing that.
>

I will try.

>
> if you do not take this seriously i will place you into
> temporary moderation,
>

that is unnecessary and extreme.

Jacob

>