can you specify HIGH or LOW byte of a LABEL/ADDRESS using the ".byte" or any other directive, is there anything similar to ORG ?

Please see the section titled MSP430 Built-In ELF Relocation Generating Operators in the MSP430 assembly tools manual.

Thanks and regards,

-George

looked at this many times... only allows you to specify 16 bit quantities using LO16/HI16... appears the only solution is to accept the PAD byte and write code to work around it

found that if I modify the linker .cmd file I can do something similar to an ORG statement that will work for FLASH ...this will not work for RAM though

getting the RAM to be placed at a specific address appears impossible... why does a compiler have no provision for specifying a (VARIABLE/RAM address) can be placed at an absolute address or at least a buffer that has a known address

the only way I have found to do this is to place (VARIABLES/RAM address) in " .data" and then use ".space" to allocate them... it is strange but for some reason the compiler ".data" counter will start at  location 0200h...of course the debugger will not know what the LABEL is for the (VARIABLE/RAM address) so you cannot WATCH a specific RAM address

attempts to use ".bss" places the RAM at C000h which is the start of the FLASH...

thanks for your response

There is no method which can split a symbol into pieces smaller than 16-bits.  Use the .field directive to put a 16-bit chunk of data (or symbol address) anywhere, and not just on 16-bit boundaries.  But I'm still unclear on why you need to do any of that.

There is no TI alternative to the IAR assembler ORG directive.  Instead, put it in a section with a particular name.  Then in the SECTIONS directive of the linker command file, you can allocate the section to a hard-coded address like this ...

    particular_section > 0x12345678

Thanks and regards,

-George

The reason for doing the thing spoken of here is to save a byte in the table.  Most software engineers do not  understand why saving a byte of code space in a table is important. Here is the best explanation I know to provide.

Hardware engineers code in assembly language for many reasons.  One is speed, one is to minimize ROM and RAM usage,  and the other is so we can make the hardware do what we want it to do.  Compilers and linkers are great but, in my experience over the last 4 decades I have spent a lot of time working around their issues. 

When you have a microcontroller with only 1K of  FLASH and 128 bytes of RAM these things are extremely important.  In high volume products, saving a few cents by going to a less expensive device is important.   I have had to redesign hardware before  to save .01 cents in the past.  This is a market that is important to TI.  If it was not, why did TI sell a development tool for $4.30 cents that cost them $15.00 to produce?

The TABLE entries are an odd number of  bytes each.  I honestly do not know how to code them to prevent the Compiler/Linker from inserting a byte.  I have tried using the ".align" and ".field" directives  but have not been successful.  If you could explain implicitly how to do this I would greatly appreciate it.  

I did find that I could get my LABELs to show up on the Debugger if I placed a single "NOP"  in EEPROM or RAM   sections that only had ".byte" and ".space" directives.  If I removed the "NOP" then they were gone.  I have never found a way yet to be able to see VARIABLEs in the Debugger when using Assembly language code. 

Thanks for all your assistance

George Mock said:

Use the .field directive to put a 16-bit chunk of data (or symbol address) anywhere, and not just on 16-bit boundaries.

With MSP430 CGT v4.2.3 using .field on a symbol address appears to force 16-bit alignment, using either COFF or ELF. As an example used this assembler code:

.align 1
LOOKUP_TABLE .field 031h,8
.field CRC_16,16
.field DO_NOP,16

DO_NOP MOV R10, R11
NOP
RET

CRC_16 .word 045AEh

The assembler listing file shows that the 2nd .field directive has been aligned to a 16-bit boundary and thus introduced one "padding" byte

10 .align 1
11 000000 0031 LOOKUP_TABLE .field 031h,8
12 000002 000C! .field CRC_16,16
13 000004 0006! .field DO_NOP,16
14
15 000006 4A0B DO_NOP MOV R10, R11
16 000008 4303 NOP
17 00000a 4130 RET
18
  19 00000c 45AE CRC_16 .word 045AEh

Not sure is this is a "bug" in the assembler, or a limitation imposed by how symbol relocation is defined in the COFF / ELF format object files.

Please ignore the first paragraph of my previous post.  I should not have recommended the .field directive.

Use the .bits directive instead.  The .bits directive can handle encoding a symbolic value that spans a word boundary.  The syntax is the same as .field ...

.bits    value, width in bits

Thanks and regards,

-George