Hi!

I have been working on a making a new computer language the last 3 years.

The reason that I started to make this language, was that I have been in to making my own processors. And I realized that it would be quite futile to make own processors if I would not have any high level language for my processors.

I concluded that making a C compiler would be a bit to time consuming. But as I have not been totally satisfied with the languages available, I decided to make a new computer language instead.

It's a system programming language. And as I have always liked the clarity of assembler, so I made it closer to assembly than C is. And I also made it easier to learn than C.

I'm thinking it's about time to release this language.

To this date I have made the compiler to generate 6502 binaries, and binaries for a virtual machine. But now I'm thinking about making it compile for x86.

I'm thinking of releasing the language for free, or maybe make it open source. But I don't know what type of license that would be suitable.

To this point, I have been generating machine code directly. But I have been thinking if it would be an idea to generate assembly files that uses flat assembler. What restrictions would that impose on the language, and what benefits would It be to make assembler files instead of binaries directly.

Does flat assembler use any object format? and should I make my compiler compatible with that instead of making binaries or assembler code?

Do you have any thoughts on this?

I have no experience in writing x86 code, and I'm a bit perplexed with all modes that the x86 processor can work in, and all different names of the registers.

Where would be the best x86 mode to make my compiler to work with in the beginning?

At the moment I'm using Linux for i386.

And I'm also wondering if 64bit code a superset of 32 bit code?

I expect an advantage of using a separate layer for assembly would be to examine the generated assembly code with a normal text editor. You can then check to see what code your compiler generates before converting to binary. Also things like jump and call offsets can be computed and optimised by the assembler.

As for modes of operation, you don't really get to choose. The OS will dictate this for the most part. You could use 16-bit code but it is unlikely to be useful for anything but DOS or a custom OS. 32-bit code would be the most compatible with many operating systems. And 64-bit mode might be necessary in some circumstances but it can be suboptimal if not used to its full potential.

64-bit code is not really a superset of 32-bit code, there are some things you can't do with 64-bit that 32-bit can (like short addressing and stack instructions), but mostly these differences are minor, so practically you can think of it as a superset.

Since you are using Linux then you can use fasm to generate ELF binary formats directly.

Does windows and Linux use different modes of operation?

What instructions should my compiler avoid, if If I would like the generated code to be as compatible with 32bit and 64bit code as possible?

And is there thing to think about, if I would like the generated code more compatible with Linux and Windows?

I can sacrifice speed, for higher similarity for the code to different platforms. This so I have the rewrite the compiler as little as possible for different platforms.

And thoughts on this? And has any texts been written on this subject?

And where can I find good information on machine code?

Logos:
This sounds interesting.
I am making something similar.
So, is it possible to see the specifications for your language?

I don't know exactly what type of specification you are thinking about.

But it's a language that is more code optimized in it's nature than C. So the code gets more optimized than C right out of the box, without any optimization techniques.

But the language is smaller than C, and easier to read and understand.

It's has OOP capability. Personalty I don't like how other languages make use of OOP. The language syntax of other languages make people construct programs that is hugely inefficient, as the OOP capabilities hides what th compiler is actually doing.

It's easy to make the compiler generate code for different processors. The easy part is to make the compiler generate code for a new processor, the hard part is to to get the insight on the how the machine language for different processors actually work.

I would like to make something more concise available soon. But I don't know where to start. I'm a bit unmotivated at the moment. The compiler is made in Javascript, but I have been converting it to C code lately, and is almost ready.

One thing that hinders me to release the compiler and full language specification, is that I don't have support for x86 right now. I don't want it to be available at the release of the language. So I want that as much as possible is available for the language, when I go totally public.

Thanks!

If you want to write both 64 and 32 bit code then you will have to make your code different. There are fundamental differences in addressing that can't be made similar. For arithmetic you can make code to operate for both but you limit the capabilities of 64 bit by doing that.

Some OSes are only 32 bit and can't run 64 bit code. Other OSes are 64 bit and will run both 32 bit and 64 bit code. Outputting 32 bit code is the most compatible form, and unless you really need 64 bit code for some particular purpose then it is often not worthwhile to use in any measurable way.

Well, then It would probably be sufficient if I make my compiler output 32bit x86 code only for starters.

Is there a great difference in execution speed between 32bit, 18bit and 8bit instructions?

Yes there is. But it depends upon what you are doing. In practice I wouldn't worry about such things until performance becomes an issue. Getting a program to work correctly is far more important than making it 2% faster IMO.