Binary executable format for new language

[Mark R.Bannister]

Hi,

I'm currently designing a new language that compiles into a bytecode
format. I have a choice:

a) Design my own binary file format for the bytecode, symbols and data

b) Use an existing standard for the file format, if existing tools
would then be of use (but the format must not prevent my file from
being portable)


What do you think?

Cheers,
Mark.

 

[Joona I Palaste]

Hi,

I'm currently designing a new language that compiles into a bytecode
format. I have a choice:

a) Design my own binary file format for the bytecode, symbols and data

b) Use an existing standard for the file format, if existing tools
would then be of use (but the format must not prevent my file from
being portable)

What do you think?

Um, not to be rude or impolite or anything, but this doesn't really
have anything to do with C. Perhaps you could ask this on
comp.programming?

 

[Noah Roberts]

Hi,

I'm currently designing a new language that compiles into a bytecode
format. I have a choice:

a) Design my own binary file format for the bytecode, symbols and data

b) Use an existing standard for the file format, if existing tools
would then be of use (but the format must not prevent my file from
being portable)

Unless you are doing an interpreter like the JVM 'a' is not possible
afaik. The OS needs to know how to load and run your executable and
this is very platform specific. Most languages allow you to compile
into several different executable formats.

and yes, comp.programming would be a better group.

NR

 

[Glen Herrmannsfeldt]

Hi,

I'm currently designing a new language that compiles into a bytecode
format. I have a choice:

a) Design my own binary file format for the bytecode, symbols and data

b) Use an existing standard for the file format, if existing tools
would then be of use (but the format must not prevent my file from
being portable)

Are you expecting to compile C into this bytecode? If so, it might be on
topic in this group. There are some possibilities for the compiled code
that exclude the possibility of writing a C compiler.

Usually you will find more people interested in using it if you use an
existing system. That is one reason for language standards. For that
reason, I would prefer choice (b).

-- glen

 

[Dan Pop]

What was your C question?

Are you expecting to compile C into this bytecode? If so, it might be on
topic in this group.

By what kind of logic? Does this newsgroup deal with C compiler
internals?

Dan

 

[Joona I Palaste]

(snip)

By what kind of logic? Does this newsgroup deal with C compiler
internals?

It pretty much has to, Dan. It also has to deal with C++ and Java. Not
only that, but it also has to deal with gardening, car mechanics,
classic literature, discussion about whether bitter is better than
lager, and so on. We don't want to come across as elitistic snobs for
which nothing is good enough, do we?

 

[Peter Shaggy Haywood]

Groovy hepcat Mark R.Bannister was jivin' on 6 Nov 2003 09:52:25 -0800
in comp.lang.c.
Binary executable format for new language's a cool scene! Dig it!

I'm currently designing a new language that compiles into a bytecode
format. I have a choice:

a) Design my own binary file format for the bytecode, symbols and data

b) Use an existing standard for the file format, if existing tools
would then be of use (but the format must not prevent my file from
being portable)

What do you think?

I think this is off topic. I think you should find a more
appropriate place to post this. I think you should refrain from making
off topic posts in future.

--

Dig the even newer still, yet more improved, sig!

http://alphalink.com.au/~phaywood/
"Ain't I'm a dog?" - Ronny Self, Ain't I'm a Dog, written by G. Sherry & W. Walker.
I know it's not "technically correct" English; but since when was rock & roll "technically correct"?