uLisp RISC 3.5 assembler crash



I’m trying the assembler after the new update.
I have a weird crash after I try to use a defcode (I tried both examples, with and without floating-point instructions).
I have no 3.4 copy of the source, so I couldn’t try with the old one.

Any idea what could be the cause?


core dump: misaligned load
Cause 0x0000000000000004, EPC 0x000000008000760e
reg00 = 0x0000000000001388, reg01 = 0x00000000800075ea
reg02 = 0x000000008017d9e0, reg03 = 0x0000000080035f98


Wait, where’s that from? Does the RISC-V environment have a fault handler that dumps register state to UART or something?

I can tell you from experience that at least the SAMD21 and SAMD51 ARMs that uLisp runs on are hilariously easy to lock up completely if you aren’t careful about what memory addresses you try to read. The “misaligned load” message suggests you’re running into something similar.


That error happens as soon as I hit enter after the defcode instruction.

75342> (defcode xx (n)
($li 'a0 3)
core dump: misaligned load
Cause 0x0000000000000004, EPC 0x000000008000760e


I noticed in the latest update, besides other changes, some of the “char” variables became “uint8_t”. Could this change on RISC-V be responsible for the misaligned address in the assembler?


Can you give some more details: what board are you using, what IDE to install uLisp, and what OS platform? I’ve tried the RISC-V assembler recently on a Maixduino board using uLisp 3.5 without problems.

I have no 3.4 copy of the source, so I couldn’t try with the old one.

It’s here:

Older versions

Let me know if that makes any difference.


Thanks, I will check as soon as I am at home.

I was looking also on the new web page you added http://www.ulisp.com/show?2Z88 (Assembler and defcode).
In that page it’s mentioned that MyCode is defined as:


but in the code I see :


I am not sure if this could be another source of issues.




I am using a Maixduino, with Arduino IDE 1.8 under Windows.
I tried assembler with uLisp 3.4 without any problem. This is the first time I’m trying to write assembler code using uLisp 3.5


No, it’s correct. The ARM and RISC-V versions are slightly different.


I’m not able to reproduce the problem on my Maixduino board with uLisp 3.5.

Does this give an error in uLisp 3.5, without the assembler code loaded?

(defcode mul13 (x) #x45b5 #x0533 #x02b5 #x8082)


I found the reason: I added the definitions (taken from your post) using the LispLibrary.h file.
With those ones enabled, I have the crash. I tried both 3.4 and 3.5


That’s interesting behaviour. Which definitions, exactly?


The Common Lisp extensions, Extending uLisp with Common Lisp functions - Using uLisp - uLisp Forum

I load them all, defining the symbol lisplibrary, in the source code.

I’ll try now loading one by one.


Found the reason: a defvar in LispLibrary.h causes crash

I removed eql and third and everything is ok.


A simple way to trigger the error is to evaluate:

(defvar eql eq)
(defcode mul13 (x) #x45b5 #x0533 #x02b5 #x8082)

So far I’ve no idea what’s causing it, but it’s definitely a bug.


I can reduce it further:

(defvar x  1)
(defcode y)

I finally set up a MAiX BiT I’ve had for a while.

I think it has to be something to do with GlobalEnv and what happens when a variable has a non-list value. I can define variables with nil and random lists in there, no problem. But any number, integer or floating point, and it explodes.


I agree, but I’m puzzled about why it only triggers a problem when defcode is called.


OK, I think I’ve found the problem. In defcode I access invalid memory if globals contains a non-list value, such as is created by:

(defvar x 1)

The fix is to replace the line:

if (pair != NULL && car(pair) != var) { // Exclude me if I already exist


if (pair != NULL && car(pair) != var && consp(cdr(pair))) { // Exclude me if I already exist

in two places (search for the comment). This should then work:

(defvar x 1)
(defcode mul13 (x) #x45b5 #x0533 #x02b5 #x8082)

By the way, there’s still a problem with:

(defcode y)

so don’t do that for the time being.

Thanks for reporting it, and the help in tracking it down.


Fixed in RISC-V uLisp Version 3.5a.