<geist>
scripted: then dont. not sure where this 'really old version of C' thing is coming from
<scripted>
geist: c89
<geist>
use modern C. or C++ or whatever you want (though C/C++ are pretty good for this sort of thing)
<hodbogi>
So much easier to do memory manipulation and complex programs with Forth on them
<geist>
sure, but where is this c89 thing coming from?
Ali_A has quit [Quit: Connection closed]
<geist>
hodbogi: at the end of the day it's a lovely 6809 too
<hodbogi>
yeah
<scripted>
well, I'm currently learning ansi c just for osdev
<geist>
scripted: then dont. that's silly
<geist>
there's no reason to stick to old versions of C for osdev
<scripted>
I like the syntax though
<hodbogi>
There's a program for Linux that can convert files into casette tape format in wav and back
<hodbogi>
I have been able to write assembly programs and MLOAD them in
<geist>
scripted: vs what? modern C?
<scripted>
actually
<scripted>
I've never looked at modern C
<hodbogi>
or CLOADM or whatever it was
<geist>
scripted: just some new features. use them
<scripted>
I only know some C++11/17 and C89
<geist>
but nothing major, but limiting yourself to old C is silly nowadays. C itself is already old, so at least use the current version
<geist>
okay, anyway
<geist>
hodbogi: hmm, does it pretend to be the tape drive so you plug it into the speaker?
<hodbogi>
omg the color computer IRC channel survived the freenode shipwreck
<hodbogi>
they are on libera now
<mrvn>
scripted: learn at least c99 if not something newer
<hodbogi>
This guy I work with is in school still and the professor is forcing everyone to uce C89 with pedantic and ansi
<geist>
yah declare vars anywhere, use C++ coments, proper bool type, etc.
<hodbogi>
and it's like, STOP, you're computer science. Just stop
<mrvn>
hodbogi: tell him to retire already
<hodbogi>
Right?
<geist>
i think it's some lesson in dealing with adversity and arbitrary restrictions
<geist>
as is the case in the Real World a lot of time
<mrvn>
hodbogi: it's so insane you must be using msvc
<hodbogi>
I told hi that the professor is essentially teaching the students bad habbits, because there are things that are obsolete or even invalid in newer C/C++ standards that you wouldn't probably know about.
<mrvn>
hodbogi: luckily you can just include the c99 headers into your code and pretend it's c89
<mrvn>
mostly
<geist>
possible it's something really dumb like whatever library/examples he has in his curriculum isn't valid c99 so he forces c89 so it works
<geist>
instead of fixing it
<mrvn>
hodbogi: do you have to declare all variable at the start of each function?
<kazinsal>
yeah I'm of the opinion that if it compiles on a modern compiler it's valid C
<hodbogi>
Like how you can no longer do char *foo = "Hello" in C++ since what, C++14? I forget now
<hodbogi>
but if you use an earlier standard how would you know
<mrvn>
geist: it's pretty hard if not impossible to write c89 that isn't c99
<kazinsal>
eg I use `-std=c17 -fms-extensions`
<geist>
mrvn: probably. i dont even care to try to come up with an example :)
<mrvn>
hodbogi: string literals are const since C99?
<scripted>
all right
<mrvn>
geist: //*
<scripted>
I think its a good idea to pick up C++ again
<geist>
mrvn: why are you wasting my brain with this! i'd rather fill with it esoteric dead architectures
<hodbogi>
mrvn: I was referring to C++, it was in a porting book I was reading, one of the newer C++ standards requires that you explicitly supply const or do it another way
<geist>
scripted: keep in mind C++ is like an order of magnitude more complex, easily
<hodbogi>
I forget at what point that changed
<mrvn>
geist: c++ comments is one of the things they added that you can easily use to break
<geist>
so... also might not be a great thing to dive into right now
<geist>
mrvn: there may be a bunch of K&Risms that got fully removed in C11 or later
<geist>
not that i've used any code with it in a long time, and if i did i have so many warnings on it'd catch it
<hodbogi>
oh like being able to declare parameters outside of the parenthesis in a function declaration?
<mrvn>
geist: yeah, but I believe that already fails with -ansi -pednatic.
<hodbogi>
I dont't know why anyone would do that anyways
<geist>
aside from old code, yeah
<scripted>
geist: Yeah but the thing is I've coded in C++ before, and I don't wanna completely forget the language which would be a shame.
<geist>
scripted: theres' no risk.
<geist>
you hae a loooooong way to go if you're going to keep programming. dont sweat it
<scripted>
I already forgot Lua
<geist>
no giant loss
<mrvn>
scripted: C++, c++03, c++11, c++17/20 are nearly different languages.
<heat>
funnily enough I'd like a way to compile really old stuff, k&r C basically
<geist>
C++ is so large you can forget tiny pieces of it and have forgotten more than an entire simpler language
<heat>
modern gcc doesn't work, and clang never did
<mrvn>
heat: so compile gcc-2.95
<scripted>
mrvn: I really noticed that once I started reading C++21 code as a C++11/17 programmer
<heat>
c++21 doesn't exist
<scripted>
*c++20
<heat>
mrvn, will that work smoothly?
<heat>
i don't want to de-bootstrap myself from 11.2 down to 2.95 :P
<mrvn>
heat: you might have to compile some intermediate gcc to compile gcc-2.95
<hodbogi>
int add(a, b) int a; int b; { return a + b; } <-- This shit, which was valid at one time, is so dumb...
<scripted>
sorry, but what the actual fuck is this
<hodbogi>
It's K&R declarations
<mrvn>
hodbogi: not sure that kernigham and richie (or however you spell them) was thinking there
<heat>
kernighan
<scripted>
you can't tell me
<heat>
?
<scripted>
c++20
<scripted>
is based off a programming language like c
<geist>
much easier to parse
<scripted>
this is straight up new syntax
<geist>
initial C compilers were written in like 4K of .text
<hodbogi>
Mind you I prefer to have my curly braces on the same line as the function declaration, instead of allman style closures, but the K&R declaration format itself is retarded.
<mrvn>
geist: modern C can be compiled in 1k.
<Griwes>
this is not a "new syntax", this is the *old* syntax
<scripted>
hodbogi: nice, me too
<Griwes>
very old
<geist>
remember prototypes weren't strict back then. that didn't come until C89 i believe
<Griwes>
prototypes *still* aren't strict
<heat>
c++20 is similar to 17 which is 14 plus few stuff which is 11 plus a few features which is 03 with a lot of features which is 98 with a few more features which is just a standardized version of C++ that was C with classes, based on C
<mrvn>
geist: huh? implicit prototypes are still a thing I believe.
<Griwes>
I think C23 changes it?
<geist>
or at least ansi C. all you were really doing was just providing the local function definition. the type of the function signature wasn't complete
<Griwes>
but `void foo()` is still stupid
<mrvn>
heat: c++20 is a major change in how you should write code.
<hodbogi>
I think the moral of the story here is just use the newest standard that is complete.
<Griwes>
(until C23 that is)
<heat>
mrvn, disagree
<hodbogi>
i.e. default compiler standard
<Griwes>
those two aren't the same
<geist>
so in the K&R style it makes sense. you define the function, the number of args, then open an implicit scope where you declare the args (names match to the arg list), then open the real scope
<heat>
i'll keep writing C++ like I usually write C++
<heat>
no ranges, no anything
<scripted>
which one is complete?
<heat>
ok, just spans
<geist>
probably easier to parse, since the parse logic is in phases
<scripted>
I feel like c++20 is a entire new language and not just new features
<hodbogi>
scripted: It means just use the standard your version of the compiler defaults to.
<mrvn>
Griwes: totaly. Why is having a return type and any number of arguments even a thing?
<heat>
and maybe <format> when that is feature complete on all standard compilers. so basically 2025
<hodbogi>
try to keep the compiler up to date
<geist>
since functions weren't really strictly typed back then it didn't matter that the function decl had the types in the list
<hodbogi>
scripted: The thing is, computers are stupid. They are as dumb as a rock
<hodbogi>
I mean they are a rock
<scripted>
they are
<mrvn>
heat: but you should use them
<scripted>
but they also are very gifted in counting
<hodbogi>
So we build smart compilers to help
<Griwes>
funny you mention <format>, an implementation of that was basically the first thing I wrote for my kernel lol
<heat>
Griwes, you're already ahead of GCC in <format> conformance :P
<hodbogi>
I kinda wonder if anyone ever made a header called format.c instead of format.h and included that as a joke.
<heat>
mrvn: I disagree. I like my minimalist C++ very much, and I don't see the point in ranges
<mrvn>
geist: back then you had implicit prototypes. So what benefit is knowing the return type?
<heat>
I have considered concepts but I don't do enough template programming to need those
<scripted>
I remember a few months ago where I argued with a physics student that bash is not better than C
<mrvn>
heat: you don't like std::vector<int> v; ... v.sort()?
<Griwes>
heat, I even already have the DR to the C++20 spec we made that makes it do compile time checks, too!
<mrvn>
+ranges
<hodbogi>
honestly..
<hodbogi>
sometimes bash is better than C XD
<Griwes>
not wrong
<hodbogi>
depends on what you're trying to accomplish I guess
<scripted>
could be.. but he argued that you could do much more in bash than in C
<Griwes>
at least with bash you can do sane string processing :V
<hodbogi>
My question becomes, wtf are you writing in bash?
<mrvn>
heat: I like not having to specify begin() + end() in algorithms. Much easier with ranges.
<scripted>
hodbogi: I don't use bash
<heat>
mrvn: I can do std::sort(v.begin(), v.end()), or add a wrapper to sort with standard containers
<scripted>
nor write bash
<hodbogi>
You know the first task I had at my current job was to rewrite somebody's XML parser written in awk+regex.
<hodbogi>
the person who wrote it swore that awk was the best language
<mrvn>
heat: you can also do std::sort(a.begin(), b.end()) by accident.
<mrvn>
heat: my point was that to sort a container you just use the container as range. No need for begin() and end().
<hodbogi>
The person did not accept that awk is essentially just a scriptable sed.
<scripted>
awk
<scripted>
thanks god google exists
<hodbogi>
Lol you didn't know what awk was?
<scripted>
hell no
<hodbogi>
Don't worry
<heat>
mrvn, why do I need to add a multi-thousand-line header library to do that?
<hodbogi>
You're not missing out
<scripted>
first I thought of AWS
<scripted>
then of ARK
<hodbogi>
look up GNU awk
<scripted>
yeah I just did
<heat>
awk is good
<scripted>
its a little younger than C
<mrvn>
heat: I have to confess I haven't looked at the header yet.
<hodbogi>
heat: yeah but did you read what my first task was? :P
<hodbogi>
It will give anyone nightmares
<heat>
hodbogi: yup :P you need to know the tool for the job
<hodbogi>
LOL
<heat>
in this case it definitely wasn't awk
<mrvn>
heat: but you are using spans, so big win there.
<mrvn>
heat: ranges are probably more of a time saver because it's less to type. Spans add more safety.
<heat>
mrvn, i look at the horror inside LLVM where you have lots of files that take multiple seconds to compile and I just don't want that around my code
<Griwes>
I'm heading towards writing actual hosted userspace programs, so I'll have to start implementing <vector> and <unordered_map> and <ranges> soon I guess
<heat>
these are absolutely not zero-cost abstractions
<Griwes>
compile time is cheap
<mrvn>
heat: have you used coroutines yet?
<heat>
no
<heat>
Griwes, is it?
<Griwes>
yes
<mrvn>
Griwes: not using an existin g STL?
<Griwes>
no
<mrvn>
heat: modules might remove the time overhead
<Griwes>
for the core system, I want as much of the code as I can get to be my own
<heat>
i don't have a $14000 workstation given to me by $CORP
<heat>
compiling llvm means I need to wait 40-50 minutes for a *non-lto* build
<mrvn>
heat: how often do you build llvm that that matters?
<mrvn>
and are you using ccache?
<Griwes>
the big things I will make exceptions for are (0) compiler-rt.builtin, (1) libc, and (2) acpica
<nomagno>
Would GPUs actually be better for building if the necessary software was there?
<nomagno>
They're massively parallel, they could get the job done in seconds depending on the size of subroutines
<Griwes>
you mean for running compilers on? almost certainly no
<nomagno>
Just with less optimization
<mrvn>
nomagno: if you want to build 1000 source files in parallel maybe.
heat has quit [Read error: Connection reset by peer]
<nomagno>
mrvn: what about building separate subroutines on different cores?
<scripted>
any truly good learning sources to learn C++20?
heat has joined #osdev
<Griwes>
remember that gpu threads, while these days extremely capable (at least on *our* platform :P), are still somewhat fake
<hodbogi>
Kinda unrelated but I was thinking the other day, have any of you experimented with any unusual data structures (i.e. 1D R-Trees, or something for organizing sections of memory in your projects?
<heat>
shitty internet
<heat>
<heat> often
<heat>
<heat> i like working on my toolchains
<heat>
<heat> then I also ultimately have to do an LTO build so I get an optimised compiler (that takes around 2hrs)
<scripted>
and there goes the internet connection
scripted has quit [Quit: WeeChat 3.5]
<heat>
also, if my toolchain changes, my CI needs to trigger a rebuild, which takes even longer
<mrvn>
nomagno: remember that while you can run massively parallel your code can't branch differently per data item or the whole performance just dies.
<Griwes>
the compile time cost is still negligible compared to the ability to productively write pretty fast code
scripted has joined #osdev
<heat>
i like fast iteration
<mrvn>
heat: then don't LTO
<heat>
I don't LTO
<mrvn>
then ccache should save you 40-50 minutes per build
<Griwes>
it's either you type less and wait a bit to compile, or you compile fast but have to write much, much more code
<hodbogi>
I really like Joe Armstrong's talk on programming multicore computers. It addresses the reasoning behind Erlang's concurrency model first, parallelism second model.
<Griwes>
I'd rather wait for compiles rather than spend more time typing and debugging
<Griwes>
if it's the other way for you, that's fine
<heat>
I just haven't found the need to do all sorts of crazy template metaprogramming and all that
<hodbogi>
You can go crazy with templates
<heat>
maybe one day I'll understand you mean
<heat>
but right now? nah
<hodbogi>
I remember going absolutely wild with Roles in Perl+Moose..
<heat>
I do use templates, don't get me wrong, but they're usually very lightweight
<mrvn>
it's qute hard to do templates right so they don't go crazy.
<heat>
very usually just simple RAII wrappers
<Griwes>
<ranges> is still a pretty tame C++ library, if you compare it with some of the monstrosities in boost
<mrvn>
it's one of the things I hate about templates. It's basically doing an exhaustive search trying to see if any combination of types will compile or not.
<heat>
I also never used boost so yay for me I guess :)
<nomagno>
mrvn: the idea is a different subroutine is pre-offloaded to each thread. If symbol names are not very context-dependent (like in C), the parsing stage will take a bit longer, but then a different thread compiles a different symbol and they're all put together
<mrvn>
SFINAE in c++ is horrible
<mrvn>
nomagno: I just run make -j 8
<nomagno>
This also needs a format where you can just concatenate symbols
<heat>
also re: modules, they don't work well with build systems yet
<heat>
will they ever? who knows
<heat>
I don't think any compiler even has full support for modules yet
<mrvn>
heat: they work fine in make
<mrvn>
heat: do you know that c++ STL headers are supposed to work as modules?
<heat>
yes
<mrvn>
So the ranges module should shave of most of the extra 2s compile time of #include <ranges>
<scripted>
learncpp.com seems like a good learning source
<Griwes>
we don't need no sfinae now that we have concepts, it's great to have actual syntax for it
<heat>
i am an avid reader of r/cpp I'll let you know
<Griwes>
mistake
<mrvn>
Griwes: are concepts actually any different there? You are still doing SFINAE and the checks are still all the same. It just looks nicer and more explicit.
<Griwes>
it looks nicer
<Griwes>
and also you have subsumption
<mrvn>
My feeling is that concepts are just better error messages, not less compile complexity
<Griwes>
so that a lot of the "a && b" followed by "a && !b" nonsense that you often find in overload selection just goes away
<Griwes>
you can require a && b and then require a and those are never ambiguous
<mrvn>
With a concept I can tell the user what is wrong instead of having the compiler tell him about all the 10000000 substitutions it tried and why each didn't work.
<Griwes>
and by god `if constexpr(requires { ... })` is the most satisfying intersection of two language features that we've *ever* had
<mrvn>
Griwes: oh yeah, I love conditional requires
<mrvn>
before this you couldn't write this with templates because SFINAE would do the "false" path when the "true" path didn't compile even though the "requires" part matched, right?
<nomagno>
Uh... Anyone remember when the C++ standard people acknowledged it was too big 20 years late?
<nomagno>
Are they going to ignore that bit for another 20 years until only Elon Musk can maintain a C++ compiler?
<mrvn>
nomagno: what is too big?
<Griwes>
who acknowledged it was too big
<nomagno>
I don't know, I read it somewhere. Either IRC or Wikipedia.
<Griwes>
as an individual of the C++ standard people species I have made no such acknowledgments
<nomagno>
Griwes: Well do you work on the committee?
<Griwes>
yes
<mrvn>
freestanding c++ needs some trimming though
<Griwes>
it's getting a nice definition that isn't just "these headers lol"
<scripted>
guys did you get the news yet
<mrvn>
Griwes: we need a freestanding - exceptions - rtti
<scripted>
twitter was bought out
<nomagno>
mrvn: 'some'? I'm unsure how you're supposed to implement C++ freestanding at the moment without a full runtime on top of the CPUZ
<mrvn>
nomagno: simple. I say -ffreestanding
<Griwes>
some of the freestanding discussions did touch on -fno-exceptions and it was a more positive reception than I expected
<nomagno>
mrvn: I say tomato?
<mrvn>
nomagno: both C and C++ stndards define a freestanding subset of the language
<nomagno>
mrvn: when did I not acknowledge that?
<mrvn>
nomagno: you sounded like freestanding c++ wasn't a real thing
<Griwes>
and as long as the more granular definition of what the library provides in freestanding is a success, I *think* we'll go there and definite that -fno-exceptions is in fact a valid thing
<nomagno>
I'm saying I'm unsure how you can actually get C++ freestanding to compile... To an actually freestanding thingy
<Griwes>
very easily?
<nomagno>
You need an entire runtime for exceptions and such
<hodbogi>
yeah but those aren't in the C++ core
<Griwes>
yeah -fno-exceptions and you squint hard enough to ignore that that's not conforming
<hodbogi>
they're provided by additional libraries
<mrvn>
nomagno: yes, you need a bit of support stuff. Which is why -fno-exceptions and -fno-rtti is a thing.
<mrvn>
nomagno: you can't really compile a freestanding C. You need some support code to set the stack pointer and zero out .bss. There is no free lunch.
<mrvn>
(+eigther)
<nomagno>
mrvn: Far less tough... Freestanding C's only requirement is essentially a callstack
<mrvn>
Griwes: doesn't gcc compile and run code just fine as long as you don't have any exceptions in your code even if you forget -fno-exceptions?
<nomagno>
The only person alive to design a system without a call stack is probably me, so we're good :)
<nomagno>
I'm still not sure how you're supposed to implement all of C++ tough. The language needs commercial oomph to be implemented fully
<Griwes>
mrvn, yeah, but with -fno-exceptions you get a nice diagnostic ;p
<mrvn>
nomagno: my IRQs, exceptions and syscalls don't have a call stack on ARM
<nomagno>
That's not a very nice thing IMO
<nomagno>
You get less competing compilers
<mrvn>
Griwes: I think it's fine unless you have an exception, only then you get unresolved symbols.
<nomagno>
mrvn: neither of those are required for freestanding C tough
<Griwes>
yes
<Griwes>
that's what I am saying, if you use them you get a nice diagnostic
<mrvn>
Griwes: right
<mrvn>
nomagno: "The only person alive to design a system without a call stack is probably me". you are not alone.
<nomagno>
syscalls are theoretically needed only for the init part of the program, and for I/O
<Griwes>
nomagno, uhhh, it's not the runtime that'll bite you when you are trying to make a competing compiler without a team, it's the stdlib and, even more, the compiler itself
<nomagno>
mrvn: noooo!
<nomagno>
Griwes: I wasn't trying to imply it's the runtime
<nomagno>
Was a separate statement
<mrvn>
nomagno: you could write your compiler to implement exceptions differently so they don't need such a "big" runtime
<nomagno>
mrvn: I could not write my own compiler.
<nomagno>
I can't dream that big. I like being pedantically compliant
<mrvn>
On cppcon there was also a nice talk about implementing exceptions as variant return types iirc.
<nomagno>
With C++ solo compiler dev for full-ish compliance is not like with C (which is already bad enough, C89 or C99 without VLAs can take months), I can't even dream big enough
<mrvn>
You probably have an optimizing C compiler before you finished the c++ parser.
<hodbogi>
holy crap it's been half an hour and you folks are still going on about this
<hodbogi>
XD
<geist>
haha right?
<mrvn>
hodbogi: only half an hour?
<geist>
but i aint complainin
<hodbogi>
I was actually reading up on reminding me how much of a shitshow memory management is in x86
<hodbogi>
and I came back and this is still going on XD
<Griwes>
"the c++ parser" being completed requires probably the vast majority of the frontend to be finished :P
<mrvn>
nomagno: I'm still dreaming of being able to write language extensions for gcc or clang so I can test and then propose new features.
<nomagno>
mrvn: I'm still dreaming of understanding the gcc architecture
<nomagno>
Like... How do people manage to port that thing to new CPUs?
<mrvn>
Griwes: There are parts in c++ in the standard that basically say: "we give up, this can't be decided"
<Griwes>
I wish to forever be ignorant of any parts of the gcc architecture
<nomagno>
Clang might be even worse
<nomagno>
LLVM is even worse, I know that for s fact
<hodbogi>
LLVM takes all day to compile
<nomagno>
But haven't looked into the clang frontend
<Griwes>
at least clang's written in c++
<hodbogi>
I use clang for my compiler but I use freebsd a lot what do you expect
<Griwes>
where gcc is written mostly in c that's compiled as c++
<mrvn>
or "if it looks like a function declaration then it is a function declaration". It's impossible, or at least too hard, to decide when something is a function declaration or variable.
<Griwes>
I know which one of those two I prefer lol
<hodbogi>
I also really like SmallerC but that compiler is kind of a toy more than anything.
<Griwes>
mrvn, nah, that one has a specified parse
<mrvn>
Griwes: gcc being compiled as c++ is a relative new thing
<Griwes>
yeah I know
<Griwes>
hence "c compiled as c++"
<nomagno>
Apple funding for LLVM probably wasn't meant to create a worse gcc.
<nomagno>
From an architecture point of view, anyway
<nomagno>
Like, they HAD a clean slate!
<mrvn>
Griwes: can't be expressed in the grammar
<nomagno>
How do you mess up again!
<hodbogi>
Solution: Write your own C compiler that compiles to smoke signals.
<Griwes>
you just parse as a function and then bail out if that fails :P
<hodbogi>
You can express your smoke signals as a streaming k-d tree of an AST
<mrvn>
Griwes: that's not how parsers normaly work
<hodbogi>
with morse code contents
<Griwes>
llvm's main goals were (1) no gpl3 and (2) aboid the gnu stupidity of "it must never be a library or Evil Corps (tm) will abuse it"
<hodbogi>
I am not a fan of the gpl...
<Griwes>
mrvn, oh, parsers are normally tasked to parse a thing that doesn't require full semantic analysis to happen before they can process all tokens
<clever>
having llvm as a library opens up so many options
<nomagno>
BTW, is it possible to program with only one symbol?
<nomagno>
Without a time factor, I know that trick
<nomagno>
This could print 'Foobar' in some system, or something
<mrvn>
unary numbers are X, XX, XXX, XXXX, XXXXX. But that requires that you can detect the start and end of the Xs.
<nomagno>
hodbogi: time factor
lainon has joined #osdev
<nomagno>
Like I said
<nomagno>
Morse code is timing-dependant
<nomagno>
It lacks meaning without a distance or a time element
<mrvn>
I would say morse code has 3 symbols, dot, dash and pause
<mrvn>
There are lots of encodings where the symbol is a state change.
<mrvn>
but again you have a timing or something extra to make it work.
<nomagno>
mrvn: I'd say it's more appropiate for this discussion to interpret it as a passive state 'pause', and an active state 'line', which together find meaning with a distance/time factor
<mrvn>
nomagno: you pause between letters
<nomagno>
In the end binary ends up winning
<nomagno>
Inescapable
<mrvn>
I want more ternary computers
<nomagno>
Ternary gates are a huge issue apparently
<mrvn>
type bool: true, false, maybe
<Griwes>
file_not_found
<mrvn>
In CMOS and the like the middle state is a huge power drain.
<nomagno>
Someone was making a ternary instruction set and they had hundreds of gates to choose from for opcodes
<kazinsal>
true/false/meh
<nomagno>
All of them useful
lainon has quit [Quit: lainon]
heat has quit [Remote host closed the connection]
Vercas5 has joined #osdev
zaquest has quit [Remote host closed the connection]
Vercas has quit [Ping timeout: 240 seconds]
Vercas5 is now known as Vercas
zaquest has joined #osdev
Vercas has quit [Remote host closed the connection]
Vercas has joined #osdev
<scripted>
whoops
<scripted>
its 4AM now
<scripted>
good bye
scripted has quit [Quit: WeeChat 3.5]
mahmutov has quit [Ping timeout: 248 seconds]
mahmutov has joined #osdev
<geist>
that happens
JanC has quit [Remote host closed the connection]
JanC has joined #osdev
* hodbogi
spins around yelling whee
<hodbogi>
Finished up some stuff for work
<hodbogi>
Even though I will probably lose my SSH connection before it's done running
rustyy has quit [Remote host closed the connection]
rustyy has joined #osdev
vdamewood has joined #osdev
heat has joined #osdev
<hodbogi>
You know I never tried but apparently readelf can read ar files.
<hodbogi>
And so can objdump. I shouldn't be surprised.
<heat>
yes it can
<hodbogi>
I just had this random hunch
<heat>
that's a great conversation starter
<heat>
you should try that on your next date
<hodbogi>
It was just nice that I was like. HM. I wonder if readelf will complain about this. Welp, I guess not.
<hodbogi>
tbf though the ar format is kind of dumb
<hodbogi>
For the reason that all of the digits are stored as ascii decimal
<hodbogi>
I always found that whack
heat has quit [Read error: Connection reset by peer]
heat has joined #osdev
srjek has quit [Ping timeout: 240 seconds]
<kazinsal>
it's an old interoperability thing
<kazinsal>
in an era where a machine word could be 12, 16, 18, 32, 36 or 40 bits, ASCII decimal does exactly what you would imagine a standard code for information interchange would
heat has quit [Ping timeout: 248 seconds]
seds has joined #osdev
mahmutov has quit [Ping timeout: 256 seconds]
hodbogi has quit [Ping timeout: 250 seconds]
Burgundy has joined #osdev
the_lanetly_052 has joined #osdev
the_lanetly_052_ has quit [Ping timeout: 246 seconds]
ThinkT510 has quit [Quit: WeeChat 3.5]
ThinkT510 has joined #osdev
pg12 has quit [Ping timeout: 272 seconds]
ThinkT510 has quit [Quit: WeeChat 3.5]
Clockface has quit [Read error: No route to host]
ThinkT510 has joined #osdev
pg12 has joined #osdev
Clockface has joined #osdev
Likorn has joined #osdev
Likorn has quit [Quit: WeeChat 3.4.1]
matthewm has joined #osdev
matthewm has quit [Quit: ERC (IRC client for Emacs 27.1)]
divine has quit [Remote host closed the connection]
GeDaMo has joined #osdev
pg12 has quit [Ping timeout: 256 seconds]
pg12 has joined #osdev
Mutabah has quit [Quit: leaving]
Mutabah has joined #osdev
Likorn has joined #osdev
sortie has joined #osdev
kingoffrance has quit [Ping timeout: 250 seconds]
simpl_e has joined #osdev
Likorn has quit [Quit: WeeChat 3.4.1]
<nomagno>
In reality we should probably switch to 6-bit ASCII
<nomagno>
Would require stripping a printable character or two
xenos1984 has quit [Ping timeout: 240 seconds]
xenos1984 has joined #osdev
<nomagno>
No
<nomagno>
I got the numbers wrong there
mahmutov has joined #osdev
sortiecat has joined #osdev
sortie has quit [Ping timeout: 256 seconds]
sortiecat is now known as sortie
kingoffrance has joined #osdev
CaCode has joined #osdev
junon has joined #osdev
<junon>
Is there any real-world reason to worry about page sizes other than 4096?
<junon>
Or is that a same assumption for most systems these days?
<junon>
Only really concerned about MMU-enabled platforms, not esoteric/low-mem platforms.
<junon>
safe*
<bauen1>
junon: Apples M1 useses page size of 16K iirc ?
<junon>
M1 uses page tables for describing used memory too, right? It's not different in that regard, just the page size?
<junon>
Sounds like Android also has weird page sizes now that I'm poking around a bit.
<bslsk05>
en.wikipedia.org: Page (computer memory) - Wikipedia
<junon>
Oh thanks!
bradd has quit [Ping timeout: 250 seconds]
mahmutov has quit [Ping timeout: 246 seconds]
heat has joined #osdev
dennis95 has joined #osdev
pg12 has quit [Quit: pg12]
ravan has quit [Remote host closed the connection]
ravan has joined #osdev
pg12 has joined #osdev
Brnocrist has quit [Ping timeout: 246 seconds]
<moon-child>
junon: hugepages?
<junon>
yeah but wasn't thinking about them I guess.
<junon>
But yeah you're right
<moon-child>
riscv supporting 512g and 256t pagesizes is kinda weird. At that point, why not just have a 'flat memory space' flag?
<junon>
no kidding
<zid>
did pml5 add 512G pages to amd64?
<zid>
or does that one not get that bit
<moon-child>
i don't think so?
<zid>
Mean, all the other tables get a cool bit to turn them into a range instead
<zid>
I guess it complicates the way they've designed the TLB too much
ravan has quit [Quit: Leaving]
<heat>
moon-child, it's not weird
<heat>
you need those pages for the big memory mapping almost every kernel has
the_lanetly_052_ has joined #osdev
the_lanetly_052 has quit [Ping timeout: 256 seconds]
srjek has joined #osdev
the_lanetly_052 has joined #osdev
the_lanetly_052_ has quit [Ping timeout: 246 seconds]
the_lanetly_052_ has joined #osdev
the_lanetly_052 has quit [Ping timeout: 256 seconds]
Teukka has quit [Read error: Connection reset by peer]
Teukka has joined #osdev
<Bitweasil>
junon, short answer, "Yes." ARMv8 allows 4k, 16k, or 64kb "small pages," plus the various large page sizes implied by those. And almost everything out there allows various large page sizes that are the "next layer up" of pages. How you handle that stuff in the TLB will be up to your system's requirements, but if you *only* handle 4k pages, you remove a lot of possibilities to run on platforms and to improve performance.
<Bitweasil>
ARMv7 supports a few different mergings of page size too, but it's not quite as gnarly as the v8 MMU.
<junon>
That seems to make generalizing a page allocator for all platforms rather difficult does it not?
<Bitweasil>
moon-child, zid, those "huge page sizes" are useful for doing things like persistent DRAM storage. There are some NVDIMMs (either battery backed or some other memory technology) that you can use as persistent disk, and if you're doing that, the sizes get big, quickly.
<Bitweasil>
So you can stuff one of those somewhere "not the DRAM region" in physical address space and map it with those huge pages to your database application or such, and have basically zero TLB overhead to your persistent storage.
<Bitweasil>
junon, yes and no. Linux has done a decent job of it. You just don't hard code page sizes into anything. The details of how your internal mapping goes to the MMU will be somewhat more platform specific, but conceptually, from the OS point of view, the difference between "I allocate 4k chunks to a process" and "I allocate 64kb chunks to a process" is just the size.
<Bitweasil>
But as x86 page tables are somewhat different in structure from ARM tables, you need something platform specific anyway.
<Bitweasil>
And ARMv7/ARMv8 tables don't really look like each other either.
<Bitweasil>
But they're still doing the same conceptual thing: Map some size region of virtual memory to physical memory, with some (mostly common) attributes.
* Bitweasil
wanders out.
<junon>
Thanks Bitweasil, this is great info. :)
mahmutov has joined #osdev
CaCode has quit [Remote host closed the connection]
<mrvn>
junon: Unless you do high performance clustering you probably will never need huge pages. Support just one base page size (e.g. 4k) is perfectly fine. The exception for mapping all of physical memory into the kerenl address space you can hardcode per arch. That's not something you will allocate dynamically.
<mrvn>
But if you want it's the same on all archs: N contigous physical pages suitably aligned build the next larger page size. Wether that's 4k/2M/1G or 4k/64K/2M/32M/1G or 16k/1M/... doesn't really matter to the algorithms you need to support it.
<mrvn>
Also note that 4k, 16k and 64k granularity on ARMv8 is optional for all 3. I assume the CPU must support at least one and currently there seems to be no example of a CPU not supporting 4k granularity.
<mrvn>
Personally I want to play with 64k pages as under linux that seems to be about the optimal buffer size for IO.
<merry>
mrvn: otomh, A-series Apple processors prior to A14 do not support 4kB pages
<heat>
linux is starting to support hugepages in the page cache afaik
knusbaum has joined #osdev
<heat>
an idea I had a few months back was to separate the notion of a physical page and a virtual page, and have virtual pages larger than physical pages
<heat>
e.g PAGE_SIZE would be 8192 but the CPU would still only have 4096 pages
<mrvn>
doing it for any initial mapping would be easy. Merging 4k pages to 2M is much harder.
<heat>
any allocations would be of PAGE_SIZE size, mappings of a page would map VIRTUAL_PAGE_SIZE / PHYSICAL_PAGE_SIZE pages
<mrvn>
heat: ARMv6 has 16k pages that are made up of 4x 4k pages. You have to set up 4 entries in the page table too.
<mrvn>
It's up to the CPU wether it handles them as a single 16k page or 4x 4k pages in the TLB.
<mrvn>
That's your idea in hardware.
<mrvn>
heat: If it's not supported by hardware do you think there is any benefit of having larger virtual pages? It's not going to save you anything and potentially costing you extra page invalidations and wasteagel from padding and fragmentation.
<mrvn>
heat: so have the app just do that. Why should the kernel inforce it where it isn't needed?
<heat>
1) most apps aren't aware of pages or page sizes
<heat>
2) lots of allocators tend to request an extremely small number of pages because they're scared to request for more memory
<heat>
3) most kernels' page caches don't support larger pages, so having more IO done in a single buffer is obviously way better
<mrvn>
stat() returns you the buffer size you should use for IO.
<heat>
4096 is also demonstratively small
<heat>
mrvn, nah, it tells you the block size
<mrvn>
And as for allocators change libc and you covered 99% of cacses.-
<heat>
and that doesn't matter because the page cache isn't in user-space
<heat>
oh also you start supporting larger block sizes
<heat>
it turns out you traditionally can't have block size > page size
<heat>
so it's currently maxed out at 4096 for compat reasons
<mrvn>
ahh sorry, statsfs I mean
<mrvn>
getting ext2 with 4k pages to work on sparc with it's 8k pages was a pain.
<mrvn>
block_size < page_size is bad too
<heat>
f_bsize is also the block size
<mrvn>
__fsword_t f_bsize; /* Optimal transfer block size */
<heat>
the "optimal" transfer block size is a fucking lie
<mrvn>
heat: then make it a truth
<heat>
it's very obviously the filesystem's block size
<heat>
with my idea, memory allocation would be faster, page caches would be better, filesystems could increase the block size
<heat>
you'd cache more in each page, so you need less pages, and buffering is more efficient
<heat>
even if a single page holds multiple fs blocks
<mrvn>
I don't see that: 1) malloc(2M)/free() will take the same time. It's the number of mappings and invalidations that matter. malloc(4k) will be half the speed. 2) page caches are under your control. make them use whatever. doesn't affect user space. 3) same again, that's kernel land
<mrvn>
zfs defaults to 128k blocks. The page size is not a hard limit.
<heat>
malloc(4k) will not be half the speed
<heat>
and malloc(2M) is faster because you can ask for more in each alloc_page
<mrvn>
heat: sure it will. you need to add 2 page table entries and have to invalidate 2 pages.
<heat>
malloc doesn't invalidate pages
<heat>
and adding 2 page table entries means that, oh no, you need to write an extra uint64_t!
<heat>
it's not half the speed
<mrvn>
heat: depends on your memory management in the kernel. free() certainly invalidates and every malloc and free must be matched. Count them as one.
<heat>
free() can also avoid invalidating if it's smart
<heat>
example: dirty bits, vm active masks
<mrvn>
I think you mean access bit.
<heat>
no
<heat>
wait, yes
<mrvn>
if a page was read it has to be invalidated. dirty has no real affect
<heat>
the A bit, yes
<heat>
and malloc and free don't need to be matched
<mrvn>
Not all archs have the A bit. Even archs (ARM) that have the A bit don't necessarily have hardware support for it.
<mrvn>
heat: malloc and free need to be matched or your code is incorrect.
<heat>
haha exit(2) goess brrrrrr
<heat>
you will need to track A/D bits independently of the CPU having hardware support for it
<mrvn>
sure, lots of incorrect code out there. but the amount leaked is usualy irrelevant compared to the rest of malloc/free.
<heat>
not incorrect
<heat>
every process cleans up all the memory
<heat>
this is not DOS
<mrvn>
heat: that's "working code" but not "correct code".
<heat>
sure is correct
<mrvn>
heat: no. correct code would also work on dos
<heat>
no because I don't write software for DOS
<heat>
my code is only sane-POSIX-systems-portable
<mrvn>
heat: that's how "working" is defined but not how "correctr" is defined.
<heat>
no.
<heat>
working is "it has bad memory corruption issues, but somehow, it's running fine, not sure how"
<mrvn>
heat: you lve in your world and I will live with everyone else in the standardized world.
<heat>
correct is "works according to spec defined by the target"
<heat>
ok sure
<mrvn>
by the way, with 8k virtual pages you have to handle 2 A/D bits. So that's twice the cost there. Hope it amortizes to the doule page size.
<heat>
how is it twice the cost
<mrvn>
1 bit vs. 2 bits each
<mrvn>
1 64bit value to check vs. 2.
<heat>
my out of order superscaler cpu will struggle to check 2 bits?
<heat>
it'll even do it in parallel
<mrvn>
that highly depends on your code.
<mrvn>
if (tbl[x].dirty || tbl [x+1].dirty) will kill your branch predictor.
<mrvn>
if (tbl[x].dirty | tbl[x+1].dirty) is probably 3 times faster
<mrvn>
I'm not saying virtual pages will be slower. But my feeling is that you need to be real clever writing the code to just keep the same speed and won't gain anything for sensible apps that already use larger blocks and allocations.
<mrvn>
And anything that really wants to use 4k pages because that's how the data is organized will loose.
<heat>
you literally said it's twice the cost. it's not twice the cost. most memory allocators do calculations based on the page size which is super tiny. most page caches are definitely bound by the page size, which is definitely tiny. most filesystem blocks are bound by the CPU's page size, which is definitely tiny
<mrvn>
heat: I said a 4k allocation is twice the cost because you have to allocate 8k.
<heat>
but it's not because the page allocator will hold 8KB pages instead of 4KB pages
<heat>
it's the same
<heat>
same latency, but larger sizes
<mrvn>
all the hardware parts are still 4k and you have to handle 2.
<heat>
so instead of a single mapping, I have two, how is that a big deal?
<heat>
you also get half the page faults
<mrvn>
heat: try it and measure. I think you won't gain anything and potentially loose half the speed.
<heat>
the only difference between my idea and selecting a larger CPU page size is that it works on CPUs that don't have variable page sizes(with the drawback that the TLB performance, and possibly page table walking, will be worse)
<mrvn>
heat: I also predict going to 16k or 64k pages will increase your gains and better amortize the costs. Maybe 16k breaks even and 64ik is a huge gain. But that's just a feeling. Needs to be implemenetd and measured.
<heat>
oh sure, actual mmu pages would be better
<heat>
but this works *everywhere*
<mrvn>
obviously measure it all with 4k pages.
<heat>
all my idea is doing is decoupling the notion of an mmu page and a system page
<heat>
it turns out the filesystem shouldn't care about how large the mmu's page size is
<mrvn>
heat: I get your idea and it's fine. I just don't believe it will benefit you for 8k pages.
<heat>
possibly not 8KB
<heat>
that was simply an example
<mrvn>
For my kernel it would be a huge slowdown since every syscall invalidates at least 2 pages.
<heat>
why?
<mrvn>
message passing interface. You gift a page to the driver.
<mrvn>
the result does the same gifting you a page back.
<heat>
idea: delay the invalidation as much as possible
<mrvn>
sure. or pass short messages in registers.
<heat>
every syscall invalidating pages isn't good
<mrvn>
that would assume you have a page to copy to
<heat>
zero-copy*
<mrvn>
So far my interfaces are 100% zero-copy and non allocating.
<mrvn>
Obvious exceptions like read allocating the buffer for the data you read.
Likorn has joined #osdev
<mrvn>
The nice thing is I really can do zero-copy all the way from user space through 20 processes for the IO layer down to writing to the physical medium. When you do a "write" the buffer becomes immutable even. No need to map it writable at all in the drivers.
divine has joined #osdev
<mrvn>
safety and security is a much bigger concern than speed for me.
<heat>
i don't think you need to do zero-copy with the MMU like that
<heat>
just pass your vm_objects around
<mrvn>
No. But I want to
<heat>
whatever keeps the pages, pass it like that
<heat>
you skip the mapping and do the DMA, etc directly
<mrvn>
NoteL: on a write drivers don't have to map the buffer. So something like a raid-1 just passes around the address and never maps the buffer.
<mrvn>
Just as is the message itself needs to be mapped. YOu have to access the control data.
<mrvn>
don't forget about iommu. DMA might have to map and unmap the buffer.
<heat>
that's actually a problem I have in my kernel
<heat>
I never map DMA
<mrvn>
heat: with 8k virtual pages you could do some nice stuff where 4k is read-only.
<mrvn>
The 2 halfs of the 8k page can have separate permissions for kernel and user.
srjek has quit [Ping timeout: 250 seconds]
rustyy has quit [Ping timeout: 256 seconds]
rustyy has joined #osdev
ravan has joined #osdev
ravan has quit [Quit: Leaving]
ns12 has joined #osdev
rorx has quit [Ping timeout: 248 seconds]
vdamewood has quit [Quit: Life beckons]
srjek has joined #osdev
<geist>
i think one of the MIPs MMUs looked like that
<geist>
something like it was a single TLB entry with a single base address but two permission bits
<geist>
for some reason
jjuran has quit [Quit: Killing Colloquy first, before it kills me…]
jjuran has joined #osdev
pretty_dumm_guy has joined #osdev
rorx has joined #osdev
arvimal has joined #osdev
vimal has quit [Ping timeout: 248 seconds]
sortie has quit [Remote host closed the connection]
sortie has joined #osdev
Likorn has quit [Quit: WeeChat 3.4.1]
dennis95 has quit [Ping timeout: 250 seconds]
dennis95 has joined #osdev
pretty_dumm_guy has quit [Ping timeout: 240 seconds]
arvimal has quit [Remote host closed the connection]
GeDaMo has quit [Remote host closed the connection]
tomaw has quit [Quit: Quitting]
tomaw has joined #osdev
wootehfoot has joined #osdev
<sortie>
It's one of those days building a gcc :)
<sortie>
Well it's a particularly cursed gcc build. You see I'm building it on the 1.0 release of my OS (from 2016) which although able to self-host the base system, it could NOT build all the ports including gcc. It could build *some* though.
<sortie>
I got the latest code from today onto a 1.0 VM and build the new base system, and then I started bootstrapping the new ports system (which can build itself) one by one, applying workarounds as needed. It's been tricky but I actually managed to build ALL THE PORTS, **except gcc**
<sortie>
Last I tried, gcc died with an OOM when building itself. I doubled the memory in the VM and giving it another try now. :)
<sortie>
If it works, then there is a viable reasonable upgrade path from 1.0 to the latest development version (which is fully self-hosting out of the box including ports), and therefore I can retcon 1.0 as self-hosting too, since it can become the latest version given the latest sources
<sortie>
So that's how I'm spending my easter vacation right now :)
* kingoffrance
waits for sortie bizkit one of those days gcc song
elastic_dog has quit [Ping timeout: 260 seconds]
stux|away has joined #osdev
vin has joined #osdev
<sortie>
gcc built!
stux|away has quit [Quit: Leaving]
<gog>
\o/
elastic_dog has joined #osdev
Likorn has joined #osdev
Matt|home has quit [Ping timeout: 246 seconds]
elastic_dog has quit [Remote host closed the connection]
stux has joined #osdev
dennis95 has quit [Quit: Leaving]
elastic_dog has joined #osdev
scripted has joined #osdev
<scripted>
hello everyone
elastic_dog has quit [Ping timeout: 248 seconds]
<gog>
hi
<zid>
ih
<zid>
do you have an appointment
<zid>
we do take walk-ins but you may have to pay a rebooking fee
elastic_dog has joined #osdev
<heat>
is this osdev tech support
<klange>
This is OSdev therapy
<heat>
hi klange, how do I open microsoft word in my OS
<mjg>
have you ported vim?
<mjg>
vim word.exe
<heat>
my son told me to use "libreoffice" but i want to use microsoft word
<mjg>
oh, you want to use it
<heat>
what's vim?
<mrvn>
at least use works
<mrvn>
heat: notepad
<mrvn>
less the interface
<heat>
can i use wordpad?
<mrvn>
I'm not sure. can you?
<heat>
i dont know that's why im askign tech support
<heat>
but you're not being very helpful
<mrvn>
how should we know what you are able to do?
<mrvn>
did you mean "may I use wordpad?"
<heat>
yes
<mjg>
heat: your inquiry is very important to us
<mjg>
please hold
<heat>
hello? hello?
<heat>
damn they hanged up on me
<heat>
microsoft tech support is getting so much worse these days
<mrvn>
your sould is delicious, please hold.
<mrvn>
while you wait: have you installed nosmoke.exe?
<heat>
no but i also dont smoke
<mjg>
you do smoke if you don't have nosmoke
<mjg>
albeit it is passive
<kazinsal>
which is different than if you don't got nosmoke
<moon-child>
I know somebody who programs solely in wordpad
<zid>
wordpad < notepad
<gog>
mew.exe
<moon-child>
wineserver -[O]w[O]
<gog>
uwu
<heat>
OwU
<Ermine>
pet-gog.exe
<gog>
pet-gog.exe has encountered fatal exception 0E
<moon-child>
wineboot -r
<Ermine>
osdev is collecting more information about this problem
<mjg>
would you like to send an automatic bug report?
<moon-child>
well it's not particularly automatic if I have to send it, is it?
<heat>
ok write the .dmp yourself then
<mrvn>
"Fear is the path to the dark side. Fear leads to anger, anger leads to hate, hate leads to suffering." "You know what suffering leads to? Javascript"
<mjg>
see, rebels think they blew up the death star
<mjg>
what actually happened is that node.js crashed into fucking oblivion
<mjg>
it was just funny timing
<mrvn>
this is not the death star you where looking for