>>7
So which side is ARM again? Having two separate instruction sets isn't very RISCy, is it?
Name:
Anonymous2008-08-20 9:43
This debate is irrelevant in this age. The CPU manufacturers implement CISC functionality by combining RISC functionality. The only real reason to change to purely RISC machines would be to help the compiler authors by not having to target so many different opcodes.
>>8
I would argue that ARM (with or without THUMB interworking) is still a RISC instruction set, though obviously not as simple as MIPS (which is stupidly simple and inefficient, space-wise). It's probably pretty debatable though.
>>13
You're implying that using a RISC architecture would increase power efficiency. >>11's question was purely rhetorical, suggesting that architecture choice is relevant.
>>16
Intel processors have been using RISC-based microcodes for the past decade, what's your point? My current boss (shortly before announcing he hasn't touched a line of code in 5 years), during my interview showed me a plaque he was awarded for working on Intel's microcode implementation.
My current boss
Did he really? Or is this just your way of saying "I will, along with my job"?
Name:
Anonymous2008-08-20 11:50
>>17
My point is that x86 is not suited for mobile and embedded platforms. It's kept around as a favour to Microsoft which can't be bothered to make their code cross-platform since NT (CE and Mobile don't count).
Name:
Anonymous2008-08-20 12:07
>>19
Actually, if one of them is doing the other a favor, it's Microsoft. If Microsoft went cross-platform, Intel yould be royally fucked.
Name:
Anonymous2008-08-20 12:33
A Linux-based ARM laptop will come out and sweep the floor with current low-end laptops in terms of price, battery life, out-of-the-box functionality and user-friendliness. It will bridge the software gap to the other ARM-based mobile devices that are so ubiquitous nowadays, and the resulting software development trend will create a bottom-up wave that will extend far into the common desktop market. It all culminates with Microsoft halting development of Windows 7, and Vista thus marking the end of an era.
Then we'll talk about RISC vs. CISC, bitch. As a history note in computer science textbooks, that is.
Name:
Anonymous2008-08-20 12:53
>>8
RISC isn't about having few instructions, it's really about having a load-store architecture.
>>21
Not only will this never happen, if it did happen the laptops would be running some pigdisgusting version of Ubanto and continue corrupting the minds of the masses with their stupid bullshit.
>>22
Hurr. That's not what they taught in my undergrad Computer Architecture courses, but given the state of ``higher'' education, I'm very inclined to believe the internet over anything some ``tried to work in the industry but wasn't good enough and now scrapes by doing minimal ``research'''' taught me in uni.
The terms RISC and CISC don't mean as much as they used to. RISC architectures became more CISC-like when their designers realized the performance penalties of forcing developers to implement missing functionality in software.
A good example of this in MIPS would be the ei/di (atomically enable/disable interrupts) instructions added to MIPS32 rev.2. According to RISC dogma, such instructions would be considered frivolous.
More generally, the simplest possible interface is rarely optimal.
Name:
Anonymous2008-08-20 13:37
>>24
MIPS was a minimal design but eg. IBM's designs have not followed that philosophy, instead using specialized instructions where it makes sense (and as >>25 noted, the MIPS instruction count has been steadily increasing.)
Of course, compared to a VAX any instruction set is "reduced".
A good example of this in MIPS would be the ei/di (atomically enable/disable interrupts) instructions added to MIPS32 rev.2. According to RISC dogma, such instructions would be considered frivolous.
lol what? Then how would you atomically enable/disable interrupts without them?
>>28 >>29
I think a trap exception could work, since it disables interrupts, and the general exception vector is used rarely enough that adding a special case for this purpose there wouldn't be too expensive.
>>30
The syscall vector is probably too performance critical to be used for that purpose.
>>31
The same vector is used for syscall and trap. You have to look at the cause register to figure out what happened. There is also no trap in MIPS-I.
Name:
Anonymous2008-08-20 16:04
>>37
In fact, taking a closer look there is no plain trap instruction, they are all conditional. I'm starting to think that >>29's trap is some retard-o-tron alias for syscall.
Name:
Anonymous2008-08-20 16:16
Coming from an x86 background (and having memorized much of the instruction set), MIPS looks so... boring.
Name:
Anonymous2008-08-20 16:18
I feel bad, because this is the first thread I don't understand at all :(