ElectronApps has quit [Remote host closed the connection]
nyah has quit [Quit: leaving]
koolazer has quit [Remote host closed the connection]
gog has quit [Quit: byee]
<Clockface>
oh no
<Clockface>
the modR/M byte sometimes specifies more than one instruction per opcode because YES
<Clockface>
im glad im only doing an 8086, it sound annoying
<Clockface>
according to its wikipedia page at least
<Clockface>
i havent seen anything doing that for the 8086 though, so its mainly in newer x86?
teroshan has joined #osdev
dude12312414 has joined #osdev
Belxjander has quit [Ping timeout: 250 seconds]
<Mutabah>
Oh, you mean the different addressing modes?
<Mutabah>
those are present in 8086
<Griwes>
mkay, I *need* a DSL for defining syscalls that'll compile down to all the common boilerplate, or I'll go insane (even working with just the first syscall - I can already see the pain of replicating what I'm doing in mailbox_read for mailbox_write, which is the next one I'll need)
ss4 has joined #osdev
wootehfoot has quit [Ping timeout: 240 seconds]
<Clockface>
nah, i meant i noticed that in some cases the "argument" to an opcode can alter the operation it does
<Clockface>
as in, more than one instruction to an opcode
pretty_dumm_guy has quit [Quit: WeeChat 3.4]
Lugar has quit [Quit: Bye]
DanDan has quit [Read error: Connection reset by peer]
Geertiebear has quit [Ping timeout: 240 seconds]
lanodan has quit [Ping timeout: 240 seconds]
lanodan has joined #osdev
masoudd has joined #osdev
<Mutabah>
Ah
k8yun has quit [Quit: Leaving]
<Mutabah>
yeah, the second register in modr/m can add more opcode bits
k8yun has joined #osdev
masoudd_ has joined #osdev
masoudd has quit [Ping timeout: 240 seconds]
Affliction has quit [Quit: Read error: Connection reset by beer]
Affliction has joined #osdev
<geist>
yah not sure how feasible it is to implement an x86 decoder as a series of jumptables for reasons like that
<geist>
vs a more brute force nested set of ifs/switch statements
<zid>
it doesn't handle override bytes well
<geist>
that too
<zid>
which are easy peasy otherwise, you just handle some flags like {base = ds; if(override_es) base = es; }
<geist>
i never looked into if there are any rules about preciseky hat happens if you get conficting prefixes, etc
<geist>
or if there really are any rules other than whatever the implementation does with it
<zid>
I think at least, the *same* prefix over and over is allowed
<zid>
Not sure what happens with different ones, UD or it takes last given only or what
<geist>
yah i can see a modern decoder looking at a series of bytes in parallel and just basically filling in a bitmask of what its seen
<geist>
and then a parallel test for invalid combinations of it
<zid>
but at the same time you can also see it just parsing them in order in the 90s and it just updating the flags like the code above
<geist>
that would handle no problem seeing multiple instances of the same thing
<zid>
and that becoming the documented behavior
<geist>
yah original imeplementatio would have done that indeed
<zid>
buut if (override_es && base != ds) UD(); is pretty easy to do
<zid>
i.e only allow segment changes *from* ds
<zid>
buut given that this is actually just meant for emulating biosen, collecting a few up, implementing exactly what they need, then waiting for bug-reports from "error: missing opcode, please report" is acceptable imo :p
<geist>
yah the spec is either whatever themanual mentions or whatever it happens to do
<geist>
probablywith modern decoders that are looking at all the bytes in parallel, either last-one-wins or invalid-combinations-UD are about as easy to implement
<geist>
since either can be implemented as a series of look up tables or whatnot
masoudd_ is now known as masoudd
mahmutov has joined #osdev
<moon-child>
I think you definitely want a table-based approach. It is pretty regular (including the extra bits in modrm), and you can handle the special bits specially
<moon-child>
'rules about preciseky hat happens if you get conficting prefixes' that is the reason why _all_ the sw x86 decoders are dogshit, and every few years somebody does some differential testing and concludes that, yep, all the sw x86 decoders are still dogshit
<zid>
:D
<clever>
on the subject of sw decoding x86, what about caching the decoded form, or even the translated form?
<clever>
does qemu's tcg cache the generated code?
<clever>
and then use normal i-cache flush controls to manage destroying that?
<zid>
dynarec for x86 is actually a fun project
<clever>
the emu68 project does something very similar with its JIT
<clever>
translating blocks of 68k asm into aarch64 asm, stopping at any branch it cant predict
<clever>
and then those branches are a lookup into the cache, and an optional JIT for the next block of code
<clever>
and all of the performance counters (cache hit rate, cache size) are then exposed thru co-processor registers in 68k asm, so the guest can query the emulator directly, lol
<clever>
its very weird to give the guest such control over everything
Matt|home has quit [Ping timeout: 250 seconds]
[itchyjunk] has quit [Remote host closed the connection]
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
k8yun has quit [Quit: Leaving]
<geist>
clever: yeah i think it does that
<geist>
fun thing to run: -d in_asm,out_asm
<geist>
i think theres another one that prints the intermediate code
<geist>
it shows you as it finds blocks of code and what it spits out
<geist>
presumably icache flushes and whanot throw it away
mrkajetanp has quit [Ping timeout: 260 seconds]
<geist>
and potentially mmu context switches
mrkajetanp has joined #osdev
<zid>
god, I'm seriously considering writing an x86 to x86 jit
<zid>
(real to long)
<clever>
zid: i have compiled qemu-user-x86, to x86 before, lol
<geist>
dunno if ASIDs on various arches whatnot saves it from tossing decoded stuff
<clever>
and it actually helped solve a qemu bug
<zid>
yea but I wanna write it, it'd be fun
<clever>
in my case, the bug is that x86-64 in qemu tcg, defaults to the very oldest 64bit cpu, without sse2
<clever>
and the software in question needed sse2
<zid>
OoT on wii will eventually crash due to OOMing because the pruning logic for stale blocks has a bug in it, re dynarec bugs
<clever>
qemu-user had the same bug, but didnt require booting an entire os for each test
the_lanetly_052 has joined #osdev
k8yun has joined #osdev
xenos1984 has quit [Remote host closed the connection]
xenos1984 has joined #osdev
xenos1984 has quit [Remote host closed the connection]
xenos1984 has joined #osdev
<geist>
clever: interesting, there has to be some global way to set the emulated cpu model
<clever>
for qemu-system, you just pass the right -cpu flag, something about haswell
<clever>
and then it works fine
<clever>
for user, its a bit more tricky to have seperate qemu and target args
xenos1984 has quit [Remote host closed the connection]
xenos1984 has joined #osdev
<Griwes>
I just started writing the "compiler" for the syscall definition dsl, and I can already tell that it'll be such a hastily cobbled together thing that it'll basically need a full rewrite at some point in the future
<kingoffrance>
yeah, but does it make use of pragma?
* kingoffrance
ducks and covers
mahmutov has quit [Ping timeout: 256 seconds]
ThinkT510 has quit [Quit: WeeChat 3.4]
sdfgsdfg has joined #osdev
ThinkT510 has joined #osdev
<moon-child>
zid: pls comment on this code: char catstring = *strcat( "firstpart", *something );
mahmutov has joined #osdev
masoudd_ has joined #osdev
masoudd has quit [Ping timeout: 256 seconds]
k8yun has quit [Ping timeout: 256 seconds]
masoudd_ has quit [Remote host closed the connection]
masoudd has joined #osdev
mahmutov has quit [Ping timeout: 256 seconds]
the_lanetly_052 has quit [Remote host closed the connection]
nick64 has joined #osdev
sdfgsdfg has quit [Quit: ayo yoyo ayo yoyo hololo, hololo.]
<geist>
what could possibly go wrong?
GeDaMo has joined #osdev
marshmallow has quit [Remote host closed the connection]
<kazinsal>
reminds me, next time I get the urge to write some code I should put together a proper "string builder" to make pagination and output table alignment easier
<moon-child>
printf? :)
<zid>
\t and %16x work fine for mee
masoudd_ has joined #osdev
DanDan has joined #osdev
masoudd has quit [Killed (NickServ (GHOST command used by masoudd_))]
masoudd_ is now known as masoudd
<geist>
%-16x even
<geist>
actually, no %#-16x
<geist>
since %#16x has the annoying gap between the 0x and the digits if less than a full set
<moon-child>
I've memorised a lot of useless information, but I've managed to avoid knowing all the minutiae of printf format specifiers
<zid>
for the most part, same
<zid>
I had to look up that - was left justify
<zid>
That's something that's actually really hard to express in code, thinking about it
<moon-child>
i just know %s/%c/%[ul]d/%[u]f, %5s, %.5s, %*s
<moon-child>
maybe more i'm forgetting
<zid>
where you have operation AB or operation BA and you need to tell it to do one or the other
<zid>
you duplicate the code or make a HORRIBLE mess of jumps
<zid>
%zu I hope
<moon-child>
oh yea that too
<moon-child>
and %p
<moon-child>
and %hd
<zid>
no idea what hd is
<zid>
short?
<moon-child>
yeah
<moon-child>
h=half i think
<zid>
I guess I do have an idea then
<zid>
I'm a dirty liar
<GeDaMo>
I keep having to look up the macros for the fixed size types
<GeDaMo>
PRIu64 and the like
<moon-child>
zid: mainly I don't know the modifiers though
<moon-child>
- and # that geist is so expert in
<zid>
yea idk what # is without looking it up
<moon-child>
i think there's also a +
<GeDaMo>
"Alternative interpretation"
<GeDaMo>
(I looked it up)
<zid>
# is alternate form..
<zid>
+ is always sign
<zid>
0X? gross
<zid>
I prefer my mixed case thanks
<moon-child>
0xFF?
<zid>
yea
<moon-child>
meh i want all lowercase
<moon-child>
0xff
<zid>
#x then
Clockface has quit [Ping timeout: 240 seconds]
nature has joined #osdev
gog has joined #osdev
<nature>
Hi All, recently got started trying to learn a bit more about the basics of computers and OSes, and so now I am playing around and making some simple things in a bootloader like printing strings etc.. And now I want to print the available VGA modes so I already read the babystep tutorials and been also reading the articles mentionned in those babysteps, and notably Omarrx024/VESA's Tutorial. It's all very
<nature>
interesting! Thanks to the community for putting all this knowledge out there.
<gog>
as somebody who's been dabbling with this for about 10 years: this way lies madness :p
* vdamewood
gives gog a fishy.
* gog
chomps fishy
<vdamewood>
nature: Beware, there be dragons here.
<bslsk05>
'Guns N' Roses - Welcome To The Jungle' by GunsNRosesVEVO (00:04:39)
<gog>
welcome to the osdev, it gets worse here every day
<nature>
Thanks for the warm welcome! :D Looking forward to face off dragons, fishes and whatnot
<zid>
madness lies with trying to go down the VGA/vesa route :p
<nature>
Now my issue is that I've been simply trying to execute the BIOS "function" (if I can call it that) "Int 10/AX=0x4F00" but my structure which is pointed to by DI never gets anything filled, everything stays as 0. Although after the call AX=0x004F which supposedly indicates success. Also I should mention I am doing this in assembly (NASM).
* zid
guesses segment selectors
<GeDaMo>
Isn't it meant to be ES:DI?
<zid>
ES:DI->512-byte return buffer
<zid>
that's what google says, where do I collect my $200
<nature>
Also I am already quite far ahead on the road of madness, the goal of my playing around for now would be to create my own colorforth inspired OS :D
* gog
sends zid an IOU
<GeDaMo>
Monopoly money suit you? :P
<zid>
USD? sure
nick64 has quit [Quit: Connection closed for inactivity]
<nature>
hahaha, I am actually trying to reproduce the part from the tutorial where he first "push es" and then pop it
<gog>
also the tinkering with video stuff can be fun, you'll find that when/if you explore UEFI or non-PC platforms all of that knowledge becomes basically useless
<gog>
VESA/VBE anyway
<zid>
so anyway, if your buffer is in the same segment as your code, load cs and es with the same thing, same as your data load ds and es with the same thing, a diff segment put something new in es
<nature>
gog: What are other pathways to achieve graphics/screens?
<zid>
VBE is the main one
<nature>
zid: I am doing it all in the first 512 bytes of the bootloader
<zid>
and if you're in qemu/bochs there's a special bochs/qemu device that's basically just VBE but even simpler
<nature>
I am guessing it's all in the same segment then
<gog>
nature: with UEFI the GOP sets up the mode and a linear framebuffer for you
<zid>
nature: what do you have cs set to?
<gog>
i can't speak for other platfors
c2a1 has joined #osdev
<nature>
I didn't set cs, so it's default I guess
<zid>
that's a bug :P
<zid>
you're just lucky your bios isn't evil
<nature>
Sorry if I am asking dumb/newbs questions!
<zid>
no go for it
<gog>
yeah, the firmware is gonna probably load you up to 0000:7c00
<zid>
do you understand the address calculation real mode does, re segmentation?
<nature>
I used "org 0x7c00"
<zid>
okay so you're expecting cs to be 0
<zid>
it's probably worth explicitly setting it to 0 as the firstish operation
<gog>
most biosen will do that, but it's better to not assume too much there
<zid>
at least set ds and es to 0 after
<nature>
zid: I believe I understand enough to at least understand your explainations :p
<zid>
if nothing else
<zid>
address calc is seg*16 | offset, anyway, if you've left 'seg' to chance it could end you up anywhere
<zid>
You just need to pick an address for your 512 buffer to live at, and set up es and di so that it points there, anyway
<nature>
okok, yeah I read the segment page on the wiki a few days ago. so I should explicitely set es and cs as 0?
<c2a1>
What was the commodore 64 used for other than games
<zid>
and ds
<c2a1>
Was there an practical business software for it
orthoplex64 has quit [Ping timeout: 256 seconds]
<zid>
cs is *more* optional because relative jumps will take care of everything for you regardless
<gog>
c2a1: it had at least one spredsheet and word processor application
<gog>
perhaps several
<zid>
real mode memory map is a mess so don't trust me, but you could always just add 512 to 7c00 and stick it at 7e00
<zid>
and there are a few hundred es:di combinations that point to that address, but I imagine es = 0, di = 7e00 would be simplest :P
<gog>
there was more than one kit to turn a C64 into a point-of-sale system
<zid>
Most of us will be straining our memory to deal with real mode stuff, fwiw, but it'll just mean I have to spend 6 seconds googling some of this stuff before I talk
<gog>
keep it real (mode)
<nature>
zid: Ok, I did set ds to 0 before, I will try to continue wrapping my head around this with those new insights
<zid>
You need to do es too, that's the one your interrupt routine cares about
<nature>
Yep
<nature>
Ok setting es=0 didn't change anything, I am not sure I understood your mention of adding 512 to 7c00 ?
<zid>
The routine works by filling out 512 bytes of crap where es:di points
<zid>
what value do you have in di?
<nature>
Shall I share the assembly I am writing?
<gog>
so the data you're loading doesn't trample on what BIOS loaded from the disk sector
<zid>
can do, anywhere that has line numbers please
<bslsk05>
pastebin.com: bits 16 ; real Mode is 16 bitsorg 0x7c00 ; Set the origin (offset) at 0x7c00 s - Pastebin.com
<gog>
zid: what do you think is a reasonable limit for refcounts on physical pages
<zid>
oooh, six?
<gog>
six??
<zid>
sounds like you already have an idea then if you think 6 is too few
<zid>
nature: Don't sti.
<gog>
idk i was thinking 8 bits for that in my page struct
<zid>
okay so you never set di to anything
<zid>
and es is set to the vga text memory
<GeDaMo>
Line 31
<zid>
oh phew
<zid>
so di is set to some value between 7c00 and 7e00, in the middle of your code, and the structure will overhang it in a weird way
<zid>
so it will write it to.. BFC00 somewhere
<zid>
0xB8000 * 16 | 0x7C00
<GeDaMo>
You've overwritten es before calling print_vbe_modes
<nature>
oooh I think I see
<zid>
a debugger would be handy here
<zid>
just stick a breakpoint on that int 0x10 and just look at what es and di are
<zid>
we could figure it out, but in more complex code it won't be so easy
<nature>
Also if I want to move this vbe_info_block address after the first 512 I need to have a GDT then no?
<zid>
no, nothing to do with gdt
<zid>
just put a label for it after your times db
<zid>
or just make es:di work out to be 0x7E00
<nature>
ooooh I see now!
<zid>
it won't load into memory, it'll just be whatever garbage happened to be there, but you can write 'vbe2' in with a mov
<nature>
having 'db "vbe2"' won't work?
<zid>
not if it's beyond the 512th byte of your file
<zid>
the bios only loads 512 bytes
dennis95 has joined #osdev
<zid>
atm you end up with the vbe2 field, some zreos, 0xaa55 written somewhere into the middle, then some garbage
<zid>
which will work fine, but it's pretty odd
<zid>
what emulator are you using, out of interest?
<nature>
db isn't nasm specific that will just write the data directly to the memory?
<zid>
db isn't a thing your cpu runs
<GeDaMo>
db is an assembler directive, not an assembly instruction
<zid>
it's a command to nasm to make it emit those bytes at that location into the /file/
<nature>
I am quickly testing with qemu, and then I plan on sticking it on a usb and check the video modes of my computer :D
<GeDaMo>
It allocates space at assemble time
<zid>
The bios loads the first 512 bytes of that *file* into memory, so anything beyond the 511th byte.. is on the floppy drive / cdrom / hard drive / whatever still
<zid>
and not in memory
<zid>
so putting actual code or data beyond that point isn't going to do anything but change the floppy disk
<zid>
what happens at runtime will be identical
<nature>
Ok!! makes sense
<nature>
so I would either have to load it with the disk service of the bios or put stuff there with mov
<nature>
got it!
<zid>
yup
<zid>
and given your requirement is "512 bytes of empty space, with 4 bytes of 'v' 'b' 'e' 2' at the start", the 'mov' route is probably best
<zid>
just pick some unused memory somewhere and shove the sig in
<nature>
and if I keep the same layout for my label it should work the same right?
<zid>
could use 7A00 if you wanted, 'behind' your kernel, so that you can grow it forwards with disk reads still to get the rest into memory
<zid>
layout for your label?
<nature>
the structure I use with vbe_info_block, so I can for instance easily write "[vbe_info_block.video_modes]" to get the address (offset) of the video modes
<zid>
Yea you could do that I guess, bit of a hack though, afaik nasm has some STRUCT stuff for doing that problem
<zid>
s/problem/properly
<zid>
I've never bothered with it though
<gog>
yeah might be better to just work with the raw offsets here
<zid>
it's basically just modes EQU 0; version EQU 4
<zid>
..
<zid>
There is a segmentation thing you can do here, sorta of the 'point' of segmentation, to make it easier
<nature>
ooh ok, and then do [vbe_info_block+version] for instance?
<zid>
well, [di+version] hopefully
<zid>
so that you read from.. your actual data
<zid>
The segmentation way to do this would just be to set ES to 0x7A0
<zid>
now the calculation is 0x7A0 * 16 | di -> 0x7A00+di
<zid>
so di = 0 would be the sig, di = 4 would be the version, di = 6 pointer to oem name, etc
<nature>
yep! makes sense
<zid>
or not using di at all, assuming that addressing mode exists, mov ax, [es:version]
<zid>
assembling to mov ax, [es:4]
<nature>
I see!
<nature>
I think now I understand a bit more segmentation
<nature>
Thanks
<zid>
that's why the code at the top set es to 0xb800 for talking to vga memory
<zid>
it's at 0xB8000, and [es:0] would just be the first pixel
<gog>
first text cell
<zid>
text is A0000
<zid>
isn't it?
<zid>
or do I have it backwards
srjek has joined #osdev
<gog>
i think a0000 is also a text mode?
<zid>
Let's take our time machine back to 1987
<zid>
and read our manual
<gog>
but i'm positive b8000 is
<nature>
I think b8000 is text and a0000 is the other mode which I don't know how to call
<zid>
A0000 is colour I think
<nature>
YES!
<zid>
and low res video modes live there
<zid>
which is why I remember it
<nature>
And to have hi res you need a framebuffer right?
<zid>
framebuffer is just a word that means memory -> pixels
marshmallow has joined #osdev
<zid>
nothing stopping you having a 10x10 framebuffer, just isn't especially useful
<gog>
in real mode you have banked memory for like 640x480x16
<gog>
or 256?
<gog>
idk
<zid>
the reason the low res modes' framebuffers live there and not more, is because it ends up bumping into B8000
<gog>
that gets to be sticky and annoying
<zid>
1920*1080*4 is erm, 2 megs :P
<zid>
8 megs?
<zid>
counting is hard
<gog>
i never count
<GeDaMo>
That's what computers are for! :P
<zid>
I also don't count, but that's not what I was talking about
<nature>
So to get hi res you need to be in protected mode right?
<zid>
no
<zid>
but you're going to have to do a LOT of fucking around to address that much memory
<zid>
might need unreal mode, which needs you to pop into pmode temporarily
<nature>
protected mode is better suited for hi res then?
<zid>
but pmode isn't anything 'special' it just makes addressing memory above 64kB a lot simpler (or possible)
<c2a1>
Have any of you experimented with making a discrete GPU driver
<zid>
clever wrote one for the pi I think?
<nature>
c2a1: not a single plop of it :(
<zid>
I do a lot of random nintendo consoles, does that count
<gog>
yes
<c2a1>
I'm talking about radeon or intel
<nature>
Also question zid why did you tell me to remove sti before?
<c2a1>
I saw one on github one time
<zid>
There's no reason to enable external interrupts
<zid>
only bad things are likely to happen, nothing useful :P
<GeDaMo>
There are open source drivers for AMD and Intel, I think, I don't know how they compare to the manufacturers ones
<bslsk05>
cesarblum/sectorforth - sectorforth is a 16-bit x86 Forth that fits in a 512-byte boot sector. (15 forks/266 stargazers/MIT)
<nature>
GeDaMo: How cool! I think I saw it once half a year ago, but I was still learning about forth and had no clue what it meant, now I can actually apreciate it
<nature>
It'll be another nice piece of code to study for my future project
terminalpusher has quit [Remote host closed the connection]
k8yun has joined #osdev
k8yun has quit [Read error: Connection reset by peer]
k8yun has joined #osdev
_xor has quit [Quit: WeeChat 3.4]
[itchyjunk] has joined #osdev
c2a1 has quit [Remote host closed the connection]
mlombard has quit [Quit: Leaving]
freakazoid333 has quit [Read error: Connection reset by peer]
mlombard has joined #osdev
tenshi has left #osdev [WeeChat 3.4]
mahmutov has joined #osdev
sdfgsdfg has joined #osdev
c2a1 has joined #osdev
<jimbzy>
Wow. I just looked at that sectorLISP link. That's gnarly.
c2a1 has quit [Ping timeout: 240 seconds]
_xor has joined #osdev
<dmh>
pretty cool huh
<GeDaMo>
The garbage collector is pretty simple too
<GeDaMo>
(assuming it works the way I think it does :P )
<zid>
I garbage collect my LISP by rming it
dude12312414 has joined #osdev
<zid>
fite me GeDaMo
* GeDaMo
throws zid down the memory hole
<jimbzy>
zid, I just don't create any garbage to collect.
<zid>
I will create a vast shadow organization to engineer titanic biomecha from the DNA of captured angels imbued with my wife's soul and force my depressed children to pilot them into battle with you to determine the face of humanity and defy God rather than use LISP
<GeDaMo>
So ... Forth, then? :P
<zid>
ofc
<gog>
a cruel angel's hypothesis you got there zid
<bslsk05>
'Michael Jackson - Wanna Be Startin' Somethin' (Audio)' by michaeljacksonVEVO (00:06:05)
freakazoid333 has joined #osdev
k8yun has quit [Remote host closed the connection]
k8yun has joined #osdev
sdfgsdfg has quit [Quit: ayo yoyo ayo yoyo hololo, hololo.]
Starfoxxes has joined #osdev
dude12312414 has quit [Remote host closed the connection]
<nature>
It's very ugly, pretty much unusable but I attained my goal today: https://ttm.sh/inj.png
<nature>
Thanks to you guys :)
<zid>
go for 140 c8
<nature>
"less pixels, less headache"
<zid>
fewer
<zid>
more importantly, you get more bits for colour
<nature>
Yes, true
<nature>
By the way I read that some video modes don't necessarily support a linear framebuffer, how do you draw in such a mode?
<zid>
non linearly
<nature>
So the pixels' addresses are all over?
mahmutov has quit [Ping timeout: 240 seconds]
<zid>
usually in some kind of banking or planar system
<zid>
so you need to talk to the vga chip to tell it to change 'window' into the internal video memory
<zid>
so you can either write the rest of the pixels, or the other colour channel, or the low/high bits of the colour
mahmutov has joined #osdev
<nature>
It's quite inneficient compared to the linear right?
<zid>
no more nor less
<nature>
ok, I am just asking those question to get a better grasp of what different things mean. Thanks for your help again
<zid>
You'd just do an extra write to a register every time you needed to change bank, so you'd just update one bank in full, swap, update another in full
<zid>
it'd add 1 write per frame or whatever
Clockface has joined #osdev
lg has quit [Ping timeout: 245 seconds]
theseb has joined #osdev
<theseb>
Any tips on implementing multiple objects in memory that will grow to unknown lengths? The basic problem I'm seeing is that if you give each object its own big part of memory, there is always the danger you won't give it enough. I think the answer is you are forced to keep resizing the chunks of reserved memory unless you put everything in the same stack?
<zid>
virtual memory
<zid>
who needs one address space when you can have loads of them
<zid>
what are you trying to track, more importantly?
<j`ey>
theseb: that's how std::vector etc work
<zid>
or you could invent some kind of list that's linked together
<zid>
so that the addressing didn't need to be contiguous
<theseb>
zid: implementing lisp....i need a region for the "environment".....(keys AND values)....also need another region or output of evaluator, etc.
<GeDaMo>
Lisp ... a language built on linked lists :P
blockhead has joined #osdev
dude12312414 has joined #osdev
<theseb>
zid: i think virtual memory is relevant here...it does all the tedious work to efficiently stuff things in a single heap but gives you an interface that makes it appear like you have multiple arrays of memories..i like it
<GeDaMo>
Are there any OSs which allow a single process to have multiple address spaces?
<zid>
I mean.. does tls count? :P
k8yun has quit [Quit: Leaving]
<gog>
hm
<gog>
how would that work though
Matt|home has joined #osdev
<GeDaMo>
You might ask the kernel to move a range from one address space to another
<GeDaMo>
The actual data wouldn't need to be copied, just a remapping
<GeDaMo>
I'm not sure there's any use for this, it was just an idle question :P
<gog>
sounds like fork() almost
<gog>
except the originating process can swap its data segment
<gog>
because the code pages would have to remain i think
<gog>
at least some of them maybe idk seems fishy
troseman has joined #osdev
troseman has quit [Client Quit]
<zid>
mremap
<zid>
is a thing yo
<zid>
mremap() expands (or shrinks) an existing memory mapping,
<zid>
argument and the available virtual address space).
<zid>
potentially moving it at the same time (controlled by the flags
troseman has joined #osdev
<zid>
probably pretty useful if realloc is about to fail
<zid>
just make the kernel sort it all out
lg has joined #osdev
<gog>
huh
<gog>
so what GeDaMo is saying basically exists already
<gog>
lol
<GeDaMo>
Not exactly, that's still in a single address space
<GeDaMo>
That would probably meet all the useful applications though
<zid>
tls is already multiple address spaces anyway
<zid>
TLS brings all the address spaces to the yard
<zid>
I could allocate you one, but I'd have to charge
masoudd has quit [Quit: Leaving]
xenos1984 has quit [Remote host closed the connection]
<geist>
there are some weird non obvious things about varargs though, like how things are expanded to int or double ahead of time, etc
<moon-child>
yeahhhh
<geist>
i forget the exact scenario but you can end up with signed chars or shorts expanded to ints and printing a bunch of extra digits if you didn't use h or hh because the caller widened it to an int on the way in
<geist>
i think unsigned small stuff doesn't matter because t'll get expanded with zeros in the top bits
<moon-child>
hmm if you "%d", short, that should work fine
<moon-child>
so only for unsigned formatting of signed things?
<geist>
i think so, but if you %x a short
<geist>
it might get the top bits set
<geist>
hence a %hx truncating the top bits off before printing
<geist>
normally if you have aggressive warnings about mismatches it'll catch it, in Gcc at least, but i think it's a bit lax about h and hh if it knows it's not a problem (ie, unsigned short -> %x). i think
<geist>
`-Wformat=2` i highly recommend
<geist>
thoguh i dont know of clang has it. i know we catch things in the zircon kernel by always additionally building it with gcc even if we're only running the clang version. gcc tends to be more aggressive about certain sets of warnings
<moon-child>
gcc has no -Weverything tho
<geist>
noticed this week, for exmaple, that clang doesn't have `-Wmissing-declarations`
<geist>
very handy to have around, though fairly strict
<geist>
(or it has it but it doens't do anything)
<gog>
yeah -Wall is a little misleading
<gog>
because it's not literally all of the warnings
<geist>
and -Wextra goes beyond that
<geist>
but i thnk it idea is -Wall is allt he 'safe' warnings
<moon-child>
I think the idea is that -Wall is all the warnings they enabled at some point, and then they realised people were using -Werror even though they shouldn't so adding more warnings to it would break people's code
<gog>
i want to be warned about everything and have it break my code tbh