jba

I am testing out what is possible with Nim on a microcontroller and the following example won't compile when --cpu:avr is the flag:

The total command, executed from vim, is !nim c --cpu:avr %

var mySeq = @[1,2,3]

proc main =
  while true:
    discard

Here is the error message:

Hint: system [Processing]
lib/nim/system/alloc.nim(136, 16) Error: type mismatch: got <uint32, int32>
but expected one of:
proc `<=`(x, y: pointer): bool
  first type mismatch at position: 1
  required type: pointer
  but expression 'x' is of type: uint32
proc `<=`(x, y: bool): bool
  first type mismatch at position: 1
  required type: bool
  but expression 'x' is of type: uint32
proc `<=`(x, y: string): bool
  first type mismatch at position: 1
  required type: string
  but expression 'x' is of type: uint32
proc `<=`[Enum: enum](x, y: Enum): bool
  first type mismatch at position: 1
  required type: Enum: enum
  but expression 'x' is of type: uint32
proc `<=`[T: tuple](x, y: T): bool
  first type mismatch at position: 1
  required type: T: tuple
  but expression 'x' is of type: uint32
proc `<=`[T](x, y: ref T): bool
  first type mismatch at position: 1
  required type: ref T
  but expression 'x' is of type: uint32
proc `<=`(x, y: int32): bool
  first type mismatch at position: 1
  required type: int32
  but expression 'x' is of type: uint32
proc `<=`[T: SomeUnsignedInt](x, y: T): bool
  first type mismatch at position: 2
  required type: T: SomeUnsignedInt
  but expression '0x0000FFFF' is of type: int32
proc `<=`(x, y: int): bool
  first type mismatch at position: 1
  required type: int
  but expression 'x' is of type: uint32
proc `<=`[T](x, y: set[T]): bool
  first type mismatch at position: 1
  required type: set[T]
  but expression 'x' is of type: uint32
proc `<=`(x, y: float): bool
  first type mismatch at position: 1
  required type: float
  but expression 'x' is of type: uint32
proc `<=`(x, y: char): bool
  first type mismatch at position: 1
  required type: char
  but expression 'x' is of type: uint32
proc `<=`(x, y: int16): bool
  first type mismatch at position: 1
  required type: int16
  but expression 'x' is of type: uint32
proc `<=`(x, y: int64): bool
  first type mismatch at position: 1
  required type: int64
  but expression 'x' is of type: uint32
proc `<=`(x, y: float32): bool
  first type mismatch at position: 1
  required type: float32
  but expression 'x' is of type: uint32
proc `<=`(x, y: int8): bool
  first type mismatch at position: 1
  required type: int8
  but expression 'x' is of type: uint32

expression: x <= 0x0000FFFF

I looked in alloc.nim and here is the function that fails:

proc msbit(x: uint32): int {.inline.} =
  let a = if x <= 0xff_ff:
            (if x <= 0xff: 0 else: 8)
          else:
            (if x <= 0xff_ff_ff: 16 else: 24)
  result = int(fsLookupTable[byte(x shr a)]) + a

I'm not sure what the issue is here? Why is the 0xFFFF a signed int when --cpu:avr is on but apparently not (because it compiles) when I do it on my PC which is amd64. If the avr type cpu is just low priority and has fallen behind, how can I personally improve that situation?

2018-05-14 19:13:03
compiler/platform.nim contains this line, (name: "avr", intSize: 16, endian: littleEndian, floatSize: 32, bit: 16), and mapping int to a 16bit type is not a smart move. Not sure how to improve that, the memory allocator assumes a 32bit system anyway. No idea why you expect the GC'ed sequence stuff on an AVR either. --cpu:avr is for --os:standalone --gc:none targets.
2018-05-14 19:42:58
jba

Thanks for the reply. I don't know anything about how the compiler works, hence my question. It is quite possible to use 32 bit integers in c on a 16 bit MCU, so it seemed like a limitation that could be circumvented were the will there.

I don't expect anything from something made for me to use for free, without restriction. I'm quite grateful for open source projects like this one.

I personally use these kinds of devices at work every day and so imagined that I could contribute to this area of the compiler if I could find a piece to start with.

2018-05-14 20:44:28