liebranca / bitter

GNU weapon of mass-destruction

KVR

The infamous, fully GPL'd GNU weapon of mass-destruction, KVR or KVNSL RAT (V as in KVLT) is my personal C coding environment for desktop; this project simply contains the tools I use everywhere else, and thus it is always growing.

What's in this repo?

• KVRNEL, C lib for debug utils, some wrappers for stdlib (mostly malloc stuff), my hash table implementation, general purpose functions such as data-type conversions, color/grayscale/unit vector quantization, among other things.
• ESPECTRO, a legacy CLI build system written entirely with python and ANSI escapes.
• BLKMGK, a small util for packing and unpacking compressed texture data.
• MAMMOTH, where I implement the PE$O language.
• SIN, graphics library used here mainly for rendering text. 3D capabilities not fully ported yet (look at /Liebranca/DSM/tree/dev/src/SIN for that).
• CHASM, SDL window manager.
• SHB7, a minimalistic custom terminal.
• FMAT, the dullest code-formatting tool in existence.

Why write all of this from scratch?

It's a mix of research and simply handrolling my own of something because no good alternative exists. Hey, I pinky promise this isn't actually an evil 16-bit OS, I would never do such a thing. wink

Dependencies

• GCC
• MAKE
• PYTHON3
• SDL2
• GLEW+GLAD
• LIBPNG16
• ZLIB1

Python is a terrible language and I personally detest it; eventually all Python glue in the codebase will be removed. But until that day comes: just deal with it.

The GLEW+GLAD mambo is a hack. SIN links against GLEW but doesn't actually include it; we use glad.h instead. That is how you open an SDL window with a drawable OpenGL context in pure Cygwin, a method apparently no one but me knows.

Speaking of Cygwin -- if you're on Windows, you'll need it. If you're on GNU/Linux, you probably don't need the GLAD hack (untested). If you're on a Mac, switch to an actual computer.

Building

Assuming I didn't mess up the dependency list and your paths are appropiately set:

cd kvr/src
make all

Or just make <target>, valid targets are:

• kvrnel
• sin
• chasm
• shb7
• mamm

make reb is just a make all with a pre-clean step.

To turn different debug flags on and off (so that you get more accurate logs), look at /src/avtomat/avtomat.py and change the value of KVR_DEBUG. A list of valid flags to set or unset can be found in /src/kvrnel/zjc_evil.h

bitter's Issues

WE NEED TABLES

A lot of cool functionality could be baked in the resulting C code if we had additional information at our disposal when translating PE$O. These include:

1. Tables of variables and constants (LNAMES, GNAMES)
2. A table for datatypes (DTYPES) Forget these two. zjc_id is enough descriptor.
3. A table for functions (FNAMES)

In order to tie this together, hashes and probably linked lists are required; both exist within Zajec though the implementation is sloppy, confusing and only accepts numbers as keys. So additional workload is translate those.

\*as\*cendant syntax

Figure 0:

var@0 =/#/op= var@1;

mamm will have trouble with this because it's fetch first token, check if it's a fetch, then oppy-poppin and finally solving -- and all to repeat the process once again; except this time generate actual instruction tokens and check whether the first oppy is an equals, kush or e-oppy.

This doesn't make any sense. Put instruction then eval once, simple. You know the minimum number of args firsthand, and *all* tokens are translated in the same run.

Thus, figure 1:

cpy var@0, var@1

I have inadvertently developed an interpreter which has a preference for this kind of mock-assembly syntax. And I like it a lot.

So: time to ascend beyond re-thinking and re-designs, this is what we're doing now.

TODOs

• cpy a, b -> a = b;
• mov a, b -> a = b; b ^= b;
• wap a, b -> c = a; a = b; b = c;
• wed type -> sets typing mode; implicit casting

• jif a, b -> jump to a if b
• eif a, b -> jump to b if not a
• entry s -> defines s as program entry point
• exit x -> stops program and returns x

• add a, b -> a += b;
• sub a, b -> a -= b;
• mul a, b -> a *= b;
• div a, b -> a /= b;
• mod a, b -> a %= b;

• and a, b -> a &= b;
• or a, b -> a |= b;
• xor a, b -> a ^= b;
• nand a, b -> a = !(a&b);
• nor a, b -> a = !(a|b);
• xnor a, b -> a = ~(a^b);
• shl a, b -> a<<b; cpy a, a << b;
• shr a, b -> a>>b; cpy a, a >> b;

• til a -> a = ~a
• cl a -> a^=a
• clm a, b -> a&=~b
• not a -> cflg set/unset non-zero a; a=!a; returns a==0;

• lis a, b -> define/redefine a as an alias for b
• buf a -> set buffer idex to a
• sow varargs -> write varargs to current buffer
• reap a -> execute op idex a for current buffer

You're not an Engineer, not even close, Lyeb

@Liebranca You are not an Engineer.
You falsely claimed to be an "engineer" in of of your videos. Engineering is not about sitting behind a screen, and pressing keys on a keyboard to write code. No, engineering is far more serious . Engineering is about designing and building real entities, like turbines or buildings. Software developers have this tendency to make huge and false claims these days. They are not engineers, and will never be engineers, not even close.

Paste libs into build commands

Everything up and running so to speak, we're just lacking a way to find all the generated *.lib that are scattered across the folder structure.

TASKLIST

1. Add a "find libs" button for module-generated bins.
2. User-input hook for defining which additional libs we'll use.
3. Check for missing dependencies
4. Add "compile and run"
5. Alias everything in PE$OLANG forget it, we'll do this later
6. Report to the ship as soon as possible.

SINx8

Some preamble

The original SIN libraries I wrote over two years ago are okay, but have two main problems that are hard to address properly without rewrites:

• It uses C++
• Geared solely towards 3D, and I just need to draw sprites onscreen
• Suffers from lack of clear architechture

What to do

• For the love of God use pure C
• KISS
• Mount the SDL wraps
• Open a window
• Bring OGL into the picture
• Draw some sprites

With a little bit of luck this will be done soon.

If I can't make a game because making the game IS the game by the end of this year I'm going to be very disappointed.

Flatten onion-like MEM layers

Currently, complex structures utilize a MEM header each, taking up a whole cache line only to tell us what we already know: how the data should be read, something that ought to be already contained within the substruct -- simply top-notch ICWH.

Ideally, a single MEM should exist per structure, located __always__ at the top of the hierarchy. This way the allocation is done once, all memory is claimed up-front and there is only one buffer to keep track of and deallocate. Sounds sweet, let's do it.

• Rename CALL macro for something more appropiate so we know it's there as a memward. Wouldn't want to get confused now, would we?
• Retool ZJC_HASH and unroll the onion. Pass &buff @offset to substructs so they simply locate themselves in the buffer and work within that space; no more, no less.
• Try caching hashcodes. Our hashing function is quite pretty but an idex%table_size per table lookup is simply murder.