00:00:00 --- log: started forth/03.11.04 03:35:25 --- quit: warp0x00 (orwell.freenode.net irc.freenode.net) 03:41:41 --- join: warp0x00 (~warpzero@dsl.31.mt.onewest.net) joined #forth 04:58:47 --- quit: oooo (orwell.freenode.net irc.freenode.net) 04:58:47 --- quit: ianP (orwell.freenode.net irc.freenode.net) 04:58:47 --- quit: MysticOne (orwell.freenode.net irc.freenode.net) 04:59:31 --- join: oooo (o@virgo.bombsquad.org) joined #forth 04:59:31 --- join: ianP (ian@inpuj.net) joined #forth 04:59:31 --- join: MysticOne (mysticone@mysticone.usercloak.freenode) joined #forth 05:28:26 --- join: ASau (~ASau@158.250.48.196) joined #forth 05:28:44 Good evening! 05:28:54 Dobryj veczer! 05:29:36 moi 06:09:15 --- join: yasam (~sam@210-55-150-7.dialup.xtra.co.nz) joined #forth 06:13:35 hrm has anyone seen tcn lately ? 06:39:59 --- join: schihei (~schihei@pD9548ABF.dip.t-dialin.net) joined #forth 06:43:18 if I mentioned the logical operator 'inequivalence' would you immediately know what I meant? 06:44:21 != ? 06:44:25 i.e. is the name familiar? 06:44:38 you mean 'not equal' ? 06:45:23 i dunno what it is in forth lol 06:45:36 someone said to me that most people dont know the term inequivalence for XOR 06:46:08 true? (Im writing something) 06:47:22 The name is familiar. 06:47:36 But what class is it used upon? 06:47:48 haha fooled you 06:47:51 Boolean? Numeric? 06:47:56 Another? 06:49:24 nah not really :) 06:49:35 Boolean 06:49:50 but it is a generally known term you belive? 06:50:43 I had assumed so 06:53:01 It was used in soviet old school of impulse electronics. 06:53:28 It used to be usual. 06:53:50 Ca. 1975. 06:55:11 Also it was called "addition modulo 2" 06:55:37 ok, its just that if the term isnt immediately obvious then that may suggest 'XOR' isnt fully groked, if you know what I mean 06:56:12 yes addition modulo two is what we used in coding theory for some reason 06:57:03 if 'fully groked' a redundancy :) ? 06:58:14 ah well, Ill just add more material, thanks anyway 06:59:28 there is no XOR gate 06:59:54 ha? 07:00:26 :) 07:00:52 I took the spotted pill 07:00:54 "Impulse electronics" now is called "digital". 07:02:01 yasam: I've lost your idea, sorry. I've another prioritized task for now. 07:03:09 ok 07:06:02 on a different note: is ANSI forth considered harmful just because its a standard or because it sucks or both? 07:06:21 or none of the above? 07:07:05 I think, the reason is second one. 07:08:09 I think, the commitee had completely lost about portability. 07:38:55 * warp0x00 is away: metakarma - what goes around comes around comes around 08:02:35 --- part: yasam left #forth 08:52:49 yassam the ans forth standard does not describe the forth language but a language of the same name 08:52:51 -- chuck moore 08:53:10 ans forth is the CAMEL of forths 08:53:25 a camel being a horse designed by a commitee 10:43:34 --- quit: onetom (Remote closed the connection) 10:46:58 --- join: onetom (~tom@cab.bio.u-szeged.hu) joined #forth 12:26:52 --- quit: schihei (Client Quit) 12:35:45 --- join: schihei (~schihei@pD9E5CC0E.dip.t-dialin.net) joined #forth 12:53:16 --- join: fabian (~fabian@p508F1CD5.dip.t-dialin.net) joined #forth 12:53:42 Hello everybody. 12:54:37 Good evening! 13:01:23 Anybody here knowing something about retrolinux? 13:06:35 --- quit: warp0x00 (orwell.freenode.net irc.freenode.net) 13:06:35 --- join: warp0x00 (~warpzero@dsl.31.mt.onewest.net) joined #forth 13:06:35 Hello? 13:06:35 fabian: I don't know anything about retrolinux. 13:06:35 fabian: so you know, you often need quite a bit of patience in this channel 13:11:57 No problem ;-) 13:13:07 --- quit: warp0x00 (orwell.freenode.net irc.freenode.net) 13:14:48 --- join: warp0x00 (~warpzero@dsl.31.mt.onewest.net) joined #forth 13:19:07 --- quit: fabian ("leaving") 14:05:42 Good evening, Herkamire! 14:06:11 retrolinux is http://retro.tunes.org, I think. 14:06:52 It is someway connected to RetroForth project. IIRC. 14:07:30 greetings. 14:08:04 Dobryj veczer! 14:23:53 --- join: kc5tja (~kc5tja@66-91-231-74.san.rr.com) joined #forth 14:23:53 --- mode: ChanServ set +o kc5tja 14:48:46 dobry den 14:49:19 ASau: russian? 14:55:42 --- quit: schihei (Client Quit) 15:35:22 --- join: arke (~chris@ca-cmrilo-cuda1-c3b-66.vnnyca.adelphia.net) joined #forth 15:41:16 greeeeets 15:41:19 greets kc5tja 15:41:26 Greetings. 15:42:03 * kc5tja is just enjoying some thought-experiments with generating video. 15:42:11 :) 15:42:22 im reinstalling X 15:42:24 lol 15:42:30 lol 15:42:33 Dobryj noczer! 15:42:43 i uninstalled teh X rpm, now a bunch of stuff is missing 15:42:58 because i (in my insanity) installed teh src over teh rpm 15:43:01 privet ASau 15:43:09 kak dela? 15:43:20 oh the X source is fun ;) 15:43:28 Kak sazha bela! 15:43:39 english is good 15:43:46 --- nick: Herkamir1 -> Herkamire 15:44:02 Herkamir1: friggin 2 hour compile on Athlon XP 1200mhz with nice even 15:44:28 arke: not bad. I think it was 3 or 4 hours for me. 15:44:38 The last time I compiled X, it took two days. 15:44:41 mur: I'm reading various SML and (O)Caml docs... 15:44:54 It's not the compile time I mind. it's trying to get it to work right. 15:45:00 It was on a 450MHz K6-III. 15:45:19 Yes, two days to compile something, only to have it choke on the very last file is infuriating. 15:45:24 kc5tja: did you at least nice it? :) 15:45:30 kc5tja: haha 15:45:40 arke: No. I just let the computer sit for two days while it compiled. No need to nice it. 15:46:00 kc5tja: ack 15:46:08 what's "nice" as a verb? 15:46:13 kc5tja: you shoulda niced it ... might have only taken 1.5 days :) 15:46:19 Herkamire: lol 15:46:23 Herkamire: dunno 15:46:26 Herkamire: youneed to add "have" 15:46:30 Herkamire: i meant teh unix nice 15:46:32 kc5tja: sounds like about what my girlfriend's computer is 15:46:51 Herkamire: Sets the relative priority of a task. A high priority task will consume more CPU time, generally speaking. But in Unix(-clones), the concept of priority is "soft" -- it isn't absolute. Hence why "nice"-ing a task rarely ever does anything at all. 15:47:26 On a hard priority based system, like QNX or AmigaOS, priorities are vitally important, and can make huge improvements in throughput. 15:47:34 (depending on the task, of course) 15:47:34 ahhh. "nice" means it is supposed to be low priority in the multitasking 15:47:46 Right. The process is "nice" to the other processes in the system. 15:47:53 gotcha 15:47:57 But with a floating, dynamic priority system, it's virtually unnecessary. 15:48:30 I've never been terribly impressed with multitasking on linux or Mac OS X 15:48:45 linux is great most of the time, but that's only because I have two CPUs 15:49:03 when I do three intensive things at once my UI is slow 15:49:30 I want a system that automatically gives high priority to what you are looking at. 15:49:33 * arke punches XF86 in the balls 15:49:50 Herkamire: write a patch for teh kernel! 15:50:00 and can put enough priority on the music player so it never skips. 15:50:02 to nicen up 15:50:03 --- nick: arke -> {7{ 15:50:08 --- nick: {7{ -> {7} 15:50:10 *#$&^$*& the kernel 15:50:21 quite hard name to memorise 15:50:23 Herkamire: Linux's priority system grants higher priority to any process that is known to receive any kind of user input. 15:50:27 i woudlnt like to use such name 15:50:31 So what you're asking for is not the fault of its priority system. 15:50:41 kc5tja: cool 15:50:45 star hash dollar ampersand carret dollar asterisk et 15:50:49 <{7}> mur: testing teh freenode naming rules 15:50:50 grrrr 15:50:58 --- nick: {7} -> arke 15:51:09 RK, why test, it's said in the IRC RFC 1459 15:51:18 It is largely the fault of the fact that X Window System uses network sockets for virtually everything involving user input; therefore, it's really lame-ass network overhead you're dealing with. 15:51:20 rfc number might be wrong 15:51:28 mur: freenode doesnt comform to teh rfc, supposedly 15:51:44 how come? 15:52:04 * kc5tja isn't aware of a single IRC network today that conforms 100% to the RFCs. 15:52:05 dunno 15:52:15 kc5tja: ok, I could see that. 15:52:48 Herkamire: This is why MacOS X *flies* compared to X11. The display system is based on a scene graph, which minimizes interprocess communications when it comes to updating the screen. 15:53:17 sure would 15:53:22 no interprecess communication 15:53:26 But user input is still handled with normal message queues. 15:53:36 Well, there is IPC, but there's just a lot less of it. 15:53:45 just write to your own memory area for your window 15:54:00 Like, when moving a window, or resizing, etc., the scene graph renderer largely handles all the gory details of updating the screen, rather than the application. 15:54:45 yeah. I think that's pretty cool 15:54:49 I'm not sure I'm going to do it... but I think it's cool 15:54:54 And, as if that weren't enough, the scene graph renderer is in a single process; thus, there's no IPC when blitting video data to the screen. 15:55:00 * kc5tja is definitely going to do it. 15:55:02 :) 15:55:06 go 15:55:07 no 15:55:09 good night 15:55:16 night mur :) 15:55:25 night my finnish friend! 15:55:27 The Atari 7800 basically did the scene graph stuff in hardware. 15:55:36 dobrij noche, ASau 15:55:44 It implemented a "display list" in hardware, which was fetched under DMA control. 15:55:57 I just don't have very much video memory to spare 15:56:04 kc5tja: neat 15:56:13 Herkamire: You don't need video memory. In fact, you don't ever WANT to use video memory for this. 15:56:26 Writing to video memory is slow, slow, slow. 15:56:38 I have a 16MB card, and 6MB worth of pixels. I'd like to have a double buffer so thaht leaves me with 4MB for textures 15:56:43 Build the screen in regular RAM first, then just blast all X MB of it to the frame buffer in one fell swoop. 15:57:17 Herkamire: writing to video mem is slow because teh CPU has to divvy it up between itself and teh adapter ... that means it can only write/read between refreshes 15:57:30 * kc5tja nods 15:57:33 kc5tja: how long does it take to send 6MB to my graphics card? 15:57:46 Herkamire: rep stosd ... dunno :) 15:58:40 That depends on many factors. What video mode are you in? What's the video refresh rate? Are you using the blitter or the CPU? What bus speed is it? 32-bit? 64-bit? 64-bit-but-only-32-bits-being-used? 15:58:51 arke: Horrifyingly slow. Use explicit loop to transfer data. 15:58:59 why? 15:59:32 arke: Simple instructions execute faster, AND more instructions can be dispatched per clock cycle. REP STOSD is a single CPU instruction, thus it sucks up time in precisely ONE pipeline, for its entire duration. 15:59:47 ouch.... 15:59:53 tr00 15:59:59 Like I said, horrifyingly slow. :) 16:00:12 Good for when you're tight on memory, but otherwise...avoid it like the plague. 16:00:31 didnt think of that ... thats prolly why explicit loop is faster than teh loop instruction, right? 16:00:52 And, on x86 boxes at least, one can use the FPU registers to transfer data even faster than the CPU can transfer data with an explicit loop (80-bit registers versus 32-bit registers!). 16:00:54 kc5tja: well, its faster on 386- 16:00:59 kc5tja: iirc, they added pipelining with teh 486 16:01:05 arke: One of the reasons, yes. :) 16:01:17 kc5tja: nice... 16:01:31 kc5tja: i dont know how to use teh fpu. it seems waaay weird to me. 16:01:52 arke: Well, they've always had pipelining, but the pipeline stages were very coarse-grained (e.g., the bus interface unit would fetch the next instruction while the execution unit was running an instruction, and the MMU was processing page/segmentation data, etc). 16:02:00 arke: It's a stack processor. :D 16:02:29 (not a pure stack processor, but it is a stack processor) 16:03:05 tell me about it! teach me! :) 16:03:37 In the case of moving data around, you'd load the 8 FPU registers with data -- treat the video data as floating point numbers (the FPU won't generate an exception until you actually try to do math with them), then save them in another area of memory. The FPU never does any math on the data. 16:04:22 I have a flatpannel (apple studio display 17") I'm not sure how/if refresh rate enters into it. 16:04:36 Herkamire: It definitely does. LCDs must be refreshed just like CRTs. 16:04:41 Herkamire: modern monitors have higher refresh rates, i think 16:05:09 arke: Doesn't matter, when the pixel switch times are so slow, persistence of vision permits lower refresh rates, and reduced power levels, without adversely affecting video performance. 16:05:45 kc5tja: i know MMX uses teh FPU stuff. could you use MMX too? 16:05:57 Yes, you can. 16:06:08 Anything that loads those 80-bit registers with data can be used. 16:06:08 would it be faster? 16:06:32 I think it might be slightly faster on more modern processors, because they're optimized with all that multimedia buzz-word crap now-a-days. 16:06:39 But the FPU is no slouch at moving data around either. 16:07:13 X uses teh libc memmov 16:07:16 written in C 16:07:18 The PowerPCs can use AltiVec, which is similar to Intel's MMX in that it's SIMD instruction set. AltiVec registers are 128-bits wide, IIRC. 16:07:36 memmov() in glibc is usually optimized for the host processor on which libc was compiled for. 16:07:43 altivec is 128 bits. 16:07:47 im still waiting for intel to come up with 256-bit regs or such 16:07:50 memmov() is used so often, that it had better be. 16:08:16 arke: While working for Hifn, I dealt with a 1024-bit integer modular math coprocessor. 16:08:30 That was fun trying to write register dumps for that. :( 16:08:43 You simply HAD to use scientific notation for it. 16:08:43 :) 16:08:48 wow 16:08:53 1024.....WOW!! 16:08:55 Spokojnoj noczi, mur! 16:08:55 that's a lot of bits 16:09:03 There's not enough screen space to represent a single register value. 16:09:31 And the coprocessor was able to process data up to 3072 bits if you programmed it correctly. 16:09:32 talk about quick moving of stuff 16:09:54 (in case you couldn't figure it out already, it was used for encryption and decryption support hardware in network routers. :) ) 16:10:10 lol 16:10:14 that really needs it 16:10:24 When processing data at 2Gbps, you better believe it. 16:10:25 :) 16:10:39 PowerPCs and MIPS are both extremely fast processors, with highly respectible FPUs; but they're not THAT fast. :) 16:10:57 MIPS asm seems very weird 16:11:11 MIPS assembly is very, very, very, very, very, very simple. 16:11:17 kc5tja: teach :) 16:11:24 It's so simple, that your x86 knowledge is making it more complex than it really is. 16:11:24 kc5tja: you use floating point units for cryptography? 16:11:32 Herkamire: No, modular integer math. 16:11:37 thought so 16:11:45 kc5tja: teach :) 16:11:45 altivec is quite good for that I think 16:11:56 Herkamire: Only for small key sizes. 16:11:57 :) 16:12:09 arke: Each instruction has a fixed 32-bit size. 16:12:19 kc5tja: THATS the part that weirded me out alot 16:12:21 modular math I mean 16:12:30 There are usually (but not always) four fields: the opcode itself, two source register operands, and a destination register. 16:12:40 kc5tja: ooh, i get it 16:12:41 Herkamire: Again, not to 1024 bits of precision. :D 16:12:53 not exactly sure what you mean by modular. I was thinking dealing with numbers with more bit's than fit in the registers 16:12:59 1+3 = 0 16:13:35 arke: Well, it makes sense, and it greatly simplifies the instruction processing hardware. 16:13:49 Herkamire: Did you get that? :) 16:14:21 kc5tja: no 16:14:40 kc5tja: 2 bit registers? 16:15:06 Herkamire: In modulo-4 math, you have only for number tokens: 0, 1, 2, and 3. Thus, when adding, subtracting, etc. two arbitrary integers, the answer can only fit between 0 and 3, inclusive. 16:15:31 2bit 16:15:31 Herkamire: No. Restricting bits is one way of achieving a power-of-two modulo. But what if you wanted a modulo-5 or a modulo-25398 number? 16:15:56 I don't know how to do modulo-anything math 16:16:24 kc5tja: #define modulo base ??? 16:16:39 Herkamire: Encryption is powerful because the modulus of all arithmetic operations being performed is a prime number, which makes "undo"-ing the math virtually (in some cases, utterly) impossible. 16:16:51 arke: No, I can do modulo-5 math in base 10. 16:16:53 kc5tja: well, what about registers? how many, how called, special abilities, etc. 16:17:07 arke: Be specific -- what are you asking about? 16:17:26 kc5tja: what are teh mips regs, and how big are they, and what can they do? 16:18:29 arke: There are 31 general purpose registers (R0 is always zero in some models; it's an actual register in other models -- it's best to just assume it is zero). There is NO hardware stack pointer. 16:18:33 --- join: Sonarman (~matt@adsl-64-169-95-193.dsl.snfc21.pacbell.net) joined #forth 16:18:47 I don't know how to do modulo math for cryptography. I have a vague understanding that you use part of the key as the modulo 16:18:52 arke: You can largely treat them as you do registers in any other CPU; you can load/store them, do math on them, etc. 16:19:11 kc5tja: no stack? 16:19:12 Herkamire: Not always. It depends on your encryption algorithm. :) 16:19:17 arke: No hardware stack. 16:19:27 eck-ppht 16:19:41 kc5tja: yeah. I was reading about public key cryptography 16:19:44 arke: When invoking a subroutine, the previous PC is placed into a CPU register, which you are responsible for saving or restoring yourself if you need to. 16:19:58 arke: It makes perfect sense. 16:20:14 arke: Why waste time saving the PC on the stack, when you're only just going to return from the subroutine anyway? 16:20:20 tr00 16:20:22 hrm 16:20:52 I asume most time is spent in leaf functions (functions that don't call other ones) so there's no point in pushing/popping the return stack for these 16:20:57 arke: Remember, MIPS is a very minimal RISC architecture -- it is designed primarily to run C code, where stack frames are established not word-at-a-time, but whole frame-at-a-time, including return address storage if necessary. 16:21:08 Herkamire: Precisely. 16:21:29 And, the 3-operand register system is a big, big, big performance booster for asm coders and hardware implementers alike. 16:21:30 kc5tja: nice... 16:21:41 kc5tja: eep? 16:21:57 The basic RISC philosophy is that there are four basic phases to each instruction: instruction fetch, operand fetch, process data, and register write-back. 16:22:05 Note the key here: register write-back. 16:22:13 Not memory write-back. REGISTER write-back. ALWAYS. 16:22:19 :) 16:22:34 eep 16:22:36 Registers take effectively zero time to write out; memory takes at least four clock cycles (because of how slow RAM is). 16:22:51 This is why there are so many registers in a RISC. 16:23:08 I like RISC 16:23:13 how do you store to memory if theres only register writes? 16:23:15 you can do a lot of computing without touching memory 16:23:24 This is also why pipelining caught on big -- while one instruction is being fetched, another is having it's 2 operands fetched, another is having it's two operands processed, and the last is having its destination register written back to. 16:23:25 arke: fetch and store 16:23:37 well, intel is kinda braindead in having only 4 regs... 16:23:41 There are dedicated instructions for loading and storing data to memory. 16:23:54 arke: 8 to be specific, though one is a dedicated, hardware stack pointer. 16:24:15 well, 8 that you usually use 16:24:20 But also look at the complex and mind-boggling addressing modes it has too. 16:24:20 s/8/4/g 16:24:29 * kc5tja uses all 7. :) 16:24:31 that i could never understand... 16:24:33 ESI, EDI, and EBP are my friends. :D 16:24:46 kc5tja: ESI and EDI i usually keep for something 16:25:09 * kc5tja nods -- I use ESI, EDI, and EBP especially for pointers. 16:25:15 I like the abundance of registers on my PPC 16:25:30 * kc5tja nods -- MIPS and PowerPC are very similar architectures, from a software developer's perspective. 16:25:38 whats teh point of EBP? i know that gcc uses it for subs as a base argument pointer... 16:25:40 If you know MIPS, you know 80% of PowerPC, and vice-versa. 16:25:44 I haven't been doing asm for that long. But I've never run out 16:25:48 arke: That's the point. 16:25:54 aah. 16:25:59 a dedicated base register. 16:27:31 "Base" Pointer -- BP. :) 16:27:32 interesting. 16:27:32 Yes. 16:27:32 This is why the default segment for the EBP register is the stack segment, not the data segment (most people don't know that). 16:27:32 i do! :) 16:27:32 But since most OSes discard segmentation as quickly as they can, it usually isn't an issue. 16:27:32 its ugly. 16:27:32 very ugly 16:27:32 immensely ugly 16:27:32 I find segmentation to be a dream come true for m.e 16:27:32 me. 16:27:32 eep? 16:27:32 what's segmentation? 16:27:47 Herkamire: It's hard to explain fully here. 16:27:55 that's ok 16:27:57 Herkamire: a way of accessing memory in which you supply 2 registers, one of them points to an area, one to the specific place in the area 16:28:02 (very simple explanation :) ) 16:28:06 The simplest possible way for me to explain it is a segment is a logical address space. 16:28:43 The nice thing about segmentation in x86, though, is that you can only access those segments that exist in your global or local descriptor tables. 16:28:44 lwzx loads from the address at the sum of two registers 16:29:07 kc5tja: why do you find segmentnation to mbe a dream come true? 16:29:33 Herkamire: well, its not really like that 16:29:39 1. You can only access memory that you've been explicitly been granted access to, and without the need for supervisor/user mode distinction. 16:29:48 Herkamire: it left-shifts, the first register, then addds the two 16:29:55 2. Logical address spaces are ideal for object oriented operating environments. 16:30:12 3. It's a more logical method of imposing access restrictions on memory than paging. 16:30:15 sounds kinda like my vague understanding of virtual memory 16:30:28 arke: No, that's true ONLY in real-mode. 16:30:39 In protected mode, it doesn't do that at all. 16:30:41 kc5tja: yeah 16:31:04 in pmode, it looks in some table for the certain value of the left reg, then uses the area described in that table for that value 16:31:07 as a base 16:31:22 * arke hates the distinction between pmode and real mode 16:31:22 left reg == a dedicated segment register, always. 16:31:26 so it's a mapping of logical addresses (the ones you have in the registers) to real addresses according to a table and a register? 16:31:42 Herkamire: yep :) 16:31:45 Herkamire: Consider the following address mode: (r0+r1+offset) 16:31:52 That's basically segmentation, as far as you're concerned. 16:31:53 Herkamire: immensely complexicated, in my opinion 16:31:57 is that even a word? :) 16:32:02 As far as the hardware is concerned, it also checks that permissions are being met. 16:32:19 arke: Just "complex". 16:32:28 :) 16:32:48 But I don't find it to be overly complex at all. 16:33:00 well, its not hard to grasp 16:33:02 sounds pretty straight foreward 16:33:03 The segment table is read from only when it's first used. 16:33:04 or not that hard to use 16:33:13 but it can be made simpler 16:33:19 the segment register is offset or r0? 16:33:28 arke: Yeah -- ditch real-mode. there's no need for it anymore. 16:33:36 Herkamire: It can be thought of that, yes. 16:33:39 brb, dog 16:33:45 Note that there are several restrictions to using segments: 16:33:54 ack 16:34:01 ill stay another few minutes :) 16:34:02 1. The effective address in the segment must be less than the segment's limit -- otherwise, it's a privilege violation. 16:34:08 later 16:34:24 2. The segment must be accessible to your process; otherwise, it's a privilege violation. 16:34:42 3. A segment can be marked read-only or read/write for data segments. A write to a read-only segment is a privilege violation. 16:34:57 4. A code segment is only read-only. A write to a code segment is a privilege violation. 16:35:08 (you can get around 4 by mapping a data segment on top of the code segment, BTW) 16:36:15 cool 16:36:20 what's in the segmentation register? 16:36:33 A segment consists of a base pointer (which points into the virtual address space), a limit (which restricts how much of said memory you can access; limits are measured in bytes for 1MB or less, or pages for 4.2GB or less), an access rights byte, and a minimum privilege byte. 16:36:44 The x86 has 6 segment registers. 16:36:59 Each segment register has only 16 bits, 3 of which are used for privilege checking purposes. 16:37:15 Well, 2 of them are (4 privilege levels; 1 user, and 3 supervisor modes). 16:37:43 Bit 3 is used to indicate the local or global descriptor table. 16:37:53 So, each process can access 16,384 different segments. 16:38:07 so you can have 4 memory [logical <--> real] mappings at once? 16:38:25 Combine that with the fact that each segment can address up to 4.2GB of virtual memory, and you can see that the stock x86 can actually address quite a bit of virtual memory (64TB). 16:38:45 There is a code segment, stack segment, and four data segment registers. 16:39:01 brb 16:39:34 There is only one real virtual to physical memory mapping, but you can have several logical to virtual memory mappings, yes. Each segment register describes one possible mapping. 16:40:38 Unfortunately, x86-64 is disposing entirely of segmentation in 64-bit mode, and switching everything to the paging system. 16:40:47 Paging is nice, but segmentation is better for protection purposes. 16:40:52 I think, at least. 16:42:54 At any rate, I digress. With creative use of multiple threads, you can get many of the protection benefits of segmentation using heavy amounts of software parallelism. Linux is not a good model for such parallelism, but a light-weight, fixed-priority based OS is (like QNX; QNX just *rocks* on x86 platform!). 16:43:04 ok, so a segmentation register describes a mapping (logical to real) 16:43:16 and can you just load whatever value you want into the register? 16:43:34 Yes, it says that, "There exists an XYZ byte address range, that's located at ABC virtual memory address." 16:43:47 Then it's up to paging to actually map it to physical, concrete RAM addresses and do the virtual memory if needed. 16:44:16 No! That's the thing; the value you load into the segment register must have a valid mapping for it in your local (or global) descriptor table. 16:45:04 While the CPU won't choke if you load an arbitrary value into a segment register, the minute you try to access a memory location with that segment, it'll give a general protection fault (segmentation unit's way of saying, "Privilege violation"). 16:45:25 The upper 13 bits of the segment register is an index into a table. 16:45:36 And only the OS can access the contents of that table. 16:45:57 (The application can do it if and only if the OS grants the permission to do it; ironically, usually through a segment itself!) 16:46:41 sounds cool 16:46:48 It is. :) 16:47:16 Multic's segmentation inspired it, and although Intel's implementation isn't as powerful as Multic's, it is damn sweet. 16:47:20 so there's a table with all the segment mappings that there are 16:47:26 Yes 16:47:33 and you load the three segment registers with the segments you want to use 16:47:39 Yep. 16:47:42 nice 16:48:02 and if you want to use a fourth segment, then you change one of the segment registers to point to the table entry for that fourth segment 16:48:03 Switching segments has some overhead, as the CPU needs to reload information from the segment tables. But it's all transparent to the programmer. 16:48:23 I see 16:48:25 And once the data is loaded, it's never re-read from memory again. 16:48:53 You can kinda sorta get the same effect on the PowerPC too. 16:48:59 The PowerPC has segment registers too -- 16 of them. :) 16:49:18 They divide the program's address space into 256MB chunks (if you're in 32-bit mode). 16:49:31 So imagine a system with 16 256MB-max segments. 16:50:08 But, the segment registers also have their own privilege checking bits, and whatnot. Plus, they provide a mechanism to access 56-bits of virtual memory (80-bits for 64-bit PowerPC mode) 16:50:50 The critical difference is that what segment register to use comes from address bits 31..28, not from a specific segment register specification in the instruction. 16:51:13 This method is equally valid, as long as you're happy with 256MB maximum segments. :) 16:51:33 (of course, you can use multiple segment registers to logically coalesce two or more segments into one, as far as the software is concerned, but you get the idea). 16:52:25 As you might expect, only the OS can actually set the segment registers. Unlike the x86, though, you must invoke an OS service to change the segment mapping. 16:53:42 But with PowerPC's lightning quick subroutine call overhead, which extends to its system call overhead, it's not that much of an issue. In fact, I expect it is performance competitive with x86's hardware-based segment descriptor fetch operation. 16:54:23 (and, obviously, if you're running 64-bit software, address bits 63..60 are used to determine the segment.) 16:58:53 * Herkamire reads this twice 16:59:51 very interesting. 17:00:24 I didn't realize the top 4 bits of memory addresses determines the seg register 17:00:32 but it makes perfect sense 17:04:24 how do you get 56-bits of virtual memory? 17:04:29 I thought it was 32 17:05:48 for one ppc app to access more than 4GB of memory it would have to change the memory mapping 17:07:39 kc5tja: boo! 17:07:56 MysticOne: Heyas. :) 17:08:05 kc5tja: I drew you a picture! 17:08:09