<vdamewood>
Let's ust pretend that mrvn types everything correctly.
<mrvn>
It feels like this requires a destructor that calls alloc.deallocate(t)
<vdamewood>
Let's pretend I type everything correctly too.
<mrvn>
vdamewood: you are the great pretender
<vdamewood>
I'm the master of pretending!
<mrvn>
s/destructor/deleter/
<doug16k>
mrvn, unique_ptr<T[]> will placement new[] and delete[] for you
<vdamewood>
Yesterday, I pretended I was a functional human being!
<mrvn>
doug16k: the question is whether delete[] is even the right thing.
<vdamewood>
Today, I'm pretending that I'm an imperative human being.
<doug16k>
it needs to remember to destruct 10. how would it?
<mrvn>
doug16k: delete[] is potentially different from alloc.deallocate(t)
<doug16k>
delete[] gets a pointer just like free(), it couldn't care less how many items there are - it destructed them already!
<doug16k>
you can just free(p) if the new[] return malloc(p)
<mrvn>
doug16k: that isn't the problem. The problem is that alloc.allocate() might do something sifferent
<doug16k>
er malloc(sizeof(*p) * N) I mean
<mrvn>
doug16k: "Allocates n * sizeof(T) bytes of uninitialized storage by calling ::operator new(std::size_t) or ::operator new(std::size_t, std::align_val_t) (since C++17), but it is unspecified when and how this function is called." I know it can't call malloc.
<mrvn>
"The "unspecified when and how" wording makes it possible to combine or optimize away heap allocations made by the standard library containers" is the part I'm worried about.
<doug16k>
you expect the optimizations to break it?
<mrvn>
no, just that it is unspecified how it behaves in detail
<doug16k>
unique_ptr can take a deleter if you want to do something funny to free it
<mrvn>
but then it has a different type. I really want to avoid that
<geist>
Oh no i look away and it has once again turned into a C++ channel
<geist>
Though i guess that’s better than a ‘hack Linux to install rootkit’ channel
<zid>
geist: Got a decent reason why amd64 sysvabi uses regs for varargs?
<geist>
Versus what?
<zid>
stack I guess
<zid>
which has the benefit of being linear rather than piecemeal
<geist>
It’s fairly common for most systems I’ve seen to do varargs as pretty much regular calling convention
<moon-child>
zid: so you can declare void f(); in one TU and void f(actual params here) { ... } in another TU
<zid>
moon-child: what's that have to do with anything?
<moon-child>
zid: afaik apple arm is the only abi that passes varargs on the stack
<geist>
In the case of piecemeal one solution the callee can do is just allocate the space on the stack linearly, and dump the regs such that they line up with the ones that are pushed
<doug16k>
zid, it is why varargs are called the same - you can't mindread if it is varargs
<zid>
x86 pmode did
<zid>
() is varargs already
<zid>
or rather, unspecified
<geist>
Though i guess that’s hard on x86 because it’s already pushed the return address
<zid>
so it actually emits code, xor rax, rax
<mrvn>
moon-child: but only in C
<geist>
Yah the ram-holds-number-of-float thing is unique to x86-64 AFAIK
<geist>
I haven’t seen anything like that in other arches
<geist>
S/ram/rax (stupid autocorrect)
<moon-child>
mrvn: where else?
<zid>
geist: oh right yea didn't think about just doing a big reg dump if you *wanted* the linear case, right
<moon-child>
topic of discussion was c abis, presumably, not for other languages
<moon-child>
zid: pushad go brrr
<mrvn>
moon-child: in C++ void f(); means no arguments.
<geist>
Yah that’s what arm 32/64 does in general
<geist>
And probably riscv
<geist>
But those are easier because the callee can control where the return address goes
<zid>
I'm of the opinion that 99% of the time you *are* in a linear situation (printf etc) rather than a 'counted' `int fmt, ...` style
<geist>
So it can just up front allocate space on the stack for the args to get slammed down on the stack, prior to pushing anything else
<zid>
so it seemed saner to me to just form the linear dump in the caller
<mrvn>
hmm, what does this declare in C++: extern "C" void f();?
<zid>
where it saves a mov to a reg
<moon-child>
zid: I agree, it is more sensible
<moon-child>
but, compat
<moon-child>
mrvn: probably no-args
<geist>
I think the general idea is that you can call a varargs function without a varargs declaration, but that’s probably not legal
<geist>
Because of zero rax if nothing else
<zid>
It's not, eax will be corrupt
<mrvn>
moon-child: probably. the extern is just about linage
<mrvn>
linkage
<geist>
Or argument widening implications of varargs (float -> double, etc)
<moon-child>
mrvn: consider that you can say extern "C" void f() { ... }. extern "C" is just for link--yeah, exactly
<doug16k>
geist, gcc emits eax changes if it doesn't have a prototype and you pass a float
<mrvn>
geist: it's legal due to implicit prototypes
<doug16k>
and not in same unit
<geist>
doug16k:yah makes sense. It’s at worst just a waste of time to null rax
skipwich has joined #osdev
<geist>
Since it otherwise doesn’t participate in the call
<zid>
so I guess my takeaway is it isn't *as* wasteful as I thought
<zid>
but I'm still not sold on regs being the default over stack
<mrvn>
geist: do you know any other arch where the first argument register isn't the first return value register?
<mrvn>
zid: it's generally faster
<geist>
Well, would only apply to arches with args in registers (vs say x86-32 or 68k which are stack based)
<geist>
Register window ones dont do that
<geist>
Ie, sparc/etc
<geist>
Alas getting kicked out of cofeee shop
<geist>
But in general no. Most of the time the return is the same as the arg regs
<mrvn>
arm, alpha, mips don't do it. powerpc?
<doug16k>
oh yeah, I use fastcall in my 32 bit bootloader code (eax edx ecx parameters) - guessing it does something similar to x86_64 to get 1st varargs from edx ecx
<doug16k>
mregparm=3
<mrvn>
here is another C++ question (sorry geist): If I have `<=>` with strong ordering why doesn't that provide `bool operator==(const T &other) { return (*this <=> other) == 0; }`?
<zid>
I keep telling geist to wear pants but he won't listen
<mrvn>
zid: don't make giest wear pants or I have to put on some too
<moon-child>
zid: why can't you just be normal and take off your pants like everybody else?
<klys>
lewd
<moon-child>
pants are just an imposition by society, man
<doug16k>
you can be sure I have pants on if you see me in irc
<klys>
haven't see you for a while
<klys>
except in #asm and #glibc
<zid>
moon-child: It's not normal it's barbaric
<heat>
#glibc exists?
<zid>
heat exists? :(
<moon-child>
zid: come over tonight, and I'll show you barbaric
<heat>
zid, yes
<zid>
moon-child: 'Come over, the goths aren't home'
<moon-child>
Legend has it that #glibc is just where ulrich drepper goes to let out his frustrations. Not recommended.
<moon-child>
(with apologies)
<heat>
#musl > #glibc
<heat>
deal with it
<klys>
because onyx runs musl dude
<heat>
and alpine
<zid>
and javascript, so instantly discounted
<heat>
actually I'm working on porting v8 right now
<heat>
so, not yet
<doug16k>
heat, how awful is it to port v8?
<mrvn>
doug16k: I don't see you on irc, no webcam.
<zid>
I bet heat is cheating and not actually porting it, and just hosting it
<heat>
doug16k, I don't know? hope that's its not much
<moon-child>
mrvn: even if there were a webcam, you wouldn't be seeing doug16k, just a representation of him
<moon-child>
mrvn: as is, you still see a representation of him (unless you are using a screenreader?), just a lower-resolution one
<doug16k>
heat, the multiprocess stuff looked terrifying when I took a peek
<mrvn>
moon-child: unless he is a weeping angle. The image is the thing.
<heat>
doug16k, what multiprocess stuff?
<doug16k>
tons of IPC - it hosts each domain in separate process etc
<heat>
isn't that all chrome?
<doug16k>
V8 has workers
<doug16k>
webworkers
<doug16k>
isn't whole multiprocess mess in there too?
<heat>
I don't know?
<heat>
we don't use that in workers
<zid>
They could be green threads and it's all uniprocess uniaddress space cus javascript is UNHACKABLE
<clever>
doug16k: ive found that a lot of the multi-process stuff in chrome is kind of pointless, there are too many things that require a single thread in the master process
<heat>
I thought you only have isolates
<clever>
doug16k: very often, that one thread takes too long to answer, and all of chrome hangs
<zid>
clever: I still use a single thread main browser
<mrvn>
clever: it also only creates a limited number of sandboxes
<zid>
(firefox went multiprocess at the same time they fucked all the addons and stuff, so there isn't an ff fork with the old plugins that's multiprocess)
<clever>
mrvn: in think in the pre spectre/meltdown days, there was a lower limit, but since then, the rules have changed, and its now one domain per renderer process
<doug16k>
heat, I think you might pull it off though :D
<mrvn>
firefox has the same problem with a single blocking main thread.
<clever>
so if you do exploit the system and access other stuff in the pid, its only your own domain at risk
<clever>
so example.com can never scrape data from paypal.com
<heat>
doug16k, I hope so, from a very quick node strace it seemed pretty basic
<heat>
i was only lacking epoll but I assume there's a poll fallback
<mrvn>
clever: the bigger problem I have is stopping domains. I don't want invisible tabs to run javascripts for days and days
<zid>
You were supposed to properly port it heat
<zid>
Implement your *own* stupid syscalls, and make it use them
<clever>
mrvn: yeah, i can only manage that by checking cpu usage in the chrome task manager, and killing child procs
<heat>
zid, what stupid syscalls
<mrvn>
clever: I want the javascript engine to pause when a tab hasn't been active for a while
<mrvn>
preferably configurable with exceotions per domain
<clever>
mrvn: most recently, i discovered that one of my bugs, involves chrome adding/removing elements from a std::vector<ObserverStorageType>, which is very cpu costly
<heat>
mrvn, that's possible in v8
<clever>
yeah, that would be lovely
<zid>
heat: WaitForObjectWithMonadFungibleTokenEx
<heat>
poll
<mrvn>
e.g. I want my mega tabs to run to completion but pretty much nothing else.
<heat>
why does v8 use depot fucking tools
<doug16k>
in chrome you can open chrome's task manager and blow away stuff deemed to be hogging resources
<mrvn>
doug16k: to much work
<clever>
personally, only discord, facebook messenger, and the tabs that are focused in each window, should get JS time
<heat>
there's a way to kill v8 isolates
<mrvn>
doug16k: and as said, I wantr to pause them, not kill them
<clever>
and everything else should grind to a screeching halt the instant it looses focus
<heat>
they get an uncatcheable exception and die
<zid>
chrome has suspended out of focus shit for ages now
<zid>
unless you use webworkers or whatever
<clever>
zid: perhaps my version 96 build is to blame
<mrvn>
zid: which naturally every dirty site does
<zid>
which just meant everybody switched to being abusive via webworkers or whatever
<zid>
and I have to leave a pixel of my idle games exposed and in a sep. window
<heat>
i use firefox in linux because im a hipster
coelho has joined #osdev
<heat>
i use chrome in windows and android because I'm a normie
<doug16k>
I was playing a game on my main machine from my kitchen machine, then ended up using my desktop from there, so I just sent sigstop to the game and froze it so I could just use the remoteplay for remote control for a bit
<doug16k>
I wonder if you could sigstop things
<mrvn>
how do you know what to stop?
<heat>
that seems like a poor idea
<doug16k>
that becomes the new problem yeah
<mrvn>
if you stop something that's calling the main thread everything stops
<heat>
im fucking dying
<heat>
its 25C here
<heat>
2am
<doug16k>
air conditioner
<mrvn>
that's not too bad
<heat>
my air conditioner is no bueno
<doug16k>
they are giving them away nowadays
<zid>
It is 15.5C here, 25C was the peak at 2pm
<doug16k>
it's amazing how much cheaper they are now
<heat>
it was 38C here around 2pm
<zid>
thirty WHAT
<zid>
have you considered not living on the surface of the sun?
<doug16k>
drastically more efficient now too - uses the condensation to wet the condenser
<heat>
zid, sunny southern europe weather be like
<doug16k>
not even one drop comes out of my AC. it's all boiled off on the condenser
<zid>
heat: Portugal is a monument to man's hubris and an affront to god
<heat>
agreed
<heat>
lets nuke it
<zid>
sink it into the atlantic
<heat>
where will british people lose their children then
<zid>
That's a sacrifice I am willing to make
<zid>
They can abuse them and hide the body at home like the rest of us I guess
<heat>
magaluf maybe?
<zid>
I'm picturing like, wile e. coyote sawing portugal off iberia
<zid>
and it sinking into the sea
<heat>
it wouldn't sink
<heat>
we'd just end up in the american east coast
<bslsk05>
'ThePoolGuy - Home' - 'Here with ThePoolGuy, i'm posting content related to water parks, swimming pools and aquatics in general. I've been in water safety, operations, management and maintenance of water parks and aquatic facilities. I want to share what I know and of course I learn as I go.
<clever>
on this channel, you can see all of the behind the scenes stuff about maintaining a water park
<clever>
and about the only thing he doesnt show, is what buttons to hit on a VFD to turn the motor on/off
<zid>
I assume water park people talking about delta P is like rocket surgeons talking about delta V, totally normal
<zid>
There's also sort of the opposite delta P issue one of my friend works with, diesel leaks
<zid>
go google high pressure injection injury if you're brave
<clever>
i already know of inflation and degloving :P
<zid>
hpij is weird, you feel fine
[itchyjunk] has joined #osdev
<zid>
then your hand swells up and turns purple
<clever>
there was an episode of NCIS i saw many years ago, where there was a loud bang in a sub, somebody dropped to the floor, and then a loud constant noise
<zid>
and you die of toxic shock and 'dirty diesel in my blood disease'
<clever>
and gibbs stopped somebody from going to help the guy
<zid>
which I suppose are basically the same thing
<clever>
he then waved a broom handle across the room, and half of the broom just fell off
<clever>
a high pressure air line ruptured, and was creating an instant-death laser across the room
<zid>
high pressure jets are the closest things we have to sci-fi lasers :P
<clever>
NCIS turned the sci-fi up to 11, and made it invisible as well
<zid>
diesel injection shit is infact, invisible
<zid>
it won't cut you in half, but you're not supposed to run your fingers along the pipes etc, because of the injection injurys tuff
<zid>
if you 'seal' the hole with your fingertip or whatever
<clever>
ive also been worried about the same thing, if somebody is messing with a pressure washer
<zid>
pressure washers are really low pressure, comparitively
<zid>
diesel injection on engines is 30kPSI, pressure washers cap out at single digit thousands
<clever>
how much do you know about hvac?
<zid>
I don't even know what it spells
<clever>
air conditioners
<clever>
and heat pumps, fridges, freezers
<zid>
I know the princples, no prctical exp
<clever>
got 2 good sources on them, both channels i watch a lot
<zid>
I don't really care about the subject
<clever>
i would have said the same before, but i cant stop watching these 2 guys :P
<zid>
I care that the person isn't a "youtuber"
<zid>
that's not what I said
<zid>
I said I don't care what the subject is, not I don't care about *that* subject
<clever>
ah
<zid>
They have to not be a youtuber, not have awful audio, not have certain vocal ticks or inflections etc
<bslsk05>
'HVACR VIDEOS - Home' - 'Hello my name is Chris and I will be posting videos about the cool stuff I see out in the field of HVACR. A little bit about my self, I've been involved in the trade for over 15 years and I will tell you right now that I do not know it all, this trade is constantly evolving and new technology is coming out every day. I am based out of Southern California and I mainly work in restaurants. If you have any questions or even suggesti
<zid>
It had the least amount possible of annoying youtubers
<clever>
and this guy just does AC repair work in californaia, and origianlly was recording the work as training for his own employees
<clever>
and decided to just make the videos public
<mrvn>
clever: what would you expect to see? refraction due to different air density? fog due to the air cooling when expaning?
<mrvn>
(in the air jet)
<clever>
mrvn: i would have expected a water jet, not an air jet
<clever>
water would do a lot more damage at lower velocities
<zid>
Turns out water is heavy, who knew
<mrvn>
clever: but it's not a high pressure water pipe, it's the air pipe
<doug16k>
wouldn't there be refraction along the density gradient where the high pressure jet met the surrounding air?
gog has quit [Ping timeout: 244 seconds]
<mrvn>
doug16k: sure. You can see that with rockets hitting the sound barrier.
<doug16k>
can't be invisible can it?
<zid>
I wonder if you can create shock diamonds
<zid>
by moving water fast enough
<clever>
mrvn: i'm also not sure what a sub would need with such high pressure air
<mrvn>
But that assumes you actually have such an air jet in the scene.
<mrvn>
clever: blowing out the balast tanks
<mrvn>
Doing CGI to show the refraction from an air jet is probably costly.
<clever>
i would think those would be pressure tanks near the balast tanks, and not a pipe bomb running thru half the ship
<clever>
mrvn: also, part of the script was that the danger was supposed to be invisible, and gibbs saved a dude from becoming the 2nd victim
<clever>
just to make him more knowledgable
<mrvn>
clever: but where would that leave the plot? I bet you have such pipes (unpressurised normaly) as backup when you have to blow out the aft tank with the forward air.
<doug16k>
I suppose the background could be unluckily shaded to make the refracted light similar enough
<mrvn>
clever: I'm pretty sure they wouldn't be totaly invisible. But could be hard to spot.
<clever>
mrvn: i would have thought the volume of the pipes would greatly reduce how much pressure and water volume you can displace then
<zid>
clever: I need you to make me some shock diamonds in a stream of water, stat
<mrvn>
clever: that's what pumps are for
<zid>
If you wanna keep it as liquid water I assume it's going to need to be moving *FAST*
<zid>
but maybe at that point some other process just takes over, that seems likely
<zid>
like.. relativity
<mrvn>
zid: want to make a water yet shooting water at fractions of c?
* clever
heads off to bed
<doug16k>
you mean a hydrogen-oxygen plasma right?
<mrvn>
doug16k: how much energy would it take to accelerate 1g of water to .5c?
<doug16k>
1/2mv^2 right?
<mrvn>
doug16k: no, that only works for low speeds
<mrvn>
there is some 1/(c-v) factor in there.
<doug16k>
.5 won't start having dilation
SpikeHeron has quit [Quit: WeeChat 3.5]
<doug16k>
small as hell anyway
<mrvn>
c/(c-v) I mean
<mrvn>
m isn't constant
<doug16k>
I played around with making a space travel sim game where it did the whole time dilation / length contraction thing
<doug16k>
seems I should remember better :P
<mrvn>
doug16k: how does that matter?
SpikeHeron has joined #osdev
<mrvn>
the time dilation only matters to the person on the rocket, the length contraction only looks like it changes something
<doug16k>
trying to remember the term for the length contraction, I forget. nevermind
<zid>
lorentz
<doug16k>
yeah thanks
<doug16k>
you really can accelerate forever, you just shorten the distance to the target if your relative speed is too high
<mrvn>
doug16k: I made a game with the speed of light limit for communication and dead slow rockets (<.2c) but I never made up a good research tree to make it interesting.
<doug16k>
otherwise you could tell you were reaching absolute c
<mrvn>
doug16k: you can accelerate forever but you get less and less out of it
<doug16k>
so you can measure when you reach c then
<mrvn>
doug16k: you never reach C
<doug16k>
what does the apparatus do when you are almost at c
<mrvn>
accelerate very very slowly
<mrvn>
(to an outside observer)
<doug16k>
I mean in the apparatus frame
<mrvn>
nothing
<doug16k>
it looks like the pendulum has no trouble swinging toward and away from forward, right? even though swinging forward is exceeding c
* klange
refreshes irssi statusbar
<mrvn>
doug16k: it's not exceeding c though
<klange>
hm, must be broken, still says this is #osdev...
<doug16k>
bnecause it is shortened to compensate outside that frame
<mrvn>
it also takes a lot longer to swing
<mrvn>
outside that frame
<heat>
why does v8 assume bleeding edge compilers
<heat>
for fuck sake
<klange>
why are you building v8 and what for?
<heat>
this is annoying
<heat>
klange, for nodejs
<heat>
for my OS
<klange>
ew
<heat>
maybe I'll port chromium one day
<heat>
its being relatively smooth since I have the latest LLVM release but... annoying to disable warnings that got introduced 1 month ago
<heat>
and they suffer from googleitis so much
<heat>
prebuilts all the way baby
<heat>
and they also try to build libc++ in tree for some reason
<doug16k>
you sure it isn't such that the people inside the ship see foreshortening of the space in front of them as they accelerate, and they can keep accelerating forever, and they begin to zip forward in time compared to the people outside that see them simply getting squished on forward axis going almost c?
<doug16k>
so they traversed all the time to go that far, but inside didn't see it elapse
<sbalmos>
RelativityOS
gog has joined #osdev
<heat>
at this point compiling google projects must draw as much power as a small country
<klys>
no header bug yet heat?
<dh`>
this is a way back now, but: <mrvn> geist: do you know any other arch where the first argument register isn't the first return value register?
<dh`>
mips
<dh`>
(arguments are a0-a3 or a0-a5 depending on abi, return is v0 or v0/v1)
<doug16k>
the people inside the ship said they didn't go over the speed of light because the distance was shorter than you saw from outside
<klange>
I ported Pyodide's JS object wrapper thing, "hiwire", and improved the JS integration for the WASM build of Kuroko.
<klange>
And replaced a bunch of eval()s with direct object manipulation and calls.
<klange>
I can even pass Kuroko functions as callbacks to JS things.
pretty_dumm_guy has quit [Quit: WeeChat 3.5]
<mrvn>
doug16k: time runs slower inside so 1m/s^2 inside becomes less and less from the outside.
<mrvn>
doug16k: the squishing is just an illusion because the photons from the front take a different time to reach an observer than the photons from the back. Or do you mean another effect?
<doug16k>
length contraction
<doug16k>
as you approach infinite velocity in your frame, you become increasingly flattened along your dimension of movement
<doug16k>
from my frame
<doug16k>
when infinite, you are a plane in my frame
<mrvn>
when you reach c you are everywhere at once.
<doug16k>
...going c
<doug16k>
the lorentz factor affects movement through time and dimensions of space
<doug16k>
when you want to translate from one frame to another
<doug16k>
the infinite speed plane person says they feel fine
<mrvn>
is that stronger or weaker than the contraction or lengthening from photons having to travel different length to reach an observer?
<doug16k>
I think it mostly says that you won't see changes propagate through the universe at a different rate
<doug16k>
as if when you move too much distance, it has to make less time elapse
<doug16k>
to the people outside your frame
zaquest has quit [Remote host closed the connection]
terrorjack has joined #osdev
zaquest has joined #osdev
<mrvn>
Like when you send a IP packet through 1foot of cable it takes 1ns. But from outside the second NIC has moved 9 foot in the same time so it takes 10ns outside for the IP paket to reach the destination.
<doug16k>
so you see them slowed down, and they zip to the destination in a week, and it's years later when they get there, they said it was a week and weirdly got closer as we sped up
<mrvn>
And now you are saing that cable will be only half a foot seen from the outside.
<doug16k>
so they didn't go superluminal to go that far in a week, they just burn all the time to get there and skipped forward through it in their frame
<mrvn>
that makes no sense, that's just time dilation
<doug16k>
I don't think the packet thing is right. the other observer would see the start of the transmission a bit later and measure the same time
<mrvn>
doug16k: no, they see the packet move through the cable and move with the frame.
<mrvn>
longer distance seen from the outside. That's why the clock slows down as you move faster.
<doug16k>
you agree that if the sun vanished altogether, we would be in orbit and not know for 8 min right?
<mrvn>
depends on how fast you are going
<doug16k>
earth would keep following the curved space for 8 min after it fanished
<mrvn>
and what mass is near you
<mrvn>
the gravity wave experiments seem to indicate that that is true
<doug16k>
because changes propagate through the universe at c
<mrvn>
on the other hand it can't vanish. Even if it goes supernova e=mc^2 so it's still there
<mrvn>
On that note: I want a condensator which capacity is measured in gramm
<doug16k>
let's say you applied a trillion 800 yotta newton pulses of acceleration per femtosecond to the sun
<mrvn>
then 8s later you would see it start to move
<mrvn>
8 min
<doug16k>
lol
<doug16k>
I wasn't sure I was saying enough force, the sun is ridiculous
<doug16k>
I showed my nephew a drawing that compares the sun and earth. I drew a little circle for earth. then a straight line down the side showing the side of the sun in comparison :P
<doug16k>
he understood
<doug16k>
earth is totally mindblowing to comprehend, both size and mass
<mrvn>
Ever wonder how time machines work? You are here one second and then you are at the same spot yesterday the next second. Do you realize how many km that spot has travelled in that time ina rather complex direction?
<doug16k>
32 bit coordinate gets you withing over a foot?
<doug16k>
because earth is so big, 32 bit is not big enough
<mrvn>
32bit is just 65536 units on each axis. That must be way more than a foot
<doug16k>
you could use it for coordinate system of whole planet, for zoning up sectors or something
<doug16k>
it's precise enough to do that with it
<doug16k>
then data inside the sector is relative to 0, s you have good precision
<mrvn>
you want to use variable length encoding for longitude and latitude though
CYKS6 has joined #osdev
<mrvn>
Like first 4 bit of the latitude say how many bits latitude uses.
<mrvn>
No pint having 16 longitude at the poles.
<doug16k>
yeah, the true range doesn't go very far north and south
<doug16k>
it becomes uninhabitable pretty quickly
CYKS has quit [Ping timeout: 255 seconds]
CYKS6 is now known as CYKS
<doug16k>
maps make it seem like civilization goes way further north
<mrvn>
Well, you do want to be able to place MacMurdoc station (or however it's spelled)
<doug16k>
that is part of the problem though, because most of the range is where longitude is huge full distance, it minimizes precision
<mrvn>
might also go further north/south in the near future
<doug16k>
way up north the longitude is precise
<mrvn>
Just release 4 billion numbered beach balls that repulse each other and let them spread out over the globe. Then after a while record where each ball is and that's yoir 32bit coordinate system.
<doug16k>
longitude becomes excessively precise as you approach the poles
<doug16k>
which is cool when you wasted bits getting it close to 90 deg
<doug16k>
not that many left
<doug16k>
it would be radians but same problem
<mrvn>
it would be 180/2^n and 360/2^n or PI/2^n and 2PI/2^n. doesn't make one bit of difference.
<doug16k>
it would cancel out yeah
<mrvn>
doug16k: here is something fun for you to play with: Build a VR world where c=100m/s or so.
<mrvn>
Cars moving at 0.5c should be fun.
<doug16k>
have home clock and ship clock
<doug16k>
how long it takes to go to work even though it takes a lot less on your car clock
<doug16k>
exactly. that's a scaled down version of what I was thinking floating through space
heat has quit [Remote host closed the connection]
<doug16k>
probably a better idea because you can see the effects easier
heat has joined #osdev
<doug16k>
better if you scale c down and put it at ground level
<doug16k>
that is where I saw that 2060 super is 12000 fps with a huge earth mesh with real world topology heights and practically no cpu with sdl+opengl 3.3
<doug16k>
so utterly OP compared to what I need
<doug16k>
topology data from SRTM project
<doug16k>
whole thing is one beautiful triangle strip but come on, I should have had to partition earth
<doug16k>
throw whole earth at it in one drawarrays, poof, utterly effortlessly
<mrvn>
I wonder what that would do to relativistic effects due to mass. The effect would get stronger with lower c, right? And black holes form far earlier too.
<doug16k>
yeah
<doug16k>
your face and the object in your hand could have significantly different lorentz factor
<doug16k>
it would seem hard to push the object fast relative to your chest and face. the people inside the object said oh no all that pushing worked, the space in front of us contracted
<doug16k>
no?
<doug16k>
the people in the object said it took a few seconds, but you pushed it for 25 seconds
<doug16k>
but they observed traversing less space right?
<doug16k>
foreshortening
<doug16k>
they got there impossibly fast because the distance contracted to balance it out
<doug16k>
penalty was more time elapsing in the other frame
<doug16k>
they think they went under c the whole time because the distance was short enough for ludicrous speed to say < c
<doug16k>
but ages elapsed
frkzoid has quit [Read error: Connection reset by peer]
<doug16k>
speed of light equals mach 1 would probably be survivable
<doug16k>
I doubt much physiology relies on past mach 1
[itchyjunk] has quit [Read error: Connection reset by peer]
<doug16k>
or maybe mach2 actually, so it is in the mostly linear region most of the time
<doug16k>
or mach 1.414 if you want to be fancy
<doug16k>
1/sin(45 deg) IIRC
<doug16k>
PI_4 radian constant sometimes
<doug16k>
I thought it would be neat to fly in space with a magic amazing amount of fuel efficiency and power, so the artificial gravity is just 1g accelerate forever
<doug16k>
half way there do 180 and 1g until you stop
<doug16k>
there's your gravity
<doug16k>
and do all the lorentz transforms to see home clock and your clock and the length contraction
<doug16k>
and put time acceleration and see how utterly infeasible it is to travel to another galaxy
<doug16k>
by the time you get 1/4 there earth has hyperdrive and is annihilating neighbour species
coelho has quit [Ping timeout: 276 seconds]
heat has quit [Remote host closed the connection]
heat has joined #osdev
<doug16k>
it would be fun to make a solar system exporer with a lot of stuff in the solar system, with lorentz transforms and magic forever 1g thrust
<doug16k>
see how many years you need to visit something
<doug16k>
strip mine the asteroid belt and get your money to say single precision inf
<doug16k>
then destroy all the neighbours? not sure what humans are expected to do
CYKS has quit [Quit: Ping timeout (120 seconds)]
CYKS has joined #osdev
chartreuse has quit [Read error: Connection reset by peer]
mzxtuelkl has joined #osdev
GeDaMo has joined #osdev
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
opal has quit [Remote host closed the connection]
the_lanetly_052_ has joined #osdev
the_lanetly_052 has quit [Ping timeout: 256 seconds]
opal has joined #osdev
the_lanetly_052_ has quit [Ping timeout: 244 seconds]
the_lanetly_052_ has joined #osdev
Affliction has quit [Quit: Read error: Connection reset by beer]
mzxtuelkl has quit [Read error: Connection reset by peer]
Affliction has joined #osdev
heat has quit [Ping timeout: 240 seconds]
dennis95_ has joined #osdev
toluene has quit [Ping timeout: 256 seconds]
toluene has joined #osdev
dennis95_ has quit [Changing host]
dennis95_ has joined #osdev
dennis95_ has quit [Quit: Leaving]
dennis95 has joined #osdev
dennis95_ has joined #osdev
pretty_dumm_guy has joined #osdev
dennis95_ has quit [Client Quit]
arch_angel has joined #osdev
Weiland has joined #osdev
_whitelogger has joined #osdev
heat has joined #osdev
tomaw has quit [Quit: Quitting]
tomaw has joined #osdev
Weiland has quit [Quit: WeeChat 3.4.1]
arch_angel has quit [Ping timeout: 255 seconds]
<zid>
anybody touch any grass?
<heat>
no
<gog>
what's grass
<mrvn>
global resource allocation singleton semantic?
<heat>
you're not a 5 star programmer, you're a 10x engineer
<zid>
Thanks babe
<heat>
np sweetie
<zid>
goto bedroom;
<mats1>
yes daddy
<heat>
affirmative father
<GeDaMo>
ita, pater
<gog>
já pabbi
<zid>
I thought you were saying 痛い！ for a moment there
freakazoid333 has quit [Read error: Connection reset by peer]
blockhead has joined #osdev
<clever>
zid: heh, by random chance, the latest HVACRVIDEOS vid, he explains the whole reason the channel started, rather then pay the new guys to follow him and learn on the job, he just films the job, explains everything, and then has the new guys watch it whenever
<bslsk05>
'HVACR VIDEOS - Home' - 'Hello my name is Chris and I will be posting videos about the cool stuff I see out in the field of HVACR. A little bit about my self, I've been involved in the trade for over 15 years and I will tell you right now that I do not know it all, this trade is constantly evolving and new technology is coming out every day. I am based out of Southern California and I mainly work in restaurants. If you have any questions or even suggesti
scoobydoo has joined #osdev
<zid>
am I scrolled up or something
<zid>
bloody time portals
freakazoid333 has joined #osdev
SpikeHeron has quit [Quit: WeeChat 3.5]
SpikeHeron has joined #osdev
skipwich has quit [Quit: DISCONNECT]
vdamewood has joined #osdev
skipwich has joined #osdev
vinleod has joined #osdev
jafarlihi has joined #osdev
vinleod is now known as vdamewood
vdamewood has quit [Killed (lithium.libera.chat (Nickname regained by services))]
<jafarlihi>
Can someone please tell me what's the right way of getting PID a physical address belongs to in Linux?
<zid>
very unlikely!
<zid>
This being osdev and not a linux support chan
<GeDaMo>
What's PID in this context?
<heat>
you can try and get the struct page but that still won't work
<jafarlihi>
GeDaMo: I want the PID of process it belongs to, can be TID
<GeDaMo>
Oh, Process IDentifier
<clever>
jafarlihi: i believe it is possible, one min
<bslsk05>
bughunters.google.com: Home | Google Bug Hunters
<jafarlihi>
If it works then I'll go around wardriving before I disclose it
<jafarlihi>
just for lulz
<heat>
that's an easy way to not get your bounty
<jafarlihi>
No one will know, I live in third world
<heat>
except... for the fact that you just snitched on you
<jafarlihi>
Why disclose to Google when you could sell it to Zerodium for 10x more pay?
<heat>
you sure about that?
<heat>
also
<jafarlihi>
Most Google paid in 2021 is 157k, Zerodium lists 2.5m for zero click rce
<heat>
do you have RCE?
<heat>
lol
<jafarlihi>
No, but I can try
<heat>
i bet it's not even an exploit
<heat>
"person who struggles to write a linux kernel module finds out millionaire exploit in android" is a new headline for sure
[itchyjunk] has quit [Remote host closed the connection]
<jafarlihi>
You jelly of my primitive?
<mjg_>
heat: you mean bug/0day. exploit is code which exploits the bug
<mjg_>
heat: s/exploits/takes advantage of/
heat has quit [Read error: Connection reset by peer]
heat has joined #osdev
<jafarlihi>
Is it possible to get kernel address range from userspace app in Linux?
<zid>
I t hink I just heard an audible grown
<zid>
groan
<jafarlihi>
take ur meds
<mrvn>
what is a kernel address range?
<jafarlihi>
nvm, i don't need it anymore, design change
<CompanionCube>
are you extra sure you wanna be saying all this when the public logs are *right there* lol
<geist>
plus you're asking people at google about stuff to try to get a bounty against a google thing?
<geist>
that makes me even less likely to even talk to you
<zid>
I wonder if you could get yourself fired for that, colluding with someone to claim bug bounties
<geist>
exactly
<zid>
I assume "yes, very easily"
<zid>
You might get away with a wrist-slap at first if you definitely didn't have anything to do with the code that was exploited, but if it was *your* code then straight to jail
<jafarlihi>
What's the best way of serializing a packed struct to be sent over Netlink as a string?
<jafarlihi>
base64?
<gog>
it has to be string, you can't send the raw bytes?
<jafarlihi>
As far as I know from sparse netlink doc you can't do that
<doug16k>
base64 causes 20% data expansion in exchange for being all [a-zA-Z0-9/+]
<doug16k>
it could be the best way if your communication channel restrictions make it the best way
<jafarlihi>
Oh wait, there's NLA_BINARY
<doug16k>
sorry 25%. it's 6 bits for every 8 bits of output
jafarlihi has quit [Ping timeout: 276 seconds]
[itchyjunk] has quit [Remote host closed the connection]
<zid>
also known as 64/256
Ali_A has joined #osdev
<mrvn>
"best" and "packed struct" are already contradictory
GeDaMo has quit [Quit: There is as yet insufficient data for a meaningful answer.]
<gog>
yeh packed structs are bad
<gog>
unless you really need them for some reason+
<gog>
can't imagine why
<mrvn>
you never need them, they just are convenient if you don't care about speed.
<zid>
I use them when I am being filthy and overlaying mmio
<zid>
with structured names
<mrvn>
zid: on ARM? That will be UB because writing bytes to a 32bit MMIO reg is bad.
<mrvn>
hope you use clang.
kingoffrance has left #osdev [#osdev]
<clever>
gog: the only code ive worked with that used packed structs, was dealing with an MBR table
<gog>
ah yes both valid uses
<gog>
of varying deegress of dubiousness
<clever>
it also has the nasty surprise of containing an un-aligned 32bit int
<\Test_User>
packed structs are useful for decreasing memory usage at the cost of cpu usage, or reducing network usage if for whatever reason you're sending them raw through the internet (second is prob a bad idea but at least a valid usage)
<clever>
and gcc may or may not do byte-wise loads, depending on the -O level
<mrvn>
Where do you even find MMIO structures that aren't aligned?
<mrvn>
clever: no, depending on the allow-unaligned flag.
<zid>
I only do it for mmio because I know the host cpu if I am doing it
<zid>
i.e for accessing a GDT entry
<mrvn>
clever: off for gcc, on for clang by default.
<clever>
mrvn: ~4 of the SDHCI registers on the rpi, are 16bit sub-regs, and allow doing 16bit load/store to a part of a 32bit reg
<zid>
if I know the host cpu, I know if unaligned reads/writes are legal
<clever>
mrvn: however, the axi bus doesnt deal with that well, and will merge/corrupt 16bit transfers
<mrvn>
clever: that's still aligned though
<clever>
yeah, its just smaller then the usual size
<clever>
other then that special case, basically everything is 32bits in size, and 32bit aligned
<clever>
and violating that causes problems
<mrvn>
and the AXI bus will merge/corrupt it when gcc does 4 byte writes.
<clever>
for some peripherals, any 8bit load, that isnt 32bit aligned, is treated as an invalid register
<clever>
so reading from +0 works, but +1, +2, and +3 are all invalid registers
<mrvn>
anyway, fazit: don't do packed.
<zid>
You can't just go around calling registers invalids
<mrvn>
I'm tempted to declare MMIO regs atomic<uint32_t>
<clever>
zid: it behaves the same as accessing registers that dont exist, via 32bit aligned addresses
<clever>
oops, forgot about a different thing
<clever>
attempting to read XHCI registers, when its disabled, causes linux to 100% lock up
<zid>
k thanks?
<clever>
ran the wrong cmd, and it killed the machine, lol
* zid
definitely didn't ask
<clever>
i was trying to get a diff example, and killed it
* mrvn
is watching Godzilla while it's on Amazon Prime.
<clever>
any register that doesnt exist, returns a constant of "spi0"
xenos1984 has quit [Read error: Connection reset by peer]
<clever>
this spi peripheral, only has 6 x 32bit regs within it, and the rest are all just an error/ident code
<clever>
but, if you do a mis-aligned read, to say +1, you will always get 0x69(i) back, even if it was part of a valid reg
<clever>
(if its 8bit)
Ali_A has quit [Quit: Connection closed]
Ali_A has joined #osdev
freakazoid333 has quit [Ping timeout: 264 seconds]
<mrvn>
if you do an byte read do you get back an 32bit value?
xenos1984 has joined #osdev
frkzoid has joined #osdev
<clever>
mrvn: i think internally, its a 32bit bus, that is ALWAYS 32bit aligned, and a byte-wise read, is the cpu selecting the right 8bits of that 32bit bus, with a byte-enable signal to tell the remote end which 8bits to use
<clever>
mrvn: and if the address doesnt exactly match, the entire 32bit bus gets loaded with a 32bit constant of "spi0"
<clever>
but the cpu was expecting an answer on bits 8:15 of the bus, so it only gets the 69 in '30 69 70 73'
<clever>
it does indeed sound simpler, if you just drop the lower 2bits from the address, set a rule that the 32bit bus must always be 32bit aligned, and then the bus just has a 30bit addr, 32bit data, 4bit enables, and some misc control flags
<mrvn>
but aparently it passes all 32bit down or the unaligned read wouldn't get the wrong result
<clever>
yep
<clever>
i forget the exact results, but ive seen people probing that with a load-many as well
<clever>
and it did something funky, like repeat a 32bit reg twice, when doing 4 32bit loads
<clever>
if i'm remembering that right, it would imply there was a 64bit bus at one stage, connected to the 32bit bus
<clever>
and that one, expects everything to be 64bit aligned
<clever>
so, to allow reads from +4/+5/+6/+7 to function, it duplicates the 32bit answer, when connecting a 32bit bus to a 64bit bus
<clever>
but, if you then do a 4x32bit load, the cpu has to break it up into 2x64bit
<clever>
and then the 64bit gets lost at the junction between 64bit/32bit busses
<clever>
so it becomes 2x32bit loads, with each value repeated twice
<clever>
all kinds of "implementation specific undefined behavour", where the specs say dont do this, and each implementation is free to do whatever it wants
bauen1 has quit [Quit: leaving]
<clever>
other testing i did, found that the vector core has a 256 bit bus to the caches, and can move 256 bits on every clock, sustained(for a total of 4096 bytes), but there is an 11 cycle startup cost
<clever>
an engineer has also stated, that the arm core on the bcm2835 (pi0/p1) only has a 32bit bus to the rest of the child
<clever>
chip*
<clever>
while the pi2/pi3, have a 64bit bus
<clever>
but its not clear which clock domain dominates it, the arm, or the axi
<clever>
perhaps the slower of the 2, plus issues waiting for an edge
bauen1 has joined #osdev
<doug16k>
if it is a 32 bit bus, you can expect somewhere to be thinking in terms of 128-bit blocks, because 4 bytes * 4 cycle burst = 128 bits. if it is thinking in terms of DDR memory interface, it would be 256 bits, 8 bytes * 4 cycles
<doug16k>
8 because double data rate 32 bit
<clever>
doug16k: the fun part, is that there are multiple buses, all of different sizes
<clever>
the mmio is all in a 32bit bus, while the vector<->cache is 256bit, the arm<->bus is 32bit, the dram is 32bit DDR
<clever>
and several others i cant name off the top of my head
<doug16k>
could be 16 bit wide DDR so it's back to 128-bit burst
<clever>
and yes, bursts help massively, like how the vector core takes 11 cycles to start a vector load, but once started, its only paying 1 clock per 256 bits
<clever>
so doing multiple consecutive loads greatly saes time
<doug16k>
yeah pipelining is why SDRAM is still with us. it's awesome
<clever>
the engineer on the forum said that the axi controller will automatically split and merge transactions
<clever>
so a 128bit bus, may turn into 4 x 32bit transfers on a 32bit bus
<clever>
i did also do some experiments with 4096 byte loads from uncached dram
<clever>
and while increasing the VPU clock speed, did result in it taking more clock cycles (it just stalled more, as it got too fast)
<clever>
doing the math on bytes/sec, it was actually more flat, and near the max capacity of a 400mhz 32bit DDR bus
dude12312414 has joined #osdev
<doug16k>
DDR can be pipelined out into one endless burst, well, until you have to do a memory refresh cycle
<doug16k>
but you can get close to using every cycle for data
<clever>
doug16k: what about having to open new rows?
<doug16k>
overlap that with the burst from another bank's row
<clever>
so you can open one row, while reading another row, in the same clock?
<doug16k>
yes
<doug16k>
you stagger the commands across the banks, they have independent row buffers
<clever>
i assume it has seperate addr and data bus then?
<doug16k>
only one can be using the data bus
<doug16k>
you stagger the commands so the end up not conflicting
<doug16k>
"you" meaning the memory controller
<clever>
where might i find better docs, on how i could drive ddr2 ram directly?
<doug16k>
to make that work you need to either make the blocks so big you ask for whole bursts, or you have a request queue that can complete out of order
<clever>
assuming i can bit-bang it fast enough
<clever>
> or you have a request queue
<doug16k>
in any case you need to get at least one request ahead to saturate it right
<clever>
one of the rpi engineers has stated, that the bcm2711 ddr4 controller, has multiple slave ports
<clever>
so it can queue up requests from several bus masters in the same clock cycle
<clever>
and then re-organize them internally,
<doug16k>
an FPGA memory controller might present it as 128-bit blocks because it fixes the problem of the memory being more clock speed than your soft core cpu
<clever>
yeah
<clever>
then you dont need to complicate the bus by telling the controller how big your burst will be
<clever>
and can run that bus at a far lower clock
<doug16k>
yeah
<clever>
> Most of the high-bandwidth bus masters have 128-bit data widths to SDRAM
<bslsk05>
forums.raspberrypi.com: Multicore PI System Bus Design Question - Page 2 - Raspberry Pi Forums
<clever>
combined with what you said, it does feel like the dram controller would have a 128bit slave port
<doug16k>
yeah, my toycore has 128 bit cache lines, one request is whole line, 128 bit
<clever>
even if its 32bit ddr to the outside, it may be 128bit internally
<mrvn>
my toycpu has 16bit bus and no cache
<clever>
and with 400mhz ddr2 32bit, thats 64bits per 400mhz, or 128bits per 200mhz
<clever>
so the internal bus can run as low at 200mhz, and still saturate the ram
<doug16k>
mine is fancy because it is a educational board with piles of peripherals
<doug16k>
has 64MB DDR
<doug16k>
I forget what number ddr
<doug16k>
ddr2 probably
<doug16k>
I use the 9th bit for dirty bit, then when doing writeback burst I use it for the byte enables, and store port is hardwired to write 1 to it, and line fill is hardwired to load 0 into it
Weiland has joined #osdev
<doug16k>
so I could enable a no-allocate store mode that clears it to 0 without MC request
<doug16k>
on store miss
<doug16k>
then writeback only writes what got written by stores
<clever>
the other thing i dont fully understand, is how you can wire a 32bit ddr bus, into a pair of ddr2 dies
<clever>
16bits each
<doug16k>
they don't care which bit of the word they are storing
<clever>
but how do you deal with sending commands to both at once?
<doug16k>
you can just put the same control signals into them both, but they use different data
<clever>
and reading a reply from both
<clever>
what about the MR's?
<doug16k>
they both work in total sync
<doug16k>
one gets and provides low bits, other gets and provides upper
<doug16k>
exact same command wires
<clever>
what about non-deterministic things, like say an on-die temp sensor?
<doug16k>
on what die
<clever>
lets say there was a temp sensor on the dram die itself
<clever>
and you had a command to read it
<doug16k>
that is probably on the SPD super low speed thing
<mrvn>
clever: then use one of the bti to chip select
<clever>
what pins are the reply sent over? and how does it not conflict when the 2 dies disagree
<clever>
i need some bus timing diagrams, to fully make sense of this
<doug16k>
SDRAM is given commands, it doesn't reply. the commands determine when a bank is allowed to use the data pins
<mrvn>
you need to select each chip for training too and pick the more conservative timings.
<doug16k>
you completely boss sdram around, it has no say in anything
<geist>
right. so you can gang as many as you want
<clever>
ah, that gives me an idea
<clever>
the 1gig pi3, is ganging a pair of 512mb dies together
<clever>
and rpi engineers have stated both that, no 16gig dies exist, but the bcm2711 can address up to 16gig
<clever>
so in theory, you could gang a pair of 8gig dies together, on a bcm2711
<clever>
however, a fork in the command traces, would likely be a nightmare for signal reflections
<doug16k>
commands are SDR
<doug16k>
easy
<clever>
and the data bus splitting in half and going to 2 places, means the training for each half of the bus differs
<clever>
the pi3's 1gig, solved that, by having the forking within the dram package
<clever>
2 ties in 1 epoxy package, that looks like a single "chip"
<clever>
very short stubs, less reflection delay
<clever>
doug16k: that that include things like read and open row? that would imply each command must request 64bits at once, because the data is moving twice as often as the commands
<doug16k>
the main case is needing one command every 4 cycles
<doug16k>
which is 8 transfers on DDR
<doug16k>
gives an idea how easy the commands are
<clever>
8 * 2 * bus_width bits?
frkzoid has quit [Ping timeout: 244 seconds]
<doug16k>
right, 4 cycle burst, then width * 2 bits
<clever>
which is 256 bits in this case
Ali_A has quit [Quit: Connection closed]
<doug16k>
during that "idle" time, it gets stuff going on other banks, so it would be intermittently more than 1 command per 4 cycles
<doug16k>
so it can just stream right into it back to back
<doug16k>
back to back on data burst I mean
<clever>
my rough understanding, is that you can have one open row for every bank of ram?
<doug16k>
right
<clever>
you must first open a row to do anything
<doug16k>
think of it like a really wide latch
<doug16k>
and you can ask for a burst of a range
<clever>
and then read/write access that opened row, which may be sram?
toluene has quit [Read error: Connection reset by peer]
<clever>
and refresh is just open+close
<clever>
and closing commits the row back to the array of capacitors
<doug16k>
yeah. "activate" means drain the caps for the row into the row buffer SRAM and hold it there
<doug16k>
precharge means put the data back into the caps
<clever>
and recondition the levels
<clever>
it may also do any on-die ecc during the open
<clever>
some posts on the rpi forums, claim the ddr4 chips, have on-die ecc, where it checks the ecc during the open, and auto-corrects any errors
<clever>
and the host controller is then entirely unaware of the ecc
<doug16k>
so you activate, then after a while that bank's row buffer has correct values, then you can issue requests to burst ranges of it back to back, then if you need a different row, you precharge the row back into the capacitor array, and activate a different row into the row buffer
toluene has joined #osdev
<doug16k>
but there are multiple copies of that whole thing so you can stagger them and get continuous data flow
<doug16k>
called banks
<clever>
and if you can arrange for data in ram, to be in different banks, you reduce the latency to switch between them
<clever>
because you wont be causing a collision within a bank
<doug16k>
you stagger the commands so only one needs data bus at once
<doug16k>
yeah, you can make stuff bank aware and not have to activate
<doug16k>
usually you don't know the memory that closely
<clever>
i think bank-aware and bursts, is why the h264 encoder on the pi is so nutty
<doug16k>
it could be mapped to address space funny
<clever>
its kinda yuv, but the planes are a total mess
<clever>
so you can access all 3 planes, in a 32x32 region, while taking all of the above into account
<clever>
> The H264 blocks need the frames in a weird column format(*), and also a second 2x2 subsampled version of the image to do a coarse motion search on. The ISP can produce both these images efficiently, and there isn't an easy way to configure the outside world to produce and pass in this pair of images simultaneously.
<clever>
> (*) If you divide your image into 128 column wide strips with both the luma and respective U/V (NV12) interleaved chroma, and then glue these strips together end on end, that's about right. The subsampled image is either planar or a similar column format but 32 pixels wide. Cleverer people than me designed it for optimised SDRAM access patterns.
<doug16k>
so you can stagger them and pipeline use of data bus even with delays
<doug16k>
when one is delaying, other bank is bursting
<doug16k>
round robin when ideal
<clever>
yeah
<doug16k>
it can become less than perfect sometimes
<doug16k>
pathologically changing row, for example
<clever>
less then perfect, if your accessing data where the stride matches up with the bank size?
<doug16k>
unluckily mapping to same bank too much
<clever>
so every access is in the same bank?
<clever>
yep
<clever>
and i think the SAND format for h264, was timed to not do that
<clever>
sized
<doug16k>
yeah, CRT accesses are so sequential, it's easy mode for MC
<doug16k>
can do that utterly perfect staggering
tsraoien has joined #osdev
<clever>
except, the h264 core needs Y, U, and V planes, it wants to access 1 macroblock at once (32x32), and it needs a second half-res image of the same frame
<clever>
so now its far more complicated to make it fit dram
<doug16k>
ah
<clever>
and thats why SAND is so much more complex
<doug16k>
yeah column is low bits of address you could say
<doug16k>
when you first look at ram, it seems really weird because it has half the address pins you think it needs
<doug16k>
because half is row, half is column
<doug16k>
might be off by 1 bit on one sometimes
<doug16k>
DDR standards say a specific width though IIRC
<clever>
doug16k: this has a good diagram on page 12
<doug16k>
yeah, see what I mean by "copies of that whole thing"
<clever>
lets see, it has 8 banks of ram, which is listed as "32,678 x 512 x 16"
<clever>
A[14:0] looks to be the addr bus, which can be either row or column
<doug16k>
yeah, the row column half-address thing
<clever>
while BA[2:0] looks like the bank selector, 3bit int, 0-7, 8 banks, perfect
<doug16k>
exactly
[itchyjunk] has joined #osdev
<doug16k>
onus on MC to stagger the commands so only one bank is using data lines
<clever>
the 18bit addr (A+BA) goes into the mode registers (likely the MR's ive seen elsewhere)
<clever>
while 15bits goes into the row muxes, and 11bits to the column stuff
<clever>
15bit row#, explains the 32678 in the memory array, so that is the row count
<mrvn>
normaly you have to latch the row and then can read multiple columns
<clever>
yep
<mrvn>
every 512 words you have to increase the row so you get a blib.
<mrvn>
blip
<clever>
and the 512x16 part, looks to be 512 columns, with each cell being 16 bits
<doug16k>
CAS latency is how many cycles after you issue a read or write it starts to use the data lines
<doug16k>
column read or write
<clever>
and then you have to plan out that many reads in advance
<clever>
so the bus isnt idle
<doug16k>
right
<doug16k>
they use the next 4 cycles
<doug16k>
when they start N cycles later, N=CAS latency
<doug16k>
so you have to make sure you don't go to another bank and say "read" too early or their burst will clash
<doug16k>
but you could go activate or precharge no problem
<clever>
yeah
Weiland has quit [Quit: WeeChat 3.4.1]
<clever>
i also notice, there is only a 2bit value, from the refresh counter to the bank control logic
<clever>
i suspect its refreshing 2 banks at once?
<clever>
this also came up, with the 8gig model of the pi4, it needed the dram power supply redone, i think because with 8gig of ram, you couldnt/didnt want to refresh more often
<clever>
so they instead refresh twice as much per refresh command
<clever>
and the diagram i linked shows that, the counter simply cant select 1 bank for refreshing
wand has quit [Ping timeout: 268 seconds]
<doug16k>
IIRC there is a "refresh this bank" and "refresh all banks" command
<doug16k>
depends how fancy you want to be
<clever>
combining what ive seen before, and this diagram with a refresh counter, it sounds like you just say "refresh something" at a regular interval
<doug16k>
fancy might get refresh over with during period it predicts will be idle
<clever>
and the refresh counter then increments its way thru all banks and rows
<clever>
and if the interval is high enough, it gets back to a row within the required timeframe
<doug16k>
yeah you just say "do a refresh" and the SDRAM logic worries about keeping track of where
<clever>
but, that counter only has a 2bit bank# coming out, 0-3, but this die has 8 banks
<clever>
so it would likely refresh 2 rows (banks 0+1) at once
<doug16k>
you have to do all the rows every 64ms. it doesn't care what timing pattern
<clever>
i think its a count of cycles on the 400mhz clock, between "do a refresh" commands, that will then meet the 64ms requirement
<doug16k>
yeah
<doug16k>
countdown is how you do it when you don't mind too much when there are delays
<clever>
but, thats not being changed with ram size
<clever>
so, the refresh interval changes based on how much ram you have
<mrvn>
I looked into using DIMMs for my toy CPU. But when I run it at 1KHz it's kind of hard to meet the 64ms refresh cycle.
<doug16k>
not necessarily, it would have more banks if row count gets too much
<doug16k>
think more banks across sticks
<clever>
yeah
<doug16k>
multiple sticks refreshing in parallel
<clever>
only x86 and other larger controllers can do that
<clever>
the rpi is limited to a single 32bit ddr port, on all models
<doug16k>
yeah, just making sure you didn't picture a 1TB machine doing nothing but refresh :D
<clever>
and this is also where ram slots on a motherboard having 2 colors comes into play
<clever>
i'm guessing the command/data for each port with the matching color, are wired in parellel?
<clever>
and they must all run at the same freq then
<clever>
and then an extra bit is used, to select which slot answers? or is the data busses instead ganged together, turning a pair of 64bit slots, into an effective 128bit slot?
<clever>
doug16k: hmmm, the only bit on that ddr2 diagram i linked, that starts to confuse me, is the DQ[13:0] area, it looks like its using bits 1/0 of the column to select a 4bit chunk of a 16bit cell, but then why is DQ 14 bits??
<doug16k>
yeah you just send the command to all of them, maybe conditional chip select
<doug16k>
that must be a typo
<doug16k>
see page 11, DQ[15:8]
<clever>
i also just noticed, page 12 is for the "512Meg x 4" chip, that does kind of imply its got a 4bit bus?
<clever>
and page 13 is the same thing all over again, but for "256 Meg x 8"
<doug16k>
x 4 means 4 data lines exactly
<clever>
where DQ is now 8bits wide, the MUX is selecting 1 of 4 8bit chunks from a 32bit cell
<clever>
and the column is one bit shorter
wand has joined #osdev
<clever>
so half the columns, half the capacity, plus the output interface is wider
<doug16k>
every other cycle is the other low bit
<doug16k>
edge, not cycle
<clever>
yeah
<clever>
this sounds like the kind of ram you would find on an x86 pc
<clever>
where you gang multiple 4bit cells together on a stick
<clever>
to create a 32 or 256bit stick
<clever>
and yeah, that DQ is looking more like a typo, page 14 then makes more sense, now its 64bit cells, with a 16bit bus going out
<doug16k>
yeah, it's 8 or 9 x8 on modern ones because it's a 64/72 bit interface
<doug16k>
you could use twice as many x4
<clever>
that makes me wonder, since the pi expects a 32bit bus, could i just gang together 8 * 4bit ddr2's and make it work?
<doug16k>
you can if you length match the data lines decently
<doug16k>
and make them almost the same impedance
<clever>
and thats why motherboard traces are so wiggly
<doug16k>
yes, they are making them the same length
<doug16k>
and/or impedance
<doug16k>
impedance is mostly the PCB person's problem. length is PCB layout's problem
<doug16k>
think of impedance as the resistance, accounting for the skin effect, where high frequency signal components only travel along the outside of conductors
<doug16k>
the rising and falling edges have extremely high frequency components
<doug16k>
way higher than what the clock implies
<doug16k>
the more straight up and down the rise/fall, the more unreasonable the frequency
<doug16k>
wires become resistors because that part of the signal wants to be on the outside of the wires
<mrvn>
and if the line wiggles you create induction
<doug16k>
but low frequency part goes right through like nothing
<doug16k>
yeah. even a straight trace is a "1 turn" inductor
<doug16k>
it makes a pitiful magnetic field around it
<mrvn>
butbut that's counted in the resistance of the wire
<doug16k>
inductance prevents current flow changes
<clever>
that reminds me, somebody had mis-wired the ethernet an ethernet cable, and it ran perfectly fine, for 11 months out of the year
<clever>
but in december, it had horrible packet loss
<clever>
miswired the pairs*
<doug16k>
it prevents off from turning on, and prevents on from turning off, as if by momentum
<mats1>
amazing
<clever>
can you guess why it only failed in december?
<doug16k>
autocrossover hid the problem partially?
<doug16k>
neat
<clever>
the ethernet cable was run outdoors, along the same hooks as the xmas lights
<clever>
60hz mains, magnetically coupled right into the ethernet lines!
<clever>
and because he didnt use the pairs correctly, it wasnt canceling itself out on the differential pairs
<mrvn>
*grrr* No speed of light lag on Moonhaven.
<doug16k>
CMOS inputs look like capacitors. the rising edge needs a current pulse to change the gate charge, then the falling edge needs a current pulse in the opposite direction. after the pulse part, it is no current flow at the gate
<doug16k>
so you want to instantaneously increase the current and have it gradually go down to zero, but inductance wants the opposite, a gentle ramp up to a current
zaquest has quit [Remote host closed the connection]
<doug16k>
so what you wanted to be a straight up voltage change "spins up" a one turn inductor that feels like a flywheel
<doug16k>
and it actually makes the gate voltage go past what you applied, then back, then past, ringing
<doug16k>
after it delayed the rise
zaquest has joined #osdev
<clever>
bbl
<doug16k>
the trace inductance interacts with the gate capacitance and makes the voltage ring when it changes
<doug16k>
energy is captured in the magnetic field, then later collapses back onto the wire and drives the voltage past the original at the gate input, then the gate input charge is higher than the driver end, and current goes backward through the trace
<doug16k>
but over distance the gradient gets smaller
<doug16k>
more inductance preventing the current change
<doug16k>
ends up looking like it oscillated around the desired signal value
<doug16k>
briefly
Vercas has quit [Remote host closed the connection]
Vercas has joined #osdev
<doug16k>
the universe is very springy
<doug16k>
springs everywhere
<zid>
I've seen scope traces of high freq circuits and to me it's fucking amazing they *ever* get it right
<zid>
rather than always getting it right
<doug16k>
yeah, that's why overclocking is so terrifying for me
<doug16k>
I realize how insane default is
<zid>
overclocking is pretty empirically solveable though
Ram-Z has joined #osdev
liz has quit [Quit: Lost terminal]
<mrvn>
doug16k: in CMOS electrons flow when you cross from hight to low or low to high. The less power you have to cross the neutral zone the more power it consumes.
<mrvn>
In modern circuit the fan in/out ratio is much higher than traditional CMOS.
<doug16k>
the input impedance is infinite for steady state. the gate is an open circuit, it's not connected to anything. all you are doing is charging it, it's basically a capacitor plate
<doug16k>
but you need to flow current in and out to charge/discharge it
<doug16k>
holding state is 0mA
<mrvn>
not quite
<doug16k>
it'll never be perfect because you'll have a tad of ripple. but close
<mrvn>
and some charge drains
<doug16k>
yeah but so close to nothing
<doug16k>
it's incredibly low leakage
<zid>
Watch out for those sneaky electrons though, they like to pretend that they're on different wires
<zid>
"but daaad I'm a waaave"
<mrvn>
zid: that's only for realy moddern circuits, not traditional CMOS
<doug16k>
that's why we call it "CMOS memory". because holding it in steady state takes almost nothing
<mrvn>
doug16k: there is enough leakage that you have to refresh the memory often
<doug16k>
that nearly zero power use to stay still is why it got named cmos
<doug16k>
dram is not nmos gate
<mrvn>
the bigger problem is getting into that high resistance state.
<doug16k>
it's a capacitor
<doug16k>
cmos is static ram
<doug16k>
it's gates holding themselves on or off
<doug16k>
but since each gate has essentially no current flow to hold it still, it takes almost no power
<doug16k>
it's like holding a balloon full. if you keep the pressure constant, no air flows
<doug16k>
power is flow times potential
<doug16k>
hold flow at 0 then power is 0
<doug16k>
it would be perfect if the voltage rail was perfectly flat
<doug16k>
neglecting tunnelling
<doug16k>
the gate charges up to the perfect charge to perfectly oppose your signal, and current is 0
<doug16k>
it's like putting dc into a full size capacitor. at first there is a pulse, until it charges up to your exact voltage and nothing flows
<doug16k>
in series with it I mean
<doug16k>
"it blocks dc" is what they say. same as the gate on a mosfet, it "blocks" that dc when in steady state
<doug16k>
put a squarewave into a mosfet gate in a simulator. you'll see a pulse of current that falls back to zero if state stays there, then a pulse when state changes, falling to zero again
<clever>
and thats basically what all of the decoupling caps around a cpu are for
<doug16k>
they fix the trace inductance
<doug16k>
the traces want current to ramp up and down diagonally
<doug16k>
caps provide the pulse
<zid>
I've never looked at what makes the various zener/mosfset/blahs different, maybe I should at some point
<zid>
I just know that transistors are npn/pnp and you suck the two sides together
<zid>
slurp
<doug16k>
the big thing with mosfets is, if you want them to have amazingly low on resistance, then you probably need to put a big charge into the gate, but if you can tolerate more on resistance, you can get ones that switch way faster
<zid>
I forget what the terms are now, P and N touching make a tiny neutral zone.. depletion area?
<zid>
depletion region!
<zid>
Man, this is crusty old knowledge from a long time ago
<doug16k>
you have to calculate whether you are losing too much in the switching region with a low resistance mosfet, or if you'd be better off with more on resistance, but switching way faster. you get a pulse of losses during switching
<zid>
We should just make idealized components and save everybody the hassle.
<doug16k>
or drive the gate really hard with low on resistance mosfet
<gog>
you contaminate some hot sand and it goes brrr
<doug16k>
like, using a pair of mosfets to switch the pulse to turn the big mosfet on and off
<zid>
gog: basically, but there's TWO types of sand, like those cool sand-in-a-bottle guys
<zid>
and it mixes a little sometimes if you shake it