<_whitenotifier-3>
[nmigen] porglezomp opened issue #316: Case pattern syntax improvement - https://git.io/JvGOA
<awygle>
whitequark: is there a way i can cause nmigen to evaluate an expression / propagate constants? i am running a Python function over a list of Consts and what i get back looks basically like Lisp code
<awygle>
mm also printing as hex would be useful
<whitequark>
awygle: hmm
<whitequark>
you could (ab)use the simulator
<whitequark>
it's not very ergonomic though
<awygle>
how would i do that?
<awygle>
just like... assign the Consts to Signals and lookat them in GTKWave?
<_whitenotifier-3>
[nmigen] whitequark commented on issue #316: Case pattern syntax improvement - https://git.io/JvGZR
<awygle>
spose that works lol
<awygle>
you're right about the ergonomics tho. want i should open an enhancement request? seems like a useful capability to have although idk how difficult it'd be to implement
<_whitenotifier-3>
[nmigen] porglezomp commented on issue #316: Case pattern syntax improvement - https://git.io/JvGZy
<awygle>
how can i do math on Consts without them changing in width?
<awygle>
i want the wrapping behavior of a 4-bit value
<awygle>
but every time i add two together the width increases by 1
<awygle>
mm, i made this work by putting .part(0, 4) after every math operation...
<whitequark>
awygle: i actually meant using the internals of pysim
<whitequark>
which has a nmigen-to-python compiler
<whitequark>
but yeah
<whitequark>
re consts: .part(0, 4) does work but it's an overly complex way to say [:4]
<awygle>
huh, thought you couldn't slice values. guess that only applies to non-consts?
<whitequark>
the default is that width is truncated only on assignment, i.e. intermediate results are "infinite width" (or rather, extended as needed)
<whitequark>
you *can* slice any value
<whitequark>
it's literally defined on ast.Value
<whitequark>
you can't slice Python numbers, since, well, Python numbers.
<whitequark>
Value.cast(12345)[:4] works
<whitequark>
though it's sort of verbose
<whitequark>
Const(12345)[:4] works and is less verbose
<whitequark>
i'm not sure if there's a good way to add opt-in wrapping arithmetics. it's not even elegant in haskell
<whitequark>
well
<whitequark>
it's inelegant in different ways there.
<awygle>
i think this is fine, i just had to figure it out
<awygle>
probably what i'll do is let it expand and then at the end do something like map(lambda x: x.part(0, 4), consts)
<whitequark>
that works *if* it's safe to let it expand
<awygle>
Should be in this case
<awygle>
I think
<awygle>
I'll double check tomorrow after sleep and caffeine....
_whitelogger has joined #nmigen
<awygle>
You think? Seems like I'd be just as likely to have bugs in the spec
<awygle>
Unless I could do formal comparison against a known working C or Python implementation, which would be cool
<whitequark>
awygle: I mean, comparison of a dumb approahc that stuffs [:4] after every operation
<whitequark>
and a "smart" one which only does it at the end
<awygle>
Ah, yes, fair enough
<awygle>
Cross language formal would be cool though.... Must be some prior art there
<whitequark>
well
<whitequark>
you really don't want your specification language to be either "unmodified C" or "unmodified Python" for reasons that are hopefully obvious
<whitequark>
(also, please don't use .part() for constant index slicing, if you use it on LHS to get n bits out of an m-bit signal it generates an m-n input mux)
<whitequark>
(er, on RHS, on LHS it generates even more logic)
<awygle>
Duly noted
<whitequark>
it'll work just fine (well, .part is deprecated, it's .bit_select now, but other than that) but it just hurts to see, like heap allocating nine individual floats for a matrix
<_whitenotifier-3>
[nmigen/nmigen] whitequark pushed 1 commit to master [+0/-0/±4] https://git.io/JvGCi
<_whitenotifier-3>
[nmigen/nmigen] whitequark dfcf793 - hdl.{ast,dsl}: allow whitespace in bit patterns.