Assembly Language FRC Robots????

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

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?

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::

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.

Perhaps having a running, modern-day-built robot with its cRIO hardware performance emulated to “1960’s-1970’s computer hardware” could be **:smiley: The Game:D ** itself…

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. :confused:

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

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.

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

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

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.

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.

davidthefat:
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.

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

ebarker:
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.

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

linuxboy:
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.

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…

Perhaps having a running, modern-day-built robot with its cRIO hardware performance emulated to “1960’s-1970’s computer hardware” could be The Game itself…

@divisionByZero0: Could you give some examples ?

**

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.

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

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.

Greg McKaskle:
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?

::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) :frowning:

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…)

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.

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.

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”