Index
> Projects and Ideas > more interactive c compiler?Goto page Previous 1, 2, 3 Next |
| Author |
|
|
TmX 14 Sep 2017, 14:28
vivik wrote:
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. |
|||
14 Sep 2017, 14:28 |
|
|
vivik 15 Sep 2017, 08:33
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. |
|||
|
15 Sep 2017, 08:33 |
|
|
vivik 18 Sep 2017, 08:50
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.)
|
|||
|
18 Sep 2017, 08:50 |
|
|
vivik 18 Sep 2017, 09:03
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.
|
|||
|
18 Sep 2017, 09:03 |
|
|
vivik 29 Sep 2017, 07:51
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. |
|||
|
29 Sep 2017, 07:51 |
|
|
vivik 26 Oct 2017, 21:50
Maybe in another 6 months.
|
|||
|
26 Oct 2017, 21:50 |
|
|
vivik 07 Nov 2017, 12:04
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. |
|||
|
07 Nov 2017, 12:04 |
|
|
revolution 07 Nov 2017, 12:11
vivik wrote: I'm concerned about how that "exception on integer overflow" will look like, need to look at generated assembly. |
|||
|
07 Nov 2017, 12:11 |
|
|
vivik 07 Nov 2017, 20:38
revolution wrote:
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:
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? |
|||
|
07 Nov 2017, 20:38 |
|
|
revolution 08 Nov 2017, 01:53
vivik wrote: I still don't quite understand what libc does other than some annoying initializations you can't get rid of. |
|||
|
08 Nov 2017, 01:53 |
|
|
vivik 24 Apr 2018, 18:14
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. |
|||
|
24 Apr 2018, 18:14 |
|
|
vivik 24 Apr 2018, 19:49
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? |
|||
|
24 Apr 2018, 19:49 |
|
|
rugxulo 25 Apr 2018, 01:06
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).
|
|||
|
25 Apr 2018, 01:06 |
|
|
vivik 25 Apr 2018, 08:56
@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. |
|||
|
25 Apr 2018, 08:56 |
|
|
DimonSoft 26 Apr 2018, 20:41
vivik wrote: @rugxulo 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? |
|||
|
26 Apr 2018, 20:41 |
|
|
vivik 28 Apr 2018, 12:39
>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. |
|||
|
28 Apr 2018, 12:39 |
|
|
DimonSoft 28 Apr 2018, 20:55
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. |
|||
|
28 Apr 2018, 20:55 |
|
|
vivik 28 Apr 2018, 21:39
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. |
|||
|
28 Apr 2018, 21:39 |
|
|
revolution 29 Apr 2018, 01:29
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. |
|||
|
29 Apr 2018, 01:29 |
|
| Goto page Previous 1, 2, 3 Next < Last Thread | Next Thread > |
Forum Rules:
|