<cr1901_modern> azonenberg: Private branch
doomlord has joined ##openfpga
d3bug has joined ##openfpga
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined ##openfpga
<pointfree> Anyone have recommendations for articles on the topic of CPLD timing constraints, etc? I'd like to educate myself in advance. It's what I currently know the least about. Google is turning up mostly Xilinx support pages and whatnot.
maaku has quit [Read error: Connection reset by peer]
maaku has joined ##openfpga
maaku has quit [Read error: Connection reset by peer]
maaku has joined ##openfpga
d3bug has quit [Quit: Leaving]
C47 has joined ##openfpga
doomlord has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
doomlord has joined ##openfpga
C47 has quit [Quit: Leaving]
cosmobird has joined ##openfpga
Bike has quit [Quit: despoil]
cosmobird has quit [Ping timeout: 276 seconds]
doomlord has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<azonenberg> whitequark: i did not change any github settings
<azonenberg> Just got back from my trip
<azonenberg> Ping me tomorrow to discuss and we'll figure it out
<azonenberg> Also, i never intended to replace openfpga's build system with splash
<azonenberg> there's no point, it's not a massive project with hundreds of bitstreams etc
<azonenberg> Which is one of the reasons why the commit bot for the splash repo logs to #antikernel and not here :p
<whitequark> right, i fully agree, so that's great
<whitequark> i'll take a look further at travis
<whitequark> ah hm, i'll need your assistance since i deleted the privkey (as i should have)
<azonenberg> Make a new key and i'll add it
<azonenberg> and remove the old one
<azonenberg> Basically, splash is meant to be used for projects where the benefits of parallel build and caching outweigh the complexity of setting it up
<azonenberg> as well as for projects that target dozens of language-architecture combinations and would be difficult to do well in another system
<azonenberg> For something that's straight cross-platform C++ 11?
<azonenberg> pointless
<azonenberg> I intend to continue using cmake for such things indefinitely
firebird_ has joined ##openfpga
azonenberg_work has joined ##openfpga
<cr1901_modern> azonenberg: Then I prob misinterpreted what you were saying when you intended to use Splash for your projects
<azonenberg> Yeah
<azonenberg> It was designed for antikernel
<azonenberg> If i or anyone else find it useful for other stuff, then so much the better
<azonenberg> Where it really shines is when you're doing unit and integration testing, and CI, on FPGA designs
<azonenberg> especially if you have multiple target devices, a cluster of x86 boxes to build on, a cluster of FPGAs to test on, and enough binaries and tests to actually benefit from that
<cr1901_modern> fair enough
<cr1901_modern> In any case, I recall you mentioning that you didn't intend to support native Windoze builds of openfpga until "some milestone was reached" (and I thought that milestone was migrating to Splash). I just decided to expedite that process :P.
<azonenberg> It's more, I don't use windows
<azonenberg> i have only a few windows VMs
<azonenberg> and no incentive to support it
<azonenberg> If somebody, like you, wants to maintain the windows build for it
<azonenberg> great
<azonenberg> I'm not intentionally writing the code to be platform specific
<azonenberg> in fact the other day me and... whitequark? were talking about making it capable of running on like a cortex-m3 or something eventually
<azonenberg> Not sure if we'd ever slim it down that much but it remains on the potential roadmap
<cr1901_modern> Cortex M3? Does (MMU) Linux run on that?
<azonenberg> No
<cr1901_modern> "azonenberg: I'm not intentionally writing the code to be platform specific" I know that. I still have... feelings about cross platform code.
<azonenberg> i was talking about bare metal
<azonenberg> like, a stm32
<azonenberg> being able to do runtime reconfig on (eventually) a greenpak5 or a coolrunner
<whitequark> yeah we did
<cr1901_modern> Ahhh that's an interesting idea. How complex is it to add C++ runtime/STL to a micro?
<whitequark> it's not
<whitequark> just build libc++ for it
<whitequark> I evne know someone who did C++ EH on an M3
<azonenberg> yeah its more, we'd need to remove references to filesystem APIs etc or at least move to an abstraction layer of some sort
<azonenberg> etc
<whitequark> azonenberg: no
<whitequark> just build with LTO :p
<rqou> apparently linux for cortex-m exists
<azonenberg> Anyway, that is not a short term priority
<azonenberg> more of, would be cool one day
<rqou> also, i totally tested c++ with EH on cortex-m, works
<cr1901_modern> Why would any subject themselves to implementing C++ EH if they're not being paid for it?
<rqou> in my experience it "just works"
<rqou> as long as your linkscript is correctly including unwind info sections
<whitequark> cr1901_modern: well are you getting paid for using windows?
<whitequark> rqou: ime it's slightly more involved
<rqou> idk then, i only barely tested it
<whitequark> you need PT_EH_FRAME_HDR to be generated by the linker
<cr1901_modern> "(5:04:39 AM) whitequark: just build with LTO :p" <-- Joke went over my head.
<whitequark> *PT_GNU_EH_FRAME is the canonical name
<whitequark> and thne you need to emulate dl_iter_phdr or something
<cr1901_modern> And wouldn't the linker bomb if you didn't include the unwind sections in your linker script anyway?
<whitequark> but it's not too bad
<cr1901_modern> As opposed to "just crashing at runtime b/c it choked on lack of EH code"
<whitequark> nah. linker scripts are permissive
<cr1901_modern> Oh FFS
<whitequark> LTO will optimize out all references to OS APIs if you don't actually transitively use them
<cr1901_modern> Ahhh, right. Makes sense :)
<azonenberg> whitequark: what i meant is, parts of the code that read netlist files etc
<azonenberg> would need to be rewritten
<azonenberg> Depending on how much of the stack we ported
<whitequark> ah yeah, sure
<azonenberg> i'm assuming, we would not port the verilog flow to cortex-m
<azonenberg> only the par
<rqou> you can use newlib to provide os apis if you don't mind how potentially-incorrect newlib is :P
<azonenberg> and you'd have to generate the netlist in C/C++ code procedurally
<whitequark> rqou: unnecessary bloat
<whitequark> azonenberg: not even necessarily generate
<whitequark> adjust analog parameters, for example
<azonenberg> Yeah, that works too
<whitequark> or counter values
<azonenberg> Store yosys output
<whitequark> could probably do that without full PAR
<cr1901_modern> whitequark: If your input ELF files had the unwind sections, but your linked script didn't specify where unwind sections should go, what does the linker do?
<azonenberg> then just patch it as needed
<azonenberg> Yes you totally could
<whitequark> cr1901_modern: it puts them somewhere
<rqou> it doesn't just ignore them?
<whitequark> iirc, no
<cr1901_modern> I never actually tried it. Though I have a toy LPC810 linker script I could play with
<rqou> iirc objcopy at least would be confused
<whitequark> here's a toy linker script for you:
<whitequark> SECTIONS {}
<whitequark> done
* cr1901_modern makes a note to try that later. I don't imagine the code would run tho ;)
<rqou> (this is going to _really_ give away how i learned embedded :P ) i use a highly-hacked version of this:
<cr1901_modern> Yea my script is less than 1/4 of that length
<rqou> in general my gcc for arm is a (horribly ugly and unpublished) hack that is mostly derived from devkitPro
<rqou> with some stuff acquired from summon-arm-toolchain (abandoned)
<rqou> and some bits and pieces picked up from the internet over the years
<cr1901_modern> __vectors_start=ORIGIN(vectors); Yes that tells me a lot. How about actually giving me an address?
<whitequark> ohhh
<whitequark> you don't need dl_iter_phdr with ARM EH, I guess
<whitequark> since it has __exidx_start
<whitequark> not sure what it does with shared object
<rqou> doesn't really work on embedded?
<whitequark> rqou: presumably you're using an existing unwinder?
<whitequark> cr1901_modern: the address is in a separate file that just defines REGIONS{}
<rqou> i think somewhere in libgcc/newlib/libstdc++ there is an unwinder
<rqou> i don't actually use exceptions or c++ on microcontrollers
<rqou> i was just testing what would happen
<rqou> (i was even throwing a float rather than a "real" exception)
<whitequark> rqou: >.jcr
<whitequark> seriously?
<whitequark> you're caring about gcj?
<rqou> i didn't write it ok
<rqou> :P
<whitequark> throwing a primitive is perfectly legal btw
<cr1901_modern> https://github.com/devkitPro/buildscripts/blob/master/dkarm-eabi/crtls/ds_arm9.mem Looks like it's called MEMORY here. An alias?
<whitequark> er yes, MEMORY it is called
<cr1901_modern> I didn't see an include directive in the linker script proper, so I got confused.
<rqou> the .specs file somehow references both
<whitequark> oh dear god, gcc specification files
<whitequark> that makes perl look readable
<rqou> one of azonenberg's buddies even hacked their university autograder system using gcc specs files :P
<whitequark> ... how
<whitequark> don't you need to rebuild gcc for that?
<whitequark> oh, -specs, wow
<cr1901_modern> whitequark: Why does "-specs" surprise you? (It doesn't surprise me that it exists b/c of the need to probably override the default linker script for a given microcontroller anyway)
<whitequark> you override the linker script using -Tfoo.ld
<whitequark> in fact, you don't even need that
<whitequark> anything that the linker doesn't recognize as a ELF/PE/COFF file it assumes to be a linker script
<rqou> wait wut
<cr1901_modern> Interesting... o.0;
<rqou> that's dumb
<whitequark> cat /usr/lib/x86_64-linux-gnu/libc.so
<whitequark> OUTPUT_FORMAT(elf64-x86-64)
<whitequark> GROUP ( /lib/x86_64-linux-gnu/libc.so.6 /usr/lib/x86_64-linux-gnu/libc_nonshared.a AS_NEEDED ( /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 ) )
<rqou> goddammit you're right
<rqou> WHY?!
<whitequark> pfhahaha
<rqou> is there really not a better solution here?
<whitequark> ask GNU
<cr1901_modern> "rqou: presumably you're using an existing unwinder?" Does libc++ provide that? Could you (as an academic exercise) write your own unwinder and somehow get GCC to generate a call to your own unwinder?
<rqou> i have no idea how this part of the stack works
* cr1901_modern wouldn't know how to do this, but I'm guessing you could
<rqou> you should be able to in theory
<whitequark> this behavior was added by: Tue Sep 13 16:30:11 1994 Ian Lance Taylor (ian@sanguine.cygnus.com)
<whitequark> cr1901_modern: no
<whitequark> libunwind provides that
<whitequark> also the unwinder interface is standardized, so, yes, trivially
<cr1901_modern> Specificed by Itanium ABI? Or something else?
<whitequark> correct
<whitequark> the only part that's not standardized is GCC's descriptions for catch filters etc
<cr1901_modern> Well, might be a good exercise to try making my own crappy one, just to see if I could do it
<cr1901_modern> (for the LPC810 or a similar small micro)
<rqou> huh, i don't recall having to use a specific libunwind
<whitequark> so, nowhere in the linker source it mentions *why* it treats unrecognized files as linker scripts
<cr1901_modern> Ask on the mailing list if you're destroying yourself in your curiosity :)?
<whitequark> I could just pester Ian
<rqou> libgcc also seems to have unwinding code: https://github.com/gcc-mirror/gcc/tree/master/libgcc
<whitequark> yes
<whitequark> libunwind+libcompiler-rt ~ libgcc
<rqou> ah, you're using clang
<whitequark> you can use libunwind with gcc
<whitequark> or likewise, clang with libgcc (as it happens on most linux systems)
<rqou> what's the advantage of doing so?
<whitequark> libunwind is written sanely
<cr1901_modern> just disable linking against libgcc :P?
<whitequark> porting it to or1k was trivial, and upstreaming also
<cr1901_modern> Wait, I'm not sure if that's possible
<whitequark> sure it is, -nostdli
<whitequark> b
<rqou> i thought gcc also has or1k upstreamed though?
<rqou> i thought that happened ages ago?
<whitequark> we're already using llvm for our in-house compiler though
<cr1901_modern> Not what I meant. From what I understand, gcc will emit calls to libgcc even in freestanding code. So not linking against it isn't guaranteed to work.
<whitequark> so having two optimization pipelines seemed silly
<eightdot> iirc sigrok has a cli interface/viewer (sadly d3bug is offline?)
<rqou> cr1901_modern: you just have to implement all the functions that libgcc would provide
<whitequark> that and gcc's build process is obnoxious
<whitequark> or just the ones you are using, anyway
<rqou> and if you forget some then you will get very fun missing symbol errors :P
<whitequark> you don't need softfp if you don't use softfp
<rqou> like my operating systems class managed to do :P
<rqou> the TAs forgot to include the implementation of __builtin_clzll in their "bag of utils.c"
<cr1901_modern> So if you use libunwind with gcc, you have to implement parts of libgcc yourself each time (or provide it as another library)?
<rqou> and apparently i was the only one who noticed
<whitequark> cr1901_modern: use libunwind and libcompiler-rt...
<whitequark> clang goes pretty far to emulate the "default" platform compiler
<whitequark> on *nix it emulates gcc, on windows it emulates msvc
<rqou> <troll> what about win32 SEH? </troll>
<whitequark> it handles that
<rqou> really? even gcc didn't
<whitequark> it was a massive effort across several llvm releases
<whitequark> but it handles that now
<whitequark> it's not perfect (there are known deficiencies, like you can't throw and catch in the same frame)
<rqou> the fs:[0] method on 32-bit?
<rqou> not the 64-bit table-based method?
<whitequark> both 32 and 64 bit iirc
<whitequark> clang even emits *codeview debug info*
<rqou> now why won't gcc get that?
doomlord has joined ##openfpga
<cr1901_modern> Well yes, but that's not what I was asking. I was simply asking how a gcc with libunwind could work if gcc hard-depends on libgcc. And it doesn't sound like using libunwind with gcc can be done cleanly (i.e. without reimplementing libgcc yourself and using -nostdlib and friends).
<whitequark> cr1901_modern: it doesn't, it depends on a particular ABI
<whitequark> that compiler-rt provides
<whitequark> libcompiler-rt+libunwind replace libgcc
<whitequark> they're a drop-in swap
<whitequark> rqou: because no one wants to spend that much effort on it?
<cr1901_modern> And how do you notify gcc of that :)?
<whitequark> cr1901_modern: you don't
<cr1901_modern> Oh!
<rqou> eh, on desktop i would honestly prefer to stop using 32-bit completely
<whitequark> i suppose someone in the team which implemented that still needs 32-bit
<rqou> but wow, I'm surprised how much clang works with the microsoft ecosystem
<whitequark> i think it was the chrome folks?
<whitequark> primarily?
<rqou> why? desktop browsers work like shit on 32-bit
<whitequark> you could go to the next llvm devmtg and just pester the responsible people directly
<whitequark> find echristo or chandler and ask who did that :p
<rqou> ime my browsing habits would easily out-of-virtual-address-space a 32-bit browser
<cr1901_modern> http://compiler-rt.llvm.org "builtins provides full support for the libgcc interfaces on supported targets" oops...
<whitequark> does like 60% of China still sit on windows xp?
<rqou> i heard that many of them are moving to win7
<rqou> my current firefox apparently has a virtual size of about 20gb
<rqou> that definitely doesn't work on 32-bit :P
<cr1901_modern> The day I realized we were all fucked was when a 4GB working set was no longer sufficient. Wirth's Law won.
<whitequark> well, chrome uses many renderer processes
<rqou> don't worry, it's only about 8gb resident :P
<whitequark> i mean, you could use PAE on 32-bit
<rqou> it can't increase your address space though
<cr1901_modern> Well, in Firefox's case everything's a single process, so PAE doesn't help there
<rqou> i honestly have no idea why it took mozilla so long to ship win64 firefox
<rqou> i remember nightlies of win64 firefox were working since ~2008
<rqou> it took them until ~last year to ship for real
<cr1901_modern> Mozilla hasn't been the bastion of wonderful choices in the past few years. But I'm biased.
<rqou> imho firefox is a very technologically powerful browser but that doesn't itself make a good product
<rqou> yeah, but that doesn't actually have any explanations as to what is holding things up
<whitequark> it does
<rqou> a quick skim shows mostly dependencies that were either fixed years ago
<rqou> or stuff that couldn't be reproduced
<rqou> they have official 64-bit builds right now
<rqou> i've been running win64 firefox since the first official build of iirc ff43
<rqou> and i've not noticed any problems whatsoever
<rqou> most bugs i encounter in firefox seem to be on android
<cr1901_modern> "cr1901_modern: well are you getting paid for using windows?" I still don't have a good answer to this other than "no." I suppose this was just a battle I willingly chose
<rqou> i've for the most part given up on doing "low-level-related" dev on windows
<cr1901_modern> It's less that I enjoy Windows and more that I dislike the direction Linux kernel dev/Apple (sic) is taking.
<cr1901_modern> /me chooses not to elaborate
<cr1901_modern> Oh and nobody (wants to) take(s) BSD seriously
<whitequark> cr1901_modern: oh btw, I forgot to mention, I've sent your GP4 breakout boards about a week ago
<whitequark> no tracking # since it's just regular airmail
<cr1901_modern> whitequark: Tyvm. No worries. I'm in no rush to receive them. Still haven't bought the skillet and/or toaster oven yet
<cr1901_modern> Though yesterday I had the opportunity to take apart a toaster oven with a family member (they wanted to know how it works). So I feel confident I could do a toaster oven mod now.
nats` has left ##openfpga ["Leaving"]
nats` has joined ##openfpga
tecepe has quit [Ping timeout: 255 seconds]
tecepe has joined ##openfpga
tecepe has quit [Ping timeout: 244 seconds]
tecepe has joined ##openfpga
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
digshadow has quit [Quit: Leaving.]
<felix_> does everyone from the openfpga projects wanting to attend the 33c3 have a chance to get a ticket?
digshadow has joined ##openfpga
amclain has joined ##openfpga
<felix_> if not, i can try to get a ticker order token for the project
<rvense> have the tickets gone on sale?
<felix_> the presale for people with a token has started; the tickets which are left after that will be sold some time later
<rvense> is that a new thing?
<felix_> yes
<rvense> where do the tokens come from?
<felix_> probably from the ccc. people who helped at least a certain amount of time at the last event and hackerspaces and otherorganizations can get tokens for the presale
<felix_> (i'm not sure where they come from, but i know someone i can ask to get a token for the project)
<rvense> ok, hm
<felix_> there will also be tickets in the normal sale, but i'm not sure how many
<felix_> iirc the last years the presale was only for the people who helped at the previous event
<rvense> yeah, that's fair
<rvense> just wondering if my hackerspace should make some "formal" request
<rvense> we're usually well represented
<felix_> which hackerspace? as i said, i can poke someone why knows whom to ask
<felix_> *whu
<felix_> *who
<rvense> labitat, in copenhagen. somebody maybe already know something, or i might ask later
pointfree has quit [Ping timeout: 265 seconds]
<felix_> ok, ask them and if they didn't get tokens, poke me again
pointfree has joined ##openfpga
<balrog> felix_: can US-based hackerspaces/makerspaces qualify?
<felix_> i think so
<felix_> if your hackerspace didn't get a token, i can ask someone to send you a token
<balrog> we didn't ask for one
<felix_> you probably only have to ask for a token if the hackerspace isn't known to the people handing out the tokens. but i was told that i can ask them when i think that some hackerspace also should get a token
pointfree has quit [Remote host closed the connection]
pointfree has joined ##openfpga
C47 has joined ##openfpga
doomlord has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
doomlord has joined ##openfpga
<rvense> felix_: we haven't got one, and would like one.. we will be bringing some lattice projects, and i was thinking about organizing an openfpga meet or assembly at some point
<rvense> felix_: but i don't know if it's too cheeky of me to ask!
m_w has joined ##openfpga
<felix_> rvense: ok, i'll ask
<rvense> felix_: if it matters, labitat.dk
<rvense> felix_: and thanks
<felix_> i asked him; as soon as i get a response, i'll tell you
<rvense> thank you very much
<felix_> he told me that the tokens are still being sent and that i should ping him again if your space hadn;t gotten a token within the next two days
<felix_> having more openfpga projects at the 33c3 would definitely be awesome
<rvense> ok, cool
<balrog> felix_: got my PM?
<felix_> balrog: yes
C47 has quit [Ping timeout: 276 seconds]
<felix_> i asked him about both spaces, but he didn't know which spaces will get tokens in the next two days, and sending out extra tokens should only be done for those spaces that initially didn't get one
cr1901_modern has left ##openfpga [##openfpga]
cr1901_modern has joined ##openfpga
<rvense> felix_: makes sense, thanks
<balrog> felix_: got it
C47 has joined ##openfpga
m_w has quit [Quit: leaving]
m_w has joined ##openfpga
<rqou> hmm the last time i went to ccc (2 years ago) i got tickets at the door
<felix_> i wouldn't count on that. from what i heard, last year there were only very few one day tickets and iirc no normal tickets left to buy directly at the venue
<rqou> hmm unfortunately i'm not affiliated with any "normal" makerspace so i guess i'll have to wait for the non-token tickets
<felix_> i can try to work something out that you can get a ticket from the presale
<felix_> can't promise, but i can try
doomlord has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
Bike has joined ##openfpga