Assembly Language FRC Robots????

[divisionByZero0]

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

[nitneylion452]

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?

[divisionByZero0]

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.

[Ether]

Originally Posted by divisionByZero0

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

@divisionByZero0: Could you give some examples ?

[divisionByZero0]

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.

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


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

[Phalanx]

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.

[divisionByZero0]

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

[davidthefat]

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.

[Birdlives]

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.

[linuxboy]

Originally Posted by davidthefat

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.

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

[Greg McKaskle]

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

[ebarker]

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.

[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.

[divisionByZero0]

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

[Greg McKaskle]

Originally Posted by divisionByZero0

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.

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