OSDev.org

hello

please tell us about some e-book instead of books because I and some of us can't buy from amazon and ... because I don't have any credit card or if I have amazon doesn't send things to Iran.

please help.

I don't know much about Iran, but do you have bookstores there? Even if Amazon doesn't ship to your country, your local bookstore should be able to order the book for you.

btw, whenever we get pdf files that are worthy, we recommend them aswell. (practical FS implementation, Intel Manuals, etc.)

Speaking of Intel manuals, I don't know if anyone else noticed, but for anyone who had wanted to order the printed version of the intel manuals and was disappointed to find they were not in print, they're back. A few weeks ago Intel started accepting orders for them again at http://developer.intel.com/design/pentium4/manuals/index2.htm

Apparently the instruction set has become so large that volume 2 is now volume 2a and 2b. I just ordered a new set myself, last ones got ruined in a mini-flood my room had.

Has x86 become a CCCISC haha

srg

srg wrote: Has x86 become a CCCISC haha

srg

Would say so, now that you have three different sets with different expansion subsets of SIMD instructions. Plus x86, normal opcodes, system opcodes, redundant encodings, expanded opcodes, explicit codes that are defined to be illegal etc. Plus performance managing, debugging and all sorts of other registers, I'd really call it a CISC machine.

and according to info gcc > C extensions > Target Builtins X86 Built-in Function, it supports the MMX/SSE instructions right from C code ...

Still no 'lgdt' nor 'inb/outb' builtin, though ...

Candy wrote:

srg wrote: Has x86 become a CCCISC haha

srg

Would say so, now that you have three different sets with different expansion subsets of SIMD instructions. Plus x86, normal opcodes, system opcodes, redundant encodings, expanded opcodes, explicit codes that are defined to be illegal etc. Plus performance managing, debugging and all sorts of other registers, I'd really call it a CISC machine.

Not to mention three main and completly incompatible (from a system point of view) modes: Real, Protected and Long.

Would say though, at least the MMU and FPU are stable. I'm having a look at m68K and there can be some real fun and games there. The 68040/060 MMU seems to be changed a fair amount from the 030. Also the half implemented FPU. At least these changes are set in stone and have been arround for years.

I think all CPU archetectures have their pitfalls (don't know about Alpha, PPC etc).

srg

what i can tell you is that from a assembler point of view, RISC introduces horrors like "the instruction right after a JMP will be executed regardless of whether the jump is taken or not" ...

Pype.Clicker wrote: what i can tell you is that from a assembler point of view, RISC introduces horrors like "the instruction right after a JMP will be executed regardless of whether the jump is taken or not" ...

Or things like an example of loading a 32-bit value into a 32-bit register using sparc instructions, where you first use SETHI to load the top 10 bits, and then use ORI to actually add the lower 22 bits. Instruction size was specified to be exactly 32 bits and they couldn't fold now could they. Loading tophalf/lowerhalf separate would make it too usable

haha Well you do realise that RISC machines aren't designed to be programmed using hand written assembler. The very reason RISC are reduced is to make life easier for the compiler. CISC machines like x86 and m68k were designed to be assembler programmer friendly and not compiler friendly.

srg

srg wrote: The very reason RISC are reduced is to make life easier for the compiler.

Worrying about pipeline interlocks and branch delays is no easier for a compiler writer than for someone who hand-writes assembler. The reason these architectures are the way they are has a lot more to do with hardware design decisions (e.g. -- pipelining) than any consideration for software.

The main idea behind RISC and EPIC as implemented in the Itanium, was to move the complexity from the hardware to the software (specifically, the compiler suite).

This way, you can optimize the routines to exceedingly high speeds, make use of places that'd usually just be a wait state (the first instruction after a jump anybody?), use methodics unseen before and still be sure of high execution speeds. It also moves the complexities now seen in processors, having huge workarounds, to the compiler.

This all results in less silicon, less bugs in the silicon (direct result), and less heat at the same performance. Downside is a fscked assembly language and a complex compiler.

Seeing the future, it's with RISC chips that can just do what they should. Compilers don't burn up, and don't eat kilowatts of electricity a day.

The snag is getting people to recompile their commercial software over to the RISC chips.

I think Motorolla's first go at this was the 68040 FPU. All the complex stuff is emulated in libraries which call the basic floating point instructions.

I think the point is that would shouldn't be trying to program these in assembly as the compiler is the master.

BTW How come the modern RISC chips are getting just as hot as the x86 (the G5 ouch), their not that much faster if at all.

srg

srg wrote: I think Motorolla's first go at this was the 68040 FPU. All the complex stuff is emulated in libraries which call the basic floating point instructions.

I think the point is that would shouldn't be trying to program these in assembly as the compiler is the master.

BTW How come the modern RISC chips are getting just as hot as the x86 (the G5 ouch), their not that much faster if at all.

That's only because you use a cisc compiler on a risc processor, and that they had to do some tricks the cisc people invented (say SIMD?) that risc couldn't beat up against. Making it in a way CISC, and therefore slower again. Same with PPC and Altivec, G5 and his 64-bit stuff, all those.

There's no strict CISC or RISC anymore.

Plus, you have something like 128 registers on a risc? consider swapping them for a different task . That's a full K of memory to swap in/out.