I have a few ideas, and I want to hear your opinions on it. Does it worth spending time on? Would you care to help it happen?

What do you think about a compiler that allows you to change part of function during execution? Or compiler that allows you to have repl-like command line? Visual studio has a feature called "edit and continue", which is pretty much that.

Biggest limitation of edit and continue, according to this link https://docs.microsoft.com/en-us/visualstudio/debugger/supported-code-changes-cpp , is changing data types at runtime. It is indeed nearly impossible if data of this type is all other the memory, but if there is only one object of this type, or only one array of objects of this type, it's actually pretty easy to change it. The "changable at runtime" data works simularly to resizable arrays, you just have a few extra space in memory, and in cases when it's not enough, compiler just allocates more and copies data there. This started sounding like a database.

Having this extra workflow would probably require changing language itself a bit. One feature that I think is necessary, is operator "del". Not like the c++ "del", which only frees memory and variable itself stays until the end of function or end of code block, but more like the python "del" or javascript "delete", which makes variable unaccessable and free for redeclaration. The reason for this, is that this language can be used from repl command line, where code blocks just may never exist. I think it makes code more clear, it allows to have more temporary variables instead of mashing multiple functions in one line, and makes more clear when the variable is no longer needed. When C first appeared, it required for all variables in code block to be defined at the beginning of said code block, and mixing code and data only appeared with C99 standard. Wish it moved further and allowed to delete variables explicitly too, but alas. Good compilers actually do check when is the last usage of local variable is, and reuse stack space.

Another feature that can be good, is changing function call notation to postfix one, forth-like. Cons: > < + - * / operations will be less readable, code will look more alien, harder to distinguish function from variable. Pros: everything will execute left-to-right, no need to memorise operators precedence and put tons of parentheses, you can see result of expression as you type, you can choose to save result or not after you got it, you can chain calls like you can in haskell with "." dot, maybe you'll be able to get multiple return values. The concept of function in c was taken from math, and all other popular languages took it from c, and wasn't revised since. Calling a function will look like this: "5 2 divmod -- q r". Maybe it will have a bit of syntax sugar, simular to x+=1, it will look like this: "x --. 1 +"

I'd like to have a language which is as interactive and easy to use as python, and as powerful and close to metal as c.

EDIT: It will be for windows 32bit, maybe later it will grow to 64bit on linux and mac. Main focus is gamedev, this is why seeing changes fast is important.

EDIT2: this whole thing pretty much boils down to "I want to write tiny exe, but don't want to do it in assembly".

I am reminded of forth when I read the description.

But I am confused as to how you plan to "change part of function during execution". Do you mean SMC? Or stop-->edit-->recompile-->continue from last stop?

@revolution
Stop->edit->recompile->continue. Ideally stopping wouldn't be even necessary, it will put breakpoint at the beginning of function and handle the rest transparently. No virtual machine or state machine compiler or whatever, only native code.

I'll use the microsoft's edit and continue approach. It works by beginning every function with 6 nop, and replacing them with jump to another function when it needs replacement. All windows dll have this prologue.

Many debuggers can do a similar thing. Put a breakpoint and modify whatever is needed manually. I think the difference here is that you want to be able to patch in bytes that are generated by compiling HLL code.

What debuggers are you talking about? If you mean assembly-level debuggers like ollydbg, then indeed you can edit everything in place manually, but it's a pain to handle. You need to find place for your new code, clean up no longer needed functions, move them closer to each other and rearrange them. You shouldn't do that manually.

gcc seems to only be able to "compile" and execute some statement, but doesn't look like it can change existing functions or define new ones. https://sourceware.org/gdb/current/onlinedocs/gdb/Compiling-and-Injecting-Code.html#Compiling-and-Injecting-Code

visual studio with it's c++ and especially c# compilers are closest ones to come to it. They are still not perfect though.

difference between my language and forth

1) my language is fully compiled, all development features wouldn't affect the final build.
2) it doesn't have stack manipulation instructions like forth does, instead it just uses variables like c and python.

My language indeed is inspired by forth, or rather by factor http://factorcode.org/ . I took my time learning it, and one thing I learned from it: author keeps warning users to use stack manipulation instructions (like 2dup 2rot swap) as rarely as possible, and later implemented syntax to add variables. It looked something like this:

5 7 + :> t1
5 7 - :> t2
t1 t2 + :> result

I intend on continuing where he left off, throwing away most of factor features, and end up with something that is more easy to read and learn. It'll be pretty much c/python, but with postfix notation.

I actually wrote about it before, you can read it here. It's a mess though https://board.flatassembler.net/topic.php?p=196422#196422

Here is one forth compiler that is pretty good, but still can be improved: vfx forth http://www.mpeforth.com/software/pc-systems/vfx-forth-for-windows/

here is a hello world for it:



It reports saving a 861710 bytes large exe file. It means it still has a 800 kilobyte runtime in every executable it produces. Every single language does that for some reason, it's impossible to find one that doesn't stuff exe files with something. C and C++ support creating freestanding exe files if you waste enough time, but still it could be done much simplier.

fasm has the "if used ..." feature. If an HLL library could use something similar then the exe file would be much smaller after eliminating the unused parts from the output.

Asm is pretty unreadable, to be honest. C abstracts away registers, so you only work with variables. Just like I try to remove stack manipulation in forth, and only work with variables.

At least write "I don't care" or "I don't get it", don't just read silently. It's important.

Another language that claimed to be something in between python and c was golang. But it's so inbetween, it failed to take both of their niches. It can't replace python because it doesn't have a repl, and even no proper debugger. And it can't replace C, because you must use garbage collector. It's good when massive parallelisation is required though. And it's a good language to steal ideas from.

good debugger > good compiler. If you want to make a language, be ready to make a whole ide for it.

I'm not sure why I care about x86 so much, maybe it's dying by now and will be replaced pretty soon. I guess it's because there are a lot of games that were made with it. Gonna disassemble them one day. Yes, I intend to use it for disassembling existing programs too, it has very low priority though.

I guess I should start studying gcc sources now. It's code generator is really good, using it as a base or as a source of inspiration wouldn't hurt. Maybe I'll be able to improve c somewhat with small blood, without going all the way to "my own ide, my own ida". Like changing default code convention, make command line more comfortable to use, little things like that.

Sucks I have no money to do all that. If you can spare some money or some time, it would be neat.

Who are you directing this comment to?

There should be more users on this forum than just revolution

I agree. But you are posting about HLL on an assembly board, so the expected number of interested users might not be so high.

There is no reason for this split to exsist, assembler knowledge should be used with high level languages, and not as an independent skill.

Actually, one of ideas I have, is making a language that can generate a code equivalent to fasm source code. This is my criteria of high quality code generation, beating hand-written code.

You are probably right about that. That would be awesome. I'd like to see it.

I wonder if now is a good time to beg for money.

Alternatively just use C#. It's not as fast, but it's much much easier to work with than C or assembly. Users don't seem to care, so there isn't that much difference after all. (I wish I knew why visual studio keeps crashing on my computer, probably because my "lightweight" windows pack is missing something, and visual studio is the only program that needs it.)

It depends upon what you are working with. For small embedded systems using any HLL might not be practical or possible. Sometimes using C# is like using a RTA96-C to power a lawnmower.

Interesting how whenever I mention money, it just gets ignored.

I haven't tried it, but I assume you're doing it wrong or else that's a demo limitation. It's fairly common for Forths to compile to much smaller size. Seriously, there are many active Forth implementations, so ask on news://comp.lang.forth (which is always busy) for better help. They really know their stuff, and I'm positive it is often done much better.



No, actually a lot of languages have "smartlinking", which strips out unused stuff. E.g. Free Pascal "-CX -XXs". A simple "Hello, world!" on Win32 gives me a relatively tiny 31 kb .EXE.



C-based languages usually don't care about size as much (or else rely too heavily on dynamic linking as a workaround). *printf() and friends are quite bloated. But, even there, you can do several things to help minimize the size.

It was a demo app. Can't afford buying it just to check.

Not sure how to use newsgroups, never used one before. I don't care about forth that much, to be honest. Just got derailed for a bit there. There are too many different variants of if else in forth, and no goto. C is closer to how hardware works, I need to aim for that.



Everything that is above 4 kb for a single api call (MessageBox) is heavy for me. It's not that it's a problem, it just means that there is something inside, and nobody will explain to me what it is.



Yes, that's that I meant by "waste enough time". I feel like I have to reimplement the whole runtime at this point, even if I just use C.