Assembly in the Arduino IDE

[Robert Paz]

I have been using the Arduino Uno to teach Assembly language programming to our students.  

To do this required modifying the IDE to accept the assembly language files (.s files), and then recompiling the IDE.  The IDE was already capable of compiling the .s files, but the IDE just did not recognize them.

Since version 1.5, however, the "hooks" that we used to do that have been changed.  I can no longer find where to modify the IDE to accept .s files.

Can anyone help me?

Thanks,

Robert Paz

[Federico Fissore]

Robert Paz ha scrito il 22/05/2015 alle 19:58:

While activating .S support needs some internal discussion, I've
prepared a PR

https://github.com/arduino/Arduino/pull/3227

ArduinoBot should provide links to downloadable IDEs in the next few hours

Even if we won't merge it, the patch will help create a customized IDE

Regards

Federico

[Robert Paz]

Hello,

Someone (ArduinoBot) posted some files on github on my post. However, I cannot download those files (it says, “404 File Not Found”)
1.How can I get those files?
2.How can I contact ArduinoBot about them?

Thanks,
Bob

> --
> You received this message because you are subscribed to the Google Groups "Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.

[Federico Fissore]

Robert Paz ha scritto il 04/08/2015 alle 20:08:
> Hello,
>
> Someone (ArduinoBot) posted some files on github on my post. However, I cannot download those files (it says, “404 File Not Found”)
> 1.How can I get those files?
> 2.How can I contact ArduinoBot about them?
>

If those files belong to a closed PR, they have been removed.
If the PR has been merged, download the hourly build
http://www.arduino.cc/en/Main/Software#hourly
Otherwise, you have to fetch the unmerged code and build the IDE your self

Regards

Federico

[Álvaro Lopes]

Robert,
I have support in ZPUino for that, contact me and I'll send you a patch so you can add support into latest Arduino IDE.

Federico: not sure anyone is interested in this, but I can also do a pull request if you wish. Changes are minimal.

Cheers,
Alvie

[Federico Fissore]

If the code you'll provide does the same of
https://github.com/arduino/Arduino/pull/3227 then it's already available
in the hourly build and will become part of 1.6.6

Regards

Federico

[L. M.]

At the moment I only have it working for AVR but I will also do ARM.

plus there are many details that should (will) be improved.  I also found out today that I might be able (no promise yet on this one) to do something about inline Assembly in C++ files.

-LM

[L. M.]

actually, if someone knowledgeable wouldn't mind laying a hand, I could use a simple link to a high level summary page with all the highlights (regs, pre-proc, ...) for both architectures (my poison of choice used to be MASM... I'm sure lots has changed)

[Matthijs Kooijman]

Hi Laurent & Robert,

> plus there are many details that should (will) be improved. I also found
> out today that I might be able (no promise yet on this one) to do something
> about inline Assembly in C++ files.

I actually think that assembly files should work, but should be named
.S. Adding .s file support should be fairly easy (requiring a small
change in arduino-builder to compiler and the IDE to edit them).

There was a small bug recently where .S files weren't actually compiled,
but that should be fixed in the hourly builds (see
https://github.com/arduino/arduino-builder/issues/74).

Gr.

Matthijs

[Andrew Kroll]

GAS syntax is way different than MASM. You may find it more complex, but also more useful. You can also just inline ASM right in C/C++ anyway, and get access to local/global variables quite easily. In most cases there really isn't a need for .S files unless you are doing something very low level and special.

--
You received this message because you are subscribed to the Google Groups "Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to developers+...@arduino.cc.

--

Visit my github for awesome Arduino code @ https://github.com/xxxajk

[L. M.]

yes, indeed ... support for these files is no more than adding .S to the extensions (so are .png/.jpeg/.md). My reservation with how it works is how badly the editor handles it.

Then comes the next question: how to fix it? Which brings you to Pandora's box:  Editor/SketchData/SketchDoc/SketchTextArea, and one step closer to understanding my warning about the refactoring you proposed in some other post.

The next sentence should be rater PG13... professional opinion? that code is not throwaway, but really nasty

[L. M.]

I imagine... I don't need to understand it to do proper syntax coloring for it though. All I need is a few broad but realistic source files to see the scope of what I need to cover. I did a first pass at an AVR instruction set, but I can't even tell if I got them all, or added some that didn't belong. I want to do the same for ARM Cortex (at least mapple level support - M3 I think). I'd also like to do a bit more than to paint the screen in pretty colors, and jump around in the code or at least display some structure (e.g at least listing the external API of a source file visible from C/C++).

embedded assembly is another story... but hey.. it's just source code... so it's a matter of deciding if it is worth a couple days of work

To unsubscribe from this group and stop receiving emails from it, send an email to developers+unsubscribe@arduino.cc.

[Matthijs Kooijman]

Hi Laurent,

> yes, indeed ... support for these files is no more than adding .S to the

> extensions (so are .png/.jpeg/.md). My reservation with how it *works* is

> how badly the editor handles it.

Ah, good point, the editor probably doesn't know how to syntax highlight
them. OTOH, we use RSyntaxTextArea, which I think supports highlighting
out of the box, so perhaps it knows how to do assembly as well. Haven't
checked, though.

> Then comes the next question: how to fix it? Which brings you to Pandora's
> box: Editor/SketchData/SketchDoc/SketchTextArea, and one step closer to
> understanding my warning about the refactoring you proposed in some other
> post.

This is a bit off-topic for this thread, but I'm currently working on
some actual cleanup of exactly that part of the code, reduce complexity
of the code and coupling of the classes. I'll probably submit a pull
request for these changes later this week, I'll drop a note to the other
thread once I do.

Gr.

Matthijs

[William Westfield]

> proper syntax coloring

Is there an accepted “proper syntax coloring” for ASM? I’m not sure it makes sense to separately recognize opcodes and registers, for instance. I see several syntactic elements:

1) C Preprocessor statements and C-style comments (colorize as per C/C++) (processed by cpp.)
1.5) Assembler preprocessor stuff (ie comments beginning with the assembler comment char.)
2) gnu assembler directives (usually being with “.”, and mostly common across architectures.) https://sourceware.org/binutils/docs/as/Pseudo-Ops.html#Pseudo-Ops
3) Labels (followed by “:”) (Your current scheme colors these the same as opcodes, but they’re one of the things I’d most like to be distinct. I think.)
4) Assembly language statements. I’m NOT sure that it’s important to break these down and further (opcode, register, etc) MAYBE distinguish numeric constants from symbols?

BillW/WestfW

[L. M.]

On Tuesday, December 8, 2015 at 10:10:30 PM UTC+1, Bill Westfield wrote:

> proper syntax coloring

Is there an accepted “proper syntax coloring” for ASM?  I’m not sure it makes sense to separately recognize opcodes and registers, for instance.  I see several syntactic elements:

lol.... look at what the IDE does by default, and you'll understand what I mean by "proper"... the current default is actually pretty funny... I would be ashamed of having my name associated with something like that, but its just me. I was thinking about looking at what VStudio does.. MS is very good.

 

1) C Preprocessor statements and C-style comments (colorize as per C/C++) (processed by cpp.)
1.5) Assembler preprocessor stuff (ie comments beginning with the assembler comment char.)
2) gnu assembler directives (usually being with “.”, and mostly common across architectures.) https://sourceware.org/binutils/docs/as/Pseudo-Ops.html#Pseudo-Ops
3) Labels (followed by “:”) (Your current scheme colors these the same as opcodes, but they’re one of the things I’d most like to be distinct.  I think.)
4) Assembly language statements.  I’m NOT sure that it’s important to break these down and further (opcode, register, etc)  MAYBE distinguish numeric constants from symbols?

if you look at my screenshot, this is partially where I am. My problems are

 - my list of opcodes is rather ... hmmm.... happenstance (plus I don't have any for the Cortex M3 instruction set

 - I have noooo clue what a realistic list of preproc macros should be for GAS (I made one, but ... again happenstance)

Thx for the link, I will look into it.  Anyone feeling like sharing links for the rest.. 

 

BillW/WestfW

@Matthijs

OTOH, we use RSyntaxTextArea, which I think supports highlighting 
out of the box, so perhaps it knows how to do assembly as well. Haven't 
checked, though. 
 

At the risk of taking more flak than I care for, you might consider the possibility that at this point I likely know more than the arduino team about Editor/.../RSyntaxTextArea. Neither good, nor bad, just a factoid with an associated probability.

[L. M.]

@BillW  this is what I currently do.. you'll notice the 'z' colorized differently from the other regs. or the numeric values colored like jump labels, or ever the fact that labels are colored differently when defined vs when used. This are all bugs I will get around to fix.