<the_oz>
Why not use the name tasklet? The scope of the application is limited, but I mean I see nothing wrong with describing the "software interrupt request handling jump spot residing code"
jistr has joined #osdev
<the_oz>
It's clearly a loaded context of task that's the problem, the "wrong" is an assumption of what a task should be and who should use it
Enapiuz has quit [Quit: Connection closed for inactivity]
voidah has joined #osdev
gog has quit [Ping timeout: 265 seconds]
X-Scale57 has joined #osdev
X-Scale has quit [Ping timeout: 256 seconds]
X-Scale57 is now known as X-Scale
edr has quit [Quit: Leaving]
Dead_Bush_Sanpai has quit [Read error: Connection reset by peer]
Dead_Bush_Sanpa1 has joined #osdev
Burgundy has quit [Remote host closed the connection]
TkTech has joined #osdev
Dead_Bush_Sanpa1 is now known as Dead_Bush_Sanpai
Arthuria has joined #osdev
DrPatater has quit [Quit: Explodes into a thousand pieces]
<kazinsal>
did the colonel tell you about the papers?
<mjg_>
is dat.tru
<kazinsal>
the papers, come on, he should have told you about the papers
<mjg_>
cause it's a millenial meme
<nikolar>
mjg_: it's not a meme, it's a tradition
<nikolar>
heat: how's your networking rewrite going
<kazinsal>
you can't go and see colonel blake
mavhq has joined #osdev
<kof673>
https://0x0.st/s/mFS6_KNr3n5hzWVUHfzYtQ/XxDe.tar.xz patches for gcc 4.1.2 (well, c language anyways) targeting bf "machine" ...sort of works, was there http://codu.org/projects/gcc_bf/ but vanished, wayback machine does not have either "assemblable brainfuck instructions", it outputs an "assembler" format that a perl script serves as linker to rewrite ...~400K "Hello world" 80M without run length encoding
<bslsk05>
codu.org: 404 Not Found
<kof673>
sadly, loops appear busted, the linker does not recognize some instructions that are output...but it can do equivalent of putchar() and getchar() lol the included libc e.g. malloc()/memcpy()/ seem busted :/
<kof673>
would make a nice target if it worked better :/
<kof673>
*4.2.1 i see everyone is amazed and ready to fix the bugs
gog has joined #osdev
youcai has quit [Read error: Connection reset by peer]
youcai has joined #osdev
youcai has quit [Read error: Connection reset by peer]
leon_ has quit [Ping timeout: 252 seconds]
aejsmith has joined #osdev
youcai has joined #osdev
leon has joined #osdev
jedesa has joined #osdev
netbsduser has joined #osdev
X-Scale has joined #osdev
youcai has quit [Read error: Connection reset by peer]
youcai has joined #osdev
X-Scale has quit [Ping timeout: 256 seconds]
nortti has joined #osdev
youcai has quit [Quit: No Ping reply in 180 seconds.]
youcai has joined #osdev
<the_oz>
why are you torturing a simple macro job
<kof673>
https://github.com/giuseppe/gccbrainfuck that seems to work too, gcc 6.1.0 frontend, bf -> machine code. it will even take the ~400k output file from the c -> bf gcc, spit out a ~3M binary, but sadly, it segfaults when ran
<bslsk05>
giuseppe/gccbrainfuck - A Brainfuck frontend for GCC (2 forks/12 stargazers/GPL-3.0)
<kof673>
https://github.com/jroivas/optimized_bf_compiler says it will "transcompile" BF to "optimized" C or python, it is just a 319-line python script. anyways...i just like to have lots of toolchains handy :D
<bslsk05>
jroivas/optimized_bf_compiler - Optimizing Brainfuck compiler, transcompile BF to optimized C or Python (0 forks/0 stargazers)
<kof673>
i would use the first c -> bf gcc as a "target" if it worked better, but seems too buggy if loops just vanish :/ i am not rewriting code without loops just for that :/ i tried goto, no luck :/
<kof673>
it is just normal little endian 8/16/32/64 perhaps, so nothing special, just another target if it worked...
<kof673>
it is enough for "cat" from stdin to stdout i guess...
<kof673>
if these all worked together, you would have a nice 3-headed dragon, c -> bf, bf -> c, bf -> executable.
<heat>
nikolar, its going well, it's reaching feature parity while being 100x more correct
<heat>
but i'm only rewriting the tcp bits, the rest was fine
<zid`>
nikolar do you wanna write a shitty compiler in bison/yacc or something
<nikolar>
Of course
<zid`>
k teach me
<nikolar>
Sure, what are we writing
<nikolar>
heat: cool stuff
<zid`>
I actually did do some a while back for advent
<heat>
yeah. i was playing around with qemu and bridged networking but it seems like it's fucked yo
<heat>
the whole setup that is
<zid`>
I think it's.. in a vmdk though
<heat>
the dnsmasq instance that someone (networkmanager??) spawns does not respond to my dhcp packets (but it does to alpine), i'm not even in the logs
<nikolar>
Kek
<zid`>
I have a parser somewhere
<heat>
ipv6 wise no one seems to get ipv6 in the bridge
<kof673>
i will look at elvm, thanks. it is possible the gcc bf -> machine code will take the c -> bf output of the other...it perhaps just silently ignores the "RLE", so it might be fine with ~80M non-RLE....
<kof673>
400k already takes ~1m 1/2 for me, so ...not sure i wanna try that theory
<heat>
mjg_, mon what do you think about the venerable bsd network stack
<nikolar>
zid`: is that just a calculator
<zid`>
It's a parser
<zid`>
that can do a couple of ops
<zid`>
it needs a function per precedence as written though, so it needs converting to a generic boi and a loop with an int prec
<zid`>
and each operator tagging with its precedence
<nikolar>
Just yacc it
<zid`>
Yea but yacc is hard and can't handle typedef
<zid`>
and it's cooler if you wrote it all yourself
<nikolar>
Sure but parsers just suck lol
<zid`>
yes
<zid`>
but it makes a TREE :o
<zid`>
trees are cool
<nikolar>
Indeed
<nikolar>
My favourite kind of parser is when I do: (struct ipframe *)buff
<zid`>
'favourite kind of parser'
<zid`>
I think you should be shot
<mjg_>
heat: it sucks
Enapiuz has joined #osdev
<heat>
damn ok plain and simple
<heat>
muh tcp_output and tcp_input though :/
<mjg_>
that's ip_input
<mjg_>
one of the total sucksorz is webdev handling of ref counts
<heat>
nah tcp_input unless someone changed it in the meanwhile
<mjg_>
the entire thing was written with the idea that nothing ever disappears
<mjg_>
bro
spareproject has joined #osdev
<mjg_>
watch any bsd vide oabout people complaining about the network stack
<mjg_>
and you will see it is ip_input
<heat>
BRO
<heat>
those are two separate functions
<heat>
maybe they renamed it, but tcp_input has historical meaning
<heat>
* TCP input routine, follows pages 65-76 of the
<heat>
* protocol specification dated September, 1981 very closely.
<heat>
*/
<heat>
void
<heat>
tcp_input(m, iphlen)
<mjg_>
huh tcp_input_with_port(struct mbuf **mp, int *offp, int proto, uint16_t port)
<mjg_>
stil there indeed
<mjg_>
altho!
<heat>
THEY ADDED A PORT?!
<mjg_>
int
<mjg_>
tcp_input(struct mbuf **mp, int *offp, int proto)
<mjg_>
}
<mjg_>
{ return(tcp_input_with_port(mp, offp, proto, 0));
<mjg_>
geezeres don't disappoint
<heat>
yessir let's go
<mjg_>
someone named F. Ucker wrote taht
<nikolar>
So zid`, what kind of language are we writing
<zid`>
nikolar: you just said it was a bad idea and we should use yacc
<zid`>
then that you had a FAVOURITE PARSER
<zid`>
so I'm confused about your life choices
<heat>
it is quite impressive how unterrible the 4.4BSD tcpip stack is compared to the rest of the system
<heat>
it does things *properly*
<mjg_>
wdym properly
<mjg_>
some of it had to line up with rfcs of the time to get the shit accepted
<mjg_>
but past that the ffcs were propably describing accdents of the implementatin
<nikolar>
zid`: the joke was that my favorite parser is no parser
<heat>
the tcp/ip stack is somewhat complex, follows rfcs relatively closely, and in general is pretty nice
<zid`>
nikolar: Still a problem
<heat>
in comparison, mmap was written while someone was on the toilet
<zid`>
anyway, how do I add like, blocks and shit
<zid`>
wrap this thing in another thing?
<nikolar>
Basically
<zid`>
open block, run parser until close block, done
<zid`>
link block to block tree
<nikolar>
Yeah
<zid`>
okay that's doable
<zid`>
but I should fix this up first
<nikolar>
Boring old recursive decent
<zid`>
did you see term() and factor()
<nikolar>
I haven't checked in detail
<zid`>
it's trying to figure out a+b*c^d or whatever
<zid`>
so it recurses to find the highest precedence thing so it can return them out of order if needed
<bslsk05>
github.com: GitHub - phil-opp/blog_os at post-02
<dostoyevsky2>
> This project requires a nightly version of Rust because it uses some unstable features.
<dostoyevsky2>
That's still the bane of Rust projects these days, though....
arminweigl has quit [Ping timeout: 252 seconds]
arminweigl_ has joined #osdev
arminweigl_ is now known as arminweigl
<zid`>
'these days'
<zid`>
meaning 'all days'
goliath has quit [Quit: SIGSEGV]
<nikolar>
kek
<zid`>
Did you manage it yet nikolar or was it too tough?
<nikolar>
nope
<nikolar>
wasn't doing that
<zid`>
well if you can't do it you can't do it
<dostoyevsky2>
imho they shouldn't use Rust in the linux kernel unless they can do it without nightly...
<zid`>
and without panics
<zid`>
and without a 30GB compiler install
deriamis has quit [Ping timeout: 252 seconds]
deriamis has joined #osdev
<nikolar>
zid`: the more i think about it, they just shouldn't use rust in the kernel :P
<zid`>
Maybe we can like, make a fuse that isn't slow and bad, and they can write filesystems in it from userspace
<nikolar>
maybe
<nortti>
do you mean panic! or do you mean kernel panics? since the former is, aiui, a kernel oops in-kernel
<zid`>
rust panic
<zid`>
it's a fancy modern high level language so it does things like allocate memory to use basic operators
<zid`>
which can oom, and it has to signal "add doesn't work" somehow
<nortti>
not in the kernel?
<zid`>
and it does that by calling abort()
<zid`>
it's like having exceptions
<nortti>
like, I know what you're talking about, but rust-in-linux does not have those APIs
<zid`>
and nobody uses those for obvious reasons
<dostoyevsky2>
didn't netbsd have some api to run drivers in userspace? Some userspace thing would have been a great first introduction of Rust code
<nortti>
rump kernel?
<Maja_>
zid`: wdym 30GB, it's 470MB, about as much as clang or gcc
<zid`>
It takes 30GB to install rust
<zid`>
I had to add new virtual disks to my machine every time rust wanted to update
<zid`>
which is frequently, because everything needs rust nightly, and also wants to update
<dostoyevsky2>
don't they call it anykernel now?
<dostoyevsky2>
But I think it just refers to the fact that drivers use an internal API to communicate with the kernel, not necessarily that those drivers run in userspace
<dostoyevsky2>
but if you write your own OS and implement the netbsd anykernel API you can reuse their drivers
<Maja_>
zid`: wait, what basic operators allocate?
<Maja_>
I can't think of any
<Maja_>
panics are more like "errors for which you probably want to exit with an error message anyway", like "you explicitly requested a heap-allocated resizable collection and the heap allocation failed. and you didn't use the 'let me handle the error myself' API"
<zid`>
yes, which is why everyone was like "We won't use rust until that api exists"
<nortti>
well it does?
<zid`>
because the way it was all written was to panic, not return Result and make alloc failable
<zid`>
it's probably better now
<zid`>
it's several years on
<Maja_>
yes, because that's what you want in most programs
<nortti>
yeah, like, the rust-in-linux project has been working with the rust upstream a lot to make sure everything they need for these is a) possible upstream b) possible without nightly
<nortti>
atm b is still not done, annoyingly
<netbsduser>
rust "panics" are just exceptions but They Really Arent Exceptions We Swear On Our Lives
<kof673>
"both?" "the two truths doctrine" j/k > NetBSD allows transparently mounting an untrusted file system image by running the kernel driver in a rump kernel in userspace > The integration of the puffs and rump # puffs is/was a fuse-like thing IIRC
<zid`>
yea I mentioned it's basically just exceptions
<zid`>
Manish Goregaokar implemented the fallible `Box`, `Arc`, and `Rc` allocator APIs in Rust's `alloc` standard library for us.
<zid`>
etc
<kof673>
i always thought of the name "rump" as "leftover", meaning can slim down to just what you need > rump kernel: partial kernel consisting of unmodified NetBSD kernel drivers
<kof673>
(e.g. for bare metal)
<netbsduser>
i don't know why they are so keen on denying that they are exceptions a la c++
<Maja_>
are they?
<zid`>
you just need to do that for everything in std, first, then you can talk about about rust outside of userspace, but it sounds like a lot of that work is now done
<Maja_>
as in, are they keen on denying it?
<netbsduser>
Maja_: yes, we were always at war with east^H^H^Hxceptions
<nikolar>
netbsduser: because they already have a way of handling errors (Result)
<Maja_>
the culture is different in that the primary usecase for catching panics is "die more gracefully" and not general error handling (because Result exists)
<nikolar>
and realistically, that's a better way of handling errors
<zid`>
alloc still panics exclusively, as far as I know
<Maja_>
and the fact that there is no special syntax for throw nor catch
<netbsduser>
these are not arguments against the point
<Maja_>
panics are basically setjmp
<nortti>
nikolar: out of interest, do you think `x + y` should return a Result?
<nortti>
or array access
<nikolar>
no
<netbsduser>
it's like saying a ream of paper is different if i sell it under the tagline "Great for printing on!" but i sell another ream under the tagline "Great for fountain pens!"
<zid`>
exceptions are a design feature that's required by a lot of languages where you can do bullshit inside operators, yea
<zid`>
that's also why I don't like C++
<nikolar>
nortti: what i was saying is that they don't like thinking of panics as exceptions because they already have a error handling mechanism
<zid`>
people will just stuff random crap into operator overloads, then exception their way free of it
<nortti>
ah, okay
<zid`>
(and look how good C++'s std is because of that)
<netbsduser>
nikolar: i think they are tilting at windmills
<nikolar>
it's a piece of art zid`, you're just jealous because you don't have that in c :P
<Maja_>
zid`: what should a[i] do if i is out of bounds?
<nikolar>
netbsduser: well they are, they use rust :P
<netbsduser>
rust can claim all they want that they were always at war with exceptions and that panic is not exceptions, but in truth, it is exceptions
<nikolar>
Maja_: it shouldn't bring the whole kernel down
<Maja_>
nikolar: yeah, I thing rust's panics map to kernel oops?
<zid`>
Maja_: panic is fine, but it needs to be user controllable
<nikolar>
they shouldn't
<nikolar>
that's the point
<nikolar>
or rather, stuff shouldn't panic
<Maja_>
i mean, oops kills the kernel thread, right?
<zid`>
We caught it *before* any memory corruption happened, so it should be fine to WARN() and kill that process
<zid`>
oops kills the entire kernel
<zid`>
wait
<Maja_>
i think that depends on the settings you have?
<zid`>
no, I think oops is what I want
<gog>
oops
<nortti>
lol
<zid`>
gog did you ever find a real tree
<gog>
no
<zid`>
one day!
<Maja_>
you can have hardening options that turn oops into panic
<zid`>
panic is the super fatal one, oops is the kill the process(s) one, but an oops might panic if you have a lock or whatever
<Maja_>
yeah, fair
<nikolar>
basically, not good either way
<Maja_>
this is basically the lock poisoning usecase
<zid`>
malloc() has the high-z result of 'NULL' for precisely this reason, a[i] is the tricky one
<zid`>
I'd say a[i] being OOB is always a bug though
<zid`>
and malloc failing is semi-excpected
<zid`>
so it makes sense that a[i] would panic -> oops, and malloc should just fail. But the problem is then, what happens if + can malloc
<zid`>
you need to be *incredibly* careful about doing things that *can* oops, inside code that can't return errors
<Maja_>
+ can malloc if you're using a bignum library i guess
<Maja_>
i.e. not the kernel usecase
<nikolar>
see, operator overloads hide crap
<nikolar>
and you need a lot of context to know if something panics
<zid`>
and I don't think rust helps at all, like, its usefulness is that it can stop you accidentally losing pointers to objects and leaking them
<nikolar>
which isn't even in the overload inteface
<zid`>
not stopping you calling panic() inside code that can't return a value
<zid`>
So it turns into the "safe subset" game that C++ plays, my favourite
<nikolar>
kek
<Maja_>
well, the difference is that you can tell the compiler "can i have the no-panic subset please" and it'll tell you if you screw up
<zid`>
can you?
<zid`>
I wasn't aware rust had that capacity
<netbsduser>
speaking of C++, a gang of two have proposed a safe c++ which is basically a reprint of rust: https://safecpp.org/P3390R0.html
<bslsk05>
safecpp.org: Safe C++
<nikolar>
lel
<nortti>
there are ways to deny panic on whole-program level at least, tho aiui those are based on linker, not compiler
<nortti>
as in, the link will fail if anything can panic
<nikolar>
at least you can know if panics can happen in your code
<zid`>
heh that's a smart way of doing it
<nikolar>
still not where, or wahy
<zid`>
you can do it that way in C too I guess
<nikolar>
kek
<zid`>
just see if anybody tries to import kernel_panic()
<dostoyevsky2>
netbsduser: Wouldn't be bad to have a safe-mode in C/C++...
<nortti>
why?
<nortti>
or, misread, sorry nvm
<nikolar>
zid`: what if you actually want a panic then
<zid`>
I like the idea of a very anal C, a-la rust, but anal about its UB not about thread safety
<nortti>
thread safety is UB in C tho?
<zid`>
I think you missed the point?
<nikolar>
kek
<Maja_>
zid`: there's clippy lints you can opt into that scream about all arithmetic operators that aren't explicitly wrapping_add or something that handles overflow explicitly
<zid`>
Maja_: yea stuff like that
<Maja_>
same for array indexing with [] instead of .get()
<zid`>
Just a very very aggressive linter that's like "I can't prove this is safe, annotate it or fix it"
<Maja_>
(which returns Option and you handle the None)
<Maja_>
they're doing PLT research, they probably know a dozen languages at a good level
Artea has joined #osdev
<zid`>
"We should make C safer, we should make sure people trust us, by writing all the C in the style of another language" isn't a good look, though
<zid`>
no matter how many dozens of languages they know
<zid`>
I'm not sure knowing dozens of languages is the prime requirement for knowing the precise pitfalls of C
<Maja_>
i think the target audience is people who know rust well enough to know when it isn't enough
<Maja_>
because refinedc is basically rust but worse
<zid`>
You can make rust worse? :o
<Maja_>
because that's what you're gonna get if you ask for "c but correct"
<zid`>
We should be giving them funding
<zid`>
If you ask for C but correct you definitely don't get rust
<Maja_>
ah, right, you can also get seL4
<zid`>
else i'd be able to return 42 from main
<zid`>
which is apparently just entirely unsuppo`rted
<Maja_>
what?
<zid`>
(thanks for the random backtick, high quality razor keyboard)
<zid`>
try it lol
<netbsduser>
i suspect what most people who use rust like is not the safety stuff but rather the expressive type system
<Maja_>
zid`: return 42 from main in... refinedc?
spareproject has quit [Remote host closed the connection]
<zid`>
what
<Maja_>
or in rust?
<zid`>
19:58] <Maja_> because that's what you're gonna get if you ask for "c but correct" [19:58] <zid`> If you ask for C but correct you definitely don't get rust [19:58] <zid`> else i'd be able to return 42 from main
<zid`>
how did you get refc from that
<netbsduser>
a bit like how a lot of people writing c don't need it for the speed (java is plenty fast) but for it being "value-neutral" and hence fitting well into systems
<netbsduser>
every other language's FFI boils down to C for a reason
<dostoyevsky2>
netbsduser: isn't the type system rather limited in Rust? Not sure what e.g. the Rust type system can do that C++ couldn't ...
<Maja_>
zid`: so you're complaining that you need to use std::process::exit to choose the exit code?
<zid`>
I'm not complaining?
<zid`>
I was directly refuting a thing you said with an example
<zid`>
oh and it'd have a ++ operator
<nikolar>
zid`: but pre/post increment evil :(
<zid`>
My favourite rustism is that the rust parser knows about ++
<zid`>
knows what it does, what you intended
<zid`>
then shouts at you for trying to use it instead
<Maja_>
yes, it also knows that greek question marks look like semicolons
<zid`>
"You have tried to use the VERBOTEN EVIL POST-INCREMENT OPERATOR, PLEASE DESIST"
<zid`>
"I HAVE SPAT OUT A .patch FILE TO FIX IT FOR YOU"
<zid`>
Fucking just skip all that and apply it internally then you bell-end
<Maja_>
if you're doing nice error messages, you only need to support the common case. if you're actually putting it in the language, you need to support everything around it
<zid`>
and let me use my ++
<Maja_>
do you really need to increment variables that often for this to matter?
<nikolar>
have you seen any c code ever
<zid`>
walking runs of data or lists etc is like, one of the only things I *ever* do
<bslsk05>
doc.rust-lang.org: ExitCode in std::process - Rust
<nikolar>
zid`: it just immitates c :P
<zid`>
wait is that
<zid`>
#![no_main] thing
<zid`>
like using _start
<nortti>
Maja_: oh yeah, I know how you're supposed to do it if you're using the normal rust main. just wanted to show zid` that if you really want to, you can indeed return 42 from main
<nikolar>
Maja_: so compiler is generating a bunch of stuff in the background that it needs to otpimize away
<nikolar>
just so i don't have to type i < sz; i++
<zid`>
what if I don't know the length though, and I'm relying on a check mid-parse?
<zid`>
which is also common
<nikolar>
also what happens when that happens too deep, and the optimizer gives up
<bslsk05>
doc.rust-lang.org: Crates and source files - The Rust Reference
<nikolar>
so you just get a bunch of generated code instead of i++ :P
<zid`>
nortti: right, so it is basically doing what I said? Not using the hosted entry point, and instead basically being like _start, to make it a 'normal' function, which can thus return
<nikolar>
zid`: don't forget, it's implicitely linking with libc (i think)
<nikolar>
so it's pretending it's c's main returning 42
<nortti>
^
<zid`>
so is that a yes?
<nortti>
basically, make it conform with the ABI expected by C runtime directly
<nortti>
still using _start though
<nikolar>
yeah using glibc _start or musl or whatever
<Maja_>
zid`: realistically you probably iterate over your input data and break out of the loop if the input data tells you to
<zid`>
Maja_: hence me using ++
<zid`>
like, strcmp is just a++; b++;
<zid`>
memcpy, strcpy, blah blah
<zid`>
90% of C is just small ++ loops :P
<nikolar>
kek
<Maja_>
and somehow Rust is not 90% of small += 1 loops
<zid`>
Because, as I've mentioned
<zid`>
is it not, infact
<nortti>
zid`: do you know what an "iterator" is?
<zid`>
what you'd get if you "made C safe"
<nikolar>
i imagine someone's rewritten string.h in rust
<zid`>
nortti: what's that in reference to?
<nikolar>
i want to see what that looks like :P
<nortti>
zid`: iterating over input data need not involve writing a small ++ loop
<zid`>
nortti: ofc it "need not"
<zid`>
but that's very very very very very very very idiomatic C
<zid`>
so again, what are you talking about?
<Maja_>
zid`: yes, because the more large-scale things you'd need to do to "make C safe" cannot be noticed if you're to stubborn to properly try using the thing and need to focus on superficial syntax differences
<nikolar>
slol
<nikolar>
*lol
<zid`>
so you're both telling me "we changed so much it's unrecognizeable" and that "you can't just look at the things you can see"
<zid`>
but that it's the same thing underneath
<zid`>
I'm.. not buying that
<zid`>
That thing you linked earlier is much more what I would expect "we made C safe" to look, toher than the fact it was C++ made safe instead
<kof673>
slol, lines of lolcode, sounds like the measurement utility for the m j g enterprise machines corp. there is only less-pessimal, no optimal, they are golf-like scores
<nikolar>
kek
<nortti>
to be clear, I'm not saying that rust is just "C made safe", it's got a lot of support for abstractions that C lacks, you could make a much more spartan "C made safe" that would support more, but not all, idiomatic C constructs
<zid`>
nortti: no, but maja did
<nortti>
you could even use i++, and eat the performance cost over iteration
<zid`>
nortti: you're just saying that you don't need ++ as much in rust, because iterators, which I agree with
<nortti>
aye
<Maja_>
look, fact is, writing correct C requires keeping track of a lot of shit that you just implicitly keep in your head
<zid`>
but it also proves *my* point, that rust doesn't look like C made safe
<zid`>
it looks like rust
<Maja_>
if you want to make it safe, you need to talk about it with the computer, so you need syntax to talk about it
<Maja_>
they can invent new, bespoke syntax, or they can borrow it from some other language
<zid`>
yes, and none of the syntax looks like C syntax, it looks like rust syntax
<zid`>
C has progressively added things to make it safer and easier to use
<zid`>
and none of the things that were added, look like rust
<nikolar>
but zid, ++ is inherently unsafe clearly
<nikolar>
that's why you can't use it in rust
<nortti>
lol
<nortti>
honestly should say that for any feature of C that rust doesn't have to reduce complexity
<zid`>
I could make a compelling safety argument to remove ++ tbh
<nortti>
octal literals with just 0- prefix? yeah those are unsafe
<zid`>
nortti: Yea I'd bin those if I remade C
<zid`>
I don't need the odd case of open (0377) or whatever to work
<nortti>
vertical tab escape in strings? unsafe
<nikolar>
just 0o123
<Maja_>
zid`: and none of the things let you specify whether, if you give a reference-counted thing to a function, said function should increment the reference count if it wants to keep using the object after returning
<zid`>
compared to the 20 times I've fucked it up and used \012 in a literal accidentally
<Maja_>
or if a function should free the thing you're giving it
<nikolar>
nortti: vertical tab escape?
<nortti>
nikolar: \v
<nikolar>
ah
<zid`>
Maja_: You know how you'd do that if you started with C, and not something else entirely? Something like 'restrict'
<nortti>
Maja_: you could use a more C-style way of annotating those, though
<zid`>
f(char owner *a);
<zid`>
and it'd be a semantic error to pass a pointer in that you didn't own
<zid`>
etc
<zid`>
it would *not* look like rust's borrow checker with let and mut
<zid`>
that makes it look like javascript :P
<nortti>
funnily enough I'd say what you presented there "looks just like rust's borrow checker", because in my mind that'd refer to the semantics, not surface syntax
<zid`>
nortti: ? All safe languages have the same semantics.
<Maja_>
okay, how do you annotate that, in strstr, the returned pointer points to the same memory as the haystack, so you need to keep the haystack alive as long as you want to use the return value, but you can free the needle?
<zid`>
but different syntax
<nortti>
right, which is the point Maja_ has been trying to make
<zid`>
Maja_: convert it to an offset
<zid`>
nortti; No, what I said is *my* point.
<Maja_>
zid`: okay, how about returning a node from a btree?
<zid`>
You would not have the syntax rust has, if your goal was "start with C but make it safe"
<zid`>
Maja_: HANDLE
<Maja_>
(rust would do fn strstr<'a>(haystack: &'a [u8], needle: &[u8]) -> &'a [u8] or whatever)
<zid`>
Rust very clearly is not C made safe, it's some 2nd cousin
<Maja_>
zid`: you can't do system programming like that
<nortti>
(syntax inspired by the type-safe-void* proposal)
<zid`>
because one is C made safe, and one is rust
<Maja_>
I'd say that it looks almost exactly like rust's borrow checker
<zid`>
I'll let you figure out which is which
<zid`>
It's a struggle, so I'll give you two guesses
<Maja_>
only that you use [ instead of <
<Maja_>
which is obviously an important difference you need a research grant to achieve
<zid`>
How can I compete with incredible arguments like "Well it looks identical if you change how it looks"
<zid`>
I'm beaten
<nortti>
Maja_: zid is talking purely on the level of syntax, not semantics
<zid`>
I don't think you'd end up with *identical* semantics, mind, but they would *necessarily* be broadly similar, if you wanted broadly similar safety
<Maja_>
nortti: right, because the syntax is the easiest thing to have opinions about
<zid`>
Like how aarch64 and x86_64 both implement 'modern architecture with registers and pointers and stuff' and have caches and all the sorts of thigns cpus have, but have quite different looking assembly
<zid`>
There's very little practical difference between thetwo
<nortti>
very C-y, incrementally applicable, zero-runtime-overhead
<zid`>
but the lineage and syntax is wildly different
<zid`>
Rust is very clearly ARM to C's x86, in this example, not x86s
<zid`>
nortti: Title is nice
<zid`>
oh they've started speaking haskell and C++ immediately, I may not be able to follow this
<Maja_>
I'd say that it's neither ARM nor x86s. more like, Itanium if the bold ideas were actually good
<zid`>
So now you agree with me all of a sudden
beto has quit [Read error: Connection reset by peer]
<zid`>
Your entire claim so far is that rust is x86s
<zid`>
mine has been "no it's fucking itanium lol"
<Maja_>
no, my claim is that to make C safe, you'd need to give it things like manual prefetching and instruction bundles
<Maja_>
and nobody cares if you call the instructions with the same names as beloved old x86
<zid`>
the fuck
<nikolar>
lol wat
<Maja_>
to continue the analogy
<zid`>
to throw it out of the window
<Maja_>
look, clearly the things that make Rust unique is not the lack of the ++ operator
<zid`>
if we were talking about what made rust unique
<zid`>
that might be relevent
<zid`>
it is however, absolutely not, and isn't
<zid`>
nortti: I can't read a word of the rationale paragraph unfortunately
<zid`>
I'll try the rest
<Maja_>
yes, because you're too picky to try anything that looks too different from C
<zid`>
again, absolutely *not* what was being discussed
<nikolar>
lol wat
<zid`>
my like or dislike for rust is *completely irrelevent* to whether rust is C-made-safe, or a complete from fresh new language
<zid`>
it's *absolutely* the latter
<zid`>
and every single thing about the language shows it
<Maja_>
I mean, it is very much the reason you wouldn't be able to understand a document that wants to explain how to achieve $thing in terms of how other languages achieve $thing
<zid`>
yes, me not understanding haskell is indeed, why I cannot follow a document trying to explain C in terms of haskell, what of it?
<Maja_>
my point is not "rust is C-made-safe", that'd be RefinedC. my point is "if you want 'C but safe', you will need an equivalent for some of the core features of Rust, the features that make Rust unique"
<zid`>
no, that was infact, your exact point
<zid`>
that I spent 20 grueling minutes trying to refute
<zid`>
<Maja_> because that's what you're gonna get if you ask for "c but correct"
<zid`>
I've quoted this several times, because you said it, then engaged with me when I argued against it
<zid`>
If you meant "you're going to end up with new and different syntax", that's a much softer claim that is absolutely true and all four of us readily agreed with it
<zid`>
and even tried to use it to talk *you* out of what you said
<zid`>
which was the much much harder version, that we disagree with
<Maja_>
> "rust but worse" is what you're gonna get if you ask for "c but correct"
<zid`>
it comes across as you backpedalling
<zid`>
without admitting you maybe over-played your hand a little
<Maja_>
i.e. you'll need to graft on deep, semantics-affecting features, which will make it basically rust, but worse, because you're grafting on features instead of designing the language to accomodate them
<zid`>
You don't have to end up with anything that looks anything like rust
<zid`>
we even gave you exact examples of doing precisely that
<nikolar>
Maja_: you do realise that rust was well under development by the time it got the borrow checker
<nikolar>
just checking
Dead_Bush_Sanpa1 has joined #osdev
<Maja_>
yes, that's what made it a unique language worth paying attention to
<nikolar>
lel
<Maja_>
(and yes, I'm aware of previous research languages with region checking)
<zid`>
Maja_: And you don't feel this is relevent to your argument at all?
Dead_Bush_Sanpai has quit [Ping timeout: 255 seconds]
Dead_Bush_Sanpa1 is now known as Dead_Bush_Sanpai
<Maja_>
(I'm using unique quantified over languages that are some kind of production ready)
<zid`>
nikolar mentioned that not because it was relevent, but because you'd enjoy talking about it, presumably
<zid`>
nice guy
<nikolar>
kek
<Maja_>
ah, right, that's why you bring it up
<Maja_>
note that it was introduced while it was still when they weren't afraid to change things a lot and break compatibility
<Maja_>
heck, half the keywords were different than modern rust when they made the change
<zid`>
exactly our point
<Maja_>
they killed entire features since then
<Maja_>
rust-just-before-borrowck is about as far from modern rust as rust is from C, and C-made-safe would be a similar distance from C, unless you make specific efforts to minimize this distance, which will result in its own language warts
<Maja_>
such as the fact that RefinedC is pretty much running two type systems in parallel
<zid`>
Your claim is that c-made-safe would be Rust
<nikolar>
except that lifetimes aren't types (if you're referring to borrow checker)
<zid`>
Your supporting evidence for this, is that neither of them are the same language by a large margin, lol
<zid`>
I'm super done, I need to stop rubbernecking this carcrash
<Maja_>
fair, I should've said "ownership types with some kind of borrow checking"
<Maja_>
that's the essence of Rust to me, but clearly it's not to you, and that's where this whole disagreement comes from
<nikolar>
types and ownership/lifetimes are orthogonal
<Maja_>
nikolar: look up "linear types"
<nikolar>
lol
<nikolar>
rust doesn't do linear types
<Maja_>
yeah, affine is what they do
<Maja_>
but my point is that it is very much considered a part of the type system in the literature
<nikolar>
you can consider them whatever you like, they are orthogonal
<Maja_>
okay, what's your point in that case?
<Maja_>
ah, I think I see
<Maja_>
do you not consider optional<&own<uninit<n>>, null> a type, then?
GeDaMo has quit [Quit: 0wt 0f v0w3ls.]
<the_oz>
"as type" -> the problem is the lack of expressive capability in the question. Extremely pedantic would say it's not a simplex type, but a complex of types.
<the_oz>
but DEFINITELY NOT runtime implemented
<the_oz>
because fuck that
hwpplayer1 has quit [Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.4)]
<the_oz>
but also what language is that and why is rust so gay
<rbox>
so angry
<the_oz>
holy shit it's an opinion
<the_oz>
watch out, it's critical without thesis provided
* geist
yawns
<Maja_>
I think the idea with the whole gay thing is that it tends to keep bigots away from participating?
<gog>
i'm gay and i still haven't learned rust
<Ermine>
the what
<gog>
the rust
<the_oz>
I've never met an outright verbal social justice identitarian that was better at making non-issues non-issues than hacker types that you have no idea what they're like to the point of being a dog on the innernet
netbsduser has quit [Ping timeout: 255 seconds]
<Ermine>
gog: I lol'd
<Ermine>
innernet innit
<Maja_>
gog: careful, it is a common comorbidity
* Ermine
gives gog a piece of cheese
<the_oz>
ain't a big truck ya heard
* gog
is fascinated
<the_oz>
type theory TRASH, let's talk about your single inflammatory opinion
<Mondenkind>
meow
<Maja_>
meow
* Ermine
retrieves his #osdev bingo card
beto has joined #osdev
<nikolar>
anyway
<Ermine>
rust is here
<nikolar>
hello geist
<Ermine>
anything else?
<Maja_>
Ermine: meowing should definitely be on the bingo card
<geist>
maybe time to write another rust os
<gog>
meow
<Ermine>
We don't usually meow, so it's not on the card
<Ermine>
c vs c++ vs rust happens more often
<Ermine>
as well as linux desktop
<gog>
don't program
<Ermine>
embrace 0-code?
<gog>
yes
<Ermine>
kek
<Maja_>
Ermine: ah, I guess I usually take a look at the chat when gog is around
<Ermine>
Instead of meowing we could be mewing
<nikolar>
geist: do you happen to know a c toolchain that targets m68k that's not gcc/llvm
<gog>
no cap skibidi riss
<the_oz>
if you're gonna nocode, try going without a callstack NOR heap
<geist>
nikolar: hmm that's a good question
<Ermine>
gog: you're mogging me
<geist>
there has to be at least one, aside from some toolchain on some copy of xenix 68k or something
<nikolar>
yeah i assumed so
<nikolar>
tcc doesn't support it
<geist>
there's at least one non binutils assembler
<nikolar>
open watcom doesn't either
<nikolar>
and i am running out of ideas :)
<Ermine>
nikolar: quick, write your own m68k compiler!
<zid`>
INTERMETRICS
<Maja_>
nikolar: vbcc?
<Ermine>
if m68k docs are available
<geist>
may be some old cross compilers that you can find. like, uh, oh what was that compiler for mac
<geist>
there was a whole company that had a bunch of compilers that i remember we used in beos until switching to gcc
<Maja_>
> vbcc supports the following backends, with different degrees of maturity: 68k, ColdFire, PowerPC, 6502, VideoCore, 80x86 (386 and above), Alpha, C16x/ST10, 6809/6309/68HC12, and Z-machine.
Arthuria has quit [Ping timeout: 260 seconds]
<nortti>
geist: metrowerks?
<geist>
yesss. metroworks
<Maja_>
(i just looked up "c compiler for amiga")
<Ermine>
Cambridge, Massachusetts
netbsduser has joined #osdev
* Ermine
squints
<nikolar>
Maja_: oh that actually makes sense, why didn't i think of it
<geist>
we must have paid metroworks to port to beos, since it was the compiler for beos for ppc
<nortti>
ACK used to support m68k at least
<zid`>
That's also what I did
<geist>
then when switched to x86 we switched to ELF + gcc
<zid`>
but I picked a different thing to amiga
<Ermine>
but beos haven't taken off...
<geist>
but anyway that's not helpful necessarily. i guess the question here is why are you looking for that nikolar ?
<geist>
sort of an XY problem
<nikolar>
well i got the rosco board, and i want to port a c compiler to it, eventually
<nikolar>
and i doubt gcc would work with 16mb of ram
<nikolar>
:O
<zid`>
compilers being open source is a modern invention though tbh
<geist>
ah okay. well i recommend joining the rosco m68k discord
<nikolar>
i did
<geist>
rosco is there as well as a bunch of smarties
<zid`>
usually they were multiple-thousand-dollar bits of corp software
<Ermine>
it's as modern invention as everything open source
<nikolar>
i just thought that you might know :)
<geist>
nikolar: oh i see you there. oh i cant read cyrillic
<geist>
but that's you
<nikolar>
yup that's me
<zid`>
nikolar: if you had helped me earlier you'd alrady have a C compiler
<nikolar>
lol
<zid`>
for a very small subset of C
<nortti>
geist: recently noticed in the haiku beta5 announcement "The old FAT filesystem driver (which dated back to sample code Be, Inc. released as open-source before their demise) has been almost totally replaced with a port of FreeBSD’s FAT driver.", was the older driver the one that you worked on, or was that a yet-different one?
<geist>
heh hard to tab complete straight cyrillic with an ANSI keyboard
<geist>
nortti: yeah i would have, though it was written before me
<geist>
it was open source before i even started fiddling with beos, back in about 1997/1998
<nortti>
oh, interesting
<nikolar>
geist: copy paste :P
<geist>
i used it as example code for writing the ext2 and ntfs driver
<geist>
and then joined as an intern, etc
<nortti>
guess it was to serve as a "here's how y'all can write your own drivers for beos, please do so"?
<geist>
though beos was closed source they would generally pick a few apps and a few drivers and release those as open source, as examples
<geist>
exactly
* Ermine
mkdir r128
<geist>
at some point for a window of time i was the only dedicated FS person after dbg left
<geist>
but the FAT driver was very mature at that point so there wasn't really any tweaks on it
<geist>
same with BFS. was only if there was a bug report or something, which there really wasnt
<geist>
was mostly woring on a new fs called CFS that never saw a formal desktop release. was used for BeIA stuff
<nortti>
oh, what was planned for that?
<geist>
it was pretty special purpose, highly compressed and space efficient
<geist>
was used in some of the BeIA releases
<nortti>
ah
<geist>
i guess it would have been in the leaked Dano or whatnot, but you wouldn't want to use it on a real hard drive unless you like to hear the disk seek
<geist>
i do remember running stress tests by checking out the whole source tree on a CFS hard drive and then building it. it was so slow but a good stress
<nortti>
"While it is possible to boot BeIA into an interface similar to the standard BeOS, doing so involves special knowledge.[citation needed]"
<geist>
beia was basically just beos with a completely different shell. built fro the same source tree, so it wasn't so much a fork of the source as just another 'distro'
<geist>
where it'd probably be hard to build even from leaked code nowadays is iirc there was a separate closed source Opera tree that we had licensed but only a few folks were allowed to see it
<geist>
so there was some amount of .so or whatnot that was copied down from somewhere to complete the build
<geist>
i dunno if that was checked into the tree or pulled down at build time
<nortti>
oh, didn't realize that'd been leaked
<geist>
oh yeah the source has been leaked a bunch of times
<geist>
from what i understand from folks internal at palmsource at the time, which is where a lot of the engineering staff ended up when they bought be's assets, there was a push to open source it
<geist>
and it got > < this close
<geist>
but eventually ran out of steam
<nortti>
aw
<geist>
before they sold it to Access, Inc. i think which promptly buried it
<nortti>
hm, would this have been around the same time as opensolaris?
<geist>
would have been about 2004
<nortti>
so a bit before
<geist>
be was sold to palmsource about 2001, and then they had a few years run on it before it shut down in 2004/2005, and then a bunch of those folks ended up at Android which got started up around then
<geist>
i didnt go that route, i left in 2001 and then went to Danger, which another big set of Be folks did
NicoleATX has joined #osdev
<geist>
then we made a thing, shipped it, and eventually most of the original folks left about 2005 or so and a fe started Android
<geist>
and thus a lot of the Be team got back together then and built android. a lot of them are directors, VPs, etc there now
<geist>
i didnt go that route and went to Apple in 2005 and worked on iphone
<bslsk05>
github.com: ack/mach/m68k2 at default · davidgiven/ack · GitHub
<geist>
i guess if you want to hack your own compiler, 68k would be a good target since it's very flexible
<geist>
more addressing modes than even x86 and somewhat more regular
<nikolar>
yeah it's an interesting arch
<geist>
it's like VAX * .75
<geist>
about the same addressing mdoes iirc, but the main limitation relative to vax is somewhat like x86 most instructions dont take arbitrary load/stores on any operand
<geist>
whereas that's a VAX thing. any operand can be any addressing mode
<geist>
but there are some instructions in 68k that do take more than one addressing mode, and not implicitly like x86 (rep movs for example)
<nortti>
does VAX also use autoincremented-register-indirect with PC to do literals?
<nikolar>
thanks nortti, figuring out how to build it now :P
<nortti>
oh, interesting, PC-relative addressing by default
<nortti>
"(Assembles to (PC)+[Rx]. This is NOT a useful mode)"
<geist>
i forget how PC is encoded, but VAX instruction format is basically <opcode><byte that describes addressing mode for operand 1><optional operand 1 data><byte that describes addressing mode for operand 2><data for 2>...
<geist>
so it's consistently laid out
<geist>
68k is somewhat similar, though it's always multiples of 16 bits, so the opcode is more flexible, and some of the opcodes imply the addressing mode
<geist>
and on both the opcodes imply how many operands there are
<geist>
nortti: and yeah, i dont think x86 has any of these but vax and 68k have some indirect modes like that
EineNdamen has joined #osdev
<geist>
like 'take the word at address pointed to by X, then do something else with that and indirect again'
<geist>
though i guess that particular addressing mode is only a single indirect really
youcai has quit [Ping timeout: 260 seconds]
<geist>
PC in vax is r15 (like ARM32) so it is easy to encode as
youcai has joined #osdev
<geist>
i remember back in the 90s having some mac friends that would continually poo poo on x86 all the time, and i think i see why
<nortti>
hm, how regular is ppc?
<nikolar>
heh
<geist>
*pretty* regular for a risc machine. my experience is that it's kinda the least riscy of general risc machines, but really about as regular as ARM64 is
<geist>
ie, it looks fairly clean though the instruction layout is complicated and there's lots of exceptions to things
<geist>
and it has a few über instructions that alias to other things (like anything involving shifting or rotating or bit masking)
<nikolar>
cisc ftw :P
<geist>
otherwise it's fairly straightforward 32 register risc machine. it does have these CR registers which is a little weird
<geist>
cr0, cr1, etc
<nortti>
condition register?
<nortti>
guess that's one way to work around false deps caused by flags
<geist>
yah i dont remember the full details, ia64 has this stuff like crazy, but like ARM64 ALU ops to modify condition registers
<geist>
but you specify the CR. yeah. and i think maybe CR0 is a /dev/null, and if yo udont specify it goes in a well known cr
<nortti>
mh
<geist>
one of those things that makes sense at the time, but is probaby a waste of instruction bits now
<geist>
because modern superscalar stuff can deal with false deps just fine
<geist>
also iirc branches have a '.' bit that you can hint to take or not take, which is almost certainly a waste of a bit in modern designs
<geist>
PPC also has a weird quirk that i haven't seen anywhere else: you can only branch indirect through two fixed special registers
<geist>
one of which is the default 'branch and link' register
<geist>
and the other is just a CR you can move into
<geist>
also a good idea at the time: those two registers were probably implemented not in the register file, but in the branch predictor unit, a stage or two ahead
<geist>
but now is probaby just extra complexity
<nikolar>
is POWER a direct evolution of ppc
<nortti>
do you know how closely this matches the POWER1 / RtPC?
<geist>
other way around. POWER is the real arch, PPC was at the time a subset of POWER
<nikolar>
oh really
<geist>
think of it as PPC forked off POWER but remained mostly synced up, and PPC64 was more or les the same as POWER4 iirc
<geist>
the IBM PPC970 cores were basically POWER4
<nikolar>
interesting, didn't know that
<geist>
so it's an IBM design through and through, though i guess there was a period of time there where they took input from other companies
<geist>
and some of that may have influenced POWER designs, and vice versa
<geist>
at least what wikipedia implies is POWER wasn't so much specced out at the time, so it was more like 'take what IBM already have, call it ppc work with that'
<nikolar>
kek
<geist>
and later on (in 2006 it seems) POWER ISA got defined and PPC was part of that spec
<geist>
and now there's openpower and whatnot, i dunno what parts are free or not
<nikolar>
i assume the openpower thing was the whole platform
<nikolar>
and not just the isa
<geist>
so i guess in that regard you can argue that PPC predates POWER
<geist>
kinda depends on if you're talking about the name or the actual underlying ISA design
<geist>
basically they made a POWER microprocessor in 1990 and then pretty quickly started the whole PPC thing
<nortti>
oh, interesting, you could still design a faster design with multichip back in 1990
<geist>
though really you gotta remember in the 90s, especially early 90s, x86 was just a toy and it was assumed some RISC thing would take over one way or another
<geist>
and in general any risc design would probably eat x86s lunch
<nortti>
I remember reading that pentium pro was when the opinion on that really changed, how accurate is that?
* zid`
laughs in DDR
<geist>
wasn't really until the late 90s when 'good enough' and 'cheap' started to take over
<zid`>
That's more flipping cause and effect imo
<geist>
i think that's pretty accurate. it was the first really solid superscalar OOO x86 design (pentium was technically superscalar since it could run two instructions at a time in specific cases)
<zid`>
transistors got cheap enough that both ram got big and slow, and cpus could afford to have proper instructions
<zid`>
so the benefits of risc evaporated
<geist>
at least if you were willing to spend the transistors on it instead of someplace else
<zid`>
which was running 1:1 with the ram on 7 total transistors
<nikolar>
lol
<zid`>
cisc was a losing proposition when adding complex instructions just made them miss ram cycles by being complicated, if they still wanted to fit into a tight transistor budget. Then suddenly it wasn't because they didn't.
<geist>
and i think the state of the art of OOO cpu designs was getting good enough that you could really work around limitations in the ISA. which i'm not sure folks really expected, hence why HP and intel were also working on IA64 since they assumed there was a limit to what you could do in hardware
<geist>
and that the future would be solved by compilers
<nikolar>
rip itanium :(
<geist>
you can argue it was a terrible mistake on intels part, and it was, but they were also hedging their bets, since both HP and intel had their own other cpus they were working on at the time
<zid`>
It was just "who's going to break first" in terms of 'going cisc', imo
<geist>
the mistake intel did was not switching to a 64bit x86 earlier, and letting AMD get a piece of that
<zid`>
do you go early, before the transistor budgets are there
<zid`>
or do you go late and maybe miss the boat
<geist>
why not both!
<zid`>
rather than risc or cisc winning or anything of the sort
<nikolar>
kek
<zid`>
risc is a compromise design that fit the era's design space
<zid`>
fast ram, expensive transistors -> risc
<geist>
well, sure, but it's also hard to justify a brand new cisc design nowadays
<zid`>
It's hard to justify a new anything, tbh
<zid`>
with how advanced litho and layout is now
<zid`>
the ISA is the trivial part
<geist>
i'm not sure i agree, its all relative
<zid`>
and designing the oo engine and stuff isn't that much work, with modern tooling
<geist>
it's trivial, but the layout stuff and whatnot is also automated now
<geist>
so it's a matter of you still have to go through the design cycles to deal with your ISA and how it works
<zid`>
but intel have things like strained silicon and high-k etc that you'd have to re-engineer to compete with them
<zid`>
same reason I don't think riscv is useful, because the isa isn't the important part for producing good chips
<zid`>
it's all the design work making the actual slab of silicon
<zid`>
do the magic
<geist>
disagree. as evidenced by the sudden proliferation of riscv cores
<zid`>
I think riscv could have been *anything* though
<geist>
since now it's far simpler to build one, and ore importantly it's free
<zid`>
as long as it was open and people started memeing about it
<geist>
oh sure
<nikolar>
except that most of those cores are mcus and most of them come from chinese companies which are trying to avoid x86
<geist>
that's the point of riscv
<nikolar>
or rather, western ip
<zid`>
right, the fact it's /riscv/ is irrelevent imo
<geist>
it's not intended to be fancy or crazy, etc. it's just free and good enough
<geist>
well, okay, riscv the ISA vs riscv the whole everything else
<zid`>
yea, it'll make some great 8051RV chips
<geist>
dont foreget riscv the tooling, etc. they are far more than just some document with an ISA
<zid`>
people are treating it like the second coming of christ though, like it wouldn't take a billion dollars to turn it into a sandy bridge but running risc-v's opcodes
<geist>
well okay but you're kinda trivilizing a lot of it
<geist>
like fixating on one part and dismissing the rest
<zid`>
I'm just pointing out a *specific* thing that bugs me, I agree it'll be great for 8051s
<geist>
alrighty
<zid`>
btw have you seen the computational lithograph stuff nvidia are doing?
<geist>
bbiab
<nikolar>
bbiab?
<zid`>
be back in a bitches
<nikolar>
lel
<zid`>
it's form before you were born nikolar
<zid`>
from*
<nikolar>
possibly
<zid`>
nikolar do you want to hear about the computational litho, or did I say it in gcc and you saw it there
<nikolar>
i want to hear about litho
<zid`>
Basically, light is dumb and doesn't go in straight lines, and prefers silly refraction patterns, etc. So the litho masks for a long time have done things like add bumps to corners to try convince the output to be more like what you wanted.
<nikolar>
oh are they computing the correct mask for the output now
<zid`>
yea, in reverse
<nikolar>
cool
<zid`>
have you seen like, a fresnel lense
<zid`>
lens
<nikolar>
yup
<zid`>
It's a weird bumpy thing to try make light go straight
<nikolar>
fresnel lens is more like a squished down normal lens
<zid`>
they're basically adding fresnel patterns onto the masks to make them not shitty, but it's all done by ML and bruteforce and stuff
<zid`>
so the masks look fucky
<nikolar>
i thought it was possible to exactly calculate the mask
<nikolar>
i guess not when there are billions of features
<zid`>
It's all whatsits, harmonics
<zid`>
nah there's too much light and too much mask, yuea