<tpw_rules>
so since boneless is written in python, and the assembler is also in python, i keep having ideas of boneless not being just an architecture but a family of architectures.
<tpw_rules>
you could have like a pass which automatically selects the 8 most common immediates to fill the arithmetic/logic and shift tables
<tpw_rules>
or one which lets W be more precise
<tpw_rules>
or which adds semi-arbitrary instructions
<TD-Linux>
it would be super annoying to change your code and suddenly not have your design meet timing though
<tpw_rules>
well the second two wouldn't have that effect. the first might i guess, but like i already get ±10MHz timing with yosys and nextpnr anyway :P
<tpw_rules>
but you could have an option to set the tables yourself
<tpw_rules>
also wq i rewrote opcode.py with the new instruction names but don't really know how to give it to you. i evidently don't understand you enough for a PR
<tpw_rules>
relatedly, for the undefined entry in the arithmetic/logic table, having something with 1 bit set would be nice. that would mean there are three bits which can be tested without EXTI. handy for peripherals
<tpw_rules>
(also also i really don't know how to do metaprogramming in python. it seems baroque to me)
<zignig>
tpw_rules: greetings earthling.
<tpw_rules>
hello
<tpw_rules>
FTR i found it somewhat strange that you emailed me. a PM would be more appreciated
<zignig>
tpw_rules: ok, sorry bout that. ;)
<zignig>
tpw_rules: I have had a go at a bit of a restucture of the Boneless assembler, making it a class rather than just functions.
<tpw_rules>
i mean i really like how it operates
<zignig>
tpw_rules: not sure if it is a better way , but I was looking to get macros,constants and other constructs.
<tpw_rules>
frankly i don't plan on using it in textual mode
<tpw_rules>
the python mode is great
<zignig>
tpw_rules: that's where my design needs a rework , I want to be able to use both. I saw your ice_panel code and it has some advanges.
<zignig>
tpw_rules: I have also been looking into a compiler of sorts and that would generate from the python mode anyway.
<tpw_rules>
i'm not sure i understand what you mean by compiler
<zignig>
tpw_rules: writing constructs in python objects that process and generate boneless asm ( as in C-compiler / LLVM , though much simpler)
<tpw_rules>
oh ok
<tpw_rules>
wq was going to do some things on that i think, like an automatic register allocator
<tpw_rules>
idk i'm just not sure how to contribute instead of whining for changes...
<tpw_rules>
but, that's tomorrow's problem
<tpw_rules>
goodnight everyone
<zignig>
gnite
Bike has quit [Quit: Lost terminal]
OmniMancer has joined ##openfpga
ZipCPU has quit [Ping timeout: 265 seconds]
ZipCPU has joined ##openfpga
Bob_Dole has quit [Read error: Connection reset by peer]
mumptai has joined ##openfpga
<whitequark>
tpw_rules: what do you mean "don't understand me enough for a PR"?
emeb_mac has quit [Quit: Leaving.]
freemint has joined ##openfpga
freemint has quit [Ping timeout: 246 seconds]
Jybz has joined ##openfpga
_whitelogger has joined ##openfpga
ym has quit [Ping timeout: 240 seconds]
ym has joined ##openfpga
Jybz has quit [Quit: Konversation terminated!]
m4ssi has joined ##openfpga
Maya-sama has joined ##openfpga
hackkitten has quit [Ping timeout: 246 seconds]
Maya-sama has quit [Ping timeout: 252 seconds]
freemint has joined ##openfpga
hackkitten has joined ##openfpga
hackkitten is now known as Miyu
freemint has quit [Ping timeout: 265 seconds]
azonenberg_work has quit [Ping timeout: 245 seconds]
Asu has joined ##openfpga
_whitelogger has joined ##openfpga
lopsided98_ has joined ##openfpga
lopsided98 has quit [Ping timeout: 245 seconds]
<_whitenotifier-f>
[whitequark/Boneless-CPU] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/JewGD
<_whitenotifier-f>
[whitequark/Boneless-CPU] whitequark ee53f37 - examples: update for upstream changes.
<tpw_rules>
whitequark: silly ideas like circular references nonwithstanding, i didn't get your idea that the metaclass stuff in the boneless assembler was intended to be architecture independent, and i didn't get that nmigen.cli was a temporary deal
<tpw_rules>
like i feel awkward that i don't understand your ideas to give effective code
<whitequark>
tpw_rules: oh. that's really my fault, i didn't actually bother documenting any of that
<whitequark>
i think if you roughly explain your plan for changes before implementing them it'll save both of us some time
<whitequark>
and that should be sufficient
<tpw_rules>
okay, that sounds reasonable.
<whitequark>
opcode renames in particular seem straightforward and fine, there's only one way to do them really
<tpw_rules>
i'm also really new to contributing to stuff in general. i've been doing stuff for myself for a decade so i've probably grown my own strange habits. but i haven't worked out how to do multiuser git at all, for example :P
<whitequark>
tbh git sucks
<tpw_rules>
i had worked that out at least, but it's still kind of a necessary evil
<whitequark>
if you don't 'get it' it's usually just git
<tpw_rules>
it's 50% that and 50% i've never needed to. i just always work on local repos in master only and avoid 99% of the treacherousness
m4ssi has quit [Ping timeout: 265 seconds]
m4ssi has joined ##openfpga
<whitequark>
ah
<whitequark>
iirc emily had some replacement for git rebase that doesn't suck
<GenTooMan>
well like all repository tools each is imperfect. However git was a big step up from CVS from what I heard. The biggest part of git I hate is using hash #'s for commit references, because they are non sequential my orderly mind twists on it.
<OmniMancer>
hmmm, guess it depends what exactly is the desired output
freemint has joined ##openfpga
<ZirconiumX>
OmniMancer: A list of connections that can be correlated with bits in the bitstream
<OmniMancer>
Ah, indeed
dh73 has joined ##openfpga
OmniMancer has quit [Quit: Leaving.]
freemint has quit [Remote host closed the connection]
freemint has joined ##openfpga
freemint has quit [Ping timeout: 245 seconds]
mumptai has joined ##openfpga
Bird|ghosted has quit [Ping timeout: 276 seconds]
Bird|otherbox has joined ##openfpga
azonenberg_work has joined ##openfpga
Jybz has joined ##openfpga
Asu has quit [Read error: Connection reset by peer]
Asu` has joined ##openfpga
dh73 has quit [Ping timeout: 260 seconds]
mumptai has quit [Quit: Verlassend]
genii has joined ##openfpga
Jybz has quit [Quit: Konversation terminated!]
Jybz has joined ##openfpga
mumptai has joined ##openfpga
m4ssi has quit [Remote host closed the connection]
X-Scale` has joined ##openfpga
X-Scale has quit [Ping timeout: 265 seconds]
X-Scale` is now known as X-Scale
freemint has joined ##openfpga
freemint has quit [Ping timeout: 245 seconds]
AndrevS has joined ##openfpga
X-Scale` has joined ##openfpga
X-Scale has quit [Ping timeout: 268 seconds]
X-Scale` is now known as X-Scale
Bird|otherbox has quit [Ping timeout: 240 seconds]
Bird|otherbox has joined ##openfpga
Asu` has quit [Ping timeout: 240 seconds]
Asu has joined ##openfpga
emeb has joined ##openfpga
Asu has quit [Read error: Connection reset by peer]
Asu` has joined ##openfpga
AndrevS has quit [Quit: umount /dev/irc]
Jybz has quit [Quit: Konversation terminated!]
<tpw_rules>
what happens in nmigen if i have multiple sync assignments to the same signal. last one wins?
<tpw_rules>
that seems to not be true
<tpw_rules>
nvm i didn't measure correctly
<tpw_rules>
is that defined though?
freemint has joined ##openfpga
<whitequark>
last one wins, it is defined
<whitequark>
if you do it across different modules things get pretty weird
<whitequark>
nmigen will flatten hierarchy and complain
<tpw_rules>
well i wasn't going to abuse it that badly, but good to know
<tpw_rules>
would it be poor form to have a small utility module accept a module and do module.submodules += self? it would make using it easier
<tpw_rules>
random note: Signal(range(min, max)) is not intuitive
<whitequark>
the idea is that you can specify signal shapes using a variety of shape-like objects
<whitequark>
signed(16), unsigned(16), just 16 (= unsigned(16)), any Enum with integer values only, any range
<tpw_rules>
range in my mind isn't a shape-like object though. it specifically returns numbers, to me
<tpw_rules>
i would expect slice before range
<whitequark>
passing an enumeration (enum or range) ~ requesting a signal that can represent all values of the enumeration
<tpw_rules>
can it do that for arbitrary lists?
<whitequark>
no
<whitequark>
that doesn't seem useful
<whitequark>
it also doesn't do this for arbitrary *iterables* because that would break legacy compatibility (at least, that's why it never will)
<tpw_rules>
i agree, but that's the only way i could rationalize what was happening. i didn't remember you could extract the parameters from the range generator
<whitequark>
shrug. any decision will be nonintuitive to someone
<tpw_rules>
true
<whitequark>
this one is internally consistent and solved a major API issue
<whitequark>
several actually
<tpw_rules>
using range specifically? like i wonder if it would make more sense to be its own object, or use slice. numpy et al have taught me to expect weird things to happen with slices
<tpw_rules>
but that's my opinion. i guess we'll see how it plays out in the future
<whitequark>
you would use slice... how?
<tpw_rules>
like slice() has the same syntax as range() but to me conveys a range of numbers, rather than a generator of a list of numbers
<tpw_rules>
(also what happens if you use a range with step != 1)
<whitequark>
oh. wait. i momentarily lost my knowledge of english and somehow thought "slice" and "list" are the same thing
<whitequark>
yes, that would work, but basically no one knows slice() even exists
<whitequark>
ok well i guess numpy talks about it
<whitequark>
hm
<tpw_rules>
like numpy has functions that act like funky arrays, so you index them and then get a result
<tpw_rules>
it is unfortunate though that python syntax doesn't permit you to just write 1:2 anywhere
<whitequark>
right sure
<whitequark>
well
<whitequark>
that syntax would be a pretty bad idea
<whitequark>
because it looks like verilog but doesn't do what verilog does
<tpw_rules>
oh, good point
<whitequark>
this API started as Signal([min=X], [max=Y])
<whitequark>
which was weirdly mutually exclusive with other keyword arguments in inconsistent ways
<whitequark>
and the max bound was exclusive, too.
<whitequark>
so if you wrote Signal(max=x).eq(x) that's wrong
<whitequark>
but only if x is exactly a power of 2, happens to work otherwise
<whitequark>
the next iteration was Signal.range(X, [Y])
<whitequark>
unfortunately, you couldn't use this in a Record because that's not how you construct them
<tpw_rules>
i wonder if that could have been better expressed with a namedtuple or something vs overloading range
<whitequark>
so we settled on Signal(range(X, [Y]))
<whitequark>
as for namedtuple, well, nmigen reuses primitives in a few places
<whitequark>
notably Signal(X)
<whitequark>
there's now unsigned() and signed() which *are* namedtuple constructors but they're pretty verbose
<whitequark>
and the semantics of Signal(range(...)) seems fine
<whitequark>
you can't use *any* iterable, but for those which you *can*, the semantics is "can represent every element of iterable"
<whitequark>
and yes, step is taken into account
<tpw_rules>
does it just bound the range or can you like only store odd values
<whitequark>
bound the range
<tpw_rules>
ok
<whitequark>
the same way as Signal(range(10)) gives you a normal 4 bit signal
<tpw_rules>
so then "can represent at least every element of iterable"
<whitequark>
yes
<whitequark>
a hypothetical linter (or better, FV integration?) could diagnose going out of range, same for enums
Asu has joined ##openfpga
Asu` has quit [Ping timeout: 268 seconds]
Bike has joined ##openfpga
emeb1 has joined ##openfpga
mumptai has quit [Remote host closed the connection]