| |
| |
| |
|
Page: 1 2 3
Comments:
<0> Colloquy is beautiful! :-)
<1> Thank you for one who told me the octal trick.
<2> You're welcome.
<1> It really makes sense now.
<2> Makes the fields really pop out, doesn't it?
<1> yeps.
<2> I haven't tried it on the 68k, but it should work there, too.
<1> also understood the idea in octal.
<1> one octal number fits to three bits.
<1> Making it quite nice occ***ionally.
<1> Rest stuff about displacement and immediate should get clear eventually, they are dependant from opcode R/M and SIB, I gues.
<3> whatever.
<4> howdy do
<5> Hey geisty
<6> hello giest
<6> geist
<4> yo
<6> do you think that a using a database for small files and small files and incomplete fragments while sill saving bigger files to the disk directly would work well
<6> like a hybrid fs
<6> question is directed at anyone who will offer input :)
<4> snowplow
<6> what
<4> free space needle
<4> burnhamd: anyway, yeah that kind of makes sense
<4> though at some level they fses and dbs tend to be the same thing
<6> but would a seperate db for small files work in practice you think
<4> where the small db is say a btree?
<6> i guess
<4> right. you've just invented reiserfs
<6> ha
<7> holl
<7> hello
<4> basically over the years cl***ic fses and cl***ic dbs have moved towards each other
<4> stuff like journalling and transactions came from db land
<6> yea
<7> i'm writing a program where things are written the screen with some colour formatting throughout (being displayed under multiple interfaces such as curses, gtk, and windows)
<6> i just wanted to know if anyone had sperated the big from the small like that
<7> do any of you know of ways to store the text along with its formatting?
<4> burnhamd: yeah, that's a relatively common trick. stick the small fragments of a file in the inode itself, large chunks off on the device
<6> didnt the first bfs attemot to try to put everything in a db
<4> and when you have a system like reiserfs or zfs or whatnot where the inodes are sitting in a btree, it basically looks like a db
<6> but then moved to metadata
<6> i gotcha
<4> yeah, something like that
<7> there are sort of 2 parts, sending the text with formatting to the frontend to be displayed and then storing it in the frontend and refreshing the actual screen with it
<4> trans: sounds like you need to invent something
<7> well what do other programs use to do that sort of thing
<4> iirc, there was something like this in the be api. it was a cl*** that could store text alongside arbitrary formatting (color, font, etc)
<6> im just going to try to read dominics book all the way through i guess maybe then ill get a ful grasp
<7> in ever program that displays text with colouring it has to store that information somehow
<6> did you keep up with the linux fs conference thing
<4> bfs is much closer to a regular cl***ic unix fs
<6> like ffs ore something
<4> it just has some extra bits (extra btrees for attributes that are interesting to index)
<7> the only method i've seen so far is putty using the text buffer method where for each char there is an attribute char as well
<4> trans: how about a string object + attributes for that substring
<7> ?
<4> and only when the attributes change do you start a new string + attributes
<7> so like an array of strings?
<4> or a list of strings, yeah
<7> with attributes for each string
<4> right. that optimizes for the probably common case where most characters are the same color + formatting
<7> hmm...
<7> any other ways of doing it (that i can keep in mind just to get a better idea of possible solutions)?
<4> not off the top of my head
<7> ok thanks
<4> reserving a byte per char is very simple and limited
<7> yeah
<6> what do you guys think about the exokernel design
<6> i beleive that microkernels are superior especially when all processors are multicore
<4> and this is based on what?
<6> based on eading about design
<6> from various sources
<6> reading*
<6> im am defininflty a noob when it comes to osdev so excuse me for the completely stupid comments when i make them
<8> hi there
<5> hey gianluca
<7> hehehe
<6> thanks geist for your help in understanding later
<6> later
<9> hi
<10> MOV\\Rd,Cd from sandpile.org, opcode 0Fh 20h
<10> Where do I find the information what those Rd, Cd, etc. mean in front of them?
<10> Oh, nvm.
<11> hi
<12> *burb*
<12> ooh, should become a song...
<13> yo folks
<13> guess not
<12> hello Windows lover
<10> hello Windows lover
<14> hello
<14> awesome, 71 nicknames
<9> mur: ?
<2> Mmm... Second-largest channel I'm in.
<14> r+ny hlo
<14> heh funny me too
<14> i'll go read newspaper then
<14> :
<14> :P
<10> mur: I think I kind of like this channel, it's almost as fun as #plan9.
<14> #planB :P
<2> Two better than #plan9 ?
<14> if Plan A fails :P
<14> hmm viagra spammers dont have reasonable expectancies on how much one shoudl eat viagra: 42 Jul 26 Nichols Chuck (1824) hi food
<15> if i have a stack as an array of numbers, is stack[0] the bottom or the top
<15> ?
<2> As ever, "it depends".
<13> yo kidz
<15> nyef, on what?
<12> mmiikkee12: on where you start counting
<2> On how the stack-array in question was designed, for starters.
<12> top bottom
<15> nyef, typedef uint_32 proc_stack_t[STACK_SIZE/4];
<2> Is it a top-down stack, or bottom-up?
<15> nyef, i don't know, that's my question. i put the address of it in esp and i'm using it with standard push/pop instructions
<2> What are you using as a stack pointer? Does it point to the current stack "top", or to one element past that?
<15> brb
<2> Ah, you have an ESP register. That narrows down the design space a bit...
<12> mmiikkee12: if you use standard push/pop, read the Intel documentation !
<12> especially the Instruction manual
<2> Heh. "Instruction manual". Never thought about that one before.
<12> "Instruction Set Reference"
<13> heh, the RTFM guy is back !
<15> Decrements the stack pointer and then stores the source operand on the top of the stack. - so stack[0] is the bottom?
<15> erm.. no, the top
<15> that didn't help much.
<12> if you dont understand even those simple things, how can we then help?
<12> do you want us to increase your intelligence by hand or something?
<15> ...
<15> telling me it decrements the stack pointer doesn't help at all.
<12> *screw*screw* now you're more intelligent than before
<12> if you dont know how stacking works, you wont be able to maintain stacks
<15> *duh* why do you think i asked?
<15> i just ask things i already know, just to test you guys ;)
<13> mmiikkee12, what are you really asking again?
<15> gr00ber, if i have an array of uint_32s, and i load the address of it into esp, is stack[0] the top or the bottom?
<2> If pushing a value onto the stack -decrements- the pointer, and the pointer points to the top, where's the bottom going to be in relation to the top?
<12> well, then I will answer your question directly:
<13> x86 is predecrement push, postincrement pop
<13> mmiikkee12, stack[0] is bottom
<12> gr00ber: that is what he already read out of the Intel manual
<15> ok, thanks
<12> &stack[STACK_SIZE] is the begin of your stack
<13> yup
<13> actually STACK_SIZE-1
<12> no, STACK_SIZE
<13> for push/pop semantics, yes, but the top is technically at -1
<12> void push(DWORD dw) { iStackIndex--; Stack[iStackIndex] = dw; }
<13> yes, that's a predecrement push
Return to
#osdev
or
Go to some related
logs:
bugmenot Sun Online Account
nvidia ubuntu wrong monitor
ballmer jokes
#suse
meanwhile patch for gaim2.0
#debian
#gentoo
scripting bat files with netcat
#web
ubuntu atiixp no sound
|
|