Search logs:

channel logs for 2004 - 2010 are archived at ·· can't be searched

#osdev2 = #osdev @ Libera from 23may2021 to present

#osdev @ OPN/FreeNode from 3apr2001 to 23may2021

all other channels are on OPN/FreeNode from 2004 to present

Friday, 6 May 2022

00:00:00 <geist> seems like that'd be a problem though, since would it' pick up a ground off all of the computers it plugged into?
00:00:00 <geist> seems like you could get a good ground loop with that
00:00:00 <geist> unless it was explicitly neutral shield i guess
00:00:00 <mrvn> BNC is uncoupled from the computer, no shared ground.
00:00:00 <geist> ah
00:01:00 <mrvn> You don't want a shared ground with systems on different breakers and different phases.
00:01:00 <geist> so probalby i nternal to the nic they have the whole transformer to decouple it like they do with twisted pair
00:01:00 <geist> what AUI did is i think simply move the PHY outside of the nic, similar to SFP nowadays or so
00:02:00 <mrvn> pretty much the same except with just one non-twisted pair.
00:03:00 <kazinsal> yeah basically the MAC spits out AUI logical signals onto an AUI interface and then the MAU on the other end of the AUI interface takes those signals and turns them into physical layer signalling, and vice-versa
00:04:00 <kazinsal> the MAU also does the collision detection and jabber detection, being 10Mbit ethernet
00:06:00 <heat> kazinsal, i kinda asked you this a few days ago but how do you implement a proper FIB? do you just have a plain array of routing table entries and then a radix tree as a cache? or can you use the radix tree as the actual routing table?
00:07:00 <kazinsal> you keep them separate and build and maintain the radix tree as a cache from the routing table
00:07:00 <kazinsal> you can also cache layer 2 header information in the radix tree for efficiency
00:07:00 <geist> i was tinking about this. presumably a radix 512 is for ipv4 only (or only makes sense there) and you build some sort of 'page table' looking structure that has an entry for every possible address?
00:08:00 <kazinsal> as well as whatever rewrite information you might want
00:08:00 <mrvn> heat: I think what linux does is cache the routing entry index in the connection and when it gets invalidated you just do a linear search top to bottom.
00:08:00 <geist> was thinking that'd be terribly expensive memory wise, but you can get massive sharing of nodes i guess
00:08:00 <geist> since entire ranges of the internals would be identical so you can reuse the same inner node?
00:08:00 <heat> mrvn, linux also needs to maintain a proper FIB for routing
00:08:00 <heat> there's no connection there
00:08:00 <geist> ie, if all of say [0...10].x.x.x is the same, yo can use the same 11 top level tables?
00:08:00 <geist> and all the internals?
00:09:00 <mrvn> heat: connection tracking?
00:09:00 <kazinsal> geist: precisely
00:09:00 <geist> so i *guess* you could do the same thing with the first 64bits of ipv6, though the layout of that would probablylet you further suboptimize
00:09:00 <heat> geist, you can just have special radix tree entries that say "this is a value, not a sub tree"
00:09:00 <heat> that's how I've seen it done
00:09:00 <geist> heat: yeah basically like a 'large page' in a page tables
00:09:00 <heat> just like a page table hugepage for instance
00:09:00 <heat> yeah
00:10:00 <geist> yah makes sense
00:10:00 <kazinsal> yep
00:10:00 <heat> how faster is the radix tree?
00:10:00 <mrvn> geist: if [0...10].x.x.x is the same you would have 0-7, 8-9 and 10 nodes in the tree.
00:10:00 <kazinsal> noticeably.
00:10:00 <heat> even for the average host?
00:10:00 <heat> or consumer router
00:10:00 <kazinsal> for forwarding? yeah
00:10:00 <geist> mrvn: why so?
00:11:00 <mrvn> geist: matching 3bit, 4bit, 5bit prefix.
00:11:00 <geist> it's not a binary tree, i'm assuming it's a bunch of tables of 256 entries
00:11:00 <geist> so a linear run of the same thing would just be N things copied
00:11:00 <kazinsal> even if your routing table has only a few different prefixes you still need to do a lookup for each packet without a trie FIB
00:11:00 <mrvn> geist: if your radix tree uses bytes instead of bits then yes.
00:11:00 <kazinsal> and then you need to then do ARP cache lookups etc
00:11:00 <geist> right, i think that's the point, since it's organized according to a.b.c.d
00:12:00 <heat> kazinsal, more or less how many routes are you expected to have?
00:12:00 <geist> though really, could radix anywhere you want as long as it is a common division of 32
00:12:00 <mrvn> geist: I would have it organized by the netmask
00:12:00 <geist> yah this is a router level thing, so netmask isn't that interesting
00:13:00 <geist> or at least the netmask can be done already for local networking stuff
00:13:00 <heat> every route has a mask
00:13:00 <kazinsal> I'll dig out my big fun book of router internals in a bit
00:13:00 <geist> i'm assuming this is more for inter-router stuff. like how routers decide how to forward stuff
00:13:00 <kazinsal> few things to take care of first
00:13:00 <geist> with this sort of radix tree they simply start with the address and drill into it
00:13:00 <mrvn> the route woulde be -> somewhere
00:13:00 <kazinsal> yeah the big use for this is to effectively make your route lookup almost fixed-time
00:13:00 <geist> such that it's at worst 4 hops
00:14:00 <geist> right
00:14:00 <kazinsal> and to be able to cache useful information in the same structure
00:14:00 <geist> indepdenent of any netmasks
00:14:00 <kazinsal> yeah
00:14:00 <geist> netmasking would feed into how you build it, since it allows you to share chunks of the tree
00:14:00 <kazinsal> maintaining your FIB becomes a bit more complicated, with some callbacks needed on routing table changes
00:14:00 <geist> or use 'large pages'
00:14:00 <mrvn> kazinsal: any tree form will be fixed time O(number of bits in the IP format) so that doesn't say much.
00:14:00 <kazinsal> but it's fine, really
00:14:00 <geist> yah could do some sot of copy on write almost, like build a new tree and switch to it
00:15:00 <geist> like a diuble buffered tree basically
00:15:00 <heat> right but I would expect that a vector with few entries would be faster than a radix tree
00:15:00 <geist> maybe, but that's where the N in O(N) matters
00:16:00 <geist> this is a cse where you throw memory/complexity at a problem such that all lookups become O(1)
00:16:00 <mrvn> You can probably also compare and match a number of entries in parallel with SSE.
00:16:00 <geist> but probably the actual numeric constant behind the '1' has a crossover point with real Ns for traditional tables
00:17:00 <heat> geist, yup, which is why I asked the avg number of routes in a router
00:17:00 <heat> I actually have no idea
00:17:00 <mrvn> If you have just your 2-4 basic routes bof your home system then a straight up array will be fast.
00:17:00 <geist> especially given that tables like that probably have relatively poor cache locality. or at least one can actually throw packets at a router to try to trigger it
00:17:00 <geist> ie, throw packets at the router that explicitly try to get it to have to thrash its cache
00:17:00 <mrvn> If you throw packets at a router many cheap ones fallback to HUB mode.
00:18:00 <geist> this table thing is also probably much more straigthforward for hardware to implement
00:18:00 <geist> some software can build the table, hardware uses it. ie, just like page tables on cpus
00:18:00 <mrvn> N-way lookup table in hardware. That's what small routers use.
00:19:00 <heat> which is why intel should introduce new x86 routing extensions for hardware accelerated lookups
00:19:00 <heat> great idea
00:19:00 <geist> anyay this is all probably Serious Router 101, but it's fun to work through it as a mental exercise
00:19:00 <heat> AVX512ROUTER
00:19:00 <kazinsal> the real fun routing in hardware is with ternary content addressable memory
00:20:00 <geist> yah i assume a whole new series of techniques were needed for ipv6
00:20:00 <mrvn> Do you want to route ethernet frames or IP frames?
00:20:00 <geist> or... actually possible ipv6 is generally much simpler, because it was designed to be that way
00:20:00 <kazinsal> you don't route ethernet frames so
00:20:00 <mrvn> kazinsal: bridging does
00:20:00 <kazinsal> that's not routing. routing is explicitly a layer 3 concept.
00:20:00 <geist> bridging i assume just has a different set of tehniques
00:21:00 <mrvn> Do you want to bridge/forward/whatever ethernet frames or route IP frames?
00:21:00 <geist> probably somewhat simpler, since the size of N in those cases is probalby largely fixed by physics
00:21:00 <heat> how would you go about connecting a router to another router?
00:21:00 <mrvn> geist: you could have a "route" for every 6byte MAC
00:21:00 <geist> well, first you put them in neighboring cages
00:21:00 <heat> do you just turn it on and start speaking ospf or so?
00:21:00 <geist> and you let them see each other through the wire
00:21:00 <kazinsal> I'm mostly interested in layer 3 but I have some layer 2 features that I am continously improving
00:21:00 <geist> they'll get used to each other's presence
00:22:00 <kazinsal> heat: depends on if they're both in the same autonomous system or separate ones
00:22:00 <mrvn> geist: so you map seen MACs to ports where you saw them?
00:22:00 <heat> kazinsal, lets assume the same, no eBGP here
00:22:00 <geist> mrvn: i dunno, my brain only has space for one concept at a time right now
00:22:00 <kazinsal> yeah you just configure stuff like OSPF or EIGRP or IS-IS or whatever tickles your fancy
00:23:00 <kazinsal> and depending on what hardware you're using, what vendor you like, and what requirements you have for little nitty gritty details
00:23:00 <mrvn> geist: Hence why I asked if this is for MACs or IPs. the solution for them is quite different.,
00:23:00 * geist shrugs
00:23:00 <geist> yah
00:23:00 <heat> hm
00:23:00 <geist> always wanted to build a switch and/or a router in fpga for lulz
00:24:00 <geist> just to stumble through all of this like a caveperson
00:24:00 <heat> so you can literally just add a router to your home network and have NAT in your local network, behind your own NAT?
00:24:00 <geist> but then i'd rather build something like a sprite engine in fpga first
00:24:00 <kazinsal> sure, no reason you can't
00:24:00 <mrvn> With IPs you have network/netmask to give you a nice structure and usualy a verry compact tree form for it. Wiht MACs is basically totally random 6byte strings.
00:24:00 <kazinsal> what happens in RFC 1918 stays in RFC 1918
00:24:00 <mrvn> geist: oh have fun with adding multicast support
00:24:00 <heat> i was afraid a router could just reject any other router
00:25:00 <geist> that's why you let them get used to each other first
00:25:00 <kazinsal> I mean you have to configure them the same overall way
00:25:00 <mrvn> and don't forget loops betgween routers
00:25:00 <geist> you dont want one router to attack the other on sight
00:25:00 <kazinsal> in a proper OSPF environment you can't just shove a router in and have it start getting your whole network's routing tables
00:25:00 <geist> since afterall you really want little baby routers, to propagate the router species
00:25:00 <kazinsal> there's HMACs and stuff
00:26:00 <mrvn> kazinsal: wouldn't that be fun when the janitor plugs in a foreign router to hijack the network
00:26:00 <kazinsal> yeah that's why there's levels of security involved in most routing protocols
00:27:00 <heat> ah, so you cant
00:27:00 <kazinsal> there are some really old routing protocols that still exist (in theory, at least) that just blast out routing tables to whoever asks
00:28:00 <mrvn> I never delt with anything more complex than managed switches where you telnet/ssh into the switch and assign MACs to ports, VLANs and routes statically.
00:28:00 <heat> real routing is insecure routing
00:28:00 <kazinsal> this is literally my job :)
00:29:00 <mrvn> viral routing is fun but very bandwidth limited
00:29:00 <geist> i can totally see the satisfaction in that
00:30:00 <geist> in just my little one router, v4/v6, 5 switch, 3 vlan, 3 AP home network it's super pleasant to know where everything is
00:30:00 <heat> you do it manually?
00:30:00 <mrvn> You can do it in RL too. Just tell all your friends about a message to xyz and let them tell all their friends till it reaches xyz.
00:30:00 <geist> and that it's operating pretty much ideally
00:34:00 <heat> do consumer routers just have one route?
00:34:00 <heat> mine seems to
00:35:00 <mrvn> heat: most people have an ISP and that's where all network traffic goes to by default if it isn't local.
00:35:00 <mrvn> s/an/one/
00:35:00 <mrvn> heat: you should have 2 routes, the local network and default gateway
00:36:00 <heat> I see routes for my local NAT'd network, the router's local network, and a default gateway
00:37:00 <geist> yah probaly
00:38:00 <geist> lokay, just moved vid card from one slot to another, starting test again. average time to failure seems to be about a day or two
00:39:00 <geist> watch -n1 'uptime; dmesg | tail -40' seems like a pretty good indicator of what's going on, since the screen sticks
00:40:00 <mrvn> lucky you. I'm debugging a problem that happens on ~5% of a 1000 node cluster once a week.
00:52:00 <mrvn> watching paint dry:
00:52:00 <bslsk05> ​'1 MILLION FPS - The Slow Mo Guys' by The Slow Mo Guys (00:18:38)
01:03:00 <geist> yah i'm being pretty slow about it since it's not a critial machine, and i only want to change one variable at a time
01:04:00 <geist> and of course it's just some derpy desktop motherboard that's not really intended to be used as a server, with a beefy power hungry cpu in it, so it's entirely possible it's just the motherboard getting loaded down or whatnot
01:06:00 <geist> or may be that reseating stuff will cause it to fix itself
03:04:00 <Clockface> does the stack do anything weird on linux besides pushing an 8 byte address to the stack upon CALL?
03:04:00 <Clockface> *in x86_64
03:04:00 <Clockface> im using purely assembly, so i dont care what the compilers are doing
03:05:00 <Clockface> i dont think it does, but for some reason im not getting data off the stack the way im expecting
03:06:00 <Mutabah> you still need to follow the right calling convention
03:06:00 <Mutabah> what are you trying and expecting?
03:06:00 <kazinsal> you should be caring what the compilers are doing
03:06:00 <kazinsal> because what the compilers are doing is "following the ABI"
03:10:00 <moon-child> well, only if you are calling into c code
03:11:00 <moon-child> if it's all assembly (syscalls included), then you don't need to care about the abi (except the kernel abi, but that doesn't care about the stack)
03:11:00 <heat> it's useful to follow some ABI in assembly as well
03:11:00 <moon-child> yes
03:12:00 <heat> Clockface, code?
03:13:00 <moon-child> (and I will add, if it's not an abi issue from talking to c, it's probably just a bug in your code)
03:17:00 <Clockface> pop RAX
03:17:00 <Clockface> push mydata
03:17:00 <Clockface> push RAX
03:17:00 <Clockface> and
03:18:00 <Clockface> pop RAX
03:18:00 <Clockface> pop registercontainingmydata
03:18:00 <Clockface> push RAX
03:18:00 <Mutabah> ...
03:18:00 <Mutabah> yeah, going to need to see more than jsut that (in a gist or pastebin?)
03:20:00 <Clockface>
03:20:00 <bslsk05> ​ %macro PEEK_ 2 %define ARG1 .%1 %define ARG2 .%2 mov rax, qword [ARG1 + rb -
03:21:00 <Clockface> wait
03:21:00 <Clockface> these arent the ones that need to be looked at
03:21:00 <Clockface> sorry
03:22:00 <Clockface>
03:22:00 <bslsk05> ​ %macro ARG_i 1 %define ARG1 .%1 %define ARG2 .%2pop raxmov rcx, qword [A -
03:23:00 <heat> can you just give us some disasm?
03:23:00 <Mutabah> That seems... really strange, pop/load/push/push is quite off
03:24:00 <Mutabah> What would be in `rax` here?
03:24:00 <Mutabah> Is this meant to manipulate your own arguments, without clobbering your return address?
03:24:00 <Clockface> yeah
03:25:00 <Mutabah> why?
03:25:00 <kazinsal> this seems like one of those times where the answer to your problem is the question "what exactly is it you're trying to accomplish"
03:25:00 <Mutabah> Any why make macros to do it instead of writing out the rather-simple code directly
03:26:00 <Clockface> im slapping together myself a high level language out of macro's
03:27:00 <Clockface> its going better than i expected, im only having issues with function calls now
03:29:00 <Clockface> if i used any assembly instead of macro's to do stuff, i wouldent be writing a language anymore
03:36:00 <Clockface> i saw someone did that with some form of BASIC too?
03:36:00 <Clockface> i never found the project, but someone said someone did it
03:40:00 <Mutabah> If you're writing a language, why not use a proper parser/code-generator
03:40:00 <Mutabah> Instead of abusing nasm's macro system to produce VERY inefficient code
03:41:00 <Mutabah> (e.g. use python to create a translator)
03:41:00 <Clockface> but i can write my bad compiler with macro's then compile the compiler when the compiler is capable of compiling
03:41:00 <Clockface> *good compiler
03:41:00 <Clockface> i intend to do that eventually, also i do regret this
03:42:00 <Clockface> im 95% done, so im not stopping now
03:45:00 <klys> finding that it's easy to stop when it seems you've reached a milestone
03:45:00 <geist> kazinsal: oh crap i used to have a name for that sort of problem
03:46:00 <geist> there was a name for it. where someone is asking about some esoteric solution and the problem probably has a much simpler solution
03:48:00 <Clockface> noob tangients?
03:48:00 <geist> heh, well you did come up with a rationale
03:50:00 <heat> XY problem?
03:50:00 <geist> ah yeah that's it!
03:52:00 <klys> so in the year 1992, what would have been the best way to devise an os to avoid the w95 trap
03:54:00 <heat> what's the w95 trap?
03:54:00 <klys> obviously you'd need lgdt/lidt and a 386
03:54:00 <geist> you just fell in it!
03:54:00 <geist> oh.
03:55:00 <klys> and as anyone might recall w95 was vulnerable to call gates, so that could be a way to swap out the swapper
03:55:00 <kazinsal> sit in a college dorm and bang out an email to comp.os.minix about how you're working on an operating system (won't be big and professional like gnu)
03:55:00 <klys> yes
03:55:00 <geist> +1
03:56:00 <heat> code-review +2
03:56:00 <kazinsal> but what exactly is the "w95 trap"
03:57:00 <kazinsal> all I get for searching it is trap remixes of the microsoft sound
03:57:00 <klys> minix was probably the best way to avoid w95 at the time
03:57:00 <heat> "anyone might recall" most people do not have the details of an almost 30 year old OS in the back of their mind
03:57:00 <heat> especially *windows 95*
03:57:00 <kazinsal> despite literally using windows 95 today I have to concur
03:58:00 <geist> yeah i mean i know quite a bit of estoeric stuff about things, but i wouldn't know about any single 'w95 trap'
03:58:00 <heat> you could use 386BSD
03:58:00 <heat> that existed
03:59:00 <klys> ah yes, bsd
03:59:00 <geist> but i guess maybe can be interpreted not as a trap as in where you fall in and your leg is stuck, but literally 'the way to do syscalls'
03:59:00 <heat> also netbsd, freebsd
03:59:00 <heat> BSD/386
03:59:00 <klys> well what you would have wanted is an invasive system which could replace w95 at a relatively low level
03:59:00 <heat> SVR4
04:00:00 <kazinsal> what
04:01:00 <klys> it's a ui thing, the next generation went the way of the mouse, then the way of the technophobe
04:02:00 <heat> what
04:02:00 <heat> technophobe?
04:02:00 <klys> so as to keep the commandline interface is success at avoiding the trap as thus defined
04:03:00 <klys> loads of phobic users have cellfones today, and will interact if you allow them to avoid keyboard usage
04:03:00 <kazinsal> are you... under the impression that before august 1995, nobody had ever used a consumer-oriented graphical user interface before
04:03:00 <klys> that's a mistake in the history
04:03:00 <heat> phobia of what exactly?
04:04:00 <klys> right, technology is still ill defined, though I think it represents literacy as an aspect of trust
04:04:00 <heat> also, wait until you hear about this:
04:04:00 <bslsk05> ​ UnixWare - Wikipedia
04:05:00 <heat> deh kernel of deh unix drawing windows on the screen
04:05:00 <heat> with a maus
04:05:00 <kazinsal> ah, good ol' Unix System Laboratories
04:05:00 <klys> I saw a book about unixware at the local thrift store where my current occupation resides, one time, it was published by NOVL and had a baseball player on the front cover
04:06:00 <klys> NOVL is now "micro focus" and lives in south Provo, they don't do anything big like NOVL was trying to do with their NDS database, though.
04:08:00 <Clockface> there are too many UNIX ripoffs!
04:08:00 <klys> NDS was just a project like the current 389-ds package
04:08:00 <Clockface> im sick of it!
04:08:00 <kazinsal> time to write one new unix ripoff to supplant all other unix ripoffs
04:08:00 <klys> srs.
04:09:00 <heat> hi,
04:09:00 <bslsk05> ​heatd/Onyx - UNIX-like operating system written in C and C++ (2 forks/41 stargazers/MIT)
04:09:00 * geist calms down Clockface
04:09:00 <geist> there there
04:09:00 <heat> i did not rip off unix
04:09:00 <heat> i ripped off linux
04:09:00 <heat> which ripped off minix, which ripped off unix
04:09:00 <heat> cuz of that, i never ripped off unix
04:09:00 <heat> suck it
04:10:00 <heat> unix? what's that
04:10:00 <sonny> turns out files are a pretty good interface
04:10:00 <klys> if you are familiar, you'll write an os with a "c library." c libraries are kind of messy though, and the interface has been standardized. tcp/ip requires it. manipulating data portably requires it. if you're like me you want to put the functions in separate namespace categories. in the end you have to rewrite the c compiler.
04:11:00 <heat> you don't need a C library
04:11:00 <sonny> Clockface: what OS inspires you?
04:11:00 <heat> tcp/ip doesn't need a C library
04:11:00 <heat> namespaces exist in C++
04:11:00 <heat> no rewriting is needed
04:12:00 <klys> that's an xy solution
04:12:00 <heat> no it's not
04:12:00 <Clockface> i was inspired by DOS and 9x mostly
04:12:00 <Clockface> *windows 9x
04:12:00 <heat> you're telling me rewriting the C compiler is less of an XY solution than "use another language"?
04:13:00 <sonny> did NT come out in 9x?
04:13:00 <heat> you do *not* need a libc as an interface (see: Go in Linux)
04:13:00 <klys> using forth is still impractical and there needs to be a better other language in the rpn space
04:13:00 <sonny> I don't know about windows design before NT
04:13:00 <Clockface> no, but i found NT later and its what made me think about moduler kernels
04:13:00 <Clockface> im probably inspired more by NT than 9x now that i think about it
04:14:00 <sonny> I read about namespaces in plan9 and I wonder if NT missed out on that
04:14:00 <heat> define UNIX btw Clockface
04:14:00 <Clockface> i initially wanted something DOSy that isnt stuck in the past
04:14:00 <sonny> if so then the object manager would be super cool
04:14:00 <sonny> otherwise, it is similar to unix virtual file system I must admit
04:15:00 <geist> <insert token comment about openvms>
04:16:00 <geist> though i think the objectnamespace thing is more of a derivative of PRISM or whatnot than VMS
04:16:00 <klys> not the e.snowden prism tho
04:17:00 <sonny> how do I google PRISM?
04:17:00 <heat>
04:17:00 <bslsk05> ​
04:18:00 <geist> alas i dont think there's much out there
04:18:00 <sonny> ??
04:18:00 <bslsk05> ​ PRISM (surveillance program) - Wikipedia
04:18:00 <geist> it was an experimental thing at DEC that got cancelled, then dave cutler left, joined up with MSFT, and they started working on NT
04:18:00 <geist> the cpu side of the project later turned into Alpha
04:18:00 <sonny> oh neat
04:19:00 <geist> but the OS side was apparently some sort of capability based µkernel thingy that was intended to replace openvms
04:19:00 <heat> "Cutler is known for his disdain for Unix."
04:19:00 <sonny> haha
04:19:00 <heat> Clockface, see you're not alone
04:20:00 <klys>
04:20:00 <bslsk05> ​redirect ->
04:20:00 <sonny> I thought unix haters mostly just complain about the UI
04:20:00 <sonny> and cryptic naming
04:20:00 <Clockface> i like UNIX, i just dont want to make another unix
04:20:00 <heat> X11 is great what are you on about
04:20:00 <geist> oh oh MICA yeah that's right
04:20:00 <geist> that was the OS side of the project
04:20:00 <geist> but not a lot to talk about
04:20:00 <bslsk05> ​ DEC MICA - Wikipedia
04:21:00 <sonny> heat: pre X, in the haters handbook
04:21:00 <sonny> also, lol
04:22:00 <sonny> Clockface: I thought about it, but it's the best/eventual design
04:22:00 <sonny> if osdev started over we'd just rediscover unix
04:23:00 <heat> y'know lots of OSes don't have unixy interfaces right?
04:23:00 <Clockface> DOS is nice in its own way though, i like how it just shuts up and gets out of the way of the current program
04:23:00 <heat> windows, a good chunk of macOS, fuchsia
04:23:00 <geist> i dunnom i think modern designs would still generally rediscover a global heirarchy namespace
04:23:00 <Clockface> its like writing an OS but all the boring stuff is premade
04:23:00 <geist> that is a really compelling thing
04:24:00 <sonny> ya
04:24:00 <geist> i think in general more modern stuff tends to gravitate towards a heirarchy of ndoes
04:24:00 <geist> nodes
04:24:00 <sonny> that's what I mean
04:24:00 <geist> where nodes are objects that support some sort of interface that you can discover
04:24:00 <sonny> unix == plan9
04:24:00 <geist> ie, not necessarily just files
04:24:00 <geist> but i mean even if you weren't trying to recreate unix, it's hard to not gravitate towards that part of it at least
04:25:00 <geist> unless you're explicitly trying not to have a global namespace, etc etc
04:25:00 <heat> otoh global namespaces are bad for concurrency
04:25:00 <Clockface> i would at least differentiate between real files on drives and "everything is a file" files
04:25:00 <geist> sure, and that might be a reason not to
04:25:00 <Clockface> and call both of them as a whole objects or something for clarity
04:25:00 <geist> even if there isn't aglobal namespace, having some sort of tree based namespace, even if it's zoned and private to processes or whatnot is still pretty compelling
04:26:00 <geist> vs, i dunno, flat string based naming where you just have to know the name
04:26:00 <geist> or everything is a UUID you have to either just know
04:26:00 <geist> or discover via another interface (ie, UEFI)
04:26:00 * heat laughs in UEFI
04:26:00 <heat> everything is a UUID
04:27:00 <geist> yah that'skinda an odd design. i guess it *does* make sense for maybe the common use case: little binary that just wants to get a handle to a thing that's either there or not, and use it and move on
04:27:00 <geist> having a 'get me this interface by UUID' is pretty convenient
04:28:00 <heat> yeah but like
04:28:00 <heat> maybe magic numbers?
04:28:00 <geist> isnt' that basically the same thing?
04:28:00 <heat> why do you need a 128-bit number?
04:28:00 <geist> oh well, yeah that's just MSFT at the time
04:28:00 <geist> but there are worse things
04:28:00 <heat> i think this is plain and simple wintel GUID extravaganza
04:29:00 <sonny> lol
04:29:00 <geist> well, sure
04:29:00 <geist> there's all sort of MSFT all over it
04:29:00 <geist> 16 bit unicode, uuids, PE binaries, FAT filesystem, etc
04:29:00 <heat> the coding style
04:30:00 <sonny> Clockface: I saw a smalltalk demo today, made me feel backwards ... but I think objects probably need more hardware support
04:30:00 <kazinsal> yeah, UEFI's cool but I sometimes wish it were more generally approachable
04:30:00 <heat> well, it's not that hard
04:31:00 <heat> for instance, filesystem operations: get filesystem, open file (you get a handle to a file), use the file, close, close the fs
04:31:00 <heat> pretty similar to an OS
04:32:00 <klys> so I guess uefi still has something like PXE boot?
04:32:00 <heat> yes
04:32:00 <Clockface> i dont think filesystems should be a bios thing
04:32:00 <klys> do you, "open network device?"
04:33:00 <heat> Clockface, have you tried reading a filesystem in 1024 bytes?
04:33:00 <Clockface> no
04:33:00 <Clockface> but most proggrammers never touch the disk directly
04:33:00 <heat> klys, network booting is more automatic than that, but it generally ends up using the HTTP/TCP, UDP protocols I believe
04:33:00 <Clockface> so, convinience at that level isnt too important
04:33:00 <heat> I don't know how you get the protocols, probably by looking at network devices
04:34:00 <klys> heat, just curious what access uefi has to the network, is it because the network device firmware is in place?
04:34:00 <heat> yup
04:34:00 <heat> firmware publishes handles and protocols to stuff
04:34:00 <heat> same with the GOP, that's all published by the GPU's UEFI firmware blob
04:35:00 <kingoffrance> "PRISM (surveillance program) " lol lemme know if you ever see the code for "PROMIS" database it was public domain originally lol
04:35:00 <klys> so that's why everyone is still using intel/broadcom/realtek network interfaces?
04:35:00 <kingoffrance> supposed to be very flexible
04:35:00 <heat> Clockface: UEFI is made with the purpose of reusing code and making life easier for everyone
04:35:00 <klys> kingoffrance, that prism never made it into the topic
04:35:00 <heat> less duplicated code, more maintainable software
04:36:00 <heat> it turns out that writing an ext2 driver in 1024 bytes of an ext2 bootsector isn't easy
04:36:00 <kazinsal> everyone still uses intel/broadcom/realtek network interfaces because those are the ones that are most commonly produced
04:36:00 <heat> klys, no
04:36:00 <kazinsal> and they're all quite simple to work with
04:36:00 <klys> because the network device vendor has to produce firmware capable of interacting with uefi on a high level
04:36:00 <klys> no?
04:37:00 <heat> what's a "high level"?
04:37:00 <klys> osi model
04:37:00 <klys> media access control
04:37:00 <kazinsal> UEFI just has a network stack like anything else
04:37:00 <heat> all UEFI firmware is just a UEFI driver
04:37:00 <heat> a UEFI driver is exactly like a UEFI app (your bootloader, your linux kernel's EFI stub) but slightly different
04:38:00 <Clockface> only 1024 bytes of non-files in ext2?
04:38:00 <klys> so you can open the network device from uefi code
04:38:00 <heat> all the vendor needs to do is write a simpler driver
04:38:00 <heat> Clockface, yes
04:38:00 <heat> of "non-filesystem-stuff"
04:40:00 <Clockface> that sucks!
04:40:00 <Clockface> fat32 blessed me with 32k
04:40:00 <klys> so just use a blocklist
04:41:00 <klys> grub2-mbr uses a blocklist
04:41:00 <heat> there's an inode allegedly reserved for bootloader stuff
04:41:00 <heat> but you need to read that first
04:44:00 <kazinsal> yeah, inode 5 is reserved as "boot loader inode"
04:44:00 <heat> anyway, UEFI is still relatively simple
04:45:00 <heat> no interrupts, no threads for example
04:45:00 <kazinsal> so I guess you can go: bios loads your first 512 bytes -> you load the next 512 for more code space -> poke at the superblock and find the inode table -> read the contents of inode 5 -> use that to load a second stage bootloader
04:46:00 <Clockface> that sounds like a major flaw, i like how fat32 just gives you 32 kilobytes
04:47:00 <Clockface> simple stuff that doenst change is better than complicated stuff that does
04:48:00 <Clockface> unlike my spelling of doesnt apparently
04:48:00 <Clockface> im going to use that from now on, its funny
04:49:00 <klys> so since you're interested in FAT here's the spec,
04:49:00 <geist> yep, actually been writing a driver recently from that spec
04:50:00 <Clockface> i was about to write my bootloaders FAT driver, but i got sidetracked since the C compilers were being annoying
04:50:00 <Clockface> so i decided to do the macro monster
04:50:00 <kingoffrance> i got competition...
04:51:00 <kingoffrance> this, has only just begun
04:51:00 <Clockface> eh?
04:52:00 <Clockface> whats going on?
04:52:00 <kingoffrance> i heard you like assembler so i wrote an assembler in assembly to assemble your assembler
04:52:00 <kingoffrance> not yet, but WIP
04:55:00 <Clockface> if my language lacks global variables and has the ability to pass functions does that make it a functional language
04:56:00 <Clockface> i feel like it would
04:56:00 <kingoffrance> i saw a horrible thing in e3vi ...the e3c was "generated" from assembly. one giant function, with computed gotos, simulated stack.
04:56:00 <Clockface> since then everything is completely dependant on the arguments
04:56:00 <kingoffrance> gives me lots of bad ideas
04:56:00 <Clockface> oh?
04:56:00 <Mutabah> Clockface: Not quite.
04:56:00 <Mutabah> That's more a "pure" language
04:57:00 <Clockface> wdym
04:57:00 <Mutabah> I believe functional is about everything being call chains, instead of having explicit control flow
04:57:00 <Mutabah> e.g. `foo.for_each(|v| bar(v))` isntead of `for v in foo { bar(v) }`
04:58:00 <Mutabah> Pure means that there are no side-effects
04:58:00 <moon-child> I don't think your distinction is particularly interesting
04:58:00 <Mutabah> Maybe not
04:58:00 <moon-child> I think the main interesting distinction to draw is between languages which are referentially transparent and those which aren't
04:59:00 <heat> see, this is why C++ is the best
04:59:00 <heat> it's also functional
04:59:00 <heat> C++ is everything
05:00:00 <heat> do you need something from your favourite old new language? no problem, we'll add it in a header
05:00:00 * moon-child smacks around heat a bit with a large trout
05:00:00 <Clockface> cna you please put python interpreter in C++ kthxbye
05:01:00 * heat smacks moon-child with <ranges>
05:01:00 <heat> that was a big one
05:02:00 <Clockface> what do you all think of microsofts .NET thingy
05:03:00 <heat> java
05:04:00 <moon-child> yeah, slow java knockoff
05:04:00 <Clockface> i thought C# itself had decent performance
05:05:00 <moon-child> yeah it's ok. But slower than java
05:06:00 <moon-child> (though, not quite apples-to-apples)
05:06:00 <Clockface> i tried both and both made my brain melt
05:06:00 <Clockface> i dont like oop very much
05:06:00 <Clockface> i can see how its probably good for big projects with lots of people
05:06:00 <Clockface> but for me, nah
05:07:00 <sonny> .net is cool
05:07:00 <sonny> roslyn compiler is 100kloc
05:08:00 <sonny> suffers from corporate stuff, but otherwise neat idea
05:09:00 <Clockface> corporations innovate a lot
05:10:00 <Clockface> especially in vocabulary no one heard of before
05:19:00 <sonny> lmao
05:20:00 <sonny> yeah m$ seems to be good at doing that
05:22:00 <kingoffrance> everyone want{s,ed} the grail of write once run everywhere. so i just imagine a tree with .net java objective-c [..] hanging :)
05:23:00 <Clockface> wasnt C supposed to be highly portable at one point
05:23:00 <Clockface> i guess it still is between CPU's
05:23:00 <Clockface> but by modern standards i guess it isnt
05:23:00 <kingoffrance> sure, c89 at least has flexible bytes
05:26:00 <energizer> wasm seems like a plausible target for portable programs
05:30:00 <Clockface> eventually i hope it replaces js
05:30:00 <Clockface> i dont like forcing half the devs in the world into one language
05:30:00 <Clockface> then everyone could use their language of choice
05:30:00 <kazinsal> wasm can't replace javascript because it doesn't directly interface with the DOM
05:31:00 <Clockface> that might change
05:31:00 <Clockface> i never said it would replace JS in its current state
05:31:00 <moon-child> what if, instead of using wasm, we just stopped having the web?
05:31:00 <energizer> i mean to replace x86, not js
05:33:00 <Clockface> i dont see much wrong with x86, if something were to replace x86 i think it would be ARM (or maybe in some far flung sci fi world, risc-v)
05:34:00 <Clockface> would WASM be that good to make hardware for anyways?
05:34:00 <energizer> well the problem isnt x86 per se it's that you cant compile for x86 you have to compile for a zillion target platforms instead of one
05:34:00 <Clockface> i know some instruction sets are easier emulated than made physically
05:34:00 <moon-child> portability is good. wasm is too mediocre. arm is ok but not portable
05:34:00 <moon-child> jit-compiling is a Good Idea. But please not wasm
05:34:00 <Clockface> wdym?
05:34:00 <Clockface> recompile x86?
05:35:00 <Clockface> do you mean for windows PE and ELF and stuff
05:35:00 <Clockface> unless you mean portability in between instruction sets
05:35:00 <Clockface> but then i think you would still have to compile for people not using WASM
05:39:00 <energizer> i heard of wasm as an multitenant isolation mechanism (Fastly)
05:39:00 <bslsk05> ​'"Isolation without Containers" by Tyler McMullen' by Strange Loop Conference (00:31:41)
05:41:00 <energizer> "If WASM+WASI existed in 2008, we wouldn't have needed to created Docker."
05:41:00 <bslsk05> ​ @adlrocha - Can WASM become the new Docker?
05:41:00 <energizer>
05:41:00 <bslsk05> ​ Lucet Takes WebAssembly Beyond the Browser | Fastly | Fastly
14:25:00 <mrvn> klys: at work we boot grub via network on uefi and have it load the kernel and ramdisk because it's network code has no problem with e.g. 1GB ramdisks.
14:26:00 <clever> i think ive done similar on ipxe, but your way sounds a lot more modern
14:28:00 <mrvn> Clockface: does your language has partial aplication and composition of function?
14:30:00 <mrvn> We used ipxe for bios boots. Can't remember why we switched to grub exactly but something just worked better there.
14:31:00 <clever> when i last did grub netboot, i was cheating
14:31:00 <clever> i had ipxe map bios disk io into iscsi
14:31:00 <clever> so grub thought it was accessing a bios legacy disk
14:32:00 <mrvn> How long ago was that because grub does netboot just fine natively
14:32:00 <clever> more, i just didnt want to bother with finding out :P
14:33:00 <clever> the ipxe thing was simpler
14:39:00 <mrvn> dnsmasq is helpful there too. You can set it up to check if the system boots via bios or uefi and give it different configs. Or check other stuff to pick a config.
14:40:00 <mrvn> dhcp-boot=grubnet.i386-pc
14:40:00 <mrvn> dhcp-boot=tag:efi-x86_64,grubnetx64.efi
14:41:00 <clever> dhcpd can do that too
14:41:00 <mrvn> Booting with bios fetched the first, uefi the second via tftp and then grub.cfg says what kernel + initrd to load.
14:42:00 <clever>
14:42:00 <bslsk05> ​ nixos-configs/router.nat.nix at master · cleverca22/nixos-configs · GitHub
14:42:00 <clever> there are variables that the client can set, and the server can then act on to diff a different answer
14:43:00 <clever>
14:43:00 <bslsk05> ​ nixos-configs/netboot_server.nix at master · cleverca22/nixos-configs · GitHub
14:43:00 <clever> and this deals with legacy pxe vs efi
14:46:00 <mrvn> mines shorter, na na nana na :)
14:48:00 <clever> lol
14:48:00 <clever> mrvn: mines reproducible!
15:24:00 <zid> My builds are always reproductiaicaible, just use the same compiler, same flags. Because I don't use __DATE__ anywhere, easy
15:25:00 <zid> (Note, I don't know which compiler I used, or flags, good luck)
15:31:00 <clever> zid: thats what nix solves
15:32:00 <zid> It solves nothing good day sir
16:01:00 <stephe> do u guys know any good books about building a x86-32 os from scratch?
16:01:00 <zid> Depends if the intel software developer's manual counts
16:01:00 <mrvn> or the barebones tutorial in the wiki
16:02:00 <zid> depends what you already know, I don't know anything holistic
16:02:00 <zid> do you know x86? do you know what kind of OS you wanna make? do you know how to use binutils? etc
16:03:00 <mrvn> and you shouldn't want to make a x86-32 os. It's a dead architecture that just won't quite die.
16:03:00 <mrvn> go 64bit
16:03:00 <zid> surprised you have a pentium pro laying around you wanna revive though over something interesting like a desktop PC or a weird ARM board
16:05:00 <stephe> partly just curious about x86 and maybe would help to understand that if i eventually get more interested and want to build something 64bit
16:05:00 <zid> amd64 is about 10x easier
16:05:00 <zid> as long as you were intending to do 32bit paging
16:05:00 <stephe> really?
16:05:00 <stephe> i thought it would have been more complicated :D shows how much i know
16:05:00 <zid> Yea 32bit mode supports hardware task switching and segmentation and stuff
16:06:00 <zid> that amd64 just forces you to hardcode to 0
16:07:00 <stephe> i see
16:07:00 <zid> so there's like, 8 chapters explaining what a whole bunch of structures do in the 32bit manual, then a single line underneath for the 64bit equivalent that says "Write a 0 to field 8, all other fields are ignored, not setting it to 0 will cause #GP when long mode is entered." or whatever
16:08:00 <stephe> do you recommend the intel manuals for 64 bit too?
16:08:00 <stephe> is it volume 3?
16:08:00 <zid> 3 is the system one yea
16:08:00 <zid> amd have manuals too, some people prefer them
16:08:00 <zid> but I am super used to the intel manual style from them.. existing for 20 years prior to amd64's changes
16:09:00 <stephe> hmm i've only seen the intel ones i'll search for the amd ones
16:09:00 <stephe> i remembed years ago intel would send out their manuals for free
16:09:00 <zid> yea I have hard copies of the 32/64 manual
16:09:00 <zid> fedex'd from america for free
16:12:00 <stephe> :D
16:13:00 <GeDaMo> I requested a set just as they were stopping sending them out so I didn't get a complete set :(
16:13:00 <zid> I didn't ask for the optim one for.. reasons, so I have 1-3
16:14:00 <GeDaMo> I have 2A, 2B, 3A, 3B
16:15:00 <zid> yea I might not even have 1, I think we have the same sets
16:16:00 <mrvn> Read both the intel and amd manuals and pick the one more to your liking. Sometimes a feature is better described in one or the other.
16:16:00 <GeDaMo> I also like this as a quick reference
16:16:00 <bslsk05> ​ x86 and amd64 instruction reference
16:25:00 <mrvn> Now that c++ has defined signed integers to be 2s-complement shouldn't that mean signed overflow is now defined?
16:30:00 <GeDaMo> This still says undefined
16:30:00 <bslsk05> ​ Arithmetic operators -
16:31:00 <GeDaMo> Maybe they'll do that in a later standard :P
16:31:00 <zid> doesn't mean every cpu that uses signed 2's comp also has an O flag
16:31:00 <mrvn> probably not. It's the part that allows a lot of compiler optimizations.
16:31:00 <zid> and there's no grammar to check it in C++ or C still
16:32:00 <zid> SETS_O_FLAG(a+b);
16:32:00 <mrvn> zid: why would you need an O flag? unsigned int doesn't have that either.
16:32:00 <zid> because it's defined and the 'check' is the < operator
16:33:00 <zid> if you're defining it, presumably you want to define it so that you can use it in real programs
16:33:00 <mrvn> zid: b = a + 10; it (b < a) overflow();
16:33:00 <mrvn> IF signed overflow is defined that codeb just works like it does for unsigned.
16:34:00 <zid> I'd have to work through all the cases to prove that to myself
16:35:00 <zid> right what if you don't know the second operand to +
16:35:00 <zid> can you still do it?
16:35:00 <zid> without sorting a and b for absolute magnitude, and then comparing
16:35:00 <zid> where a and b can have arbitrary sign
16:36:00 <mrvn> sure. you just have to check for the second argument to be positive or negative and then check for over or under
16:36:00 <zid> can already do that by doing those comparisons as unsigned
16:36:00 <mrvn> But that is your problem to solve, not the languages.
16:36:00 <zid> I'd rather jut check the o flag :p
16:36:00 <mrvn> I would also rather have a Carry bit.
16:36:00 <zid> same :(
16:37:00 <mrvn> but totally different problem
16:37:00 <zid> I'm not sure how you could work tuples into C though
16:37:00 <zid> and without them it's sort of much less of an issue to begin with because you have to write two expressions regardless, one for the value and one for the carry
16:38:00 <zid> making it like errno maybe?
16:38:00 <zid> but now you're just literally writing assembly, with flags
16:38:00 <zid> it's ugly
16:40:00 <mrvn> If you write your tupple add with unsigned and compute the carry yourself gcc actually can optimize that into addx.
16:40:00 <zid> yea and it'll probably do jo for the case where I do the 'does a and b signed overflow' too, but I don't want the code to be peppered with the checks
16:41:00 <zid> I think in reality I'd rather they left it undefined, and let gcc have an UBSAN option that makes it call abort()
16:41:00 <mrvn> doing big int with signed integers wouldb waste 1 bit. nobody sane would do that.
16:41:00 <zid> good job unsigned exists then
16:42:00 <mrvn> doesn't gcc have a __builtin for arithmetic with carry?
16:42:00 <zid> possibly
16:43:00 <mrvn> zid:
16:43:00 <bslsk05> ​'CppCon 2019: Marshall Clow “std::midpoint? How Hard Could it Be?”' by CppCon (01:02:32)
16:43:00 <zid> no thanks
16:45:00 <GeDaMo> "A study published in 1988 shows that accurate code for it is only found in five out of twenty textbooks.[63] Furthermore, Bentley's own implementation of binary search, published in his 1986 book Programming Pearls, contained an overflow error that remained undetected for over twenty years."
16:45:00 <bslsk05> ​ Binary search algorithm - Wikipedia
16:46:00 <mrvn> The proposal for std::midpoint took 4 (iirc) revisions before it actually worked for all corner cases.
18:50:00 <geist> hah why am i watching this?
18:51:00 <GeDaMo> Dopamine! :P
19:00:00 <mrvn> this?
19:00:00 <zid> hololive obviously
19:01:00 <GeDaMo> I assumed your midpoint video
19:02:00 <GeDaMo>
19:02:00 <bslsk05> ​'p6w24t8mxtx81' by [idk] (--:--:--)
19:07:00 <geist> the midpoint video
19:07:00 <geist> the speaker is plesant to listn to
19:07:00 <geist> i also wonder what he's drinking there
19:07:00 <geist> looks like a scotch or something
19:09:00 <vdamewood> geist: Whatcha watchin'?
19:10:00 <geist> something mrvn linked before
19:10:00 <bslsk05> ​'CppCon 2019: Marshall Clow “std::midpoint? How Hard Could it Be?”' by CppCon (01:02:32)
19:10:00 <zid> Dr Pepper if he has any sense
19:10:00 <zid> but he's a C++ guy so I have counter-evidence
19:12:00 <geist> could be tea
19:13:00 <geist> it's the usual standin for whiskey when filming movies and TV
19:13:00 <zid> because shaking bottles of dr pepper to make them flat uses up a runner's time for too long
19:18:00 <mrvn> too dark for apple juice
19:25:00 <mrvn> geist: Note: the code still fails to compute the midpoint of a 3GB char array on 32bit archs.
19:25:00 <mrvn> with pointers
19:25:00 * geist nods
19:26:00 <mrvn> makes me wonder if qsort() works with arrays > 2GB.
19:28:00 <geist> it is one of the nice side effects of 64bit address spaces. no hardware (that i know of) supports a single aspace that covers more than half of the space
19:28:00 <geist> and thus no signed math issues
19:28:00 <mrvn> geist: amd64 pointers go from -xxxxx to xxxxx
19:29:00 <geist> sure, but no real system has a single aspace that crosses that boundary
19:29:00 <mrvn> Only problem is that nullptr there right in the middle
19:29:00 <geist> but you're right, i guess i should rephrase
19:29:00 <geist> no combination of 64bit hardware & software has an aspace that crosses a signed boundary
19:30:00 <geist> that i know of. i'm actually kinda curious what modern POWER or z/machines can do. if there's any machine that actually enabled a full 64bit virtual aspace it'd be those
19:30:00 <mrvn> On 64bit archs a-b can always fit in a ptrdiff_t
19:30:00 <mrvn> (so far)
19:31:00 <geist> POWER in particular with their hashtable was always more intrinsically set up to handle a full 64bit aspace than page tables
19:31:00 <geist> since you just add more bits to the TLB and the hash
19:31:00 <geist> i forget how big a PPC64 (ie, POWER4) let you go
19:35:00 <jjuran> I met Marshall Clow at MacHack :-)
20:40:00 <sbalmos> geist: tangentially along the same lines, I was always fascinated by the OS/400 / z/OS native bytecode software distribution system. The whole switch from 32 to 64 bit was a non-issue, since it just transparently recompiled all software on next load. Always made me wonder whether, maybe not WASM, but some OS that "natively" distributed its libraries and apps in LLVM IL format would work.
20:41:00 <zid> real compliation is slow
20:41:00 <j`ey> LLVM IR isn't fit for that, since it already has encoded stuff like ptr size etc
20:42:00 <mrvn> LTO output could be
20:42:00 <zid> If you just want 'most of the speed, but no 40 minute pause while it optimizes during the rebuild', you can just run the bytecode
20:42:00 <zid> gcc takes me 15 minutes to link
20:43:00 <mrvn> sbalmos: why not just distribute source code? '!/usr/bin/gcc' :)
20:43:00 <mrvn> sbalmos: why not just distribute source code? '#!/usr/bin/gcc' :)
20:44:00 <zid> My favourite cross platform bytecode is a zip of the github
20:44:00 <sbalmos> mrvn: gotta have something of a binary format for the folks who don't/can't distribute source
20:45:00 <mrvn> base64?
20:48:00 <sbalmos> j`ey: random curiosity hasn't gone deep enough yet... LLVM the instruction set doesn't define a pointer width, but the IR does?
20:49:00 <mrvn> sbalmos: something like sizeof(void*) is probably already evaluated
20:49:00 <sbalmos> mrvn: grr
20:50:00 <mrvn> Would any constexpr/consteval/constinit code remain in the IR?
20:50:00 <sbalmos> mrvn: I was even thinking of Rust for a moment, but then you still have to define the platform tuple, memory widths, etc for rustc for anything not already defined
20:51:00 <j`ey> sbalmos: I dont really understand that question, but also stuff like what mrvn said
20:52:00 <zid> and again, it all just comes back to optimization taking time
20:52:00 <zid> you don't want to redo them all every time you run it, that's called javascript
20:52:00 <zid> and it's slow and uses shit loads of memory
20:53:00 <sbalmos> obviously not
20:53:00 <sbalmos> like I first said, was just fascinated by OS/400's not-quite-source bytecode distribution
21:31:00 <energizer> if you want to specify cpu pipelining sequence for a program, is that expressible in uops, or not even there?
21:33:00 <moon-child> zid: this is well studied by eg java, js
21:33:00 <moon-child> you do it incrementally
21:33:00 <energizer> iow, is there a language that can customize pipelines on a per-program basis, or is it fundamentally baked into the hardware and you cant touch it
21:33:00 <moon-child> and unlike java, you can cache. But you might not want to, since the whole reason java is fast is that it dynamically recompiles based on runtime stimuli
21:35:00 <mrvn> energizer: For ia64 you have to pipeline yourself.
21:37:00 <energizer> i see, cool
21:37:00 <mrvn> gcc/clang will customize pipelines sometimes by inserting a NOP. But it's really a cpu specific optimization.
21:38:00 <mrvn> add eax, ebx; nop; mul eax, edx or so can be faster than without NOP kind of thing.
22:05:00 <mrvn> C++ is allowed to merge calls to new. Is C allowed to merge malloc calls?
22:06:00 <mjg> how would that work vs free later?
22:06:00 <mrvn> it has to see free calls for it
22:07:00 <mrvn> int *p = new int; int *q = new int; ... delete q; delete p; can be optimized into allocating 8 byte and a single delete
22:08:00 <mrvn> or none and put 8 byte on the stack
22:11:00 <mjg> i know c allows for malloc/free to be elided altogether
22:11:00 <mjg> or at least that's how clang sees it
22:11:00 <jjuran> Seems like a similar merging of malloc calls would be allowed under "as if" behavior
22:12:00 <mjg> so while i don't have a definitive answer, it does seem that "yes" would work in special cases of that sort
22:12:00 <mjg> [i know about clang because it keeps fucking up the malloc microbenchmark from will-it-scale, making it a nop]
22:12:00 <mrvn> jjuran: can't be under "as if" because malloc/free have side effects
22:13:00 <mjg> see above
22:13:00 <mjg> at least clang elides malloc + free altogether in this loop:
22:13:00 <mjg> while (1) {
22:13:00 <mjg> void *addr = malloc(SIZE);
22:13:00 <mjg> assert(addr != NULL);
22:13:00 <mjg> free(addr);
22:13:00 <mjg> (*iterations)++;
22:13:00 <mjg> }
22:13:00 <mjg> making the side-effect note moot
22:13:00 <mrvn> the side-effect note means the standard has to specifically allow this
22:14:00 <jjuran> mrvn: The only side effect I can think of is mutating the malloc pool, and that's a detail not specified by the language
22:14:00 <jjuran> Well, the exact bits of the address are observable
22:15:00 <mjg> again see above. clang elides malloc + free altogether in the pasted loop. so either the standard allows this or clang is violating it and i'm guessing it's the former
22:15:00 <mrvn> depending on your malloc and sizes the addresses might stay the same
22:15:00 <mrvn> mjg: yeah, me too. Just aren't sure about it.
22:16:00 <kingoffrance> eh, if it inlined it that would scrwe up the microbenchmark too, no?
22:17:00 <kingoffrance> i mean, it would be constant screw up seemingly, but point being if you really wanted to call a function, other ways that gets "elided" too
22:17:00 <mrvn> kingoffrance: like when malloc/free are static inlie functions?
22:17:00 <kingoffrance> well someone like me who wants to intercept everything, i do worry about these things lol
22:17:00 <kingoffrance> i dont know practically if ppl do
22:18:00 <mrvn> glibc intercepts malloc/free. it has hooks that get called on every call.
22:18:00 <mrvn> And in mjg's example suddenly no hooks get called.
22:19:00 <kingoffrance> yep
22:19:00 <moon-child> mjg: see, this is why it's nicer to write such benchmarks are written in asm :P
22:19:00 <mjg> it's not my code man fwiw
22:19:00 <mjg> i just suffer because of it
22:20:00 <mrvn> mjg: what does your code get turned into? "1: b 1b"?
22:20:00 <mrvn> or is iterations volatile and printed in a SIG_ALARM?
22:22:00 <mjg> said empty loop
22:22:00 <mjg> running the bench only gives you 0s
22:23:00 <mjg> funny part is that clang aligned the loop target to 16
22:23:00 <moon-child> lol
22:23:00 <mjg> by injecting a 2 byte nop prior to it
22:23:00 <mjg> 0x0000000000202761 <+1>: mov %rsp,%rbp
22:23:00 <mjg> 0x0000000000202760 <+0>: push %rbp
22:23:00 <mjg> 0x000000000020276e <+14>: xchg %ax,%ax
22:23:00 <mjg> 0x0000000000202764 <+4>: cs nopw 0x0(%rax,%rax,1)
22:23:00 <mjg> 0x0000000000202770 <+16>: jmp 0x202770 <testcase+16>
22:23:00 <mjg> so now you can do nothing faster
22:24:00 <mrvn> do nothing, really, really fast
22:43:00 <gog> literally me all day
22:44:00 <mrvn> not me, I do nothing quite slowly.
22:57:00 <heat> i've been digging through clang today
22:57:00 <heat> trying to find out how to implement fcheck-new
22:57:00 <heat> no dice so far although I've made some progress
22:58:00 <heat> kinda gave up for the day 5 hours ago so I just s l e p t until now
23:02:00 <heat> YES
23:02:00 <heat> I DID IT
23:05:00 <heat> jk I didn't
23:05:00 <heat> wait I did lol
23:05:00 <heat> ez
23:06:00 <geist> EEEEEEEZZZZ
23:12:00 <heat> wasn't that hard
23:12:00 <heat> apparently these "compiler" "people" know what they're doing
23:13:00 <zid> compiler "people"
23:13:00 <geist> implement as in you added a patch to llvm?
23:13:00 <heat> I've written the patch yes
23:13:00 <geist> oh cool!
23:13:00 <geist> get your name in the codes!
23:13:00 <heat> just need to clean it up, get a test case and submit it for review
23:14:00 <geist> it;s interesting that clang actually knew of the switch. did someone add logic to accept the switch but there wasn't any meat behind it?
23:14:00 <heat> yes
23:14:00 <heat> there are a bunch of ignored flags here
23:14:00 <geist> -fwheres-the-beef
23:15:00 <heat> you know -falign-loops, -falign-jumps, etc?
23:15:00 <geist> yah
23:15:00 <heat> IT'S ALL A LIE
23:15:00 <zid> llvm's frontend does a bunch of gcc compat ignores, like how gcc does a bunch of solaris ignores :p
23:15:00 <geist> :(
23:15:00 <geist> guess it would be nice to actually get a list of which ones are ignored
23:17:00 <heat>
23:17:00 <bslsk05> ​ llvm-project/ at main · llvm/llvm-project · GitHub
23:17:00 <heat> ctrl+f for clang_ignored
23:17:00 <mrvn> what does fcheck-new do?
23:17:00 <heat> the global operator new becomes nullable
23:18:00 <heat> meaning if(!ptr) isn't redundant, and it re-adds checks for null before constructing objects
23:18:00 <mrvn> so "new int" is a compiler error?
23:18:00 <geist> ah yeah `defm fcheck_new : BooleanFFlag<"check-new">, Group<clang_ignored_f_Group>;`
23:19:00 <heat> mrvn, no. more like new int behaves exactly like e.g new (std::nothrow) int
23:19:00 <mrvn> ahh, always or only on nothrow?
23:19:00 <heat> always
23:19:00 <heat> basically the global operator new loses the implicit nonnull attribute
23:19:00 <geist> yah from fiddling with it, basically everything but a plain new (nothrow, or even custom ones) can return null according to the compiler, thus it wont elide a check
23:19:00 <mrvn> That seems wrong. I would only want that on nothrow
23:19:00 <geist> gcc added this switch to make it work in all cases
23:21:00 <mrvn> A super feature would be for implicit checks for new == nullptr with stack unwinding in constructors.
23:23:00 <mrvn> Foo(size_t size) : data(new uint8_t(size) { } ... Foo *foo = new Foo(); if (!foo) panic(); should work
23:24:00 <moon-child> I use -falign-functions so I can stick data in the low bits of function pointers
23:24:00 <moon-child> am I a bad person?
23:24:00 <zid> yes but that's not related
23:24:00 <mrvn> yes
23:25:00 <mrvn> how do you even access the bits in a function pointer?
23:26:00 <moon-child> cast it to an integer
23:26:00 <mrvn> function pointer can be larger than intptr_t
23:26:00 <moon-child> not on the platforms I care about
23:26:00 <moon-child> and see app. J.2
23:26:00 <zid> It's IDB, so you do it in an IDB way that works on your I
23:27:00 <mrvn> on basically not x86 you don't even have to align the functions.
23:27:00 <mrvn> (for 1 bit)
23:28:00 <moon-child> 2 bits, no?
23:28:00 <moon-child> afaik arm and riscv ops are 4 bytes each, so you get 2 bits
23:28:00 <mrvn> 16 bit opcodes gives you even addresses
23:29:00 <moon-child> what arches have 2 byte ops?
23:30:00 <zid> fum
23:30:00 <geist> riscv
23:31:00 <geist> and arm32 with thumb
23:31:00 <geist> but still even at least
23:31:00 <mrvn> MC68000
23:32:00 <moon-child> riscv is 4 byte ops
23:32:00 <mrvn> ia64 has 256bit opcodes, right?
23:32:00 <geist> nope. there's a 16bit instruction set
23:32:00 <moon-child> there are compressed 2 byte ops, but you have to pair them
23:33:00 <geist> nope
23:33:00 <moon-child> oh
23:33:00 <geist> they are and can be totally unaligned
23:33:00 <geist> well 2 byte unaligned
23:33:00 <geist> there are no such restrictions with branching to aligned-on-two offsets
23:35:00 <geist> i think they decided that even though very low end modern cpus will probably fetch at least 32 bits at a time aligned on 4 bytes, it's not a lot of hardware to deal with decoding the instruction in the second half of the word, or an instruction that crosses that threshold
23:35:00 <geist> there may be some penalty to branching to a 4 byte instruction unaligned, but probably only on very low end cpus, before it has a chance to prefetch
23:49:00 <heat> do the riscv/arm instructions need to be 4 byte aligned?
23:50:00 <mrvn> 01:33 < geist> well 2 byte unaligned