channel logs for 2004 - 2010 are archived at http://tunes.org/~nef/logs/old/ ·· 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
http://bespin.org/~qz/search/?view=1&c=osdev&y=19&m=2&d=3
12:04:29 <ryoshu> hi
12:04:52 <ryoshu> https://nxr.netbsd.org/xref/src/sys/arch/i386/stand/lib/realprot.S#90
12:05:02 <ryoshu> what does happen in gdt_fixup? why to fixup it?
12:05:14 <ryoshu> and how is it fixing? why?
12:15:06 <Mutabah> looks like it's manging the GDT's offsets to point to the location of the boot code/data
12:15:17 <Mutabah> Likely something specific to this bootloader
12:16:32 <eryjus> looks like it is managing the real-mode segment selectors prior to getting into protected mode...
12:16:54 <eryjus> it is the first thing called from https://nxr.netbsd.org/xref/src/sys/arch/i386/stand/bootxx/bootxx.S#58
12:20:21 <geist> huh. the little trs-80 model 100 came in the mail
12:20:25 <geist> it's actually a darn nice little machine
12:20:34 <geist> keyboard is pretty swanky
12:37:56 <ryoshu> Mutabah: am I reading it correctly that code/data/real segments are mapped into the same exact place in memory?
12:43:53 <doug16k> ryoshu, the way I read it, it puts the real mode cs and ss into ourseg and stkseg, then puts (stkseg-ourseg)<<4 into stkdif, then sets the base of code/real/data seg gdt entries to same base as real mode cs
12:45:34 <doug16k> note that nothing loaded ds, ss or cs there, nothing will necessarily happen yet
12:45:36 <ryoshu> I was wondering about rationale for (stkseg-ourseg)<<4
12:46:10 <doug16k> real mode segments must be shifted left 4 to convert to linear address. the diff of real mode segs << 4 is the byte distance
12:46:14 <ryoshu> 'sets the base of code/real/data seg gdt entries to same base as real mode cs' is it rational action?
12:46:36 <doug16k> absolutely. x86 gcc codegen is assuming cs, ds and ss have the same base
12:47:11 <doug16k> you must ensure cs==ds==ss base before entering gcc generated code
12:47:29 <doug16k> having es == ds is a very good idea too. also clear DF :D
12:47:36 <ryoshu> another question... is it legal to use %eax (32-bit registers) in .code16?
12:47:43 <doug16k> yes
12:48:02 <doug16k> that tells the assembler to escape instructions to be the "other" mode with address size or operand size prefixes
12:48:04 <ryoshu> is it a syntax suggar or supported in 16-bit mode?
12:48:14 <doug16k> in code16 32 bit ops are prefixed. in code32, 16 bit ops are prefixed
12:48:57 <doug16k> the assembler must know whether the cpu is in 32 bit or 16 bit mode. the instructions are not the same
12:49:24 <ryoshu> I think that .code16 means that we are in 16-bit mode.. but EAX is 32-bit?
12:49:40 <doug16k> 0x66 .... in 32 bit mode means a 16 bit override prefix. 0x66 in 16 bit mode means 32 bit override prefix
12:49:40 <Mutabah> You can use the 32-bit regs from real mode
12:50:59 <doug16k> and you can use 16 bit registers in 32 bit mode
12:51:24 <doug16k> the code16 or code32 tell it how to put the overrides on when you want non-default operand size or addressing mode
12:53:17 <ryoshu> 'code/real/data seg gdt entries' 'ds, ss or cs' cs=code, ds=data.. real==ss?
12:53:56 <doug16k> what?
12:54:28 <ryoshu> 01:46 < ryoshu> 'sets the base of code/real/data seg gdt entries to same base as real mode cs' is it rational action?
12:54:32 <ryoshu> 01:46 < doug16k> absolutely. x86 gcc codegen is assuming cs, ds and ss have the same base
12:54:35 <ryoshu> 01:47 < doug16k> you must ensure cs==ds==ss base before entering gcc generated code
12:56:18 <doug16k> x86 has a bunch of cases where it will implicitly use ds, es, or ss. gcc can forget about that issue if it uses a flat memory mode. to make it not matter whether the cpu chooses ds, es, or ss, for a given addressing mode and instruction, they just require them all to be the same
12:56:32 <doug16k> s/mode./model./
12:56:52 <doug16k> the same as in, same base, same limit
12:57:13 <ryoshu> I see
12:57:40 <ryoshu> (stkseg-ourseg)<<4 <- is it some magic? I don't understand it
12:57:43 <ryoshu> its purpose
12:57:55 <clever> looks like a normal bit shift
12:58:09 <ryoshu> but why?
12:58:17 <doug16k> << 4 because a difference of 1 in real mode segment is 16 bytes
12:58:18 <ryoshu> I know that logical bit shift
12:58:32 <doug16k> real mode address = (seg << 4) + ofs
12:59:08 <doug16k> << 4 is the equivalent of * 16
12:59:09 <ryoshu> I see, thanks
12:59:22 <ryoshu> it makes more sense now!
01:04:21 <pounce> Hello, im trying to figure out if im in compatibility mode on an x64 processor. Is there any way to do that?
01:09:57 <doug16k> pounce, execute 0x48, 0x90
01:10:16 <doug16k> in compatibility mode it is dec eax. in long mode it is xchg rax,rax
01:10:42 <doug16k> dec eax + nop I mean
01:11:03 <pounce> oh thanks!
01:35:38 <geist> doug16k: that's cute
01:38:12 <ryoshu> I've just found http://www.isdaman.com/alsos/hardware/proc/386INTEL.TXT
01:38:18 <ryoshu> need to refresh my knowledge
01:38:43 <doug16k> will you think less of me if I use cpio format for my initrd of kernel modules? :D
01:39:51 <doug16k> that format is as trivial as it gets!
01:41:29 <doug16k> the TRAILER!! filename at the end though. wow
01:42:20 <geist> not at all
01:42:25 <geist> it's a decent format for precisely that
01:43:06 <geist> not great for streaming because of that, but perfectly find to skip through to find the sections once its in memorry
01:43:16 <doug16k> I almost reinvented that wheel. glad I didn't
01:43:27 <geist> ar format is i think fairly handy too
01:43:54 <geist> having metadata at the end does fail the 'can you decompress it on the fly and pick out individual sections' test
01:44:04 <geist> because you have to decomress the whole thing to find the TOC to then decide what part you needed
01:44:25 <geist> tar or it's variants are a little nicer because of that property
01:45:33 <doug16k> the 512 byte alignment thing deterred me a bit when I looked before
01:45:36 <geist> years ago i wrote an ELF loader of a gzip compressed elf file with the basic prroperty that as far as i can tell, elf data structres never reference anything 'before' them
01:45:51 <geist> ie, you always find the program headers before the segments they point to, etc
01:46:17 <geist> that way you can essentially stream a compressed elf file into the final location without previously having to decompress it somewhere else
01:46:48 <geist> REL entries and string table would probably scrrew that up, but in this case it was not a relocatable binary
01:50:22 <doug16k> you could also manually do it with zlib and do a sync_flush(?) at key points so you can seek there. then it's getting into custom stuff though
01:51:16 <doug16k> it would be cool to have a native compressed executable format though
01:51:48 <geist> yah a little surprised there isn't a real CELF. my guess is the general utility of it for larger systems is not big enough
01:51:59 <geist> because it would generally cause problems with demand paging it in
01:55:36 <doug16k> which you could mitigate (compress 16KB or 64KB ranges separately or something), but that is sacrificing compression ratio
01:55:43 <doug16k> I guess by then benefit is getting thin
01:59:13 <pounce> oh that makes sense
01:59:47 <pounce> when you turn off paging in long mode it turns into compatibility mode
02:01:29 <pounce> or wait, does it turn into protected mode? how do i tell the difference ]
02:04:03 <markweston> 9:s #osdev
02:04:05 <doug16k> pounce, read CR4
02:04:36 <markweston> what board should I buy to learn osdev?
02:04:38 <doug16k> if CR4.LME is 1 and CR4.LMA is 0 then turning on CR0.PG goes back into long mode
02:05:49 <doug16k> LME = long mode enabled, LMA = long mode active
02:06:09 <pounce> ok, thanks!
02:06:28 <pounce> I suppose i should change my instructions back to 32 bit since now I know it's in compat mode XwX
02:08:01 <kingoffrance> doug16k: is upx a bad place to start? they claim decompression "in place". even has a psx target
02:09:02 <kingoffrance> or is there some reason it would be better not to "compress elf/whatever" but it would be better to design from ground up a "compressed object/executable/library format" ?
02:09:45 <doug16k> yeah that's a good idea too, very mature
02:09:47 <clever> kingoffrance: one major downside of things like upx, is that you cant share the .text memory between multiple processes
02:10:11 <clever> with non-packed executables,you just mmap the file into ram, and the kernel shares things for you
02:10:20 <doug16k> clever, can't you? if the kernel is aware it can.
02:10:24 <doug16k> generally that's true though
02:10:40 <clever> doug16k: upx is allocating normal memory via mmap, and uncompressing the real .text and .data to that
02:10:50 <clever> and the kernel cant dedup that between multiple identical processes
02:11:42 <doug16k> you mean the implementation? I don't have a clue what UPX does in detail. I mean, it is feasible to decompress into CoW pages if the kernel is aware of the compression, in your own kernel
02:12:20 <clever> CoW pages would require finding an existing copy to share the table entries with
02:12:56 <clever> which also reminds me of a lot of security bugs, does any process on the machine page a page with these contents?
02:13:10 <clever> brute-force readout of ram, cross-user
02:17:44 <kingoffrance> thats kinda what i was getting at...custom OS could presumably "fix" that sharing issue
02:23:47 <kingoffrance> https://en.wikipedia.org/wiki/.kkrieger thats my hero, but i dont know how much applies to code "procedurally generate" ...and just cuz something is packed small, doesnt mean RAM usage at runtime necessarily matches
02:24:41 <clever> kingoffrance: yeah, if you had a kernel level unpacker, then you could remember the unpacked version and share properly
02:24:56 <clever> kingoffrance: but at that point, i would just go with a compressed filesystem, and have unpacked executables
02:25:16 <clever> then your mmap level stuff just asks the FS "get me range x-y of file z", and the FS deals with decompression
02:25:48 <clever> ext4 at one point had an (unmerged) patch to support immutable compression
02:25:59 <clever> you run a special util on a file, and the blocks on-disk are then compressed, and the file turned immutable
02:26:31 <clever> so they didnt have to deal with writes to a random offset screwing with compression
02:35:13 <ryoshu> clever: hi
02:35:18 <doug16k> clever, I meant, when you get a page fault for some VA range (because nothing has touched there until now), you do whatever decompress you must do (and perhaps commit a range around the access), and make the decompressed pages CoW. all further new processes will have that read only CoW page present. if they write it, then make a private page
02:35:20 <ryoshu> clever: we walked on #qemu :)
02:35:40 <ryoshu> clever: making my knowledge on booting deeper in order to get -kernel to work
02:36:11 <clever> doug16k: yeah, but that requires the kernel to understand the compression, so UPX and userland trickery cant handle it
02:36:58 <doug16k> oh, that was my point the whole time. I was pondering a native compressed format with full kernel awareness and participation
02:37:11 <clever> ryoshu: i first joined #osdev because i wanted to make an entirely custom qemu bios, for an entirely custom "machine" type, to be able to run xen unikernels, lol
02:37:29 <clever> doug16k: i think it would be simpler, and far more beneficial, to have native compression at the filesystem layer
02:37:37 <clever> doug16k: then non-executables can also benefit from it
02:38:22 <CompanionCube> that ext4 cmpression sounds lame
02:39:20 <clever> CompanionCube: likely why the patch was rejected
02:39:38 <CompanionCube> but even lz4 compression can be v. useful
02:39:39 <clever> personally, i use zfs and its automatic compression (supports write!)
02:39:44 * CompanionCube checks the stats
02:40:06 <CompanionCube> current compression ratio is 2.27x
02:40:46 <clever> CompanionCube: 1.38x for the entire desktop, 2,8x is the best i have (but its a 4mb layer from docker)
02:41:05 * CompanionCube should look at his user data values
02:41:28 <clever> 2.47x is the best ratio on a real dataset, a 23gig volume where i also enabled dedup, because i'm storing duplicate copies of things a lot
02:42:41 <CompanionCube> clever: https://gist.github.com/samis/04c12633b66f9ed223e4f7c59dded73c
02:43:25 <CompanionCube> I hope the dedup ratio's high enough to make the overhead worthwhile
02:44:12 <clever> CompanionCube: i'm storing 42gig of data, on only 23gig of disk
02:44:35 <clever> CompanionCube: and i work with software that regularly downloads ~8gig of data, and has some misc metadata that has upgrade problems
02:44:44 <clever> so i need many copies of that 8gig, that at 99% identical
02:45:11 <CompanionCube> so, worth the DDT-induced slowness ten?
02:46:10 * CompanionCube wonders how much the ratio will improve when zstd compression is supported
02:54:24 <markweston> how do you get into the OS game? do start from microcontrollers and work your way up?
03:19:08 <renopt> markweston: nice thing about osdev stuff is it's so open-ended, you can start anywhere and work on whatever you prefer
03:21:17 <renopt> a little microcontroller OS is a good place to begin if you're just getting into it, simple hardware and small scope
03:24:36 <markweston> thanks, my esp32 just arrived, it's gonna be a blast
03:50:41 <nyc`> I don't like the way ext* do hashing for directories. It's kind of questionable if hashing is the right way to go at all. Hash tries are probably better for on-disk affairs if they're determined to leave sorting unassisted.
03:59:18 <zhiayang> hm, part 2 of the ioapic nonsense
03:59:26 <zhiayang> wiki says the id register is read only
03:59:52 <zhiayang> but ioapic spec says r/w, and furthermore “This register must be programmed with
03:59:52 <zhiayang> the correct ID value before using the IOAPIC for message transmission.”
04:00:11 * zhiayang confuzzlement increases
04:01:40 <nyc`> Some things probably follow the spec, and the rest need kernel workarounds.
04:02:31 <zhiayang> :/
04:03:18 <zhiayang> then in that case i’ll probably write what the tables tell me into the registers if there’s a discrepancy
04:03:40 <nyc`> The Sequent boxen I worked on had so many IO-APIC's it was mind-boggling.
04:06:18 <geist> yah largest i've seen on consumer level stuff is 3
04:06:41 <geist> my experience is that AMD things tend to be a bit more complicated. two non symmetric io apics for regular ryzen hardware, etc
04:08:33 <bcos_> zhiayang: Are you sure you're not misreading the OSdev wiki (e.g. getting "APIC version register, read only" confused with "Get/set APIC ID")?
04:11:39 <bcos_> zhiayang: Also note that when Intel says "must be programmed with the correct ID value before use" what they really mean is "firmware does this, OS should not"
04:13:58 <zhiayang> bcos_: “It's a Read-Only register with almost all bits reserved. The only interesting field is in bits 24 - 27: the APIC ID for this device”
04:14:06 <zhiayang> oh, hm
04:14:15 <zhiayang> but it does explicitly say it’s read write
04:19:20 <bcos_> zhiayang: I think we're looking at different pages (I'm looking at https://wiki.osdev.org/APIC#IO_APIC_Registers )
04:20:15 <bcos_> ..and you're looking at https://wiki.osdev.org/IOAPIC :-)
04:22:17 <zhiayang> lmao
04:22:33 <zhiayang> hm, so what should be the course of action here
04:22:40 <zhiayang> to set or not to set?
04:23:22 <bcos_> Not set (maybe complain if firmware screwed it up if you're being diligent)
04:23:34 <zhiayang> i see
04:23:49 <zhiayang> the reason i ask is because firmware indeed screwed up
04:24:27 <bcos_> Ah - I remember you mentioning a bug in VirtualBox?
04:24:34 <zhiayang> yep
04:25:01 <zhiayang> the id in the madt doesn’t match the ioapic id
04:26:07 <bcos_> You can do an "if(computer_is_virtualbox) { if(IO_APIC_ID_is_borked) { workaround(); } .."
04:27:09 <bcos_> Over time you'll probably end up with 25% of your code being "if(something) { workaround(); }" - CPU errata alone can blow through thousands of lines of code.. ;-)
04:31:12 <zhiayang> :D:
04:31:30 <zhiayang> i see
04:31:31 <geist> though frankly most hobby oses dont get to that point. to et there you need a vast array of hardware to test on
04:31:41 <geist> so dont get too worried about it
04:31:50 <zhiayang> right
04:31:51 <geist> but errata do exist, and there are lots of exceptions
04:32:12 <zhiayang> i just want the kernel to be “correct” so it works on as many emulators as feasible
04:32:19 <geist> but dont stress out about it. work around the stuff you know, and make the code defensive so that it at least fails gracefully when it hits something it doesn't
04:32:42 <geist> i think the latter part is key. that way when someone tries it and it fails on their setup, you have printfs or whatnot to give you a hint to whats going on
04:32:56 <zhiayang> mm, right
04:33:06 <zhiayang> i’m now just printing a warning for this particular case
04:33:11 <geist> good idea
04:53:15 <pounce> grr, im getting this weird error on nasm and i can't figure out why
05:02:02 <Mutabah> paste?
05:04:35 <pounce> it's just `and rax, ~(1 << 31)` and it's saying "dword data exceeds bounds"
05:06:09 <geist> may be because whatever their internal integerr promotion rules are it generated a 64bit integer or whatnot
05:08:17 <geist> try anding that with 0xffffffff
05:08:28 <geist> (~(1 << 31) & 0xffffffff) or somethig
05:08:33 <geist> see if that clears it up
05:09:49 <Mutabah> pounce: Or try 0x7FFFFFFF
05:10:07 <pounce> geist: yeah that works...
05:28:48 <pounce> doug16k: not sure if you're still here... but ive been looking through the manuals and i can't find cr4.LME or LMA
05:32:28 <Mutabah> pounce: LME is in EFER (one of the MSRs)
05:38:58 <pounce> ok ill check that out. cand find much in the manuals but also im really tired so ill look later
05:39:05 <pounce> tyvm
06:06:38 <doug16k> oh sorry it is EFER
06:26:50 * klys edges slowly forward at physical allocation
09:25:55 <zhiayang> am i imagining this, or is there a bit or flag somewhere to set that the lapic timer runs at a constant rate independent of cpu clock speed?
09:39:16 <zhiayang> wait or is it always fixed?
10:40:42 <renopt> zhiayang: it's always fixed, you can set a divisor though
12:12:46 <zhiayang> renopt: ah right, i was thinking of the tsc
12:13:08 <zhiayang> also: is there something special about how qemu does the lapic timer?
12:13:43 <zhiayang> it appears to tick a lot slower than it should
12:13:52 <zhiayang> (versus virtualbox)
12:14:44 <zhiayang> https://bpaste.net/show/d97aa05085e3
12:14:48 <zhiayang> this is the init code
12:27:17 <nyc`> zhiayang: I wouldn't be surprised if it's a bug in qemu.
12:38:43 <zhiayang> hm
12:38:59 <zhiayang> the smaller i set the divisor on the PIT, the slower the lapic timer gets
12:39:12 <zhiayang> i *don't think* there's anything obviously wrong with my calibration code
12:49:54 <zhiayang> unless i'm not programming the PIT correctly
01:52:56 <zhiayang> hm ok apparently using mode 2 (rate generator) vs mode 3 (square wave) makes it less bogus
01:53:11 <zhiayang> although i've used mode 3 before without such issues
01:53:14 <zhiayang> i think, at least
01:59:20 <nyc`> Testing a known working OS using the lapic timer might be worthwhile.
02:26:02 <jmp9> Hi everyone. Does anyone have good article about fixed point numbers?
02:48:57 <jmp9> Uhm
02:56:55 <knebulae> @jmp9: you might want to be more specific, or you're liable to get a wikipedia link. I'm not gonna lie-- it's in my clipboard.
03:07:21 <mrvn> wikipedia, please. How about a loink to the c/c++ standard?
03:08:08 <knebulae> @mrvn: which one?
03:11:17 <mrvn> hmm, I know I've seen it but google is unhelpful
03:12:19 <mrvn> https://stackoverflow.com/questions/9883532/why-arent-fixed-point-types-included-in-c99
03:12:34 <mrvn> https://gcc.gnu.org/onlinedocs/gcc-4.9.0/gcc/Fixed-Point.html#Fixed-Point
03:14:01 <mrvn> I thought C had included it but seems to still be a draft.
03:15:02 <olsner> what does that actually do that you don't get from sticking fixed-point numbers in uintN_t?
03:15:27 <mrvn> olsner: shift when you do a * b
03:15:55 <mrvn> or a = 5.3;
03:32:15 <mrvn> olsner: and one more thing: Fixed-point types are supported by the DWARF 2 debug information format.
04:31:00 <zhiayang> quick qn #2: is it possible for there to be lapics without an ioapic
04:45:09 <w1d3m0d3> for fixed point maths don't you just need a defined point position and two integers? since 1234/5678 == 12.34/56.78
04:52:06 <klys> 2.998e+8
05:06:27 <bcos_> zhiayang: Yes, it's possible to have LAPIC without IOAPIC (and it was common for single-CPU machines in the "very late 1990s to very early 2000s" period)
05:12:42 <bcos_> w1d3m0d3: For division the shifts subtract like "(x >> m) / (y >> n) == x/y >> (m-n)" and for multiplication the shifts are additive like "(x >> m) * (y >> n) == x * y >> m+n)"
05:13:18 <bcos_> ..and if you're writing good code often the "implied position of the fixed point" moves after every operation
05:13:57 <w1d3m0d3> well yeah since shifts are multiplications/divisions with 2^x
05:15:43 <bcos_> e.g. like "my_20_12_result = my_16_16_number * my_4_28_number" to preserve as much precisions as possible without risk of overflow
05:16:00 <bcos_> ..and without any shifts
05:16:25 <bcos_> (assuming 32-bit maths)
05:17:12 <w1d3m0d3> ah I get what you're talking about
05:17:17 <bcos_> also like "my_17_15_result = my_16_16_numberA + my_16_16_numberB"
05:17:46 <bcos_> It's like, "roaming fixed point"
05:19:56 <bcos_> Of course in C and type conversions this "roaming fixed point" would be a massive disaster, and sometimes you'd want to change the underlying size (e.g. "my32_32 = my16_16 * my16_16"); so the best choice is to throw C in the trash and use assembly
05:19:58 <bcos_> ;-)
05:20:51 <kingoffrance> that stack overflow is interesting, i am out of my league as usual, the one dsp i purchased, there was a c compiler (24 bit char, 48/96 for other stuff) but the attitude is it was only for "prototyping your audio algorithm"...then rewrite in asm when it works satisfactorily
05:21:29 <kingoffrance> i didnt know there was "serious" people using c on dsps
05:23:03 <kingoffrance> thats also vaguely another reason i think "Wide chars" are ridiculous
05:23:35 <aalm> öäå
05:24:27 <bcos_> Wide chars are ridiculous because they're undefined (no way to guess if the platform uses UTC, UTF-16, UTF-32 or anything else)
05:25:25 <Griwes> that's why C++ is now going to have separate types for all three
05:25:37 <Griwes> but at the same time, the C committee says "this can be solved with locales"
05:25:49 <Griwes> (this is an almost exact quote from their minutes :|)
05:26:36 <bcos_> For C, I'd just roll my own (using uint8_t for UTF-8 and uint32_t for UTF-32 and not having anything else)
05:26:45 <bcos_> ..for C++, I'd vomit and use C
05:27:07 <bcos_> ;-)
05:27:18 <Griwes> ah yes, rejecting the language that actually actively try to solve the issue for a language that claims it can be solved with locales :>
05:27:23 <Griwes> typical bcos approach
05:28:07 <bcos_> There's too many perfectly good reasons to reject C++ before you even consider character encodings
05:28:19 <aalm> bcos++;
05:29:07 <Griwes> but since most of them that make any sense whatsoever are also problems with C, and because I've heard this nonsensical rant too many times already, I'm going to tune out now
05:30:30 <w1d3m0d3> to quote obama people who still argue this are on the wrong side of history
05:32:35 <bcos_> Almost every language created in the last 20 years is an attempt to fix C++ (Objective C, C#, Java, Rust, Go, ...)
05:32:43 <bcos_> Is that the history?
05:33:18 <bcos_> Hrm - I should say "compiled language" (excluding Javascript, Python, ...)
05:33:50 <w1d3m0d3> so is c++11 and onwards and I think it did an acceptable job of that
05:34:11 <w1d3m0d3> unless there's something I don't know, which is possible, there's no reason I should not use it
05:34:50 <zhiayang> if there was a c with namespaces and constexpr i'd use it
05:35:21 <bcos_> Namespaces are fine/nice. Constexpr probably shouldn't exist (compiler should be smart enough to figure it out itself)
05:36:22 <bcos_> Templates, function overloading and exceptions need to be banned, and it's impossible for any *addition* to C++ specs to remove/deprecate things like that, so C++11 can't do an acceptable job of fixing C++
05:36:39 <zhiayang> hm, the lapic timer goes straight to the idt right
05:36:54 <zhiayang> so why does not initialising the ioapic lead to no timer interrupts
05:37:34 <bluezinc> what the heck is wrong with character encodings in C++?
05:37:41 <zhiayang> bcos_: what is your solution to polymorphism without templates?
05:38:04 <bcos_> zhiayang: IO APIC initialisation shouldn't interfere with LAPIC timer (suspect bugs)
05:38:19 <bcos_> zhiayang: Nested structures
05:38:21 <zhiayang> i'm not initialising it at all
05:38:28 <zhiayang> so i'm not sure where the bugs come up
05:39:44 <bcos_> The main problem with templates is that programmers say "Oh, I can use the existing template for this type" (resulting in bloated code with the same basic stuff duplicated for many types) instead of saying "Oh, I can use a common type to avoid duplicating code"
05:41:50 <bluezinc> std::vector is a good use of templates, but there's a lot of other not-so-good ones.
05:42:51 <jjuran> std::vector<int> and std::vector<unsigned> will in all likelihood generate duplicate code.
05:43:25 <jjuran> Same with std::vector<long> and either std::vector<int> or std::vector<long long>, depending.
05:44:20 <jjuran> Or void* and any other kind of pointer to data.
05:45:21 <jjuran> To prevent that bloat, you have to actively fight the language.
05:45:29 <bcos_> Yes
06:00:01 <zhiayang> oops, forgot to eoi to the local apic, hence no interrupts
07:06:40 <kingoffrance> "Note that multiplication on the DSP56000/DSP56001 treats data as fractions; however, the C programming environment does not support a fractional data type." https://en.wikipedia.org/wiki/Motorola_56000 (quote from PDF footnote 5) that c draft fixed point stuff they didnt use there, it pretty much was "drop to assembly" although C did do non-standard floats
07:08:34 <kingoffrance> there was old gcc too e.g. 1.37 , but i dont know what it did https://www.rockbox.org/wiki/MotorolaDSP56k
07:43:20 * geist yawns
07:54:07 <klys> <y4wn>
09:09:08 <glauxosdever> https://forum.osdev.org/viewtopic.php?f=11&t=33473 <- I wonder, do we really need this thread there?
09:09:45 <glauxosdever> It's been reported (not by me) but it seems that no moderator handled it
09:14:12 <bcos_> Check if any mods have logged in...
09:14:42 <glauxosdever> Two in this month
09:15:28 <glauxosdever> I.e. the last 3 days
09:16:17 <bcos_> Hrm - from memory, I thought trident was better than that
09:16:51 <glauxosdever> Mostly asking irrelevant questions usually
09:17:51 <glauxosdever> Still, not as bad as this one
09:22:36 <glauxosdever> Furthermore, what they are saying is not even religiously correct
09:23:18 * bcos_ wonders who is "member # 666"
09:23:20 <glauxosdever> (The last two sentences contradict themselves, I don't want to repeat them here)
09:23:54 <glauxosdever> "The requested user does not exist"
09:24:15 <bcos_> Ah, pity ;-)
09:25:12 <bcos_> As for which programming languages and OSs will be used after Jesus returns; you'd first have to figure out when he returns (and if he already did, and if he never will)
09:25:15 <Ameisen> I'm trying to figure out how one would implement a null-conditional dereference operator in a low-level, static language like C or C++
09:25:35 <Ameisen> foo->?bar - what would it return if foo is null?
09:25:47 <Ameisen> my thinking has been that it would require something like foo->?bar : something_Else
09:25:56 <bcos_> Ameisen: ..like, "if(x == null) throw else *x"?
09:26:22 <Ameisen> more like eliminating if chains like if (foo && foo->bar && foo->bar->foobar)
09:26:22 <glauxosdever> bcos_: The religiously correct answer is that we will not need programming languages and computers anymore
09:26:34 <Ameisen> that would become if (foo->?bar->?foobar : false) { ... }
09:26:39 <ybyourmom> There will be no more war, no more sadness
09:26:43 <Ameisen> or so
09:26:43 <bcos_> (what do you do in the NULL case? Throw, pretend the dereferenced value was zero, ...?)
09:26:54 <ybyourmom> The lion will lie down with the lamb, and we will melt our swords into ploughs
09:26:58 <Ameisen> different langauges handle it differently
09:27:03 <Ameisen> it's more difficult in C++ as it has true primitives.
09:27:17 <Ameisen> C# uses something like int? (either int or not there)
09:27:34 <Ameisen> though I think specifying an "otherwise" value works?
09:28:43 <aalm> 1
09:28:48 <bcos_> My theory is; if you want to dereference but it's NULL then you've got an error with the program's logic and should be informed of that error so you can fix it, so the best alternative is probably SIGSEGV
09:29:01 <glauxosdever> Just crash. Problem solved. Next time use simpler languages
09:30:05 <glauxosdever> I've never really understood exceptions and how are they really usable, apart from minimising cleanup code in some cases
09:32:22 <glauxosdever> Otherwise, they add more complexity than needed. Also, what happens if you got an OOM exception? Do you get another OOM exception when allocating a exception object for the first OOM exception?
09:32:24 <Ameisen> bcos_ - as said, this is intended to be a replacement for if chains like foo && foo->bar && foo->bar->foobar
09:32:53 <Ameisen> not for 'not null or fail' cases
09:33:29 <bcos_> So deferencing a NULL gives you a NULL?
09:33:44 <bcos_> (for pointer types)
09:34:01 <Ameisen> My thinking is presently foo->?bar->?foobar : other_value
09:34:08 <Ameisen> either it returns foobar, or it returns other_value
09:34:54 <Ameisen> with the default 'other_value' being the default initializer value (nullptr for pointers)
09:35:12 <Ameisen> which works for situations where you are checking for the existence of a member of a member of a member.
09:35:36 <Ameisen> Many languages support this, it's just trying to work it into a low-level, static syntax
09:35:59 <Ameisen> alternatively, support an optional syntax like C# does
09:36:02 <kingoffrance> lots of ppl dont like it "only single return point" but i basically never have those chain, because i likely if (!x) { goto fail; } much earlier
09:36:05 <Ameisen> T *?ptr
09:36:21 <Ameisen> kingoffrance - in C++, I'd mark that in a code review very quickly.
09:37:05 <Ameisen> I suspect if C++ had finally clauses, and else clauses for loops, it'd eliminate basically all uses of goto.
09:37:06 <bcos_> "checking for the existence of a member of a member of a member" sounds like someone forgot to encapsulate
09:37:35 <Ameisen> the usual case would just be: if (foo && foo->bar) ...
09:37:41 <Ameisen> which would become if (foo->?bar)
09:39:19 <kingoffrance> well, in c, i probably have if (! (foo && foo -> x && ...) ) { goto fail; } so i am perhaps worst of both worlds ameisen
09:39:44 <kingoffrance> multiple chains of multiple return points
09:40:24 <Ameisen> o_O
09:40:26 <Ameisen> *ack*
09:42:31 <glauxosdever> On another note, has anyone written a x86 emulator or virtualiser for their custom non-UNIX-like OS? Because it would be fun to run your OS under your own OS. Of course, that's an excessive amount of work
09:43:29 <bcos_> I think there's been a few people trying to write hypervisors (using Intel/AMD virtualisation extensions)
09:44:13 <bcos_> Not sure how far they got (seems sort of easy until you start having to emulate devices)
09:45:24 <glauxosdever> And also you have to implement BIOS and UEFI
09:45:40 <glauxosdever> (Or is that provided, not sure?)
09:46:28 <Ameisen> Just write an entire emulator that also supports anything that an OS would need.
09:46:32 <Ameisen> We could call it a kernel.
09:46:40 <bcos_> Maybe. I'd cheat (build boot loader directly into hypervisor so guest starts with the first "firmware independent" piece)
09:46:45 <Ameisen> or a colonel.
09:47:03 <Ameisen> glauxosdever - meh, just support uefi
09:47:09 <bcos_> ..although I did write most of a BIOS for Bochs once..
09:47:16 <Ameisen> I don't recall the last time I ran into something that only supported BIOS
09:47:29 <glauxosdever> bcos_: Link?
09:47:34 <Ameisen> a lot easier to get things initialized in a UEFI environment, as well
09:47:43 <glauxosdever> I'm genuinely interested
09:47:46 <bcos_> No link - dead
09:47:49 <Ameisen> also interestingly, Visual C++ natively supports UEFI (makes sense since it is PE)
09:48:02 <glauxosdever> :-(
09:48:08 <glauxosdever> Not even an archive?
09:48:09 <Ameisen> You don't have to support either BIOS or UEFI. You can implement your own standard.
09:48:10 <Ameisen> :D
09:48:20 <Ameisen> BC-OS
09:49:00 <renopt> "why?"
09:49:03 <renopt> "just bc"
09:49:08 <glauxosdever> :D
09:49:39 <glauxosdever> bcos_: Anyway, was it relatively easy?
09:51:52 <glauxosdever> Because I'd like to experiment with that stuff too
09:53:42 <bcos_> From memory, I think it only took about ~month to get the basic stuff done (without ACPI, SMM, PXE, ..)
09:54:11 <bcos_> - found a "bios2.tar" in my archives but for some reason it's 330+ MiB
09:55:14 <bcos_> Ah - it's because there's 4 whole Bochs source code directories in the archive(!)
09:57:51 <glauxosdever> What Bochs version (year)?
09:58:11 <glauxosdever> I.e. would it run under current Bochs?
10:01:13 <bcos_> Bochs 2.3 mostly (one of them is "Bochs-20060518" so maybe 2006)
10:01:59 <bcos_> Not sure if it'd work on modern Bochs. E.g. I mostly reverse engineered CMOS values to make it work and some might have changed
10:03:29 <glauxosdever> Oh, ok. Apart from those CMOS values, did you consult any resources you would recommend to me?
10:03:31 <Ameisen> I wonder if people in the 70's would find it odd that we are still using tape archives.
10:03:44 <Ameisen> ... when we are mainly using spinny disks and solid state drives
10:05:23 <knebulae> @Ameisen: tape has a lot of qualities for long-term archival that no other storage medium can match.
10:07:48 <bcos_> glauxosdever: Just normal hardware info (same stuff you'd use for writing an OS - PIC datasheet, PS/2 controller datasheet, ...)
10:09:27 <glauxosdever> Except the BIOS (or UEFI) also needs to do other stuff, like detect memory
10:10:23 <bcos_> Bochs is really easy for that - just pluck some numbers from CMOS (and don't do any "memory sizing" or memory controller config)
10:11:11 <bcos_> glauxosdever: Does your IRC client have direct file transport support? Stripped my BIOS source code thing down to ~450 KiB and..
10:13:23 <glauxosdever> It does, but I never attempted that so I can't guarantee the transer will succeed
10:14:46 <glauxosdever> Well, could you please retry?
10:15:16 <bcos_> Retrying
10:18:15 <bcos_> glauxosdever: Doesn't seem to be starting - if you're interested, try http://bcos.hopto.org/bios.tar.gz
10:19:47 <glauxosdever> Ok, that worked :-)
10:19:57 <glauxosdever> I'll have a look (or two)
10:21:03 <bcos_> :-)
10:27:23 <kingoffrance> Ameisen: https://defuse.ca/b/WAL5ip6WheAp4jPlbYndwf thats simple to me, but you might ack. legend: "tracepath" 2d point enumerator, e.g. i could combine with terminal output to make it follow a shape "FR" -- pseudo-class/object mechanism, function redirector (struct of function pointers + opaque state) big_uint == unsigned big integer
10:27:47 <kingoffrance> one could "chain" that whole body, but no reason
10:28:01 <kingoffrance> gimme an "ack" rating
10:33:36 <Ameisen> https://i.imgur.com/Lm5CdE2.jpg
11:08:13 <jmp9> I get extremely bored. I don't want to do anything, I completely don't know what to code next and don't have any wish to do anything. What wrong with me, guys? I remember I was very enthusiastic
11:08:36 <bcos_> jmp9: Just guessing, but it sounds like you might be human..
11:10:06 <jmp9> A human. And you aren't?
11:10:30 <bcos_> Technically, no anymore
11:11:05 <jmp9> How?
11:11:57 <klys> do you really care what someone else thinks. are you there to please anyone else or do you want success. now that you've done this much, how do you want to spend your time. shat was your goal and what are the prospects.
11:12:25 <klys> s/sha/wha/
11:15:42 <jmp9> I'm worrying that I spent my time uselessly
11:16:53 <jmp9> You know, i'm already nolifer
11:18:15 <klys> if you need a new goal, archive / back up your project and move on to something worthwhile. even if it just means compiling a new kernel, there are avenues available to you.
11:19:00 <klys> super bowl starts in 15 minutes
11:19:08 <klys> 10
11:19:54 <xiphias> i forgot that even existed
11:53:55 <jmp9> Okay
11:54:01 <jmp9> My friend want rape his classmate
11:59:17 <xiphias> what
11:59:28 <xiphias> if any part of that sentence is true, i don't know wtf you're telling us for
11:59:39 <xiphias> cops exist