The Place to Start for Operating System Developers
http://f.osdev.org/
Contradiction: they ARE algorithmic optimisations. Ergo they are AS GOOD AS.bzt wrote:@dozniak: what I meant constant folding and constant propagation and liveness analysis never will be as good as algorithmic optimalization.
https://en.wikipedia.org/wiki/Delay_slotbzt wrote:@Octocontrabass: could be! According to the wiki, DEC have used MIPS. I really don't remember, I can only recall my "wtf is happening here?!?" moment
This is either wrong or irrelevant depending on how you define 'smarter'.bzt wrote:I agree on all what you said, except this one. A human is always smarter than any compiler, .....
To expand upon this statement I think the reason we have so many different languages is the that we have so many different problem contexts.... a simple example being:Schol-R-LEA wrote: Well, that's the thing, you really can't - I mean, you can learn to read it to some degree, just from the similarities it has to other procedural languages if nothing else, but without practice at writing C code, you'll never really get a feel for the language. So in that sense, yes, you would need to write a significant amount of C code before you could read it well.
What does make you think this?DixiumOS wrote:Another way to say that C is good is that in Assembly you can't use numbers as large as... 1.7x10^308.
floats, doubles...Techel wrote:What does make you think this?DixiumOS wrote:Another way to say that C is good is that in Assembly you can't use numbers as large as... 1.7x10^308.
Have you checked any assembler documentation for those, or are you just guessing?DixiumOS wrote:floats, doubles...
And yet C translates into assembler. There's a paradox there somewhere.DixiumOS wrote:Another way to say that C is good is that in Assembly you can't use numbers as large as... 1.7x10^308.
This clearly says you don't know how C works. Did you know that part of compiling your C file is converting it to assembly language and then assembling it? Literally, yes literally, anything that can be done in C can be done in assembly language, because assembly is just the mnemonic representation of the CPU's bytecode.DixiumOS wrote:floats, doubles...
Code: Select all
fld num1 ; load num1 and push it onto the fpu stack
fld num2 ; load num2 and push it onto the fpu stack
faddp ; pop two numbers, add them, push sum on the stack
fstp res ; pop sum from the stack and store it in resJust because you don't know doesn't mean no one knows. BTW, using the FPU is deprecated and, by default, 64-bit applications utilize SSE.DixiumOS wrote:I meant that almost no one knows how to do floating point in Assembly.
Hint:Code: Select all
fld num1 ; load num1 and push it onto the fpu stack fld num2 ; load num2 and push it onto the fpu stack faddp ; pop two numbers, add them, push sum on the stack fstp res ; pop sum from the stack and store it in res
Code: Select all
; double precision (this is "double" type in C)
movapd xmm1, [num1]
movapd xmm2, [num2]
addpd xmm1, xmm2
; XMM1 contains resultWell, anyone who can cut and paste from stackoverflow "knows" how to do that. Whether they understand it or not is another matter.DixiumOS wrote:I meant that almost no one knows how to do floating point in Assembly.
Hint:Code: Select all
fld num1 ; load num1 and push it onto the fpu stack fld num2 ; load num2 and push it onto the fpu stack faddp ; pop two numbers, add them, push sum on the stack fstp res ; pop sum from the stack and store it in res
so many people think C is fast these days... Assembly is like a few bytes. Imagine a boot sector in C. It would reach 1KB instead of 512 bytes.