buffbug has quit [Read error: Connection reset by peer]
<geist>
this is a real toughie debug why the system is exploding on this 68k board
<sonny>
what are you using for debug?
<geist>
a uart
<sonny>
oh ok
<geist>
it's the usual 'enable interrupts and the system explodes'
<geist>
it ends up branching through soemthing near zero. which is fine, except i'm not seeing any exception vectors firing *except* when it actually does fire
<geist>
so i'd think the exception handlers arent pointed to properly except it eventually *does* end up calling one (illegal instruction)
<geist>
like if i put a bunch of illegal instructions at 0, it immediately fires the proper undefined opcode vector. so i know that the exception table *is* pointed to properly (VBR register)
Coldberg has joined #osdev
Coldberg has quit [Remote host closed the connection]
freakazoid343 has joined #osdev
Coldberg has joined #osdev
freakazoid343 has quit [Quit: Leaving]
C-Man has quit [Ping timeout: 260 seconds]
lainon has joined #osdev
<kazinsal>
geist: this the 68010 board?
<geist>
yah
<kazinsal>
neat
<kazinsal>
been thinking of getting one to hack on. add it to the pile of all the other obsolete boxes I keep meaning to hack on :)
sonny has quit [Ping timeout: 250 seconds]
<geist>
hmm, this is a real pickle
<geist>
basically the instant i enable interrupts (set the IRQ level to 0) it branches to zero, where i've put a bunch of illegal instructions
<geist>
and then boom it calls into my vector table
<geist>
so thinking i had a bad vector table, i absolutely filled it (all 256 words) with at least a branch that's non zero
<geist>
looking up the stack there doesn't appear to be any iframes above it that look like anything
<geist>
okay it must be trying to fire an interrupt because the IRQ level in the SR is set to 4 when it does trigger the illegal
<geist>
what is at irq 4....
<kazinsal>
hmm
gog has quit [Ping timeout: 272 seconds]
<kazinsal>
uart perhaps? could have been buffering a "transmit buffer clear" interrupt
<geist>
yah i totally expect it to be the case, but it *should* have fired my exception handler
<geist>
so there must be something about exception vectors i dont understand on 68k
<geist>
also yay got a surprise hailstorm
<kazinsal>
yeah, we had one of those the other day. all of a sudden there was this funky noise outside and I saw the hail, then about 15 minutes later it was back to blue sky
<geist>
ah i see, there's a bus protocol where devices can provide irq numbers for stuff outside of irq level 1-7
<geist>
so the DUART is set up to deliver timer interrupts to vector 45. need to see how that relates to irq levels
<geist>
vector 0x45. i can of course just mask it at the DUART but need to grok why it's not just firing my unhandled vector handler
lainon has quit [Quit: lainon]
nyah has quit [Ping timeout: 248 seconds]
<geist>
ah i see. so in 68k there are 8 IRQ levels. the cpu will fire any irqs at > current level and thus setting irq level to 0 effectively enables all irqs (level 0 is unused), and 7 disables all
<geist>
external hardware can trigger an irq by setting IRQ0-IRQ2 lines to something nonzero and then the cpu goes into a special bus cycle where it can ask you for the vector
<geist>
so simple hardware can not ack that and then yuo get one of the 7 default autovector vectors or hardware can provide the irq and you get what you get with x86-pc
<geist>
but the cpu is then moved to that IRQ level
<geist>
it's a 3 bit field in the current SR register (like EFLAGS)
vdamewood has joined #osdev
<geist>
okay so based on this i can see now that it tried to fire an irq for vector 0x45 and then went off in the weeds
mahmutov has joined #osdev
<geist>
oh duh, no can count
<geist>
didn't fill out my vector table enough. cripes.
<kazinsal>
ha! put in 256 bytes instead of 256 dwords?
<geist>
basically yeah
<kazinsal>
classic
<geist>
and thus only got up to vector 64, whjcih is in 68k space precisely where the user vectors start (0-63 are reserved)
<geist>
the porevious port i did only used the autovectored irqs, whcih are in the reserved space
<geist>
so never noticed the table was too short
<geist>
the 68681 DUART is pretty neat, and clearly designed to work with 68ks since it understands the IRQ prototcol directly, etc
pretty_dumm_guy has quit [Quit: WeeChat 3.5]
<kazinsal>
oh interesting, I was going to ask if there was an interrupt controller on the board in one of the PLDs or something
<geist>
there seems to be some sort of interrupt proiority encoder that goes out to the external bus
<geist>
so some facility for that
sonny has joined #osdev
<geist>
ah now this is annoying: 68000 just dumps a simple frame on the stack, but everything above it (68010+) dumps a more complex frame but with a little field that says what frame type it is an what the vector # was
<geist>
so. nice thing is you can just route all exceptions to a single function on 010+ bcause yuo can just read the vector # off the stack that hardware pushed for you
<geist>
but for 68000, nope.
heat has quit [Read error: Connection reset by peer]
heat_ has joined #osdev
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
mahmutov has quit [Ping timeout: 246 seconds]
srjek has quit [Ping timeout: 260 seconds]
qubasa has quit [Remote host closed the connection]
heat_ is now known as heat
gildasio has quit [Ping timeout: 240 seconds]
heat has quit [Remote host closed the connection]
vdamewood has joined #osdev
sonny has quit [Quit: Client closed]
sonny has joined #osdev
kazinsal has quit []
kazinsal has joined #osdev
Likorn has joined #osdev
<geist>
got the port basically fully working now. pretty happy with it
<geist>
seems to work fine. of course its only 10Mhz, so it's not the fastest thing LK has run on. probably the slowest thing, actually
<geist>
and i am running the timer at 1khz
<kazinsal>
damn, nice work!
<geist>
'fibo' is a fun test. it starts 2 threads for every result and recursively does
<geist>
so it blasts through thousands of threads
<geist>
with this amount of memory can only get up to about 'fibo 11' before running out of ram
<geist>
fibonacci that is
enkeyz has joined #osdev
buffbug has quit [Ping timeout: 250 seconds]
sonny has left #osdev [#osdev]
Teukka has quit [Read error: Connection reset by peer]
Teukka has joined #osdev
the_lanetly_052_ has joined #osdev
pretty_dumm_guy has joined #osdev
<nur>
sortie, I love your retweet about location-based pay grades. I sobbed at "**But if you live in the "wrong" place, they won't pay you enough to thrive.**"
gog has joined #osdev
Likorn has joined #osdev
m5zs7k has quit [Ping timeout: 272 seconds]
Likorn has quit [Quit: WeeChat 3.4.1]
m5zs7k has joined #osdev
Burgundy has joined #osdev
xenos1984 has quit [Read error: No route to host]
gildasio has joined #osdev
xenos1984 has joined #osdev
corank_ has quit [Remote host closed the connection]
corank_ has joined #osdev
nyah has joined #osdev
Burgundy has quit [Ping timeout: 248 seconds]
Burgundy has joined #osdev
C-Man has joined #osdev
dennis95 has joined #osdev
vai has quit [Ping timeout: 246 seconds]
hodbogi has joined #osdev
GeDaMo has joined #osdev
gog has quit [Quit: byee]
gog has joined #osdev
heat has joined #osdev
diamondbond has joined #osdev
srjek has joined #osdev
Affliction has joined #osdev
diamondbond has quit [Client Quit]
dennis95 has quit [Quit: Leaving]
<klange>
arm64-on-arm64 tcg is so fast I keep accidentally using the wrong phony target in my makefile on my mac and only noticing when I wonder why a menu is feeling a little laggy
Likorn has joined #osdev
Likorn has quit [Quit: WeeChat 3.4.1]
Vercas1 has joined #osdev
Dreg has quit [Quit: Dreg]
Vercas has quit [Ping timeout: 240 seconds]
Vercas1 is now known as Vercas
childlikempress has joined #osdev
moon-child has quit [Quit: !]
gxt has quit [Remote host closed the connection]
Dreg has joined #osdev
gxt has joined #osdev
the_lanetly_052_ has quit [Remote host closed the connection]
the_lanetly_052_ has joined #osdev
heat has quit [Ping timeout: 246 seconds]
srjek has quit [Ping timeout: 240 seconds]
srjek has joined #osdev
archenoth has joined #osdev
eau has joined #osdev
khoa has joined #osdev
eau is now known as test
test is now known as eau
<gog>
mjá
<zid>
is it 18:30 yet
<ThinkT510>
yes
<zid>
liar :(
<ThinkT510>
you didn't specify where
<gog>
eastern europe
<GeDaMo>
What happens at 18:30?
<zid>
well I am not in baghdad or mogadishu
<zid>
series 3 airs silly
<zid>
well, ep 1
<ThinkT510>
of...
<GeDaMo>
You'll have to be more specific :P
<zid>
That you don't know is a dishonour upon yourselves
amine has joined #osdev
heat has joined #osdev
mxshift has joined #osdev
Ali_A has joined #osdev
<gorgonical>
zid is secretly a massive love is blind fan
<bslsk05>
docs.oracle.com: Relocation Sections - Linker and Libraries Guide
<gog>
the oracle docs are actually more complete
<Griwes>
there's documents similar to what I linked for other architectures
<zid>
"iRMX is a real-time operating system designed specifically for use with the Intel 8080 and 8086 family of processors."
<zid>
not exactly a bit of mainstream documentation you got there
<Ali_A>
I mean, that is what I got after researching the term `fixup`
<Griwes>
why are you searching the term "fixup"
<Griwes>
look at the specs for the appropriate version of elf and your arch's psabi
<zid>
Fix-up: For fixup in the context of executable formats on computers, see Relocation (computer science).
<zid>
"Relocation is the process of assigning load addresses for position-dependent code and data of a program and adjusting the code and data to reflect the assigned addresses."
<Ali_A>
I read it somewhere in some docs and didn't understand it, so I researched it and that what led me to that document
<Griwes>
(that's elf64 and x86_64 psabi for amd64)
<Ali_A>
Okay, thanks everyone!
* geist
yawns
<geist>
good morning everyone
* gog
passes geist a coffee
<geist>
yay
Gooberpatrol66 has joined #osdev
<papaya>
coffee is life
dude12312414 has joined #osdev
dude12312414 has quit [Remote host closed the connection]
mahmutov has joined #osdev
<pounce>
gm
<pounce>
have recently been interacting with somebody at work who worked on kernels at apple/freebsd/etc
<pounce>
maybe that means i can get payed for it too :p
<enkeyz>
pounce: good luck!
<pounce>
lol, doubt it though
<enkeyz>
pounce: do you have commits to linux kernel?
<pounce>
nope, only my own
<pounce>
err, i guess some other teaching ones too
<pounce>
one of my professors called linux the least fun OS to work on
<pounce>
which was not inspiring :p
<geist>
i'm not gonna disagree with that
<pounce>
plus im at $big_tech so i can't without causing legal issues
<pounce>
without permission that is
<enkeyz>
wut
<pounce>
there are rules about when you can/can't contribute to open source :<
<j`ey>
worth asking about though, ive done it a few times
<enkeyz>
pounce: I wouldn't sign something like that, that's for sure
<gog>
i was watching cathode ray dude the other day and he said "now i hate linux in a lot of ways. i've been using linux since i was about 10 and i find it to be a detestable experience"
<gog>
i related so much
<enkeyz>
bye
<j`ey>
enkeyz: all the big companies do it :<
<mjg>
red hat used to not do it
<pounce>
yeah it sucks big tech is a disease
<pounce>
mjg: doubt that's the same now
<mjg>
the ibm merger, i know
<mjg>
maybe they walk in ties now
<enkeyz>
mine is the exact opposite, it's even encouraged to contrib to open-source
<geist>
yah it very much depends. mine is generally okay with it too
<enkeyz>
it's a good advertisement for the comp
<enkeyz>
you can even do it under work hours - if you don't have any backlog ofc
<pounce>
ah, that's nice
<mjg>
solid
<mjg>
all companies i worked for were hacking on opensource projects internally
<mjg>
and several never bothered to upstream squat, even bugfixes
<mjg>
one funny bit which came out of it is that there was a bug in apache which got fixed at my first workplace
<mjg>
when i went to another one i had to fix literally the same bug in that apache
<mjg>
;)
<mjg>
neither patch got upstreamed, i have no idea if the bug still exists (it was 15 years gao)
<enkeyz>
mjg: that sound like against the apache license
<mjg>
oh?
<geist>
not so sure, i dont think apache has any real obligation to roll back to mainline
<geist>
iirc it's basically MIT + patent blabs
<enkeyz>
i remember something
<enkeyz>
similar
gog has quit [Read error: Connection reset by peer]
<bauen1>
i finnd it a bit weird that people don't at least try to get their own changes upstreamed, yes it easily increases the time required by 1-10 times, but then it's "not your problem anymore" (not quite, but you get the idea, no more rebasing your own changes everytime upstream does something)
gog has joined #osdev
<geist>
usually it's just the annoyance of doing it
<geist>
and the 100 other things you're probably supposed to also be doing
Likorn has joined #osdev
Ali_A has quit [Quit: Connection closed]
<heat>
j`ey, all open-source projects or just big ones?
childlikempress is now known as moon-child
<j`ey>
heat: for my job, it doesnt matter how big the project is, still have to get some kinda approval
<heat>
:/
<heat>
here at $LC_CORP they let me work on whatever I want as long as it doesn't compete with the company
<j`ey>
it's usually pretty easy to get approvals now, they streamlined it a lot
<energizer>
why do we have the concept of 'the stack and the heap' instead of just having a bunch of different memory allocator options?
<heat>
energizer, you don't
<energizer>
?
<heat>
they're all built on mmap
<heat>
there's no "stack or heap"
<j`ey>
heat: same here.. it's just good to have some thing in writing
<heat>
the stack is only special in the sense that it grows
<Griwes>
programming languages can have a concept of "automatic storage", but that's still... just mmap
<sham1>
But that's an implementation detail
<mjg>
does not have to be anything
<heat>
it's mmap all the way down
<sham1>
Now now, could also be sbrk
* sham1
runs
<mjg>
for one, may be optimized out latogether, or only be used in regs
<heat>
sbrk is a myth
<heat>
brk is the shit
<Griwes>
sbrk? you mean super broken?
<sham1>
Yes
<heat>
sbrk isn't broken what
<Griwes>
i mean it's not mmap
<heat>
brk is still mmap, but with extra steps
<Griwes>
it hides the useful parts of mmap
<heat>
i don't agree
<heat>
for one, it allocates memory, it's also slightly faster than mmap I believe (due to it growing the existing region for instance), and guarantees the whole heap is contiguous
<heat>
that last point is super nice for the malloc implementation
<heat>
it's just way less flexible than mmap
GeDaMo has quit [Remote host closed the connection]
<Griwes>
Fair. *makes a note to make his mapping objects and vmos resizeable in the future*
<heat>
linux also has mremap which resizes/moves the region as well
<geist>
also there's a subtle thing where sbrk can actually allocate discontiguous regions
<geist>
i didn't realize it until some point in the past where i was fiddling with dlmalloc and it understands this from sbrk
<heat>
hm?
<geist>
there was some subtle detail, iirc, where if you ask for N bytes and sbrk returns something that isn't 'last allocation + N' you can assume it's actually giving you a new discontiguous block of N bytes
<heat>
i don't think this is a thing in most sbrk implementations
<heat>
at least not in Linux
<geist>
maybe in the BSDs?
<heat>
possibly, if they even still have it
<heat>
i know there used to be a bug in linux's sbrk where you could accidentally overwrite your stack with the brk'd memory
<heat>
but that's very old I think
<geist>
i dunno, the man page for sbrk says it returns the pointer to the new block. so it could return a discontig block
<geist>
basically it could try to mremap but if fails start a new one
<heat>
sbrk is not even a system call
<heat>
brk is
<geist>
sure, but that's an implementation detail
<geist>
brk doesn't have to be either
<geist>
seems like both of them could be totally implemented in process on top of a mmap based system
<heat>
" However, the actual Linux system call returns the new program break on success. On failure, the system call returns the current break. The glibc wrapper function does some work (i.e., checks whether the new break is less than addr) to provide the 0 and -1 return values described above."
<geist>
i guess my point is sbrk() is more powerful than it looks. not saying it's great or whatnot, but it has more flexibility
<heat>
oh you could totally implement it on top of mmap, though it would be awkward
<geist>
you musth ave a different man page than i do
<heat>
the big advantage seems to be that you have a bunch of empty address space you can expand into
<geist>
oh duh, i'm looking at the macos one
<heat>
heh :D
<geist>
"On success, sbrk() returns the previous program break. (If the break was increased, then this value is pointer to the start of the newly allocated memory). On error, (void *) -1 is returned, and errno is set to ENOMEM."
<geist>
that's the behavior i was looking for
<geist>
basically if it wasn't the last return + N then it's a new block
<heat>
dlmalloc says the memory is always contiguous for the unix sbrk
<bslsk05>
github.com: dlmalloc/malloc.c at master · ennorehling/dlmalloc · GitHub
* geist
nods
<heat>
"The value of incr may be adjusted by the system before setting the new break value." <-- something cool I found in solaris's sbrk(2)
<geist>
yah, ad that's kinda the problem with the api right? it returns the old break point, so if it fiddled with incr, i guess you're obligated to immediately follow up a successful one with sbrk(0) to see where it actually bumped it to
<geist>
well, okay i guess that's fine, threading issues aside
<heat>
this seems to be solaris-only
<heat>
at least SUSv2 doesn't mention that
<geist>
the linux man page says it may round incr up to a page boundary
<geist>
and the mac one, but i guess that's fine too
<heat>
i guess that means for the purpose of keeping track of the pages allocated to sbrk?
<geist>
yah
<geist>
but then if that's defined, it's not really an arbitrary increment
<heat>
sbrk is hard
<heat>
:(
<heat>
the best part of old unix is the confusion
<kingoffrance>
"why do we have the concept of 'the stack and the heap' instead of just having a bunch of different memory allocator options?" eh? that pretty much covers 2 common cases: contiguous, not-guaranteed contiguous
<kingoffrance>
what other schemes are there?
Raito_Bezarius has quit [Ping timeout: 260 seconds]
<kingoffrance>
or what scheme does not fall into one of those?
mctpyt has joined #osdev
<geist>
and of course brk/sbrk is totally legacy, but it makes sense given the design of say a PDP-11 and how processes were laid out. you literally would have two segments you grew in different directions, on i think 16 byte boundaries
<geist>
(though pdp-11 was actually more like 8 fixed segments, where each of them had a base + length + direction bit
<geist>
)
<moon-child>
what were the other segments?
<geist>
VAX even had that, since user space (2GB) was two 2 1GB page tables, the second of which grew downwards
<geist>
moon-child: well, iirc pdp-11 was a bit more flexible. it had a 64k address space (16 bit machine) but it was divided into 8 8k segments
xenos1984 has quit [Read error: Connection reset by peer]
<geist>
each of which has a base + length + direction bit (i think the directio bit is correct)
<geist>
the base & length was i think in units of 8 or 16 bytes. but fairly high granularity
<geist>
so really you had some ability to do mmap() style stuff in 8 or less slots, but the way unix used it was the classic program + data + heap at bottom, stack at the top growing down thing
<geist>
on context switch you just swapped those 8 control registers
wolfshappen has quit [Quit: later]
<geist>
meant the 'pmm' wasn't in pages of course, you're chopping up all of physical address space at 16 byte contiguous runs
wolfshappen has joined #osdev
<geist>
but you can also do compaction and whatnot if you need to for non-resident processes
<kingoffrance>
so stack and heap, and anything else variants of that :)
<geist>
text/data/heap yeah
<geist>
so a process pribably had 2 logical segments in the kernel, spread across the 8 hardawre segments
Raito_Bezarius has joined #osdev
<geist>
of course you could see how fork() would work naievely. you'd just copy those into a new chunk of physical and allocate to the new process
pretty_dumm_guy has quit [Ping timeout: 256 seconds]
<geist>
but iirc there was some ability to mark a segment as RO and then take some sort of exception and do some sort of lazy vfork style thing
<heat>
didn't they just swap to disk back then?
<geist>
and i guess more advanced stuff would allocate the physical space in units up to 8k, since say a 20K contiguous run in a process would be 8 + 8 + 4
<geist>
basically it's like an 8 page page table with partial pages
<geist>
and physical alignment was looser
<geist>
oh sure. but if you had the ram you wouldn't swap before you needed to
<geist>
anyway it's definitely more flexible and efficient than some sort of fixed bank of 64k that you could select at any time. lots of early systems would do that. kernel just set a control register that would set the upper N bits on the physical address space
<geist>
then you have say 1MB physical chopped into 16 64k slots
<geist>
cpus like 65c816 had that built in
<geist>
vs the weird overlapping 8086 scheme where you only got 20 bits out of it
<geist>
i still dont completely understand what intel was smoking when they came up with that
<kazinsal>
I suspect they looked at the 16-byte boundary thing for segment limits on the PDP-11 and went "hey bob *takes enormous bong rip* how many transistors will it take to implement (seg << 4 + off)"
<geist>
well, i suspect 8086 they thought would be a feature. i thik they were drinking OO programming is future koolaid and thought that the segment + ptr thing is a real feature
<geist>
vs the more strict strategy of having to switch between fixed 64k pages
<geist>
so i guess their idea was that an 8086 program really had full access to everything directly, just through these little 64k straws, but you could have them active simultaneously in the form of the multiple segment registers
<kazinsal>
yeah, I don't think anyone ever really intended it to be a multiprogramming machine
<geist>
whereas pdp-11 style stuff was clearly designed for multiprocessing, yeah
<geist>
and something like 65c816 could address 24 bits with the same amount of segmentation (8 + 16) but then there was no overlap, so you had to bank switch a lot
<geist>
though it had an addressing mode for some instructions that provided a full 24bit long address
<geist>
and iirc had a way to do a long branch to 24bit address, which swapped segment register
pretty_dumm_guy has joined #osdev
<kazinsal>
yeah looks like it has absolute long, absolute indexed long, and absolute indirect long addressing modes
<kazinsal>
and long versions of jmp/jsr/rts
xenos1984 has joined #osdev
<geist>
68k is refreshing in that regard since it has zero notion of any sort of segmentation. it was flat memory from the get go
<geist>
either you have an external (and later internal) paging unit or nothing at all
<geist>
though i think user/supervisor is out on the bus in the form of the FC0-2 control lines, so you could fairly easily statically carve up physical space into kernel and non kernel memory
<geist>
well, probalby 010, which has better support for that (it's main difference from 000)