psykose has quit [Remote host closed the connection]
psykose has joined #osdev
gog has quit [Ping timeout: 276 seconds]
<geist>
klys: basically have more or less full RO working. Been pondering how to deal with more structural open file/dir tracking in prep for RW support
<bslsk05>
github.com: lk/lib/fs/fat at master · littlekernel/lk · GitHub
<geist>
oh also started to write some more comprehensive unit tests
bradd has quit [Quit: No Ping reply in 180 seconds.]
bradd has joined #osdev
mahmutov has quit [Ping timeout: 272 seconds]
<clever>
geist: i was just thinking, how do you know what blocks are even free in fat?
<geist>
they have a zero in the FAT
<clever>
my understanding, is that the FAT table still has the singly linked list for deleted files?
<geist>
that's probably the primary reason cluster 0 (and 1) are unused by definition
<clever>
or are those slots zerod for the entire file?
<geist>
slots zeroed
<clever>
ahh
<geist>
so finding a free block is basically a linear scan of the FAT
<clever>
yeah
<clever>
semi related, i had an old hdd that suffered a drop, and dos wouldnt boot anymore
<geist>
FAT32 has an extra secondary data structure called FSINFO after the BPB that stores some hints to bootstrap the next mount instance, like first free cluster, etc
<clever>
but one day while playing with the "known dead" drive with the covers off, i discovered "dir" still could list files!
<clever>
and only when dir prints the free space, does it go into the click of death
<geist>
so to delete a file in the dir you just mark the first character of the name with 0xe5
<clever>
and having learned more about fat by that point, i knew free space was just iterating over the entire FAT table
<geist>
and presumably you dont touch the rest of it. or at least that's how DOS behaved
<clever>
so i just turned off displaying free space with a flag, and was able to recover some files
<geist>
since the FAT was zeroed out, presumably what would happen is if you wanted to undelete a file you hoped it was in one segment and would recover the clusters started where it was
<geist>
since you would have lost the chain
<geist>
and yeah total free space is one of the hints in the FSINFO
<clever>
this hdd originally ran win 3.11 i believe
<clever>
so it probably predates FSINFO?
<geist>
what's kinda dumb about it is the data structure 'helps' the next mount instance, but then in FAT.pdf it says the next mount must validate the info anyway
<geist>
yes, FSINFO is a FAT32 only thing
<geist>
so if you cannot assume it's up to date then what purpose does it serve?
<clever>
perhaps if it was cleanly unmounted?
<geist>
yah that's my thought. there's another cheezy hack where FAT cluster 1 has basically a mounted/clean unmounted bit you're supposed to set and clear
<geist>
i dunno when that shoed up, but looks like one of those 'oooh we have another bit that previously was ignored, lets use this)
<geist>
the whole design is full of that
<geist>
layers of backwards compatible hacks
<clever>
yeah
<clever>
another fun bug i had
<clever>
one of my mp3 players, lacked directory support
<clever>
all music must be in the root directory
<geist>
yah that was pretty common back then
<clever>
also, the root directory table is of a fixed size
<geist>
but the even worse FAT12 and FAT 16 is fixed size, yeah
<clever>
so the SD card runs out of space way too quickly
<geist>
the default is i think 512 entries
<clever>
i couldnt even use 10% of the card
<geist>
FAT32 fixes that too, actually responsible for a lot of the hackery in the dir parsing code i wrote
<geist>
having to deal with the root dir being a special case (in fat12/16) vs a normal looking file with a cluster list
<clever>
that mp3 player also had a weird quirk with its random play
<clever>
it was prng, with the seed saved somewhere to flash
<clever>
if the battery runs dead mid playback, the seed isnt updated
<geist>
hah
<clever>
so upon starting up again, it plays the same "random" songs again
<geist>
random on embedded is actually kinda a tricky problem
<clever>
i think it ran ~2 days on 2 non-chargable AAA's
<clever>
~1 day on rechargable ones
<clever>
then i said "screw it" and taped 4 D cells together, in both parallel and series
<clever>
it ran for 6 months :P
<geist>
yah i have some old Olympus voice recorder/m3p player thing that basically has all these limitations
<geist>
from the early 2000s
<clever>
6 month battery life!!, at the cost of the batteries being 3x the size of the mp3 player
<geist>
like those old lantern style flash lights. kinda miss em
<geist>
had a handle and a large square box under them
<geist>
usually took 2 of those square lantern batteries
<clever>
i think ive got one of those in the garage
<geist>
very 70s
<clever>
my mp3 adapter was very ugly :P
<clever>
2 D's end to end, tapped to the side of another 2 D's, to form a 2x2 square
<geist>
i never tried to see how the car handles mp3s. i should try it some day
<clever>
paperclips tapped to the ends as a bus bar
<geist>
i'm sure it can deal with an mp3 stick, or even a cdrom with mp3s on it
<geist>
but who carries those around, right?
<clever>
and some speaker wire going to dowels that act as AAA's
<Ali_A>
So I had to read 3-4 chapters of intel's manual, reading CSAPP Book chapter 7, reading a couple of books about C, a couple of books about assembly (there were for RISCV so the transition was a bit hard at first) reading a 4-5 chapters about 64 bit assembly, reading SYSV ABI , Linker and Libraries guide from Oracle, gas (gnu assembler) guide, tons
<Ali_A>
20~30 blogs about the process of linking, relocations, and sort of stuff, (and many other blogs for understanding bootloading from a floppy disk using real mode + many other things), and gdb and IDK, it is been 2-3 month since I started to make my own OS and all of that, was just to get a bootloader running, that loads an image from a compiled C
<Ali_A>
file into qemu, and being able to debug it. I knew OS dev was no walk in the park, but that feels like a bit too much? like shouldn't there be a better way? (tho, I like the result of it, I managed to learn how to not be surprised by how big manuals are and just read them, googling for hours, and learned new tools for sure) but I feel, considering
<Ali_A>
how many OS devs are out there (or at least people who knows what happens at the level of OS) I assumed there is like a standard set of things where u acquire before starting to build your own OS
<Mutabah>
Well... you don't need to write a bootloader really
<Mutabah>
I usually suggest using multiboot and getting grub/pxelinux to load your code
<Mutabah>
(which starts you in protected mode with a working framebuffer)
<Mutabah>
But, there is still a lot of other information you need to know to properly write an OS.
<Mutabah>
There are quiet a few tutorials that will either give you the rough outline, or just show you a away to do it that you just need to copy
<Ali_A>
I mean, I am just writing an OS from scratch, so I at least wanted to be able how loading is happening.
<Ali_A>
what is the natural next step for me in this case? there are many things, different tutorials continue differently after this step, my ultimate goal is to have a shell and port tinyCCompiler or any other C compiler and just probably have a hello world program from my own OS
<Mutabah>
Knowing abstractly how it works is useful, but bootloaders (especially BIOS ones) are lots of effort for not much gain.
<Mutabah>
Protected mode, text output, keyboard input, ...
<Mutabah>
then maybe a filesystem and usermode
<Ali_A>
is usermode necessary?
<Ali_A>
well, I guess it is necessary u don't want to write an app that corrupt your kernel so that was a silly question
nur has quit [Remote host closed the connection]
<Ali_A>
Mutabah thanks! will look at how to move to protected mode (I assume it is just a few asm instruction) and then will look how to output text from my kernel.
nur has joined #osdev
<moon-child>
Ali_A: usermode is not necessary if you restrict your applications to a capability-safe (ie memory-safe) language
<moon-child>
if your apps are all written in java, they won't be able to corrupt your kernel no matter what you do, so there is no point in doing hardware context switching
<moon-child>
if you want to support capability-unsafe languages, then yes, you should use hardware privilege controls
hwdyki has joined #osdev
<Ali_A>
Thanks
hwdyki has left #osdev [#osdev]
Likorn has quit [Quit: WeeChat 3.4.1]
xenos1984 has quit [Read error: Connection reset by peer]
<geist>
right basically most of what you listed off is complexities that exist on the x86 platform because of 40 years of backwards compatibility and lots of hardware flexibility
<geist>
you can skip most of that up front by letting firmware and bootloaders do that for you
<geist>
you may eventually want to figure it out, but it's not a good use of your time getting started
<geist>
and also a great way to really get discouraged
<moon-child>
indeed
xenos1984 has joined #osdev
bliminse_ has quit [Quit: leaving]
lg has quit [Read error: Connection reset by peer]
lg has joined #osdev
bliminse has joined #osdev
<Ali_A>
just to be sure on the terminology, firmware refers to the hardware and its ReadOnlyMemory that ships with it right ?
<stephe>
I see a lot of bootloaders using 16 bit code when stored on the MBR on an i386 machine. So i386 can't run 32 bit code right away or is it just due to trying to keep it within the 512 byte limit of the MBR?
<zid>
cpu turns on in real mode
<zid>
You'd struggle to boot your existing software if it booted in the new fancy incompatible mode
Burgundy has joined #osdev
<zid>
and by 'new' I mean '1982'
<stephe>
Hmmm ok
<gog>
you can indeed run 32 bit instructions off the MBR during real mode but they add an extra byte of override prefix
<stephe>
Right, so partially backwars compatibility and partly space savings?
<gog>
basically
<gog>
but it's also not necessecary because you can't even address >1MiB until A20 is enabled
<gog>
but getting into protected mode involves some time in spooky mode
<gog>
with A20=1 but CR0.PE=0
dennis95 has joined #osdev
<stephe>
gog: hmm i see
<stephe>
why is it spooky?
<stephe>
so with a20 enabled you can address 2MB?
<gog>
i was mistaken, spooky mode is when you have a segment selector loaded and then disable CR0.PE
<gog>
and it's spooky because you have the full range of address space for 32 bits but you're still technically in real mode
<stephe>
aha
<zid>
I'd say unreal mode is a cool mode, but then I remembered long mode existed
Ram-Z has quit [Ping timeout: 276 seconds]
<gog>
long mode best mode
<zid>
all other modes are dead to me
<gog>
any mode without IP-relative addressing is cringe
<gog>
so that leaves only one
<zid>
any mode where you have to fill out more than one tss value is right out, any mode where you don't get at least 32MB of memory is also right out
<zid>
really narrows it down
<gog>
yes
<gog>
it is unfortunate that the design of long mode means you can't really just start with the CPU already in it
<gog>
but that's what UEFI is for
<zid>
that's what my tiny bootstrap program is for
<gog>
also that
<vdamewood>
stephe: You can access more than 2MB with a20 disabled, you just can't access odd-numbered megabytes of memory, (using a 0 index).
<vdamewood>
So, megabytes 0, 2, 4, and 6 would work fine, but 1, 3, 5, and 7 would access the megabyte one lower instead.
<zid>
heh hadn't thought about it that way, but it makes sense
<zid>
it doesn't disable address lines >= 20, just.. 20
<zid>
you have a stuck bit for the parity of megabytes
<stephe>
vdamewood: ahh right
<stephe>
that makes sense
Ram-Z has joined #osdev
laocid has joined #osdev
dude12312414 has joined #osdev
dude12312414 has quit [Client Quit]
laocid has quit [Ping timeout: 248 seconds]
srjek has joined #osdev
Ali_A has quit [Quit: Connection closed]
doorzan has joined #osdev
Ali_A has joined #osdev
gwizon has joined #osdev
<Ali_A>
regarding bootloaders, I just remembered, I saw a video once about a person who used grub to load his kernel (which does nothing more than an infinite loop)
<Ali_A>
however, neither in linker script nor in the assembly he mentioned where should grub entry's point be? like in my own bootloader, I load my kernel at some sector, and then jump to a specific address within the loaded kernel to start executing the code, that section contains the first byte of my entry point. So my question, does grub have a defined
<Ali_A>
entry point that operating systems should follow or something?
xenos1984 has quit [Remote host closed the connection]
<Ali_A>
I just found the video for the reference, (it set's ` .= 0x100000` then puts the `.text` sections together, but that address is never mentioned again)
<Ali_A>
vdamewood thanks, that explains it, it just uses the .multiboot section to define the type of the architecture, and I believe it then knows that it is an elf, and just jumps to the elf's entry point, thanks!
<vdamewood>
This guy is saying some things I find kind of fishy
<vdamewood>
Like he talks about loading the first two megabytes from the hard drive, no. BIOS systems load the first 512 bytes from the heard drive.
<vdamewood>
hard*
xenos1984 has joined #osdev
<Ali_A>
I didn't follow his videos (tho I watched the first 3 or so), but after setting my kernel to be an elf (for making debugging with gdb possible) and I know elf format loads the entry point at 0x18 offset from the start of the image, I had to jump to it to start executing my entry point so I remember something like that never happened in this video
<Ali_A>
and wanted to ask
<gog>
you can tell ld where the entry poitn is on the command line, use _start, or it'll complain and default to the start of the first executable section
Likorn has joined #osdev
<Ali_A>
I usually just use the ENTRY command or -e
<zid>
Windows' sound mixer crashed, and now my audio has automatic volume supression somehow
genpaku has joined #osdev
<zid>
so if any of ya'll get as far in your osdev to get a sound mixer, don't do that pls
srjek has quit [Ping timeout: 240 seconds]
xenos1984 has quit [Read error: Connection reset by peer]
dennis95 has joined #osdev
Likorn has joined #osdev
Likorn has quit [Client Quit]
zaquest has quit [Remote host closed the connection]
xenos1984 has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
<nomagno>
Do conditional branches in ISAs usually just skip the next instruction?
<zid>
nope
<nomagno>
Then what do they usually do?
<zid>
usually a small relative offset added to pc
<GeDaMo>
ARM used to have conditional instructions
<zid>
but still weren't usual
<nomagno>
zid: right so 'jcz 12' usually skips 12 if nonzero?
<zid>
... if(x) { printf("meow"); } ... -> jz skip1; do exceptional case; blah; blah; skip1: do normal crap
<zid>
you jump to the } effectively
<nomagno>
zid: I'm talking about machine code, not assembly, if that makes sense
<nomagno>
I care about the microops
<zid>
Microop cache does none of this stuff
<zid>
on a modern isa
<zid>
It just completely eliminates the instructions it won't run from the stream
<nomagno>
Why does trying to get sane design lessons from modern CPUs always fail?
<zid>
so if a; b; c; d; e and there's a jump from b to e and it predicts it will be taken
<zid>
it just decodes a; b; e; into the micro-op cache
<GeDaMo>
Sanity is over-rated :P
<zid>
and if the jump really wasn't taken, it'll stall and refill it correctly instead
<nomagno>
That's messed up
<zid>
It's incredibly fast, though.
<zid>
The code itself should still be in L1, so the penalty isn't that big, and the successful prediction is a HUGE win.
<zid>
It's like rewriting the program to have no jumps or conditionals in it ahead of time
<zid>
It turns things like a 'loop over 4 things adding them together' into 4 straight adds, clearing all the overhead of the compare test and jump
<zid>
With a sufficiently clever computer: mov eax, 4; L1: add ebx, 1; dec eax; jnz L1 can just turn into "add ebx, 4"
<zid>
That's why we have a billion transistors implementing the same thing as 30k transistors did in the 80s :p
<zid>
and why they use 250W of power
<nomagno>
I'd take a decrease-in-ops-per-Mhz if it means all of a sudden there's more than three CPU vendors.
<zid>
for what reason
<zid>
nobody else would
<nomagno>
On the grounds of not liking oligopolies
<zid>
and you can always use an 8051 if you're serious about that
<GeDaMo>
There are more than three vendors but none of the others make anything you actually want to use :P
<geist>
sure or use some arm or riscv cpu. tons of vendors there
<geist>
but anyway, modern superscalar design is complex but not that different between vendors. it's pretty standard stuff
<geist>
just varying levels of tradeoffs and design ability of the different teams at different companies is all
<nomagno>
I'm trying to use RISC-V yes. But I also want to buy a patent-free one, which means being picky
<geist>
you can't always get what you want
<nomagno>
Starlight got close but it clearly wasn't good enough to get regular runs
<nomagno>
BeagleBoard should release something in the next few years that is decent
<geist>
anyway i dunno how you're getting superscalar design and patent free and whatnot intermixed. you're saying you only want cpus that are sufficiently old that they dont use modern, patented techniques?
<geist>
if so, as zid says. use something 20+ years old
<nomagno>
geist: No, I'm saying on the one hand I think superscalar design gatekeeps the industry, and on the other that when I buy RISC-V it'll be something patent-free, which really isn't that far fetched
<mrvn>
zid: why should it include c, d? Should it do that for jumps covering 1GB? That's the same as predicting the jump not being taken (or predicting both branches being taken)
<geist>
i think it's more like the branch predictor will up front decide which way the branch is going to go, and the cpu will start running that path. it should be correct most of the time
<j`ey>
nomagno: are you sure its patent free? i thought it was one of those things where people with patents allpw them to be used by riscv
<zid>
risc-v will be slow as fuck without patented implementation techniques
<nomagno>
j`ey: RISC-V is specifically not patented
<zid>
might as well use an 8 051
<nomagno>
zid: I'm trying to support open development in general, thank you for expressing your disillusionment.
<zid>
reality*
<zid>
If you braindead implement risc-v like we did in the 80s it will.. perform like an 80s chip
<nomagno>
Well you just add more hertz!!!!
<zid>
it isn't some magic isa with easy performance gains, it's actually a really crap isa that clever implementation may make fast enough to be usable
<mrvn>
Here's some food for thought: All the pipelining and branch prediction and such is because waiting for stuff to finish before doing the next takes way too long. But why not extend hyperthreading way way more? Run 8, 16 or even 64 threads and waiting for the condition of a branch to compute is a none issue.
<zid>
power.
<mrvn>
you save power by eliminating the pipeline gates
<zid>
It's the literal answer.
<zid>
The reason you don't, is it's incredibly power wasteful
<zid>
You could just pack in twice the clockrate and then waste 20% on branch prediction, instead of using 200% the power
<mrvn>
You can also better utilize functional units. Instead of 6 cores with 3 adders each you have 1 core with 18 adders used by 64 threads.
<zid>
branch prediction is a win in 99% of cases, that means you're running the wrong code 99% of the time.
<nomagno>
zid: It's pretty clear RISC-V gets destroyed by ARM and AMD64 any day of the week, doesn't really change my sentiment that supporting ISAs where it's reasonable for new players to enter the market at speedy rates is a decent idea
<mrvn>
zid: branch prediction is only a win if you don't have any other work to do inbetween.
<zid>
go for it, but it isn't practicable
<zid>
chip fab is expensive, designing cpus is expensive. The ISA is the easy boring bit.
<zid>
The reason you use an existing ISA is to cover the costs of the former, you get to be a VIA selling chips into a market you don't own.
<zid>
or a cyrix
<mrvn>
The thing is that the average PC now has something like 4-6 cores and software (and games) are utilizing it more and more. Getting 8-64 threads do actual work is not impossible.
<zid>
*only* using my fpu units already breeches my power budget.
<mrvn>
zid: try using >80% of your cpus functional units
<zid>
okay give me 400W more cooling and I'll try
<mrvn>
just let it throttle down
<raggi>
I don't always wear my power budget, but when I do I stay warm
<zid>
sounds identical to doing nothing to me, but you get worse latency
<zid>
I get to run the genuinely single thread things at 5GHz too instead of 1GHz
<mrvn>
zid: nah, you have to do something useful, not just dummy ops to keep units busy.
<zid>
so now you owe me 400W and a unicorn program
<nomagno>
I don't know, while it may very well be faster to do CPUs the modern way with their speculative execution and OOE and all of that, on the other side why does AMD64 have like 3 layers of abstraction between almost-unnavigable machine code and dead-simple microcode?
<zid>
yes, an amd64 'may be faster' than an 8051.
gwizon has joined #osdev
<nomagno>
I get legacy compat, but the 90/10 rule is an understatement with x86
<mrvn>
nomagno: backward compatibility
<zid>
nobody cares about how complicated the machine code is, concentrating on decode speed is a relic from the 80s before CPUs were faster than memory.
<zid>
As soon as memory is slower than the cpu your considerations completely invert.
<zid>
At that point you care about keeping caches filled and speculation for read-ahead etc
<nomagno>
zid: A monster ISA is not really better by any possible heuristics ever tough
<zid>
Except the one that matters, performance.
<mrvn>
Would be fun to see a massively SMP 6502, like 1024 core.
<nomagno>
zid: what's the logic behind a monster ISA being faster than a small one?
<zid>
nomagno: hardwre is faster than software.
<mrvn>
nomagno: the ISA isn't the bottleneck
<zid>
a magic complicated crc32 instruction
<zid>
is VASTLY faster than a software implementation of crc32
<nomagno>
Not being the bottleneck wasn't my point. It was x86_64 is ugly as fuck
<zid>
ngl it very much appears to me that you're just here to troll
<moon-child>
nomagno: oh yeah, well
<moon-child>
you're ugly as fuck
<mrvn>
nomagno: but it runs win95.
<nomagno>
I'm not trolling, but that's unironically what a troll would say so fuck. I'm just frustrated at modern machines
<nomagno>
The complexity is justified but still not-nice
<mrvn>
nomagno: and nobody is arguing that x86 is ugly as fuck
<mrvn>
why do you think so many work on ARM instead?
<nomagno>
Well I think so. It isn't very objective mind you
<nomagno>
mrvn: nobody is or isn't?
<nomagno>
I'm not so sure nobody is arguing for either side honestly :P
<mrvn>
nomagno: it's a 64bit system based on a 32bit extension of a 16bit cpu build out of a 8 bit design copied from a 4 bit crap.
<zid>
and as mentioned, it's *completely* irrelevent
<sbalmos>
finish out the line
<mrvn>
nah, I think the 4 bit was an original design
<nomagno>
mrvn: Yeah well I'm sure you can find some people that like it, but anyways
* moon-child
grabs popcorn
<sbalmos>
by a 2 bit company that can't take 1 bit of criticism
<zid>
it'd be relevent only if decode speed became a major factor again somehow, and if we lost access to C compilers
<mrvn>
nomagno: the ISA is for legacy code and since it takes less than 1% of power / gates nobody cares.
<mrvn>
(except us poor programmers)
<mrvn>
Is there any x86_64 CPU yet that has dropped 16bit support?
<nomagno>
On a related note, the ME/PSP are like, total security holes
<zid>
I believe someone mentioned there was an embed range that didn't have it
<kingoffrance>
+with software from a 2 bit company <insert vendor you dislike here> that cant stand 1 bit of competition
<zid>
if you consider 'being able to use your PC' a security hole, then yes
<zid>
There was always a ME, just now you know some vague details about it.
<mrvn>
And if you don't want to mess with ME/PSP you can always put your rootkit on the NIC.
<zid>
or literally anywhere
<mrvn>
Run a nice little ARM OS on the WiFi card.
<zid>
the point of these firmwares is to run, it doesn't matter which you modify
<zid>
the ME is at least signed
<nomagno>
The capabilities of the ME and PSP are kinda not the same as those of any kind of predecessors
<mrvn>
I would love to be able to run a tiny webserver on the wifi card.
<nomagno>
Doesn't it also have network capabilities?
<zid>
always has done
<zid>
wake-on-lan isn't new
<mrvn>
nomagno: it has access to the NIC
<mrvn>
zid: Question then is: Can it send network traffic while asleep?
<zid>
Yes
GeDaMo has quit [Remote host closed the connection]
<mrvn>
I could imagine the NIC powering down the sending part of the hardware when in standby
<nomagno>
Well that's not very nice is it. Signed firmware that can't be turned off and likely will never be patched on most computers, and has network capabilities
<nomagno>
At that point I'd prefer the firmware not be signed by intel, and it requires you to enter a DNA sample to swap it
<nomagno>
:P
<mrvn>
nomagno: worse: you can't patch it because you can't sign it.
<mrvn>
And the firmware is controlled by foreign states
<nomagno>
mrvn: Well intel releases patches
<nomagno>
So not exactly true
<mrvn>
nomagno: intel is not you
<mrvn>
They and the US can patch in a backdoor into your system. They will never ever patch one out.
<zid>
You don't
<zid>
have to plug anything into the system NIC port
<mrvn>
zid: doesn't help if it's a shared port
<zid>
The one on the mobo is the special system access and control port
<zid>
which the ME uses for remote management in the server room
<zid>
if you give a shit about it being connected to the internet.. don't
<nomagno>
mrvn: well you can patch it
<nomagno>
You are applying the patch
<nomagno>
Yes, I know semantics is irrelevant here, but it irked me :P
<mrvn>
I always hate the servers where eth0 and management share a physical connector. It's insecure and I haven't seen one that doesn't break and need a power cycle every now and then.
<mrvn>
nomagno: by "you can't patch it" I obviously mean you can't fix the code yourself.
<mrvn>
Apropo hiding code somewhere: The x86 MMU is turing complete. Just compute stuff on it.
<nomagno>
Is there any part of x86 that isn't turing complete?
gwizon has quit [Quit: leaving]
<mrvn>
floppy controller?
<nomagno>
I bet the list of turing-complete instruction mnemonics is greater than that of non-turing complete
<nomagno>
has anyone actually taken a look at this!? :P
<mrvn>
sure. there are lots of papers on minimal opcodes required for a cpu
<zid>
turing completelness is a pretty low bar
<zid>
the problem is the infinite tape
<nomagno>
No no, I'm talking about specifically x86 instruction mnemonics
<nomagno>
the ones that depending on the arguments and context change opcode
<mrvn>
well, the infinite tape part is always ignored for a finite tape large enough to do at least something
<nomagno>
the MOV instruction/mnemonic is LBA-complete by itself, by a long shot, for instance
<zid>
"x86 mmu is turing complete, you just need 128TB of ram per conventional kilobyte" isn't as impressive :p
<mrvn>
nomagno: nand is. add I believe isn't.
<zid>
"and it runs at 4IPC, instructions per century"
<mrvn>
zid: but I have 128TB :)
<nomagno>
Is there actually any way to actually build a computer with only non-conditional NAND applications on a turing machine?
<mrvn>
nomagno: yes
<nomagno>
Because it seems to me like you'd need a NAND tree, rather than a NAND list
<mrvn>
so?
<nomagno>
mrvn: yes to the first or second message?
<nomagno>
so what?
<nomagno>
urgh I'm confused now
<mrvn>
a turing machine can compute anything that is computable. Evaluating a nand tree certainls is computable.
<nomagno>
mrvn: No, I'm saying if a NAND tree is turing-complete
<nomagno>
asking*
<mrvn>
nomagno: you can build a turing machine out of nand gates
<mrvn>
connect both inputs and you have NOT. That gives you AND, OR, NOR, XOR and every other gate you usualy have.
<nomagno>
mrvn: yes, I played the little game where you do it, but the thing is I'm not sure which data structure would be able to represent the arrangement of nand gates necessary
<nomagno>
a tree? a directed graph?
<mrvn>
s/tree/graph/ by the way
<mrvn>
a directed cyclic graph
<nomagno>
mrvn: Yes, I know that, there's a little web game somewhere where you put it in practice, neat
<nomagno>
but what kind of graph?
<nomagno>
Necessarily cyclic?
<mrvn>
yeah. Has to loop somewhere
<nomagno>
HM... yes
<mrvn>
You can compute anything with a tree or non cyclic graph but a turing machine needs to loop
<mrvn>
you don't want to build one tree per problem.-
gwizon has joined #osdev
<nomagno>
I'm not actually sure you'd be able to make useful memory out of this tough, don't the weird toy NAND flip-flops that keep state need essentially to be async to work?
<mrvn>
nomagno: you can build all the gates out of NAND and then just implement the common flip flops
<mrvn>
I believe some of the common flip flop designs (inclusing master/slave) even use NAND naturally.
<nomagno>
mrvn: they do
<nomagno>
mrvn: yes but the issue now is that is the nand cyclic graph can only be executing one NAND at a time, you can't keep alivethe signal can you?
<nomagno>
you need multiple NAND 'tape heads' going trough the graph at the same time to achieve persistent state, which I guess makes sense
<mrvn>
heah? every NAND gate in the graph evaluates every tick
<nomagno>
mrvn: Hm...
<nomagno>
you're right
gwizon has quit [Client Quit]
<mrvn>
if you want to simulate this digitally then you double buffer all gates so signals take 1 tick to propagate through the gate.
<mrvn>
Same if you simulate it analog and want it accurate
Likorn has joined #osdev
<nomagno>
I don't see how double buffering will help simulate proper propagation
<mrvn>
you compute all the outputs from the inputs into an internal buffer. None of the inputs change during the computation. Then when it's all done you propagate the internal results to the output and all the inputs change.
<geist>
re: riscv and patents. the riscv *design* is patent free but that doesn't mean you can't build an implementation that uses all sorts of tricks
<geist>
and i dont think the riscv license forbids you from using patented implementation techniques
<nomagno>
geist: It doesn't
<nomagno>
that's why I didn't say I'm buying a RISC-V CPU
<nomagno>
I said I'll try to wait for a patent-free RISC-V CPU
<geist>
sooo..... that doesnt leave a lot
<nomagno>
which is a narrower subset
<nomagno>
anyways mrvn: I see, thanks, useful insight!
<geist>
how do you know something is patent free?
<geist>
because it says it is doesn't mean it doesn't infringe on patents. the creator just may not know it
<zid>
geist: That's what I mentioned earlier, might as well use an 8051 if you don't want patents, risc-v will be just as slow without patented implementation techniques.
<nomagno>
geist: Same can be said of copyright
<geist>
right. something so old its bound to have not touched any modern patents
<mrvn>
nomagno: it's something that you need for any cellular automaton and that most game designers aren't capable of using.
<zid>
Plus who gives a fuck if something was *created* using patents.
<zid>
Everything is
<nomagno>
you can make a copyright license and it's considered safe. Why wouldn't a patent license be safe?
<zid>
coke, bread, water
<geist>
nomagno: sure, but one can claim something is patent free but it doens't mean anything when the lawyers find it infringes
<geist>
that just means the creator is saying they dont knowingly use any of their own patents
<geist>
that doesn't give you some sort of legal protection
<geist>
though IANAL
<nomagno>
mrvn: Do you really need it for a cellular automaton? ... Oh yeah I see what you mean, my implementation of rule 110 a while ago definitely wasn't stupid enough to edit the buffer live
<geist>
whereas if you use an implementation from a company that says 'we license this for use in X and we will give you patent protection if you use it' you're in basically a better place
<nomagno>
So that's what you mean with double buffering
<nomagno>
Makes sense
<mrvn>
nomagno: it's also something you want to multithreading. Because with this simple buffering trick you can compute all elements in any order on any number of cores.
<nomagno>
mrvn: Yeah I'm pretty sure I actually apply this everywhere without calling it double buffering :P
<mrvn>
nomagno: it's what you call it in graphics. :)
doorzan has quit [Remote host closed the connection]
<mrvn>
you have it a lot on the hardware level too. Just think how many latches your CPU has.
<nomagno>
mrvn: Yeah well my game's software renderer is underway, but mentally I was just thinking 'on my side I have a buffer, then I blit it to the screen when the frame is done'
<mrvn>
screen being the second buffer hence double buffering
<bslsk05>
'Life in life' by Phillip Bradbury (00:01:30)
<nomagno>
doing this*?
<mrvn>
nomagno: a ton of games
<nomagno>
'oh yeah I'll just copy stuff to the screen live, makes perfect sense'
<nomagno>
I guess the atari 2600 games DID do this, which is bonkers
<nomagno>
they actually blitted just in time for the CRT scanning beam to copy the stuff over
<nomagno>
shit tier machine
<mrvn>
A lot of games don't buffer the game state and then you can't tirivially multithread the code or at all.
<nomagno>
mrvn: I think my game state isn't actually buffered, thinking about it. My reasoning was since the output is the only way to know when it changes, and that is obviously buffered, it's fine
<nomagno>
But yeah that's a fair point
<nomagno>
Thanks, actually!
<nomagno>
I'll write this down in my design notes
<mrvn>
nomagno: as soon as the output is the input of something else you introduce a dependency there
<nomagno>
mrvn: is that to say my strategy is fine or I should make it double buffered to make it more modular?
<mrvn>
nomagno: i would always double buffer to break the dependency
<nomagno>
Was thinking so too, I'll add it to my notes then for sure
<mrvn>
Otherwise you end up with e.g. items moving down faster than up.
<mrvn>
Or things depend on the order you place them on the board. Worse, saving a loading a game can change the order of items and suddenly the timing changes.
<mrvn>
and as said, the big one: double buffered you can trivial multithread stuff.
<mrvn>
nomagno: another tip: you don't have to copy the data in the propagation phase. Just have a "Foo output[2];" and a global "int phase" that switches between 0 and 1 every tick.
<mrvn>
output[phase] is last turns output (this turns input) and output[1-phase] is this turns output
<mrvn>
nomagno: I like documenting stuff in .md files
<nomagno>
Should have been fixed, if the bot didn't hate me
<nomagno>
mrvn: I like it too!
<mrvn>
nomagno: I would even say code and docs should be in the same repo so you always have the code and docs match. Even more have it in the same file.
<nomagno>
mrvn: Hm... fair
<nomagno>
Well I try to make everything be self-documenting... and then I add tons of comments anyways because verbosity cool
<mrvn>
saddly, that still doesn't garantee people will update the docs when they update the code.
<mrvn>
a++; decrement a by 1.
<mrvn>
+//
<nomagno>
Any suggestions to improve my website workflow? I guess my current approach is safe. I commit to the repo, push, log in manually to the webserver box, then git pull
<nomagno>
An automatic git pull would risk someone hacking some less secure device and uploading malware to the website trough the docs/ folder
<mrvn>
why not push to the webserver when you commit/merge to the stable branch as commit hook using an ssh key?
<mrvn>
or when you sign a commit
<nomagno>
commit signing is a good idea, the ssh hook IDK
<mrvn>
ssh just takes care of the manual part
<nomagno>
I guess
<nomagno>
But wouldn't this require the source forge to have some kind of CI/CD?
<mrvn>
You can have the webserver fetch, check the signature and only then merge
<Ali_A>
I was reading this and it says, "ake care when implementing your kernel. If you use segmentation, the DS segment should be configured to have its base at the same address as SS does. Otherwise you may run into problems when passing pointers to local variables into functions, because normal GPRs can't access the stack the way you might think." I
<Ali_A>
don't quite get that, any ideas?
<bslsk05>
wiki.osdev.org: Stack - OSDev Wiki
<Ali_A>
what does it mean, "normal registers can not access the stack the way u think"
<zid>
ds and ss not being in the same range puts locals and statics/dynamics into different address spaces effectively
<zid>
so if you copied the value of esp into esi for example
<zid>
*esi would no longer refer to the same place *esp does
<zid>
which will make a C compiler *very* unhappy
<Ali_A>
I am not very familiar with segmentation mode, but I thought `data segment` points to `.data` in the assembler? and that is a segment (at least on ELF format) points right after `.text segment` , while I know that the stack usually is just below the kernel and grows downward, so they are very far from each others no?
<zid>
no
<zid>
ds is a selector that determines the attributes of regular memory accesses
<zid>
mov eax, [esi] and such
<zid>
permissions, base, range, etc
<zid>
ss is a selector that determines the attributes of stack accesses
<zid>
push, pop, etc
<zid>
(and cs for code, instruction fetches)
<Ali_A>
I might need to re-read chapter 3 from intel's manual, because I thought it was stack segment (SS), code segment (CS) data segment (DS)
<zid>
You could for example, load your code to 0x0, your data to 0x10000 and put your stack at 0x20000
<zid>
and then set cs, ds and ss's bases to 0, 10000 and 20000 respectively
<zid>
and then they all see their respective data at '0'
<zid>
so esp of b00 would give 'push blah' -> base 20000 offset b00 -> access address 20b00
<zid>
and esi of b00 would give 'mov [esi], blah' -> base 10000 offset b00 -> access address 10b00
<zid>
That's called a segmented memory model and it's awful please don't
<Ali_A>
yeah, this is the first time I hear or this, '=D , besides chapter 3, which part I should read to understand this in a bit more detail + (yeah I never used segmented memory mode, so no wonder)