flat assembler
Message board for the users of flat assembler.
 Home   FAQ   Search   Register 
 Profile   Log in to check your private messages   Log in 
flat assembler > Projects and Ideas > more interactive c compiler?

Goto page 1, 2  Next
Author
Thread Post new topic Reply to topic
vivik



Joined: 29 Oct 2016
Posts: 186
more interactive c compiler?
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".


Last edited by vivik on 22 Sep 2017, 06:49; edited 2 times in total
Post 09 Sep 2017, 10:55
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15242
Location: 1I/ʻOumuamua
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?
Post 09 Sep 2017, 11:53
View user's profile Send private message Visit poster's website Reply with quote
vivik



Joined: 29 Oct 2016
Posts: 186
@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.
Post 09 Sep 2017, 13:24
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15242
Location: 1I/ʻOumuamua
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.
Post 09 Sep 2017, 14:08
View user's profile Send private message Visit poster's website Reply with quote
vivik



Joined: 29 Oct 2016
Posts: 186
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.
Post 09 Sep 2017, 15:03
View user's profile Send private message Reply with quote
vivik



Joined: 29 Oct 2016
Posts: 186
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
Post 10 Sep 2017, 07:51
View user's profile Send private message Reply with quote
vivik



Joined: 29 Oct 2016
Posts: 186
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:


Code:
start \ hmodule 0 commandline show -- res
    4drop
    0 z" Hello World" z" VFX Forth" MB_OK MessageBox drop
    0
;

' start is EntryPoint
Save hello
bye



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.
Post 10 Sep 2017, 07:52
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15242
Location: 1I/ʻOumuamua
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.
Post 10 Sep 2017, 08:24
View user's profile Send private message Visit poster's website Reply with quote
vivik



Joined: 29 Oct 2016
Posts: 186
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.
Post 10 Sep 2017, 08:36
View user's profile Send private message Reply with quote
vivik



Joined: 29 Oct 2016
Posts: 186
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.
Post 11 Sep 2017, 18:42
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15242
Location: 1I/ʻOumuamua

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

Who are you directing this comment to?
Post 11 Sep 2017, 19:20
View user's profile Send private message Visit poster's website Reply with quote
vivik



Joined: 29 Oct 2016
Posts: 186
There should be more users on this forum than just revolution
Post 12 Sep 2017, 04:42
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15242
Location: 1I/ʻOumuamua

vivik wrote:
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.
Post 12 Sep 2017, 04:45
View user's profile Send private message Visit poster's website Reply with quote
vivik



Joined: 29 Oct 2016
Posts: 186
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.
Post 12 Sep 2017, 06:08
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15242
Location: 1I/ʻOumuamua

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

You are probably right about that.

vivik wrote:
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.

That would be awesome. I'd like to see it.
Post 12 Sep 2017, 06:15
View user's profile Send private message Visit poster's website Reply with quote
vivik



Joined: 29 Oct 2016
Posts: 186
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.)
Post 12 Sep 2017, 06:37
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15242
Location: 1I/ʻOumuamua

vivik wrote:
Alternatively just use C#. It's not as fast, but it's much much easier to work with than C or assembly.

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. Shocked
Post 12 Sep 2017, 07:40
View user's profile Send private message Visit poster's website Reply with quote
vivik



Joined: 29 Oct 2016
Posts: 186
Interesting how whenever I mention money, it just gets ignored.
Post 12 Sep 2017, 08:58
View user's profile Send private message Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2124
Location: Usono (aka, USA)

vivik wrote:
Here is one forth compiler that is pretty good, but still can be improved: vfx forth

It reports saving a 861710 bytes large exe file. It means it still has a 800 kilobyte runtime in every executable it produces.



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.


vivik wrote:

Every single language does that for some reason, it's impossible to find one that doesn't stuff exe files with something.



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.


vivik wrote:

C and C++ support creating freestanding exe files if you waste enough time, but still it could be done much simplier.



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.
Post 13 Sep 2017, 00:08
View user's profile Send private message Visit poster's website Reply with quote
vivik



Joined: 29 Oct 2016
Posts: 186

rugxulo wrote:

vivik wrote:
Here is one forth compiler that is pretty good, but still can be improved: vfx forth

It reports saving a 861710 bytes large exe file. It means it still has a 800 kilobyte runtime in every executable it produces.



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.



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.


rugxulo wrote:

vivik wrote:

Every single language does that for some reason, it's impossible to find one that doesn't stuff exe files with something.



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.



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.


rugxulo wrote:

vivik wrote:

C and C++ support creating freestanding exe files if you waste enough time, but still it could be done much simplier.



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.



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.
Post 13 Sep 2017, 07:37
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page 1, 2  Next

< Last Thread | Next Thread >

Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001-2005 phpBB Group.

Main index   Download   Documentation   Examples   Message board
Copyright © 2004-2016, Tomasz Grysztar.