klange changed the topic of #osdev to: Operating System Development || Don't ask to ask---just ask! || For 3+ LoC, use a pastebin (for example https://gist.github.com/) || Stats + Old logs: http://osdev-logs.qzx.com New Logs: https://libera.irclog.whitequark.org/osdev || Visit https://wiki.osdev.org and https://forum.osdev.org || Books: https://wiki.osdev.org/Books
redrew has left #osdev [#osdev]
elastic_dog has quit [Ping timeout: 248 seconds]
elastic_dog has joined #osdev
kingoffrance has joined #osdev
nyah has quit [Ping timeout: 276 seconds]
gog has quit [Ping timeout: 276 seconds]
Likorn has quit [Quit: WeeChat 3.4.1]
Matt|home has joined #osdev
Ali_A has quit [Quit: Connection closed]
hbag has joined #osdev
heat_ has joined #osdev
heat has quit [Ping timeout: 240 seconds]
mahmutov has quit [Ping timeout: 272 seconds]
heat_ has quit [Read error: Connection reset by peer]
heat has joined #osdev
lainon has quit [Ping timeout: 246 seconds]
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
zaquest has quit [Remote host closed the connection]
zaquest has joined #osdev
heat has quit [Ping timeout: 240 seconds]
sonny has joined #osdev
sonny has quit [Remote host closed the connection]
srjek has quit [Ping timeout: 240 seconds]
k8yun has joined #osdev
kingoffrance has quit [Ping timeout: 250 seconds]
<kazinsal> "virtio-scsi: Improvements" thanks, virtualbox changelog.
bradd has joined #osdev
Likorn has joined #osdev
h4zel has quit [Read error: Connection reset by peer]
<zid> unifont is what my OS uses
<zid> It looks nice enough
<moon-child> unifont is as ugly as you
<zid> It's pirated though because I deleted all the licencing
<psykose> i don't think deleting some licence files of open source fonts counts as piracy
<moon-child> it does if those license files say you're not allowed to delete them
<psykose> people read those? weird
<zid> it's precisely what it means :P
<klys> so what's the unicode sequence for adding an arbitrary glyph cookie to the local font?
<zid> It's per impl
<moon-child> lmao
<zid> apple POWER bug
<bslsk05> ​www.w3.org: Color — SVG 2
<bslsk05> ​www.w3.org: Removed: Color — SVG 2
Likorn has quit [Quit: WeeChat 3.4.1]
k8yun has quit [Quit: Leaving]
<geist> hmm, think i finally kinda grok the trait class stuff that some folks were using in the fuchsia inclusive template container classes
<geist> basically had to plow through it in godbolt to figure out how it works together
Ali_A has joined #osdev
scoobydoo has quit [Ping timeout: 240 seconds]
Ali_A is now known as Aragami
the_lanetly_052 has quit [Remote host closed the connection]
<Aragami> so, I wanna write UEFI applications, I am reading the spec (however it is 2.5K pages) I am not sure which parts are relevant? my aim is two things, 1- I write a bootloader from my x64 kernel. 2- write a small UEFI application game (I was inspired by someone who wrote a game in the boot sector, so I wanted to do the same), however I am not sure what
<Aragami> is `gnu uefi` , `gnu-uefi reduced`, `tainocore` ? I supposed that UEFI is something in the motherboard, within the hardware itself, so why do I need gnu or something else? (yes, the headers, sure but I don't understand that each one of those mean)
<geist> you dont. you can do it manually if you want
<geist> the gnu uefi stuff is just an existing library for you so you dont have to type in a bunch of stuff
<geist> think of it as just a library and some build system stuff to get you to a uefi main without needing to set it up for you
<Aragami> geist great, so where can I read about doing it without all of this extra stuff?
<geist> what extra stuff are you talking about specifically?
<Aragami> I understood from your message that I don't need gnu/gnu-reduced uefi or taino core as they are just wrappes, to simply the development process.
<geist> right
<Aragami> to simplify* the development process
<geist> right
<Aragami> right, so I asked where can I read about booting/writing an application without using those (those refer to gnu-reduce/tainocore etc) because every single web-page I found online used them
<geist> you mean you dont want to use them but you awnt to start from a completely blank slate?
<geist> (just to be precisely clear what your'e tasking)
<geist> asking
<kazinsal> I'm guessing they mean they want to just make UEFI calls etc from C without needing the whole smattering of gnu-efi libraries etc
<geist> yah agreed, just want to make sure
<Aragami> yes, assuming I can get to that with less than 500 LOC then I am up for it
<geist> there's a bunch of refedfence to 'i dont want this extra stuff' but in reality theres a *lot* more extra stuff if you go in clean slate
<geist> since you now have to build up the EFI environment from scratch
<geist> you can probably get a Uefi Main in 10 lines of code, maybe 50 lines of build system, and some toolchain work (need a toolchain that can generate PE binaries, etc)
<geist> but then you'll immediately n eed to start building up an infrastructure to communicate with the uefi hooks to do anything
<geist> not that bad, but basically the manual you have is everything: it defines the C functions, all the UUIDs you need to query, all the interfaces you need to implement
<geist> and part of the reason it's 2.5k pages is there's a lot of it
<geist> i personally dont really like the GNU EFI stuff really, but it does bootstrap you ahead a lot, because basically someone else has typed in a bunch of stuff you'll have to just type in yourself
<geist> i haven't done it from scratchmyself though, so i think someone like klange may have better advise
<Aragami> I just usually like to understand something but building it in a crappy code, then just use the `existing libraries`
<Aragami> by building* in a crappy from scratch code*
<kazinsal> ironically gnu-efi is kind of the lightweight option for UEFI application support
<kazinsal> EDK2 is a complex nightmare
<Aragami> I thought `gnu-reduced` was supposed to be the `lightweight` inferred from the name, I don't know what goes in there.
<geist> yeah, gnu-efi is not terribly bad per se. we had a project for fuchsia called gigaboot20x6 that used to exist in a standalone form
<geist> that was more or less what you seek, or an example of it
<geist> but it has since been subsumed into the fuchsia tree and hard to tease apart
<kazinsal> reduced-gnu-efi is a third party fork iirc
<geist> i really can't use it because GNU, so when i finally do get around to doing this i'll probably end up typing in a bunch of crap
<geist> but not really because i want to
<kazinsal> yeah I have no idea what license gnu-efi is under
<kazinsal> I would assume like LGPL or something
<geist> possibly, yeah. i know we didn't use it at work precisely because of that
<geist> so the author of gigaboot just typed in all the headers again we needed
<Aragami> Well, I guess that I means I must start reading the spec (I need a documentation for the documentation)
<geist> but it wans;lt a *lot* of work
<geist> just a lot of tedious stuff
<geist> Aragami: suggestion: start with gnu-uefi or whatnot and get things going
<geist> and then if you want remove it later
<Aragami> good suggestion actually,
<geist> it's really not a good use of your time just typing in all that stuff so you can get to hello world. that's ag reat way to get super discouraged
<geist> because then you dont get anything working until a long ways in. if you were already experienced in it it'd be one thing
<geist> but if you're just getting started, you really need to get your bearings in the landscape, so using an existing framework that helps you is really not a bad idea
<Aragami> the problem is I am terrible with gnu system, and whenever I see the name gnu, I get terrified, that I will have to use the `gnu echo system`
<geist> at the end of the day it's still you and UEFI apis. i think all the gnu-efi stuff does is provide a lot of headers and the build system magic to drive the compiler
<geist> which is frankly the least interesting and most tediuos part of it
<geist> but again, i dont really know the specifics
<kazinsal> yeah, it's really the skeleton
<Aragami> sure, thanks for the advice, I will follow it, let's see how can I get a simple UEFI app using gnu efi
<geist> yah play with that and then see if you want to rip it out after using it
<Aragami> (y)  thanks guys!
<kazinsal> yep. get something working and booting first so you get used to how to build for UEFI
<geist> may turn out it doesn't really help you much and once you have something working it's easier to remove it piece at a time until you're left with just your stuff
<geist> exactly
<kazinsal> then yank whatever you don't want
<kazinsal> interesting. it looks like gnu-efi might not actually be a GNU project
<kazinsal> its homepage is just a sourceforge project
<zid> the gnu- didn't give it away?
<zid> oh might *not* be
<zid> reading comprehension is hard
<kazinsal> license appears to be BSD-like and attributes a 1998-2000 copyright to Intel
<geist> yah honeslty https://wiki.osdev.org/GNU-EFI looks pretty useful to me
<bslsk05> ​wiki.osdev.org: GNU-EFI - OSDev Wiki
<kazinsal> yeah, might poke at that next time I feel inspired to do a UEFI
<geist> and if the license is BSD like then sounds like a win-win
<kazinsal> some of the specifics of that page concern me a bit like using your host system's native compiler but I bet you could substitute in x86_64-elf-* and it'd probably work fine with a bit of tweaking
bauen1 has joined #osdev
pretty_dumm_guy has joined #osdev
_xor has quit [Quit: WeeChat 3.4.1]
Vercas has quit [Remote host closed the connection]
Vercas has joined #osdev
sortie has quit [Ping timeout: 276 seconds]
<geist> yah
Belxjander has joined #osdev
<geist> it at least acknolwedges it
sortie has joined #osdev
duckworld has joined #osdev
duckworld has quit [Client Quit]
duckworld has joined #osdev
vimal has joined #osdev
GeDaMo has joined #osdev
Aragami has quit [Quit: Connection closed]
Burgundy has joined #osdev
gog has joined #osdev
pretty_dumm_guy has quit [Quit: WeeChat 3.5]
pretty_dumm_guy has joined #osdev
<corecode> hi, i guess this is a bit OT here, still trying. For an embedded application I'm wondering about using a simple protocol on top of ethernet for enumerating and addressing nodes. ip/ip4 + udp + mdns is a bit heavy
<gog> there's DHCP/BOOTP
<corecode> yea, still IP etc tho
<gog> true
<corecode> i don't need routing
<gog> i guess use case matters most
<gog> there are benefits to having at least a partial IP stack
<corecode> i agree, but i'm trying to do this on fpga without a soft core
<zid> I mean, if what you wanna do is simple, and it won't sprawl to being "ip but I made it badly" then go for it imo
<zid> ip is the easy bit though tbh
<zid> It's just version, length, dest, source, checksum, and protocol number that it's carrying, afaik
<zid> and arp is pretty braindead, someone sends "who has x" and they reply "I have x" and you write down the mac
<clever> and also because of its braindead nature, there is basically no context involved, and no way to know if you should block it in a firewall
<clever> so arp can also be used to detect if a machine is online, even if the firewall wants to block everything
gog has quit [Ping timeout: 250 seconds]
gog has joined #osdev
bauen1 has quit [Ping timeout: 250 seconds]
bauen1 has joined #osdev
nyah has joined #osdev
<corecode> yea but then i need to assign IPs
pretty_dumm_guy has quit [Ping timeout: 276 seconds]
Vercas has quit [Remote host closed the connection]
Vercas has joined #osdev
pretty_dumm_guy has joined #osdev
<zid> well you need to assign some kind of address
<corecode> yes, i was hoping for some long unique ID i could use
PapaFrog has quit [Read error: Connection reset by peer]
LostFrog has joined #osdev
<zid> they're called mac addresses
<zid> and the routing of traffic between them is the ethernet layer
<zid> honestly ip is sorta busted we could have just used mac addresses all over
<zid> but it evolved from other systems in weird ways
XgF has quit [Ping timeout: 260 seconds]
XgF has joined #osdev
<clever> zid: and do you want to manage a global routing table based on macs?
<clever> IP and BGP mostly solve that problem
dennis95 has joined #osdev
heat has joined #osdev
Vercas has quit [Remote host closed the connection]
<corecode> yea i think i'll have to generate local MACs from some unique ID
Vercas has joined #osdev
<corecode> the FPGA doesn't have a mac address, because it isn't a MAC
<corecode> i mean, i make it into a MAC
gwizon has joined #osdev
<heat> corecode, ip isn't that big
<heat> like, at all
<heat> ip + udp is like the simplest thing you can have
<heat> 1) why would you need mdns?
<heat> if you're already getting into a spot where "oh yeah I need mdns" then doing it all in fpga might not be the best idea
<corecode> for enumeration
<corecode> i guess i could run a dhcp server on my custom server side
<heat> i feel like you're trying to do too much in FPGA
<corecode> but it just feels like a network protocol is not what is needed in this case, because it doesn't have to be routed
<heat> what are you trying to do exactly?
<corecode> there is a set of devices that will be connected via ethernet, and a central source (running linux) needs to detect their presence and then send data to them
<clever> ive had plans for the same thing in the past, and wanted to use mdns/avahi to solve it
<clever> plus dhcp
<clever> but i didnt look into the mac addr issue
<corecode> yea if the things already run a system that supports these protocols, sure
<corecode> but i wonder, is there a simpler way
<corecode> for now i'll assume that i have some unique ID stashed somewhere
<heat> you can run a budget mdns
<corecode> and that i can manufacture a unique mac address
<corecode> yea, but why go through IP + UDP + mDNS (which is multicast)
<heat> ethernet broadcast discovery packets every X seconds, clients need to reply with their unique id and ethernet address
<corecode> heat: yea exactly
<corecode> that's why i was wondering, is there an existing protocol
srjek has joined #osdev
<heat> no i don't think so
<corecode> there are some ieee 802 link layer things
<corecode> LLDP i think?
<heat> everything's done on top of ip usually
<heat> corecode, hmm that looks possible yes
<heat> then again, you don't care about interoperability
<heat> so you might save yourself some sanity if you don't go down that route
<corecode> yes
<corecode> but often other people have already addressed corner cases that i don't want to painfully figure out later
<corecode> so at least checking what other things do is required
Likorn has joined #osdev
Likorn has quit [Client Quit]
gwizon has quit [Quit: leaving]
Starfoxxes has quit [Remote host closed the connection]
vdamewood has joined #osdev
<mrvn> Check out the network console on linux. I think that is ethernet and not IP. Might be reusable for you.
Ali_A has joined #osdev
<mrvn> Who still has a 32bit time_t?
dude12312414 has joined #osdev
<heat> most 4.x linux 32-bit targets
jjuran has quit [Ping timeout: 256 seconds]
jjuran has joined #osdev
<mrvn> "this time I assure you no good will be done with the money"
pretty_d1 has joined #osdev
pretty_d1 has quit [Client Quit]
pretty_dumm_guy has quit [Ping timeout: 250 seconds]
Piraty has quit [Quit: -]
Piraty has joined #osdev
Vercas has quit [Quit: buh bye]
Vercas has joined #osdev
Likorn has joined #osdev
kingoffrance has joined #osdev
dennis95 has quit [Quit: Leaving]
knusbaum has quit [Quit: ZNC 1.8.2 - https://znc.in]
knusbaum has joined #osdev
<hbag> trying to format a floppy disk as atari st 720k but not having much luck so far
<hbag> so i can read and write to it on my pc and my atari ST
<GeDaMo> What problems are you encountering?
<hbag> when i try and format the disk on windows, i get "windows is unable to format this disk"
<hbag> can't read it either
<heat> which windows?
<hbag> 10
<heat> i wouldn't be surprised if windows 11 couldn't mount atari floppies :v
<bslsk05> ​www-user.tu-chemnitz.de: Atari Floppy Format
<GeDaMo> "floppies formatted on early Atari machines can't be read on PCs but floppies created on PC can be read on Atari"
<hbag> ah
<hbag> im using an atari 520STFM
<GeDaMo> I don't know what the formatting options are on Windows
<GeDaMo> Is there a command line format program?
<hbag> well afaik ST 720K is identical to FAT12
<bslsk05> ​www.atari-forum.com: 720k Floppies with Windows 10 and a USB Floppy drive. - Atari-Forum
<hbag> aaaaaand now my USB floppy drive isnt even showing up when i plug it in
<hbag> this operating system owns
Ali_A has quit [Quit: Connection closed]
mahmutov has joined #osdev
<hbag> formatting this thing is taking a while im unsure if its actually doing anything lol
Ram-Z has quit [Ping timeout: 240 seconds]
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
<hbag> should i be leaving the HD hole uncovered while it formats? i have no idea
srjek has quit [Ping timeout: 240 seconds]
<hbag> ah
<geist> well first i'd double check that the low level format is compatible with PC 720k
<hbag> ?
<geist> there's also some general issue with using HD disk drives to format 720k floppies. also using HD disks in 720k mode
<geist> sometimes that works, sometimes it doesn't
<geist> (on PCs at least)
<geist> then there's the second issue that i thin kthe atari FAT is subtly different from DOS/windows FAT
<geist> maybe in incompatible ways?
<geist> but yeah that link up there seems pretty good
<hbag> idk, that atari forum link says it should work fine as long as my drive is able to format like that
<geist> right, trouble with the USB based floppy drives is i think they only understand a very narrow set of things
<geist> i've got one too and have had mixed success for this sort of thing
<geist> are you using an older 720k disk or a HD one?
<geist> that's also an issue i've bumped into. the smaller head of the HD (1.44) drives writes out a little bit 'less' data because it has to fit it in tighter, and sometimes 720k drives can't read that
<hbag> i only got HD disks laying around
<geist> also similar, i think HD disks have a different amount of flux or whatnot
<jimbzy> Hallo
<geist> hola jimbzy
<jimbzy> What's the good word in your neck of the woods?
<GeDaMo> Why do woods have a neck? :|
<jimbzy> Why don't you have one, GeDaMo?
<jimbzy> ;)
<GeDaMo> I'm not a woods as far as I know :|
<jimbzy> :|
<jimbzy> If a woods had a neck it would probably be their roots.
<geist> well, it stopped being quite as cold and rainy for a bit
<bslsk05> ​en.wiktionary.org: neck of the woods - Wiktionary
<kingoffrance> old windows (perhaps xp) at least, can corrupt floppies and then complain the disk is unreadable. write protect them if disks are from elsewhere :)
<kingoffrance> or they can silently quietly trash things
<geist> yah re: low level formatting, i think a proper PC has more control of what happens if it has a real floppy conroller chip and a floppy drive. i think the USB based ones it's up to whatever the microcontroller in the drive does
<geist> so i think windows has far less options
Starfoxxes has joined #osdev
<GeDaMo> Can you try formatting it from Linux?
<geist> but thats independent of the FAT format, which i think has deviated a bit with atari, amiga, etc. probably just because they forked off an early version of the FAT FS in the 80s and then went in slightly different directions
<geist> i can absolutely see the dos/windows fat driver not giving a shit about any sort of compatibility. it most likely assumes there is One True FAT and has no interest in trying to play nice with any other variants
<kingoffrance> i may be misremembering, i seem to recall usb floppy i could use differently depending on: 1) plugged in at boot, hence "usb emulation" versus plugged in later, but this would vary with hardware/bios/windows versions too....
<kingoffrance> *versus 2)
<kingoffrance> and i dont know modern stuff if it would even try that
<geist> yah i'm actually kinda curious now precisely what the usb floppy protocol is. it seems to be standard enough
<geist> my guess is when it comes to whatever the FORMAT command is it probably just takes an enum of disk type
<geist> instead of something lower level like precise layout of the sectors
<geist> all this aside if you have any floppy disks or want to work with one, i suggest picking up one of these usb floppy things. they're cheap and i dunno if they'll be on sale forever
<heat> geist, wouldn't it be the mass storage protocol?
<geist> possibly? dunno precisely how FORMAT would work in this case, but i guess scsi is sufficient to describe it
<geist> but as kingoffrance was sayign i think there may be a simpler, boot time variant of it
<heat> i bet that would depend on the BIOS to SMI the shit out of legacy floppy accesses
<heat> like it happens for USB keyboards and mice
<gog> fairly sure that it works like that, and that it's all translated to scsi-like commands for the mass storage protocol
pretty_dumm_guy has joined #osdev
<gog> but what im reading is that most USB floppies can't format 720k
<gog> they can read and write it fine, but are not equipped to format them ?
<gog> idk seems weird
<heat> btw I found out how linux invalidates routes
<heat> they just keep a counter
<heat> when something changes, they increment it. every route cached has the current counter at the time it got looked up. before using it, they check if its up to date
<heat> geniusly simple mechanism
<sham1> gog: I don't see how that would even happen. Formatting should just be writing should it not?
<gog> sham1: i was mistaken, it was that attempting to write a 720k image to a 1440k floppy on a USB drive is likely to fail but apparently there's a way to do it
<gog> and also that most USB floppies support 720k mode
<heat> what's better? have a single API with a bit more complexity or two simpler APIs
<heat> i'm rethinking my network configuration API and I need a way to pass both AF_INET and AF_INET6 addresses
<heat> a struct sockaddr would work but that makes the API worse (variable struct sizes, and sockaddr is just worse to work with overall vs raw address types)
mahmutov has quit [Ping timeout: 276 seconds]
mahmutov has joined #osdev
GeDaMo has quit [Remote host closed the connection]
<mrvn> gog: The 1.44 floppy head has a thinner track so it formats the middle of the magnetic strip but not the sides.
<heat> https://gist.github.com/heatd/72b338f3e86e32c1dab40445ec17e150 <-- if anyone wants to give feedback
<bslsk05> ​gist.github.com: gist:72b338f3e86e32c1dab40445ec17e150 · GitHub
<mrvn> heat: C or c++? I would suggest returning the sockaddr. Allocation isn't that costly.
<heat> i think it looks super usable but i'm biased :)
<heat> mrvn, this is supposed to be C compatible over a socket interface (send())
<heat> a-la AF_ROUTE or AF_NETLINK
<mrvn> heat: those defines are so last milennium, use an enum
<heat> to submit a request you fill hdr.msg_type with i.e NETKERNEL_MSG_ADD_ROUTE, and then you fill out the rest of the structure
elastic_dog has quit [Ping timeout: 260 seconds]
<heat> it's also a SOCK_STREAM socket so userspace can easily get the results back
<mrvn> why not an add and del syscall?
<heat> why a syscall?
<mrvn> because everything else uses syscalls
<heat> these are traditionally either ioctls or structs over a pseudo AF_
<mrvn> Or do you have a FS descriptor where you send fskernel_hdr r_hdr.msg_type = READDIR?
<mrvn> traditionally it's also using a struct sockaddr so that is no argument.
<heat> I like the AF_ route because I can just have SOCK_STREAM semantics and take the input bit by bit, no need to do realloc loops, etc
elastic_dog has joined #osdev
<heat> netkernel is supposed to be a socket to generic kernel stuff, not just networking (totally stolen from linux's netlink)
<heat> adding syscalls is something I don't want to do willy-nilly
<mrvn> Any idea WHY the interface is socket based?
<heat> it's substancially better than the ioctls that involve a freaking alloc - ioctl - see if it fit loop
<mrvn> yeah, ioctl is horrible too, But aren't the network stuff simple syscalls?
<mrvn> +why
<heat> but this isn't like "main" syscall material IMO
<heat> how many programs manipulate routing tables?
<mrvn> how many programs set the system clock?
<heat> fair. why not do it in a socket then?
<mrvn> maybe it's their way of doing generic progrmming because sockaddr can be anything.
<heat> connect("clock.monotonic")
<heat> send({.new_time = now()})
<mrvn> I always found the network stuff inconsistent with half being syscalls and half socket based.
<heat> (in this case: because setting the time doesn't need much of an interface, it's a plain clockid + timespec)
<heat> also useful: you can get information back from the system
<heat> bind("routing_notifs"); while(recv(...) to listen for routing table changes
<heat> also pollable
<mrvn> yeah, the polling bit makes sense.
<mrvn> so why didn't they use it for e.g. inotify too?
gog has quit [Ping timeout: 276 seconds]
<heat> i don't know
<heat> consistency?
<heat> historically file things are in syscalls, and net things are in pseudo-socket things
<heat> just like tty things are in ioctls
pretty_d1 has joined #osdev
pretty_dumm_guy has quit [Ping timeout: 272 seconds]
wolfshappen has quit [Ping timeout: 260 seconds]
wolfshappen has joined #osdev
wolfshappen has quit [Read error: Connection reset by peer]
gog has joined #osdev
RAMIII has joined #osdev
RAMIII has quit [Changing host]
Ram-Z has joined #osdev
srjek has joined #osdev
dude12312414 has joined #osdev
dude12312414 has quit [Remote host closed the connection]
Burgundy has quit [Ping timeout: 250 seconds]
sonny has joined #osdev
bradd has quit [Ping timeout: 276 seconds]
bradd has joined #osdev
sonny has left #osdev [#osdev]
bradd has quit [Quit: No Ping reply in 180 seconds.]
bradd has joined #osdev
<Clockface> being an x86 programmer is garunteed SSE(x)
<geist> cute
<Clockface> if they ever extend SSE somehow, i hope its called SSE-X
<Clockface> petition AMD and intel
<Clockface> that would be fun
<Clockface> well
<heat> nah
<heat> SSE2, SSE3, SSE4
<heat> also SSSE3
<Clockface> reffering to all of them, SSEX is technically correct then
<Clockface> since version number is an unknown value in that context
<Clockface> : - )
<heat> SSEN :)
<gog> i don't like simd instructions, you could say i'm assexual
Celelibi has quit [Read error: Connection reset by peer]
zaquest has quit [Remote host closed the connection]
Celelibi has joined #osdev
pretty_dumm_guy has joined #osdev
pretty_d1 has quit [Ping timeout: 256 seconds]
zaquest has joined #osdev