<_whitenotifier-7>
[amaranth-lang/amaranth-lang.github.io] whitequark 3a94e0f - Deploying to main from @ amaranth-lang/playground@66583d5cf444cace722588e896c010e7d1221bef 🚀
<_whitenotifier-5>
[amaranth-lang/playground] whitequark e953320 - Encode share blob as base64 instead of urlencode, to reduce overhead.
<_whitenotifier-5>
[amaranth-lang/amaranth-lang.github.io] whitequark 1c59d28 - Deploying to main from @ amaranth-lang/playground@e953320af53aab9980034fe7d09f12b7aac0a841 🚀
<_whitenotifier-7>
[amaranth-lang/amaranth-lang.github.io] whitequark c27e978 - Deploying to main from @ amaranth-lang/playground@69bd7326abfc8f03bc5f47f53a9808792059ca31 🚀
<whitequark[cis]>
that looks like way too much ceremony for handling signedness
<whitequark[cis]>
i don't think it even matters for a multiplier?
<cr1901>
It does if I introduce unequal widths (sign extension), but no it doesn't right now
<whitequark[cis]>
then don't handle that as a part of the multiplier? definitely better than the 250 lines of ceremony before we get to the actual impl
<whitequark[cis]>
wait, what's an invalid input to a multiplier?
<galibert[m]>
Signedness matters in a multiplier when the size of the result is bigger than the size of the inputs
<cr1901>
Any cycle where the valid signal wasn't asserted.
<whitequark[cis]>
galibert: right, so it depends on where you do the extension, before or after
<galibert[m]>
yep, also dont forget than hard multipliers usually have the outputs bigger than the input to get full precision
<cr1901>
This multiplier is hardcoded to produce 2*input width right now
<zyp[m]>
no support for uneven input widths?
<zyp[m]>
unequal*
<cr1901>
I want to implement it in terms of max(len(a), len(b)) and sign or zero extend :P
<cr1901>
(And pray the optimizer works)
<cr1901>
Otherwise, no, not yet
<zyp[m]>
why not len(a) + len(b)?
<cr1901>
I don't follow
<zyp[m]>
len(a * b) for full precision is len(a) + len(b)
<cr1901>
Ahhh, yea, that should work and not be too difficult to add
<whitequark[cis]>
though I think you can also do sext if a or b are signed, zext otherwise
<whitequark[cis]>
oh i guess not
<cr1901>
I do need the Sign enum. But I could do something like have the inputs and outputs as unsigned, and the user checks what type of multiply was done and do as_signed()/as_unsigned()
<whitequark[cis]>
yeah I feel like signed/unsigned should be the property of the operation not the data type
<whitequark[cis]>
theoretically it belongs to the data type, practically you'll want one or the other most of the time
<cr1901>
Correct. But also, now that these docs are committed, I have something to refer to when I actually _need_ to document a tagged union for the first time.
<cr1901>
zyp[m]: This'll have to do: https://www.wdj-consulting.com/smolarith/. I can't get RTD to build. And if I open an issue right now, I'm... not going to be nice.
<zyp[m]>
hmm, fixed.Value should probably have .as_signed() and .as_unsigned() so you could transparently use fixedpoint shapes instead of integers in your SignedOrUnsigned
<cr1901>
wq thinks I should get rid of SignedOrUnsigned, so it's probably going to go
<cr1901>
What could possibly happen instead is I have a "RawMultiplier" that is unsigned/signed only, and arbitrary shapes could be fed to a wrapper over the raw multiplier
<zyp[m]>
also, if you're gonna support fixedpoint, it's probably a good idea to accept a shape argument rather than a width argument
<cr1901>
yes, it
<cr1901>
s planned
<zyp[m]>
instead of figuring out the output shape yourself, you could do (a * b).shape()
<cr1901>
Changing the width to a shape arg will be 0.2, see that RFC 41 is a draft and Idk when it'll be done
GenTooMan has quit [Ping timeout: 260 seconds]
<galibert[m]>
Something that would be interesting is the possibility of building large multipliers from smaller hard ones. Like a 53x53 from 27x27 blocs
<cr1901>
Probably in scope for a hypothetical Karatsuba module
<cr1901>
[13:21:09] <whitequark[cis]> "tbf I would probably put things like In(width) into the :type: field instead of writing it all out" Like this?