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

[Luke Kenneth Casson Leighton]

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.

>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.

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 and start providing solutions and working within
the parameters set.

> 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)

derogatory statement missing the benefit of what was implemented
please stop making derogatory statements that undermine the
design.

the length 256 is detected inside operators which set it to
the size of input parameters.  determining the length of the
sign-extended return result is thus "deferred".

as an optimisation (only), a static compiler may post-analyse
the AST and note the length, passing that as an explicit
parameter to the EXTS function.

why are you forcing me to be the one to describe these things?

i do not have time to do this.

you HAVE to wake up and start thinking through these types
of solutions, instead of wasting everyone's time with false
objections.


> -- ideally it would just return a Python int (doesn't require infinite
storage, simple range analysis can deduce the maximum number of bits needed
for storage, making it a signed fixed-length integer that can't be
sliced/indexed)

no.


Jacob everything you wrote was extreme confrontational and
"false objections".

please cease doing that.

if you do not take this seriously i will place you into
temporary moderation, and if any replies contain false
objections or describe problems without also solutions
that fit within the parameters i will reject it and ask
you to rewrite it.

the amount of time i am wasting on dealing with the false
objections is very distressing and disrespectful.

if you do not acknowledge that you will improve then i will
automatically enact moderation within 48 hours.

l.


-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68