<geist>
fairly standard technique for reusing existing blocks in your cpu hardware for multiple things by sequences a series of steps. basically if your cpu is multi cycle anything it's at least going to need to have some sort of sequencer, usually in the form of a ROM, to drive it
<geist>
8080 and whatnot was basically applying a standard technique on the then new microprocessor, vs a big pile of TTL chips or vacuum tubes
<zid>
6502 has a nice little mask rom covering 1/5th of the die
<zid>
each instruction is 4 cycles and it just grabs a 100bit value for opcode * 4 + cycle from the table, for which control lines to light up, done
rwxr-xr-x has joined #osdev
<geist>
yep. doesn't really even grab it, it just has the current opcode latched + some sequencer i think that's directly driving the rom at any given point
<geist>
which is then driving a bunch of control lines
<geist>
but that's basically the standard microcode implementation. wire up a bunch of generic components (registers, ALUs, etc) to a common bus or two and then use N bits out of microcode to directly gate which piece is reading/writing to the busses at any point
<geist>
i think ben eater has a pretty good series of this too, and i'm seeing some folks build more sophisticated designs based on what ben did
<rwxr-xr-x>
ben eater makes super good shit
<rwxr-xr-x>
jdh too
<geist>
yah he is good at keeping it simple and not skipping over things, even if it feels slow sometimes. he also makes mistakes and then fixes them, instead of just editing it out. i appreciate that
gildasio1 has quit [Remote host closed the connection]
<bslsk05>
github.com: PlaceholderOS/kernel_entry.asm at f8eb19b3a1aee577c3406a5be2432c5197008bb0 · FrostWizard4/PlaceholderOS · GitHub
<rwxr-xr-x>
I can breakpoint to all the spots I would expect it to, but it never gets there
<zid>
what on earth is this file
<rwxr-xr-x>
lmao
<zid>
it's exporting the symbol it's calling, but also copy-pasting a different file into itself, that presumably has that definition... *boggle*
<rwxr-xr-x>
See, that's where the second question comes in, what are some good resources for learning asm?
<zid>
This is just a structural mistake from lack of programming knowledge
<zid>
the assembly is fine, `call blah` `jmp $`
<rwxr-xr-x>
Yeah, i barely understand how this shit works, and I know a good few languages
<rwxr-xr-x>
assembly is like fucking chinese
<zid>
odd, assembly is easier than any other language
<zid>
good luck with your Box<Box<List<Map::cancer<T>>,12>>s
<rwxr-xr-x>
that's what I think as well, but I can write java, c or javascript all day long,and I love messing with assembly but it screws with my head
<zid>
I don't believe you can write C all day long
<zid>
if this is how you use #include
<geist>
lets keep it nice
<rwxr-xr-x>
I can write it, didn't say it would work though
<zid>
haha nice
<rwxr-xr-x>
I do though funnily enough
<rwxr-xr-x>
and somehow it works
<rwxr-xr-x>
it ain't efficient though lmao
<zid>
but yea, global/extern/include all work identically to how they work in C
<gog>
i'm writing c++
<zid>
so given you made it here, you also would have made it in C, ergo it's not an asm issue, it's a structural/programming issue
<rwxr-xr-x>
shit that would've been nice to know earlier
<zid>
That's exactly my point
<zid>
If you were comfortable with how they worked in C, you wouldn't have been confused about how they worked
<rwxr-xr-x>
fair enough
<zid>
if this were a C program, you've done `int kernel_main(void); #include "kernel.c"`
<zid>
which I very hope isn't how you write C programs, but who knows
<geist>
so fundamentally you use asm files the sam way as C files. ie, you can have multiple ones, and you can even have headers, but the linker puts together them at the end, etc
<geist>
depending on the assembler you're using you may ormay not have to declare externals though. gas for example you simply use a symbol and then you have to resolve it in the linker or it doesn' tlink
<geist>
but you *do* have to export symbols from gas assembler files with .global
gog has quit [Ping timeout: 256 seconds]
<rwxr-xr-x>
Interesting
<rwxr-xr-x>
thanks for the info!
<rwxr-xr-x>
for some reason I never even thought I had to do any work with includes, i can just stick in the path to the file and it handles it
<bslsk05>
www.righto.com: How the 8086 processor's microcode engine works
<geist>
ah already linked. well good naywya
<rwxr-xr-x>
Okay, so, I %include "file_name", then pass the path of file_name into nasm when making an object file with the -i option, correct?
<zid>
no, not in the least
<zid>
includes are text-copy pastes, that's it
<zid>
In practice they're for storing macros and equs and other helpful things that you might wish to have in multiple files
<zid>
but don't want to write out multiple times
<zid>
object files are units are code, which may import or export symbols, which the linker resolves when producing the output executable
nyah has quit [Quit: leaving]
<rwxr-xr-x>
So including a file is the equivalent of pasting the contents into the file i'm working in
<geist>
yes
<geist>
so you *can* split your system over a bunch of files and then just include them in one spot, but that's pretty rare and that that useful
<geist>
usually you just use include to do as zid says: include macros or other common shared source between different .asm/.c/.S files
<rwxr-xr-x>
gotcha
<rwxr-xr-x>
the point of switching from the bootsector to kernel is confusing as all hell for me, in my mind, when reading the nasm docs, I want to extern kernel_start, and global it in kernel.asm
heat_ has quit [Ping timeout: 256 seconds]
<geist>
well to be fair it *is* tricky and confusing unti you fully grok it
<rwxr-xr-x>
my current game plan is to break shit till it works
<rwxr-xr-x>
there is 0 information about writing a kernel in assembly
<rwxr-xr-x>
because its a shit idea
<rwxr-xr-x>
there are a few things i've found that im gonna try now though
<geist>
wait. tyou're going to write a kernel in assembly?
<rwxr-xr-x>
That's what i've been doing lmao
<rwxr-xr-x>
who needs C y'know?
<geist>
well i mean lots of stuff starts off with kernel that then calls into C or something else
<rwxr-xr-x>
Oh no no no
<geist>
it's not at all obvious that you have been intending to do it 100% in asm
<rwxr-xr-x>
I mentioned it a couple times, and there is no c files in the repo, but maybe you haven't looked at the garbage fire that THAT is
<geist>
i have not
<rwxr-xr-x>
fair enough
<geist>
intentionally, because you keep saying it's a garbage fire
<geist>
so... that kinda disincentivizes me to spend any time with it
<rwxr-xr-x>
i ain't proud of it, if it works that's one thing, but it doesn't right now
<geist>
honestly i'd be able to help a bit more but i do not use nasm at all, and do not generally use intel syntax
<geist>
and none of the example code i have to poit you at is in the same syntax, so will probably just confuse you more
<rwxr-xr-x>
i have come across so many different syntaxs while google searching lol
<geist>
for x86? there are really functionally 2
<geist>
but a ton of assemblers, but in general there's gas and nasm style ones
<rwxr-xr-x>
I haven't specified it much unless i'm looking for specific stuff, i just look at whatever google throws at me when I don't specify x86
<geist>
but one of the fun things you've picked up as a result of wanting to do somehting 100% in asm is you have to deal with the fact that there is no one standard assembler, or standard syntax
<geist>
so. there ya go
<geist>
that is a bad idea. you want to make sure you dont get cross linked with random other arches
<rwxr-xr-x>
Good to know
<geist>
since there is no one assembly syntax, no one architecture and no one assembler. so you have to sort through that a bit
<geist>
also why it's a bit hard to find some sort of ready made tutorial or whatnot. ie, you picked a Hard Mode thing to be doing
<geist>
but that being said, it's been done many times so it's not exactly the first person to have gone this route
<geist>
anyway gotta go
<rwxr-xr-x>
Cya!
<rwxr-xr-x>
I tend to choose hobbies and projects that are way out of my league, probably not a good idea
<rwxr-xr-x>
fun as hell though
<kof123>
eh, i concur, but depends on hobby or work, whose dime it is on, how long you expect to live etc.
<rwxr-xr-x>
Oh, random ass question I just remembered, when reading about switching to 32-bit PM, far jumps where used to clear out the cpu so it wouldn't finish running 16-bit instructions while switching to 32-bit PM mode. All that being said, is there a way to do the equivalent without far jumps
<rwxr-xr-x>
completely impractical, but bugged me
furt_box has quit [Quit: Leaving]
smach has joined #osdev
<zid>
anything that reloads cs, reloads cs
<zid>
jumps are just aliases for adds/movs to eip, far jumps also mov to cs
poisone has quit [Read error: Connection reset by peer]
FreeFull has quit []
rwxr-xr-x has quit [Remote host closed the connection]
TkTech has joined #osdev
gog has quit [Ping timeout: 260 seconds]
pieguy128_ has quit [Ping timeout: 246 seconds]
<Clockface>
can you still get 16 bit x86 microcontrollers?
pieguy128 has joined #osdev
<Clockface>
i dont care about PC compatibility or any of that crap, just similar enough that i dont have to learn anything
<\Test_User>
"similar enough" isn't all that long ago, if you don't mind support for higher bit modes as well
<Clockface>
i dont mind
<Clockface>
i just probably dont need anything very powerful but i would like to be able to use x86 assembly
<Clockface>
since thats what im the most comfertable with
<Clockface>
actually
<\Test_User>
any computer that supports legacy bios mode, getting one with the a20 line disabled may be a bit harder, but probably not too hard to find one
<Clockface>
i meant more microntrollers
<\Test_User>
microcontrollers with bios support? or do they not get a bios
<Clockface>
i dont care about bios
<Clockface>
i just like the x86 instruction set and i want to know if any use it
<Clockface>
8051 derivatives are super similar too, but those are 8 bit
<Clockface>
i think intel quark exists
<Clockface>
and are beefy
heat_ has joined #osdev
<\Test_User>
I say bios bc that always starts you in 16-bit mode, I don't really know enough about the differences with a microcontroller and how your code is run in one of those, but as long as whatever it starts with is 16-bit mode and not like uefi that uses the highest should do
heat_ is now known as heat
<heat>
good morning vietn-osdev
<Clockface>
hey heat
<Clockface>
chill out man
<heat>
i have LITERALLY no chill
<\Test_User>
"heat" "chill"
<\Test_User>
you intend to kill heat or smth?
<Clockface>
Test_User: microntrollers usually dont have firmware
<Clockface>
they just start running whatever you flashed into them
<\Test_User>
ah
paulpaul1076 has joined #osdev
smach has quit [Ping timeout: 268 seconds]
node144 has joined #osdev
TkTech has quit [Ping timeout: 260 seconds]
TkTech has joined #osdev
smach has joined #osdev
node144 has quit [Quit: Client closed]
<zid>
day 4 is a lot of text for ultimately a simple operation wow
<jjuran>
Is there an osdev leaderboard?
<zid>
if you can beat my 2 hours 20 mins I will be surprised
<bslsk05>
github.com: aoc2022/day4.c at main · heatd/aoc2022 · GitHub
<heat>
my solution is even simpler
<zid>
yes, very simpler
alpha2023 has quit [Read error: Connection reset by peer]
<zid>
I don't see how the inside out case works in your code
<zid>
oh because you test vs the opposite edge
<zid>
I just added the inside out case to part 1, rather than rethinking it and doing it simple like yours, you win
alpha2023 has joined #osdev
<mrvn>
parsing the input is probably more work than solving it.
GeDaMo has joined #osdev
xenos1984 has quit [Ping timeout: 252 seconds]
xenos1984 has joined #osdev
xenos1984 has quit [Ping timeout: 256 seconds]
<heat>
mrvn, im rooting for you to solve the whole thing in bash
<heat>
although admittedly POSIX sh would be even funnier
<zid>
friend did it in powershell one year
xenos1984 has joined #osdev
<geist>
how's the advents going?
<zid>
day 4 was very very very very easy
<zid>
and I still didn't write simple code for it, whoops
<zid>
something something separatign axis theorem
vdamewood has quit [Read error: Connection reset by peer]
vdamewood has joined #osdev
<mrvn>
They should make some challenges that take forever if you aren't clever.
poisone has joined #osdev
<klange>
The difficult has historically built with each day. Some of the later problems in previous years would bite quite hard if you had a bad algorithm.
<zid>
yea but it's also supposed to be slightly uneven
<zid>
so that <center> turns it into a christmas tree
<zid>
day4's going to make a super fat bit :D
<mrvn>
the fatter the easier it is?
<zid>
although the dropoff seems high this year
<zid>
2020 was purely decreasing :o
<jjuran>
mrvn: They do.
gxt has quit [Ping timeout: 255 seconds]
node1 has joined #osdev
elastic_dog has joined #osdev
gildasio1 has quit [Remote host closed the connection]
gildasio1 has joined #osdev
gxt has joined #osdev
<mrvn>
heat: I didn't do day 3 in bash.
<heat>
cringe
<mrvn>
maybe I should.
<heat>
only 2 options are better: posix sh and csh
<heat>
or fish lol
<mrvn>
I didn't use any bash features so far
<mrvn>
For day 3 I see 2 "problems": converting lines into strings with 1 char per line and converting chars to priority scores.
elastic_dog has quit [Quit: elastic_dog]
<mrvn>
The rest is just sort, uniq -c and grep
<geist>
RRRRRUUUUUUST
elastic_dog has joined #osdev
<geist>
because obviously whateve ryou have done is unsafe
heat has quit [Read error: Connection reset by peer]
heat_ has joined #osdev
epony has quit [Quit: QUIT]
dra has quit [Quit: Leaving]
<geist>
ddevault: hmm. it should. what machine are you emulating?
<geist>
at least on -machine virt i'm almost positive it adds the initrd and cmdline to the device tree, just as you expect. we use that in zircon
node1 has quit [Ping timeout: 260 seconds]
<geist>
OTOH now that i remember it there was some silliness in the setup that caused it to maybe not do it if it was an elf or a not elf
<geist>
i think we used to carry a local patch for that on our qemu tree
nyah has quit [Remote host closed the connection]
<geist>
it's part of the general observation that -kernel is not handled exactly the same way on all arches on qemu. basically each arch/board reimplements it and mostly does the same thing, but subtle differences arise
heat_ has quit [Remote host closed the connection]
heat_ has joined #osdev
GeDaMo has quit [Quit: That's it, you people have stood in my way long enough! I'm going to clown college!]
sebonirc has quit [Remote host closed the connection]
sebonirc has joined #osdev
\Test_User has quit [Ping timeout: 246 seconds]
<mrvn>
geist: someone else repoted something like that a while ago.