Assembly Language FRC Robots????
 

How likely will this language become easily usable/debuggable to program FRC robots in the future?::rtm::

Re: Assembly Language FRC Robots????
 

I doubt it ever will.

But the real question is why you would want to use a lower level language like assembly over a high level language like C++ or Java?

Re: Assembly Language FRC Robots????
 

There are certain programming techniques that I like to do in a Low Level environment that I feel like the Higher Level stuff would not done better, even in the cRIO's processor's environment.

I do like the High Level languages too, but does anyone think there could be some sort of preview/tutorial of Low Level programming other teams could introduce to their programmers? Just saying, if this would easily bring students into programming-related careers that WILL use Assembly Language. ::safety::::safety:: :eek: ::ouch::

Re: Assembly Language FRC Robots????
 

It's highly unlikely that it will ever be available for FRC. It would be a fantastic challenge though. Sign me up.

Take it from me, I've been a low level assembly programmer and systems engineer for over 30 yrs. I'd prefer it hands down, but it's not practical in today's world. While assemble code(even badly written assemble code) will always out perform any OOP language it is not the trend of software engineering. Lower memory requirements, lower disk requirements, lower processor requirement.

I write in assembly because my company's business requires that high performance, low resource utilization. Many of my programs execute millions of times a day, that simply can't be done with OOP.

Although I certainly would love to see the challenge of writing code fort this years game on a system with 16K of RAM instead of Megabytes of even Gigabytes of RAM, or even less. Then do it on a slow 40Mhz not Gigahertz processor.

Re: Assembly Language FRC Robots????
 

Perhaps having a running, modern-day-built robot with its cRIO hardware performance emulated to "1960's-1970's computer hardware" could be :D The Game:D itself.....

Re: Assembly Language FRC Robots????
 

Hey, it is called inline assembly. Look it up. Or can you just use the assembler in the WindRiver package to directly assemble the code then link it? I will not be able to do it next year. Not because of my lack of skill or knowledge, but the sake of others. I would love it if I had the permission to, but I do not have the permission. Perhaps an off season project.

You will be surprised, if you actually get your nose into it, it is not this behemoth that can't be beaten. It just sounds scary; you are just afraid of the unknown. Majority is understanding how a computer actually works. It really is a billions of switches. I am not saying I KNOW how a computer actually works per se, but I know enough to say I know the top level of the hardware level. Hopefully I learn the ins and outs of computer hardware in college... But I can't wait that long. :/

To be honest with you, I LOVE the low level. Its just me however, I am just unconventional like that.

Re: Assembly Language FRC Robots????
 

Our team has no regular programming mentors, I have to fend for myself. as much as I'd LOVE to program in asm, I don't have anyone to show me what the heck I'm doing! I think a lot of teams might have the same problem.

Re: Assembly Language FRC Robots????
 

Oooh if you could chronicle that I would appreciate that. I really want to learn asm and if you could write up a tutorial about how you apply it to FRC I would really appreciate it.

Oliver

Re: Assembly Language FRC Robots????
 

Interesting topic.

I prefer to recruit from CS departments that teaches assembly in at least one class. I think it is useful, perhaps even necessary, for truly understanding computer architectures. On the other hand, once hired, productivity is important. Higher level languages were invented for good reason, and in my career, I've replaced more assembly than I've written.

For instance, in an early project, I was tasked with rewriting 100 pages of assembly code macros for 68k so that it would run on a 386. I read through the assembly code macros for days looking for a strategy to map the two architectures. The code was primarily doing floating point, and it was dealing with nasty stuff -- overflows, underflows, extended formats, double formats, single formats, integers, etc. I was still struggling to determine how I'd deal with the FP register differences when I talked with my mentor and we discussed why it was in assembly in the first place. Over the next few days, I wrote six pages of C code that used macros and other techniques to keep efficiency. It replaced the functionality of the assembly code, was portable not only to the 68k and x86, but also worked on SPARC. For performance reasons, it called about fifty lines of assembly that identified special float values such as infinities and NANs. Would the assembly code have been more efficient? I'll never know, because NI wouldn't want to pay me for the several months it would have taken me to write and debug it. Later it would also have taken several months more to write it for SPARC. And then there was the PA-RISC processor for HP. More time.

In all, that single decision probably saved the company half a man-year of labor costs with no impact on runtime efficiency. Even better, the code was pretty easy to read and test. Fifteen years later, the C macros were rewritten into C++ templates and again, the efficiency was maintained.

My point? Learn your tools. Explore assembly by writing a small function that you call from C++. Perhaps start with a routine to average sensor readings or something small. Work your way up to a PID. That will be more of a challenge than you may think. Be sure to compare the results to the C version. If you love it and you can show efficiency of the finished code and your ability to write it, keep going. But if you find yourself spending lots of time writing many lines of buggy assembly code, you will have discovered why some extremely bright individuals built higher level languages.

Enjoy the journey.

Greg McKaskle

Re: Assembly Language FRC Robots????
 

Go get a job maintaining someone elses assembly code. It will give you a new perspective on things.

Another neat exercise is to write code in C or Ada or something and run it through a really good compiler and look at it's output. The good compiler writers have advantage over a run of the mill assembly programmer. Interesting exercise.

And to add a note to Greg's comment about hitting the bottom line .... I want processors to work for me, not the other way around.

Re: Assembly Language FRC Robots????
 

Well apparently, from talking to my mentor, he really says that the negatives really outweigh the benefits. He pretty much said I can use assembly all I want out side of the competition bot. You really do not need all that efficiency in the code unless you are doing some very data intensive things such as object recognition.

Re: Assembly Language FRC Robots????
 

I agree, assembly has similar vocational benefits as any other higher language. Regardless of the type of data you're using.

I've been doing that, that's where my main background knowlegde of assembly came from.

Assembly has a similar programming difficulty to C++ or Java. So if FIRST really did use assembly as a alternate language, there would be a very nice tutorial of assembly all teams could understand.

And as I've mentioned before.....

Re: Assembly Language FRC Robots????
 

@divisionByZero0: Could you give some examples ?

Re: Assembly Language FRC Robots????
 

It's a good idea to have an assembly copy of source code to see what the executable will do exactly. That way you can see what the high language version of the code will look like in an assembly code debugger. You can also rewrite certain parts of you high language code into certain algorithms that will use the same inputs, sends the same outputs, and using the same resources (via. I/O, RAM, etc.). While at the same improving the speed and/or size of the code.::safety::

With enough knowlegde with assembly, you could do anything. Like hardware-level debugging, I/O programming to connected ports on the computer, self-modifiing code, super-sneaky virus hacking, network security weaking, disabling global satellites, reverse engineer executable code for network servers that'll force-delete every websites' and connected home computers' data, tuning the Internet into nothing but a super-massive black hole of sacred, manmade data, of which all the 0's and 1's will be gobbled up and every bit of memory will be turned into 2's!!!!!!!!!!!!!!
:ahh: :ahh: :ahh: :ahh:

(Sorry, too evil....)
Though first paragraph I am serious.

Re: Assembly Language FRC Robots????
 

Similar difficulty to C++ or Java? I'm not sure what leads you to that conclusion. The complexity of the syntax may be similar, but reading a program written in assembly, or controlling the computer resources with it is far far more difficult. From my experience, the time it takes to write code is more like ten times as much. The number of bugs and difficulty of understanding bugs goes way up too.

To echo Ether, and peak behind some of the mystique of assembly programming, can you name tasks that cannot be programmed in C? Ones that requires assembly?

Greg McKaskle

Re: Assembly Language FRC Robots????
 

I whole heartedly agree with all the other engineers in this thread, assembly languages are great and it is important for Software Engineers/Systems Engineers to understand them to really understand why your code does what it does. RPI's Computer Science and Computer Engineering curriculums both require a course that introduces programming at that level. The point of this class is not to learn an Assembly Language but rather to learn how the processor executes your code and learn that you should be grateful you don’t need to write code at that level very often.

I have some experience writing low level code for extremely low cost/power microprocessors however there is no reason to write in assembly for something as powerful as the cRIO. If you want to learn assembly as an academic exercise then I can see the benefits, however learning it and using it instead of C++/Java/LabView for FRC applications makes absolutely no sense. There may be something that you would want to write in assembly for the cRIO but I have not in my time in FIRST seen any reason to even inline assembly never mind writing robot code from scratch entirely in assembly.

One of the aspects of engineering that is often overlooked by students on CD is the importance of identifying your tool-set and using the correct tools. Assembly Programming is often a tool that is better left in the toolbox. You can always fashion a tool from stone and slowly scrape aluminum away to lighten your robot but I guarantee your team will be more grateful if you just throw it on the mill.

Re: Assembly Language FRC Robots????
 

::rtm::
You can use assembly to control hardware at a deeper level than C++ or Java. A great example, that is not related to FIRST but still considered very educationally challanging to try as a hobby or future profit, is to manually hard-code hardware accelerated software for the GPU/PPU (if one wish to make their own new 3D rendering software similar to OpenGL, DirectX, etc). Homebrew games (ie: Nintendo Wii/DS/3DS/GameBoy/GameCube/64/SNES/NES/etc.) are commonly made with an assembly syntax, whenever a high level language compiler is not available. Preatty much if you want the most of your hardware, assembly can let you make you own algorithms that is too trickly to program under C++/Java's syntax.

:yikes: ::safety:: ::ouch::
(Do not hack the cRIO, FIRST will frown apon it) :(

And as I've ment by "Similar difficulty", I ment learning assembly is similar to learning C++ or Java (but mostly C++). The main difference in assembly to C++ is you need to write out every individual steps from each line of C++ code, in the correct logial/mathematical order, and line up the jump conditions correctly.

(Should I mention self-modifing code.....)

Re: Assembly Language FRC Robots????
 

You have to realize how much abstraction the C++ library provides. Which is a good thing IMHO in this context. Not once, had I ever found a use for simple bit manipulation such as AND, OR, XOR, NOT... I only used them for conditional operations. I really never even used them to mask binary data or anything like that. I never had to shift any bits. The only practical usage of assembly in the context of FIRST is probably only mathematical functions. Which is more than enough to do bit manipulation on the C++ level. You still can use &, ~, |, ^, <<, >>... Which is And, Not, Or, Exclusive Or, Shift Left, Shift Right respectively. Now, can you tell me how in the world you will incorporate those operations into your project? Sure, I can find uses for bit shifting, probably not the other operations. I can force myself to use them, but where is it practical to mask bits or anything of those sorts.


Do you really have more control? I really doubt you, even I, can handle even making a motor move using Assembly. There might be system calls or something to directly write data to the speed controller, but even that probably takes up lots of time debugging and ect.


I know, I know, I just barely scratched the surface on Assembly, but you get the point.

Re: Assembly Language FRC Robots????
 

I think that there is agreement and understanding in this thread that Assembly programming has its uses, and it is in some cases necessary to use Assembly languages when you are pushing the limitations of your hardware. However what is important to note is that the topic of the tread you created is Assembly Language for FRC. C++, JAVA and Labview are all efficient enough for the application.

I don't know if the wording is just strange but your last sentence doesn't make sense to me. If something is to tricky to write in C++/JAVA how would it be easier to write it in Assembly?

You seem to make a statement here than contradict it immediately you say the difficulty is similar, and then you describe the difference as being much more complicated. It is a lot easier to write in a High level language than it is to write in a low level one.

Based on this post I assume the majority of your programming experience is from programming PCs and FRC programming. If you ever write code for a control system that doesn't have an established framework like WPILib you will quickly find out where Bit masking and bit-wise logic is useful. Any time you need to access a register you will use these tools. If you look at the code WPI provides I am sure you will find plenty of places where this was used.


I am sure you are a bright kid and a talented programmer but comments like this make you look arrogant. You are clearly implying that you believe you are more capable than he is and that if something would be a stretch for you then it would surely be impossible for others. Perhaps you believe this; perhaps it is just a case of your intent not coming through the text. Either way think before you make comments like that.

Re: Assembly Language FRC Robots????
 

First of all, I did not mean to offend anyone. Now, it is true, majority (actually all) of my work with assembly literally has been on a computer on protected virtual mode. I have seen codes for embedded control systems. I totally agree with you, those tools a essential for any assembly work.

I tend to sound arrogant, it is a personality flaw I have. I try to sound as nice as I can. The "even" should have been an "or", quiet possibly "and"

Re: Assembly Language FRC Robots????
 

This is a fine answer, but mostly to different questions. I asked about tasks that require assembly, not HW that requires it because you don't have a compiler that targets it. And it is a hard question, because IMO, if a HW vendor does a good job, they write the several pages of assembly functions for you and expose them with ANSI C entry points. Then none of their users ever need to use the inline assembly in order to make the HW do special things. The user just calls a function that makes the HW do the special things. They can call it from pretty much any language made since we went to the moon. Even better, when the vendor finds a bug or revs the HW, they can update the function to keep the user code working.

Similarly, if a HW vendor wants you to use their HW, they should IMO provide a backend to gcc or another compiler, along with mechanisms for getting code onto their HW, header files, etc.

Generally, C was designed for making OSes easier to write and more portable. It, and a few languages like it, were expressly given features so that they could write interrupt routines, treat code as data, and use assembly to call special CPU instructions unique to that HW. It was designed largely so that people would no longer have to write the OS in assembly. If this were a bad idea, C, UNIX, linux, and other OSes written in C would have died out and OSes written in assembly would be dominant.

-------------------------------------

Looking at the specific points ...
Deeper level:
There is truth to this. The PPC in the cRIO has a special register called the MSR -- the machine state register. This controls low-level features including the power management state of the CPU. By writing different values to this, you can put the CPU into -- awake, doze, nap, and sleep modes. To modify this and other special registers, you have to use a supervisor-level special machine instruction called mtspr (move to special purpose register). How do I know this? I looked it up at the following URLs.

http://rocky.digikey.com/WebLib/Moto...ata/MPC603.pdf
http://publib.boulder.ibm.com/infoce...gref/mtspr.htm

Does this mean that you cannot change the power mode? No. You do it by calling VxWorks routines such as cpuPwrCStateSet( ) or one of the dozen related functions. Note that I'm not even sure if this works on the PPC, but this is what I was able to find in the VxWorks docs. On a different OS, you'd make a different call. If you work for Intel or FreeScale, if you work on one of those projects that decides you want your own proprietary OS, you will need to write this function, and you will do so by using assembly. Otherwise, the OS will actually prevent, or try to prevent you from doing this. Do it wrong, and you will probably corrupt the machine state and crash within a few microseconds. And I don't mean crash as in throw an exception or with a nice dialog. I mean crash as in seized up -- no CPU instructions are being executed anywhere sort of crash.

Compiler not available:
When a bridge isn't available, people take a ferry. When that isn't available, a few people swim, but most go somewhere else. Once they build a bridge, that is what people use. My point is ... look around for a compiler, or build one. They sometimes name bridges after the engineer who builds it -- other times after the congressman who funds it.

Tricky Algorithms:
Examples please. If you wish to make your algorithm brittle and non-portable, even to new versions of the same CPU, use assembly. This is not common.

I think you just did. This is actually very HW dependent and is generally prohibited by the OS. Harvard architectures and derived architectures load code into different memory caches. They do this for efficiency gains for "normal" code. At this point, self-modifying code is either illegal, or needs cache flushes and is now quite inefficient. Similarly, most OSes mark VM pages as write protected. Your code will throw an exception in doing this. The compiler in LV takes your diagram and generates machine instructions directly as data. It then requests the OS to declare it as code so that it can be executed. JITters do the same thing. Sure, there are architectures and OSes where this is still possible, but from what I see happening, they are again, incredibly rare.

Conclusion:
By the way, I gave the references above so that you can read or skim it to appreciate the complexity of the CPU in the cRIO. It is a pretty old RISC architecture -- pretty simple and clean by most standards. And still, it is soooo tedious to try and keep straight what values you have in different registers, dealing with running out of registers, dealing with how the ABI defines parameter passing and other conventions. I do not want to discourage you from learning about hard things or even doing hard things such as this. But I want you to be aware of what you are trying to do.

If you attempt to program any significant portion of your FRC code in assembly, you will be making your task ~20 times harder than other approaches. You will most likely have a less impressive robot, disappoint your teammates, and the next batch of programmers will probably say interesting things about your code and your ancestry. By all means, learn about CPU architecture and underpinnings, but don't expect it to have much immediate impact on your robot. Learn assembly if you like, but do it in a supportive and safe environment.

If you have other assembly questions or debates, I'll be happy to take part.

Greg McKaskle

Re: Assembly Language FRC Robots????
 

There are other tricky high level syntax that might give you data that you could of munipulated better in assembly, ie. the BASIC syntax.

And...
Since it would be a waste of time remaking the entire WPILib in assembly, of which it was already set up for FRC, You could recompile the code in Windriver, and debug the code at the low level to see and learn what the C++ code is really doing. Then you will have to make some sort of documentation of the assembly code of what you should be doing to control the robot.
(Without doing harm to the cRIO.):(

:D :confused: :D
How ironic that a simple inside joke could be added to an intelligent responce. Self-modifiying code is not always illegal, or inefficient. It's just another powerful programming force that can either create or destroy many, many miracles.....
::rtm::
http://en.wikipedia.org/wiki/Self-modifying_code

Re: Assembly Language FRC Robots????
 

This thread is missing the biggest factor in making a decision to use assembly. We are tasked with coding and testing all the robot application firmware from scratch each year and we have only 6 weeks to get it done! Using assembly is fun to talk about but a crazy idea! And some other points...

- I have been doing this kind of stuff for almost 30 years. Anything and everthing done in assembly can be done in C (and C++ since it is simply a superset of C). The only tricky things are some instructions that are only available in assembly (like synchronizing the pipeline, invalidating caches etc) and there are pre-processor macros for these types of things. Note that this is not true of Java or most other 4GLs.

- Self-modifying code is from the devil ;o). Nobody in their right mind does this anymore. Every company I have ever worked for prohibits this practice. And on the cRio, under VxWorks, it is quite difficult to do since the text segments (where executable code is stored) are typically marked read-only.

- Most software spends huge amounts of time in just a few small areas of the code. Optimizing these regions in assembly so they are faster or might fit entirely into cache can yield huge improvements in throughput. For example, on the robot, putting the PID calculation thread in assembly might be kewl. But NOT in 6 weeks!

- It used to be that one could express algorithms in assembly better than a compiler. But in the last couple decades ANSI C added features (like the 'register', 'inline' and 'volatile' keywords) and compilers have improved to the point that it is very difficult to do a better job than the C compiler - and by extension better than LabView.

- Assembly is used today and is irreplacable for some things like booting the processor, binding interrupt service routines and executing some privileged instructions. But these things are done for us in the OS. Using assembly for application programming on the FRC robot is fun to talk about, but a really bad idea.

HTH

Re: Assembly Language FRC Robots????
 

WOOOOOPS!!! :yikes:
I've accedently trolled my own thread!!!!
Thank you all for mentioning that self-modifing code is a big no-no (along with me trying to convince myself somewhat right from "psuedo-true" wikipedia facts for the self-modifing code, but failed after hours of me researching the real dirty truth of the self-modifing code, via: learning how computer viruses work).

:mad:
Sorry for any cRIO hackers who would like to pray on poor defence-less robots. Your answer(s) are not here......

:confused:


On a serious note:

Very true!!!! My original thought was to use assembly language as a alternative programming language, not to make 99.99999999% of the FRC programming population to come down with an epidemic of coma-like headaches, but just to give FIRST an exposure of learning a low-level language. I believe low-level programming is just as vocationally benifical as high-level programming when it comes to programming robots. :D

(WITHOUT SELF-MODIFING CODE!!!!!) :(

So can we please stop with the SELF-MODIFING CODE.
From this point on, only post any opinions for anyone who is fully Pro/Con for the assembly language. Considering we all made enough facts on this thread for everyone to think about.

Re: Assembly Language FRC Robots????
 

am going to assume you did not mean to shout at me or the CD community - plz take things down a notch

HTH

Re: Assembly Language FRC Robots????
 

Sorry, I'm one of those programmers who likes the SELF-MODIFIYING CODE.:yikes:
(And no, I'm not a hacker):o

But seriouly, anyone else, who has any other expert advice of how assembly language can be used in FIRST, please join in......

Re: Assembly Language FRC Robots????
 

I'm not exactly an "expert", but having studied a bit of assembly code in college, my advice on how to use it in FIRST is: Don't!

Re: Assembly Language FRC Robots????
 

I would have to call Greg, and raise him another 5 or 10 times. (make that 50-100 times harder).

Lets clarify this... we're not talking about a few lines of optimized assembly code here, we're talking about a full blown, real time processing system with I/O, networking, disk operating systems, image processing, yada, yada, yada.

No point in just doing the main calling code in assembly. If you want ultimate control and performace then you need to recode EVERYTHING in assembly. Needless to say.. No-One is going to do it. Ever... period...

That being says, I think a basic knowledge of assembly code is a great skill for an embedded programmer to know... just like boolean logic gates and flip-flops.

Anyone who wants to get a taste of this world should get themselves a little 8 pin PIC processor and a PICKIT2 programmer and go for it. But be ready to start thinking in register memory maps, bit test operations and interrupt service routines, because it all gets a LOT more down and dirty.

Phil.

Re: Assembly Language FRC Robots????
 

Us programmers are already worked too hard. :rolleyes:

Re: Assembly Language FRC Robots????
 

I'm assuming this is true for every team.
ie: Mushroom cloud motor burnout...