dadd simulation incorrectly does regular binary addition and overflow, not decimal addition.

Currently:
set r13=0x0001
set r14=0x9999
dadd.w r13,r14

current r14 value: 0x999a
expected r14 value: 0x0000 (SR.CARRY=1)

I've implemented a fix that closely follows the existing implementation but does decimal addition and handles decimal overflow. It generates the correct output on the above test case. I will issue a pull request shortly.

The 6502 simulator shift instructions seem strange. There is a check for mode == 4 which makes the instructions operate on the accumulator. However, mode 4 is OP_INDEXED8_X. I believe the check should be mode == OP_NONE instead.

Hi!

The "ADR" instruction described in the STM32F103C8 programing manual "The Cortex®-M3 instruction Set" is not recognized as a valid instruction when assembling a THUMB source.

ADR
Load PC-relative address.
Syntax:
ADR{cond} Rd, label
Where:
• ‘cond’ is an optional condition code (see Conditional execution on page 56)
• ‘Rd’ is the destination register
• ‘label’ is a PC-relative expression (see PC-relative expressions on page 56)
Operation:
ADR determines the address by adding an immediate value to the PC. It writes the result to the destination register.
ADR produces position-independent code, because the address is PC-relative.
If you use ADR to generate a target address for a BX or BLX instruction, you must ensure that bit[0] of the address you generate is set to1 for correct execution.
Values of label must be within the range -4095 to 4095 from the address in the PC. You might have to use the .W suffix to get the maximum offset range or to generate
addresses that are not word-aligned (see Instruction width selection on page 58). Restrictions
Rd must be neither SP nor PC. Condition flags
This instruction does not change the flags.
Example:

ADR R1, TextMessage ; write address value of a location labelled as
                    ; TextMessage to R1

Regards!

The disassembler for the STM8 architecture does not take into account the variable instruction length. It tries to decode one instruction at every four-byte boundary, even though instructions can be anywhere from one to five bytes long. Rather than always advancing start by 4, it should advance it by however long the previously decoded instruction was.

Additionally, the display is not accurate: rather than showing the bytes that make up the instruction, it shows the two bytes at the beginning of the four-byte word, padded with two bytes worth of zeros.

Hi Mike,

this input (MSP430):

b:  .db 1
    .db 1 ; padding

mov.b #b, r4

gives this error (version 9c5c74c):

Pass 1...
Error: Unexpected token '0' at ...:4
** Errors... bailing out

It may be a parser error because

• changing the label from b to c
• or replacing mov.b by mov

makes the assembler happy.

If alignment in a BSS section (having only .resb/.resw) uses padding then the Low Address is affected.

Example: Low Address should be 0xb000

.msp430
.org 0xa000
blah8:  .resb 1
.align 16
blah16: .resw 1
.org 0xb000
        mov.b   #42,&blah8

0xb000: 0x40f2 mov.b #0x2a, &0xa000                     cycles: 5
0xb002: 0x002a
0xb004: 0xa000

data sections:


Program Info:
                         LABEL ADDRESS  SCOPE
                         blah8 0000a000 0
                        blah16 0000a002 0
 -> Total symbols: 2

Include Paths: .
               /usr/local/share/naken_asm/include
               include
 Instructions: 1
   Code Bytes: 6
   Data Bytes: 0
  Low Address: a001 (40961)
 High Address: b005 (45061)

Hi!

following some code samples which show the problems with PC relative load instructions, I have run into.

Case 1: label is before PC

                    .arm

                    .equ    START           = 0x08000000

                    .org    START

                    B       LOOP

CONST_FOO:          .dl     0x12345678

LOOP:
                    LDR     R4,CONST_FOO

                    B       LOOP

gives this error:

Pass 1...
Error: Offset out of range (0,4095) at src/foo.asm:12
Pass 2...
Error: Offset out of range (0,4095) at src/foo.asm:12

Case 2: Label is after PC

                    .arm

                    .equ    START           = 0x08000000

                    .org    START

LOOP:
                    LDR     R4,CONST_FOO

                    B       LOOP

CONST_FOO:          .dl     0x12345678

gives this error:

Pass 1...
Error: Unexpected token 'CONST_FOO' at src/foo.asm:8
** Errors... bailing out

When a preprocessor conditional is nested inside another, the .endif directives are not correctly matched. As an example,

.define FOO 0
.if FOO
.if BAR
.endif
.endif

fails with Error: unmatched #endif at filename:0

It seems that, since the contents of the if block are not to be included, they are not parsed to match up inner endifs, and so the second endif is seen as extraneous. The same problem occurs with .ifdef, and with nesting inside an else block that is not to be included.

Two issues I came across using naken_util.

1. b/wprint don't consider end range, they always print 128 bytes.
   Looks like a bug in naken_util.c

336:  if (start <= end) { end = start + 128; }
376:  if (start <= end) { end = start + 128; }

2. clear gives a strange response.

stopped> clear z
Flag r z set. 

Bug on line 1205 in naken_util.c

offending code:

   .z80                                                                                                                                               
                                                                                                                                                      
   .macro BLAH                                                                                                                                        
   ld a, 0xff                                                                                                                                         
   .endm                                                                                                                                              
                                                                                                                                                      
   ld a, 0xff                                                                                                                                         
   ld (0xce00), a                                                                                                                                    
loop:                                                                                                                                                 
   jp loop 

build command:
naken_asm -b red.asm -o red.bin

output:

 Athors: Michael Kohn
         Joe Davisson
    CPU: MSP430, MSP430X, 6502, 65816, 6809, 68HC08, 68000, 8051,
         ARM, AVR8, dsPIC, Emotion Engine, MIPS, PIC32, Propeller,
         STM8, THUMB, TMS1000, TMS1100, TMS9900, Z80
    Web: http://www.mikekohn.net/
  Email: [email protected]
Version: January 22, 2017

 Input file: red.asm
Output file: red.bin

Pass 1...
Internal error: macro longer than 1024 bytes on line 960
** Errors... bailing out

Program Info:
Include Paths: .
               /usr/local/share/naken_asm/include
 Instructions: 0
   Code Bytes: 0
   Data Bytes: 0
  Low Address: fffffffe (-2)
 High Address: 0000 (0)

*** Failed ***

I saw this problem with b3aaff8. Removing the macro block fixes compilation. I expected this code to work. I've attempted to paste in your example macros and they also cause the same problem.

Hi.
I have some trouble generating include for msp430fr5969 using latest gcc msp430 include. There is no register addresses in the output (no wdtctl, padir etc).

Any suggestions?

Perhaps I should fix script with some python magic.

Hi!

This issue describes a situation where trying to disassemble the following source code loaded at address 0x08000000 generates a segmentation fault.

Source code:

                    .arm

                    .equ    START           = 0x08000000

                    .org    START

                    B       LOOP

CONST_FOO:          .dl     0x12345678

LOOP:
                    LDR     R4,CONST_FOO

                    B       LOOP

Build command:

naken_asm -bin foo1.asm -o foo1.bin

Trying to dissassemble

$ naken_util -arm -bin -address 0x8000000 -set_pc 0x8000000 foo1.bin 

naken_util - by Michael Kohn
                Joe Davisson
    Web: http://www.mikekohn.net/
  Email: [email protected]

Version: January 26, 2019

Loaded bin foo1.bin from 0x8000000 to 0x800000f
Type help for a list of commands.
stopped> disasm

Addr    Opcode    Instruction                              Cycles
------- --------  ----------------------------------       ------
Vectors:
Segmentation fault: 11

Regards!

Hi
I'm writing new 6502 program and i need to see RAM changes while program running. Stopping and printing RAM is not efficient. While playing with naken_util I see dumpram option but it is not implemented in 6502 simulation. I've imlemented it but it is not working like what I expected. I thought it's dumping RAM during simulation running. So I wrote some changes and now I'm calling simulate_dumpram function in simulate_run. Here is what it looks like

I can make PR if anyone want to see how I implemented it. I will like to see suggestions of implementation also.

When adding data with a directive such as .db or .dw, the argument is not bounds-checked, so for example .db 0x1234 results in an output byte of 0x34 without any warning as to the truncation.

May I suggest you add PDP-8 to your set of assemblers and disassemblers? It's a very simple instruction set, so it should be easy. The instructions are 12 bits, like the baseline PIC processors.

Documentation:
https://github.com/awesome-cpus/pdp8/
http://homepage.divms.uiowa.edu/~jones/pdp8/man/

Hi, after playing around with the STM8 core recently, I stumbled over an issue with the LDF instruction.

It seems that the assembler truncates addresses below $100 and then accuses illegal addressing mode.

LDF ([$0010.e],X),A ; does not work
LDF ([$0100.e],X),A ; does work

I think the first variant should be valid too and generating the corresponding opcodes manually via the .db directive the instruction executes fine on the real device.

Regards.

The functions for reading and writing ELF files do not generate or recognize the machine number for several of the supported architectures. The latest version of the gABI spec defines machine numbers for the STM8 (186), the 68k (4), the 68HC08 (71), the 8051 (165), the PowerPC (20), and the Z80 (220) architectures, among others.

The assembler currently fails to understand instructions that use indexed or indirect addressing modes with a label that is yet to be defined. For example,

.stm8
.org 0
ld a, (test, x)
test: .ds8 1

fails with

Error: Unknown operands combo for 'ld' at filename:3.

while moving the label definition before the instruction avoids this:

.stm8
.org 0
test: .ds8 1
ld a, (test, x)

succeeds. In indirect addressing modes, it fails at the parsing stage:

.stm8
.org 0
ld a, ([test], x)
test: .ds 1

fails with

Error: Unexpected token ',' at filename:3

This is specific to a subset of addressing modes (I have not tested all of them), as

.stm8
.org 0
ld a, test
test: .ds8 1

assembles (though see issue #4).

If a mov instruction needs to use the long addressing mode, its length will change, but this mistakenly does not update label addresses. For example,

.stm8
.org 0x100
mov test, test
test: .ds8 1

produces the listing

0x0100: 55 01 03 01 03 mov $103, $103

when it should produce

0x0100: 55 01 05 01 05 mov $105, $105

since the mov instruction is now 5 bytes long.

Hi,
I'm trying to assemble something like

.macro(usec)
MOV #(((usec * MCLK) -2) /3),X
.endm

When I use this I get a

Error: No matching ')' at ../foobar.asm:xx

Any way to work around this?

Hi!

I started to play around with the '.arm' assembler and stumbled over this issue, where I get an error every time I use a forward branch to a label.

Example:

                    .arm

                    .equ    START           = 0x08000000

                    .org    START

                    BAL     FOO             ; branch forward causes error
                    MOV     R0,R0
FOO:

Version: July 1, 2018

Regards.

Many of the STM8 instructions have different forms for one-byte and two-byte addresses, and the one-byte form is preferable for space efficiency whenever possible. However, when an address argument depends on a label that has not yet been defined, the assembler currently always chooses the long form, even when the argument could fit in a byte. I have checked that this occurs with mov, ld, ldw, and neg, so it probably applies to most instructions. Here is an example:

.stm8
.org 0x00
ld a, test
test: .ds8 1

produces

0x0000: c6 00 03  ld A, $3
0003: 00

when it would be better to produce

0x0000: b6 02  ld A, $02
0002: 00

It seems that this issue is partly caused by the fix to issue #3, as prior to that mov would attempt to use the short form.

Hi!

the following lines show some examples of the usage of the EQU pseudo instruction. It happens that the implementation in naken_asm does not support the terminating colon in the label name for this instruction. Also seems that the directive notation ".equ" is not supported at all. Maybe this is a documentation glitch and it isn't to be used this way at all.

Terminating the labels with a colon certainly is a matter of preference. I use it a lot in PIC programming, since labels terminated with colon are rendered bold in the source code editor, which helps a lot.

Since colons are supported for the other directives, I think it wouldn't hurt to make it work with EQU too.

                .65816

FOO1:           equ    %00001111       ; fails to compile
FOO2            equ    %11110000       ; compiles
FOO3:           .db    1, 2, 3         ; compiles
FOO4            .equ    %11110000      ; fails to compile (listed in directives)

Regards.

The contents of files included with .include "filename.s" are not shown anywhere in the .lst listing file. Any data they declare shows up in data sections: at the end, but the source and the assembled machine code are not present in the listing. It would be good if the .include directive in the listing file was immediately followed by a listing of the included file's contents (perhaps with some comments marking the beginning and ending), just as if the main file contained all included source. (Alternately, each included file could generate a separate listing file, but this seems less convenient.)

The current version generates this error in Pass 1

Error: Unknown operands combo for 'BMI' at ...

Code snippet:

                    .thumb
                    .align  32
UNSUPPORTED:        .scope

                    CMP     R1,#32
                    BMI     CONTROL
CONTROL:
                    .ends

BTW Previous version of naken_asm assembles without error.

Hi!

I wanted to set the carry flag and accordingly to the programing manual this is done by using the MSR and MRS instructions, which the assembler fails to recognize.

        MSR R0,APSR        ; copy APSR (application program status register) into R2
        ...
        MRS APSR,R0        ; copy R2 back into APSR

Regards.

Some OP_ADDRESS8 instructions with 0x00 address which writes back to memory are crashing simulator. In this case these instructions are:

ASR, ROL, LSR, ROR, STY, STA, STX, DEC and INC

This problem only occurs when simulator started without -run argument. When -run used executing done succesfully (cycle count is right). Removing -break_io code from WRITE_RAM macro is resolved problem but I can't find another solution.

This code:

                    .thumb
                    .align  32
UNSUPPORTED:        .scope

                    CMP     R1,#32
                    BMI     CONTROL
CONTROL:
                    .ends

Gives error:

Error: Unknown operands combo for 'BMI' at ...

When issuing one of the directives .big_endian or .little_endian, the assembler fails with, for example,

Error: Unknown directive 'big_endian' at filename:lineno.

This is because the conditionals in check_for_directive for these two directives do not return 1, but fall through to return 0, indicating no directive matched.

I also note that the default endianness specified for STM8 is incorrect: it is actually a big-endian processor.

This is a serious problem, as it means any word-length data or addresses stored will be loaded in backwards.

The support for the STM8 MCU only includes the assembler and disassembler. This issue is for adding STM8 simulator support as well.

Hi!

the current version of the THUMB assembler doesn't accept 'S' flavors of some instructions.

One critical usage, is the MOVS instruction to return from an interrupt routine. Maybe there is a workaround though which I weren't able to find out.

                    MOVS    PC,LR

Cross-checking with documentation I figured out that none of these variants are accepted:

                    MOVS    PC,LR
                    MVNS    R1,R2

                    ADCS    R1,R2
                    ADDS    R1,R2
                    SBCS    R1,R2
                    SUBS    R1,R2
                    ANDS    R1,R2
                    BICS    R1,R2
                    EORS    R1,R2
                    MULS    R1,R2
                    ORNS    R1,R2
                    ORRS    R1,R2

                    ADCS    R1,R2,R3
                    ADDS    R1,R2,R3
                    SBCS    R1,R2,R3
                    SUBS    R1,R2,R3
                    ANDS    R1,R2,R3
                    BICS    R1,R2,R3
                    EORS    R1,R2,R3
                    MULS    R1,R2,R3
                    ORNS    R1,R2,R3
                    ORRS    R1,R2,R3

The special case of indirect addressing with zero base should be converted to simple register indirect addressing.
This reduces both code and execution time.

Example: these two operations are equivalent, both should result in one word of code (0x482e).

    mov 0(r8),r14

0x0104: 0x481e mov.w 0(r8), r14                         cycles: 3
0x0106: 0x0000


    mov @r8,r14

0x0108: 0x482e mov.w @r8, r14                           cycles: 2

Given this code:

loop: jmp loop

Assembling by hand:

• jmp gives 3Cxx (according to slau144j, page 62)
• loop gives -1 (jump back 1 word)
• combining 3Cxx and 9 bits from -1 gives 3DFF

Assembling with naken_asm:

• gives 3FFF [1]

Who is wrong?

[1] The full Intel HEX is:

:02000000FF3FC0
:00000001FF

EDIT:

• changed label from l to loop to avoid similarity with digit 1
• added page number for slau144j
• slightly improved layout and markup

Hello there,

I'm playing around with the simulator (just trying to learn msp430 assembly for the third time here), and it stroke me that it'd be very useful for novices to be able to experiment with new expressions during a simulation. The simulator would stop executing the current program, assemble and execute the new expressions, without incrementing PC (unless instructed by the new expressions).

This new feature would serve two purposes:

1. allows experimenting with instructions without writing whole programs for it
2. enables easier debugging since instructions can be added on the fly

How do I go about implementing this feature? Any assistance (since I haven't looked very deep into the codebase) would be very much appreciated.

xkxx

Currently, both standard messages (such as version info, include paths, and code size) and error and warning messages are printed to stdout. It would be convenient if the errors and warnings were printed to stderr instead, so that one could suppress stdout (i.e. > /dev/null) to make it easier to see whether assembly had succeeded and what had gone wrong. Alternately, a command line "quiet" option could be added, that would suppress all messages except errors and warnings internally.

Following a macro declaration, line numbers reported in error messages will be one less than correct (cumulative with the number of declarations). For example,

.macro test
.endm

error

will produce the error message

Error: Unknown instruction 'error' at filename:3

despite error being on line 4. This does not depend on the contents of the macro.

Oops ... hit the enter key before closing the quote ;-)

        .ascii   "This is a long "
        .ascii   "text broken into "
        .ascii   "lines\0"

When printed the string becomes ...

This is a long text broken into lines0

I know there is the .asciiz directive too ... but for sake of consistency, I think decoding the '\0' wouldn't hurt.

Regards.

Hello,

The STM8 disassembler produces peculiar results when presented with undefined instructions:

05 9d          ???
0b 9d          ???
71 9d          ???
72 9d 9d       ???
75 9d          ???
90 9d 9d       ???
91 9d 9d       ???
92 9d 9d       ???

I don't see why 05, 0B, 71, and 75 should be two-byte instructions. Or why the prefixed instructions are three bytes in length.

One gets a somewhat cryptic message. Possibly a typo in common/naken_asm.c line 218. (1 --> i)
Maybe an error saying "wrong option" would be even better.

btw: any chance to get long options with double dash? just a wish.

$ naken_asm x.asm -l -dump

naken_asm

Authors: Michael Kohn
         Joe Davisson
    CPU: 4004, 6502, 65816, 6809, 68HC08, 68000, 8051, ARM, AVR8
         Cell BE, dsPIC, Epiphany, LC-3, MIPS, MSP430, PIC14, PIC24,
         PIC32, Playstation 2 EE, PowerPC, Propeller, RISC-V,
         STM8, SuperFX, THUMB, TMS1000, TMS1100, TMS9900, Z80
    Web: http://www.mikekohn.net/
  Email: [email protected]
Version: October 13, 2017

Error: Cannot use x.asm as input file since x.asm was already chosen.  <<<<<<

The "configure" file is missing a line to include the STM8 simulator at around line 429.

Hi!

When trying to transfer one register into another via the MOV instruction, the assembler complains giving this error:

Error: Unknown operands combo for 'MOV' at src/main.asm:211

where the corresponding source code looks like this:

                    MOV     R2,R1

BTW Currently I am using PUSH/POP instruction to get around this issue.

Regards.

When running in the 6502 simulator, the disassembled output looks strange. The current instruction looks fine, but subsequent instructions are disassembled at the wrong location, so looks like garbage.

 ! 0x1000: ldx #0xff                                0-0
   0x1002: 0x009a
   0x1003: ldx #0x10                                0-0
   0x1005: 0x004c
   0x1006: bbr3 0x13, 0xfd2 (offset=-54)            0-0
   0x1009: 0x00b5
   0x100b: 0x0095

Simulation Register Dump                               Stack
------------------------------------------------------------
        7 6 5 4 3 2 1 0                          0x1ff: 0x00
Status: N V - B D I Z C                          0x1fe: 0x00
        1 0 0 0 0 0 0 0                          0x1fd: 0x00
                                                 0x1fc: 0x00
  A=0x00   X=0xff   Y=0x00                       0x1fb: 0x00
 SR=0x80  SP=0xff  PC=0x1003                     0x1fa: 0x00


0 clock cycles have passed since last reset.

 ! 0x1002: txs                                      0-0
 > 0x1003: ldx #0x10                                0-0
   0x1005: 0x004c
   0x1006: bbr3 0x13, 0xfd2 (offset=-54)            0-0
   0x1009: 0x00b5
   0x100b: 0x0095

Simulation Register Dump                               Stack
------------------------------------------------------------
        7 6 5 4 3 2 1 0                          0x1ff: 0x00
Status: N V - B D I Z C                          0x1fe: 0x00
        0 0 0 0 0 0 0 0                          0x1fd: 0x00
                                                 0x1fc: 0x00
  A=0x00   X=0x10   Y=0x00                       0x1fb: 0x00
 SR=0x00  SP=0xff  PC=0x1005                     0x1fa: 0x00


0 clock cycles have passed since last reset.

 ! 0x1003: ldx #0x10                                0-0
   0x1005: 0x004c
   0x1006: bbr3 0x13, 0xfd2 (offset=-54)            0-0
   0x1009: 0x00b5
   0x100b: 0x0095
   0x100c: beq 0x10c3 (offset=-75)                  0-1
   0x100e: 0x00e1

Simulation Register Dump                               Stack
------------------------------------------------------------
        7 6 5 4 3 2 1 0                          0x1ff: 0x00
Status: N V - B D I Z C                          0x1fe: 0x00
        0 0 0 0 0 0 0 0                          0x1fd: 0x00
                                                 0x1fc: 0x00
  A=0x00   X=0x10   Y=0x00                       0x1fb: 0x00
 SR=0x00  SP=0xff  PC=0x133f                     0x1fa: 0x00


0 clock cycles have passed since last reset.

 ! 0x1005: jmp 0x133f                               0-0
   0x1008: 0x00ca

Code:

                    .thumb
                    .align  32
UNSUPPORTED:        .scope

                    CMP     R1,#32
                    BMI     CONTROL
CONTROL:
                    .ends

Gives error:

Error: Unknown operands combo for 'BMI' at ...

Hi,

The disassembly for PUSHM generates the wrong size (.W or .A). It seems the opcode bit value for the size for PUSHM is inverted from all the other opcodes (based on the table on page 162 of SLAU144J). I think you need to change disasm/disasm_msp430.c line 663 from "wa=(opcode>>8)&0x1;" to "wa=((opcode>>8)&0x1)^0x1;".

There also appears to be a corresponding error in the assembler. In file "asm/asm_msp430.c" you need to change line 1131 from "int al=(size==20)?1:0;" to "int al=(size==16)?1:0;"

Apologies for not submitting a proper patch, git access is blocked from work.

When "naken_util -run out.hex" encounters an illegal instruction the exit code is still 0. I think it should be not 0. This would be useful for automated testing.

I hoped to fix it by checking the return value of the simulation, but simulate_dump_registers_<arch> (which in turn calls simulate->context) does return void.

Hej!

I'm using your MSP430 simulator to test a compiler. I compile and run a test program. If a bad condition is detected, a special routine is called which is supposed to halt and signal failure. If the test runs to completion, another routine is called to signal success.

Some processors have special ILLEGAL, HALT, or BREAK instructions which I sometimes use for this. I didn't find any for the MSP430, so I used the illegal opcodes 0000 for success and 0001 for failure which at least makes the simulator halt.

Would it possible to have the simulator detect success/failure for this use case, and exit with a corresponding code?

The only unary operator present, ~, for bitwise complement, does not function correctly. As a minimal example,
.db ~1
should produce 0xfe as output but instead produces 0xff, as it does with any number following the tilde.

To take the complement currently requires treating bitwise complement as a binary operator that ignores its second argument, as in
.db 1~0
which produces 0xfe, with the 0 ignored.

Internally, OPER_NOT takes two arguments from the stack and pushes the bitwise complement of the first argument. Since the stack is initialized to contain a zero, giving only the second argument results in an output of the bitwise complement of zero, 0xff.

At a minimum, OPER_NOT should push the bitwise complement of its second argument rather than its first, so that a bare ~1 will function correctly. Much better would be proper handling of unary operators, so they only pop the single argument used.

Also, note that the expression -1 relies on the initialization of the stack to contain zero, since there is no unary negation operator and the - is treated as subtraction. A complete fix would allow - to be parsed as either binary (OPER_MINUS) or unary (OPER_NEGATE, perhaps?) depending on context.

Hi Mike,

calling a non existing label in naken_util seems to call 0.

Steps to reproduce:

Generate input:

$ cat > test.s43
zero:
	mov #0, r12
	ret

one:
	mov #1, r12
	ret

$ naken_asm test.s43

$ naken_util out.hex
set r12=0xffff
call nosuchfunc

R12 is zero now. I think there should some kind of warning.

Here's the probably the place where the simulation gets invoked:
https://github.com/mikeakohn/naken_asm/blob/master/simulate/msp430.c#L428

Within an assembly function, there are often many internal jumps for conditionals and loops. The labels for these jumps do not need to be visible outside the scope of the function. It would be good to have some form of local label, which is only visible within some context, and which does not need a globally unique name.

Usually, some feature of the symbol name distinguishes local from global labels: some assemblers have local labels as those that begin with a ., some those that begin with a digit, and some those that end with a $. My personal preference is for labels beginning with _ to be considered local.

There are also a few ways to define the context for a local label: some assemblers consider the context to be the area between two non-local labels, some require explicit directives to specify the area, and some require specifying when using the label whether to search forward or backward.

While of course it is easy to fake having local labels—say, by prepending an underscore and the function name—it makes for slower-to-type and harder-to-maintain code than does proper support.

Thoughts on usefulness or on specifics of syntax and semantics?

Since I'm also in the toolchain business, I'm curious. Do you have a strategy for adding targets? Do you have some sense which of processors are most popular?