vishapoberon / compiler Goto Github PK

via RETCHK.

compiler should issue a warning.

What is the difference and use of .h and .sym files in voc?
I see many .h files in voc-1.1 directory.
I can generate .sym file using voc -s.
What is the difference between .h file and .sym file?
Do these files have any use for programmer or they are only meant for voc's internal use?

Trying to reproduce the Pascal copytext using J&K Software Tools modules results in the following:

copy.mod compiling copy. Main program. 259 chars.
/tmp/ccsPZDIr.o: In function main': /home/sinuhe/src/obn/copy.c:14: undefined reference toFilters__init'
/home/sinuhe/src/obn/copy.c:17: undefined reference to `Filters_copy'
collect2: error: ld returned 1 exit status
Assemble and link: gcc -fPIC -g -I "/opt/voc/include" copy.c -o copy -L"/opt/voc/lib" -l voc
-- failed: status 0, exitcode 1.
Terminated by Halt(1).

The following code was used:

MODULE Prims; IMPORT ulmIO;
CONST FS* = 1CX; EOF* = 1CX;

PROCEDURE getc*(VAR c: CHAR): CHAR;
VAR ch: CHAR;
BEGIN ulmIO.Read(ch);
IF ~ulmIO.Done THEN c := EOF
ELSE c := ch
END;
RETURN c
END getc;

PROCEDURE putc*(c: CHAR);
BEGIN ulmIO.Write(c)
END putc;

END Prims.

MODULE Filters; IMPORT Prims;

PROCEDURE copy*;
VAR c: CHAR;
BEGIN WHILE (Prims.getc(c) # Prims.EOF) DO Prims.putc(c) END
END copy;

END Filters.

MODULE copy; IMPORT Filters;
BEGIN Filters.copy
END copy.

These were compiled with the following commands, assuming separate files for each module:

voc Prims.mod; voc Filters.mod; voc -m copy.mod

This is on Fedora 24 with GCC 6.1.1.

Is there something I'm doing wrong?

Oddly, a more classic copytext works, as it is essentially the same program:

MODULE copytext; IMPORT ulmIO;
VAR ch: CHAR;

BEGIN ulmIO.Read(ch);
WHILE ulmIO.Done DO
ulmIO.Write(ch); ulmIO.Read(ch);
END
END copytext.

Now in SYSTEM.h these definitions are duplicated (twice-defined):

__LSHR __LSH __ROTL __ROTR

subj

make sure Oberon.Par argument handling works on Unix.

Hi this is not as much of an issue, more of a question or comment. I could not figure out how to make a comment on the Vishap blog or home page. I can't log in to wordpress because there is no "register" feature, to create an account to comment with, that I could find.

You know how C and GoLang have variadic functions (functions with variable arguments) or in the case of freepascal they call them VARARGS. ... With your Vishap compiler tool have you ever come across C functions that have multiple arguments, variable amount, not a fixed number of arguments? Does your compiler have an ability to make variable number of arguments? Or does your compiler have the ability to link to C libraries that use a variable amount of arguments?

http://publications.gbdirect.co.uk/c_book/chapter9/stdarg.html

Similar to standard pascal's WriteLn which allows multiple types:

writeln("string", 6543, float)

WriteLn in freepascal is like a variadic function in GoLang.

Or there is things like Printf and such.

What happens if there is a C dll that has variable amount of args... , can you link to that DLL and use the function in oberon?

This is an incompatibility that exists between C and Oberon, as Wirth is against such "features" in programming languages, even though his WriteLn in standard pascal was basically the same thing (but compiler magic).

For example in Oberon you have to go:
console.WriteString("some string"); console.WriteInt(4634);

Instead of
console.Write("some string", 4634);

Whereas standard pascal and C allowed you to do that, as does GoLang.

So when a C library has variable amounts of arguments how would oberon deal with it?

PROCEDURE Test (v: ARRAY 5 OF REAL); BEGIN END Test;

voc returns:

err 200 not yet implemented

but it is clearly a syntax error.

if Ulm's Coroutines module will be implemented, that would allow to build the rest of Ulm's libraries, like Iterators, etc, which depend on coroutines functionality.

Dear David.

Once you've got rid of alloca in favor of an explicit allocation and deallocation, there was a problem that still doesn't solved, only masked.

    PROCEDURE Prefixed(x: OPT.ConstExt;  y: ARRAY OF CHAR): BOOLEAN;
        VAR i: INTEGER;
    BEGIN i := 0; 
        WHILE x[i+1] = y[i] DO INC(i) END ;
        RETURN y[i] = 0X 
    END Prefixed;

static BOOLEAN OfrontOPC_Prefixed (OfrontOPT_ConstExt x, CHAR *y, LONGINT y__len)
{
    INTEGER i;
    __DUP(y, y__len, CHAR);
    i = 0;
    while ((*x)[__X(i + 1, 256)] == y[__X(i, y__len)]) {
        i += 1;
    }
    __DEL(y);
    return y[__X(i, y__len)] == 0x00;
}

Look at the last line of the C function. Here is the access into the memory which is already disposed. The way of alloca meant empty definition of __DEL(), and everything worked properly. But now __DEL() is

#define __DEL(x) Platform_OSFree((LONGINT)(uintptr_t)x)

So we have to solve this problem somehow. Such a solution, as below, as you have now, I find unsatisfactory.

    PROCEDURE Prefixed(x: OPT.ConstExt;  y: ARRAY OF CHAR): BOOLEAN;
        VAR i: INTEGER;  r: BOOLEAN;
    BEGIN i := 0;
        WHILE x[i+1] = y[i] DO INC(i) END ;
        r := y[i] = 0X;
        RETURN r;
    END Prefixed;

If you are interested in how I'm doing. Now I will do:

    PROCEDURE Prefixed(x: OPT.ConstExt; y: ARRAY [1] OF CHAR): BOOLEAN;
        VAR i: INTEGER;
    BEGIN i := 0;
        WHILE x[i+1] = y[i] DO INC(i) END ;
        RETURN y[i] = 0X
    END Prefixed;

And probably I'll go back to the use of alloca. I do not like this, but I did not come up with a better solution.

Looks like Texts module does not always return R.eot on 64bit systems.
Illustration is here.
That happens because

IF u IS Piece

in the procedure Read may return TRUE on 64bit systems, while in the same situation it returns FALSE on 32bit systems.

64bit system:

32bit system:

this is the macro which implements the IS test:

#define __ISP(p, typ, level)  __IS(__TYPEOF(p),typ,level)

It's in SYSTEM.h and does not work correctly on 64bit systems.

On my Debian 32 bit, procedure Reals.Expo (for REAL) didn't work right, whereas ExpoL (for LONGREAL) did work. As a result, Texts.WriteReal and Texts.WriteRealFix did not work (Texts.WriteLongReal did work).
I went ahead and fixed it (in src/library/v4/Reals.Mod):

  PROCEDURE Expo*(x: REAL): INTEGER;
    VAR i: INTEGER; l: LONGINT;
  BEGIN
    IF SIZE(INTEGER) = 4 THEN
      S.GET(S.ADR(x), i); 
      i := SHORT(ASH(i, -23) MOD 256)
    ELSIF SIZE(LONGINT) = 4 THEN
      S.GET(S.ADR(x), l); 
      i := SHORT(ASH(l, -23) MOD 256)
    ELSE HALT(98)
    END;
    RETURN i
  END Expo;

Before that it was just this:

  PROCEDURE Expo*(x: REAL): INTEGER;
  BEGIN
    RETURN SHORT(ASH(S.VAL(INTEGER, x), -23) MOD 256)
  END Expo;

And probably the issue had something to do with the incorrect work of SYSTEM.VAL for REAL to INTEGER conversion.

P.S. Not sure if SIZE(INTEGER) = 4 is required, but I added it for the future. The optimization removes the IF statement during compilation anyway.
I used the graphic over here for reference and this simple test program:

MODULE R;
IMPORT Out := Console, Reals, S := SYSTEM, Oberon, Texts;

PROCEDURE Expo(x: REAL): INTEGER;
  VAR i: INTEGER; l: LONGINT;
BEGIN
  IF SIZE(INTEGER) = 4 THEN
    S.GET(S.ADR(x), i);
    i := SHORT(ASH(i, -23) MOD 256)
  ELSIF SIZE(LONGINT) = 4 THEN
    S.GET(S.ADR(x), l);
    i := SHORT(ASH(l, -23) MOD 256)
  ELSE HALT(98)
  END;
  RETURN i
END Expo;

PROCEDURE Do;
VAR x: REAL; i: INTEGER; W: Texts.Writer;
BEGIN
  Texts.OpenWriter(W);
  x := 0.15625; (* Expo should return 124 = 01111100 *)
  REPEAT
    Texts.WriteLongReal(W, LONG(x), 25);
    Texts.Append(Oberon.Log, W.buf);
    i := Expo(x); Out.Int(i, 6); Out.Ln;
    x := x * 2
  UNTIL x > 10000
END Do;

BEGIN
  Do
END R.

to generate interfaces for C modules that can be used with voc.
good if it can be compiled by voc itself.
it requires porting ADT from ooc second version.

VAR l: LONGINT; BEGIN l := -9223372036854775808;

for LONGINT 64 bit gives "error 203 - number too large."

Problem is in OPS.Number. A number calculates as positive, and, after it, the sign changes.
l := 9223372036854775807 works ok

WHILE i < n DO d := Ord(dig[i], FALSE); INC(i);
    IF intval <= (MAX(LONGINT) - d) DIV 10 THEN intval := intval*10 + d (* <=  positive *)
    ELSE err(203)
    END
END

Arthur has found this bug. It present in Ofront, Ofront+ and voc. Yet I do not have a solution. Maybe you look, Dave?

MODULE SpeedTest;
IMPORT Out := Console;

(* VAR m: ARRAY 50 OF INTEGER; - If array is declared here - all is ok *)

PROCEDURE F3(n: INTEGER): INTEGER;
VAR i: INTEGER;
    m: ARRAY 50 OF INTEGER; (* Segmentation fault when handle m[45] *)

  PROCEDURE f(n: INTEGER): INTEGER;
  BEGIN
    Out.Ln; Out.String('DEBUG: f('); Out.Int(n, 0); Out.String(') = ...'); Out.Ln;
    Out.Int(m[n], 0); Out.Ln;
    IF m[n] = -1 THEN m[n] := f(n - 1) + f(n - 2) END;
    RETURN m[n]
  END f;

BEGIN
  FOR i := 3 TO LEN(m) - 1 DO m[i] := -1 END;
  m[1] := 1; m[2] := 1;
  RETURN f(n)
END F3;

BEGIN
  Out.String('START.'); Out.Ln;
  Out.String('F3(45) = '); Out.Int(F3(45), 0); Out.Ln
END SpeedTest.

Doing 'make -f makefile.darwin.clang.x86_64' on my Mac-mini (OSX 10.10.5), seemed to work fine. However, installing gave this:

Mac-mini:voc jkleiser$ sudo make install
Password:
test -d "/opt"/voc-1.1/bin | mkdir -p "/opt"/voc-1.1/bin
cp voc "/opt"/voc-1.1/bin/
cp showdef "/opt"/voc-1.1/bin/
cp ocat "/opt"/voc-1.1/bin/
#cp vmake "/opt"/voc-1.1/bin/
cp -a src "/opt"/voc-1.1/
test -d "/opt"/voc-1.1/lib/voc | mkdir -p "/opt"/voc-1.1/lib/voc
test -d "/opt"/voc-1.1/lib/voc/ | mkdir -p "/opt"/voc-1.1/lib/voc
test -d "/opt"/voc-1.1/lib/voc/obj | mkdir -p "/opt"/voc-1.1/lib/voc/obj
test -d "/opt"/voc-1.1/lib/voc/sym | mkdir -p "/opt"/voc-1.1/lib/voc/sym
cp libVishapOberon.so "/opt"/voc-1.1/lib
cp: libVishapOberon.so: No such file or directory
make: *** [install] Error 1

When I then try to compile a simple module, I get this:

Mac-mini:voc jkleiser$ ./voc MyHelloWorld.Mod -M
 GNU x86_64 target
MyHelloWorld.Mod  translating MyHelloWorld  main program    327
MyHelloWorld.c:2:10: fatal error: 'SYSTEM.h' file not found
#include "SYSTEM.h"
         ^
1 error generated.

clang  MyHelloWorld.c /Users/noch/local/voc-1.1/lib/libVishapOberon.a  -o MyHelloWorld  -fPIC -g -I /Users/noch/local/voc-1.1/src/lib/system/darwin/clang/x86_64 -I /Users/noch/local/voc-1.1/lib/voc/obj  
clang: error: no such file or directory: '/Users/noch/local/voc-1.1/lib/libVishapOberon.a'

I need to make the version string a variable in Configuration.Mod. Currently it's a constant, which means it gets compiled into each module that uses it and so 2 compiler modules always appear different (and so are currently omitted from the checksum test.)

Need a way for the build to indicate a checksum change is expected, e.g when the compiler hexliiteral parsing was corrected.

Actually, storing the checksum is turning out to be unhelpful - when the report shows a checksum change there is no information around to help analyse why it changed. Really I need to compare the previous and new .c and.h files to see what has changed.

But in fact the .c and .h files should match the bootstrap sources except in a very few details (especially the version info comment at the start.)

So I'll drop the checksum support and replace it with a diff between the newly built .c and .h sources and the corresponding bootstrap source (bypassing the version comment).

Is it sufficient to do this for the compiler modules, or is it necessary for the library too? I'll stick with the compiler for now.

The build status needs to reflect the current branch and SHA. When the build completes the status report should get checked into the repository - so when looking at earlier versions of the repository the status matches that version. (Currently there is just one status reflecting the latest build whichever branch it was on.)

And it would be nice if the status updated dynamically up to the point that the builds complete.

Obviously when the completed status report gets checked in, the github webhook will need to recognise that it's only a status change and not trigger another automatic build.

For the Windows builds I am going to need to run all 6 builds in sequence and the machine is not very fast. (The builds are: cygwin32 cygwin64 mingw32 mingw64 msc32 msc64.)

Generation of the bootstrap sources must currently be done from a 64 bit environment, there is an issue with the source generated on a 32 bit machine being able to generate source for a 64 bit machine. With the source checking above it may be necessary to generate the 32 bit bootstraps from a 32 bit environment. That's a bit of a nuisance. I can most easily do this from cygwin as I can build both 32 and64 bit enlistments on the same machine with cygwin. In the long term I think it will be possible to generate both 32 bit and 64 bit compilers from any compiler, making this easier. See roadmap for some related thoughts.

Naming the Oakwood modules by anything other than their standardized name (see the Oakwood Guidelines document) fails to utilize them in a useful way. It makes more sense to have these be the default modules, along with the Ofront modules (or even instead of), for the sake of preserving compatibility. (I know the Oberon Report doesn't require any particular modules.)

On my Mac, with OSX 10.11.2, I got

-bash: gmake: command not found

so I just used make instead.
And the name of the makefile is "makefile.darwin.clang.x86_64", not "makefile.clang.darwin.x86_64" as your COMPILE says two places.

procedure ulmPrint.Out gets parameter 'nargs'.

When function gets called via ulmWrite.Int, 'nargs' argument receives 2, it's visible in debugger upon entering the function.

Then the generated code looks like this:

struct Out__12 _s;
_s.out = &out;
_s.fmt = (void*)fmt; _s.fmt__len = fmt__len;
_s.nargs = &nargs;
_s.p1 = (void*)p1; _s.p1__len = p1__len;

Out__12 _s is used by compiler for implementing nested functions.
Then, when we enter SetSize nested function, *Out__12_s->nargs is some very big number, in the case right now 17179869186. That's why,

WHILE index < nargs DO

in SetSize function which looks like

static void SetSize__65 (void)
{
        INT32 index;
        index = 0;
        while (index < *Out__12_s->nargs) {
                switch (index) {

goes to the long loop.

By the way, the CASE statement was not compiled, there was a warning 307 (no ELSE symbol after CASE statement sequence may lead to trap) and then compiler was stopping, by saying 'assertion failed'. Unless I've changed case sequence by adding ELSE before closing END.

Memory model I am trying to use is default, -O2.

vmake currently takes list of modules and outputs sorted sequence suitable for compilation, or creating a makefile.

because oberon has exact hierarchy of modules vmake does not need this list, but only main module name.

it can then not only prepare the list by itself, but also run voc to compile all necessary modules.

warn programmer when facing

TYPE INTEGER=LONGINT

or

TYPE LONGINT = REAL

alike type aliases. it is useful to know when compiling a module about those.

MODULE test;
  VAR
    int,int2  : INTEGER;

BEGIN
  int  := 1234;
  int2 := 0;
  INC(int2, ASH(int,24));
END test.

INC seems to be broken with expressions that contain ASH(). This code compiles well on oxford oberon-2 and other oberon compilers.

$ voc -m test.mod
test.mod  compiling test.

   8:   INC(int2, ASH(int,24));
                            ^
    pos   102  err 111  operand inapplicable to (this) function

Module compilation failed.

might be good to have a package manager.
to download, compile and install new libraries to the voc prefix.

here the simplest solution would be not to add a separate library (because it would lead to complications of compile command lines generation) but rearchive libvoc.so and libvoc.a to contain new binaries.

for the sake of simplicity, library can be characterized by the git repository and branch.

Reported by Артур Ефимов.

    On 2017-01-17 12:34, Артур Ефимов wrote:

        Hi Dave,

        I've just found another bug. It's a new one, as I've been getting a segmentation fault trying
        to recompile a module that has worked with the older version of voc. I managed to narrow 
        it down to a small module:

        MODULE StringBug;
        VAR s: POINTER TO ARRAY OF CHAR;
            s2: ARRAY 32 OF CHAR;
        BEGIN
          s2 := s^
        END StringBug.
         
        I know this is an incorrect program, but it produces a segmentation fault upon compilation, 
        not in runtime. I've tested it on Debian 32 bit.

        Here is what "gdb --args voc StringBug.Mod" outputs:
        Starting program: /opt/voc/bin/voc StringBug.Mod
        Program received signal SIGSEGV, Segmentation fault.
        0x08069e5e in OPC_CompleteIdent (obj=0x0) at OPC.c:1656
        1656        level = obj->mnolev;

        Arthur

I just tried 'make -f makefile.darwin.clang.x86_64' on my Mac (OSX 10.11.2), and got "make: *** [stage5] Error 1". See attached file for details.
stage5error.txt

may be it is feasible to make gcc command line and warnings not shown by default but require a special verbose flag. it might be even more relevant to clang, because it issues more warnings by default.

imagine a procedure

PROCEDURE a(VAR s : ARRAY OF CHAR);

now let's say we want to test s[i] for something, but mistakenly write

IF s = 0X THEN

should there be warning or error about that?

create a useful In compatibility module in order to be able to compile ETH Oberon modules.

voc signals compilation error 113 incompatible assignment when parameter of type PROCEDURE assigned to variable of type PROCEDURE.

MODULE Test0;

VAR
  setUp : PROCEDURE;
  count : INTEGER;

PROCEDURE SetUp*(pr : PROCEDURE);
BEGIN setUp := pr
END SetUp;


BEGIN count := 0;
END Test0.

Compilation gives:

$ voc Test0.Mod
Test0.Mod  compiling Test0.

   9: BEGIN setUp := pr
                       ^
    pos   111  err 113  incompatible assignment

Module compilation failed.

I think the README.md should tell whether voc is Oberon-2 or Oberon-07, and it would also be nice with a link to some basic Oberon reference documentation.

Like Oberon module, Texts module, which all modules are available in voc by default?
Does this module list covers all default/necessary modules supported by Oberon system?

Voc has many libraries inbuilt, V4, S3, Ulm's, ooc etc.
How to use a specific library? Any compile time option?
Or everything available at the same time? No name space clash?

and similar - Linux/arm, etc, i. e. in src/system/linux/x86asm calls would call not libc functions, but kernel calls directly.

this have several benefits:

• lesser dependency on libc in resulting apps.
• should be smaller size
• should be faster
• easier to implement native backends, and eliminate dependency from C compilers.

Is it possible to add a compiler option for freestanding/bare metal compilation? (Equivalent GCC flag -ffreestanding )

I am interested to know the steps we follow to prepare voc compiler.
Below are my guesses. Kindly correct them.

To make voc, only requirement was gcc on my linux machine.
But most of the code for this compiler is written in Modula-2.
Also we use ofront to convert .Mod to .c.
I am trying to co-relate these three statements and guess how you could have proceeded.

First build ofront using gcc. Is ofront source written in C?
Then convert Modula-2 sources of voc to .c files.
Now compile them using gcc.

Am I mistaken? Kindly correct me.

I compiled and installed Vishop Oberon compiler 1.1 on my linux.
Below is my Hello.Mod file collected from net.
I compiled the file using voc -m. It went fine.
When I tried to run the module using ./Hello, I see nothing. :-(
What is that I missed? Why it is not working?

~# cat Hello.Mod
MODULE Hello;
IMPORT Oberon, Texts;
VAR W: Texts.Writer;
PROCEDURE World*;
BEGIN
Texts.WriteString(W, "Hello World!");
Texts.WriteLn(W);
Texts.Append(Oberon.Log, W.buf);
END World;

BEGIN
Texts.OpenWriter(W);
END Hello.

Occasionally the build on OpenBSD will fail with MODULE expected. The error report goes on to show the error line, which is the very beginiing of file, and when the error reporting code reads the file the 'MODULE' statement is there just fine. It can happen on any Oberon source file, but it is always the first line.

It's worth looking into whether file buffer uniqueness management may not work correctly on OpenBSD - e.g. maybe we're relying on something in stat that's not valid for OpenBSD. Or maybe there's an uninitialised varianble :-(.

gadget windows as standalone applications on X11?

Norayr commented out code to get a list of errors from file OfrontErrors.Text in OPM.LogErrMsg, but he forgot to comment out all declared variables, that only need to run this code.

I propose to make output of an error message without using of array "errors.errors: ARRAY 350 OF ARRAY 128 OF CHAR". These messages are only required to output into the console, they are not used in any way differently. accordingly, we can achieve economy of memory.

• Oleg-N-Cher/OfrontPlus@8f7ee7d

WHILE (LEN(str)#0) DO

compiles to

while (1)

I wanted to check how long some computation took, and I tried something like this:

start := Kernel.Time();
f := Fibo(n);
stop := Kernel.Time();
Out.Int(stop - start, 12);

However, I'm not sure what this "stop - start" tells me. It doesn't look like milliseconds or microseconds. How can I obtain milliseconds (or microseconds)?
I'm doing this on Mac OSX.

partly implemented.
shoud take a couple of days to finish.

does it make sense to separate RTL routines, like Init, LSH, from unportable and/or unsafe functions that SYSTEM encapsulates.

right now SYSTEM.o is linked to any voc program. does it make sense?

on the other hand, most weight of SYSTEM.o comes not from unportable functions, so we won't gain anything in size, but it will complicate the compiler, and requires a lot of changes.

showdef is an amazing tool, specially for newbies, it helps to understand the content of a module without reading the source code.
however, it will be more useful, it the .sym files where also commented about every TYPE, CONST, PROCEDURE, etc.
This also means that we will need to re-implement showdef, AFAIK it does not support comments.
thanks in advance.

I see on voc webpage, "Work on native backends for arm and x86_64 is in progress."
I am excited about this.
Now voc converts Oberon program to a C program using ofront.
Then compiles generated C code using gcc, gas and ld to emit final elf file.
I hope, work is going on to directly convert Oberon to asm code which can then be assembled using as to generate object code. We will still use ld or a new linker is being made?

Voc is a Oberon-2 compiler.
Oberon-2 is a super set of Oberon.
Oberon-7 used in Project Oberon 2013 is simpler than Oberon.
How far voc supports Oberon 7? Any part of Oberon-7 is yet to implement?

I think, while using voc to program, one can't take advantage of garbage collector.
Am I mistaken?