<rqou> friggin' comcast
<rqou> anybody have recommendations for an ethernet-controllable ac power switch?
<rqou> for automated power-cycling, of course
<azonenberg> Buy a not-shitty modem?
<azonenberg> comcast's business grade modems seem to not suck too hard
<rqou> not my comcast account
digshadow has joined ##openfpga
<pie_> https://youtu.be/CtK4RvX8Kis?t=225 this looks more promising for the hardware than a diy EM
<pie_> well, im no tsure
pie_ has quit [Ping timeout: 240 seconds]
pie_ has joined ##openfpga
<pie_> good book https://imgur.com/a/YBoyB
_whitelogger has joined ##openfpga
Bike has quit [Quit: Lost terminal]
indy has quit [Ping timeout: 248 seconds]
openfpga-bb has quit [Ping timeout: 240 seconds]
indy has joined ##openfpga
azonenberg has quit [Ping timeout: 246 seconds]
Hootch has joined ##openfpga
teepee has quit [Ping timeout: 240 seconds]
teepee has joined ##openfpga
pie_ has quit [Ping timeout: 255 seconds]
<openfpga-github> [openfpga] rqou opened pull request #119: xbpar: Add DumpAsDot debug helper method (master...debug-dump-xbpar) https://git.io/vFnf9
<openfpga-github> [openfpga] rqou closed pull request #115: xc2par: What on earth are we going to do about this mess of a PR? (master...xc2par) https://git.io/v5F9X
nrossi has joined ##openfpga
teepee has quit [Ping timeout: 258 seconds]
teepee has joined ##openfpga
<openfpga-github> [openfpga] rqou opened pull request #120: Import new new new xc2par implementation (master...x-x-x-ng-xc2par) https://git.io/vFntF
<openfpga-github> [openfpga] rqou commented on issue #120: Note that I declared bankruptcy on trying to cleanly sort out the early commits since there were around two other partial attempts embedded in it, so those were turned into a single giant merge. https://git.io/vFnqe
<openfpga-github> [openfpga] rqou commented on issue #120: Note that I declared bankruptcy on trying to cleanly sort out the early commits since there were around two other partial attempts embedded in it, so those were turned into a single giant squashed commit. https://git.io/vFnqe
<rqou> hey azonenberg_work, unlike the last pile of crap, i actually want to merge this WIP code into master
<azonenberg_work> poke me tomorrow
<azonenberg_work> Will look
<rqou> it no longer touches your code at all since it's using a coolrunner-ii specific algo
m_t has joined ##openfpga
teepee has quit [Ping timeout: 248 seconds]
teepee has joined ##openfpga
teepee has quit [Ping timeout: 252 seconds]
teepee has joined ##openfpga
enriq has joined ##openfpga
pie_ has joined ##openfpga
xdeller__ has quit [Quit: Leaving]
teepee has quit [Ping timeout: 240 seconds]
teepee has joined ##openfpga
teepee has quit [Ping timeout: 258 seconds]
teepee has joined ##openfpga
pie_ has quit [Ping timeout: 252 seconds]
eduardo_ has joined ##openfpga
eduardo__ has quit [Ping timeout: 240 seconds]
pie_ has joined ##openfpga
azonenberg_work has quit [Ping timeout: 258 seconds]
jhol has joined ##openfpga
pie_ has quit [Ping timeout: 240 seconds]
teepee has quit [Ping timeout: 248 seconds]
teepee has joined ##openfpga
enriq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
digshadow has quit [Ping timeout: 240 seconds]
Hootch has quit [Quit: Leaving]
moho1 has quit [Quit: WeeChat 1.7.1]
digshadow has joined ##openfpga
azonenberg_work has joined ##openfpga
<rqou> azonenberg_work: any objections to my xc2par code?
<azonenberg_work> Not yet but havent reviewed
enriq has joined ##openfpga
moho1 has joined ##openfpga
moho1 has quit [Client Quit]
moho1 has joined ##openfpga
gnufan has joined ##openfpga
gnufan has left ##openfpga [##openfpga]
<rqou> whitequark: you're familiar with clang+llvm, right?
<rqou> have you ever tried building libunwind for ppc?
<rqou> could you please take a look at this? https://github.com/rust-lang/rust/pull/45422
gnufan1 has joined ##openfpga
nrossi has quit [Quit: Connection closed for inactivity]
<rqou> hey azonenberg_work you should merge my code :P
<azonenberg_work> ^^ _work
<azonenberg_work> after i get back :p
<rqou> oh, you're actually at work
<rqou> it's so weird since you seem to be wfh half the time
<rqou> :P
<azonenberg_work> lol
<azonenberg_work> Yeah i generally actually go to the office ~2 days a week and the rest of the time i'm IDAing at my desk at home
<azonenberg_work> but it varies by gig
enriq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<awygle> "IDA-ing"?
<azonenberg_work> Firmware RE
<awygle> Innovative Device Attack
enriq has joined ##openfpga
<awygle> Oh it's a program, I see
clifford has joined ##openfpga
<azonenberg_work> rqou: re your PR, where do you think it stands?
<azonenberg_work> as far as feature completeness
<rqou> it's a rather-complete skeleton
<rqou> if that makes any sense :P
<rqou> there's plumbing or "unimplemented" asserts in quite a few places, but they exist for all the major features
<rqou> i wanted to merge now because it's no longer a huge mess with a language sandwich
<azonenberg_work> so is it still rust? but saner structure?
<azonenberg_work> or C++
<rqou> it's all Rust
<rqou> not sandwiches with C++/xbpar anymore
<azonenberg_work> ok
<azonenberg_work> oh so 100% standalone?
<rqou> yeah
<azonenberg_work> i really wanted to make more shared code but if you have to do rust this is probably better than a sandwich
<rqou> although exposing a c abi is planned for the future
<azonenberg_work> So can you actually run basic state machines etc?
<azonenberg_work> all the way from verilog to bitstream?
<rqou> not yet
<rqou> a single and gate works though :P
<azonenberg_work> Lol
<azonenberg_work> well thats a start...
<rqou> i want to merge now because it's now standalone
<azonenberg_work> i'll test tonight
<rqou> the sandwich would have been pretty unmergable :P
<azonenberg_work> lol yes
<azonenberg_work> Just saw this
<azonenberg_work> have not had time to look at it yet
<azonenberg_work> but might be worth looking at for RE
<azonenberg_work> ideally i would want a native port that scales better, i doubt the JS would handle huge netlists well
<azonenberg_work> But it looks way better than graphviz as far as rendering of circuits
<rqou> um... i'm not sure how well this will work either
<rqou> svg rendering is waaay slower than i expect
<rqou> hmm azonenberg_work dumb question: on slg46140v can you get away with a greedy PAR?
<rqou> it seems it only has one big fully-connected crossbar?
<azonenberg_work> No, because most of the primitives are mutually exclusiev with another
<azonenberg_work> i.e. a counter may block out a LUT
<azonenberg_work> So you cant place all the luts then all the counters because you may not have any counter sites free
<azonenberg_work> Also, once we get to timing driven PAR i will want to fine tune lut locations etc to optimize performanec
<rqou> wait so the counter and lut are sharing a site?
<rqou> that seems pretty insane
<azonenberg_work> in 46140 almost all of the fun hard IP blocks are dual with a lut or ff site
<azonenberg_work> This applies to most of the gp5 parts too
<azonenberg_work> in fact, better handling of such is one of the things holding back gp5 support
<azonenberg_work> the 4662x is one of the few that does NOT have extreme resource sharing
<rqou> huh azonenberg_work if you have a slg46140v it is exhaustively searchable
<rqou> (slg46620v isn't)
<rqou> hmm maybe not
<azonenberg_work> Pretty sure there's N! possible placements exhaustively :p
<rqou> yeah, but 16! (because there are 16 lut sites) is only on the order of 2^44
<rqou> that's very near exhaustively explorable
<azonenberg_work> not efficiently
<rqou> yeah, hence the "maybe not"
<rqou> i originally thought there were only 8 lut sites because i misread the "Combination Function Macrocells" section
<azonenberg_work> So there's 8 combined sites
<azonenberg_work> then two non-combined DFFs, two non-combined counters, and eight non-combined LUTs
<azonenberg_work> plus a bunch of other hard IP
<azonenberg_work> Some sites are trivial to place, like the shreg is either at LUT3_6 or unused
<rqou> yeah, luts will always dominate
<rqou> also, wtf is up with "Combination Function Macrocells?"
<rqou> super confusing
<azonenberg_work> Thats just what they call two separate logic blocks sharing one routing location
<azonenberg_work> and one set of bitstream bits
<azonenberg_work> anyway i think we should just improve the existing placer i have for greenpak
<rqou> the way the diagram was drawn i initially assumed that it was a totally different type of site
<azonenberg_work> yeah
<azonenberg_work> In greenapk i call this a Greenpak4PairedEntity
<whitequark> rqou: yeah I ported libunwind to a new platform
<whitequark> let me see your thing
<whitequark> libunwind *definitely* should build with clang -intergrated-as
<whitequark> which errors are you getting?
<rqou> "/home/rqou/code/libunwind/src/UnwindRegistersRestore.S:100:17: error: unexpected token" and similar
<rqou> built using: cmake .. -DLLVM_CONFIG=`which llvm-config-6.0` -DLIBUNWIND_ENABLE_SHARED=0 -DCMAKE_TOOLCHAIN_FILE=../test.toolchain
<awygle> azonenberg_work: picked a bad day to go to the office. Is it snowing in the city too?
<azonenberg_work> It was snowing during my bike ride in, and pretty heavily around ulnchtime
<azonenberg_work> seems to have lightened up a bit
<azonenberg_work> i dont see anything right now
<azonenberg_work> But i've biked to/from work in worse
<azonenberg_work> i'll take snow over 33-degree rain any day
<awygle> It's coming down pretty good over here. Glad I decided not to bike today.
<rqou> hmm, apparently my connection dropped
<rqou> anyways, the .toolchain file:
<rqou> set(CMAKE_C_COMPILER clang-6.0)
<rqou> set(CMAKE_CXX_COMPILER clang-6.0)
<rqou> set(CMAKE_C_FLAGS "-target powerpc-linux-gnu -integrated-as" CACHE STRING "" FORCE)
<rqou> set(CMAKE_CXX_FLAGS "-target powerpc-linux-gnu -integrated-as" CACHE STRING "" FORCE)
<rqou> set(CMAKE_SYSROOT /usr/powerpc-linux-gnu)
<rqou> also using packages gcc-powerpc-linux-gnu and libstdc++-7-dev-powerpc-cross (on debian sid)
<rqou> whitequark: i found this person having the same issue, with no replies: http://lists.llvm.org/pipermail/llvm-bugs/2017-January/053054.html
enriq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<whitequark> oh
<whitequark> the integrated asm is just fucked
<whitequark> that's SNAFU
<whitequark> sec
<whitequark> you have an LLVM checkout that you build, right?
<rqou> i don't
<whitequark> (well you will need one)
<rqou> wait, why? i just wanted libunwind
<whitequark> because you'll need to fix clang's integrated ass
<rqou> wtf
<whitequark> what wtf? rust doesn't use binutils for assembling
<rqou> but rust can work with ppc-glibc already
<rqou> i thought ppc-musl would be easy
<whitequark> glibc provides its own unwinder because it has C++, IIRC
<whitequark> or maybe gcc in glibc builds does
<whitequark> I'm not 100% sure
<rqou> so how did this libunwind code ever work?
<rqou> what is it supposed to assemble with?
<whitequark> it was evidently never built with clang -integrated-as
<whitequark> just binutils
<rqou> but binutils doesn't accept that code either
<rqou> which was the original problem
<rqou> that's in the failed travis build on the rust PR
<whitequark> correction
<whitequark> binutils *on Mac OS X*
<rqou> wat
<rqou> binutils changes its syntax depending on host os?
<whitequark> The naked 'r*' and 'f*' register designations are a Darwinism.
<whitequark> SysV notation requires '%r*' and '%f*', or naked numbers.
<whitequark> actually, yes
<whitequark> there's an Apple as dialect
<whitequark> and SysV as dialect'
<rqou> wtf
<rqou> but unlike x86 it doesn't have .apple_syntax/.sysv_syntax?
<whitequark> I haven't a faintest clue
<whitequark> if (isDarwin())
<whitequark> return ParseDarwinExpression(EVal);
<whitequark> no it just looksat the triple
<rqou> what
<rqou> so does libunwind even work on ppc linux? or only on darwin?
<whitequark> the latter
<whitequark> well
<whitequark> it does work on ppc linux if you manage to build it
<rqou> does mach-o use dwarf unwinding?
<whitequark> because UnwindRegistersSave.S is not OS-dependent
<whitequark> yes
<whitequark> Mach-O uses DWARF everywhere
<rqou> er, wasn't there something about ios using sjlj instead?
<whitequark> iOS, yes, macOS, no
<whitequark> it's probably a single-line patch to PPCAsmParser.cpp
<rqou> hmm for the rust PR it seems the easiest way is to just convert the .S files to sysv syntax
<whitequark> do it properly
<rqou> meaning?
<whitequark> teach LLVM's as to parse UnwindRegisters*?
<rqou> but that can break other things
<whitequark> that is?
<rqou> hmm actually no, it shouldn't
<rqou> rich felker (who does musl) told me that there is a convention on ppc to do "#define r0 0" and similar
<rqou> but that gets preprocessed before as runs, so there should be no problem in theory
<whitequark> yes
<rqou> hmm, but just patching libunwind gets the code out faster and potentially with less bikeshedding
<whitequark> you need to, hmm
<rqou> also, "If handwritten asm includes an identifier like lo16 then all bets are off - but no-one would do that, right?"
<rqou> why do i need to patch llvm?
<rqou> as long as libunwind builds, i should be able to continue?
<whitequark> well
<whitequark> check if binutils treats # on ppc as a start of a comment
<whitequark> then just replace ; with #
<whitequark> or even better
<whitequark> use //
<whitequark> since it's preprocessed
<rqou> anyways, isDarwin feels like a giant hack
<rqou> there must be some historical reason for this?
<whitequark> probably
Zorix has quit [Quit: Leaving]
Zorix has joined ##openfpga
m_t has quit [Quit: Leaving]
Bike has joined ##openfpga
gnufan1 has quit [Quit: Leaving.]
<rqou> wtf
<rqou> powerpc libunwind restores the "ctr" loop count register
<rqou> and then immediately trashes it
azonenberg_work has quit [Ping timeout: 258 seconds]