<heat>
mjg, i know i'm late, but page folios exist as a pending patchset
<heat>
mostly to make hugepages in the page cache doable
<heat>
but basically if you have a hugepage of n pages, those n pages will all point to the same folio
<heat>
it's supposed to be super transparent
<heat>
I think some filesystems already support hugepages pre-folios, but they're few
<heat>
I don't know if they collapse a single radix tree level as a hugepage
<heat>
the radix tree API in linux morphed into xarray some years ago, it's basically a fancy array interface with a radix tree behind it
sonny has joined #osdev
SikkiLadho has quit [Quit: Connection closed for inactivity]
<mrvn>
Is there a realloc equivalent in c++?
ngc0202 has quit []
<geist>
Not that i know of. It’d be pretty hard to deal with with constructors of arrays of things i think
<geist>
Since that’d probably be the only real use case of it
<geist>
I guess it’d have to run constructors on the newly appended objects and vice-versa for destructors
<geist>
Otherwise i guess it’d invoke the move operator between them. Sort of an interesting idea at least
<mrvn>
Would only work with types that have a trivial copy/move constructor.
<geist>
Or even non trivial, as long as it had them
<mrvn>
if they are non-trivial you have to allocate a new block and move them all. I don't think you could call the move constructor if the libc realloc moved the object already.
<geist>
It is an interesting proposition though, could build something like that on top of C’s realloc i suppose, but you’d have to have fully custom new/delete implementations too, i guess
<geist>
Oh that’s true. You’d really need some sort of heap level integration
<mrvn>
A realloc_dont_move()
<geist>
Like, some sort of try-realloc implementation: try to resize this allocation but if you can’t then dont actually do it
<geist>
Yah
<geist>
Or really extend, because shrink you can up front run the destructors
<mrvn>
But I would assume that realloc basically always moves. The likelyhood there is space after an array is small.
<geist>
Yah
Likorn has quit [Quit: WeeChat 3.4.1]
<geist>
But if you had your own arena style allocator and you were rolling your own thing that uses placement news…. You could build something like this
Ali_A has joined #osdev
<geist>
Which isn’t really that whacky, folks dothat sort of stuff all the time
<mrvn>
I just hate code like this: T* newArray = new T[returnSize()+1]; for(int i = 0; i<returnSize(); i++){ newArray[i] = array[i]; }
<geist>
Or forcing a move in that case
<geist>
Yah
<geist>
OTOH probably all wrapper friendly things would basically do the same thing in the new block case
<geist>
Which as you say is probably pretty frequent
<geist>
Unless it’s some sort of custom arena
heat has quit [Remote host closed the connection]
<geist>
Resizing down is maybe more realistic, since that’s probably doable in pretty much all cases
heat has joined #osdev
<geist>
Like an array of ref pointers that you then decide doesn’t need to be as big maybe
<geist>
But then i guess this is precisely what std::vectors are for basically
<mrvn>
but I believe they will copy on shrink
* geist
nods
<geist>
And certainly have no mechanism to return the unused portion of the backing store
<mrvn>
Now that we have constraints for trivially movable and such one could define a newgrow and newshrink operator
<mrvn>
well, newshrink would always work.
<geist>
And finally an new array size that takes floating point values!
<mrvn>
3.5 strings?
<geist>
Oh what amazing things we could build with that
<geist>
Partial constructors would be the bomb
<mrvn>
How about a std::vector<bool> with 2^33 entries on 32bit systems? size_t is just too small.
<geist>
Like it passes to you in the constructor the fractional part so you can try to allocate as much as you can
<geist>
S/allocate/initialize
<heat>
upgrade size_t to a uint128_t
<heat>
or a long double
<mrvn>
I want uint128_t for ARM
<heat>
either clang or gcc just broke the ABI for uint128_t
<heat>
turns out they were following the sysv spec slightly wrong
<mrvn>
for what arch?
<heat>
x86
<mrvn>
isn't that just the same as two uint64_t?
<heat>
alignment
<mrvn>
hmm, wait. what if there is only on register left? half in register, half on stack?
<mrvn>
heat: what is alignof(uint128_t)?
<moon-child>
mrvn: for the argument passing? I think they do all in memory if the entire struct doesn't fit in registers
<bslsk05>
github.com: make the alignment of >= 128 bit integer types 16 bytes to prevent failure to properly align u128 when using 16-bit cmpchxg · Issue #2987 · ziglang/zig · GitHub
<heat>
clang didn't break because they hardcoded it apparently
<mrvn>
clang 6.0.0 has align 16 and no __int128 before that.
<psykose>
i think that broke rust 128-bit ffi too
<psykose>
same llvm reason
<mrvn>
Same with gcc 6.1 onwards.
<heat>
<heat> clang didn't break because they hardcoded it apparently
<heat>
psykose, yeah, because they got it from LLVM
<mrvn>
Seems to llvm is the odd one out and violates the hardware requirements.
<heat>
clang, zig, rust build on top of LLVM
<heat>
if LLVM is buggy, those 3 are buggy :)
<mrvn>
Can't check msvcc, no __int128 there.
Dyskos has quit [Read error: Connection reset by peer]
Dyskos has joined #osdev
nyah has quit [Ping timeout: 276 seconds]
Dyskos has quit [Read error: Connection reset by peer]
Dyskos has joined #osdev
Dyskos has quit [Client Quit]
<mrvn>
"You want to get into some trouble?" "How much trouble?"
srjek has quit [Ping timeout: 260 seconds]
sonny has left #osdev [#osdev]
troseman has quit [Ping timeout: 250 seconds]
vdamewood has joined #osdev
<gog>
one trouble please
<gog>
is it my code that's broken or is it me
<psykose>
both
<gog>
the code's brokenness is a manifestation of my own brokkenness?
<gog>
deep
<mrvn>
the codes brokeness is a misjudgement by your own brokeness
<gog>
no, it's actually broken, i broke it and i'm still digging up how :p
<gog>
the answer is probably pointers
<heat>
why
rustyy has quit [Ping timeout: 248 seconds]
<mrvn>
pointers are evil, you have to hide them in wrapper classes
* vdamewood
hand mrvn a shared-ptr
* vdamewood
hands gog a fish
* heat
hands mrvn a range
* heat
hands mrvn a span
* heat
hands mrvn a string_view
* gog
takes a reference of the fsh
<heat>
huh, many ways to do the same thing huh
<vdamewood>
gog: Don't take a reference, Take ownership and properly consume the API.
rustyy has joined #osdev
<mrvn>
but the c++ guidelines say you should take ownership of pointers. But then you have to check them for nullptr. They should really advocate retruning owned references.
<mrvn>
why does new even return a pointer? It's never ever returning nullptr, that's what bad_alloc is for.
<vdamewood>
mrvn: as opposed to what?
<mrvn>
references
rustyy has quit [Quit: leaving]
<mrvn>
T & new<T>
<Mutabah>
`T&` isn't a pointer
<Mutabah>
Well, last I checked it wasn't
<mrvn>
exactly, can't be nullptr
<heat>
it can also return a nullptr
rustyy has joined #osdev
<mrvn>
(sort of)
<Mutabah>
(References may act like pointers, but they aren't)
<mrvn>
heat: only the nothrow version
<heat>
mrvn, any nonstandard operator new can afaik
<mrvn>
heat: that's your problem them. don't break the standard
<heat>
you can define a new operator new
<heat>
that's not nonstandard
<vdamewood>
Well, pointers can be deleted, references can't.
<mrvn>
vdamewood: make delete take a reference to match the new new
<vdamewood>
Also, pointers can be passed around as values themselves, references can't.
<Mutabah>
pointers can be reassigned
<mrvn>
Mutabah: cows can be brown. so?
<mrvn>
references can be taken the address of
<vdamewood>
pointers can be passed to C functions.
<vdamewood>
Pointers can do arithmetic.
<mrvn>
vdamewood: which would be wrong on an object returned by new
<vdamewood>
mrvn: new, sure, but not new[]
<mrvn>
no argument there
<Mutabah>
All really moot points, since C++ can't change the behaviour of `new` without breaking a LOT of code
<Mutabah>
And really, you shouldn't be using it directly in modern code
<mrvn>
new? you need it lots of places
<vdamewood>
Not really. make_unique and make_shared cover its usecases these days.
<Mutabah>
and if you explicitly need `new`, you should wrap it in a custom container type
<mrvn>
right, not quite used to them yet
<mrvn>
you are probably right. returning a raw pointer should be only in legacy interfaces that you can't fix.
<Mutabah>
`std::unique_ptr` is a managed pointer based around `new`/`delete`
<mrvn>
lets make new return a unique_ptr :)
<vdamewood>
mrvn: Can't without changing backwards compatability. make_unique does that anyway.
<mrvn>
except you have to check that for validity again.
<mrvn>
I want an unique_ref to show in the API that it will always return an object.
<vdamewood>
throw new fit();
<Mutabah>
That's more a problem of C++ allowing/requiring null states for everything
<mrvn>
yes
<mrvn>
You kind of need a linear type system for this.
<Mutabah>
If you want that level of changes... I have a language for you
<mrvn>
Like when you pass a unique_ptr to a function the compiler should warn about it being used after.
<Mutabah>
mrvn: I honestly see rust as a redesign of C++ with modern principles.
<vdamewood>
C is for coding. That's good enough for me.
<heat>
based
<vdamewood>
The only reason I'm not very deep in rust, myself, is that when I tried to write some boot code with it, the boot code didn't work because I was missing some implementations for required functions and I didn't really want to reimplement them.
<mrvn>
The reason I don't write rust is that I don't know any rust
<heat>
i'm not deep in rust because the standard library was broken and kept unmapping my user processes's stacks
<heat>
i tried fixing it but it didn't work so fuck it
<heat>
it would also make llvm a dependency on my gcc builds
<heat>
and that's a bit awkward
<Mutabah>
a gcc-backed compiler is in the works
<Mutabah>
(well, two are :])
<vdamewood>
Personally, I would just switch to LLVM if they had a decent 16-bit compiler.
<vdamewood>
maybe s/compiler/backend/
<heat>
my OS compiles with both
<vdamewood>
Oh, don't get me wrong. I use (Apple) clang to build my 32-bits.
<heat>
Apple clang is the cursediest clang :)
<vdamewood>
Yeah, but it actually works out of the box for cross compiling.
<heat>
all of them do
<heat>
but clang won't ever support 16-bit
<heat>
they focus on modern CPUs
<vdamewood>
Yeah, but I still need 16-bit code for my BIOS-based boot loader.
<mrvn>
do you really write a hugely complex compiler backend for the 100 lines aof asm you need to switch to 32bit?
<mrvn>
or do you want to support avr?
<vdamewood>
I think I switched to 32-bit mode in fewer lines than that.
<vdamewood>
Though, once I figure out how to boot properly with UEFI, I'm going to drop BIOS support.
<vdamewood>
And once that happens, I won't need 16-bit support, anymore anyway.
<heat>
well, it's ez
<mrvn>
vdamewood: that's what grub-efi is for
<heat>
open filesystem, read file, load kernel, close file
<heat>
get acpi tables, get memory map, exitbootservices
<heat>
/maybe/ set the video mode, /maybe/ load an initrd
<vdamewood>
mrvn: That's rather unhelpful.
<mrvn>
heat: install grub, don't change any code, boot with uefi out of the box
<heat>
write a UEFI bootloader, have fun
<mrvn>
vdamewood: why?
<vdamewood>
I mean, I'm doing OS dev. You might as well tell me not to write an OS and use Linux instead.
<mrvn>
vdamewood: you already support booting bios and uefi through grub. why change anything?
<vdamewood>
"Don't write a tool, Use one that exists already."
<Mutabah>
IMO, the fun of OSDev is setting up the post-boot stuff.
<Mutabah>
Dealing with the boot-time firmware is a distraction from doing the runtime stuff
<psykose>
some people are really attracted to the boot though
<bslsk05>
github.com: Carbon/efibootldr at master · heatd/Carbon · GitHub
<vdamewood>
heat: I'd share mine too, but I don't think I've pushed it anywhere.
<heat>
i haven't found the need to do much more than that
<heat>
of course, you can give yourself a fancy UI if you want
<heat>
you also optimise your file IO because UEFI supports (optional) asynchronous IO
<heat>
s/you/you can/
<mrvn>
not sure you really care about async IO during boot
heat has quit [Ping timeout: 260 seconds]
<vdamewood>
Well, might be time for me to go home.
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
bslsk05 has quit [*.net *.split]
CompanionCube has quit [*.net *.split]
Stary has quit [*.net *.split]
mcfrdy has quit [*.net *.split]
ecs has quit [*.net *.split]
SanchayanMaity has quit [*.net *.split]
energizer has quit [*.net *.split]
merry has quit [*.net *.split]
graphitemaster has quit [*.net *.split]
kanzure has quit [*.net *.split]
Amanieu has quit [*.net *.split]
valerius_ is now known as valerius
ecs has joined #osdev
SanchayanMaity has joined #osdev
Amanieu has joined #osdev
graphitemaster has joined #osdev
mcfrdy has joined #osdev
CompanionCube has joined #osdev
kanzure has joined #osdev
merry has joined #osdev
Stary has joined #osdev
energizer has joined #osdev
lg has quit [*.net *.split]
wgrant has quit [*.net *.split]
pg12 has quit [*.net *.split]
MiningMarsh has quit [*.net *.split]
DanDan has quit [*.net *.split]
MiningMarsh has joined #osdev
lg has joined #osdev
pg12 has joined #osdev
wgrant has joined #osdev
agrosant has joined #osdev
agrosant has quit [Max SendQ exceeded]
* mrvn
takes a big axt and makes 2 channels.
<bradd>
hi. what do you folks recommend for arm development hardware?
<mrvn>
an arm soc
<clever>
stockholm makes me say rpi :P
<bradd>
would a cheap rpi 3 work ok?
<mrvn>
sure
<bradd>
ok, off to find one online now :)
<bradd>
thanks
Likorn has joined #osdev
bauen1 has quit [Ping timeout: 246 seconds]
the_lanetly_052 has joined #osdev
haliucinas has quit [Ping timeout: 260 seconds]
DanDan has joined #osdev
vdamewood has joined #osdev
vinleod has joined #osdev
vdamewood has quit [Ping timeout: 240 seconds]
<geist>
would recommend a rpi4 over a 3
<geist>
depends on what you're trying to do though. do you want to bare metal osdev, or just want an ARM machine to run say linux on?
<bradd>
bare metal osdev
<mrvn>
are the RPIs still out of stock?
<geist>
yah might be hard to get ahold of
<geist>
but, yeah rpi4 is miles ahead of rpi3 in terms of bare metal
<geist>
if nothing else because it's much more modern (cortex-a72 vs -a53) and a bit more standard (uses a GIC interrupt controller, has a real hard ethernet block etc)
<geist>
lots of the rpi3 is hanging off usb
<bradd>
yeah, i've been looking. best i've found so far is a rpi 3 model B for $53.95 cad
<geist>
yah a but hard t come by right now
<bradd>
I'm gonna look around a bit over the next few days. maybe I'll find something
Likorn has quit [Quit: WeeChat 3.4.1]
bauen1 has joined #osdev
<nur>
just think how awesome the RPI5 will be
<nur>
(because I have RPI's 1 and 2 and did nothing much with them so I won't be getting any more till I have something to boot on them :) )
gildasio has quit [Remote host closed the connection]
gildasio has joined #osdev
Burgundy has joined #osdev
pretty_dumm_guy has joined #osdev
vinleod is now known as vdamewood
Ali_A has quit [Quit: Connection closed]
the_lanetly_052_ has joined #osdev
the_lanetly_052 has quit [Ping timeout: 246 seconds]
GeDaMo has joined #osdev
netbsduser has joined #osdev
m3a has quit [Quit: leaving]
w41 has quit [Ping timeout: 260 seconds]
pretty_dumm_guy has quit [Quit: WeeChat 3.5]
pretty_dumm_guy has joined #osdev
gog has quit [Quit: byee]
gog has joined #osdev
FatAlbert has joined #osdev
<FatAlbert>
GeDaMo: how's my hero doing
<zid>
when are you two going on a date
Brnocrist has quit [Ping timeout: 260 seconds]
bauen1 has quit [Ping timeout: 246 seconds]
bauen1 has joined #osdev
Brnocrist has joined #osdev
<psykose>
yesterday
<mrvn>
all my troubles seem so far away
<kazinsal>
idea: a weezer-style song called "beatles stoned" about being so high you just jam out to the beatles
Jari-- has quit [Ping timeout: 260 seconds]
nyah has joined #osdev
yasar11732 has joined #osdev
yasar11732 has quit [Quit: Leaving]
Vercas has quit [Quit: Ping timeout (120 seconds)]
Vercas has joined #osdev
bauen1 has quit [Ping timeout: 246 seconds]
puck has quit [Excess Flood]
puck has joined #osdev
bauen1 has joined #osdev
bslsk05 has joined #osdev
Vercas has quit [Remote host closed the connection]
Vercas has joined #osdev
valerius has quit [Killed (NickServ (GHOST command used by theophilus!~corvus@user/theophilus))]
valerius_ has joined #osdev
cross has joined #osdev
ngc0202 has joined #osdev
xenos1984 has quit [Read error: Connection reset by peer]
xenos1984 has joined #osdev
nyah has quit [Quit: leaving]
srjek has joined #osdev
Matt|home has quit [Ping timeout: 276 seconds]
bauen1 has quit [Ping timeout: 246 seconds]
bauen1 has joined #osdev
kingoffrance has quit [Ping timeout: 248 seconds]
les has quit [Changing host]
les has joined #osdev
sonny has joined #osdev
sonny has left #osdev [#osdev]
Matt|home has joined #osdev
wand has joined #osdev
heat has joined #osdev
kingoffrance has joined #osdev
the_lanetly_052_ has quit [Ping timeout: 256 seconds]
haliucinas has joined #osdev
zhiayang has quit [Ping timeout: 256 seconds]
mahmutov has joined #osdev
Vercas has quit [Ping timeout: 240 seconds]
the_lanetly_052_ has joined #osdev
bliminse has quit [Quit: leaving]
wand has quit [Remote host closed the connection]
cross has quit [Quit: leaving]
cross has joined #osdev
cross has quit [Client Quit]
cross has joined #osdev
cross has quit [Client Quit]
cross has joined #osdev
bliminse has joined #osdev
wand has joined #osdev
gog has quit [Ping timeout: 256 seconds]
sonny has joined #osdev
<sonny>
Am I crazy to think a personal computer should be an rtos?
<zid>
Yes
<sonny>
but latency/responsiveness is most important
<heat>
the opposite of no
<Griwes>
rtoses are about deadline accuracy that you, a human, are unlikely to be able to perceive
<sonny>
I imagine also the OS just hands over to the process instead of focusing on multiprogramming
<zid>
They're great if what you want is to DDoS yourself
<zid>
instead of having a general purpose computer
<sonny>
lol
<Griwes>
(ignore my comment if you are not, in fact, a human)
<sonny>
zid: already happens on mobile, one app at a time
<j`ey>
sonny: its still doing stuff in the background
<sonny>
networking, power control, what else?
<heat>
your OS already has pretty decent real time guarantees
<sonny>
oh really?
<sonny>
ok
<heat>
yes, that's how audio works fine
<heat>
even under load
<heat>
it's not just a stupid round robin :)
<sonny>
ah
<zid>
rtos basically just means "will stop you running programs if it thinks the audio will skip"
<zid>
instead of "The audio might skip if you manage to load so much shit the machine freezes"
srjek has quit [Ping timeout: 240 seconds]
<heat>
the regular scheduler is already pretty decent, and things like POSIX let you add schedulers that are more realtime if you so choose
<zid>
and 'thinks' will be "any chance greater than 0"
<heat>
yeah
<heat>
nobody dies if your audio skips a millisecond
<zid>
on a heavily loaded machine
<zid>
and tbh, you can still get audio skips on rtos it just tries its absolte best to stop it happening
<zid>
a naughty device still might interrupt storm it or whatever
<sonny>
oh rip
<sonny>
a personal system also should be distributed obviously, but it seems that's ok to do by a protocol?
<sonny>
is there anything else that makes an OS distributed?
<sonny>
I mean, you can kiss driver problems goodbye :-)
<sonny>
maybe it's that kernel services itself can be shared?
<sonny>
directly
zhiayang has joined #osdev
* geist
yawns
<geist>
good afternoon folks
* zid
throws peanuts
<geist>
oooh i love peanuts
sonny has quit [Remote host closed the connection]
sonny has joined #osdev
<sbalmos>
just as long as we don't end up being a peanut gallery
vimal has quit [Remote host closed the connection]
FatAlbert has quit [Ping timeout: 248 seconds]
sonny has quit [Remote host closed the connection]
sonny has joined #osdev
Dyskos has joined #osdev
<heat>
helllllllllllllo
<heat>
i have returned
<zid>
oh what did we do wrong
<heat>
you're not making a unix clone
<heat>
the gods wake me up when there's people not making unix clones
<zid>
I could make one if I wanted!
<heat>
do it pussy
<heat>
bet you can't
<klange>
language
<heat>
sorry
<zid>
heat: I could if I had any focus, time, capacity or depth
<zid>
I just don't want to
orthoplex64 has joined #osdev
GeDaMo has quit [Quit: There is as yet insufficient data for a meaningful answer.]
<zid>
heat: What should my first syscall be?
<heat>
exit, per svr4
<zid>
okay done
<zid>
what's second?
<heat>
oh god what a blunder
<heat>
read is the first one of course
<heat>
then it's write
<heat>
open, close
<zid>
I don't have anything to read though
<zid>
I have no open
<heat>
you won't exit(2) until the 60th syscall
<heat>
it's the UNIX(tm) way
<heat>
yes you do, STDIN
<zid>
should I just include a lorem ipsum generator
<zid>
so that I have something to read from stdin
<heat>
actually i'm very much stupid, I got confused because I started reading from the x86_64 system calls(of course they're different, why wouldn't they be)
<heat>
exit is indeed the first syscall per SVR4
<heat>
then fork
<zid>
okay exit is easy, if(rax == 0) shutdown();
<heat>
then it's the basic read/write/open/close
<klange>
When I was getting things set up early on, I started with a 'print' syscall ;)
<zid>
yea my real first syscall just did a kprintf that a syscall happened
<kazinsal>
I think mine was yield
Likorn has joined #osdev
<heat>
mine was write
<heat>
the first user programs were just write(STDOUT_FILENO, "Hello World!\n", strlen("Hello World!\n"));, without the strlen part because I had no libc
xenos1984 has quit [Read error: Connection reset by peer]
bauen1 has quit [Ping timeout: 240 seconds]
<mjg>
you can sizeof on it
<mjg>
zid: implement exit() which can fail
<heat>
you can sizeof a string?
<klange>
yes, a string constant can be sizeof'd
<klange>
I have a macro somewhere in one of my things that does this
<klange>
sizeof on a string literal will include the nil byte, of course
<heat>
i always depended on strlen getting constexpr'd by the compiler
<heat>
TIL
<heat>
Is that because "hello" is actually a char[6]?
<heat>
probably right?
<klange>
yes
Dyskos has quit [Quit: Leaving]
mahmutov has quit [Ping timeout: 246 seconds]
xenos1984 has joined #osdev
<zid>
string literal just decays to const char * really easily, same as an array
<moon-child>
char*, not const char*
<moon-child>
(unless you use c++ i guess)
<sbalmos>
let's not talk about UTF-8 multibyte either. how about hello world in Cyrillic?
<zid>
neither if you're talking about C moon-child :P
<zid>
char* is a C++ thing to 'prove' that the whitespace doesn't matter, it's universally char * in C
<moon-child>
zid: ? I'm talking about const, not spaces
<zid>
I am talking about type names
<zid>
you said "If you're talking about C, you mean char*" I said "if you're talking about C, you mean char *"
<heat>
char * str
<heat>
checkmate
<moon-child>
zid: k
<heat>
fwiw I still use int *p in C++
<moon-child>
when I include the identifier, I put the * next to it, cf char *s. But when there's no identifier, I leave off the spaces cf char*
<moon-child>
if you write char* x, then you should be forced to initialise with = malloc(sizeof* x)
mahmutov has joined #osdev
<zid>
Just skip all the silly intermediate steps and shoot them
<zid>
no need to boobtrap their codebases first
<heat>
rust
Vercas has joined #osdev
srjek has joined #osdev
xenos1984 has quit [Ping timeout: 252 seconds]
bauen1 has joined #osdev
xenos1984 has joined #osdev
mahmutov has quit [Ping timeout: 250 seconds]
troseman has joined #osdev
Burgundy has quit [Ping timeout: 252 seconds]
srjek has quit [Ping timeout: 240 seconds]
<geist>
boobtrap eheheehehe
<kazinsal>
hehehe
<zid>
It's like a beartrap
<geist>
and yeah the * thing is so dumb
<geist>
i lost that battle at work, because style guide is dumb
<zid>
Did you at least get tabs
<geist>
of course not
<geist>
and 2 space indents too!
<zid>
okay I want geist on the other team
<zid>
he's bound to get me what I want taht way
pretty_dumm_guy has quit [Quit: WeeChat 3.5]
<geist>
but so it goes. work is for the young, with still okay vision
<zid>
He's basically a double agent
<zid>
presumably you could fix it with a fancy editor but that's work
<geist>
yah to be fair i stopped generally using tabs about 10 years ago, since any decent editor can do the right thing with tab expansion
<kazinsal>
for some reason my brain really likes type* foo more than type *foo
<geist>
and then folks will always screw it up and put both
sonny has quit [Ping timeout: 252 seconds]
<geist>
i had no problem with tabs, except people would constantly bitch about it and screw it up, so then okay fine. now you get spaces and now you dont get to set your indents locally. have fun.
sonny has joined #osdev
<geist>
kazinsal: oh totally it really *should* be left associative, except it's not
<zid>
and the file is bigger for no reason, and you can't test if someone has fucked up and mixed alignment and indentation, and other fun trivialities
<geist>
zid: yeah what i did years ago is get vim to display a marker for tabs, so at least i can personally see it when its mixed
<kazinsal>
right? it mentally maps like (type pointer) (foo), not (type) (pointer foo)
<zid>
the type just has a space in it
<zid>
and it's wrong on EVERY level
<geist>
i read some justification for why it's right associative, and it kinda makes sense from a regularity point of view, and simplifies the initial parser
<zid>
It's `char *`a, b; which is wrong on both fronts so it cancels out ;)
<geist>
iirc its mostly beacuse * is already right associative for other ops, and then its 'regular' with & operator
<geist>
the real silly point is using the * in a declaration in the first place, instead of something like 'ptr'
<geist>
but since it was recycled, it acts like how its used in other parts of the language
<zid>
I assume it mattered what was easy to type on a selextric typewriter or something :P
<geist>
nah i think it's simply when you see * the parser can group it with the next thing
<geist>
in * for mul and * for deref, etc
<zid>
I mean, in regardes to making the grammar sensical
<zid>
these days we could just say you put an emoji snake
<geist>
and of course initial language parsers were written in like 4K of ram
<geist>
so they chose to make it simple
<kazinsal>
yeah
<zid>
as in, there are archaic practicalities they had to consider that we don't
<geist>
but yeah it's worth reading it, somewhere there's a doc by one of the C authors that basically talks about initial development of the language and the design choices they made
<geist>
it's a good read
<geist>
probably about 20 years old, but floating around somewhere
<heat>
tab-spaces are fine
<heat>
2 space tabs are not
<zid>
what's a tab subtract spaces
<heat>
ask javascript
<heat>
they can probably give you a random answer
<zid>
NaNaNaN Batman
troseman_ has joined #osdev
troseman has quit [Ping timeout: 240 seconds]
<geist>
heat: re: ia64 you should look into the itanium syscall mechanism. it's totally whacky and pretty neat
<geist>
and has some of these 'branch into the middle' things to think about
<geist>
it's a brain teaser how you can actually make it work securely
<zid>
to be fair, so is amd64 :P
<geist>
har har. though kinda true for different reasons
<zid>
I'm not sure you'd figure out the whole swapgs mess if you just read the instruction listing
<zid>
and not any code or system guide or whatever
<geist>
or you'd stumble upon the gs problem and then wonder how you solve it
<geist>
and suddenly swapgs makes sense
<mjg>
mismatched swapgs == $$
<geist>
i think i came into it that way. originally i had read swapgs and was like huh okay this is odd
<mjg>
which os did not have one
<geist>
then later on when implementing it for reals.... oh i get it
<heat>
mjg, those bugs are the worst to debug
<zid>
irq_entry: /* Erm.. what the fuck reg can I destroy here for a new rsp?.. shit, where's the book */
<geist>
yah really anything that is modal like that is intrinsically a bad idea
<geist>
SMAP has kinda a similar problem
<geist>
wher eyou have to keep toggling a bit back and forth and there are paths where you can end up with it not set right
<zid>
do any chips have FRED yet
<geist>
also a thing that arm solved much cleaner by having the same thing but requiring no toggles
<mjg>
now that you mention it i never checked what happens if you disable or enable it twice in a row
<mjg>
i presume nothing changes?
<geist>
mjg: which one smap?
<mjg>
smap
<mjg>
clac or stac, twice
<geist>
it's the EFLAGs.AC but i'm thinking about. yeah no problem
<geist>
in fac tyou should generally just clac (or stack i forget the polarity) on entry into the kernel basically alaways because of this
<geist>
at least you're not toggling it, you're hard setting it to one way or another
<mjg>
you have to flip it for user access here and there and -- surprise -- there were bugs in page fault handlng
<mjg>
and i don't mean my code :->
<geist>
arm solves it (PAN - priviledged access never) by simply having a second set of load/store instructions that access memory as if they were user code
<geist>
and thus you enable pan and then use those instructions for your user copy
<geist>
pretty solid way to do it
<mjg>
interesting
<mjg>
but how much of thei nstruction set do the duplicate to do it?
<geist>
(though there's a design flag in it they have fixed in newer v8.6)
<geist>
mjg: you mean the load/store user instructions?
<mjg>
yea
<geist>
that's the rub, they're not as powerful instructions, so it's hard to implement really efficiency
<mjg>
i'm guessing you may try to get fancy depending on transfer sizes
<geist>
ie, only a single register sized load, no writeback update
<geist>
vs the usual mechanism where you'd use a load/store pair instruction
<mjg>
ye, i expected it comes with a huge drawback
<geist>
i htink there may be some microarchitectural reason for that, like the cpu is using some temporary different context when accessing it and maybe a single load/store is doable without any complex uop decoding
<geist>
(ie, pair of loads, or writeback to the base register)
<mjg>
so imo the thing to do would be to roll with an instruction which takes adress range
<mjg>
that still lets you use the regular instruction set
<mjg>
i meant instruction address range -- from foo+0x$whatever to foo+0x$whatever_end
<mjg>
which would encompass all legal user access
<mjg>
but i have no idea how (not)problematic would that be to implement in hw
<mjg>
it may reven require that the end of the segment is the closing instruction, so you can't fuck up on this front
<geist>
for a single copy you mean?
<mjg>
copyin/out: ... ; stac [address of paired clac] ; /* copying happens here */ ; clac
<mjg>
if you stac with a lolo addr you get an exeption, which presumably be sorted out during development and wont reach production
<heat>
but if you get an exception and stac you need a stack of stac's
<mjg>
now that you mention it, someone may want to stac upfront in the routine and then have multiple exit points, each of which requires its own clac
<mjg>
so the above does not help in said case
<heat>
out: clac; ret
<heat>
that's not a problem
<mjg>
:sadpanda:
<mjg>
the point was to prevent footshoting. the one exit point with clac is something the pgorammer can do on their own as it is
<mjg>
the proposal does not help with the other case
<mjg>
i mean finding problems with it
<heat>
i don't think that's really an issue cuz stac and clac happens on self contained assembly routines/inline asm
<heat>
you don't /really/ have complicated flow control there
<mjg>
freebsd copyin/copyout have multiple exit points, each of which requires clac to be slapped in there