Search logs:

channel logs for 2004 - 2010 are archived at http://tunes.org/~nef/logs/old/ ·· can't be searched

#osdev2 = #osdev @ Libera from 23may2021 to present

#osdev @ OPN/FreeNode from 3apr2001 to 23may2021

all other channels are on OPN/FreeNode from 2004 to present


http://bespin.org/~qz/search/?view=1&c=osdev2&y=23&m=1&d=28

Saturday, 28 January 2023

02:44:00 <heat> zid`, AMD K7 Athlon – microarchitecture of the AMD Athlon classic and Athlon XP microprocessors. Was a very advanced design for its day. First generation was built with a separate L2-cache chip on a board inserted into a slot (A) and introduced extended MMX. The second generation returned to the traditional socket form factor with fully integrated L2-cache running at full speed. The third generation, branded as XP, introduced full support for SSE.
02:48:00 <zid`> Thanks bro
02:48:00 <zid`> You've gotten a meme stuck to the bottom of your shoe and tracked it into the channel btw
06:02:00 <Jari--_> morning from Finland EU
06:02:00 * Jari--_ got some ideas on how to implement semantic A.I. and integrate it into the OS
06:03:00 <Jari--_> practical solutions, algorithms, etc. googled for months
07:53:00 <sham1> Machine learning to do things like scheduling
07:53:00 <sham1> "Adaptive scheduling"
07:55:00 <sham1> Anyway, the choice of algorithm really would depend on what you're trying to do with the AI
07:56:00 <sham1> Hell, you would most likely not even need "complicated" things like neural networks to do stuff, but again, it depends
08:00:00 <sham1> I suppose the biggest problem would be to a) gather the data set necessary and b) to train the damn model. You obviously would have to avoid overfitting, so something like k-fold cross-validation for training whatever model you'd be doing would be what you'd go for
08:14:00 <dinkelhacker> Can someone explain me what the 'table entry' is in aarch64 mmu long descriptor format? https://developer.arm.com/documentation/den0024/a/The-Memory-Management-Unit/Translation-tables-in-ARMv8-A/AArch64-descriptor-format
08:14:00 <bslsk05> ​developer.arm.com: Documentation – Arm Developer
08:16:00 <dinkelhacker> My understanding is that at L1 and L2 tables I either point to subsequent table with a table descriptor or I directly map the block of memory (block entry).
08:16:00 <dinkelhacker> But what's the table entry then?
09:59:00 <ddevault> this page is not a good source
09:59:00 <ddevault> you want
10:00:00 <ddevault> https://mirror.drewdevault.com/ARMARM.pdf
10:01:00 <ddevault> D8.3
10:01:00 <ddevault> dinkelhacker: ^
20:18:00 <x8dcc> hello, I am trying to implement the simple getchar function I mentioned yesterday, but I have a small issue
20:19:00 <x8dcc> I use an array to store the user's input chars, and it gets updated in the keyboard IRQ handler. This array is checked by the actual getchar function to check if its empty, and wait until it has a value
20:20:00 <x8dcc> the problem is that with -O2 the compiler optimizes this empty while loop, so it never exits. Is there any way I can specify the compiler to make that check volatile?
20:21:00 <x8dcc> afaik making the "static char[]" volatile *should* fix it, but I don't know if there is a better way since all the other array operations (for example in the kb handler) would not get optimized
20:22:00 <clever> x8dcc: without volatile, gcc assumes there are no other things (threads/irq) that could change a variable
20:22:00 <clever> and if a var is seen to have some value, it wont bother checking it again, until the local code has change it
20:22:00 <x8dcc> yeah, with -O0 it works fine (at least that part)
20:22:00 <clever> it can help to read the generated asm, and see what its really doing
20:23:00 <x8dcc> clever: so making that array volatile would be the only way to tell the compiler to check that? my loop is literally "while (getchar_arr[pos] == EOF);"
20:24:00 <clever> yeah, making the array volatile is one option
20:24:00 <x8dcc> I guess since it's a simple function I could write it in assembly, but it seems kinda sketchy
20:24:00 <clever> you could also have seperate read and write pointers, rather then relying on a magic value in the array
20:24:00 <clever> and then make only those pointers volatile
20:25:00 <x8dcc> oh, wait, I could declare a local pointer to that array in that function and make that volatile, that could work too, right?
20:25:00 <x8dcc> not sure if its what you meant but that could work
20:26:00 <clever> have a read_pos and a write_pos index into the array
20:26:00 <clever> the writer increments write_pos after writing data
20:26:00 <clever> the reader increments read_pos after reading
20:26:00 <clever> if readpos == writepos, then there is no data in the buffer
20:27:00 <clever> and make writepos volatile
20:27:00 <clever> plus some logic to wrap when you hit the end of the array
20:27:00 <x8dcc> I see what you mean
20:27:00 <x8dcc> yeah, I already check that
20:27:00 <geist> yah make the head/tail pointers volatile. you'l;l want to anyway
20:27:00 <geist> later on there are better ways of locking/synchronizing this, but for now spinning on some volatile regs will do t
20:28:00 <geist> the array should probably be volatile too
20:29:00 <x8dcc> okay, I fixed this part, something else is still broken but it's progress
20:29:00 <geist> yay
20:29:00 <x8dcc> thank you for the suggestions :)
20:29:00 <clever> printf all the vars on every iteration?
20:30:00 <x8dcc> hm?
20:30:00 <clever> to debug what is making it not work
20:33:00 <x8dcc> I'm going to use gdb since someone here told me how to use it without patching it lol
20:33:00 <clever> ah, that can help a lot
20:33:00 <x8dcc> https://temp.sh/xeoyG/ss-1674937912.png heh, close
20:34:00 <x8dcc> yeah, I love gdb
20:34:00 <clever> my main target lacks gdb support
20:34:00 <x8dcc> what do you mean? why?
20:34:00 <geist> oh no now you're gonna hear about it!
20:34:00 <clever> the cpu isnt supported by gdb, and the jtag interface isnt documented publicly
20:35:00 <x8dcc> haha
20:35:00 <clever> i would have to implement my own gdbserver stub from scratch
20:35:00 <x8dcc> oh I see
20:35:00 <x8dcc> a nice vacation project is all I see
20:35:00 <clever> and even then, there is the problem of what if the gdb server crashes?
20:35:00 <clever> simpler to just printf debug my way to answers
20:35:00 <x8dcc> meta-debug the debugger
20:39:00 <mrvn> x8dcc: volatile isn't enough when you have multiple cores.
20:40:00 <mrvn> You need the hardware approriate memory barriers around each access so you might as well use atomic and let the compiler handle that.
20:40:00 <geist> mrvn: we know this, we're just trying to keep it simple for now
20:41:00 <geist> this spinning on volatile thing is not the ultimate solution, but will work for now until proper blocking/etc is immplemented
20:41:00 <mrvn> except it has race conditions and will drop keys randomly and isn't really simpler than atomic.
20:42:00 <mrvn> you can spin on atomic too
20:43:00 <geist> feel free to help them implement atomics
20:43:00 <mrvn> thank good for builtins
20:43:00 <mrvn> -o
20:44:00 <geist> feel free to help them implement wrappers for the builtins, etc
20:44:00 <geist> x8dcc: i never asked, what architecture are you working with here?
20:45:00 <mrvn> also C or C++?
20:45:00 <mrvn> and what standard version
20:45:00 <mrvn> .oO(volatile being deprecated makes it rather more complex in newest standards)
20:45:00 <x8dcc> okay, I fixed it completely
20:46:00 <x8dcc> mrvn: for now I am only working with 1
20:46:00 <x8dcc> geist: I want to make it 32 bit
20:46:00 <geist> sure, but what architecture? x86?
20:47:00 <x8dcc> yes
20:47:00 <x8dcc> I am not sure if I will end up adding ring3 userspace or everything ring0
20:47:00 <geist> yah that comes quite a ways down the road
20:47:00 <x8dcc> I kinda like both ideas, I know ring3 is obviously better
20:48:00 <x8dcc> mrvn: C, I am not using any C++ code
20:48:00 <mrvn> urgs. you might want to rethink that. Unless you want an OS for some industrial PC boards 32bit just forces you to learn stuff you never need again and adds problems you rather wouldn't have.
20:49:00 <mrvn> I assume you don't actually have a 32bit only cpu?
20:49:00 <x8dcc> no I don't, but what do you mean? rethink using cpp?
20:49:00 <geist> i think they're talking about rethinking x86-32
20:49:00 <geist> since presumably you're using x86-64 now?
20:49:00 <demindiro> x64 is better in pretty much every way
20:50:00 <mrvn> x8dcc: rething going to 64bit long mode
20:50:00 <demindiro> Larger address space, more registers etc
20:50:00 <x8dcc> geist: my host machine is x86-64, yes
20:50:00 <demindiro> RIP relative addressing especially
20:50:00 <geist> mrvn: or you mean the opposite? *not* going to long mode?
20:50:00 <mrvn> no, I mean he should take the leap and go long mode.
20:51:00 <mrvn> The little time spend learning how to switch to long mode is well worth it. Easily saved later one because the arch is just better.
20:51:00 <geist> but they already are aren't they?
20:51:00 <x8dcc> well for now I want to keep making it 32 bit, and maybe I will switch in the future
20:51:00 <demindiro> I would do it now
20:51:00 <geist> oh! you're in 32bit x86
20:51:00 <geist> i see. yeah you'll want to switch fairly soon, trouble is of course all the page table stuff, which to a newbie is a big pile of nonsense
20:51:00 <demindiro> It's a tiny effort that'll save you headaches later
20:52:00 <x8dcc> hmm, I will think about it
20:52:00 <geist> but anyway, i'm happy you're making progress with IRQs and whatnot. what i'd personally do is flesh that out a bit, get handy with interrupts and generally speaking building up some infrastructure for kernel mode
20:52:00 <x8dcc> now that I have getchar, I can focus on the #1 most important priority. The pc speaker piano.
20:52:00 <geist> then basically start over with what you know, go directly to x86-64
20:52:00 <geist> oh or the pc speaker piano. sure if you have a specific goal x86-32 will do that just fine
20:53:00 <x8dcc> geist: yeah, is what I thought initially, start with this and once I know what I am doing, maybe try 64bit
20:53:00 <geist> and honestly you dont even need interrupts for that, can just poll the keyboard
20:53:00 <mrvn> x8dcc: with just single tones or mixing multiple key preses?
20:53:00 <mrvn> also: 1 bit sound quality sucks.
20:53:00 <mrvn> been there, done that. :)
20:54:00 <x8dcc> heresy
20:54:00 <x8dcc> it is perfect in every way
20:54:00 <x8dcc> anyway, I guess for now single tones, not sure how hard it is to mix them
20:55:00 <mrvn> ever done sound recording by polling the dataset port on the C64?
20:55:00 <x8dcc> the piano thing is just a dumb game, btw, it's obviously not my final goal haha
20:55:00 <geist> well it *is* a timer on the PC, so its not quite as bad as having to manually flip the speaker back and forth (ie, apple 2)
20:55:00 <mrvn> x8dcc: hard. you have to compute the wave form and then turn the speaker on/off to make the waveform. Single tone you just set a pitch and volume.
20:56:00 <geist> at least with PC you're basically furiously reprogramming a square wave generator
20:56:00 <x8dcc> mrvn: I don't know what the "dataset port on the C64" is
20:56:00 <x8dcc> mrvn: isn't that what doom used? I think I read something like that in the osdev wiki or somewhere else
20:57:00 <mrvn> x8dcc: it's where you connect the tape recorder to load/save data. It has a low and high pass filter on it so you can detect 2 tones.
20:57:00 <x8dcc> damn, that sounds extremely easy and friendly
20:57:00 <mrvn> So recroding from it all you get is 2 frequencies basically.
20:57:00 <mrvn> 1 bit quality too. it's beRAUSCHend.
20:59:00 <geist> heh i wouldn't call that extremely easy and friendly
20:59:00 <geist> more like, slightly more functional
21:00:00 <x8dcc> do you know if the templeos piano app supports multiple key presses? I am guessing it does
21:01:00 <x8dcc> that app (and templeos in general) would be my ideal perfect os, but you know, I am not him
21:02:00 <mrvn> x8dcc: blasphemer. Thou shall have no other OSes than TempelOS.
21:03:00 <x8dcc> amen
21:04:00 <x8dcc> you should search the "adulteress" video of templeos, truly beautiful
22:02:00 <sham1> TempleOS. Did Terry ever conclude that it indeed is the 3rd Temple™?
22:04:00 <kof123> i always took at as somewhat tongue in cheek, no idea
22:04:00 * kof123 points up like alchemist