current JS version definitely does not have this problem.

can't say about Kotlin or Java one way or the other.

Hellfingers: no, your code is wrong. You're only checking if the boss's happiness is <= 5 or not, and that's not what you should be doing at all.

The java problem still has the same error

It looks that kotlin version works fine. If you still have an issue then check your coding once again or post your issue over github codewars help forum so we can try to help you;p

same with js

Same issue with the java random tests.

I'm having issues with random tests too :/
Is it an error in the exercise?

Done. Many thanks for finding that error.

(possibly a next function label).

unless the code isn't correctly written, all proc will end with a ret command. But yes. ;)

You need to mimic plain recursive calls. Meaning that when the first ret is executed, you go back to the last call proc_func statement executed. Meaning, in that routine, you continue to read the commands after the call, then you end up on the ret inside the continue: routine label, which sents you to the previous call proc_func statement executed, and again, and again, ... until you finally ret from the first call of the routine and go back to the 5th line of the script, then print the result, then end the program.

Meaning, you need to see those two routines as one single block:

proc_func:
    cmp   d, 1
    je    continue
    mul   c, a
    dec   d
    call  proc_func
continue:
    ret

equivalent to:

proc_func:
    cmp   d, 1
    je    ret
    mul   c, a
    dec   d
    call  proc_func
    ret

EDIT: note the difference in the names: one is called proc_..., meaning it will be "called" while the other is just a label used to mimic a GOTO statement.

The expected behaviour of the program could be should have been accomplished by adding a ret command after call to proc_func

True. But for the purposes of this kata it seems entering another function (by parsing the commands sequentially), and calling ret inside that other function is deemed the same as calling a non-existant ret command inside proc_func. At least, such logic lines up with the way this test case is structured.

ok, went to it with a brain in better shape than last time... x)

This:

proc_func:
    cmp   d, 1
    je    continue
    mul   c, a
    dec   d
    call  proc_func

continue:
    ret

is actually equivalent to this:

proc_func:
    cmp   d, 1
    je    ret
    mul   c, a
    dec   d
    call  proc_func

and you have to keep track of the different levels of the calls to interpret that correctly.

all routines will always have a ret command somewhere (sometimes, the ret of one called routine is the one of another routine that you reach using a jump command instead of a call one, as in the present case), so you have to go back to the location of the previous call command.

EDIT: keep in mind that all registers are global variables, here.

As I understood that case, after you return inside continue: ret to the call proc_func (line 14), you will keep moving forward line-by-line and run into the continue: ret on lines 16-17 again and again. This way ret operation will be called enough times to return you back to line 5, and you should proceed to the end operation normally.

With what language version do you have this problem?

mmmmh... Correct, I had it wrong (did that one a fair amont of time ago, sorry...).

I don't have time right now to investigate further, sorry.