<hackerfoo>
Other contributors are welcome, though. Development is done in the open through public GitHub repos and a public IRC channel, and there are many smaller tasks for people who can't work on the project full time.
Bike has quit [Quit: Lost terminal]
<hackerfoo>
The team at Google is small (4 people), so any help is appreciated.
rohitksingh has joined ##openfpga
pie_ has joined ##openfpga
rohitksingh has quit [Ping timeout: 245 seconds]
_whitelogger has joined ##openfpga
Jybz has joined ##openfpga
<pepijndevos[m]>
Need to scroll back further later but this hls talk is really fascinating
<pepijndevos[m]>
I has this course about DSP algorithms and it had all these retiming and scheduling algorithms, and I kept thinking there should be a way to use this power without something stupid like compiling c++ to hdl
<pepijndevos[m]>
And it's the kind of innovation I am exited to see as a result from open source synthesis tools
pie_ has quit [Ping timeout: 276 seconds]
Jybz has quit [Quit: Konversation terminated!]
Miyu has joined ##openfpga
hackkitten has quit [Ping timeout: 276 seconds]
hackkitten has joined ##openfpga
Miyu has quit [Ping timeout: 265 seconds]
mkru has joined ##openfpga
emeb_mac has quit [Ping timeout: 240 seconds]
mkru has quit [Remote host closed the connection]
<azonenberg>
hackerfoo: oh, that's public knowledge now?
<azonenberg>
back in the early days it was a kind of "black project" with people laundering commits through private gmail addresses etc because google didnt want to risk getting sued or something
<azonenberg>
people were on company time working on the project but in a deniable fashion
OmniMancer has joined ##openfpga
pie_ has joined ##openfpga
hackkitten has quit [Quit: Leaving]
hackkitten has joined ##openfpga
<daveshah>
Pretty sure this is the first time it's been mentioned in public
ym has joined ##openfpga
<hackerfoo>
You can easily check which GitHub users are contributing Google-owned code because they should be part of the Google organization on GitHub.
<hackerfoo>
We use our personal email because because it seems more in the spirit of open source, and some of us had existing open source work.
<daveshah>
Mmm, I've had some trouble with demarcating work and non-work code; with my former employer taking a lot of credit for stuff I did in my own time and somewhat against the will of my employer
<hackerfoo>
Google has a process for formally approving personal projects, which I followed for PoprC.
<hackerfoo>
And there's some protection under California law, but it has a giant hole in it, so it's best to get approval in writing.
<daveshah>
It's not so much credit as a legal sense as much as behaving as if it's their project when in many ways it isn't
<hackerfoo>
There's not much you can do about that in a nice way, if they aren't willing to talk about it.
<daveshah>
Indeed, I have left them anyway now for a few other reasons
<emily>
lol, typical google NDA stealth on display
<emily>
what happened to people being afraid to even reference codenames?
vup2 has quit [Quit: No Ping reply in 210 seconds.]
TD-Linux has quit [Ping timeout: 245 seconds]
GityUpNow has quit [Ping timeout: 245 seconds]
grantsmith has quit [Ping timeout: 245 seconds]
grantsmith has joined ##openfpga
grantsmith has quit [Changing host]
grantsmith has joined ##openfpga
linzhi-sonia has quit [Ping timeout: 245 seconds]
eightdot has quit [Ping timeout: 245 seconds]
vup has joined ##openfpga
TD-Linux has joined ##openfpga
linzhi-sonia has joined ##openfpga
eightdot has joined ##openfpga
pepijndevos has quit [Ping timeout: 240 seconds]
<hackerfoo>
emily: SymbiFlow is a public project. No NDAs needed.
<hackerfoo>
But I want to be clear that I don't speak for the company or the project.
pepijndevos has joined ##openfpga
<hackerfoo>
I just want to promote it so we can get more contributors.
<hackerfoo>
PoprC is NOT a Google project, and was started long before I joined Google.
<hackerfoo>
I guess I promote PoprC mostly just because I like talking about it.
<nats`>
hackerfoo, maybe changing the name one day will be a good idea :D
<nats`>
I can't find anything on google even by adding fpga, hdl or language
<hackerfoo>
popr.dev
<hackerfoo>
It doesn't have a lot of users yet :)
<hackerfoo>
My next goal is adding an AXI interface so I can put a bunch of functions written in Popr on an FPGA card in my computer and pipe data through them.
<nats`>
just took a quick look is it a stack based language ?
<hackerfoo>
Because that would be cooler than using LEDs and switches.
<pepijndevos>
The idea that this would map nicely to HDL is something I have not considered
<hackerfoo>
I think of each word as building a graph rather than manipulating a stack.
<pepijndevos>
Right
<pepijndevos>
Trying to remember what this Hadoop thing was that was basically very stream oriented
<hackerfoo>
I was surprised how easy the IR was to convert to Verilog. In some ways it's easier than C.
<pepijndevos>
Maybe Cascalog, Stork, or Spark, at least something stream oriented.
Asu has joined ##openfpga
Asu has left ##openfpga ["Konversation terminated!"]
freemint has quit [Ping timeout: 245 seconds]
freemint has joined ##openfpga
cr1901_modern has quit [Ping timeout: 240 seconds]
genii has joined ##openfpga
<GenTooMan>
sigh sometimes yosys can be very frustrating.
<ZirconiumX>
GenTooMan: How os?
<ZirconiumX>
*so
freeemint has joined ##openfpga
freemint has quit [Read error: Connection reset by peer]
<GenTooMan>
It loves to optimize things but is too aggressive. This kind of troubles reminds me of the issue (2011-2013) in the optimizer in C/C++ ignoring the volatile keyword meaning and removing reads and writes that were required.
<emily>
that "issue" in C++ has never gone away and volatile is being deprecated in the latest standard
<whitequark>
the solution is obviously to not use verilog for anything
<ZirconiumX>
I'm sure pepijndevos will be happy to hear that
<ZirconiumX>
:P
<whitequark>
i'm not sure vhdl is much better to be honest :p
<pepijndevos>
I've not had any footnuke experiences with vhdl ;)
<whitequark>
there are verilog programmers who don't have any such experience with verilog
<whitequark>
you kinda have to go beyond n=1
<GenTooMan>
whitequark that's why I have been working with nmigen instead.
<daveshah>
ime, Yosys doesn't optimise enough for 50% of things and optimises too much away for the other 50%
<daveshah>
Therefore it's perfect :p
<pepijndevos>
Well, most behavior seems pretty sane, explicit, and well defined. Stuff like signedness, wire/register, sync/async, casting, where Verilog just silently does the oposite of what I want 9/10 times.
<whitequark>
ok, let me rephrase
<whitequark>
vhdl is much better than verilog in many ways, but i'm not sure if it's good enough
<pepijndevos>
(not claiming vhdl is perfect)
<whitequark>
then again being much better than verilog is such a low bar
<pepijndevos>
Oh definetely. The number one reason I'm excited about open source synthesis is to have some innovation on the language font.
<whitequark>
have i mentioned a cute idea i've had here?
<whitequark>
being able to instantiate nmigen modules from verilog
<whitequark>
(with yosys)
<ZirconiumX>
nmigen is more or less a frontend for direct RTLIL
<pepijndevos>
Uh... not knowing nmigen, what currently stops you from instantiation nmigen modules in verilog?
<mwk>
pepijndevos: parametrization, basically
<whitequark>
^
<mwk>
when you instantiate a parametrized module in verilog, yosys basically has to do something like template instantiation in c++
<ZirconiumX>
Unrelated, but since daveshah is around: for the ECP5 a PFUMX is a mux for two LUT4s into a LUT5, and a L6MUX21 is a mux for two LUT5s into a LUT6, right?
<mwk>
doing that with nmigen would require actually calling from yosys into nmigen
<whitequark>
yep
<whitequark>
i want to make it generic
<whitequark>
something like a blackbox
<daveshah>
ZirconiumX: Yes, although L6MUX21 is also used for LUT7s out of two LUT6s
<pepijndevos>
So you'd basically add a `read_nmigen` command to yosys?
<whitequark>
but yosys knows to call some filter process to get the body of the blackbox
<whitequark>
nope
<whitequark>
it would be driven entirely without yosys scripting
<whitequark>
you'd say something like...
<ZirconiumX>
daveshah: Cheers, and interesting to note
<mwk>
pepijndevos: that also applies to vhdl and verilog interworking, btw
<mwk>
you can get to fun stuff like vhdl in turn instantiating a verilog parametrized module
<pepijndevos>
mwk, yea... I noticed. This is something ghdl does not do yet.
<mwk>
so basically whatever manages the whole synthesis has to be able to call both frontends at will, until the whole thing converges
<daveshah>
It gets even more fun when you consider hierarchical references too (not that Yosys supports them in most cases anyway)
<mwk>
well, not converges, just ends...
<pepijndevos>
Hmmm, I think it'd be nicer if it'd work the same as verilog modules, rather than filter magic. So you can just read_verilog and read_nmigen and read_vhdl all the things and have them refer to each other.
<whitequark>
pepijndevos: that's impossible
<whitequark>
(well, for read_nmigen)
<pepijndevos>
why?
<whitequark>
an nmigen design is just a bunch of python files
<whitequark>
you can't extract even the list of modules from it
<whitequark>
hmm
<whitequark>
but maybe it *should* be possible
<whitequark>
so we'd have something like
<whitequark>
"this nmigen file is an entry point and it lists exactly the modules that can be instantiated if you read_nmigen it"
<whitequark>
well, it'd be less "read_nmigen" and more like "read_rpc", right?
<mwk>
hmm
<mwk>
sounds nice
<whitequark>
so if you do `read_rpc [cmdline]` then the command at [cmdline] is called and tells yosys which blackboxes it provides
<daveshah>
Or, generate an RTLIL file with blackboxes and the process to call
<mwk>
or "connect_rpc"? we're not really reading anything
<whitequark>
daveshah: one problem with that is ports
<daveshah>
That's managed for Verilog
<whitequark>
i mean
<emily>
it'd be nice to have a protocol based on JSON or protobufs or just... anything other than CLI back and forth, especially since there will be plenty of potential setup cost / optimization opportunities for multiple instantiations
<pepijndevos>
I mean... a frontend takes source code an produces RTLIL, the fact that nmigen has to invoke Python to produce code doesn't seem that relevant?
<emily>
tbh I'd rather it be more like read_nmigen for the user and that's defined in terms of some lower-level RPC thing the user doesn't have to think about
<whitequark>
daveshah: does a yosys blackbox have to declare ports upfront?
<whitequark>
i guess not
<whitequark>
since you can use generate statements for that in verilog
<emily>
pepijndevos: but nmigen modules can make decisions in Python code based on the things it's parameterized over
<mwk>
I... think so?
<mwk>
hm
<emily>
pepijndevos: so an instantiation later in Verilog can cause the need to execute different Python code
<mwk>
but that probably depends on where in the process you are, and I've only been working on the later step
<emily>
it can't just be a one-pass thing
<mwk>
s
<pepijndevos>
emily, but as I understand, verilog also does this, where it produces rtlil but keeps the source around for if you initiate it later with different generics.
* mwk
looks at hierarchy pass
<whitequark>
pepijndevos: yosys has built-in knowledge of verilog
<whitequark>
yosys does not have built-in knowledge of nmigen
<emily>
ah, ok. I imagine that involves a lot of built-in knowhow about Verilog in Yosys though
<daveshah>
whitequark: abstract modules from read_verilog -defer don't have ports
<emily>
I doubt you could do something quite so fluent with CPython
<whitequark>
when yosys needs to instantiate a verilog abstract module, it effectively calls into itself
<whitequark>
and by definition it has more visibility into itself than into nmigen
<whitequark>
daveshah: oh hm, what do they do have?
<pepijndevos>
whitequark, so can't this built-in knowlege be extended for vhdl and nmigen and other things?
<daveshah>
whitequark: literally just the module name (and src attribute)
<whitequark>
pepijndevos: why should it be?
<daveshah>
e.g. for picorv32.v
<daveshah>
autoidx 1
<daveshah>
attribute \src "picorv32.v:2809"
<daveshah>
attribute \cells_not_processed 1
<daveshah>
module $abstract\picorv32_wb
daveshah has quit [Excess Flood]
daveshah has joined ##openfpga
<pepijndevos>
Seems like eventually you'd want to be able to cross-instantiate modules between languages
<whitequark>
does yosys really have to intrinsically understand nmigen, clash, hardcaml, chisel, and whatever new hdl someone comes up with in a year?
<emily>
whitequark: because C++ is a richer glue than shell and text IO
<emily>
you could still make integration for a new language fairly lightweight and easy
<emily>
but not needing to recompile yosys doesn't seem like an obvious goal
<daveshah>
Yosys does already have plugin support
<emily>
especially when glasgow is pinning specific yosys versions anyway
<daveshah>
(using .so)
<whitequark>
emily: glasgow is irrelevant here
<pepijndevos>
whitequark, well, not built-in, but it'd be useful if a module could teach it about his
<whitequark>
there won't be any verilog in glasgow
<pepijndevos>
*this
<whitequark>
only nmigen
<emily>
I think using IPC of some sort of reasonable, but it should be some proper JSON protocol or something rather than a super ad-hoc "run this command line in the shell" thing.
<whitequark>
emily: i mean, obviously? you still have to tell it where to find what it needs to run
<emily>
or it could just communicate over a unix socket or whatever
<whitequark>
yeah good luck doing that on windows
<emily>
modulo portability concerns but my point is that one process for instantiation isn't going to scale very well
<emily>
you kind of want one python process doing all the instantiations and not re-evaluating your whole design every time
<whitequark>
yes
<whitequark>
that's what i'm saying
<whitequark>
14:32 < whitequark> but maybe it *should* be possible
<whitequark>
14:32 < whitequark> so we'd have something like
<whitequark>
14:32 < whitequark> "this nmigen file is an entry point and it lists exactly the modules that can be instantiated if you read_nmigen it"
<whitequark>
14:33 < whitequark> well, it'd be less "read_nmigen" and more like "read_rpc", right?
<gruetzkopf>
unix socket server would work in modern windows
<mwk>
pepijndevos: what.... what have you done
<pepijndevos>
XD
<GenTooMan>
he didn't implement prolog horn clauses at least?
freeemint has quit [Ping timeout: 245 seconds]
<GenTooMan>
I suppose how to pronounce nmigen would be "interesting" but it probably doesn't matter, ... yet. People aren't arguing over how to pronounce it just using it, which I think is a better use of time.
<hackerfoo>
About adding other support for other languages to Yosys, maybe it can be decomposed into a set of synthesis libraries, the same way LLVM isn't a single compiler, but a set of libraries for making compilers.
<hackerfoo>
Then nmigen could work with these libraries through Python's FFI.
<daveshah>
I believe Yosys can already be used like this
<daveshah>
it can be built as a shared library and even used as a Python module (although the latter is a bit experimental)
<whitequark>
this suggestion severely overestimates how easy it is to get FFI to work
<whitequark>
LLVM's public interface is its C API (which I maintain), and it's still quite difficult to use it reliably
<whitequark>
Yosys' public interface is RTLIL
<whitequark>
so if you wanted Yosys to expose RTLIL programmaticaly to FFI, you'd have to define a C API on top of it
<emily>
(this is why I was suggesting JSON RPC)
<whitequark>
in case of LLVM, some people emit textual LLVM IR, but it doesn't have any guarantee of stability, whereas its C API does
<whitequark>
in case of Yosys there is something of an opposite situation, it has an unstable C++ API, and stable-ish RTLIL
<hackerfoo>
whitequark: RTLIL won't allow interaction between frontends, right?
<whitequark>
define interaction
<hackerfoo>
If it's just generating IR, that's easier than an API.
<hackerfoo>
But you need something more if you want calls between frontends to pass parameters.
<whitequark>
sure, so what i'm saying is that yosys can mediate it
<hackerfoo>
What you really need is a sort of linker.
<whitequark>
a linker for RTLIL is called `cat`
<hackerfoo>
But I guess Python code could do anything with the parameters, hence iteration.
<whitequark>
no, not at all, i don't think
<whitequark>
look at how verilog abstract modules work
<hackerfoo>
whitequark: it's called place and route.
<whitequark>
shrug. you could make any sort of useless comparison with machine code toolchains. that's not insightful at all.
<hackerfoo>
But I mean, the way that linkers can resolve symbolic locations.
<mwk>
synthesis is not compilation
<whitequark>
consider how abstract verilog modules work in yosys
<mwk>
there are some parallels, but expecting everything to have an equivalent is just misleading yourself
<hackerfoo>
Yeah, it's all really loose analogies. Let's stop.
<whitequark>
yosys sees an instance -> yosys calls back into (its own) verilog frontend with a list of parameters -> yosys integrates the RTLIL returned by frontend back
<whitequark>
now, consider how abstract (as in generic) nmigen modules would work in yosys
<mwk>
but if you really want a parallel
<whitequark>
yosys sees a (foreign, nmigen) instance -> yosys calls back into (foreign) nmigen frontend (via rpc) with a list of parameters -> yosys integrates the RTLIL returned by frontend back.
<mwk>
imagine you want to use STL, the C++ library, from rust
<hackerfoo>
The point is, if you could defer parameters to a deterministic solver (not Turing complete), it could be used by any language.
<mwk>
a linker won't help you with that
<emily>
mwk: I really don't want to imagine that.
<hackerfoo>
And then just have nmigen emit constraints for the solver.
<whitequark>
that's never going to work even for verilog
<whitequark>
verilog elaboration isn't deterministic, you can read files.
<emily>
hackerfoo: basically you're saying yosys should handle all the parameterisation in RTLIL?
<whitequark>
or just use DPI-C
<emily>
that's basically asking it to take up the mantle of a sufficient HDL itself
<emily>
which is difficult when there's such a large degree of parameterization in existing designs that depends on executing real-world Python code etc. to resolve
<mwk>
also, verilog parameter instantiation is probably Turing-complete alreadt
<emily>
you'd then be in the business of compiling Python to something-like-generic-Verilog/VHDL
<emily>
and at that point probably whitequark quits
<whitequark>
oh, i've already considered and rejected that idea
<hackerfoo>
emily: Yeah, I guess. Is solving for parameters really that complex? I haven't used migen/nmigen.
<whitequark>
nonstarter
<emily>
hackerfoo: a parameter is literally just a Python variable.
<emily>
it could be a boolean or whatever.
<emily>
you can branch on it.
<emily>
you can branch on arbitrary Python computations made with it.
<emily>
you'd have to translate arbitrary Python code to the IR, in other words.
<whitequark>
in practice, it is common for nmigen parameters to e.g. influence port names and widths
<emily>
so you can no longer be a simple Python eDSL
<hackerfoo>
Sure, but does it need to be?
<emily>
unless you want to completely change the architecture
<emily>
and make nmigen a fundamentally different kind of language
<whitequark>
it would be extremely challenging, if possible at all, to represent even that simple transformation in RTLIL
<emily>
(also, in practice compiling arbitrary Python would be intractable.)
<whitequark>
hackerfoo: don't forget that your architecture *doesn't even work for Verilog*
<whitequark>
(and I assume VHDL too)
<whitequark>
since you can do all these things just fine in plain old Verilog
<hackerfoo>
I haven't used either much yet, so I haven't explored the dark corners, but I'm a big fan of simple languages.
<hackerfoo>
And also provable termination (non-Turing complete subsets.)
<whitequark>
simple languages can be nice if you never go outside of the domain they're tailored for
<mwk>
hackerfoo: they you're not in luck
<whitequark>
if you need something more complex, you're stuck in a puzzle, trying to express what you need
<emily>
hackerfoo: I think any proposal which makes yosys unable to compile Verilog can be safely summarized as a non-starter.
<whitequark>
i'm not interested in puzzles
<emily>
you can feel free to create your own useless toolchain that works with no existing HDLs though
<mwk>
since expanding verilog parametrized modules is already turing-complete
<hackerfoo>
Yeah, I guess.
<hackerfoo>
It's not something I plan to work on, so these are just half-thought out ideas.
<emily>
don't get me wrong, I like provable termination too
<emily>
but I don't think HDL parameterization is simple enough to delegate to a lowest-common-denominator IR.
<whitequark>
^
freeemint has joined ##openfpga
<emily>
there are very flexible forms of metaprogramming being used extensively in practice for hardware
<daveshah>
I do think it might be interesting to have something that can handle a _subset_ of what parametrisation allowed
<emily>
and it's not too viable to reduce the power and flexibility of metaprogramming when the "target" (hardware) is so fundamentally weak and fixed at runtime
<daveshah>
To allow formal verification of modules/map rules for all possible parameter values
<whitequark>
yes
<mwk>
hmm
<mwk>
that would be nice
<whitequark>
that is something i'm interested in
<whitequark>
but i don't have the first clue of how to actually do it for real designs
<whitequark>
and i suspect yosys will not be the place where this happens
<daveshah>
`for` loops create a bit of a problem
<whitequark>
you'd probably have to build a new FV-oriented toolchain from scratch
<emily>
daveshah: yeah, a system that did try to solve these kinds of problem would be interesting
<emily>
and tbh I'd love to work on one
<daveshah>
The simplest hack would be turning parameters into extra "inputs" and just creating circuits for generates
<emily>
but it's a large enough project in complexity and scope of unsolved problems that you'd hope you'd get a degree or grant or two out of it :v
<whitequark>
daveshah: :/
<whitequark>
i guess that could work
<emily>
beautiful
<daveshah>
Making width-generic implementations of operators would be "fun"
<emily>
nand-oriented computing
<emily>
RTLIL partial evaluator
<emily>
lambdaRTLIL.
<whitequark>
yeah
<whitequark>
i feel like embedding "soemthing like RTLIL" in "something higher-order" would be nice
<emily>
ok how about we embed "literal RTLIL" in "Tcl which is higher-order because you have strings"
<emily>
think of the code reuse
<mwk>
aaaaaaaaaa
<whitequark>
;w;
<emily>
verilog parameterization is not strong enough to parameterize stuff by other circuits, right? i.e. in a higher-order way
<emily>
nmigen, clash, etc. can do that but I guess it just won't be exposed to other languages
<mwk>
emily: aaaaaaaaaaaa
<emily>
I feel like those are the truly useful kinds of parameterization but interoperation for them sounds ... difficult.
<mwk>
hm
<emily>
mwk: what have you got against abstractions? ;w;
<mwk>
oh wait, you mean like passing a module name to use as a submodule by your module?
<mwk>
then not aaaaaa, that actually sounds very nice
<mwk>
I thought you wanted to introspect the circuit contents from verilog...
<emily>
:D
<emily>
that *does* sound exciting but not quite what I was proposing, no
<emily>
but yeah, more like being able to pass modules around
<emily>
and even generate modules dynamically on the fly
<daveshah>
You can do a lot of horrible things with the Yosys "scripts in wires" extension
<mwk>
what exten... oh
<daveshah>
`script -scriptwire`
Sellerie has quit [Quit: Ping timeout (120 seconds)]
<daveshah>
Sadly it doesn't support here-documents (unlike usual Yosys scripts), so Verilog-in-Verilog isn't possible
<emily>
;w;
<emily>
I just want to remind everyone that the International Criminal Court can read the logs to this channel.
<mwk>
arrested for metaprogramming crimes?
freeemint has quit [Ping timeout: 264 seconds]
<GenTooMan>
same goes with numerous spy agencies across the world.
<hackerfoo>
`in0`/`out0` is the input/output. Notice that it toggles `in0_ready` but not `out0_valid`, so `[1 2 3...]` becomes `[1 1 2 2 3 3 ...]`
promach has joined ##openfpga
<hackerfoo>
This is one kind of higher order function that even Haskell can't do.
<pepijndevos>
hackerfoo, I'm trying to read your tutorial, but I don't really get the : False not [] pushl example
Sellerie has joined ##openfpga
<pepijndevos>
Oh wait maybe I get it... so in the first example there is a False, and the push connects it to the not, and in the second example false not are already connects, and the whole connected thing gets connected into the block??
<pepijndevos>
Now trying and failing at the swab example...
rohitksingh has joined ##openfpga
<pepijndevos>
Every time I think I've got it I en up with no result at all, an error, or the same thing I started with. My basic approach is to pop them out of the box, swap them, and push them back...
<pepijndevos>
But something about how things connect and in what order is broken in my head
<hackerfoo>
pepijndevos: So, I changed the behavior of the repl since I wrote that.
<hackerfoo>
Because people were failing on the `swab` exercise, but I guess I broke what I was trying to illustrate with `False not [] pushl`.
<hackerfoo>
Type `:lim 1` to fix it.
<pepijndevos>
So what changed?
<hackerfoo>
The compiler doesn't reduce inside quotes, but the repl will reduce up to the limit, so that the printed result makes more sense.
<hackerfoo>
To understand why the `:lim 1` behavior can be frustrating, try `[1 2 3] [+] map`
<pepijndevos>
What does it mean to reduce inside quotes?
<pepijndevos>
Eh... I get not result
<hackerfoo>
The result is correct from PoprC's point of view, because a quote that isn't consumed (by taking it apart with ap) doesn't need to be computed.
<hackerfoo>
You should get `[...]` with `:lim 1`, but `[2 3 4]` with a higher limit.
<pepijndevos>
Eh nope, no result with anything I try
<hackerfoo>
Oh, sorry: `[1 2 3] [1+] map`
<pepijndevos>
ahhh
<pepijndevos>
I still don't get how that relates to the other two examples...
<hackerfoo>
Popr is aggressively lazy. You can think of quotes of holding suspended computations, possibly missing inputs.
<pepijndevos>
What's the "correct" way to write swab?
<hackerfoo>
*of quotes as
<hackerfoo>
Any way that works should be equivalent.
rohitksingh has quit [Ping timeout: 245 seconds]
<hackerfoo>
This is the case for most simple functions.
<pepijndevos>
I just want to be blown away by your superior solution, compaerd to my dozen steps
<pepijndevos>
Oh, need to go. Will catch up later.
rohitksingh has joined ##openfpga
<hackerfoo>
You can check with `:bc swab`. You should get equivalent bytecode however you implement it.
<hackerfoo>
I would just write `[swap] .`, but I didn't introduce `.` yet.
<hackerfoo>
For fun, you can look at the Verilog it generates with `:cv swab`.
pie_ has quit [Ping timeout: 276 seconds]
Jybz has quit [Quit: Konversation terminated!]
<hackerfoo>
A version not using `.` is `swab: popr swap popr swap pushl pushl`
<hackerfoo>
Ah, but the bytecode isn't equivalent.
<hackerfoo>
This is because they *are* different, try `[A B C]`.
<hackerfoo>
So `swab` was not well specified.
<hackerfoo>
So there's a bug and a half in my tutorial.
ym has joined ##openfpga
rohitksingh has quit [Ping timeout: 240 seconds]
pie_ has joined ##openfpga
rohitksingh has joined ##openfpga
rohitksingh has quit [Ping timeout: 265 seconds]
rohitksingh has joined ##openfpga
emeb_mac has joined ##openfpga
gnufan_home has joined ##openfpga
<TD-Linux>
is there a recent comparison of diamond vs nextpnr anywhere? I personally don't care but might be handy for replying to haters
<whitequark>
well, for one, you don't have to crack nextpnr to use it.
<TD-Linux>
yeah tbh arguing about routing quality is a great position to be in. it means that all the more important problems are solved :)
rohitksingh has quit [Ping timeout: 265 seconds]
mumptai has quit [Quit: Verlassend]
freeemint has quit [Remote host closed the connection]