<geist>
it was a bit odd splitting like that, instead of just having 16 register, but i think the advantage was probably internal. maybe the bus layout had some sort of direct wiring of A register to address computation logic, since 68k has super complex addressing modes
<geist>
and of curse you only needed 8 bits to address a register
<geist>
so they probaby had two register files that were independently accessed for A and D regs
<dh`>
from what I remember of m68k instruction encoding, that ends up being important
<geist>
yah
<geist>
since there's all these complex addressing schemes, and the way its laid out is fairly regular and pretty elegant the least number of bits allocated to the A registers is key
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<dh`>
it's not just that; they won't *fit* if larger
wootehfoot has quit [Quit: Leaving]
rorx has joined #osdev
rustyy has quit [Quit: leaving]
rustyy has joined #osdev
xing_song has quit [Read error: Connection reset by peer]
xing_song1 has joined #osdev
DonRichie has quit [Quit: bye]
<geist>
yah i mean they'd have to come up with a different sceme and then it probably would work as well, etc
DonRichie has joined #osdev
sdfgsdfg has quit [Quit: ZzzZ]
sdfgsdfg has joined #osdev
Burgundy has quit [Ping timeout: 245 seconds]
nyah has quit [Ping timeout: 268 seconds]
xing_song1 has quit [Read error: Connection reset by peer]
DonRichie has quit [Quit: bye]
DonRichie has joined #osdev
freakazoid12345 has joined #osdev
freakazoid343 has quit [Ping timeout: 245 seconds]
sdfgsdfg has quit [Quit: ZzzZ]
<zid>
did discord just die
<blockhead>
hopefully
<moon-child>
idk I don't use discord
zid has quit [Remote host closed the connection]
<gog>
it's working for me
zid has joined #osdev
<zid>
teest
<zid>
icles
<hbag>
im stoned and drunk on some spiced apple hard cider. i am now going to attempt to write a bootloader.
<gog>
zid
<blockhead>
it will be the best boot loader ever
<gog>
i've been working on stuff too i promise
<zid>
gog
<zid>
was it some testicles
<gog>
not for long
<hbag>
the first assembly i learned was MIPS and that was literally yesterday so here fucking goes lmao
<gog>
(scissor emoji)
<gog>
i'm stoned too btw
<hbag>
nice
<hbag>
ive recently discovered i only need to half-pack my dynavap to get a pretty fuckin solid high out of it
<hbag>
if i pack it more and denser it seems to trail off
<gog>
i just smoke i don't have fancy gizmos
<hbag>
is there a comprehensive instruction set manual for NASM
<gog>
NASM does MIPS assembly?
<zid>
Yes, it's called the x86 manual
<zid>
intel sdm volume 2
<Affliction>
The nasm manual for the assembler features, and the intel manuals for the architecture features
freakazoid12345 has quit [Ping timeout: 260 seconds]
freakazoid333 has joined #osdev
ElectronApps has joined #osdev
someonejv has quit [Ping timeout: 256 seconds]
someonejv has joined #osdev
ajoberstar has quit [Quit: ERC (IRC client for Emacs 27.1)]
gog` has joined #osdev
gog has quit [Ping timeout: 240 seconds]
IshoAntar has joined #osdev
IshoAntar has quit [Ping timeout: 260 seconds]
xing_song has joined #osdev
rustyy has quit [Quit: leaving]
IshoAntar has joined #osdev
rustyy has joined #osdev
IshoAntar has quit [Quit: Konversation terminated!]
sdfgsdfg has joined #osdev
dude12312414 has joined #osdev
epony has joined #osdev
particleflux_ has quit [Quit: 418 I'm a teapot]
particleflux has joined #osdev
newpy has joined #osdev
Affliction has quit [Quit: Read error: Connection reset by beer]
Affliction has joined #osdev
<newpy>
I'm having a little trouble understanding the "Expand Down" flag for segment descriptors
<bslsk05>
wiki.osdev.org: Segment Limits - OSDev Wiki
<newpy>
the 16-bit example just confused me more, I thought the stack would start at 050000 and grow down until 040400
<kazinsal>
For the most part segmentation is a long-dead thing and you just have a giant flat address space that you control what's visible in it with paging
<newpy>
kazinsal, yea I get that, just skimming over the boot loader process before moving on
<newpy>
kazinsal, so does "base address" have a different meaning for expand down segments?
<newpy>
ie. it's not the "starting" address?
<kazinsal>
The stuff for 16-bit segments there is extremely irrelevant and you shouldn't think about it
<kazinsal>
That's from extremely-legacy 16-bit 286 protected mode
<kazinsal>
At no point should you ever *ever* use that
<newpy>
oh ok, I'll check the 32 bit example
<kazinsal>
The real reason to basically ignore the nitty-gritty details of segmentation is that in 64-bit mode you *can't* use them. Segments must always have a base of 0 and a limit of all-one bits
<newpy>
I'm just reading through a whirlwind tutorial starting from boot time, setting things up for C-compiled code, etc
<newpy>
not going to go too deep into it, planning on moving quickly into higher level OS algos etc
<zid>
If you start doing C in 286 pmode or real mode or something I will cry
<newpy>
zid, nah it's using assembly to set up the environment for 32-bit C
<newpy>
zid, can you walk me through a calculation of address exception checking in an expand down segment?
<kazinsal>
There's really no reason to ever use an expand down segment.
<kazinsal>
I'm not even sure why we have an article on it.
<kazinsal>
We ought to have a "historical curiosity" tag...
<newpy>
oh I think I misread my tutorial
<newpy>
it says the data segment will be identical but for the type flags ... "Expand down: 0. This allows the segment to expand down - TODO explain this"
<newpy>
but setting expand down to 0 means it grows *up* not down
<geist>
that sounds about right. and osme of the sub variants of that
<jason1234>
so we have only netbsd,... too bad. quite sad actually.
<geist>
power/ppc, sparcv7-v9, etc
<geist>
honestly there just arent that many arches that have ever been up to modern mmu + unix class
<kazinsal>
okay, they have actual counts. 16 CPU architectures (including variants of an ISA) and 58 ports
<geist>
ia64, 3b2, uh, microblaze, nios2
<jason1234>
58 ... quite a lot.
<geist>
some various things like ARC maybe
<kazinsal>
assuming you consider different-endian variants of the same architecture to be separate CPU
<geist>
right, again port != arch. i can think of a handful of 68k based ports alone that are all 68k based
<jason1234>
you have to consider diff endians, they are different chips, but compatible though
GeDaMo has joined #osdev
<kazinsal>
yeah, at a certain point once you've genericized the architecture specific part itself, each machine port is basically just support for the additional chipsets etc. on top of the CPU
<geist>
looks like i've ported my os to 8 or 9, depending on how you account
<geist>
(and if i get around to merging that vax port back)
<geist>
but it's a smaller kernel, so much easier to port
<geist>
oh riscv, mustnt forget riscv
<kazinsal>
a Mac II and a Sun-2 both use 68k CPUs but they're completely different machines
<jason1234>
geist: exactly
<jason1234>
what is the name of your OS geist?
xing_song has quit [Read error: Connection reset by peer]
<bslsk05>
github.com: lk/arch at master · littlekernel/lk · GitHub
<jason1234>
super. thank you
<jason1234>
a smaller kernel is king - always
<geist>
kazinsal: yah i can't really think much more than about 16
<geist>
of the sum total of all >=32bit + mmu capable architectures that ever existed
<kazinsal>
totally. I don't know anything that still has up to date builds for stuff like NS32k
<geist>
i860, i960, etc
<geist>
88k maybe?
xing_song has joined #osdev
<kazinsal>
yeah, the lifespan of that was pretty short though
<geist>
not sure i960 ever got an mmu either
<kazinsal>
not many machines out there based on it, PPC came out a few years after its release
<kazinsal>
but yeah there's probably 30-40 32-bit architectures out there but 30-40 32-bit architectures with the capacity to run a vaguely modern Unix? forget about it
<jason1234>
thank you !
<jason1234>
I will try our little kernel. i am interested by a kernel that can compile very fast.
xing_song has quit [Read error: Connection reset by peer]
xenos1984 has quit [Quit: Leaving.]
xing_song has joined #osdev
<geist>
oh sure
<jason1234>
we could try it on our VPS on ircnow on openbsd
<jason1234>
we use com0 / serial to run it on vps.
<jason1234>
qemu -curses is too nice actually to test OSs
<jason1234>
geist remember me the name: geirt in BE country.
mahmutov has joined #osdev
<geist>
hmm?
<GeDaMo>
I think jason1234 is saying your nick reminds them of geirt
<geist>
yah suppose so
<kazinsal>
staring at e1000 PHY stuff and this is definitely a level of bizarre I wasn't really ready for tonight
<geist>
yah i was just staring at figuring out how to kick the chip after it gets a RX overflow
<geist>
it seems to get 'stuck'
<kazinsal>
there's a neat function on most of the e1000e PHYs that can estimate cable length for you
<kazinsal>
but you need to grab PHY register data for each of the twisted pairs, then look up the registers in a LUT
<kazinsal>
s/the registers/the results/
<kazinsal>
looks like some PHY versions just give you a rough estimate whereas a couple others either give you a +/- 5m estimate and the later models give you a +/- 1.5m estimate
<kazinsal>
not quite as accurate as a TDR but that's pretty good
<kazinsal>
probably enough to find cable faults too
<geist>
neat
<geist>
are you required to calibrate every boot or is it more of a diagnostics thing
<kazinsal>
looks like a diagnostics thing
<kazinsal>
trying to find some actual documentation on how it *works* mind you
<kazinsal>
great, that's not a PDF, that's a CSV. that doesn't help me at *all*
<kazinsal>
thanks intel. thintel.
<geist>
regular docs or are you looking for some specific diagnostics thing?
<kazinsal>
docs for the PHY itself
<kazinsal>
problem is the reference I'm using isn't exactly clear on what an "IGP02" PHY *is*
<geist>
hmm, i've heard of IGP before. some sort of chipset thing?
<kazinsal>
yeah, my suspicion is it stands for Integrated Gigabit PHY
<kazinsal>
aha, seems it's the i210 series integrated PHY
<jason1234>
i got the toolchain. I did chroot. and now it compiles. I am under devuan ascii.
<jason1234>
taht' all??? it took 1 minute only.
jafarlihi has joined #osdev
<jafarlihi>
Hey. Another stupid question, sorry. I'm trying to do x86 track in exercism.io. As soon as I add "mov eax, [string]" to my assembly file, I get this error: "/usr/bin/ld: two_fer.o: relocation R_X86_64_32S against `.rodata' can not be used when making a PIE object; recompile with -fPIE". When I remove that line of asm, it compiles normally and runs the tests. What could be the cause of this?
<GeDaMo>
Needs to be RIP-relative?
<jafarlihi>
Hmm, not sure what that means. I'll look into it.
<GeDaMo>
Are you writing 32-bit or 64-bit code?
<jafarlihi>
64 bit I think
<GeDaMo>
Which assembler?
<jafarlihi>
NASM
<GeDaMo>
Try mov eax, [rel string]
<jafarlihi>
That worked, thanks!
<GeDaMo>
That was a good guess :P
<GeDaMo>
jafarlihi: alternatively, you can put DEFAULT REL at the top of the file
<jason1234>
how do you boot lk.bin with qemu-system-x86_64 ?
<j`ey>
jason1234: look in scripts, there's a file called do-x86 or do-qemux86 or something
<jason1234>
thx
<jason1234>
mikeos can be started with qemu-system-x86_64 myfirstos.bin <-- directly. Or I can put : dd if=myfirstos.bin of=/dev/sdb2 and boot from grub.
<jason1234>
with chainloader.
kspalaiologos has joined #osdev
Burgundy has quit [Remote host closed the connection]
someonejv has quit [Read error: Connection reset by peer]
jafarlihi has quit [Ping timeout: 256 seconds]
kanton has joined #osdev
mahmutov has joined #osdev
someonejv has joined #osdev
nyah has joined #osdev
gog has joined #osdev
scoobydoo has quit [Read error: Connection timed out]
scoobydoo has joined #osdev
nj0rd has quit [Quit: WeeChat 3.4]
nj0rd has joined #osdev
mahmutov has quit [Ping timeout: 256 seconds]
xing_song has quit [Read error: Connection reset by peer]
xing_song has joined #osdev
pretty_dumm_guy has joined #osdev
xing_song has quit [Read error: Connection reset by peer]
xing_song has joined #osdev
dennis95 has joined #osdev
sdfgsdfg has quit [Quit: ZzzZ]
wand has quit [Remote host closed the connection]
wand has joined #osdev
scoobydoo has quit [Read error: Connection timed out]
scoobydoo has joined #osdev
<amazigh>
what is devuan ascii (i looked around could not find an answer)
srjek has joined #osdev
xing_song has quit [Read error: Connection reset by peer]
xing_song has joined #osdev
gdd has joined #osdev
robyndrake has quit [Quit: WeeChat 3.3]
xing_song has quit [Read error: Connection reset by peer]
g1n has quit [Read error: Connection reset by peer]
xing_song has joined #osdev
robyndrake has joined #osdev
kuler has quit [Remote host closed the connection]
wootehfoot has joined #osdev
xenos1984 has joined #osdev
gog` has quit [Quit: byee]
mahmutov has joined #osdev
someonejv has quit [Ping timeout: 240 seconds]
<blockhead>
amazigh: from the front page of the devuan site, ascii is the "oldoldstable" release. So it's older than beowulf (oldstable) and chimaera (stable)
someonejv has joined #osdev
vdamewood has joined #osdev
blockhead has quit [Ping timeout: 256 seconds]
blockhead has joined #osdev
xing_song has quit [Read error: Connection reset by peer]
xing_song has joined #osdev
kspalaiologos has quit [Quit: Leaving]
ElectronApps has quit [Remote host closed the connection]
vdamewood has quit [Read error: Connection reset by peer]
vdamewood has joined #osdev
lleo has joined #osdev
<amazigh>
^^'
x88x88x has quit [Read error: Connection reset by peer]
dude12312414 has joined #osdev
xing_song has quit [Read error: Connection reset by peer]
xing_song has joined #osdev
tomaw_ has joined #osdev
tomaw has quit [Ping timeout: 633 seconds]
tomaw_ is now known as tomaw
dennis95 has quit [Quit: Leaving]
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
<catern>
style 1 is sometimes called "busy looping". style 2 and style 3 aren't busy looping. what's a good single name for the "lack of busy looping" that covers both style 2 and style 3?
<GeDaMo>
Misfenestration!
<zid>
former isn't actually a busy loop imo
<zid>
it lacks the requisite 'busy' imo
<GeDaMo>
Oh, I thought catern sent that to the wrong channel :P
<catern>
nope :)
<zid>
I think that's because nero is in ##asm doing osdev
<catern>
zid: sure, s/sleep(1)/noop()/ if you like
<zid>
I'd just call that 'blocking'
<zid>
or 'async'
<zid>
for the latter
<zid>
rather than trying to cram them into the same term
<catern>
but rather than say "my system lacks X", and I'd like to say "my system is 100% Y"; that is, some alternative to saying "my system is busy-loop-free"
<catern>
it's convenient to be able to phrase things positively rather than negatively
<zid>
sounds like a problem to me :p
<zid>
spinlocks are handy
<catern>
sure, regardless of whether it's good or not, it would be useful to say - or "outside of so-and-so part, it's 100% Y"
<catern>
(if it's a message-passing microkernel, say)
freakazoid343 has joined #osdev
freakazoid333 has quit [Ping timeout: 240 seconds]
* geist
yawns
<geist>
good afternoon everyone
scoobydoo has quit [Read error: Connection timed out]
Burgundy has quit [Remote host closed the connection]
<catern>
GeDaMo: btw I did like your word, event-driven. I just worry that that overlaps with the "thread-based vs event-based concurrency" debate, when I want a word that applies to both of those
scoobydoo has joined #osdev
mahmutov has quit [Ping timeout: 256 seconds]
freakazoid343 has quit [Ping timeout: 245 seconds]
immibis has quit [Remote host closed the connection]
<geist>
zid: so question: you've fiddled with the e1000, is there any special thing you need to do when you get a RX overrun?
GeDaMo has quit [Remote host closed the connection]
<geist>
in this case I have 16 entries in the ring, and 15 rx descriptors. Occasionally i get a fast spew of packets that overruns it (HEAD loops around and == TAIL)
<geist>
so unsurprisingly it stops, of course. but when i start putting rx descriptors back in the queue i get a weird effect where HEAD follows TAIL as I push tail forward
<geist>
i'm also *not* getting a rx overflow IRQ
<geist>
I assumed i'd just get a rx overflow irq and then just start putting things back in the tail, but it's almost like it's stuck in some sort of state i have to clear somehow
<geist>
and obviously i can increase the size of the rx ring and reove printfs and stuff where this situation doesn't happen in the first place, but i'm intentionally trying to see what happens in thi s edge case
sdfgsdfg has joined #osdev
<zid>
I didn't experience that, but I also didn't stress it hard enough to probably have noticed sorry
<zid>
maybe if I started sleeping inside the handler or something, atm it's just too damn fast
biblio has joined #osdev
<geist>
yah at the moment it's because i have a crap ton of printfs in the net stack
<geist>
and occasionally on my network someone spams a huge pile of ipv6 router solicitations or something
<geist>
like 20 packets in short succession
biblio has quit [Client Quit]
<zid>
I would have thought dropping the packet was the 'correct' solution, so just ignoring it and dealing with the descriptors as normal is fine
<zid>
and maybe your head/tail thing is just a code issue
<geist>
right,that's what i assumed. treat the rx overflow as an informational thing and move on
<geist>
but yah the weird thing is at the time it runs out you end up with something like RDH = RDH = say 5
<zid>
are you using the status bit to grab all the descriptors with packets and clearing them etc?
<geist>
RDH = RDT = 5
<geist>
and then as i start stuffing rx descriptors back in i bump RDT
immibis has joined #osdev
<geist>
but when i read back RDH it's immediately == RDT
<zid>
did you get another packet in the meantime?
<geist>
like every time i bump RDT, RDH follows it
<zid>
sounds like it might be re-absorbing the overflow if the heads and tails etc are moving
<geist>
right. but no new packets
brynet has quit [Quit: leaving]
<geist>
hmm, maybe there's something wrong with the descriptor that causes it to instantly consume it
<geist>
like it's got zeros in it or something
<geist>
will check
<zid>
also there's a weird off by 1 with the descriptors
<zid>
which my code apparently does, but I don't remember reading about it
<geist>
yah it is annoying that if you have say 16 sized ring, you can apparelty only queue 15 descriptors
<geist>
otherwise you'll push RDH = RDT and then that's a stop
<zid>
I read the tail and add 1 to it, then write it back and increment
<zid>
for every packet that has status = 1
<geist>
yah though i keep a local copy of tail and the last known head so i dont have to
<zid>
I could maybe batch the tail update I've not tried
<geist>
but i'm asserting here that tail doesn't get out of whack
<zid>
The draft that's on my github is functional at least so it's linkable over irc
<bslsk05>
github.com: boros/e1000.c at master · zid/boros · GitHub
<geist>
i'm guessing i'm screwig up the copy back of the rx descriptor
<geist>
such that the hardware consumes it instantly. it's already known that descriptors with zero in the address are skipped by hardware
<zid>
That's the simplest 'apparently working' solution I came up with, anyway
<zid>
it deals with *small* bursts for sure, and regular traffic
<geist>
kk, thanks
<geist>
the tx path is of course simple
<geist>
and i had to do what you're doing and increase the RX buffer size to 2048
<zid>
I'm not sure I really tested the tx path, I only really reply to pings with it :P
<geist>
due to limitations in my pktbuf struct for the net stack
<geist>
it assumes that packets come in in one buffer, but was previously assuming that ethernet controllers can receive into arbitrarily sized buffers
<geist>
ie, you could queue up literally a 1536 byte buffer
<zid>
I just used 4096
brynet has joined #osdev
<zid>
and I give it physical pages straight off my allocator
<geist>
which all the other eth drivers (of which there are like 3) could do. the e1000 is the first one is the first one i've seen that requires a power of 2 buffer size, but i see why
<zid>
because.. least code
<geist>
it actually greatly simplifies their logic since they can compute instantly how many descriptors it'll take
<zid>
if I need something else I will have to write it
<geist>
yah i just allocated 2K * rxring desriptor contiguous region and then pass it up the net stack. the way the net stack works it always makes a copy at the end of the processing of the packet, so the packet is synchronously returned to the driver and it can just put it back in the ring
<geist>
so no sweat. it's not zero copy, but it's not awful: one copy
<zid>
Mine's too monolithic to care atm, the buffer is just free as soon as the net_() call returns
<zid>
so I never bother to copy the data, or change the address
<geist>
exactly. same here
<geist>
i can just stuff the existing pktbuf back in the next ring descriptor, which is what happens
<zid>
I don't even do that, I don't touch any field except to reset status
<zid>
at driver load I put a frame into each descriptor and they never change
<geist>
well, i do only because the TAIL is probably in a different slot at that point
<geist>
ie, HEAD is 5, TAIL is 9, i get a packet for 5 i have to put it back in slot 9
<geist>
but no big deal since a rx ring descriptor can just be made up from scratch in 2 lines of code
<zid>
Mine's technically super performant, but that's mainly because I don't actually do any real work so I have no compromises to make ;)
<geist>
but there's probably a bug in the logic there somewhere, hence my issue
<geist>
yay
<zid>
It's nice when there's no other considerations to care about :D
<geist>
what this is also pointing out to me is that i need to do some more serious work on my tcp/ip stak
<geist>
the one in LK is intentionally simple, it's called 'minip' because it's mini
<zid>
like say, wanting to steal the packet and map it into userspace for raw sockets, so I don't need to be able to remove the page from the descriptor
<geist>
but it also has serious limitations like it has no concept of multiple interfaces, etc
<geist>
so i should at least grow the notion of more than one interface and some sort of simple routing table
<zid>
Mine's even better than yours, it doesn't evne know what a subnet is
<geist>
the stack i wrote like 20 years ago for newos was more of a traditional thing, so i go back to it for inspiration, but the style of code is too foreign to directly use
<zid>
If it gets pinged, it assumes it's for it and replies
<zid>
otherwise why did it even see the ping, it's not like my qemu is on a switch ;)
<geist>
basically minip has a few fields: current mac address, current ip address, current subnet mask. and then a TX pointer from the driver and there's a RX function the driver calls
<geist>
and that's pretty much it
<zid>
yea net_give_packet(buf, len) is my entire interface, hopefully the network stack can just deal with anything it needs to deal with, the only requirement is that buf has to be 'done with' by the time it returns
<geist>
pretty functional for simple embedded things, but want to expand it a teensy bit. doesn't even handle loopback stuff
<geist>
yah, exactly the same here
<zid>
because I don't pop the packet out of the ring, I jsut mark it as read
<kazinsal>
I gotta do up a sockets implementation
<zid>
I'm not honestly sure why you're going to the effort to pop/push to yours
<geist>
only difference is i have this 'pktbuf' thing which is basically a fancy descriptor that points to a buffer and has an offset + len field. so you can as the stack processes headers 'peel off' from the start of the buffer
<zid>
There's probably some requirement like raw sockets or something that I don't have
<geist>
and on the way down the lower layers can prepend headers, works nicely, but still requires everything be contained in a single data buffer
<zid>
I like the idea of allocating a 4k page, char[2048] for headers, char[2048] for the network card
<zid>
and just keep re-encapsulating it up the osi stack
<geist>
yah i can do that with the pktbuf: there's a way to start off with the offsets set
<zid>
I hadn't considered that but it's very clever and cute
<geist>
something like pktbuf_alloc(MAX_HEADER_LEN, DATA_LEN); where it basically starts off with data_buf = buf + MAX_HEADER_LEN;
<geist>
i recommend that for a simple solution, works well and requires very little code
<zid>
It beats continually allocating new pages and memcpying into it with an offset for the new header
<bslsk05>
github.com: lk/pktbuf.h at master · littlekernel/lk · GitHub
<zid>
if you can just use it like a stack and keep pushing headers
<geist>
for inspiration
freakazoid12345 has joined #osdev
<zid>
I'd probably just do it all with bit hacks because I am silly
<geist>
also helpful that the pktbuf struct has a linked list node so you can also easily chain it into a queue or whatnot
<geist>
and a flags field for things like 'checksum is already computed by hardware'
<geist>
but what pktbuf *doesnt* do is allow for scatter gather chains of things, ie, the traditional mbuf thing in BSD stacks and whatnot
<geist>
which is much nicer but a lot more complicated
<geist>
or i forget what linux calls it. netbufs?
<zid>
I don't know the reference so it's lost on me
<zid>
I prefer to go in semi-blind and mess around
<geist>
word.
<zid>
It's nice not to have to do a research project first, at least ;P
<geist>
my general feel is the moment you need to start passing around 2 or 3 arguments to things that are related and need to stay in sync (ie, void * + size_t) they should probaby be encapsulated into some sort of struct or object
<geist>
or at least that's the new me thinking, vs me 20 years ago
<zid>
I just go by encapsulation, for the most part
<zid>
and object lifetime
<geist>
yah
<zid>
by value if the lifetime doesn't matter, if it matters then that api will have a _new function
<zid>
which returns an opaque pointer
<geist>
yah. i'm writin gmore code in C++ but i'm holding the line that apis are C (with maybe a convenience C++ wrapper)
<geist>
and thus you end up with some void * style pointers
<geist>
or struct foo; style pointers for some type safety
<zid>
90%+ of my interface end up as void blah_verb(struct blah *blah, ...);
freakazoid12345 has quit [Ping timeout: 240 seconds]
<zid>
where the ... is the param to the verb
<zid>
it also aligns with the sysvabi
<zid>
which was designed with that in mind presumably
<geist>
yah, and then i've found it's pretty nice to then for C++ you can just rewrap that in a wrapper C++ object that has a bunch of inline methods to the C routine
<geist>
so you get the best of both worlds
<zid>
I also think all of this falls out completely naturally from the requirements and writing anything in a different way is super weird
<geist>
that's what we've generally done with zircon over the last 5 years, to then slowly merge that abstraction such that the underlying thing is C++, and it has been a nice way to slowly transform a code base, or leave the code base as is
<geist>
ahd yeah i've been doing noun_verb() for a long time. if anything it comes from being able to easily complete the reference as you're typing
<zid>
I've never used an IDE with completion :p
<geist>
one of my main compaints with C++ is you end up with generic looking functions like Process()
<geist>
because it's part of some larger thing
<zid>
isn't that because of namespacing though, you can not 'use blah' then it turns back into blah::process, which is effectly blah_process
<geist>
i have only used simple ctags style lookup for the most part
<geist>
which then means it's really really handy if your function names are completely self contained, thus that there's one of them in the system
<zid>
(which is also why I never saw the point of C++ namespacing, because.. I already do that from C just fine thanks)
<geist>
agreed
<zid>
yutani_window_is_bottom
<zid>
nice
<geist>
i dont like excessive c++ namespaces, but you always get one level of it in the form of class { method; }
<kazinsal>
yutani_window_could_go_either_way
<gog>
is the return type of that function adigadulgdaf_gha_t
<geist>
and that's the problem, your methods end up being simple names which fouls up simple name completion that doesn't understand the context
<kazinsal>
gog: lmao
<zid>
bite_t pillow;
<geist>
but the general pushback at work is 'get a better editor' so there you go
friedy10 has joined #osdev
<kazinsal>
operator::uwu
<geist>
as a side note i've been using YouCompleteMe in vim and it's been pretty okay
<geist>
if you feed it a decent compile_commands.json (which can be generated with `bear make`) it basically deals with my code base at least
<klange>
My completer is a pretty dumb thing that groks ctags files
<geist>
YCM runs a clang compiler in the background, so it can be fairly intensive, since it's continually reparsing the file you're working with though
<geist>
it ends up being about half way between totally dumb and a fully integrated IDE, but i can dig it
<zid>
notepad++ knows about the C stdlib, I don't know why
<zid>
I've used it twice so far because I always forget which way around fread goes
bauen1 has joined #osdev
<zid>
C stdlib has basically a single struct object (FILE *) and isn't consisent on the verb_noun pattern so it uses dst, src, size, .. pattern from memcpy etc
<zid>
at leat, that's what I think
<geist>
yah that one is annoying
<klange>
what's really fun is the f* functions that have different orderings for where the file goes
<geist>
yah, exactly
<zid>
yea that's what we're talking about
<zid>
I think it's because it mimics memcpy's prototype, not noun_verb prototypes
<klange>
I can't imagine I would have been an effective programmer in the days of short symbols.
<zid>
or memset etc
<zid>
so fread goes dest, size, source
<zid>
but source is a FILE *
<friedy10>
Hey guys! My name is Friedrich, and I am a college student. I really enjoy OS dev and low level programming, and I'm looking for a software engineering internship for this summer. Any ideas? I just want to get some real world experience doing this type of stuff.
<zid>
add sound to my gameboy emulator, thanks
<zid>
The pay is £0 and nobody will respect you for it
<gog>
i will
* zid
is not a very good salesman
<gog>
respect you that is, not add sound to zid's gameboy emulator
<zid>
damn
<friedy10>
At least someone will respect me for it.
<geist>
friedy10: where are you located?
<geist>
not like that matters as much anyway, if it's remote
<zid>
geist stop trying to find people to cough on
<geist>
awww that's mean
<zid>
They're mine to cough on not yours!
<friedy10>
I am in Pittsburgh, but I don't mind flying around the U.S
<geist>
that's gog that coughs up hairballs on people
<zid>
You should, planes are full of germs :p
<gog>
do not
* gog
hacks
* kazinsal
moves gog off the carpet
<zid>
I bet that's not a consideration gog's wife knew about, that there'd have to be a convenient piece of lino nearby at all times
<geist>
or newspapers spread around
<gog>
it's cool our floor is tile
sdfgsdfg has quit [Quit: ZzzZ]
wootehfoot has quit [Read error: Connection reset by peer]
<geist>
also omg new Letterkenny season
<zid>
I stopped watching that at the start of the radio call-in season I thought it was super weak
<zid>
did it recover?
<geist>
i dunno, but was just watching the cold opens
<geist>
i'm a few seasons back. basically i love their witty scenes, but the overall plots are mostly just to move them between scenes
<geist>
it's kinda like watching shakespeare for hicks. it's about all the clever wordplay
<geist>
at best. sometimes it's not as good though
<zid>
yea I've apparently watched more of if than you have :p
<kazinsal>
I still haven't started watching the new season of The Expanse yet
<kazinsal>
it's on my to do list, just... idk, last season didn't have the same feel as the ones before it and now I'm not as interested in jumping headfirst into this one
<zid>
I watched the first season, didn't really interest me too much
<zid>
really generic and nothing that compelling
sdfgsdfg has joined #osdev
brynet has quit [Quit: leaving]
bauen1 has quit [Read error: Connection reset by peer]
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
brynet has joined #osdev
freakazoid343 has joined #osdev
xing_song has quit [Read error: Connection reset by peer]