aboutsummaryrefslogtreecommitdiffhomepage
path: root/notes/slulrt2.txt
blob: 782bbce752c8aff2d174fbca64475b27290565c9 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92

slulrt, second design attempt
=============================

Building libraries in a portable way with a "C toolchain" is really
un-portable. Especially if you don't want to add extra dependencies
(like automake etc). Even with automake I think you can only build *libraries*
for reasonably unix-like platforms (probably not Windows, but I haven't tried).

Idea:
Write slulrt in SLUL, with some special extensions: 
1) *Maybe* unsafe SLUL
2) *Maybe* machine code, if this is needed.
   (maybe for stuff like floating point?)
3) Linking in C object code.
   (Position Independent Code on *nix platforms)
   This is needed for *BSD.
4) Some way of defining which symbol belongs to
   which library (and which symbol version).


Unsafe SLUL
-----------
We really want unsafe SLUL to be *explicitly unsafe*.
It should be required to declare the "unsafeness" in ALL of the following:
* [slul] section in the slulbuild.conf file
* Filename indication of unsafety:
   - maybe a file extension? (".unsafe.slul" instead of ".slul")
   - maybe a special filename or directory ("unsafe/" or "unsafe.slul")
     (better?)
* Function bodies
* Location of unsafe action, with an explicit annotation of HOW it is unsafe.
* In a command line option to the SLUL compiler (e.g. --unsafe)
Also, NO guarantees of stability between SLUL versions for unsafe code!

And some kind of disclaimers, and vague wording without promises. Maybe
something like this:
"The behavior of code in an unsafe block is undefined, and implementation
 specific. Compilers MAY implement support for unsafe code, but are not
 required to do so."
"In an unsafe block with the .pointertype option, the compiler MAY skip type
 safety checks of references (which can lead to undefined behavior). The exact
 behavior of the .pointertype option is implementation defined."
"Compilers MAY implement support for unsafe code. The <chapter/section/etc>
 is purely informational."
"Support for unsafe SLUL code is not an official part of the SLUL language
 and is subject to change at any time."


slulbuild.conf
    [slul]
    unsafe = true
    name = slulrt
    ...

    [source]
    xxx.slul.
    unsafe/fp.slul
    unsafe/mem.slul

unsafe/mem.slul:
    ...
    func unsafe extern mmap(ref addr, usize len, int prot, int flags, int fd, off_t offset) -> ref
    func aalloc(xxxx)
    {
        ...
        unsafe in (.pointertype, .uninit) {
           unsafe block = mmap(unsafe addr, len, prot, flags, 0, 0)
        }
        ...
    }


Linking in C object code
------------------------
Perhaps something like this:

slulbuild.conf
    [slul]
    unsafe = true
    name = slulrt
    ...

    [objfile]
    ccode.o

Makefile
    slulrt: ccode.o
            cslul

    ccode.o: ccode.c
            $(CC) $(CFLAGS) -fPIC  -c $< -o $@