flat assembler
Message board for the users of flat assembler.

flat assembler > Projects and Ideas > more interactive c compiler?

Goto page Previous  1, 2, 3  Next
Author
Thread Post new topic Reply to topic
TmX



Joined: 02 Mar 2006
Posts: 815
Location: Jakarta, Indonesia
vivik wrote:

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.


The closest one I can think of is Nim (no REPL, though).

Scheme/Lisp implementations have nice REPLs (and metaprogramming feature as well), but on the other side seems like they are not targeted for system programming like C.
Post 14 Sep 2017, 14:28
View user's profile Send private message Reply with quote
vivik



Joined: 29 Oct 2016
Posts: 425
https://nim-lang.org/features.html

huh, hello world of 41 kb. Must be because of garbage collection.

All languages seem to either always have or always not have garbage collection. Because if gc exist, it must be build into language, and language should be build according to that. But gc is an overkill in some situations, and isn't necessary if you are careful to always free memory. I hope to turn garbage collection into a debugging feature, and remove it from the final build. I'm not sure how exactly I would make that, memory management is probably more complicated than code generation. I'll probably take a static analysis approach, simply warning a programmer when he forgot to free something. Not sure. I care about the final binary more than about the prettiness of language itself.

Here is a bit more about garbage collection https://board.flatassembler.net/topic.php?p=196423#196423

I feel like a politician right now. Bunch of promises. Think of them as ideas, sense of direction.
Post 15 Sep 2017, 08:33
View user's profile Send private message Reply with quote
TmX



Joined: 02 Mar 2006
Posts: 815
Location: Jakarta, Indonesia
vivik wrote:
https://nim-lang.org/features.html
huh, hello world of 41 kb. Must be because of garbage collection.


I'm not a Nim expert (just started learning it).
The interesting thing about Nim is it compiles to C.
Feel free to examine the generated C code.

Or improve the Nim runtime efficiency Smile
Post 15 Sep 2017, 08:51
View user's profile Send private message Reply with quote
vivik



Joined: 29 Oct 2016
Posts: 425
Can't really improve Nim beyond certain point. If Nim compiles to C, then it has flaws of C I'd like to fix. Namely being unable to receive multiple return values from a function. (You can do that, but it's not supported directly, you must pass variable's address as one of arguments. It's pretty ugly. Compiler probaly can optimize that away, but I have no idea if it actually does that.)
Post 18 Sep 2017, 08:50
View user's profile Send private message Reply with quote
vivik



Joined: 29 Oct 2016
Posts: 425
I wonder if Edit and Continue is patented. I found this, but it's ocr and some figures are not shown: https://www.google.com/patents/WO2015200235A1?cl=en . It's also pretty new, but that function replacing technique is around 15 years old by now.
Post 18 Sep 2017, 09:03
View user's profile Send private message Reply with quote
vivik



Joined: 29 Oct 2016
Posts: 425
Meanwhile you can check out http://ziglang.org/ , interesting how it listed both "no garbage collection" and "no dependency on C" right on the front page, two problems I complained about with Nim. It actually passed "4 kilobyte test", but it's still very very raw at the moment. Try donating to him, maybe it will speed things up.

I'm concerned about how that "exception on integer overflow" will look like, need to look at generated assembly. Need to compile the damn thing first.

Internally depends on llvm, and with windows it depends on either visual studio or mingw, I guess for the final assembly->binary and for headers.

The "comptime" feature is really promising, it's zig's way of killing preprocessor for good, and replacing C++ templates. Also, I like how it's goal seems to "simplify and replace C". My goal is to simplify and replace assembly without compromising anything.

Also check out https://luapower.com/winapi , it seems to pass the "interactive" requirement. Don't think the resulting exe file is good though.

There is also Idlewild https://board.flatassembler.net/topic.php?t=18704 , don't think it passes either requirement, but it's focus is also gamedev. Crossplatform, written in haskell. Confused on how to install this thing, so haven't tried it yet.
Post 29 Sep 2017, 07:51
View user's profile Send private message Reply with quote
vivik



Joined: 29 Oct 2016
Posts: 425
Maybe in another 6 months.
Post 26 Oct 2017, 21:50
View user's profile Send private message Reply with quote
vivik



Joined: 29 Oct 2016
Posts: 425
I'm concerned that Zig thinks that exceptions are useless. I thought so too before, but I think they can actually speed program up. If used with care.

Another thing is that Zig claims to compete with c, but still uses llvm for all code generation. It could be a limiting factor, too many operations in the middle, it can affect compilation speed. It also supports too many processors and oses, which could mean it wouldn't use os native functionality properly.

That I really like about Zig is, oddly enough, how it handles switches. You can use ranges, you can use else, and not having everything covered is a compile-time error. You can mark one of cases as unreachable, and then it will be a runtime error.

About Idlewild, it's an interesting language, simple but still pretty capable. It only compiles to a 64bit assembly, which I for some reason avoid. I'm trying to make 32bit windows games, since it will run everywhere anyway.

My progress with luajit is that I got it running. At first I recompiled it myself, and some programs broke because my compiled luajit had no proper manifest. I finally see what they are for. I'll probably never use manifest files, ever.

I need to make my own. I have no idea how much time I still have.
Post 07 Nov 2017, 12:04
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15976
Location: Qo'noS
vivik wrote:
I'm concerned about how that "exception on integer overflow" will look like, need to look at generated assembly.
Perhaps using the dedicated x86 instruction INTO? Note that there is no equivalent INTC for unsigned overflow. Nor for that matter any other generic INTcc for any other condition code variations.
Post 07 Nov 2017, 12:11
View user's profile Send private message Visit poster's website Reply with quote
vivik



Joined: 29 Oct 2016
Posts: 425
revolution wrote:
vivik wrote:
I'm concerned about how that "exception on integer overflow" will look like, need to look at generated assembly.
Perhaps using the dedicated x86 instruction INTO? Note that there is no equivalent INTC for unsigned overflow. Nor for that matter any other generic INTcc for any other condition code variations.


Didn't knew INTO existed, Thanks, it could come in handy one day.


vivik wrote:
I'm concerned about how that "exception on integer overflow" will look like, need to look at generated assembly. Need to compile the damn thing first.


It's only a debug feature, release version goes without those.

vivik wrote:

Internally depends on llvm, and with windows it depends on either visual studio or mingw, I guess for the final assembly->binary and for headers.


Looks like visual studio is only needed for libc. Maybe one day zig will work without libc, technically it can to some extent. I still don't quite understand what libc does other than some annoying initializations you can't get rid of. Looks like work on it is in plans.

I'm looking for a chit chat and a reason to not work, ain't I?
Post 07 Nov 2017, 20:38
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15976
Location: Qo'noS
vivik wrote:
I still don't quite understand what libc does other than some annoying initializations you can't get rid of.
It provides all the things like printf and other OS specific related functions. That is the theory anyway.
Post 08 Nov 2017, 01:53
View user's profile Send private message Visit poster's website Reply with quote
vivik



Joined: 29 Oct 2016
Posts: 425
Found a language that passes the 4kb test. https://en.wikipedia.org/wiki/PureBasic

Only if you use winapi directly though, I guess using any library unavoidably increases size.
Post 24 Apr 2018, 18:14
View user's profile Send private message Reply with quote
vivik



Joined: 29 Oct 2016
Posts: 425
The thing that is necessary to connect assembly programs with high level programs are custom calling conventions. Just specifying which registry (and stack space) contains which variable, which registers you should preserve, and which registers are ok to overwrite. Register allocation is a complicated matter, too complicated to run on every compilation. Compilation should run in two steps: deciding which calling convention to use (whole program wide, and probably half manually), and then compile each function in isolation. Deciding calling conventions should run as rarely as possible, and reused as often as possible.

Another, probably too complicated to do feature, is using local variables from other functions. Instead of just passing an addresses of those local variables from caller to callee, you may tell that those variables are always on [esp+4] [esp+8] [esp+c] (or always in eax). Tricky to do, probably should be done only manually.

This should make code a little bit smaller. Like, 2-4%, i guess?
Post 24 Apr 2018, 19:49
View user's profile Send private message Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2302
Location: Usono (aka, USA)
FPC supports various calling conventions (default: "register", same as Delphi) including "pascal" and "cdecl", so you can link in C code with it. It also supports inline assembly instructions. Plus, I've already mentioned before that it has a smartlinker (for Windows, even built-in, also built-in assembler, no external as/ld normally needed).
Post 25 Apr 2018, 01:06
View user's profile Send private message Visit poster's website Reply with quote
vivik



Joined: 29 Oct 2016
Posts: 425
@rugxulo
Not enough. Need to create your own conventions, not just use a set of compiler provided ones.

I can't tell my compiler that it doesn't need to save any register whatsoever in main(), it keeps saving some.
Post 25 Apr 2018, 08:56
View user's profile Send private message Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 362
Location: Belarus
vivik wrote:
@rugxulo
Not enough. Need to create your own conventions, not just use a set of compiler provided ones.

I can't tell my compiler that it doesn't need to save any register whatsoever in main(), it keeps saving some.

Don’t remember if there’s some support of this in standard C/C++ but at least in Pascal/Delphi you’re free to replace a subroutine body with an asm...end statement which lets you write a subroutine with virtually any calling convention you wish.

Although there’re little to no means to describe custom calling conventions in HLLs anyway, so why bothering with them while size-coding if you’ll still have to write assembly code?
Post 26 Apr 2018, 20:41
View user's profile Send private message Visit poster's website Reply with quote
vivik



Joined: 29 Oct 2016
Posts: 425
>in Pascal/Delphi you’re free to replace a subroutine body with an asm...end statement which lets you write a subroutine with virtually any calling convention you wish.

Demonstrate that please. Write a function that accepts a number in eax, and returns two numbers in eax and ecx. Provide disassembly listing for the result.

Wait, this is for asm only? I hoped to write the procedure in hll, and only specify interfaces in asm. So that I can call hll code from asm.
Post 28 Apr 2018, 12:39
View user's profile Send private message Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 362
Location: Belarus
vivik wrote:
Wait, this is for asm only? I hoped to write the procedure in hll, and only specify interfaces in asm. So that I can call hll code from asm.

What would be the purpose? What exactly would you specify in asm? A code that would internally copy parameters from places specified by your custom calling conventions to places HLL-compiled code expects them to be? Then what would you win while losing in terms of code size and performance? Or do you mean you want to specify custom calling convention and let the HLL compiler do its job? Then again, the code might be more optimal if you don’t get on the compiler’s way.

Calling convention is a more low-level concept that should not be explicitly configurable in HLL since it ruins the whole idea of HLL. If you want an HLL, use one of the predefined ones; if you want a custom one, feel free to switch to assembly and create everything you wish keeping track of every single bit. Otherwise it looks like you’re trying to pull a splinter out of your finger with an excavator.
Post 28 Apr 2018, 20:55
View user's profile Send private message Visit poster's website Reply with quote
vivik



Joined: 29 Oct 2016
Posts: 425
Custom calling convention is needed for connecting assembly language and hll language properly. Just the need to push variables to stack (when you could just pass them in registers) kind of defeats the point of writing some function in assembly.

Pseudocode:

Code:
func do_something([eax] int par1, [ecx] int par2) : [eax] int res {
    res = par1 + par2
}    


If you specify that some registers are trashed by this function, they will be saved before entering the function and restored after this function (or maybe this register just wouldn't be used outside for some time, for 5 or more function calls in a row). If some registers are marked as preserved, they will be saved on entering the function (or somewhere in the middle), and restored at exiting it (or somewhere in the middle).

Ideally it will be the compiler who will decide a proper calling convention. But register allocation is a complex problem, probably only solvable by trial and error, and benchmarks.
Post 28 Apr 2018, 21:39
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15976
Location: Qo'noS
HLL don't have any concept of registers. That is really the point of an HLL: to separate the programmer from the intricacies of the underlying hardware. If you compile your code for ARM then eax has no meaning.

Of course, many HLLs don't actually succeed in completely separating the programmer from the hardware, but that is a failing of the specific HLL, not a failing of the concept.
Post 29 Apr 2018, 01:29
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2, 3  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


Copyright © 1999-2018, Tomasz Grysztar.

Powered by rwasa.