AVR Freaks

Can't hurt to try!

Error: junk at end of line, first unrecognized character is `('

Can't help, either, apparently :(

I started a thought experiment on that before starting the thread.  'For deity's sake, the compiler generates jump tables for breakfast.  Surely gas can handle this...'  But the twist is that the compiler will, I suspect, always generate jump tables with complete entries, and as my OP demonstrates, .byte .word has no issue with a simple pm(label).  I'm trying to omit the MSB and use .byte.

 

Further, the avr-gcc-list thread I linked to seems to suggest the problem lies with binutils, not with avr-gcc.  But that may certainly be an incorrect analysis.  EDIT:  indeed, the error messages themselves appear to be issued by the assembler. /EDIT

 

I shall have to try to coerce the C compiler into chasing after a ball I faked throwing, and see where it runs... I just don't yet quite know how to do that.  I'll give it some thought, though.

  But... they are?:

https://sourceware.org/binutils/docs/as/AVR_002dModifiers.html

9.5.2.3 Relocatable Expression Modifiers

The assembler supports several modifiers when using relocatable addresses in AVR instruction operands. The general syntax is the following:

modifier(relocatable-expression)

pm_lo8

pm_lo8

This modifier allows you to use bits 0 through 7 of an address expression as an 8 bit relocatable expression. This modifier is useful for addressing data or code from Flash/Program memory by two-byte words. The use of ‘pm_lo8’ is similar to ‘lo8’.

pm_hi8

This modifier allows you to use bits 8 through 15 of an address expression as an 8 bit relocatable expression. This modifier is useful for addressing data or code from Flash/Program memory by two-byte words.

For example, when setting the AVR ‘Z’ register with the ‘ldi’ instruction for subsequent use by the ‘ijmp’ instruction:

ldi r30, pm_lo8(sym)
ldi r31, pm_hi8(sym)
ijmp

There seems to be no issue with using them in operands of instruction operands, only with pseudo ops like .byte.  So the machinery to handle the reloc is already in there.

 

I suspect I've misunderstood your meaning.

 

I haven't yet sussed out how to coax avr-gcc to emit a jump table consisting of only the LSB of the addresses.

The thought crossed my mind, but composing an OP with a plea for help seemed like an easier first step :-)

Also tried:

	.byte pm(label1)

... in the hopes that .byte would silently drop the high 8 bits, but:

Error: junk at end of line, first unrecognized character is `('

 

I can't catch a break :‑/

 

EDIT:

 

assembles:

------
.byte lo8()

.word pm()

 

doesn't:

--------

.word pm_lo8()

.word lo8() <--- this one is especially surprising!

.byte pm()

.byte pm_lo8() <--- this is really what I need...
 

 

That was the key insight!

 

Here is a test program:

.equ	mode, 16

.section .vectors

.org 0

zero:
	ldi	mode, -1

again:
	inc	mode
	andi	mode, 0x07

	ldi	ZH, hi8(jump_table + __AVR_PM_BASE_ADDRESS__)
	ldi	ZL, lo8(jump_table + __AVR_PM_BASE_ADDRESS__)
	add	ZL, mode
	ld	ZL, Z
	ijmp

label1:
	rjmp	again

label2:
	rjmp	again

label3:
	rjmp	again

label4:
	rjmp	again

label5:
	rjmp	again

label6:
	rjmp	again

label7:
	rjmp	again

label8:
	rjmp	again

.type	jump_table, STT_OBJECT
jump_table:
	.byte ((label1 - zero) / 2) & 0xFF
	.byte ((label2 - zero) / 2) & 0xFF
	.byte ((label3 - zero) / 2) & 0xFF
	.byte ((label4 - zero) / 2) & 0xFF
	.byte ((label5 - zero) / 2) & 0xFF
	.byte ((label6 - zero) / 2) & 0xFF
	.byte ((label7 - zero) / 2) & 0xFF
	.byte ((label8 - zero) / 2) & 0xFF

 

Assembled:

Disassembly of section .text:

00000000 <zero>:
   0:	0f ef       	ldi	r16, 0xFF	; 255

00000002 <again>:
   2:	03 95       	inc	r16
   4:	07 70       	andi	r16, 0x07	; 7
   6:	f0 e4       	ldi	r31, 0x40	; 64
   8:	e0 e2       	ldi	r30, 0x20	; 32
   a:	e0 0f       	add	r30, r16
   c:	e0 81       	ld	r30, Z
   e:	09 94       	ijmp

00000010 <label1>:
  10:	f8 cf       	rjmp	.-16     	; 0x2 <again>

00000012 <label2>:
  12:	f7 cf       	rjmp	.-18     	; 0x2 <again>

00000014 <label3>:
  14:	f6 cf       	rjmp	.-20     	; 0x2 <again>

00000016 <label4>:
  16:	f5 cf       	rjmp	.-22     	; 0x2 <again>

00000018 <label5>:
  18:	f4 cf       	rjmp	.-24     	; 0x2 <again>

0000001a <label6>:
  1a:	f3 cf       	rjmp	.-26     	; 0x2 <again>

0000001c <label7>:
  1c:	f2 cf       	rjmp	.-28     	; 0x2 <again>

0000001e <label8>:
  1e:	f1 cf       	rjmp	.-30     	; 0x2 <again>

00000020 <jump_table>:
  20:	08 09 0a 0b 0c 0d 0e 0f                             ........

 

It's still a bit of a kludge.  A macro makes it a bit less ugly:

.macro jmptab label
	.byte	((\label - zero) / 2) & 0xFF
.endm
.
.
.
.type	jump_table, STT_OBJECT
jump_table:
	jmptab	label1
	jmptab	label2
	jmptab	label3
	jmptab	label4
	jmptab	label5
	jmptab	label6
	jmptab	label7
	jmptab	label8

 

I can only mark one post as the solution, but both Matt and Bill share in the kudos.  Thanks to skeeve also for an alternative ugliness to the ugliness suggested in the avr-gcc-list thread.  Indeed, thanks to all respondents.

 

EDIT:  cleanup

Understood.  My test code was adapted from an existing application.  I typically use .section .vectors along with -nostartfiles to ensure code starts at 0x0000.