Gnu Assembler problems (not sure where this belongs :)

Go To Last Post
8 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am having some problems with the AVR version of the GNU assembler that you install with the Atmel tools.  I have not encountered any of these problems with any other version of the GNU assembler.   Until I have resolved these issues (these are BUGS in this version of the GNU assembler) I am basically stalled.  I need a viable work around...

 

Problem 1:

 

I have a macro that lays down a string with a leading count byte.  The macro is as follows

 

.macro string str

  .byte 9f - (. + 1)

  .ascii "\str"

9:

 .balign 2, 0

.endm

 

I have a work around for this but it is a major PITA.  I just need to pass in the length of the string to the macro so ... 400+ strings in my sources and i have to count the length of every single one by had.  STUPID!

 

This macro works flawlessly on the X86 version of the GNU assembler that comes with my Linux installation and with the Linux installation I put on my BeagleBoad-XM (ARM).  I have used this macro for years without problem.  The AVR version of the assembler pukes on it because the address "9f" (forward reference to a local label) is too big to fit in a byte.   err seriously?  Im not storing an address, im storing a delta between two addresses which is GUARANTEED to be less than 64 bytes.

 

Second problem...

 

some_code:

  call foo

  call bar

  call bam

  .int 1f

  call blah

  ...

1:

  ...

 

1f is an address and is 24 bits so we cant stuff that in a 16 a 16 bit .int data type.  If i make it a ".long 1f" then the assembler pukes on not being able to write 32 bit values into the 16 bit memory addresses in .text.  I could modify my code to expect a delta but again 1f - (.+1) wont fit here because the delta is a 0x000000nn <-- 32 bit value that wont fit in a 16 bit .text cell.

 

Any help would be appreciated !

 

 

If something can be read without effort then great effort has gone into its writing

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That looks and sounds a lot like this:

 

https://sourceware.org/bugzilla/...

 

Oh and it looks like this was also noticed here previously:

 

https://www.avrfreaks.net/forum/i...

 

but no resolution on that.

Last Edited: Mon. Mar 16, 2015 - 05:13 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

so what your telling me is that im basically ***** (deleted) till some developer up stream pulls his head out and fixes it... again :P

 

typical lol

ty for the reply

If something can be read without effort then great effort has gone into its writing

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You are using open source tools. Things only get bug fixes and new features when someone desperate enough for them puts their head above the parapet and offers a patch to deliver the change. I'm guessing that although this issue has clearly been noted before that no one has been desperate enough for a fix.

 

Having said that the first thread I linked it seems from comments #3 and #4

 

https://sourceware.org/bugzilla/...

 

that there already was an attempt to fix this and the place the fix needs to go is in tc-avr.c, elf32-avr.c and avr.h so perhaps you can just pull the source of binutils, try applying these existing patches - modifying if they don't match the current source - then rebuild your own copy of the AVR binutils.

 

It does seem curious though that a previously committed patch seems to have been "lost". I wonder why issue 11297 didn't simply fix this already?

 

BTW for AVR and GCC/GNU tools the "best" way to do strings in flash these days is actually to use .c and __flash:

 

https://gcc.gnu.org/onlinedocs/g...

 

So just:

const __flash char str1[] = "hello";
const __flash char str2[] = "world";

Though these are obviously C not Pascal style strings. You would need some additional jiggery-pokery to store the lengths.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

lol no way im going to use c!, im a dedicated heretic! 

 

This is an AVR Forth I'm working on.  In fact, I already have a fully working AVR Assembler written for my Linux Forth and an AVR  meta/target compiler.   This meta compiler is already producing a binary for the AVR Forth kernel but... have you ever tried to single step through a Forth disassembly with no symbols?  I wrote the thing and I get tied into a mental gordian knot in no time flat!. 

 

The plan is to build it with the Atmel tools just so I can run unit tests on every primitive in the kernel (with symbols available as I debug) and then switch back to the meta/target compiler method of development.  Once the Forth kernel is fully working I will have no need what so ever for any other development tool created by any other person. 

 

And yes, all my Forths are open source (tho some are not officially released yet like my ARM and Thum2 Linux versions... : )

 

As for the issue I posted about I spent the entire rest of the day yesterday (itll 3 am) figuring out how to make the project build using winavr instead of the Atmel tools.  I'm now building just fine and am putting the finishing touches on the kernel code and should be unit testing shortly... yay... it only took me a day and a half with no rests other than a 15 minute lunch to figure out how to get this done! THIS is why I Loathe and DESPISE just about every other development tool ever created (notable exceptions: Devpac for the Amiga, A386/D386 for DOS, Lazer Genius Assembler for C64).

 

ty for the help you guys rock!

 

If something can be read without effort then great effort has gone into its writing

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ty for the help you guys rock!

Your welcome.

 

I must say you do have an "interesting" view of the world.

 

Personally I take my hat off to the geniuses that have brought us GCC to the AVR and all for free! But I accept that as it's a work of love rather than commercial there may be issues.

 

Now you've highlighted the issue - even though no one else seems troubled by it - I'm tempted to look at it my self if only to understand why the issue seemingly still exists when it's supposed to have been fixed. Then again my mistake may simply be using a binutils 2.20 as that's all this Ubuntu 12.04 LTS offers.

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Im a Gentoo user myself (no distro flaming tho :).. which means my system revolves around the GNU tools.  I recognize the work that has gone into their development and the enormous amount of work that has been done with them.  I simply do not like the whole "edit 6000+ lines of c, compile it in 2+ hours, link it in half an hour and then debug for 9 months" C development cycle (only slightly exaggerated) and any time I have to use GDB my teeth start to itch. 

 

With Forth I write a primitive (avg of 4 to 8 lines of code) and immediately test it.  Each primitive is developed with limited purpose and is thus kept very small so is easy to test/debug.   I then create more primitive and test them.   When all (most?) of my primitives are written and tested I create higher level definitions using them and... IMMEDIATELY test them.  This cycle repeats until the application is done.  

 

This means that at every stage of development, everything that has already been developed has also already been fully tested.   The development cycle goes from "edit, compile, link, debug, repeat ad-nausium" to "edit, debug, repeat".  No need for a debugger, no need for trace tools, no need for a linker or any of that stuff.   The resultant application is developed in no time flat and is orders of magnitude more space efficient than c (and with embedded devices that's very important!). 

 

Im sure you can do the above development in cycle C too but... edit 4 or 5 lines of C and then compiling it would get real old real fast.  In Forth it just flows naturally.

 

This however is a hobby.  99.999999% of my professional development is in C and that's usually using some form of the GNU tools :)

 

If something can be read without effort then great effort has gone into its writing

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yup my 3rd year project at uni ('83..'84) was an investigation into the use and efficiency of Forth on various systems. I did a 6809 version (lovely because of the two stack pointers!) and a PDP11 version (two opcodes at the core of the TIL interpreter) so I recognize some of the attractions of Forth. In fact I even applied for a job to do it professionally but while I was waiting for their answer/offer something else came up and I ended up working there for 25 years instead!