11-26-2014, 12:34 AM
(11-25-2014, 01:25 AM)TSO Wrote: @Magazorb
I have waited two days to answer this because it was quite upsetting and insulting. I therefore felt the need to calm myself before responding.
(11-22-2014, 06:17 PM)Magazorb Wrote:TSO Wrote:snip
Yorn, man your just a suborn fan-boy of the x86
You quoted a post where I was responding to LD's statement that Intel doesn't microcode often, in which I showed two prominent examples where they do (an the rest of the architectures in that manual also use it heavily), and then stated that I think that the use of microcoding in x86 is inefficient and stupid. Your response is that I love intel and x86? The only reason why I even know it instead of ARM or something more efficient is because I am using a computer with a Sandy Bridge architecture.
Magazorb Wrote:fact most IPs use 90% of the things x86 use and then add a ton of features more, most documentation for architectures use references to x86 that would be several hundred pages long for all the nitty gritty and then explain the difference, saving them many pages, goes back to the old programming saying "Don't repeat your self" stop following your father blindly, he says things about modern programmer and how they "have the speed to not have to program efficiently" THAT IS WRONG!, coders don't program, don't ever confuse a coder and a programer, a coder is a retard and a programmer is a engineer, the fact you concistantly blindly against us as if you're god is becoming annoying, you're statments majority of times are incorrect and you treat them like law.
I can see the value in what you are saying about me, but I don't see how this is relevant to the discussion at this time. I am not a god, I am incorrect very often, in fact; but in this discussion, I directly cited the Intel manual on this topic. Last time I checked, Intel generally is a solid source for information about Intel.
Magaxorb Wrote:Do your research please, x86 isn't a big architecture, hence why other architectures incorpate it, their are some architectures that are so big that adding x86 to it would be a pain, guess what ARM is one of those, they arent a architecture there a IP, a company with many architectures and some of them really are good and much more advanced then x86, Haswell is so heavily expanded on x86 to give nothing but serial computations (infact back in earily 2000's intel made a 7GHz processor prototype as a attempty to get even more serial computation out of their cores, they failed measable with requiring so much power and gained so little performance) that they just contiune adding as much as they can to get as many instructions about what's going to happen and start speculating, this wasn't defined in x86 orginaly, but i'll contiune saying that x86 is as what intell wants to call it (although they did a dirty move to call it theirs ages ago when it was some other guys and then got law suits made so that AMD couldn't use it but that resulted as having all the different names for what's still x86 but with extensions, yes intel had done some bad stuff but they seem mostly nice these days)
I know x86 isn't the biggest architecture, and I know it's not the most efficient. The prior direction of the discussion was me saying that it was unnecessarily large (and, by extension, so are most larger architectures). (Also, that's not exactly how that dirty move went down, but I'm not going to get into it right now.)
Magazorb Wrote:If you really insist for me to give you a nice example of what destroys x86? CBEA is one (this actual dominated the computational market in the 2000's, no x86 machine could keep up, even today the aging arch with no update still can outperform modern x86 in computation), PCP is another, Mill is also a 3rd.
I thought everything was a better alternative to x86, but if there are only three, I guess I must be wrong.
Magazorb Wrote:now to go back to microcode, did you know most code is focused on intels "x86" so they run signicantly better on intel hardware then AMD? no probably not, and code that's focused on AMD tends to run not so well on intels chips, this is a fact and people do still do this, just because your too ignorant to open your eyes to realise it's still being done (infact more now then ever before and this will only ever continue to expand with many alternative archs getting funding to become competitive, heck AMD has released statements saying they will support other archs as well as x86 and have proccessors that will just happen to run code of the other)
Funny thing, I actually did, which was why I was specifying Intel. The reason that AMD and Intel differ in efficiency is because AMD does not have licencing for Intel microcode (except on the i80386 and a few others), they only have an x86 licence.
On that topic, rather recently, Intel threatened to revoke said x86 licence after AMD acquired an ARM licence and stated they were going to make a dual compatible CPU. I get the feeling that they are going to make it dual compatible through microcoding and a recognition algorithm, otherwise one would have to specify in the program which architecture to use. I would assume that such a header would be unrecognized by other systems, meaning that they would fail to run the program properly. Even then, the processor must default to one of the two modes when initially loading the operating system or any other programs... it just sounds like a mess to me.
Magazorb Wrote:you're arguments come from where? where's your evidence, where's your references? like you just make points over and over that we can't find anything to support them, we do our research a lot, as of late lord more so then me, but we tend to have a idea what we're talking about and then you just seem to arguagainst what we say pointlessly, then you seem to think your right, then you seem to stray from what you orginaly said and pretend that's what you said in the begining when it agrees with what we was saying the whole time and then pretend you was right... but if we ever make open suggestions or point it out that's what we said at the start but you said no you don't respond.
I would check... oh I don't know... the link that was right there in the post, or if you didn't see that, check the manual's name which I showed right in the quote header. If I don't respond it's because you were right, meaning that the conversation need not go on. What's the problem in that? Often times we are saying the same thing and through either communication error or a difference in notation we come to a disagreement, which we then spend like four pages bickering about until one of us gives up. Once we both realize that we were saying the same thing, the conversation ends.
Magazorb Wrote:It's unlike me to question other peoples research as it's not often can i say I've researched what they have, but now i have to question, where on earth is your research coming from? my assumption is your dad as it's very x86 and that would have been the arch of the time, but you seem unacknowledged of any other archs... and you seem suborn that other archs aren't competitive, i can't comprehend where on earth this seems to be comming from...
Actually, my father doesn't know much about how the computer makes it happen, he just knows how to code for it. Even then, he has forgotten a lot. My research comes from a lot of places. In this discussion (about x86), though, it comes entirely from the x86 manuals. Again, though, my position in the discussion was that x86 was an inefficient pain in the ass with too much microcode and too many superfluous opcodes compared to other architectures.
Magazorb Wrote:I'm sorry if this seems like a forward attack but i really need to rant about this about you because it's bugging me and being as much as i like to learn new things question people seems to very good for learning
So please do share with us where your knowledge has came from.
Basically it all comes down to the Intel manuals (but only for this discussion), wikipedia, and an ancient book on Boolean logic and the algebra of sets (unless math has changed, I'm going to say this is still a valid source). Most of the other times, I'm coming up with a solution to problems myself without research, but we haven't really had a discussion around that because those are mostly conceptual ideas.
@LordDecapo
Yes, I was aware that the 8086 did not have as much microcode, but let's examine even something as simple as pushl %eax. It gets broken down into what is equivalently subl %esp, $0x4 followed by movl %eax, %(esp). Intel x86 processors will convert that PUSH command to those two micro operations, and I think AMD does as well, but that depends upon how they optimize the stack machine. I can view that x86 manual, open to a random opcode, and there is pseudocoding for that operation that describes what the microcode performs.
In fact, let's do just that. (Everything is from the Intel 64 and IA-32 Architectures Software Developer's Manual, my own comments are inside bracets)
Randomly checked Opcodes: AAA, FLDENV, BLSMSK, MINPD, MOVS, MOV, MUL, PUSH, SAR/SAL/SHR/SHL
It's actually difficult to find something that is microcode for itself, but I found two for you.
And there we have it. It seems like only the oldest and most basic of operations can actually get by without their own microcode. On top of the written micro-operations, the system also runs a check against the IOPL flags, CS, and the control registers, on nearly all of the operations for security reasons. Then, the microcoding is used to control the out of order execution algorithm as well as the in order retirement unit. Finally, I can't guarantee the actual binary values of operations and operands are preserved through the micro-op decoder.
Nice response good sir, better then had anticipated apologies to be a dick like that though.
though a few notes (in no order):
It's a open forum, anyone can read and respond upone anything.
I never said their was only 3, nor did i directly imply, it did say for example.
About the microcode, it's done due to architecture which other architectures using similar to intel's without intel's licences, this is due to the fact they can't just randomly patient things that everyone uses openly, the difference in microcode despite how few thire is now, is due to the difference in micro architecture, Intel goes for a heavily vectorized approach meanwhile AMD doesn't (AMD architecture is really interesting when you break it down it's remarkable how they get so much performance from such few units on such old dies, though it's a really hard achivment to vectorize MIMDs to the extent that intel managed)
my questioning of where you get things from wasn't 1 case. It's a you shoot us down for being wrong with evidence that doesn't prove we're wrong.
wasn't your argument that programmer are bad now days because of a lack of programming in microcode then those retards that just go derp derp derp, "maNz Iz ar pr0graMmar"? (i refer to coders with extremely poor programming skill, unfortunately this is about 70% of "programmers"
supporting code designed for another architecture really isn't that hard,as long as it isn't a after though their's many ways you can go about it, the ways you listed are some, but more excist.
If the differance was obvious enough you can even have HW figure it out, would imagen that you would know what the code is you're going to execute is though once you was running with a kernel (only speculation).
that concludes the notes.
I must apologies for offending you, however to be self critical can help, I'll fully admit at times i forget to look into all the details before declaring laws XD my point although i did word it very aggressively and perhaps in hindsight offensive is that you should be willing to accept incorrectness in your points and have a more open mind about how people respond to what you say
Anyhow have a nice time.