theandrew168 / bronzebeard Goto Github PK

sw ra,(sp)
AssemblerError: invalid syntax in expr: "sp )"

lhu a2,(a0)
AssemblerError: invalid syntax in expr: "a0 )"

both work with a leading 0 such as in sw ra, 0(sp)

version 0.15 doesnt like numbers given in 0x?? as third operand it seems:
AssemblerError: register must be a valid integer, name, or alias: 0xa
slli a4,a4,0xa

Hi Andrew,

I updated my local git repo and rebuilt the latest version, then used it to compile a previously compiled program and the md5 checksum is identical to the last built version from February (and the build is still super fast).

So awesome, thank you for this tool.

The assembler already supports the --verbose flag but it doesn't really do much. What sort of debug output would be useful here?

Dear Sir,
Is there a possibility of adding CSR privileged instructions to Bronzebeard such as CSRRW, CSRRS, and CSRRC without which interrupt enabling seems impossible.
Regards
Sajeev

I came across an interesting package called (tqdm)[https://github.com/noamraph/tqdm] whilst reading fluent python and thought it might be a solid addition to the assembler when compiling larger programs.

Let me know what you think, and if Interested I can get a PR going.

The version 0.15 bails out on:
lui a4,0xfffff
with the message:
AssemblerError: 20-bit immediate must be between -0x80000 (-524288) and 0x7ffff (524287): 1048575

If src and dst are both not x0 then C.MV can always be used instead of ADDI.

AssemblerError: invalid syntax in expr: "4 0xb1 0x05 0x3a 0x3a"
line 425: db 4, 0xb1, 0x05, 0x3a, 0x3a

"bytes 4, 0xb1, 0x05, 0x3a, 0x3a", however, works.

The processing for the include directive is performed before lexical analysis, and thus before comment removal, so any in-line comments on the same line as an include directive will be treated as part of the filename and cause a confusing error message.

In this special case, in-line comments need to be removed before the include directive is processed

Hi @theandrew168 ,

Would it be possible to add support for writing basic macros in the assembly programs? I wanted to see how derzforth would change in size if I inlined all the j next instructions.

For the moment my hack in derzforth.asm is to replace <4 spaces>j next with include next.asm, which contains:

# standard forth routine: next "macro"
    lw W, 0(IP)     # W <- [IP]
    addi IP, IP, 4  # IP += 4
    lw t0, 0(W)     # t0 <- [W]
    jr t0

The binary size increased by exactly 200 bytes, which I think is worth it for the performance gain.

Either way, I think it would be interesting to have a real macro syntax or something similar to what GAS and NASM provide... doesn't have to be as complex/powerful though. What do you think?

I love the minimal no-nonsense approach of this project (which I found when looking for a Risc-V assembler FORTH and finding Derzforth) and it seems a great fit for embedded development on small Risc-V microcontrollers. There are now some interesting, and very low cost, Risc-V chips and development boards available which use the RV32EC configuration (rather than the fuller RV32IMAC) such as the CH32V003 "ten cent" chip which has caught a lot of media attention. I would love to be able to use bronzebeard to develop software for these as well as the more expensive Longan and SiFive boards which you support.

Would you consider adding RV32EC support in bronzebeard?

Hi sir,
I am using windows OS. I installed bronzebeard and it assembles properly the Longan nano example and outputs a bb.out file . I tried to install zadig but the longan nano cannot be programmed from windows. Later I tried with a VM ubuntu installation and the programming was successful. Is it possible that bronzebeard can output a .HEX format file so that it can be uploaded by the programming software provided by sipeed. The sipeed program software accepts .hex and .bin as inputs. bb.out is not recognized.
I am a novice (hobbyist) and started studying RISCV and have no exposure to any other language than AVR assembly . If bronzebeard can output these formats then it would be easy to program from windows10 with sipeed software (GD32 MCU dfu tool_v3.8.1.5784)without the hassle of running a linuxVM which is very cubersome with 20gb space lost. It would be so kind of you if this option can be enabled.
Regards
Sajeev

The current design of running multiple passes over the instructions is a bit too cute. I think it'd make more sense to let the lexing / parsing phase be distinct from how labels / vars get resolved and how instructions get encoded down into bytes.

It could be cleaner to whip up a few descriptors for each instruction component / field. Each descriptor should validate the input when written and present the split / shifted encoding when read. Then, each instruction type is just a collection of these descriptors and their values can be or'd together to create the final instruction.

Also, I'm considering a rewriting the project in Go. I've been using it for my other recent projects and I've gotten used to the safety and confidence that its static typing provides. It frustrates me more than it used to when a syntax error only shows itself upon execution (or a missing import, a missing param, etc). The assembler itself wouldn't be very difficult (its just data in, data out). The fussy part would be the simple DFU implementation that I built for flashing the GD32 devices.

From what I've researched on USB programming in Go, it isn't pretty. On *nix platforms, it's the standard fair: make sure libusb is installed and cgo will take the wheel (the gousb module comes into play here). On Windows, though... big RIP. The docs are slim, the maintainer(s) don't seem very helpful, and it requires GCC to be installed. I looked at some other WinUSB based modules but nothing seemed very trustworthy (at this point).

However, the GD32 devices have a 2nd method of flashing new firmware: the STM32 loader. From what I can tell, this is a very common serial-based mechanism that can be used to program the STM32 family of devices and any other that implements the protocol. There is a python library for this process and I've tested it on the Longan Nano (seemed to work fine). The benefit of this method from a Go perspective is that it doesn't require fussing with USB! It only requires a serial connection.

As it turns out, dealing with serial devices is much more straightforward than USB on all platforms. Here is an existing library that does it. On *nix, you can read / write a device through the regular file API. Config options are handled with IOCTL calls (which Go supports via the syscall and unix modules). On Windows, serial devices can be accessed by means of a small set of functions within the winbase.h API. These functions are located in kernel32 and can dynamically loaded / called using the syscall library).

Sure, the syscall and unsafe modules have their downsides and risks. But I'd take them over cgo anyday! Not having to fuss with C compilers everywhere is a win. Anyway, if I can write a simple and clean STM32 loader in Go that works on all major platforms (Windows, macOS, Linux), I'll plan on continuing with the rewrite. There would be a lot of tests to convert to Go but... price of progress, I guess?

li a4,4
gets assembled into
lui x14,0x0
addi x14, x14, 4
instead of
addi x14, zero,4

So it should check for signed 12bit range and omit the lui if not required.

Add some documentation that explains how to use the assembler, what the flags do, and when one should use them.

Now that the IMAC extensions are complete, how they can be utilized to add value to the assembler? It'd be nice to have a flag that automatically checks instructions for compressibility and does the conversion. It might also be possible to notify the dev of situations where an instruction is close to being compressible and what they'd need to change to get it there.

This simple code part raises an error when assembled with --compress:

li a6, gfx_data

AssemblerError: constraint failed: imm must not be 0

According to the specs, c.lui must indeed not be zero as also reflected in bronzebeard/asm.py:
C_LUI = partial(ciu_type, opcode=0b01, funct3=0b011, cs=[RegRdRs1NotZero, RegRdRs1NotTwo, ImmNotZero])
However, the assembler should fall back to normal non-compressed format rather than bailing out here.

Currently, all of the project docs live in the main README / docs directory. I'd like to setup something a bit nicer (maybe host them on readthedocs?). Look into getting started with that and make it clean.