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=18&m=9&d=18
12:02:49 <rain1> what mode does grub put you into? I need to get into 64 bit mode but i'm not sure where it'd be starting from
12:04:14 <heat> rain1: 32.
12:04:30 <rain1> https://forum.osdev.org/viewtopic.php?t=11093 should I use this?
12:04:32 <bslsk05> forum.osdev.org: OSDev.org • View topic - Switching from real mode to long mode directly..
12:04:37 <gog> no
12:04:48 <gog> grub puts you in flat 32-bit protected mode without paging
12:05:41 <gog> fortunately it's easier to get into long mode from protected mode
12:05:52 <rain1> oh that's great
12:05:54 <rain1> https://wiki.osdev.org/Setting_Up_Long_Mode#The_Switch_from_Protected_Mode I can try using this
12:05:55 <heat> rain1: that's what I do: https://github.com/heatd/Onyx/blob/master/kernel/arch/x86_64/boot.S
12:05:56 <bslsk05> wiki.osdev.org: Setting Up Long Mode - OSDev Wiki
12:05:58 <bslsk05> github.com: Onyx/boot.S at master · heatd/Onyx · GitHub
12:06:00 <heat> note that it's awful code
12:06:07 <heat> that's why I argue against using multiboot
12:06:40 <rain1> I just don't want to write a bootloader
12:06:44 <rain1> at least to start with
12:06:57 <heat> rain1: You're writing for the microkernel right?
12:07:18 <rain1> yeah, but doing a non microkernel first
12:07:48 <heat> rain1: If we use carbon you'll already have a UEFI bootloader
12:08:05 <heat> that just Works™
12:08:18 <heat> and paging that Just™ Works™
12:36:53 <rain1> im looking at all 4 intel manuals but i acn't find the part that explains going from 32 bit protected mode to long mode 64 bit subsystem
12:37:18 <rain1> maybe the kernel itself should be 32 bit, but userspace programs 64 bit?
12:37:27 <Mutabah> no...
12:37:34 <Mutabah> Look for "IA-32e mode"
12:51:05 <rain1> https://os.phil-opp.com/entering-longmode/ its so complicated
12:51:05 <bslsk05> os.phil-opp.com: Entering Long Mode | Writing an OS in Rust (First Edition)
12:52:35 <Mutabah> welcome to x86 :)
12:52:45 <zid> paging is forced, which is what makes it non-trivial
12:52:51 <zid> otherwise it's just twiddling a couple of status bits
12:53:13 <Mutabah> https://os.phil-opp.com/entering-longmode/#enable-paging - This is the most important part
12:53:13 <bslsk05> os.phil-opp.com: Entering Long Mode | Writing an OS in Rust (First Edition)
12:56:46 <johnjay> rain1: holy crap OS:D&I is hella expensive... regular price $200!
12:57:07 <klange> it's a textbook used in colleges, so, RIP
12:57:13 <rain1> aw i hate when books are expensive
12:58:29 <geist> also consider looking at the AMD manual. it's sometimes cleaner and easier to read
12:59:32 <rain1> yeah I found a good diagram in the AMD manual
12:59:39 <rain1> https://github.com/phil-opp/blog_os/blob/post_2/src/arch/x86_64/boot.asm this is the source for the blog post
12:59:41 <bslsk05> github.com: blog_os/boot.asm at post_2 · phil-opp/blog_os · GitHub
01:00:45 <geist> yah, since AMD invented the 64bit extensions they seem to go a bit out of their way to describe the transition to it
01:01:22 <johnjay> that makes sense
01:01:32 <johnjay> in the computing world ppl only document things they create pretty much
01:03:44 <heat> I'm supposed to believe one guy created the intel hd graphics architecture?
01:04:20 <zid> I'd be unsurprised if one guy they poached from sgi or 3dfx or somewhere designed it
01:05:00 <heat> yeah no
01:05:19 <heat> the architecture grew a lot from the original G45 to kaby lake
01:05:20 <bcos_> One guy designs the overall architecture, 10 people figure out the details, 100 people implement it?
01:05:49 <rain1> it builds but it doesn't boot
01:05:53 <zid> more like yea, but they have super good simulators, decades of vhdl designs to steal etc
01:06:01 <zid> so maybe even like 5 people total
01:06:16 <rain1> the phil-op post2 code does not work in qemu
01:06:33 <heat> the G45 had 3 "fairly" small volumes, kaby lake has 16
01:07:14 <heat> I also just realized that I might not need to reprogram the port clock timings because the vbios did it for me
01:07:24 <heat> Wonderful.
01:11:50 <bcos_> heat: If you're writing a native video card driver; always assume that it's the secondary video card and not the primary (and that vbios did absolutely nothing)
01:12:41 <heat> bcos_: I was going to say that the IGD cannot run as a secondary video card but it technically can
01:12:50 <heat> :/
01:13:06 <zid> I don't have intel GMA sadly so I can't try write a driver for it
01:13:16 <heat> you don't?
01:13:26 <heat> oh right, amd
01:13:27 <zid> nope
01:13:32 <zid> I just don't have it
01:13:47 <heat> you have an intel cpu that doesn't have one?
01:13:49 <zid> yes
01:13:50 <heat> that's rare
01:14:07 <zid> neither i7-3820 or e5-1620 have it
01:14:26 <heat> yeah, that's old
01:14:39 <heat> I believe every consumer intel CPU has one these days
01:14:52 <zid> w-2125 doesn't either
01:14:55 <zid> which is the skylake equivalent
01:14:57 <bcos_> Most Xeons don't, and about half the desktop CPUs don't.
01:15:07 <heat> they don't?
01:15:23 <heat> I thought intel started pushing them like crazy to i7s
01:15:29 <zid> It's a sliding scale inversely proportional to the cost of the cpu
01:15:53 <rain1> i have some kind of mental block with paging
01:16:02 <zid> It's getting more common
01:16:08 <zid> rain1: It's *super* catch-22 and hard to reason about
01:16:15 <zid> but it's basically just a tree
01:16:23 <Mutabah> rain1: What bit are
01:16:26 <Mutabah> rain1: What bit aren't you getting?
01:16:40 <heat> zid: that's odd, I don't see why expensive CPUs wouldn't have one
01:16:43 <zid> pml4 contains 512 leaves which are the addresses of pdpts, each one of those contains 512 leaves which are the addreses of pds, which are pts, which are pages
01:17:03 <zid> heat: die space / enthusiasts are using gpus / servers have builtin video for kvm
01:17:26 <heat> mh, probably die space
01:17:38 <bcos_> Probably also some "binning" going on
01:17:57 <bcos_> ...oh, the GPU is borked on this die, guess that's a model xyz instead of a model wxy
01:18:07 <zid> You can see the strata of chips that do and don't if you make a nice excel spreadsheet, you DO have one right? :p
01:18:09 <heat> I remember reading about CPUs which just had a fused-off igd
01:18:24 <zid> 3820 is a fused 1620 xeon
01:18:31 <klange> can i pass through the onboard intel GPU to a KVM guest [assuming, obviously, that I have a second GPU being used by the host]...
01:18:34 <zid> but 1/10th the price second hand on ebay when I got it :p
01:18:44 <heat> klange: yes
01:18:50 <zid> klange: as long as the bios doesn't suck yea
01:18:51 <heat> you can even pass it through when using it
01:18:55 <zid> iommu groups and stuff need to be set up
01:19:04 <zid> heat: that sounds more like paravirt
01:19:13 <heat> i915 supports GVT which is a fancy word for "virtual gpus"
01:19:31 <zid> I should dig out my i810 board and write a driver for that :P
01:19:32 <heat> its emulation is a bit more limited though
01:19:35 <zid> all 2MB of shared video memory
01:20:57 <heat> I was using GVT before, but I stopped because I had an older laptop around and GVT wouldn't give me an EDID through I2C
01:21:02 <heat> the laptop doesn't too
01:21:22 <zid> do modern GMA things have a ramdac?
01:21:27 <zid> or is it all DP/HDMI only
01:21:33 <heat> because there's no I2C port for eDP
01:21:53 <heat> zid: no
01:21:59 <zid> figures
01:22:06 <heat> it's eDP, DP and HDMI only these days
01:22:11 <zid> hdfurys are expensive :(
01:22:43 <zid> https://www.hdfury.com/product/hdf1-nano-gx/ $99 part to get back what $20 gpus have had forever heh
01:22:44 <bslsk05> www.hdfury.com: HDF1 Nano GX | HDFury.com | Connect and Fix everything in HDMI
02:22:19 <cpplearner> Guys, this kernel assignment that I'm currently working on assigns 0x21 to a keyboard interrupt. But, when I searched both 0x21 or 21h in the Intel Manual, it gives nothing meaningful that's related to a keyboard. Then, what mandates the hardware (in this case, a keyboard) is supposed to send a irq to this specific interrupt vector?
02:23:39 <Mutabah> legacy :)
02:24:11 <cpplearner> Oops... Then, it's the BIOS's job??
02:24:11 <Mutabah> The PS2 controller was (and pretends to be with modern machines) connected to line 1 of the PIC
02:24:18 <bcos_> CPU manual only covers the CPU, not stuff outside the CPU (chipset, PS/2 controller, PIC, ...)
02:24:44 <Mutabah> The PIC is configurable in which CPU interrupt vector it'll trigger when one of its interrupt lines are triggered
02:24:58 <Mutabah> (In the example you're using it's been configured with a base of 0x20)
02:27:30 <zid> https://en.wikibooks.org/wiki/X86_Assembly/Programmable_Interrupt_Controller
02:27:31 <bslsk05> en.wikibooks.org: X86 Assembly/Programmable Interrupt Controller - Wikibooks, open books for an open world
02:27:42 <zid> list here of what each IRQ is legacuacly defined as
02:28:04 <zid> which irq triggers which interrupt vector is up to the PIC
02:28:52 <cpplearner> Oh, thank you. I'll check it out right right now. Especially, I didn't know about the "PIC". =D
02:34:47 <zid> if you don't move them up you'll have serious issues distinguishing them from exceptional handlers
02:34:51 <zid> (divide by zero, etc)
05:26:29 <johnjay> hrm
05:26:43 <johnjay> thinking about os development... is that mainly minix unix and L4?
05:26:50 <johnjay> idk what other ones that are open source/foss
05:27:20 <Mutabah> What do you mean?
05:27:38 <klange> "Unix" is not open-source, though sources for ancient historic versions are available, and BSD has an interesting history.
05:27:58 <johnjay> Mutabah: i mean, the wiki had a barebones example with gcc and c
05:28:19 <klange> There are lots of open-source OSes you can look into.
05:28:24 <johnjay> like what
05:28:49 <bcos_> ReactOS, Hiaku
05:28:51 <johnjay> i meant bsd + linux there when i said unix lol
05:28:52 <klange> Sortix is solid interpretation of POSIX. https://gitlab.com/sortix/sortix
05:28:54 <bslsk05> gitlab.com: sortix / Sortix · GitLab
05:29:25 <klys> :) FreeDOS
05:29:28 <Mutabah> There's klange's ToaruOS - https://github.com/klange/toaruos
05:29:28 <bslsk05> klange/toaruos - Hobby kernel + userspace, built mostly from scratch. Composited GUI, dynamically linked ELF binaries, networking, Python applications, and more. (273 forks/2331 watchers)
05:29:59 <klange> Haiku is a very complete (even binary-compatible) open-source recreation of BeOS. https://git.haiku-os.org/haiku/
05:30:23 <klys> wasn't there something called simpleos ?
05:30:59 <klange> Fuchsia is a Google project, one of its main developers is a regular here. https://github.com/fuchsia-mirror
05:31:00 <bslsk05> github.com: Fuchsia · GitHub
05:31:20 <klys> seems it was something that could read the ACPI tables and that's about it
05:31:20 <johnjay> interestin the thing about posix
05:31:59 <johnjay> everyone always brings up TempleOS
05:32:06 <johnjay> but idk if anybody actually studies that for useful ideas
05:32:22 <klange> Terry passed away recently, hit by a train, possible suicide.
05:32:40 <johnjay> yeah, sad
05:33:07 <bcos_> Well, no, not if you're religious
05:33:34 <klys> yeah sad if you're religious. to kill oneself is to shed innocent blood.
05:33:42 <bcos_> (then it's more like "Yay, I'm going to see God!"
05:33:43 <bcos_> )
05:33:45 <klange> Mutabah has already linked my previous (discontinued) project, which had a lot of ports...
05:33:57 <klange> bcos_: Many religions consider suicide a ticket straight to hell.
05:33:58 <Mutabah> klange: Oh, -nih is a separate repo?
05:34:10 <bcos_> "possible suicide" != suicide
05:34:11 <klange> nih is a separate repo: https://github.com/klange/toaru-nih
05:34:12 <bslsk05> klange/toaru-nih - A completely-from-scratch hobby operating system: bootloader, kernel, drivers, C library, and userspace including a composited graphical UI, dynamic linker, syntax-highlighting text editor, network stack, etc. (7 forks/58 watchers)
05:34:36 <klange> I maaaay move the nih branch into klange/toaruos on github just for the namespacing at some point
05:34:42 <johnjay> "Fuchsia's user interface and apps are written with Flutter, a software development kit allowing cross-platform development abilities for Fuchsia, Android and iOS. Flutter produces apps based on Dart, offering apps with high performance that run at 120 frames per second. Flutter also offers a Vulkan-based graphics rendering engine called "Escher""
05:35:42 * bcos_ wants to find the person responsible for making up these names, and punch them
05:35:46 <johnjay> klange so toaruos is your hobby OS?
05:35:57 * johnjay nods in agreement
05:36:50 <klys> it seems no one had mentioned DGOS yet
05:37:11 <zid> okay so the i217 manual says there's a reg at 0x2800 and 0x2804 for hi/low and are 32bit, but the 8254x manual says it's a 64bit reg at 0x2800.. I can probably just do a 64bit write for either.. right?
05:37:18 <klys> there's a participatory list of projects on the wiki.
05:38:17 <bcos_> zid: Probably not - a lot of the 32-bit stuff ignores 64-bit writes
05:38:25 <zid> hrmph, no idea which chip I have
05:38:34 <zid> I guess I could check though
05:38:39 <zid> no idea how to check irl but hey
05:39:15 <bcos_> Probably an Realtech NIC that works completely different then... ;-)
05:40:09 <bcos_> zid: Normally your PCI enumeration code would tell you what everything is (and start the right driver/s)
05:40:21 <johnjay> who is "I"?
05:40:23 <johnjay> https://wiki.osdev.org/Intel_Ethernet_i217
05:40:25 <bslsk05> wiki.osdev.org: Intel Ethernet i217 - OSDev Wiki
05:40:31 <zid> that page does 32bit writes
05:40:58 <zid> and its manual agrees, but the 'superset' doc for all those family of chips are 64bit writes.. so I guess this old ass one needs special casing
05:41:04 <bcos_> johnjay: https://wiki.osdev.org/index.php?title=Intel_Ethernet_i217&action=history
05:41:05 <bslsk05> wiki.osdev.org: Revision history of "Intel Ethernet i217" - OSDev Wiki
05:41:07 <Mutabah> johnjay: The author of that setance most likely
05:41:37 <johnjay> right. it's probably violating some wikipedia type policy to just write it as "I did this", "I did that" in a wiki
05:41:54 <zid> Are you talking about writing in first person?
05:42:03 <klys> yeah
05:42:07 * johnjay is interested in writing an e1000 driver though
05:42:20 <klange> We don't have much of a style policy on that wiki.
05:42:33 <johnjay> zid: in math/science papers it's always "we" or "us"
05:42:37 <klange> Though, yeah, the blog post esque descriptions some people write can get annoying.
05:42:40 <johnjay> i.e. "We derived this, we computed that"
05:42:44 <zid> johnjay: I am a native english speaker
05:42:58 <klange> The Royal We
05:43:01 <johnjay> it's clunky and artificial, but it's less confusing than blog style
05:43:19 <zid> I don't need a lesson on how english works, I asked if your comment was about someone using first person
05:43:35 <klange> Though in the case of papers it's because lots of papers are written by teams of multiple people and using "we" even when you're a team of one contributes to a style that sounds like you're talking about a team of researchers.
05:44:10 <johnjay> i don't see what scientific conventions have to do with "how english works"
05:44:17 <johnjay> klange: good point
05:44:24 <klange> Based on the history of that page, "I" appears to be Kemosparc, who wrote the bulk of the article as a 'User talk:'
05:44:41 <zid> This is clearly a writeup, not an article.
05:45:32 <johnjay> Usually when I see that style I assume I'm reading a blog, so I immediately scroll down to see who the blog author is
05:46:11 <klys> well, such are issues in communications; this community is more of an engineering specialty.
05:46:40 <zid> If you write this in third person you lose a lot of nuance about what state the information is being presented as
05:46:43 <zid> which is very important here
05:47:04 <zid> first person = this is what I did and what happened, third = this is the ritual for performing this action
05:47:35 <zid> It's clearly just a writeup of his first draft mess
05:47:40 <zid> first person is warrented
05:48:01 <johnjay> i didn't think of that zid but third person does sound somewhat more 'authoritative' in a sense
05:48:10 <klange> no, that's more of a passive voice type of thing
05:48:19 <klange> third person would be replacing "I" with "the author"
05:48:48 <bcos_> 1st person = I did this. 2nd person = I saw that guy do this. 3rd person = That guy said he saw another person do this.
05:48:52 <bcos_> ;-)
05:49:34 <johnjay> but 2nd person si more like giving instructions. like, "You write this function, then you compile the function, then you get a result"
05:51:02 <zid> oh hey to make this code even more fun
05:51:14 <zid> he writes to the TX base address as two 32bit writes
05:51:26 <zid> and the RX descriptor as a 64bit write
05:51:34 <zid> but it's actually a 32bit write
05:51:49 <klange> obviously demonstrating that you can do both :)
05:52:17 <zid> except it doesn't
05:52:21 <zid> because the 64 gets truncated down to 32
05:52:28 <zid> and it appears to be entirely in the wrong spot in the code
05:52:28 <klange> lol
05:52:40 <zid> so it probably just does nothing, but doesn't matter
05:53:05 <klys> so, if you have two 32-bit regs, can you write them both at the same time? It seems someone was saying you can't.
05:53:16 <zid> That's what I just got told
05:53:41 <zid> The bus isn't going to split it for you, I'd imagine
05:53:49 <zid> if the device is 32bit on its end but the bus is 64
05:54:11 <klys> and this is a pci-x device?
05:54:34 <zid> pci-x devices exist int he wild?
05:54:53 <klys> hmm I thought it was just the bus
05:55:05 <bcos_> pci-e?
05:55:11 <klys> yeah same
05:55:16 <zid> not really :P
05:55:19 <klange> they are not the same thing
05:55:41 <zid> pci-x is white pci slots with wider busses, pci-e is the new slot that is annoying like agp by having speed ratings and shit ;)
05:56:11 <klys> oh I meant pci-e then
05:56:13 <zid> and now you have to match your cpu to your slots else your slots don't work, woot
05:56:30 <bcos_> ?
05:56:44 <zid> pci-e lanes, mid-range intel chips have fuck all
05:57:24 <zid> ryzen had the full complement though so now their new chips are back to having good numbers again
05:57:28 <bcos_> That's because they shifted the PCI host stuff into the same chip (and don't have the old "northbridge + southbridge"), not because of PCI-e
05:57:38 <zid> but for a while, like just before skylake they had sod all lanes
05:57:44 <zid> unless you bought the x or whatever
05:58:17 <zid> 6700k has 16 pci-e lanes, my sandy bridge has 40
05:59:08 <klys> first post
05:59:14 <zid> pirst fost
06:09:26 <zid> Another suspected bug in this code, think it sets up the tail reg wrong, nice
06:52:32 <zid> bwaaha perfect, my e1000 code is officially a 'right mess', I only do 2M or 4k frames so I just chopped a 2MB frame into little bits with lots of ugly math
06:53:18 <zid> I should probably just make it all statics but where's the fun in that
06:53:38 <zid> (then I'd just need the dynamic linker for the kernel module to map the entire thing with a 2M page and I could go home)
06:53:39 <bcos_> That can't work
06:54:23 <bcos_> (unless you load the same module N times when there's N network cards)
06:55:09 <zid> Ignore the wet ink, my design document has always obviously said that each device is only supported once
06:55:15 <zid> it says so right here next to this smudge, in the margin
07:00:48 <klange> i can download my website's home page, so I consider my e1000 driver "good enough"
07:01:08 <zid> I can't, I was too lazy to write the define constants, so it doesn't compile yet :P
07:01:36 <klange> that said I've never tested it with an actual e1000 card, so *shrug*
07:17:32 <izabera> anyone familiar with magic files?
07:17:48 <zid> If I told you I'd get kicked out of the magic circle
07:17:59 <izabera> right
07:18:06 <izabera> don't tell me
07:18:23 <izabera> just a small hint will suffice
07:18:31 <izabera> how do i print a pstring? %s grabs a null-terminated one
07:18:33 <zid> no idea what you're talking about
07:20:24 <ybden> izabera: magic(5)?
07:20:36 <klys> int i = 0; for(; s[ i ] != 'p' && i < l; ++i ) fputc( s[ i ] ); // rly idk, just thought you're barking up the wrong tree
07:20:50 <ybden> what
07:20:57 <klys> oh, and add stdout to fputc()
07:21:13 <ybden> assuming this is the magic(5) file format, which does indeed contain a data type named pstring, that has nothing to do with this
07:21:19 <Mutabah> izabera: pstring = pascal string?
07:21:28 <ybden> yes
07:21:41 <bcos_> Oh, so not a string of pee?
07:21:47 <Mutabah> You can use `%.*s` to print a fixed number of characters
07:21:49 <klange> Can you %.*s?
07:21:58 * klange slaps Mutabah around a bit with a large trout.
07:22:12 <klys> .theo
07:22:13 <glenda> This bug report totally sucks.
07:22:24 * Mutabah retaliates with a salmon
07:22:26 <klange> omg i can rotate windows with my mouse again
07:22:50 <klange> it's super slow compared to cairo's transformations
07:22:51 <klange> but it woooorks
07:23:07 <FireFly> ...interesting WM feature :p
07:23:32 <ybden> it's not a real WM until you add wobbly windows
07:23:55 <sham1> Or the cube
07:24:02 <klange> I never did wobblies because cairo's transforms - while fast - were limited to skews and rotates
07:24:16 <ybden> or windows you can rotate around the Z axis
07:24:23 <sham1> Well now you can do what Compiz could because NIH
07:24:41 <klange> if i port compiz it's still technically nih!
07:24:48 <sham1> !
07:24:51 <izabera> ybden: there's nothing in that page that helps me
07:25:22 <klange> compiz was my first real experience with contributing to open-source software
07:26:36 <klange> I need window-relative window operations, so I can make menus and stuff appear appropriately for transformed windows - currently have a lot of stuff that says "create a window at this point (that I calculcated from my own position)"
07:27:06 <izabera> i've also been grepping for pstring in https://github.com/file/file
07:27:06 <bslsk05> file/file - Read-only mirror of file CVS repository, updated every half hour. NOTE: do not make pull requests here, nor comment any commits, submit them usual way to bug tracker or to the mailing list. Maintainer(s) are not tracking this git mirror. (129 forks/368 watchers)
07:27:25 <izabera> they all seem to use %s with pstring
07:27:37 <izabera> which i don't understand
07:27:38 <klys> appears compiz-dev depends on libgtk-3-dev
07:27:46 <klange> It's complicated.
07:28:04 <klange> Compiz core includes the gtk window decorator
07:28:20 <Mutabah> Are you sure they're using pascal strings?
07:28:45 <bcos_> izabera: That can't work only they terminate it first (to convert to C style string)
07:28:52 <bcos_> *unless they
07:28:54 <Kazinsal> what insane human is using pascal strings in the 21st century
07:29:21 <sham1> For instance people who Rust
07:29:27 <Mutabah> sham1: Eeeh, not quite
07:29:27 <klange> extract the length and use %.*s unless that's not supported in `file`'s printf.
07:29:28 <sham1> Those strings know their lengths
07:29:35 <Mutabah> sham1: pascal strings are length-prefixed
07:29:39 <sham1> Oh
07:29:39 <Mutabah> sham1: rust ones are fat pointers
07:29:41 <izabera> Mutabah: my file format has 4 bytes that represent the length of a string in little endian, and after those bytes there's a string of that length, and it's not null terminated
07:29:44 <sham1> *oh*
07:29:49 * sham1 gets a sudden realisation
07:29:51 <sham1> Eww
07:29:53 <izabera> Mutabah: and i need to print it, then keep parsing the rest
07:30:01 <Kazinsal> I was gonna say, Rust ones are less pascal strings and more std::string without the horror
07:30:13 <Mutabah> sham1: eww?
07:30:36 <klys> well suppose strings were all < 256 chars
07:30:43 <sham1> Length-prefixed, while nice, is still weird
07:33:51 <zid> I'd probably do >127 means 4 byte
07:34:47 <Mutabah> or use leb128
07:34:52 <klange> just store the length as a utf-8 codepoint ;)
07:34:57 <Mutabah> (where >127 means there's extra bytes to follow)
07:35:02 <Mutabah> Or utf-8
07:35:28 <bcos_> Surely you'd have a size prefix to determine the size of the size?
07:35:32 <sham1> klange: that sounds horrible
07:36:07 <zid> bcos_: Mine technically does, and it's 1 bit
07:36:52 <bcos_> I want "1st byte is size of size, next N bytes (determined by size of size) is the size of the string, then the characters"
07:37:04 <bcos_> ..or maybe just have a zero terminated "size of the size"
07:37:10 <klys> http://45.55.20.239/vla.txt
07:37:12 <Mutabah> bcos_: You do you
07:37:15 <zid> bcos_: in ascii
07:37:29 <zid> "12","hello world!" or whatever
07:37:53 <bcos_> "12\0Hello World!"
07:38:11 <bcos_> ..you have to use zero terminators with your pascal strings.. ;-)
07:38:33 <zid> it is zero terminated
07:39:23 <klange> from looking at various sources, it would seem that file's print methods know what kind of object they are receiving and %s should just work™ with a pstring
07:39:54 <klange> eg. it's not just some blind call to printf with some arguments passed
07:40:52 <FireFly> klange: is it bad if I feel encoding the length of a pstring as an UTF-8 codepoint isn't a horrible idea?
07:43:30 <sham1> Yes
07:50:30 <klange> I need to add scale+rotate rendering to cover additional cases in my window blitting (resizing rotated windows) which was covered in cairo by a single transform matrix, but, it works https://i.imgur.com/S1aGcaN.png
07:51:05 <sham1> How slow is that compared to Cairo
07:51:09 <klange> hella slow
07:51:09 <sham1> And are you using SSE
07:51:13 <sham1> Or AVX
07:51:15 <klange> not for this
07:51:19 <klange> and hell no to avx
07:51:42 <sham1> I won't blame you
07:52:00 <sham1> But it'd make it faster
07:52:03 <klange> the base case of a non-rotated non-alpha-adjusted window is SSE
07:52:52 <klange> but any alpha modification and it falls back to the software alpha blitter; any rotate or scaling and it's using the software bilinear filter blitter
07:53:02 <bcos_> klange: Font are all blurred by "double anti-alias"
07:53:39 <klange> haha yes, extra fuzzy
07:54:24 <klange> if I could get that bilinear filter running faster than translated-from-wikipedia-pseudocode speeds
07:54:29 <klange> then that would be greaaaat
07:54:57 <klange> though the rotation also loses a lot of speed from its transform calculations
07:58:52 <geist> yay just got back from seeing Toe. they were pretty good
07:59:49 <klys> was it very funny
08:05:13 <klys> the band, then
08:31:30 <geist> yep
08:32:21 <zid> It's a shame that there isn't some handy opengl reference imp somewhere to use easily
08:32:27 <zid> I'd love to make a desktop that used shaders etc
08:32:40 <klange> "opengl" and "easy" don't really go together
08:32:42 <klange> ;)
08:32:55 <klange> you can get mesa's older swrast built on a potato
08:32:55 <sham1> zid: mesa?
08:33:09 <zid> sham1: I don't think that has a shader compiler and crap does it?
08:33:13 <klange> it does
08:33:28 <zid> intredasting
08:33:33 <zid> but I did try to build mesa once
08:33:37 <klange> yeah I have a slow as fuck teapot shader demo for toaruos
08:33:39 <zid> I got to having installed 7 build systems
08:33:42 <zid> then gave up
08:33:45 <zid> because I still needed more
08:34:10 * klange grabs an ISO of toaruos 1.2.3
08:34:45 <sham1> I think most of what mesa dependencies alongside mesa nowadays uses meson
08:34:50 <klys> toe seems all right if you can put up with nonstop four-note sequences
08:35:30 <klange> https://i.imgur.com/KNzYoru.png
08:36:09 <zid> sham1: I ahd to install ant and cmake at the very least
08:36:49 <zid> and llvm
08:37:36 <klange> yeah, I had to dig into the past to find a version that was easily built for potatoes
08:38:14 <klys> that's quite a reflection on that teapot there
08:38:35 <klys> very clean
08:38:38 <klange> It's an old nvidia office lobby, one of their sample reflection maps
08:39:16 <zid> https://cdn.discordapp.com/attachments/417023075348119556/451155845892276244/unknown.png I made this
08:39:32 <zid> It was like 20 hours of writing tooling and crap and 4 hours of learnine opengl :p
08:39:37 <klange> I could load the dragon model into this renderer
08:39:42 <klange> I think I have it somewhere
08:39:52 <zid> My pipeline is.. silly :D
08:40:09 <zid> It compiles the .blend to .c with a python script, then compiles that to .bin
08:40:14 <klange> this is an asci .obj + frag loader
08:40:21 <zid> I absolutely hate obj
08:40:27 <zid> and writing a loader for it disgusted me
08:40:29 <zid> I gave up
08:40:40 <klange> eh, so do I, but it was a requirement of the college graphics course i was in seven years ago, so *shrug*
08:40:53 <klange> in fact that was basically the assignment in question
08:40:56 <zid> It's literally more work to load obj than my entire project
08:40:58 <klange> "load an obj and render it"
08:41:17 <sham1> Meh. obj isn't that bad to parse
08:41:22 <zid> parsing it is the easy part
08:41:35 <zid> Deduplicating and indexing it into verticies and stuff? really awful
08:41:41 <zid> I had to make an 8 component vertex hash map
08:42:26 <klange> way more work than this old hunk of junk did https://github.com/klange/toaru-opengl/blob/master/teapot.c
08:42:28 <bslsk05> github.com: toaru-opengl/teapot.c at master · klange/toaru-opengl · GitHub
08:43:13 <zid> ah you used oldschool rendering that's why
08:43:20 <zid> opengl 1.1
08:43:41 <zid> except it's mixed with shaders? wtf
08:43:41 <klange> it was seven years ago and that's what the course taught :)
08:43:47 <klange> you can do both, you know
08:43:50 <zid> how
08:44:14 <zid> GL_LIGHT0 isn't going to do shit when I am the one supposedly implementing the lighting with a shader, the fixed function pipeline and programmable pipeline shouldn't interact
08:44:49 <zid> unless maybe if you only did verts in fixed and fragments in a shader, or vice-versa
08:45:59 <zid> Anyway loading obj is a huge ballache if you're doing indexed rendering, where you give a face number to opengl and a buffer of verticies
08:46:10 <zid> as you *never* repeat a vertex if you do that
08:47:15 <elderK> zid: I'm pretty sure that depending on what you're doing, you can use shaders without you know, throwing out everything from legacy GL's pipeline.
08:47:17 <zid> vector of vector of 3-indices or whatever
08:47:37 <elderK> Although I'm not completely aware of all the details.
08:47:40 <zid> elderK: I think if you split it down the vert/frag lines you can, I don't see how it could possibly work otherwise
08:47:51 <zid> s/can/might be able to
08:48:11 <elderK> I'm pretty sure that's how things worked. I mean, we had games that were using basic shaders before the pipeline was completely... programmable.
08:48:21 <zid> See my question about what LIGHT0 is supposed to if I have a fragment shader in use
08:48:33 <elderK> Yeah, I saw that.
08:48:41 <klange> that may well be doing fuck all in that code
08:48:57 <zid> You could probably mix them for doing different calls to glDraw...
08:49:05 <elderK> zid: Perhaps there are certain restrictions. Who knows :)
08:49:07 <zid> pipeline(); glDraw...(); programmable(); glDraw()
08:49:23 <zid> and have a fixed function cube behind a shaded teapot or whatever
08:49:24 <elderK> I'd figure something like that, yes.
08:49:53 <zid> I was about ready to need to add a shader cache to my opengl toy when I gave up :P
08:50:05 <bcos_> Surely the whole "fixed function" stuff is just emulated with GPU on modern cards, so you can replace any stage if you're bored
08:50:08 <elderK> Is your opengl toy open?
08:50:11 <zid> I would have had to re-compile the vertex shader for every model
08:50:31 <klange> anyyyyway the point was, hey, yeah, you can grab an old as fuck mesa and it does shader stuff and can do it all in software with no real dependencies
08:50:32 <elderK> That sounds painful :P
08:50:55 <elderK> Also, HAPPY TUESDAY ALL! :)
08:51:06 <zid> It's not on github because it wasn't in a fit state and needs test-data and stuff, but I have it on my drive I think
08:51:22 <elderK> I'd be interested in checking it out, depending on what exactly it does :P
08:51:22 <zid> https://drive.google.com/open?id=1TRL8M3KudqSeJBP7Nzp-c_Ht0fnwIQiw idk try that
08:51:25 <zid> it says dragon_spec.rar
08:51:32 <zid> which I assume is a specular dragon renderer
08:52:10 <zid> https://drive.google.com/open?id=1cexywf6tcKfsw6tPSzpWLVBVsUpjqXCO is 'dragon.rar' don't ask me what the difference is
08:52:34 <elderK> Thanks :)
08:52:40 <elderK> :P I'll diff them
08:53:00 <zid> I ran dragon_spec, seems to work so that's nice
08:53:22 <elderK> The other one doesnt have any source?
08:53:33 <zid> oh, I guess that's the difference
08:54:01 <zid> lemme zip up the working tree
08:56:12 <elderK> Thanks :)
08:56:32 <zid> You're also getting bob-omb battlefield from sm64 :P
08:56:49 <elderK> I've been on/off learning about GL for years. I took a "Computer Graphics" paper last semester, where we wrote a raytracer (software), and a "phong renderer" in gL.
08:57:03 <elderK> :P
08:57:09 <elderK> I never played that game :)
08:57:16 <zid> well, better go do it
08:57:19 <elderK> hahha
08:57:31 <zid> https://drive.google.com/open?id=1fd7Ilg6pAszwqK28eNciw7rfLnM5wHTb
08:57:59 <zid> check dragon.c :P
08:58:16 <zid> (if your editor doesn't explode)
08:58:42 <zid> I accidentally used short instead of int to index it and it took 20 minutes for cmd to finish all the error message printing gcc did
08:59:25 <elderK> The entire program is in bomb.c?
08:59:29 <zid> no
08:59:45 <elderK> Maybe google drive
08:59:46 <zid> bomb.c is bobomb battlefield
08:59:49 <elderK> s "previewer" is busted.
08:59:58 <zid> You were supposed to hit the underscored down arrow
09:00:00 <zid> and download it
09:01:16 <zid> oh whoops I edited it this like.. 2 days ago to see if a shader I found worked
09:01:23 <elderK> I did :)
09:01:29 <zid> https://cdn.discordapp.com/attachments/417023075348119556/489251386920271872/unknown.png It did work :P
09:01:37 <zid> It was a CRT effect filter :D
09:01:44 <elderK> I will look at in detail shortly - studying on/off right now.
09:01:51 <elderK> Cool picture!
09:02:11 <elderK> The water/land looks awesome, btw
09:02:16 <zid> yea it's stolen
09:02:29 <elderK> Skybox? Or is it being rendered?
09:02:33 <zid> skybox
09:02:38 * elderK nods
09:02:39 <zid> it's a cubemap
09:02:43 <zid> with a custom shader
09:02:57 <zid> and by custom I mean it uses a funny trick so that you can render it last for extra performance
09:03:07 <elderK> Cool :)
09:03:12 <elderK> I'm going to have fun reading through this stuff :_)
09:03:18 <elderK> Thanks a bunch for uploading it :)
09:03:23 <zid> Grab the fshade.txt from the other .rar and shove it in dragon/
09:03:26 <zid> to fix the lighting
09:04:38 <zid> Other things I did between boros v1 and not working on boros for 2 years: tetris grandmaster, beat exapunks, got the titlescreen of prehistorik man working better in my gameboy emulator
09:04:56 <zid> beat mgsv, made that dragon
09:05:11 <zid> https://cdn.discordapp.com/attachments/417023075348119556/449850839150886912/unknown.png Oh that's a cool one, diffuse is red, specular is green
09:07:16 <elderK> :D Nice
09:07:23 <elderK> Boros?
09:07:27 <zid> my 'os'
09:07:34 <zid> I'm back at it after 2 years off
09:07:42 <klange> sometimes it's good to take a break
09:08:23 <zid> I also overclocked my cpu for fun, that was pretty neat, I took it to 4.5GHz and it passmarks like an 8700k despite being 8 years old
09:09:50 <elderK> :O 4.5GHz?!
09:09:56 <elderK> And yeah, breaks are good.
09:10:05 <zid> they're coming in faster than that stock these days
09:10:29 <elderK> I saw a post a few months back about Intel shipping ~4GHz processors.
09:10:29 <zid> 8086k has a stock turbo of 5GHz
09:10:33 <elderK> :O
09:10:52 <zid> I'll take a w-2125 though, if you've got one spare
09:23:24 <elderK> :P I'm happy with anything that's better than the last model :P
09:23:37 <elderK> I haven't owned a "high end" machine for many, many years.
09:23:55 <elderK> :P These days, I just live with whatever laptop I can get that has a decent processor.
09:32:19 <FireFly> same. I find an acceptable CPU covers all my needs nicely enough
09:36:39 <elderK> Supporting the various virtualization extensions though is a must for me.
09:36:56 <elderK> Although that isn't as "big" of an ask anymore, everything has VT stuff these days.
09:37:46 <elderK> Besides, I don't really play games all that much anymore and if I do, they are "ancient" games that I enjoyed when I did. So, for instance, pretty much anything I would play would run on a 500MHz machine with "that era" video hardware.
09:37:59 <elderK> So, bleeding edge hardware isn't so much of an issue anymore for me.
09:38:21 <elderK> Things compile fast enough - and I use a pretty minimalistic distribution of Linux - I hardly ever hit swap.
09:38:39 <elderK> Building Firefox, WINE or QT always takes frikkin' forever though.
09:38:43 <elderK> Or GCC.
09:39:20 <elderK> :P I can live with that. Living without broadband would be far harder.
09:42:15 <zid> I don't even attempt to build C++ code on my machine and it sounds a lot faster than yours
09:44:09 <zid> points for bravery I guess
09:46:09 <elderK> Core i5-7200U @ 2.5GHz.
09:46:17 <elderK> 8G RAM. :)
09:46:21 <elderK> SSDs are a total must have though
09:46:31 <zid> yea 8G + C++ sounds like a nightmare
09:46:32 <zid> -j0.4
09:46:46 <elderK> The only thing I build that causes me to hit swap, is Firefox.
09:46:50 <elderK> Everything else is okay.
09:46:55 <elderK> I usually build at -j4
09:47:05 <klys> tried to build android
09:47:08 <zid> yea I have 4+HT so I use -j8.. I'd need about 128GB for that
09:47:43 <elderK> I'm pretty sure mine's dual core, with HT. I doubt I have four "real cores."
09:48:25 <klange> yep
09:49:08 <zid> passmark score of a 7200U.. 4625, notbad
09:49:50 <elderK> It's a Lenovo machine - I'm pretty happy with it. Particularly with their EFI implementation.
09:49:54 <elderK> After having a Toshiba, man,
09:49:57 <elderK> They did EFI so so so bad.
09:50:04 <zid> mine's 9k stock and 13k overclocked
09:50:19 <elderK> Like, if I alter the boot stuff from Linux, the EFI shows it in the boot menu. On Toshiba, it would really... screw up.
09:50:46 <zid> I've yet to see a decent laptop bios
09:50:49 <elderK> And in terms of maintenance, the Lenovo beats the shit out of the Toshiba :P
09:50:55 <zid> for some reason they're all awful
09:51:07 <elderK> Iono. I've had no problem with the Lenovo one.
09:51:15 <elderK> Every IBM or Lenovo machine I've ever used has been a pleasure in this regard.
09:51:35 <elderK> Toshiba has always been shit universally for me. Compaq was pretty shit too.
09:51:36 <zid> There'll be something that sucks, don't worry, you just haven't found it yet
09:51:39 <elderK> Haha
09:51:41 <elderK> Always is :)
09:52:03 <zid> My mobo has offline bios updates so I can just hex edit mine and reflash it whenever
09:52:07 <zid> without having to risk bricking it
09:52:17 <elderK> I like to think that "ThinkPads" are higher quality than other stuff. It's probably not so true these days, but, it sure feels that way :)
09:52:24 <elderK> That's awesome!
09:52:52 <zid> yea, even without the CPU installed, I just put it on a flash drive and hold the cmos clear button while it boots
09:53:06 <zid> and it copies the file named <mobomodel>.ROM to the bios chip for me
09:53:18 <zid> I guess the ME does it or something
09:53:32 <zid> so I could potentially brick it if I messed with the ME stuff? idk
09:54:32 <zid> the mobo costs like 10x what any other part of my pc costs
09:54:53 <zid> People are almost giving away my cpu on ebay now, £20
09:57:18 <elderK> Maybe in a few years I'll invest in a desktop. Iono, laptops are extremely convenient for me.
09:57:30 <elderK> And yeah, tech depreciates quickly.
09:57:54 <elderK> I was looking for some Nth hand cheapie laptops online, ebay. It made me kind of sad how hard it was to find one with a floppy drive :P
09:58:08 <elderK> I have a weird nostalgia for floppies :P
09:58:22 <zid> I want a 2nd hand broken laptop with hdmi and vga that can both be used at the same time
09:58:23 <zid> thanks
09:58:38 <zid> broken display that is
10:00:26 <elderK> Aye - that's a real must have for me - VGA and HDMI that can be on at once. And DP too, if p ossible.
10:00:35 <elderK> I spend much of my time using the laptop, wired to things like displays, keyboards, etc.
10:00:50 <zid> I just what a ghetto arcade machine :P
10:01:03 <elderK> I don't often "work" on the laptop, as a laptop. I'll "consume" from it in laptop mode, like, reading books or something. But for anything real, I'm at my desk, wired.
10:01:03 <zid> VGA out to a CRT, hdmi out to my capture card on my desktop
10:01:07 <elderK> Hehehe
10:01:12 <elderK> :D MAME all the way.
10:01:20 <zid> actually, a PC based arcade game
10:01:23 <zid> taito type-x
10:01:43 <zid> the drm is incredibly complicated, first, it checksums the bootsector
10:01:44 <zid> the end
10:10:30 <elderK> Jesus
10:10:33 <elderK> That's pretty nuts
11:23:43 <elderK> Have you guys seen this? :P
11:23:44 <elderK> https://gitlab.com/femsf/toleranux/blob/mistress/README.md
11:23:45 <bslsk05> gitlab.com: README.md · mistress · Feminist Software Foundation / toleranux · GitLab
11:23:59 <sham1> Now we have
04:14:50 <chibill> https://hackaday.com/2018/09/17/a-1-linux-capable-hand-solderable-processor/ Seems like an interesting chip that could be targeted by some people here. :) (I want to try and do development on it.)
04:14:51 <bslsk05> hackaday.com: A $1, Linux-Capable, Hand-Solderable Processor | Hackaday
04:16:45 <clever> chibill: what about keeping the ddr3 data lines all matched?
04:17:49 <chibill> Well there are pre-made boards avalibale. Plus it makes for a neat challegne
04:19:11 <clever> chibill: and i'm curious as to what part of the software is a mess on the A13
04:40:45 <chibill> I have no idea considering they have Debain Linux Images and source for it.
04:42:00 <chibill> Barebones is what I am after :P Considering its cheap with a lot of memory I could make a nice high powered Micro - Controllor or a custom Computer with custom OS for stuff.
04:44:37 <clever> chibill: one min
04:46:13 <clever> chibill: http://linux-sunxi.org/BROM
04:46:14 <bslsk05> linux-sunxi.org: BROM - linux-sunxi.org
04:47:24 <chibill> I am not sure that applies to the A13
04:48:22 <chibill> https://www.olimex.com/wiki/Bare_Metal_programming_A13
04:48:26 <bslsk05> www.olimex.com: Bare Metal programming A13 - Olimex
04:54:42 <chibill> Hm I could look at https://github.com/NextThingCo for more info as their C.H.I.P board uses the Allwinner R8 which is just another name for the A13 (According to linux-sunxi.org
04:54:44 <bslsk05> github.com: Next Thing Co. · GitHub
05:00:07 <chibill> Also seems its support in main stream linux http://linux-sunxi.org/Linux_mainlining_effort#Status_Matrix
05:00:08 <bslsk05> linux-sunxi.org: Linux mainlining effort - linux-sunxi.org
05:15:31 * geist yawns
05:25:06 * shikhin yawns to give geist company.
06:05:21 <nshp> any resources on starting APs in a UEFI system?
06:05:43 <nshp> getting a bit lost in all the outdated or BIOS-specific instructions out there
06:06:01 <heat> it doesn't have anything to do with the BIOS
06:06:28 <heat> First you get the MADT table or the MP tables or your favorite tables
06:06:56 <nshp> do I though? this is one of the things I'm not sure about
06:07:09 <heat> do you what?
06:07:46 <nshp> what information do I actually need from MADT or MP?
06:07:54 <nshp> just the local APIC base?
06:07:56 <heat> Okay, so I never worked with the MP before
06:08:14 <heat> so I can only tell you about MADT
06:08:27 <isaacwoods> you're also meant to bring APs up in the order in the MADT, not randomly
06:08:46 <heat> isaacwoods: there are no order restrictions afaik
06:09:07 <heat> Basically, you iterate through the table looking for subtable headers that have type `ACPI_MADT_TYPE_LOCAL_APIC`
06:09:33 <heat> with that, you get each cpu's lapic id
06:09:51 <isaacwoods> heat: spec says you should, not sure if it matters for real tho
06:10:21 <heat> you can theoretically wake up every processor without even looking at the MADT
06:10:26 <heat> at the same time
06:10:31 <nshp> the examples I'm looking at (those which I can actually read) seem to just broadcast SIPIs to all but the active processor, not specifying which to start at all
06:10:35 <heat> so I bet it doesn't
06:10:42 <geist> yeah i dont think uefi changes the secondary boot processors booting really
06:10:45 <heat> nshp: Yes, that's what you need to do
06:10:58 <geist> you can and probably just still use ACPI to read the MADT table, which says which cpus are there
06:11:08 <geist> UEFI will hand you the ACPI pointer if you want, or you can search for it in the legacy way
06:11:24 <geist> and then you boot each core the same old way you always did, which is annoying but functional
06:11:36 <heat> geist: You cannot search for it the the legacy way
06:11:44 <heat> not supported by UEFI at all
06:11:45 <geist> okay, you heard it there
06:11:54 <geist> in that case you need to grab the ACPI pointer from uefi
06:12:43 <nshp> so far, not talking about actually being nice to the universe and making this code work on everything, I'm not seeing a reason to talk ACPI just yet
06:12:46 <geist> i'll try to polish t off in the next day or so but i just wrote this weekend some little standalone code to find and parse some of the simple ACPI tables
06:13:09 <geist> you have to, because that's what describes which CPUs are there
06:13:24 <heat> you can look at the MADT without "talking ACPI"
06:13:27 <geist> MADT table == acpi
06:13:54 <heat> you kinda just have to parse 2 tables to get a MADT
06:13:58 <nshp> but, as the wiki says somewhere, can I not also just compile-time configure the number of cores and wait for "that many" to come up?
06:14:06 <heat> the DSDT and the SSDT are way different
06:14:12 <heat> no
06:14:20 <geist> nshp: for getting started, sure. it's totally not a good solution beyond simple hackery
06:14:35 <geist> because you cannot assume anything about the layout of the cpus, what their apic ids are, etc
06:14:36 <heat> LAPIC IDs aren't guaranteed to be contiguous(or make sense at all)
06:14:41 <geist> except that the BSP is i think always 0
06:14:57 <nshp> but each core can get its own ID once it starts, no?
06:14:59 <geist> whcih is a lie, take that back
06:15:15 <geist> i have an AMD machine here that numbers the 4 cores apic id 0x10 - 0x13
06:15:18 <heat> nshp:?
06:15:31 <nshp> switch on the x2APIC, read the APIC_BASE MSR, read the ID register out of that APIC mapping?
06:15:51 <geist> nshp: in short, no.
06:16:08 <geist> nbut you're now just talking about writing more code than just parsing the MADT table, which is really quite simple
06:16:35 <nshp> is that more code? isn't that code I need anyway?
06:16:42 <geist> no
06:17:08 <geist> you dont *need* x2apic, and x2apic is only present in very recent intel machines anyway, so by using it you're not being backwards compatible or compatible with any AMD machine
06:17:22 <geist> it's purely an optimization
06:17:47 <geist> and anyway you dont want to reassign apic ids for all your cpus. if you do you still need the MADT table to know which ones are already in use
06:17:50 <nshp> right, but again, I have no grand dream of actually making this code work on anything but my computer and my emulator
06:17:53 <geist> and make sure yo udont double assign anything, including io apics
06:18:11 <geist> so. if you're ony care about running on your computer, then hard code the APIC ids and move on
06:18:16 <geist> that seems to be the answer you want, so go for it.
06:18:29 <geist> i bless this as acceptable
06:18:32 <heat> that's really no excuse though
06:18:53 <heat> iterating through a simple table in memory to read what LAPICs exist is very simple
06:18:54 <geist> agreed, but if they dont wanna do the work, then let em be
06:19:17 <geist> if you want to jump directly to the meat of things and bootstrap the cpus, which is its own task, then that's a good starting point
06:19:25 <nshp> I don't mean to give the impression that I don't appreciate the help, just really trying to dig through the layers of information out there which are mainly for compatibility
06:19:31 <geist> suggestion: write the code such that later on when you implement the MADT table, etc, you just drop that code in
06:19:48 <nshp> sure
06:19:49 <geist> key is ACPI/MADT is the current gen stuff, you're skipping a few layers of compatibility there
06:20:06 <geist> but it's pretty good starting point because there doesn't seem to be anything else on the horizon, and it's been the standard since at least x86-64 came along
06:20:22 <geist> so it's fairly safe. if you wanna skip it and hard code for now, makes sense, but leave a hole to implement that later
06:21:05 <geist> re: booting the secondary cores. i think the state of the art is still the old classic apic INIT signal stuff
06:21:15 <nshp> so it seems
06:21:21 <geist> which is annoying, but mangeable i dont think UEFI give syou a more handy mechanism
06:21:48 <geist> the most annoying part is not the actual delivery of the signals, it's that each core comes up in 16 bit mode, so you have to write the bootstrap code to get it from 16 -> 64 and into your kernel
06:22:00 <heat> wait let me open up the intel manual
06:22:18 <nshp> heh, I was wondering if there was some odd corner of UEFI which magically switched on the APs for me. not great documentation there.
06:22:33 <heat> obviously not
06:22:39 <geist> i dont think so. there may be a UEFI call to boot the other cpus, but i'm not aware of it
06:22:51 <geist> iirc, there was a bios32 call or something somewhere along the way, but i dunno if anything used it
06:22:51 <heat> UEFI is very explicit on what services exist at runtime
06:23:18 <nshp> and *that* was my next question geist - I was wondering if I have to write the bootstrapping code even though the BSP is already in long mode
06:23:18 <nshp> that's unfortunate
06:23:35 <geist> yep. my experience is the bootstrapping code is no big deal.it's 20 lines of asm
06:23:45 <nshp> sure
06:23:49 <geist> the experience is the getting everything set up so that there is a 16 bit trampoline < 1MB, etc is more annoying
06:23:58 <geist> and it gets more annoying the more sophisticated your kernel gets
06:24:23 <geist> since it's essentially more special case snowflake stuff you have to implement for this brief period
06:24:24 <nshp> and then the vector passed to the SIPIs is the address of that trampoline, right?
06:24:27 <heat> Anyway, my code sends an INIT to the AP, waits 200ms, sends an INIT level de-assert, times out after a second and retries once
06:24:36 <heat> it works pretty nicely so you might want to try that
06:24:43 <geist> right. and you can tell it what address to go to, which is nice, but it has to be <1MB physical, because real mode
06:24:53 <nshp> ok
06:25:02 <nshp> heat: got a source link?
06:25:10 <geist> so i'd suggest as you bring up your VM just dont mess with <1MB. i just leaeve it all off limits to the regular VM
06:25:22 <geist> so that you can grab a block of it for this
06:25:36 <heat> I use 0x0 for the trampoline page
06:25:45 <nshp> alright
06:26:00 <heat> nshp: https://github.com/heatd/Onyx/blob/master/kernel/arch/x86_64/apic.c#L417
06:26:02 <bslsk05> github.com: Onyx/apic.c at master · heatd/Onyx · GitHub
06:26:37 <nshp> heh, each example I look at has a different busy-
06:26:41 <nshp> * busy-wait implementation
06:26:58 <geist> https://fuchsia.googlesource.com/zircon/+/master/kernel/arch/x86/smp.cpp#44 for another example
06:26:58 <bslsk05> fuchsia.googlesource.com: kernel/arch/x86/smp.cpp - zircon - Git at Google
06:27:09 <nshp> thanks
06:27:09 <heat> I hlt because the timer's already up so you kinda have to wait for irqs
06:28:33 <johnjay> anybody heard of xv6?
06:28:38 <heat> yes
06:28:40 <johnjay> it's used in an MIT course apparently
06:28:44 <heat> I personally believe it's awful
06:28:49 <geist> right
06:28:58 <johnjay> awful for teaching purposes or awful in general?
06:29:03 <heat> both
06:29:09 <johnjay> something bad can be useful as "don't do it this way"
06:29:28 <heat> It's incomplete, broken, hacky
06:29:51 <graphitemaster> herd an interesting discussion today, if somebody without education has a brilliant idea, do you dismiss it automatically?
06:29:59 <heat> graphitemaster, no
06:30:10 <johnjay> graphitemaster: yes because if you have education you want to keep your job and authority
06:30:13 <graphitemaster> if so, who takes the blame for all the dismissed ideas that actually worked
06:30:18 <johnjay> anybody outside is a threat to that!
06:30:40 <heat> xv6 is not what a good UNIX (or not UNIX, system in general) should be. It doesn't do things properly
06:30:48 <heat> Also, it's 32-bit
06:30:57 <graphitemaster> I was sort of veering towards "yes"
06:30:58 <johnjay> heat: meaning, if you compare it to the actual Unix v6 it's worse?
06:31:07 <heat> no idea
06:31:13 <heat> old unix sauce is awful as well
06:31:18 <graphitemaster> the discussion was the topics of mathematics mind you and how the maths community doen't take anyone seriously unless they have a phd
06:31:35 <johnjay> graphitemaster: the bottom line is everybody hates the free market when it's their own industry. so if you want to be self interested then yes you dismiss their ideas. it's not far sighted fc
06:31:39 <heat> computing has progressed a lot since unix v6(or even unix in general)
06:31:48 <johnjay> graphitemaster: ramanujan didn't have a phd
06:32:04 <johnjay> heat: sure. the only justification i can think of is to study the evolution of ideas
06:32:35 <graphitemaster> geist, your smp code there could use a couple modern C++ isms like a unique_ptr for that thread calloc
06:32:42 <graphitemaster> that goto cleanup mess :(
06:32:45 <heat> instead of that you kinda get people thinking that's how kernels work
06:32:46 <johnjay> graphitemaster: there was a book on how academics are trained to only think in certain approved ways or something
06:33:44 <graphitemaster> johnjay, humm
06:33:52 <johnjay> graphitemaster: sec let me find it
06:34:16 <johnjay> ah ok this is it: https://www.amazon.com/Disciplined-Minds-Critical-Professionals-Soul-battering/dp/0742516857
06:34:19 <bslsk05> www.amazon.com: Disciplined Minds: A Critical Look at Salaried Professionals and the Soul-battering System That Shapes Their Lives: Jeff Schmidt: 9780742516854: Amazon.com: Books
06:35:03 <johnjay> the writer has a physics PhD, for some reason the description doesnt' mention it
06:35:53 <johnjay> This is not particular to the maths people, just academia in general
06:37:07 <graphitemaster> johnjay, does the book provide examples for people who are not educated in that way and thus have a perspective that has helped them provide invaluable information for academia?
06:37:42 <johnjay> it's more about how people inside academia are controlled and boxed in
06:38:18 <johnjay> here's a story about ramanujan, the genius mathematician with no formal training:https://www.amazon.com/Man-Who-Knew-Infinity-Ramanujan/dp/1476763496
06:38:20 <bslsk05> www.amazon.com: Amazon.com: The Man Who Knew Infinity: A Life of the Genius Ramanujan (9781476763491): Robert Kanigel: Books
06:40:50 <johnjay> See here also for someone in academia explaining his reasons for accepting or not accepting unsolicited papers: https://www.scottaaronson.com/blog/?p=304
06:40:53 <bslsk05> www.scottaaronson.com: Shtetl-Optimized » Blog Archive » Ten Signs a Claimed Mathematical Breakthrough is Wrong
06:40:59 <johnjay> i'll stop the link spam now
06:41:54 <heat> I think one of the better and more complete kernels out there is zircon
06:42:00 <heat> the code is really clean and easy to understand
06:42:16 <heat> linux is way too complete for a newbie to understand what it's doing
06:42:55 <heat> (it has a fetish for function pointers)
06:42:55 <johnjay> heat: you mean fuchsia from google?
06:43:04 <heat> I mean zircon, the kernel, from google
06:43:10 <heat> fuchsia is the whole OS
06:43:17 <johnjay> ok. wikipedia makes it sound like an afterthought
06:43:23 <johnjay> with th OS being the main thing
06:43:25 <graphitemaster> it's been renamed
06:43:31 <graphitemaster> it used to be magenta
06:43:33 <heat> I miss magenta
06:43:37 <heat> best name ever
06:43:43 <graphitemaster> but Google has some internal project named magenta so they had to rename
06:45:33 <johnjay> heat: should I try spinning zircon up in qemu
06:45:37 <nshp> I expected the netbsd kernel source to make sense, given how much of its userspace code is remarkably simple
06:45:39 <graphitemaster> magenta is clearly the code name of the coloring department who decides which shade of purple to invent for the new pixel phones
06:45:40 <johnjay> or does it not matter
06:45:41 <nshp> I was wrong.
06:46:12 <heat> fuchsia is huge
06:46:16 <heat> I gave up trying to build it
06:46:41 <johnjay> so it's more about reading hte source code for ideas then if you can't run it?
06:46:52 <heat> yes I mostly just read source code
06:46:55 <graphitemaster> fuchsia has a relatively simple build process though
06:47:04 <heat> I disagree
06:47:20 <graphitemaster> the fx tool is pretty easy
06:47:22 <johnjay> if android is any indication i'm scared to try building it lol
06:47:24 <johnjay> esp with myb ad internet
06:47:26 <graphitemaster> fx set x64
06:47:29 <graphitemaster> fx full-build
06:47:30 <graphitemaster> done
06:47:38 <johnjay> it will probably say "downloading the 5GB install image..." or something
06:47:53 <heat> I remember I had to wait a lot of time for it to download stuff, so I kinda gave up
06:48:02 <heat> dunno maybe I was following the wrong thing
06:49:22 <heat> But yeah, I mainly use linux as reading material, then zircon if I really don't understand what linux is doing
06:50:17 <heat> which is relatively common when reading huge blobs of source code like the i915
06:50:32 <graphitemaster> anyways I've never been able to successfully run a Fuschia OS
06:50:35 <graphitemaster> I've been able to build it
06:50:52 <graphitemaster> but fx run has never worked
06:51:01 <graphitemaster> just solid black screen
07:02:27 <johnjay> er
07:02:54 <johnjay> well if ou build it but it doesn't run properly that's still not that useful
07:03:21 <johnjay> can you just separate zircon out and compile it separately?
07:03:28 <heat> I don't think so
07:03:44 <heat> when I need to look at things running I have a kernel and an initrd and I just run it with qemu
07:03:46 <heat> works pretty well
07:03:59 <heat> then I snoop whatever I wanted to see
07:04:23 <johnjay> qemu doesn't have -kernel anymore right?
07:04:40 <heat> it does
07:04:44 <johnjay> ok
07:07:28 <johnjay> i googled compiling linux with msys2 and i got some post from 2015 about compiling linux 0.11 on windows 10 with gcc 1.4 wtf
07:08:25 <bauen1> lol
07:33:01 <johnjay> TIL that making programs fight each other like pokemon is a thing
07:33:02 <johnjay> https://github.com/codeguru-il/corewars8086
07:33:02 <bslsk05> codeguru-il/corewars8086 - Core Wars for standard 8086 assembly. (15 forks/19 watchers)
07:34:46 <glauxosdever> > src/main/java/il/co/codeguru/corewars8086
07:35:50 <glauxosdever> rain1: When are we starting?
07:52:32 <glauxosdever> Another thing, I'm wondering how should a programming language encourage hierarchical modularity (e.g. a compilation unit that contains modules that contain submodules that contain subsubmodules...)
07:55:25 <glauxosdever> I was thinking of "a source file is a module" that may link/include other files "modules" and the top-level module along with all of its submodules recursively are a compilation unit
07:56:50 <glauxosdever> I think C++ has namespaces?
08:02:03 <glauxosdever> Probably should be clearer concerning the last question, I know C++ has namespaces but they are not exactly what I want
08:04:17 <froggey> sounds similar to rust's modules: https://doc.rust-lang.org/book/2018-edition/ch07-00-modules.html
08:04:17 <bslsk05> doc.rust-lang.org: Modules - The Rust Programming Language
08:05:11 <rain1> hey
08:07:35 <rain1> I got so swamped by all the documentation
08:07:57 <rain1> I wanted to make a 64 bit version of the barebones kernel
08:08:00 <glauxosdever> froggey: Thanks, I'll look into rust a bit more before starting. It indeed has a lot of good ideas, I have read some documentation, but not everything
08:08:16 <rain1> so i just need to jump from protected mode to long mode & enable 64 bit mode
08:09:45 <glauxosdever> rain1: Let's start with protected mode first
08:09:57 <rain1> but I think grub puts us into that mode
08:10:03 <glauxosdever> As we will implement it anyway and it's easier
08:10:13 <glauxosdever> It does
08:10:44 <rain1> so what did you mean? writing a 32 bit kernel?
08:10:52 <glauxosdever> Yes
08:11:15 <glauxosdever> Unless we don't want to support 32-bit x86 machines
08:11:53 <rain1> I wasn't planning on it
08:16:35 <johnjay> rain1: which documentation swamped you?
08:16:53 <rain1> well i have these 4 enormous intel software developer PDFs and 3 AMD ones
08:17:13 <rain1> and i couldn't even really find the answer in them
08:17:29 <rain1> I found a 'recipe' from some 64 bit rust kernel example, but it didn't work in qemu
08:17:35 <johnjay> rain1: that does kind of defeat the purpose of having giant manuals. can you link them in your readme on github?
08:18:05 <rain1> https://github.com/microkernel2018/microkernel2018/wiki#documentation they are here
08:18:07 <bslsk05> github.com: Home · microkernel2018/microkernel2018 Wiki · GitHub
08:18:19 <rain1> oh I didn't add the AMD ones, one sec let me edit this
08:18:37 <johnjay> i see you do have the xv6 book there...
08:18:47 <johnjay> heat was saying it's garbage
08:19:03 <rain1> there
08:19:05 <rain1> oh
08:19:41 <johnjay> i might be overstating it
08:20:39 <heat> it's not garbage, it's crap ;)
08:20:46 <rain1> alright
08:21:50 <rain1> https://i.imgur.com/MmttS2E.png
08:21:57 <rain1> i found this good diagram in the AMD manual
08:22:13 <rain1> but I couldn't find much beyond that about how to go from protected to 64 bit
08:22:15 <heat> btw I just want to say that I'm not interested in the project anymore
08:22:19 <heat> because we clearly don't see eye to eye
08:22:34 <heat> and I feel that all my advice is getting ignored
08:23:15 <glauxosdever> heat: I hope it's not because of me
08:23:22 <heat> it's not
08:24:10 <rain1> can anybody point me to the proper documentation for this? I kind of understand the process that needs to be done by reading https://github.com/phil-opp/blog_os/blob/post_2/src/arch/x86_64/boot.asm but i don't want to just translate that file to GNU AS
08:24:11 <bslsk05> github.com: blog_os/boot.asm at post_2 · phil-opp/blog_os · GitHub
08:24:35 <heat> although the whole "lets support old hardware" kinda put me off for good, it's something that I really do not agree with
08:24:47 <heat> rain1: first load a 32-bit gdt
08:24:57 <heat> flush segments, farjmp/retf
08:25:11 <heat> set up paging structures
08:25:22 <rain1> heat: we're not supporting old hardware at this point, just raspberry pi and 64 bit intel machines
08:25:27 <heat> enable long mode and paging and stuff
08:25:55 <rain1> where did you hear this?
08:25:59 <heat> 64-bit is old-ish
08:26:08 <rain1> what
08:26:16 <rain1> do you have a 128-bit computer
08:26:24 <glauxosdever> I suggested we do support older hardware (32-bit and BIOS)
08:26:34 <heat> the whole "lets use multiboot" and "lets support BIOS" is something that I really do not agree with
08:27:01 <heat> it's very old stuff
08:27:31 <glauxosdever> I don't really agree with multiboot either, but it makes it easier for people to get started. I suspect rain1 would make a better bootloader later
08:27:43 <rain1> ok, thank you. I'm going to read about UEFI for a bit and decide if we should use that instead of grub multiboot
08:27:45 <glauxosdever> Or we would make it together
08:28:00 <glauxosdever> Or..
08:28:10 <heat> I can't see why you would want to support very old things in a new project
08:28:14 <glauxosdever> heat: I'm just thinking more realistically
08:28:31 <heat> fuchsia does not support BIOS for example.
08:28:43 <heat> and it's a decision I fully understand
08:29:50 <heat> and I'm not feeling like rewriting code honestly, for a system that's going in a direction I do not agree with
08:30:28 <glauxosdever> I don't agree with it either. But I could work on it alongside my projects
08:30:42 <glauxosdever> Or not, it depends
08:30:48 <glauxosdever> Anyway, bbl
08:31:15 <rain1> It doesn't seem like rpi has eufi
08:31:16 <rain1> uefi*
08:31:32 <rain1> so would uefi be used only in the x64 arch
08:32:13 <heat> rpi doesn't support multiboot either
08:32:22 <johnjay> rain1: how much RAM does your pc have? i'm thinking of upgrading
08:32:35 <rain1> you shouldn't need a lot of RAM
08:32:50 <johnjay> rain1: well i use firefox so...
08:32:57 <johnjay> 8GB is not enough apparently
08:33:20 <heat> I use chromium + visual studio code + emulators and 8GB is plenty
08:33:35 <heat> note that visual studio code is chromium
08:33:54 <heat> so, 2 chromium instances, one as a web browser and the other one has an editor, and I have plenty mem
08:34:14 <johnjay> "UEFI requires the firmware and operating system loader (or kernel) to be size-matched; for example, a 64-bit UEFI firmware implementation can load only a 64-bit operating system (OS) boot loader or kernel. After the system transitions from "Boot Services" to "Runtime Services", the operating system kernel takes over."
08:35:09 <heat> johnjay: you can load 32-bit kernels, you just have to step back to protected mode, which I'm not sure if it's possible
08:35:24 <heat> there's no actual "you can't do that!"
08:37:27 <rain1> wow would UEFI put us straight into 64 bit mode?
08:38:09 <heat> yes
08:38:22 <johnjay> latest UEFI spec is 2.7A: http://www.uefi.org/specifications
08:38:27 <bslsk05> www.uefi.org: Specifications | Unified Extensible Firmware Interface Forum
08:38:34 <johnjay> the document is 2800 pages. ;_;
08:38:47 <glauxosdever> Back
08:38:57 <glauxosdever> Last time I checked it was 2600-something
08:38:58 <heat> see, I don't think you're paying attention to what I'm saying
08:39:02 <heat> I don't like to be ignored
08:40:10 <heat> johnjay: I currently have more than that open right now
08:41:19 <johnjay> alright i'll keep that in mind
08:41:42 <mauz555> what is the difference between a Newlib cross compiler and a Linux Cross Compiler for the same ISA (target) ?
08:42:11 <rain1> I think heat is right and we should use UEFI
08:43:32 <rain1> grub multiboot was nice because you can easily boot in qemu with -kernel foo. I'll search about how to boot a uefi kernel in qemu
08:43:55 <rain1> I would prefer not to have to create a .iso every time to test
08:46:50 <zid> why not, it's the same as using grub
08:47:07 <zid> mount -t iso19550 -o loopback blah.iso /mnt/iso; cp kernel.bin /mnt/iso; umount /mnt/iso
08:47:27 <heat> thats not good
08:47:34 <heat> mounting to create it sucks
08:47:38 <zid> especially because I got the iso number wrong
08:47:48 <heat> mcopy + mformat is good
08:47:51 <zid> don't need to mount to create it
08:48:06 <zid> but it's what I do as my make run, essentially, for speed
08:48:20 <heat> zid: https://github.com/heatd/Carbon/blob/master/scripts/make_efi_iso.sh
08:48:22 <bslsk05> github.com: Carbon/make_efi_iso.sh at master · heatd/Carbon · GitHub
08:48:49 <zid> make prep creates the fs, make run injects the latest copies of all the files
08:49:28 <heat> my script is really simple and works nicely, and works on .iso and usb flash drives
08:50:11 <heat> I don't believe you can use ISO<whatever the hell its called> on flash drives
08:51:35 <glauxosdever> ISO-9660 :-)
08:56:43 <johnjay> there's no isocopy/isoformat equivalent to mcopy + mformat for linux?
08:57:28 <freemint> Hello in the next few weeks i got an OS porting project. I do not have the hardware yet but i wanted to introduce myself beforehand.
08:57:38 <rain1> hi
08:58:08 <johnjay> rain1: what's a good code implemenation of uefi? grub?
08:58:08 <johnjay> that 2800 book doesn't look too promising
08:58:22 <heat> johnjay: it's very easy
08:58:26 <freemint> I am University student from Germany and i want to port an embedded OS to a "new" CPU architecture.
08:58:36 <heat> it's actually really simple to write an efi bootloader
08:58:57 <johnjay> oh is there an osdev wiki page about it?
08:59:06 <heat> it's all really well defined
08:59:14 <johnjay> right... in a 2800 page specification
08:59:22 <heat> you're not supposed to read it all
08:59:30 <freemint> The CPU architecture is J-Core. it is an fork of the commercial SuperH architecture for which the patents expired.
08:59:57 <johnjay> ok
09:00:03 <freemint> J-core is binary backwards compatible but adds a few new instructions like CAS.
09:02:57 <freemint> I plan to port the (micro-)T-kernel on to a board which runs j-core inside an FPGA. This kernel was ported to SuperH before and i can use GCC with a few minor patches. There is already an Linux running under J-core on the FPGA board. One challenge is that i might have to do without an mmu. But that is no problem as micro-T-kernel was designed/specified for such situation
09:02:59 <johnjay> this osdev wiki has a lot of pages. even on uefi
09:04:01 <freemint> I hope i can rely on you. Most of the heavy lifting was already done before but still it is my first osdev project.
09:04:53 <freemint> 1. do you think that project is manageable before December when is also study for university?
09:06:00 <freemint> 2. How can i best preserve my progress/path? I am willing to contribute to the wiki but SuperH is not even listed as non profit X86 architecture
09:06:25 <zid> Is that.. an alice bot?
09:07:12 <freemint> I am not a bot.
09:07:31 <freemint> hi rain1
09:08:20 <glauxosdever> Goodnight!
09:09:08 <heat> what the hell is superh
09:09:10 <heat> and j-core
09:09:31 <zid> SH-2++
09:09:50 <zid> it fell out of patent protection and someone made a little 'compiler for SH2 cores'
09:09:57 <zid> make --with-cores=4 --with-fpu
09:10:06 <zid> spits out the design files, documentation etc for a cpu
09:10:23 <johnjay> jcore is a clean room open processor... but i can't read more because the site doesn't respond. http://j-core.org/index.html
09:10:28 <bslsk05> j-core.org <timeout>
09:10:40 <zid> It's pretty neat honestly
09:11:00 <heat> >not x86 nor armv8 nor riscv
09:11:04 <heat> noty
09:11:04 <johnjay> SuperH (or SH) is a 32-bit reduced instruction set computing (RISC) instruction set architecture (ISA) developed by Hitachi and currently produced by Renesas. It is implemented by microcontrollers and microprocessors for embedded systems. As of 2015, many of the original patents for the SuperH architecture are expiring and the SH2 CPU has been reimplemented as open source hardware under the name J2.
09:11:36 <zid> only SH2 I ever dealt with was it was in the Psikyo SH2 arcade board :P
09:11:52 * zid english gud
09:13:41 <freemint> zid thanks you explained it well
09:15:08 <freemint> heat yeah this is a known bug. The company behind the first MIT license implementation was rebounded but people are less carefull with project infrastructure now. The mailing list is down since months. But the irc #j-core lives and so does the project.
09:15:49 <freemint> oh that explanation was from johnjay, sorry for mistaking you for somebody else
09:17:00 <freemint> anyway nice to meet you all
09:24:41 * freemint is reading how to ask questions now.
09:26:26 <johnjay> eh
09:26:35 <johnjay> you mean the ESR how to ask questions thign?
09:26:36 <johnjay> *thing
09:28:39 <freemint> no that one i read that in the past but the particular rules outlined for this community
09:30:24 <johnjay> The topic says Don't ask to ask --- just ask!
09:31:24 <freemint> 1. do you think that project is manageable before December when i also study for university and it's my first osdev project?
09:31:47 <freemint> 2. How can i best preserve/share my progress/path? I am willing to contribute to the wiki but SuperH is not even listed as non profit X86 architecture
09:32:22 <johnjay> dunno what a non profit x86 architecture means
09:32:36 <johnjay> i guess you could open a github account, that's waht most people do
09:33:42 <Maka_Albarn> does anyone have any hints on implementing a decimal-to-string conversion algorithm?
09:33:49 <heat> Maka_Albarn: that's easy
09:34:07 <heat> wait, string to decimal or decimal to string?
09:34:19 <Maka_Albarn> heat: decimal to string.
09:34:50 <Maka_Albarn> I'm trying to figure out how to print the value of a integer as a decimal to the screen
09:35:07 <Maka_Albarn> I have a Hex conversion done, now I need decimal.
09:36:17 <heat> So, you have the number, you use number % 10 to get the last digit, transform to ascii, place in buffer, divide number by 10 to get next digit
09:36:23 <johnjay> Maka_Albarn: in what language? C? you use %d for integers in printf...
09:36:23 <heat> and you keep doing it until you reach zero
09:36:33 <heat> johnjay, no printf here
09:36:58 <heat> Anyway, after placing all the ascii characters in a buffer you'll notice they're reversed
09:37:08 <heat> so you reverse them back into the correct order
09:37:18 <heat> if you think about it, it makes a lot of sense
09:37:21 <Maka_Albarn> johnjay: i'm implementing a printf().
09:37:28 <heat> Maka_Albarn: Got it?
09:37:44 <johnjay> oh ok. my bad
09:37:47 * Maka_Albarn facepalms
09:38:12 <heat> I assume that means you got it ;)
09:38:14 <Maka_Albarn> heat: thank you for answering my, in hindsight, stupid question.
09:38:26 <heat> It's not stupid at all, I didn't know how to do that too
09:38:43 <heat> (back then, that is)
09:39:01 <freemint> i ment I do not know where to put my SuperH/J-core results as they are not listed under "non x86" architecture
09:39:03 <zid> I asked that question on efnet 15 years ago :)
09:39:03 <Maka_Albarn> how do you limit it to only the number of digits?
09:39:10 <zid> Maka_Albarn: 0/10 = 0
09:39:21 <heat> you keep checking if number == 0
09:39:37 <heat> after that you could transform your function into a parse digits into whatever base
09:40:01 <heat> since you just need a char buffer to get the correct character to use
09:40:22 <heat> (since hex, octal and binary work just like that too)
09:40:53 <zid> n%base and n/base are the only bits of math you really need
09:41:00 <zid> oh and c - '0' I guess
09:41:01 <freemint> also i missed everything after "i do not even know what non-profit x86 means
09:41:18 <freemint> (oh a log let me catch up)
09:50:14 <heat> https://forum.osdev.org/viewtopic.php?t=33195&p=285905#p285905
09:50:16 <bslsk05> forum.osdev.org: OSDev.org • View topic - Configuration error in HP Printer
09:50:24 <heat> this is turning into a real issue, no?
09:50:40 <heat> (it's spam btw, careful)
09:51:16 <zid> but what are you going to do about the configuration error in my HP Printer
09:51:29 <heat> have you tried turning it off and on again?
09:52:29 <zid> I tried filling it with bees
09:53:20 <heat> did you try filling it full of thermal paste and rgb leds?
09:53:44 <zid> No just my PC
09:53:51 <heat> well, try it
09:54:32 <zid> It's now printing 800,000 pages a second but the pages are covered in bees :(
09:54:56 <heat> I heard bees don't like thermal paste
09:55:04 <heat> did you try covering them with thermal paste?
09:55:55 <zid> I'm not sure you're supposed to upset the bees
09:56:00 <heat> yes you are
09:56:02 <heat> believe me
09:56:20 <heat> I'm the best at bees, I'm so great at bees, I've got the best bees
09:56:26 <zid> antiapithist
09:56:38 <zid> Unlike me, I am a pro apathist
09:57:56 <heat> Queen bees tell me I've got the best bees, and believe me, I do, I've got the best bees, believe me folks
10:11:02 <Maka_Albarn> question. if I push %ebx onto the stack, and then call _init, will I still get ebx from the stack when I call _main?
10:11:31 <zid> 'get' it frm the stack?
10:11:48 <zid> oh you mean will _init destroy your stack frame?
10:12:07 <heat> yes you'll get it back
10:12:44 <Maka_Albarn> good. Then I just need to add the multiboot tag to get the memory map, and I can get started on my memory manager.
10:16:11 <Maka_Albarn> according to the multiboot spec, the boot info is already in memory. Does that mean I don't need a info request tag in my header?
10:16:53 <zid> how do you expect to know where it is if not told?
10:18:22 <Maka_Albarn> The spec says that the address of the boot info is in %ebx upon kernel entry.
10:18:49 <Maka_Albarn> I just want to know if I need to tell GRUB that I want it for it to put it there.
10:21:36 <zid> how do you expect to know where it is if not told?
10:21:51 <zid> rephased slightly, why do you expect it to be there if not instructed to
10:23:47 <rain1> how do I make a UEFI bootable kernel?
10:24:03 <rain1> it needs to be a relocatable PE executable
10:24:28 <rain1> but is there anything special beyond that, or can I just put code in there to write to the screen (for example)?
10:24:30 <zid> gcc is a good pick
10:24:40 <zid> You will need to know the execution environment
10:24:42 <geist> pretty much
10:24:51 <zid> but I don't think it's particularly restrictive
10:24:56 <geist> if you want to just run code in the UEFI context then yes look into one of the many frameworks for this
10:25:07 <rain1> oh I need a framework?
10:25:11 <geist> gnu-efi is i think the starting point that a lot of folks do
10:25:30 <geist> well, uefi has an entire programming api to interact with hardware
10:25:44 <zid> rain1: unless you want to re-write all the relevent headers etc it might be an idea to steal some, yes
10:26:12 <geist> and if you intend to just disable EFI and then run bare metal, then you stkill need to at least be able to call ExitBootServices()
10:26:27 <geist> but usually there are a few other things you want to grab from EFI before you do, like the memory map (a la e820)
10:27:14 <rain1> hmm
10:27:20 <heat> yeah
10:27:58 <rain1> https://wiki.osdev.org/UEFI_Bare_Bones ah they have one here
10:28:00 <bslsk05> wiki.osdev.org: UEFI Bare Bones - OSDev Wiki
10:28:06 <rain1> ill try building it
10:28:15 <heat> I take the time while in the bootloader to do modesetting and getting useful firmware info before loading the kernel and initrd and booting it
10:28:23 <heat> rain1: iirc all of those are slightly broken
10:28:40 <geist> yahm, also assumptiosn that the screen is in any one spot and wehatnot is not really true on uefi anymore
10:28:50 <geist> in general uefi starts in gfx mode, so for the most part VGA text is gone
10:28:53 <rain1> maybe we can fix it and even put the improvements back into the wiki
10:28:59 <rain1> oh
10:29:02 <heat> https://github.com/heatd/Carbon/blob/master/efibootldr/Makefile
10:29:03 <bslsk05> github.com: Carbon/Makefile at master · heatd/Carbon · GitHub
10:29:05 <rain1> so to do text I need to do graphics first?
10:29:06 <heat> that's how I got it to work
10:29:08 <rain1> that is way too hard
10:29:17 <geist> yes. well, that is the future
10:29:21 <rain1> I saw Carbon has a font in it
10:29:31 <geist> the fact that PCs had a text mode in the past and is pure legacy
10:30:31 <zid> My OS only supports teletype machines with the nice hole punched infinite reel paper
10:30:50 <rain1> it's interesting to learn that
10:31:23 <heat> rain1: I told you so, there's some value in grabbing things that are done and work and are tested and re-using them
10:31:53 <zid> Unless you're a masochist like me
10:32:20 <heat> There's a reason why zircon is based on lk, for example
10:32:33 <heat> It's not just a "screw it, copy them"
10:33:04 <heat> Writing code is moderately hard, writing good code is hard and writing well-tested code is even harder
10:33:15 <heat> and all of that difficulty stacks up
10:33:23 <geist> hence why for pure hobby code where you're trying to learn you may or may not change the calculation
10:33:36 <zid> If you don't steal, don't expect what you make to be good.
10:33:38 <geist> vs production quality
10:33:45 <zid> We stand on the shoulders of giants
10:39:34 <heat> note that plotting pixels isn't hard
10:40:16 <heat> it's just really boring and unpleasant because it *will* be slow, at least in your 1st or 2nd implementations
10:41:57 <zid> Which version is barycentric triangle rasterization with sse4.2
10:42:49 <heat> uh, remember those bees you had in your printer?
10:43:25 <zid> sure
10:45:55 <heat> so, get your cpu, put some rgb leds on the pins, bees love rgb leds. then wait for the bees to bend the pins, put it back on the mobo, paint it with thermal paste(can never have too much), reboot(you should do this with your pc on) and a new feature should pop up on your cpuid
10:46:28 <zid> is it bees
10:46:51 <heat> i don't know what you're asking but it's probably bees
10:47:43 <zid> is the cpuid feature Features: bees, avx, ..
10:47:59 <heat> yes
10:48:31 <heat> then you install android honeycomb for the sweet sweet performance gainz
11:07:30 <yasar> I am curious about writing a program that can be started from GRUB, do its thing, and halt (like memtest for example). I don't know what it takes to write such program yet. I was wondering if reading about OS development would be right decision, because, such program needs to be its own OS I think.
11:08:26 <zid> yes
11:08:29 <heat> yes
11:08:35 <clever> yasar: do you want it to return back to grub, reboot, or just poweroff when done?
11:08:44 <zid> odd question
11:08:59 <heat> they explicitly said "halt"
11:09:03 <yasar> just poweroff is enough
11:09:20 <clever> yeah, id just make it its own os, and boot it using something like multiboot maybe
11:09:50 <heat> poweroff is hard, if you don't want to mess with really crappy hardware stuff it's impossible to do
11:10:13 <heat> I'm assuming you want to do something that doesn't involve writing a kernel and boot an OS
11:10:28 <geist> bees!
11:10:42 <clever> for basic stuff, you could just use a grub module
11:10:57 <clever> https://wiki.osdev.org/Writing_GRUB_Modules
11:10:58 <bslsk05> wiki.osdev.org: Writing GRUB Modules - OSDev Wiki
11:11:09 <clever> then you would be able to leverage all of grubs stdlib
11:13:50 <yasar> clever: do you mean that grub will provide a C library or something more?
11:14:22 <clever> yasar: not sure what all grub provides, but it has memory allocation, fs and block drivers, and some display/keyboard drivers
11:14:31 <clever> which would save a lot of work
11:15:04 <yasar> drivers sounds nice :)
11:16:48 <yasar> It is odd that poweroff is hard. Wouldn't BIOS provide such functionality?
11:17:17 <clever> yasar: the original machines bios was for lacked the ability to turn themselves off
11:17:36 <clever> yasar: https://i.kym-cdn.com/photos/images/original/001/286/950/e05.jpg
11:18:19 <yasar> flashback to childhood memories :)
11:18:38 <zid> why has that been like, superscaled
11:19:06 <clever> no idea, just grabbed the 1st one off a google image search
11:20:41 <Maka_Albarn> heat: can you double check my multiboot header?
11:20:43 <Maka_Albarn> git clone https://BringerOfShadows@bitbucket.org/BringerOfShadows/firststep.git
11:20:45 <bslsk05> bitbucket.org: BringerOfShadows / firstStep — Bitbucket
11:20:54 <Maka_Albarn> arch/i686/boot.s
11:22:40 <clever> yasar: https://github.com/coreos/grub/blob/2.02-coreos/grub-core/lib/i386/halt.c
11:22:41 <bslsk05> github.com: grub/halt.c at 2.02-coreos · coreos/grub · GitHub
11:23:11 <clever> yasar: far simpler when EFI is in play, https://github.com/coreos/grub/blob/2.02-coreos/grub-core/lib/efi/halt.c#L35
11:23:13 <bslsk05> github.com: grub/halt.c at 2.02-coreos · coreos/grub · GitHub
11:23:18 <Maka_Albarn> https://gist.github.com/MakaAlbarn001/76c7cd763bd6f6aef82d412ed7d7edac
11:23:20 <bslsk05> gist.github.com: boot.s · GitHub
11:24:09 <heat> Maka_Albarn: Man I don't remember how the header is layed out
11:24:10 <clever> yasar: https://github.com/coreos/grub/blob/2.02-coreos/grub-core/commands/halt.c and this creates a `halt` command in the grub repl (and config/menu) that just runs grub_halt() from one of the previous files
11:24:11 <bslsk05> github.com: grub/halt.c at 2.02-coreos · coreos/grub · GitHub
11:25:22 <heat> yasar: To turn off the BIOS you have to go through something really fucking stupid called "ACPI" for which you need a full bytecode interpreter in order to shutdown the machine
11:25:31 <heat> er, turn off the machine
11:26:49 <heat> So technically, the BIOS gives you the way to shutdown the machine, it's just given to you in a really stupid and complex way
11:27:06 <clever> heat: from skimming over the code i linked above, i dont think grub has support to shutdown via acpi
11:27:22 <clever> it appears to only support qemu and bochs
11:27:39 <heat> GRUB doesn't touch ACPI at all afaik
11:32:34 <clever> oh, i missed these 2 lines
11:32:35 <clever> #if defined (GRUB_MACHINE_COREBOOT) || defined (GRUB_MACHINE_MULTIBOOT) grub_acpi_halt ();
11:32:50 <clever> https://github.com/coreos/grub/blob/93fb3dac4ae7a97c080d51d951d0e5a3109aaac7/grub-core/commands/acpihalt.c#L389
11:32:52 <bslsk05> github.com: grub/acpihalt.c at 93fb3dac4ae7a97c080d51d951d0e5a3109aaac7 · coreos/grub · GitHub
11:34:24 <clever> heat: doesnt look like it handles any bytecode, its just looking for a given field
11:35:06 <clever> wait, line 110, opcode, dang acpi!
11:37:58 <yasar> Would ubuntu on virtualbox be a good choice as a development environment?
11:38:10 <zid> I'll work, I guess
11:38:16 <zid> (gentoo for life)
11:39:36 <heat> clever: holy crap the madmen did it
11:40:00 <heat> G R U B I S T O T A L L Y N O T B L O A T E D
11:40:18 <zid> 2 or 0.97?
11:40:19 <klange> grub is an OS with mediocre task execution
11:40:21 <heat> 2
11:40:25 <klange> both? 2 moreso
11:40:28 <zid> I've yet to use 2
11:40:38 <zid> it had xml in it so I laughed and kept on 0.97
11:40:51 <heat> grub3 will have json
11:40:55 <heat> just sayin
11:41:10 <zid> grub4 hopefully will have mongo and druple and ruby
11:41:29 <heat> grub5 will have asynchronous blockchain based booting
11:41:43 <heat> all written in Node.js™
11:42:06 <Maka_Albarn> can anyone check my multiboot info request tag? https://gist.github.com/MakaAlbarn001/76c7cd763bd6f6aef82d412ed7d7edac
11:42:06 <clever> i think somebody ported python to grub already
11:42:16 <clever> https://lwn.net/Articles/641244/
11:42:17 <bslsk05> lwn.net: Python without an operating system [LWN.net]
11:42:53 <yasar> Cross compiler docs states that "You need to use a cross-compiler unless you are developing on your own operating system."
11:43:03 <klange> To be fair, I ported Python to my OS and Grub likely has a much more complete C library in there.
11:43:13 <yasar> did anyone actually ported a compiler to his own OS?
11:43:17 <heat> I propose we get rid of computers
11:43:19 <zid> hundreds of times
11:43:19 <heat> yasar, lots of people
11:43:31 <zid> yasar: You won't actually need a cross compiler if your desktop is x86
11:43:43 <yasar> Interesting, I would assume it would be hard
11:43:45 <zid> because you won't need to re-tool it away from linux you can just use linux's defaults as yours
11:43:55 <heat> Personally, my gcc is kinda broken so the best it can do is output assembly, the assembler + ld work fine
11:43:57 <klange> We highly recommend cross-compilers for various reasons, but "need" is hyperbole.
11:45:01 <zid> Unless you're using stuff other than ELF, cdecl, 16 byte stack alignment etc, you can just use your system's gcc
11:45:19 <yasar> Do you guys also write your own C library? For example, glibc's malloc uses mmap or sbrk, but what if your OS doesn't have those syscalls?
11:45:36 <heat> ^^ yes, yes and yes
11:45:50 <heat> but sbrk sucks though
11:45:51 <zid> I just spent the past few days designing half of mmap :P
11:46:00 <zid> I don't ahve the sbrk part of it (I can't give it NULL)
11:46:14 <heat> that's not sbrk
11:46:21 <zid> sort of is tho
11:46:21 <heat> that's basic virtual address space allocation
11:46:23 <clever> linux doesnt have an sbrk syscall, only brk
11:46:36 <clever> sbrk is a glibc helper, that uses some global vars in userland
11:46:42 <heat> brk is a base data segment + incrementing
11:46:46 <heat> clever, yes
11:47:10 <zid> I haven't even begun to think about virtual address management, sigh
11:47:16 <heat> mine is a bit broken
11:47:25 <heat> because I can't write self-balancing binary trees for shit
11:48:07 <zid> plus at that level you're still not past the whole catch-22 of needing virtual addresses to meddle with the physical addresses responsible for the virtual addresses, so you can't just write it normally
11:48:29 <heat> what catch-22?
11:48:34 <zid> the one described
11:48:42 <clever> heat: that reminds me, i deleted a lot of data on a zfs volume, that was using dedup, which i believe is a binary tree/hashtable (not entirely sure)
11:48:46 <heat> dunno what that one is
11:48:52 <clever> heat: but the memory usage for the table hasnt changed at all
11:48:57 <geist> then either you side stepped it or you havent hit it yet
11:49:06 <clever> and on avg, each entry now uses more ram!
11:49:14 <clever> heat: i have a feeling zfs is also lacking the ability to self-balance its binary tree
11:49:17 <heat> I'm really not seeing what the problem is
11:49:34 <zid> heat: I want to add a node to my tree that tracks virtual memory, for example.
11:49:36 <geist> heat: needing virtual memory to touch physical memory to modify page tables
11:49:46 <zid> I allocate some vir- oh wait that's an infinite loop
11:50:01 <heat> welcome to x86-64
11:50:08 <zid> why are you telling US
11:50:08 <heat> where you can map everything and not give a shit
11:50:09 <zid> welcome
11:50:15 <zid> you're the one who said you didn't understand it
11:50:16 <geist> nah, it's a problem on every architecture
11:50:31 <geist> solvable in different ways depending on the arch
11:50:39 <geist> but that's the catch-22
11:50:45 <zid> massive amounts of cop-outs and cheating is my approach so far
11:50:52 <zid> like heat appears to be advocating
11:50:53 <heat> zid: i wasn't understanding what you're trying to say
11:51:03 <heat> it's not cheating if linux does it
11:51:05 <geist> yay cop outs and cheating!
11:51:06 <zid> kek
11:51:17 <geist> nah, it's all about compromises and design decisions with different tradeoffs
11:51:33 <geist> depednding on your point of view many of these things can be either cop outs or cheating or clever
11:51:37 <zid> It'd be nice if there were a special 'access phyical memory' opcode or something
11:51:55 <heat> it would probably be hella expensive to do
11:51:55 <zid> if I had a single u64 write gadget opcode that took 100 cycles or whatever and did that it'd be solved with no need for mess
11:52:36 <heat> also, x86 doesn't need more instructions
11:52:43 <zid> one more prefix can't hurt
11:53:10 <zid> 0x66 rep lock phys mov [rsi], 0
11:53:44 <heat> that would be slow, complex and you couldn't properly control caching
11:53:53 <heat> and a possible security issue
11:53:56 <geist> even better: access via an alternate PCID
11:54:06 <geist> some architectures have something like this, i believe ultrasparc does
11:54:30 <geist> and then you can just leave a set of page tables that identity map physical, and access via that
11:54:45 <geist> that way you still get protection and whatnot if you want
11:54:49 <zid> yea, leaving those just laying around is a security issue these days
11:54:55 <heat> or
11:55:10 <geist> indeed. though about as bad as having a Big Ass MAp in the kernel
11:55:20 <heat> you use the APs to do dirty work for you while the BSP just sends messages to cpus
11:55:26 <lachlan_s> Bit Ass Map?
11:55:31 <lachlan_s> s/Bit/Big
11:55:37 <geist> Big Ass Memory Map
11:55:41 <geist> BAMM
11:55:55 <heat> AP0 for touching physical memory, AP1 for doing real mode crap, AP2 to kill bees, etc
11:56:05 <geist> or Big Ass Physical Map maybe
11:56:07 <geist> BAPM
11:56:18 <lachlan_s> Nah, bamm is better
11:56:21 <geist> yah
11:56:34 <heat> personally I quite like EL TORITO
11:56:46 <lachlan_s> What's it for?
11:56:48 <geist> EL TORITO!!! BAMM!
11:56:56 <zid> dipping into salsa
11:57:05 <lachlan_s> thanks
11:57:11 <klange> Ｅ Ｌ Ｔ Ｏ Ｒ Ｉ Ｔ Ｏ
11:57:15 <geist> lachlan_s: it is a strategy for addressing physical memory from the kernel, basically map a sizeable chunk of it, if not all of it, using large pages preferably
11:57:31 <geist> that way you can easily do a void *phys_to_virt(uint64_t phys_addr);
11:57:42 <zid> I did mine using 4k cus I am lazy as fuck
11:57:50 <zid> that was my 'disregard security' copout
11:57:51 <heat> oh my lord
11:57:51 <lachlan_s> Ah, I see
11:57:54 <geist> it's a very convient solution, much more doable on 64bit
11:58:23 <klange> yasar: my old OS had a GCC and binutils port https://i.imgur.com/c1zdN5q.png
11:58:23 <geist> so you do a simplicity/speed tradeoff for security (since having a BAMM in the kernel is a little dangerous)
11:58:42 <heat> geist: is it though?
11:58:43 <bcos_> To make it truly awesome, you need 3rd party modules running in kernel space, so that "trivial access to everything in RAM whether it's needed or not" can reach the peak of security disasters... ;-)
11:58:54 <geist> correct. note this is what linux does
11:59:32 <geist> the alternative is usually some sort of mechanism where you can do a get_phys_page/put_phys_page api where you map/unmap into some chunk of kernel space
11:59:45 <geist> preferably with some sort of LRU mapping so that frequently used things stay mapped
11:59:48 <klange> bcos_: obviously the real reason to go NIH - security :)