16 bit word addressing

[ptilden]

I am building a homebrew 16 bit computer where a memory address refers to a 16 bit word (i.e. the bytes in a word are not individually addressable). Is the any way to configure bespokeasm to do this?

[michaelkamprath]

Yes. You need to create a relevant configuration file.

For 16 bit addressing, set the address_size option to 16. But you probably want to set other options line endian, page_size, etc.

For 16 but words, that's a matter of how your ISA works. You will have to be mindful of things like the size of instruction size and operand size when you are defining your instructions, and their respective endings. But as long as your define it properly, it will work.

[ptilden]

PT16regtest1editlst.txt
PT16regtest1lst.txt
PT16regtest1asm.txt
PT16regyaml.txt

Hi Michael,

Thanks for the update.

I have attached files for where I am currently up to. This is still very much a work in progress. PT16regtest1lst.txt is the output from bespokeasm. PT16regtest1editlst.txt is PT16regtest1lst.txt modified to show the adressing that I want to achieve.

[michaelkamprath]

Oh yeah, I see. It addressing based on 16 bit words. I'll take a look at things likely this weekend. Likely need to add a word size setting (defaulting to 8 bits).

[michaelkamprath]

Got a question here ... how should an ASCII string be laid out for a 16 bit data word? One or two bytes per word?

[ptilden]

Hi Michael, one byte per word would be really good if that is not too difficult to arrange.

[michaelkamprath]

@ptilden I took a look at this over the weekend. I'd need to generalize the concept of "byte code" to be more of "word code" where the word size could be defined (defaulting to 8 bits). While I do see a path to get this done, it won't be a "quick fix".

[ptilden]

Hi Michael, thanks for the update. I will look forward to using it when you get done.

[michaelkamprath]

It's worth mentioning I've made some progress on this (adding support for arbitrary data word sizes). I have the general architecture in place and it's working for 8-bit words. Now to test and debug for other word sizes.

[ptilden]

Hi Michael, thanks for the update. Your efforts on this are appreciated. I will look forward to using it when you get done.

[michaelkamprath]

@ptilden I am getting to the point where I am testing word sizes other than 8-bit. Could you send me the bespokeasm configuration file you were trying to use with some simple same code to compile (for my testing purposes)?

[ptilden]

PT16regtest1.asm.txt
PT16reg.yaml.txt
PT homebrew coumputer ISA 16 reg 3 bus.pdf

Hi Michael,

Here are my test files.

I am using reverse_argument_order: to reverse the order of fields in the instruction but it does not seem to be working.

I have also attached my ISA document so that you can see what I am trying to achieve.

[michaelkamprath]

@ptilden does this output look right to you?

------+------+---------------------+-----------------------+---------
 line | addr |        bytes        | instruction           | comment
------+------+---------------------+-----------------------+---------
    1 | 0000 | 0000                |     nop               | 
    2 | 0001 | 0863 000a           |     ld      r6,r3,abc | 
    3 | 0003 | 1005 000a           |     ldi     r5,abc    | 
    4 | 0005 | 1005 ffff           |     ldi     r5,-1     | 
    5 | 0007 | 0c79                |     ldr     r7,r9     | 
    6 | 0008 | 1443                |     ldis    r1,3      | 
    7 | 0009 | 0000                |     nop               | 
    8 | 000a |                     | abc:                  | 
    8 | 000a | 0061 0062 0063      |     .byte   "abc"     | 
    9 | 000c | 0061 0062 0063 0000 |     .cstr   "abc"     | 

[michaelkamprath]

actually, the address to the .cstr at the end looks wrong. Let me fix that ...

[michaelkamprath]

fixed the addressing bug. here is the updated output. Does this look right to you?

------+------+---------------------+-----------------------+---------
 line | addr |        bytes        | instruction           | comment
------+------+---------------------+-----------------------+---------
    1 | 0000 | 0000                |     nop               | 
    2 | 0001 | 0863 000a           |     ld      r6,r3,abc | 
    3 | 0003 | 1005 000a           |     ldi     r5,abc    | 
    4 | 0005 | 1005 ffff           |     ldi     r5,-1     | 
    5 | 0007 | 0c79                |     ldr     r7,r9     | 
    6 | 0008 | 1443                |     ldis    r1,3      | 
    7 | 0009 | 0000                |     nop               | 
    8 | 000a |                     | abc:                  | 
    8 | 000a | 0061 0062 0063      |     .byte   "abc"     | 
    9 | 000d | 0061 0062 0063 0000 |     .cstr   "abc"     | 

[ptilden]

Hi Michael,

Thanks for the update. The addressing is correct.

In the yaml file I am using reverse_argument_order: in some of the instructions. In the LD and LDR instructions I am wanting to interchange the register fields in the binary output. In the LDIS instruction I am wanting to interchange the register and immediate fields. Am I using reverse_argument_order: correctly or have I missed something?

[michaelkamprath]

yes that's the right way to use the reverse_argument_order option.

[michaelkamprath]

@ptilden Please give the generic-data-word branch of BespokeASM a try. Note you will need to change your YAML file as specified in the CHANGELOG of that branch. For your reference, here is the modified version of the configuration file you sent me:

description: PT 16 reg
general:
  address_size: 16
  word_size: 16
  multi_word_endianness: big
  registers:
    - r0
    - r1
    - r2
    - r3
    - r4
    - r5
    - r6
    - r7
    - r8
    - r9
    - r10
    - r11
    - r12
    - r13
    - r14
    - sp
  origin: 0
  identifier:
    name: PT16reg
    version: "0.1.0"
    extension: asm
  min_version: 0.5.0
operand_sets:
  16_bit_reg:
    operand_values:
      r0_reg:
        type: register
        register: r0
        bytecode:
          value: 0
          size: 4
      r1_reg:
        type: register
        register: r1
        bytecode:
          value: 1
          size: 4
      r2_reg:
        type: register
        register: r2
        bytecode:
          value: 2
          size: 4
      r3_reg:
        type: register
        register: r3
        bytecode:
          value: 3
          size: 4
      r4_reg:
        type: register
        register: r4
        bytecode:
          value: 4
          size: 4
      r5_reg:
        type: register
        register: r5
        bytecode:
          value: 5
          size: 4
      r6_reg:
        type: register
        register: r6
        bytecode:
          value: 6
          size: 4
      r7_reg:
        type: register
        register: r7
        bytecode:
          value: 7
          size: 4
      r8_reg:
        type: register
        register: r8
        bytecode:
          value: 8
          size: 4
      r9_reg:
        type: register
        register: r9
        bytecode:
          value: 9
          size: 4
      r10_reg:
        type: register
        register: r10
        bytecode:
          value: 10
          size: 4
      r11_reg:
        type: register
        register: r11
        bytecode:
          value: 11
          size: 4
      r12_reg:
        type: register
        register: r12
        bytecode:
          value: 12
          size: 4
      r13_reg:
        type: register
        register: r13
        bytecode:
          value: 13
          size: 4
      r14_reg:
        type: register
        register: r14
        bytecode:
          value: 14
          size: 4
      sp_reg:
        type: register
        register: sp
        bytecode:
          value: 15
          size: 4
  uint16_no_bytecode:
    operand_values:
      uint16:
        type: numeric
        argument:
          size: 16
          byte_align: true
          endian: big
  uint6_no_bytecode:
    operand_values:
      uint6:
        type: numeric
        argument:
          size: 6
          byte_align: false
          max: 63
          min: 0
instructions:
  # General
  nop:
    # no operation
    bytecode:
      value: 0
      size: 16
  # Data Transfer
  ld:
    bytecode:
      value: 0x08
      size: 8
    operands:
      count: 3
      operand_sets:
        reverse_argument_order:
        list:
          - 16_bit_reg
          - 16_bit_reg
          - uint16_no_bytecode
  ldi:
    bytecode:
      value: 0x100
      size: 12
    operands:
      count: 2
      operand_sets:
        list:
          - 16_bit_reg
          - uint16_no_bytecode
  ldr:
    bytecode:
      value: 0x0c
      size: 8
    operands:
      count: 2
      operand_sets:
        reverse_argument_order:
        list:
          - 16_bit_reg
          - 16_bit_reg
  ldis:
    bytecode:
      value: 0x5
      size: 6
    operands:
      count: 2
      operand_sets:
        reverse_argument_order:
        list:
          - 16_bit_reg
          - uint6_no_bytecode

[michaelkamprath]

The output listing looks correct for your configuration. What is not lining up with your expectations?

[ptilden]

Hi Michael,

I have reverse_argument_order: true in the definitions of the ld, ldr and ldis instructions. I would have expected the following outputs for these instructions:

ld 0836 000a
ldr 0c97
ldis 1431

Is this the correct directive for changing the output order of instruction fields? Am I using the directive correctly?

[michaelkamprath]

I see. Looks like you want to reverse the order of the byte code pertaining to the operands, not reverse the order of the argument values that get appended as immediate after the instruction byte code. The setting for that is reverse_bytecode_order. See documentation.

[ptilden]

Hi Michael,

That worked, thanks very much. Now I can get busy defining the rest of my instructions.

[michaelkamprath]

Great. I'll merge the PR into the main branch in the next day or so. Got a few more things to wrap up before doing that.

[michaelkamprath]

@ptilden I have merged all the changes necessary to support arbitrary data word sizes, and thus your 16-bit word ISA with the release of v0.5.0 (#38). There are probably many more things I can do to add more robust support here (e.g. configuring how byte-strings are mapped to 16-bit+ words), but I'll leave those to different features. Closing this discussion for not. For any new features, please open a new discussion.