libec (mini-libc)

[enkore]

Just a scrapbook

Obligatory functions

Memory managment

• malloc(words)
• free(pointer)
• memcpy(dst, src, words)
• memset(pointer, val, words)

Strings

• strcat(dst, src)
• strdup(src)
• strcmp(val1, val2)
• strlen(val)
• strtok(val, delim)

IO

• fopen(file [mode?])
• fwrite(src, words, handle)
• fread(dst, words, handle)
• ftell(handle)
• fseek(dest, origin, handle)
• fclose(handle)
• Something for reading directories contents + file attributes
• getc() (read character from keyboard)
• puts() (write string to screen)

Networking

• opensocket(proto)
• connect(sock, target, port)
• send(sock, buf, len)
• recv(sock, buf, len)
• listen(sock)
• bind(sock, port)
• Probably name resolution, if any

Additional functions

Screen management

• clear() - clear screen & set cursor position to 0,0 (upper left corner)
• sloc(x, y) - set cursor position
• scroll() - scrolls screen contents by one line (upper line vanishes, blank line at the bottom of the screen)
• gets() - get line from keyboard
• mirror(boolean) - enable/disable automatic mirroring (typed text automatically appears at current cursor pos)
• color(foreground, background, blink) - explicit way to change color(?)

Security Considerations

• A malicious program can corrupt all files on the hard disk, but it could also use direct IO for that anyway

[Jarvix]

networking: UDP?
and not sure we can have shutdown or reboot, depends on notch.

[enkore]

open/send/recv/... I thought something like reduced Berkeley sockets... so that we use the same interface to multiple protocols... UDP/TCP/RCP whatever is implemented... see my edit

[jeremy-w]

We should leave out the broken string-handling functions that don't require you to consider the length limit:

• Use strncmp instead of strcmp
• Use strncat instead of strcat

It might also make more sense to use Pascal strings with an explicit length byte at s[0] rather than the usual C NUL-delimited system. Walking a string to get its length is pretty common, and the Pascal length-prefix approach avoids it. ETA: Pascal-string proposal is being written up by Boreeas, starting with https://gist.github.com/2345992.

Apple compilers at least used to support a hybrid where you'd start the string with \p and it would embed the length as the first byte, while still NUL-terminating the string body. "\phi" => \x2 h i \0

[enkore]

The current string format draft also proposes pstrings, so we can also
use them here. This libc is already kinda different from a normal one
and when the majority of C compilers implement strings as pstrings,
we're good to go...

We should leave out the broken string-handling functions that don't require you to consider the length limit:

• Use strncmp instead of strcmp
• Use strncat instead of strcat

It might also make more sense to use Pascal strings with an explicit length byte at s[0] rather than the usual C NUL-delimited system. Walking a string to get its length is pretty common, and the Pascal length-prefix approach avoids it.

Apple compilers at least used to support a hybrid where you'd start the string with \p and it would embed the length as the first byte, while still NUL-terminating the string body. "\phi" => \x2 h i \0

[enkore]

I just wanna ask if #39 has any impact on this regarding the possiblity of a RFC.

[enkore]

Probably add some stuff to calculate with bigger numbers? 32-bit ints/uints, maybe even 64-bit ints? That could make writing programs much easier and reduce code repetition across programs and it's neither hard to implement nor large.

[0xabad1dea]

Strlen for pstrings would be better off as an inline macro than an actual function... would save a lot of cycles :)

I would strongly advise for strtok to be implemented in a re-entrant fashion (I have a religion against non-re-entrant standard functions) and any others like that which I am forgetting at the moment

The network as implemented may or may not map to the sockets concept - we'll have to wait and see.

We should have screen routines, like ncurses lite.

[enkore]

Problem with (inline) macros is, that they're language dependent, while functions are not. But as the implementation of strlen is really a one-liner, we could recommend implementing it as a macro.

Regarding re-entrantiness: As we don't have to implement this, I would propose, that all obligatory functions must be re-entrant.

Screen routines should be non-obligatory; not everyone needs them and getc(), puts() provides a basic interface to this.

Probably something like this?

• clear() - clear screen & set cursor position to 0,0 (upper left corner)
• sloc(x, y) - set cursor position
• scroll() - scrolls screen contents by one line (upper line vanishes, blank line at the bottom of the screen)
• gets() - get line from keyboard
• mirror(boolean) - enable/disable automatic mirroring (typed text automatically appears at current cursor pos)
• color(foreground, background, blink) - explicit way to change color(?)

[enkore]

That won't go into libc, as its the compilers responsibility to provide this. (Yes, I am aware that I wrote that)

Probably add some stuff to calculate with bigger numbers? 32-bit ints/uints, maybe even 64-bit ints? That could make writing programs much easier and reduce code repetition across programs and it's neither hard to implement nor large.

[enkore]

First draft

I call this libec know, to have a more google-able name

[enkore]

https://github.com/enkore/0x10c-Standards/blob/wip/LIB/Draft_libec.xml

Small update, so that ppl. can use intrinsic functions for this.

[Chase-san]

Maybe I should start in one some of these when I have some more free time.

[aubreyrjones]

I don't think that the streams IO pattern is a good fit with any of the statements Notch has made on memory mapped/DMA IO. One of the irc logs, he even implied that floppies might be accessed through bank switch!

In such a world, it makes more sense to work in terms of loading blocks of data.

I'm just throwing this api off the cuff, but maybe something like:

// Open a file, returning a struct.
file_struct *open_file(/*path spec, or id, or whatever*/);

// Read the next block of the file, putting a pointer to it in block_ptr.
bool read_next_block(file_struct *file, OUT word **block_ptr);

// Read the given block.
bool read(file_struct *file, int block_offset);

// After making changes to the buffer in memory, you flush to disk
bool write(file_struct *file, word *block_ptr);

// Invalidates the backing buffer, cleans up
bool close(file_struct);

// Convenience functions, inlined

// Given a word offset from start of file, finds appropriate block
int block_from_word(int word_offset);

// Given a word offset from start of file, finds what offset it is
// from start of its block.
int word_in_block(int file_word_offset);

I think it's silly to talk about IO in depth before we see real IO specs. But, if IO is all memory-mapped, then stdlib needs to provide convenience on top of those facilities, not simply ape 40 year old irrelevant standards.

[enkore]

Dito on that. That's why I more or less said "for now we just assume C90" :) Lets see what the future brings in this regard.

Besides that I uploaded a new revision, mainly concerning memory management (+memmove), and strings (+sprintf). Also made some formal changes...

[Triang3l]

:memcpy ; cdecl (dest, src, size)
    set c, pick 3
    set j, pick 2
    set i, pick 1
    sti [i], [j]
    sub c, 1
    ifg c, 0
        sub pc, 4
    set pc, pop