To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.roboticsOpen lugnet.robotics in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 Robotics / 25081
25080  |  25082
Subject: 
Re: mindstorms NXT and memory
Newsgroups: 
lugnet.robotics
Date: 
Tue, 10 Jan 2006 16:42:58 GMT
Viewed: 
9922 times
  
In lugnet.robotics, Alexander Sack wrote:
   In lugnet.robotics, Kevin L. Clague wrote:
   In lugnet.robotics, Alexander Sack wrote:
   In lugnet.robotics, Jordan Bradford wrote:
  
   I said that RISC machines (in general) are harder to program in machine code. The ARM is as easy as any other processor to program in high level languages.

Do you mean machine code (binary) or assembly language?

There the same.

Obviously you’ve not coded in machine language, or you’d know they are not.

If you are talking about the actual 1’s and 0’s that represent machine code then you are correct and I misinterpreted your last post, i.e. the binary. When people speak of binaries they are usually referring to something like an executable binary such as ELF or COFF. I saw “high-level language” and short circuited.

Yes, I have never coded at the machine code level and pray I never have too.

Now you’re talkin! I’ve never really done more than a half dozen instructions, unless it was a homework problem waaaaaaaay (and I really mean waaaaaaaay ;^) back in college.

  
  
  
   I first learned assembly language programming on a MIPS chip (RISC). I’ve also done it on a Motorola 68HC11 (a microcontroller), and I’ve written both pure machine code and assembly language for the Intel 8086. I much prefer the MIPS processor, followed by the 68HC11, and dead last is any Intel x86 chip. Bleah.

For machine code, pretty much any chip is “hard” to program.

I guess my last post didn’t make it.

Fundamentally, Steve is correct that RISC is typically more complex to program since it uses less general purpose registers and more complex instructions (it tries to do more per clock tic than CISC).

You misunderstand RISC and CISC. CISC instructions often combine data memory references with arithmetic, logical, or brach capabilities. RISC machines do not. RISC instructions try to do *less* per clock tick, thus the instructions take less logic, and can run *faster*.

Typically RISC instructions are simpler than CISC instructions. Often RISC architectures separate memory related instructions from arithemtic, logical, branch or other miscelaneous instructions. RISC machines typically have many more registers than a CISC machine. The SPARC machines that Sun makes (RISC) gives you 31 general purpose registers which can be used for address or data. Compare this with the 68000 CISC where you get 8 address and 8 data.

Yup I switched them. My bad, that’s correct. RISC needs to have more general purpose registers to make up for the lack of complex instruction types on CISC. Thanks for the review.

I guess this is what CISC proponents say. I don’t know that I agree. I think that no matter the architecture type *more* is better! Register access is orders of magnitudes faster than memory access, so less memory access are better.

Register access time halves every two years, yet DRAM access times halve every six years. Memory is painfully slow these days.... but now I’m *really* off topic!

  
   The reason that folks think RISC is more complex to program is that it typically takes a few RISC instructios to emulate a CISC instruction. I don’t find it more or less difficult, just different. I’ve done assembly on 8080, 8085, 8086, 80286, IMB 360, IBM370, IBM 390, 6502, 6800, 6811, 68000(all CISC), as well as SPARC, and soon to be ARM7 (RISC). I find the orthoginality of RISC instruction sets much nicer than the redundancy of CISC machines. Having worked on simulation of future CISC and RISC products from the gates up, I find RISC a much better machine design.

I think its all personal preference at this point. Like I said, the lines between RISC and CISC are much less than they use to be.

I think that the fact that X86 has effectively gone RISC indicates that RISC is winning the conceptual battle. You trade a little bit of programming effort spread across a lot of programmers, for the ability to toss out a lot of hardware complexity and the engineering cost that it takes to make sure the complexity is really working.

Sun’s most recent hardware announcement was for a four stage instruction pipeline that chip vs chip dramatically outperforms anything Intel (3X) has (with their 20+ stage pipeline). Now that we’re this far off topic, maybe we need to move this thread ;^)

It is fun to discuss, but doesn’t really have much to do with NXT so I’ll sit down and be quiet.

  
-aps

Kev



Message has 1 Reply:
  Re: mindstorms NXT and memory
 
(...) I totally agree! I stated this in another thread (or maybe this one) that assembly code on Intel is like Java Byte Code (but worse). I mean its not like you *really* know as a "high-level assembly programmer" exactly the order in which (...) (18 years ago, 10-Jan-06, to lugnet.robotics, FTX)

Message is in Reply To:
  Re: mindstorms NXT and memory
 
(...) If you are talking about the actual 1's and 0's that represent machine code then you are correct and I misinterpreted your last post, i.e. the binary. When people speak of binaries they are usually referring to something like an executable (...) (18 years ago, 10-Jan-06, to lugnet.robotics, FTX)

223 Messages in This Thread:
(Inline display suppressed due to large size. Click Dots below to view.)
Entire Thread on One Page:
Nested:  All | Brief | Compact | Dots
Linear:  All | Brief | Compact

This Message and its Replies on One Page:
Nested:  All | Brief | Compact | Dots
Linear:  All | Brief | Compact
    

Custom Search

©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR