Introduce a C Compiler ucc

[Flash Gordon]

Spiros Bousbouras wrote, On 12/05/08 20:45:

It occurs to me that the opening poster did not say to
which standard he tries to conform. Unless "ANSI C"
has only one interpretation.

ANSI C has three main interpretations that I can think of. C89, C95 and
C99. It is most often used to mean C89 because ANSI standardised C first
in 1989, but they adopted the amendment that made it what is often known
as C95 and the 1999 standard, so ANSI C can certainly refer to them as
well. I find it hard to see how someone can use the term "ANSI C" to
refer to something other than the language as it has been standardised.

In any case, I would consider my comment valid whether the OP had
mentioned ANSI C, ISO C or just C.

 

[Keith Thompson]

Not on a Unix systems, where there isn't a "text mode".

Yes, it does apply. On an output operation, '\n' is replaced by an
ASCII LF character. (As it happens, '\n' already is an ASCII LF
character, so the replacement is particularly easy to do.)

 

[Spiros Bousbouras]

Not on a Unix systems, where there isn't a "text mode".

Yes there is , it's just no different from binary mode.

 

[Ian Collins]

Yes, it does apply. On an output operation, '\n' is replaced by an
ASCII LF character. (As it happens, '\n' already is an ASCII LF
character, so the replacement is particularly easy to do.)

'a' is also replaced by ASCII 'a' character, so what's the difference?

 

[Spiros Bousbouras]

Spiros Bousbouras wrote, On 12/05/08 20:45:



ANSI C has three main interpretations that I can think of. C89, C95 and
C99. It is most often used to mean C89 because ANSI standardised C first
in 1989, but they adopted the amendment that made it what is often known
as C95 and the 1999 standard, so ANSI C can certainly refer to them as
well. I find it hard to see how someone can use the term "ANSI C" to
refer to something other than the language as it has been standardised.

In any case, I would consider my comment valid whether the OP had
mentioned ANSI C, ISO C or just C.

I wasn't suggesting that your comment isn't valid
I was just curious which standard the OP is aiming
for.

 

[dj3vande]

'a' is also replaced by ASCII 'a' character, so what's the difference?

On ASCII systems, 'a' IS an ASCII 'a' character, in all contexts a C
program cares about.
In the context of I/O operations on a file opened in text mode, '\n' is
a C end-of-line character, which is converted to a host-OS end-of-line
on output. The fact that '\n' is an ASCII LF on ASCII systems and that
a Unix end-of-line is an ASCII LF at the end of the line makes the
conversion in this case trivial, but it IS a conversion.
(If that bothers you, consider: I have a char *, and I assign it to a
void *. Did a conversion happen? Did anything change as a result?[1])

In other words: On Unix, text mode is indistinguishable from binary
mode, but they are still two distinct modes.


dave

[1] Answers: Yes, a conversion happened; and yes, the type of the
pointer changed, but (unless you're on a DS9K.x where they've found
a loophole in the "same representation" requirement), nothing about
the actual bits making up the pointer has changed.

--
Dave Vandervies dj3vande at eskimo dot com

I am trying to move 3 bits from left to right with >> operator

Try holding the 3 bits in place, but shift the rest of your computer's memory
right to left. --Kaz Kylheku gives stupid answers to stupid questions in CLC

 

[Flash Gordon]

Spiros Bousbouras wrote, On 12/05/08 22:50:

I wasn't suggesting that your comment isn't valid
I was just curious which standard the OP is aiming
for.

OK, no problem.

 

[Keith Thompson]

'a' is also replaced by ASCII 'a' character, so what's the difference?

I don't recall claiming that there is one, but now that you mention it
.... actually, there isn't much of a difference. C99 7.19.2p2:

Characters may have to be added, altered, or deleted on input and
output to conform to differing conventions for representing text
in the host environment. Thus, there need not be a one-to-one
correspondence between the characters in a stream and those in the
external representation.

which covers both '\n' conversion and any conversion that might be
necessary for 'a' and other "ordinary" characters.

 

[dreamAnders]

Another problem: the program below reports

(test.c,10):error:struct or union member key doesn't exsist
(test.c,10):warning:conversion between pointer and integer without a cast

The error goes away if the "const" in the declaration of hp is
removed.

typedef struct hash_entry {
void *key;

} HashEntryStruct;

HashEntryStruct h;

int main(void)
{
const HashEntryStruct *hp = &h;
void *key = hp->key;

return 0;

}

-- Richard

Sorry this bug should be found before beta release. I wrote this
compiler at my spare time. Now I released its beta version
for more test. Now I received some feedbacks. If you will, hope that
you can send bug report to the address mentions at the document, or
you can submit it in sourceforge. I will try to set up the developer
community, update the release as soon as I can.

 

[dreamAnders]

That was quick!

But I still find the conditional operator doesn't work when the
second operand is 0 and the third is a pointer. (It now works
with them the other way round.)

I also have a problem with files that include sys/socket.h (this
is on Linux). I don't know if it's a problem with your compiler as
such or with the compatibility of the header files. I get this
error:

(/usr/include/bits/socket.h,165):error:Expect type specifier or qualifier
(/usr/include/bits/socket.h,165):error:Expect ;
(/usr/include/bits/socket.h,165):error:Expect type specifier or qualifier
(/usr/include/bits/socket.h,166):error:Undeclared identifier: __uint64_t

-- Richard

I checked the conditional operator problem and found the problem:a
typo error, shame me.
And for the socket.h, __uint64_t is the keyword in gcc, not in ucc.
Now ucc can't support 64bit.

And ucc does support a tricky method to work around these extensions
provided by gcc and vc.
If you will check the win32.c under driver, you will find the trick.

ucc can pass -keyword __uint64_t to ucl and add one line on the
keyword.h under ucl, the __uint64_t will work.
(Ugly, but now works)

 

[dreamAnders]

dreamAnders said:

<snip>




No shame at all. Your attitude to bug reports is commendably positive.

Now, I know you like anonymous unions, and I understand that you want to
support them in your compiler, and that's fine - but *using* them in your
compiler prevents me from compiling the compiler itself, because /my/
compiler doesn't support them.

Is there any likelihood that you will be releasing a version of the code
that does not require the host compiler to support anonunions?

I understand that you don't currently supply headers or a library, relying
on the host environment to supply these. Again, that's fine - but if you
were to make your compiler's source code conform to ANSI C (and especially
to the 1989 ANSI (1990 ISO) Standard), you *might* find that some people
in comp.lang.c would be very willing to help you fill that gap.

<snip>

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

That's great! I wish that some people in comp.lang.c to help me fill
that gap very much.
I will try to set up the developer community and evolve the project.

 

[Walter Banks]

I don't see why. If I wanted to write a compiler for some arbitrary
language X, I'd almost certainly choose C to do it, rather than X. So why
someone else can't choose to write a C compiler in language X rather than
C is beyond me.

C might not be the best language to implement a compiler in. C's weak typing
for example.

ucc is written in C as you have pointed out. It is an interesting project
that takes compilers back to some fundaments. Wenjun Wang is to be
commended for a nice piece of work.

Increasingly I expect we are going to see home grown Asian development
tools like ucc appearing.

Regards,

--
Walter Banks
Byte Craft Limited
Tel. (519) 888-6911
http://www.bytecraft.com
(e-mail address removed)

 

[Gene]

Also, I don't really like the fact that one must have Ms Studio to
compile the compiler Can't you distribute binaries?

You guys are real pieces of work. (I've replied only to the most
egregious.) This is obviously an initial offering of a substantial
personal project with lots of potential. The code really is a marvel
of clarity. (It reminds me of http://www.t3x.org/bits/s9fes/. And I
commend the literate programming style/tools of s9fes to
dreamAnders.)

Give the guy a break. Celebrate the new resource and--if you see fit
to criticize--do so with contributions that fix the apparent bugs or
omissions.

Jeez...

 

[dreamAnders]

You guys are real pieces of work. (I've replied only to the most
egregious.) This is obviously an initial offering of a substantial
personal project with lots of potential. The code really is a marvel
of clarity. (It reminds me ofhttp://www.t3x.org/bits/s9fes/. And I
commend the literate programming style/tools of s9fes to
dreamAnders.)

Give the guy a break. Celebrate the new resource and--if you see fit
to criticize--do so with contributions that fix the apparent bugs or
omissions.

Jeez...

Thanks a lot. The literate programming style/tools is interesting.

 

[dreamAnders]

Well, I had it lined up to download, but when I saw the messages
about total lack of comment, and then need for MS stuff, I took it
down.

Thank you for downloading. Well there is nearly no comments, but I
assure
you the code clarity is my important concern when writing the code.
I will add more comments later. When using on Windows, it needs MS
stuff.
btw, there are many students using MS stuff on China.

I need to set up a web about ucc as soon as possible. And I already
used subversion.
I hope there are people who will join the developer community to help
it grow.

 

[Noob]

btw, there are many students using MS stuff on China.

Tell them to give Red Flag Linux a try.
http://en.wikipedia.org/wiki/Red_Flag_Linux
(Don't waste your time on MS stuff.)

 

[João Jerónimo]

Also you should understand that by using extensions where they are not
required you are limiting the portability of your code more than
necessary and also preventing your compiler from being compiled with the
maximum warning levels supported by compilers. Try using gcc options
"-ansi -pedantic -Wall -Wextra" and see what it says. MS Visual Studio
also can be configured to give a lot of useful warnings.

I don't consider reasonable requiring -ansi on GCC for standard-compliant
code because it limits you to C89, witch lacks many useful features. I
would suggest -std=c99 instead.

JJ

 

[soscpd]

Hello DreamAnders, List

Nice work. Thanks for all your effort. If you like a hand to support
binary versions of your compiler, call-me on my inbox, directly. I can
pick some guys here to keep that builds updated and hosted.

Regards
Rafael