dmcoles / evo Goto Github PK

When generating code for the CLR opcode using a data register operand, there is a microcode bug in the 68000 CPU that can crash the system. If it hasn't been fixed already, the CLR.W D0 opcode should be implemented as EOR.W D0,D0. It's a drop-in substitute for all sizes.

When trying to compile EEC on MorphOS, I ran into a function called IeeeDPFieee used to convert single precision to double. It didn't compile correctly with E-VO v3.6.0 because I listed it in ShowModule as IeEEDPFieee. The third and fourth character of all of the calls in the library need to be lowercase. Could this have something to do with the FD files for OS3.x not matching?

http://aminet.net/package/dev/e/Gels020 corrects this on 020+. Please include. (I am the author of the package listed above.)

there is Eval already, but no 'Read' that could turn a string into code.
A REPL should allow to dynamically load modules.

The beginners guide by Jason Hulance mentioned in E-VO.guide is not in the docs folder

Sorry to spam the ticket reporting system.
I don't really know where to discuss AmigaE coding. So please let me know where is a better place (anyone reading here, maybe open Discussions?).

I've again played a bit with AmigaE lately and thought I'd add some higher-level functions/PROCs, i.e. for 'reduce/fold'.

What I came up with is this:

EXPORT PROC reduce(lst, initialValue, fun)
    DEF accu, it, tmp, len, i
    len := ListLen(lst)
    accu := initialValue
    FOR i := 0 TO len-1
        it := ListItem(lst, i)
        tmp := accu
        accu := Eval(fun)
    ENDFOR
ENDPROC accu

Called like so using a quoted expression:

    DEF result, accu, it
    result := reduce([1,2,3,4,5], 0, `accu+it)
    PrintF('reduce result: \d\n', result)
    assertTrue(result = 15, 'Is not 15')

In the reduce function the tmp := accu is necessary, otherwise it won't work. But I do not understand why. Can someone shed some light?

I've also seen some built-in function like MapList use a variable pointer ({x}), but I'm not sure how this is used in the implementation and why is it needed.
My variant works with convention that accu and it must be used.

EEC-Developers/eec#25 describes an optimization where the first pass of the compiler could keep track of which registers are used by a function and save only the non-scratch members of the register list to the stack in the function preamble and restore the same list at the end. Since it's 68k series only, I thought I'd mention it here also.

In a future release could there be a separate assign other than emodules: for debug mode? I find myself having to put debug modules in the place of release mode compiles when tinkering with the module framework.

https://github.com/dmcoles/EVO/wiki/2.-The-Distribution

Mentions a Bin and Doc folder but the download doesn't contain these.

I tried to implement file logging with the following:

-> Globals are prefixed with g_ and defined here
DEF g_idcmp, g_scrn, g_wndw

#ifdef DEBUG
DEF g_log
PROC trace(msg,var=NIL)
    IF var
        VfPrintf(g_log,msg,var)
    ELSE
        Fputs(g_log,msg)
    ENDIF
    Flush(g_log)
ENDPROC
#else
PROC trace(msg,var=NIL) IS RETURN
#endif

PROC main()
#ifdef DEBUG
    g_log:=Open('file.log',MODE_NEWFILE)
#endif
    trace('hello log!\n')
#ifdef DEBUG
    Close(g_log)
#endif
ENDPROC

When compiled with DEBUG not defined, the compiler complains about the preprocessor directive being in the Global scope.

Yet on the unit test it seems to work. All that's in the module is a single function and an enum definition. There is a possibility that loading a module from in another module might be the culprit. The sources are in the EEC Framework project. The module it is being loaded from is not uploaded yet.