I have attempted a "partial" (source only... and docs) release of 
0.99.00 on SF. Keith and Chuck's work has "languished" long enough!

https://sourceforge.net/project/showfiles.php?group_id=6208

Your mission, should you choose to accept it, is to download the source, 
attempt to compile it, test it if possible, and let us know how it goes.

Best,
Frank

Frank Kotler  <spamtrap@crayne.org> writes:
> I have attempted a "partial" (source only... and docs) release of
> 0.99.00 on SF. Keith and Chuck's work has "languished" long enough!
> 
> https://sourceforge.net/project/showfiles.php?group_id=6208
> 
> Your mission, should you choose to accept it, is to download the
> source, attempt to compile it, test it if possible, and let us know
> how it goes.

Is this the 64-bit capable one?

I've finally ordered my first 64-bit x86 machine (been Alpha 
since the 90s, and G5 for a couple of years, though), so if 
it is, I may well be forced to bang my head against the 137 
new opcode families since I last programmed x86 asm in anger.

Phil
-- 
"Home taping is killing big business profits. We left this side blank 
so you can help." -- Dead Kennedys, written upon the B-side of tapes of
/In God We Trust, Inc./.

On May 24, 2:38 pm, Frank Kotler  <spamt...@crayne.org> wrote:
> I have attempted a "partial" (source only... and docs) release of
> 0.99.00 on SF. Keith and Chuck's work has "languished" long enough!
>
> https://sourceforge.net/project/showfiles.php?group_id=6208
>
> Your mission, should you choose to accept it, is to download the source,
> attempt to compile it, test it if possible, and let us know how it goes.
>
> Best,
> Frank

Compiled with mingw/gcc and run without problems. However couldn't
compile with microsoft vc as that compiler does not have inttypes.h
c99 header (probably does not supports c99).

Greetings, Branimir.

Phil Carmody wrote:

....
>>https://sourceforge.net/project/showfiles.php?group_id=6208

....
> Is this the 64-bit capable one?

Yes. (also includes the "-f macho" output format for MacOSX - previously 
available only at Apple)

> I've finally ordered my first 64-bit x86 machine (been Alpha 
> since the 90s, and G5 for a couple of years, though), so if 
> it is, I may well be forced to bang my head against the 137 
> new opcode families since I last programmed x86 asm in anger.

Think of it as a "first person shooter" with moving targets! :)

I'm not up to 64-bits yet - seems to me that "more registers" is going 
to be more important than "wider registers", for most purposes(?). 
Everything will have to be completely re-thought/re-written to take 
advantage... I hope it turns out to be "fun"...

Best,
Frank

Branimir Maksimovic wrote:

....
>>https://sourceforge.net/project/showfiles.php?group_id=6208

....
> Compiled with mingw/gcc and run without problems.

Good!

> However couldn't
> compile with microsoft vc as that compiler does not have inttypes.h
> c99 header (probably does not supports c99).

Oh, oh! Nasm *does* require C99 support - since 0.98.39 (needed 
"snprintf" to get rid of a buffer overflow). C99 is apparently not as 
widely/fully supported as I'd been led to believe...

I understand MS has decided they're not happy with their tools being 
used in conjunction with open-source projects. I guess if you've got 
"boughten" tools the EULA allows it, but the "free" tools, maybe not. If 
you care, check your EULA.


Thanks for the feedback, Branimir!

We'll have to get some binary packages up there... soon...

Best,
Frank

On May 24, 9:37 pm, Frank Kotler  <spamt...@crayne.org> wrote:
> Branimir Maksimovic wrote:
>
> ...
>
> >>https://sourceforge.net/project/showfiles.php?group_id=6208
>
> ...
>
> > Compiled with mingw/gcc and run without problems.
>
> Good!
>
> > However couldn't
> > compile with microsoft vc as that compiler does not have inttypes.h
> > c99 header (probably does not supports c99).
>
> Oh, oh! Nasm *does* require C99 support - since 0.98.39 (needed
> "snprintf" to get rid of a buffer overflow). C99 is apparently not as
> widely/fully supported as I'd been led to believe...

Microsoft has their own "ms99" standard and I guess
they don;t care about c99.
If you want you can #ifdef some parts of the code:
eg __int8 - __int64 instead of standard header ints,
 or sprintf_s instead of snprintf ...

>
> I understand MS has decided they're not happy with their tools being
> used in conjunction with open-source projects. I guess if you've got
> "boughten" tools the EULA allows it, but the "free" tools, maybe not. If
> you care, check your EULA.

It says nothing about free tools. I use vc++ 2005
express which can be downloaded and used for free.
I guess problem with eula would be if I use some commercial
tools with it, or develop for platform other than windows.
But I can't see anything that prevents using it with free
tools.

Greetings, Branimir.

On May 24, 7:38 am, Frank Kotler  <spamt...@crayne.org> wrote:
> I have attempted a "partial" (source only... and docs) release of
> 0.99.00 on SF. Keith and Chuck's work has "languished" long enough!
>
> https://sourceforge.net/project/showfiles.php?group_id=6208
>
> Your mission, should you choose to accept it, is to download the source,
> attempt to compile it, test it if possible, and let us know how it goes.
>
> Best,
> Frank

If it trashes our hard drive, will you reimburse us ?

It's only 20 Gigs.

Andy

Hello,

Frank Kotler <spamtrap@crayne.org> schrieb:
> Branimir Maksimovic wrote:

>> However couldn't
>> compile with microsoft vc as that compiler does not have inttypes.h
>> c99 header (probably does not supports c99).
>
> Oh, oh! Nasm *does* require C99 support - since 0.98.39 (needed 
> "snprintf" to get rid of a buffer overflow). C99 is apparently not as 
> widely/fully supported as I'd been led to believe...

Yes, using c99 is bad. According to comp.lang.c, there is almost no
implementation that implements C99 correctly and completely.

Note that MS compilers have _snprintf() since MSVC6.

> I understand MS has decided they're not happy with their tools being 
> used in conjunction with open-source projects.

This is not true. The compilers from Microsoft are mainly C++ compiles
that happen to be able to compile C, too. Microsoft does not want to add
C specifics which make it incompatible with C++. Thus, if you want to
convince Microsoft to implement C99, make C99 become an integral part of
the next C++ standard, as far as possible.

There have been some statements from Microsoft employees on blogs and/or
newsgroups (I don't completely remember) that said so.

Regards,
   Spiro.

-- 
Spiro R. Trikaliotis                              http://opencbm.sf.net/
http://www.trikaliotis.net/                     http://www.viceteam.org/

Spiro Trikaliotis  <spamtrap@crayne.org> writes:
> Hello,
> 
> Frank Kotler <spamtrap@crayne.org> schrieb:
> > Branimir Maksimovic wrote:
> 
> >> However couldn't
> >> compile with microsoft vc as that compiler does not have inttypes.h
> >> c99 header (probably does not supports c99).
> >
> > Oh, oh! Nasm *does* require C99 support - since 0.98.39 (needed 
> > "snprintf" to get rid of a buffer overflow). C99 is apparently not as 
> > widely/fully supported as I'd been led to believe...
> 
> Yes, using c99 is bad. According to comp.lang.c, there is almost no
> implementation that implements C99 correctly and completely.

If lack of full bugfree implementations was a reason why use 
of a language is bad, then use of pretty much _all_ versions
of all languages is bad.

I can't think of any language I've used where the most 
popular implementations thereof wasn't either woefully
incomplete, or as buggy as a bag of cockroaches.

Phil
-- 
"Home taping is killing big business profits. We left this side blank 
so you can help." -- Dead Kennedys, written upon the B-side of tapes of
/In God We Trust, Inc./.

Andy wrote:
> On May 24, 7:38 am, Frank Kotler  <spamt...@crayne.org> wrote:
> 
>>I have attempted a "partial" (source only... and docs) release of
>>0.99.00 on SF. Keith and Chuck's work has "languished" long enough!
>>
>>https://sourceforge.net/project/showfiles.php?group_id=6208
>>
>>Your mission, should you choose to accept it, is to download the source,
>>attempt to compile it, test it if possible, and let us know how it goes.
>>
> 
> If it trashes our hard drive, will you reimburse us ?
> 
> It's only 20 Gigs.

If it trashes your hard drive, I personally will make both a one and a 
zero available to you for free internet download with an unlimited-copy 
royalty-free license.

Arrangement of those 20G worth of 1's and 0's, of course, is solely your 
own responsibility.

Ed

Hello Phil,

Phil Carmody wrote:

> Spiro Trikaliotis  <spamtrap@crayne.org> writes:
>> Yes, using c99 is bad. According to comp.lang.c, there is almost no
>> implementation that implements C99 correctly and completely.
>
> If lack of full bugfree implementations was a reason why use 
> of a language is bad, then use of pretty much _all_ versions
> of all languages is bad.

This might be. Nevertheless, sticking to C89/C90/C95, you are on the
safe side. If you use C99, you are asking for trouble whenever
portability is important for you. This is true for the moment, and it
does not look like it will change soon.

Regards,
   Spiro.

-- 
Spiro R. Trikaliotis                              http://opencbm.sf.net/
http://www.trikaliotis.net/                     http://www.viceteam.org/

In article <slrnf5olne.qgj.news-200605@news.trikaliotis.net>, 
spamtrap@crayne.org says...

[ ... ]

> This is not true. The compilers from Microsoft are mainly C++ compiles
> that happen to be able to compile C, too. Microsoft does not want to add
> C specifics which make it incompatible with C++. Thus, if you want to
> convince Microsoft to implement C99, make C99 become an integral part of
> the next C++ standard, as far as possible.

That's pretty much scheduled to be the case -- the current draft of C++ 
0x requires that a C++ compiler include essentially everything that's 
been added in the C99 library anyway. In the core language, some things 
like variadic macros will probably be added to C++ 0x, but other things 
like variable length arrays probably won't.
 

-- 
    Later,
    Jerry.

The universe is a figment of its own imagination.

Spiro Trikaliotis  <spamtrap@crayne.org> writes:
> Hello Phil,
> 
> Phil Carmody wrote:
> 
> > Spiro Trikaliotis  <spamtrap@crayne.org> writes:
> >> Yes, using c99 is bad. According to comp.lang.c, there is almost no
> >> implementation that implements C99 correctly and completely.
> >
> > If lack of full bugfree implementations was a reason why use 
> > of a language is bad, then use of pretty much _all_ versions
> > of all languages is bad.
> 
> This might be. Nevertheless, sticking to C89/C90/C95, you are on the
> safe side. If you use C99, you are asking for trouble whenever
> portability is important for you. This is true for the moment, and it
> does not look like it will change soon.

On what platform that you use will the latest version of gcc 
not compile? If none, what particular feature of C99 do you 
most use that the latest version of gcc does not support?

Phil
-- 
"Home taping is killing big business profits. We left this side blank 
so you can help." -- Dead Kennedys, written upon the B-side of tapes of
/In God We Trust, Inc./.

"Phil Carmody" <thefatphil_demunged@yahoo.co.uk> wrote in message 
news:87vee35niu.fsf@nonospaz.fatphil.org...

> On what platform that you use will the latest version of gcc
> not compile?

Um, like Windows?

-- 
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

"James Van Buskirk"  <spamtrap@crayne.org> writes:
> "Phil Carmody" <thefatphil_demunged@yahoo.co.uk> wrote in message 
> news:87vee35niu.fsf@nonospaz.fatphil.org...
> 
> > On what platform that you use will the latest version of gcc
> > not compile?
> 
> Um, like Windows?

I had no idea it was quite that backward. 

Then again, 'doze shouldn't need gcc - didn't Herb deliver 
what he promised?

Phil
-- 
"Home taping is killing big business profits. We left this side blank 
so you can help." -- Dead Kennedys, written upon the B-side of tapes of
/In God We Trust, Inc./.

In article <87wsyi6zq5.fsf@nonospaz.fatphil.org>, 
thefatphil_demunged@yahoo.co.uk says...
> "James Van Buskirk"  <spamtrap@crayne.org> writes:
> > "Phil Carmody" <thefatphil_demunged@yahoo.co.uk> wrote in message 
> > news:87vee35niu.fsf@nonospaz.fatphil.org...
> > 
> > > On what platform that you use will the latest version of gcc
> > > not compile?
> > 
> > Um, like Windows?
> 
> I had no idea it was quite that backward. 
> 
> Then again, 'doze shouldn't need gcc - didn't Herb deliver 
> what he promised?

I'm not sure exactly what he's talking about -- I have gcc 4.3.0 running 
just fine in Windows and that's not really even officially released yet.

As far as why I happen to use it: I'm really running the conceptGcc 
compiler, which includes a fair amount of C++ 0x "stuff" (especially 
concepts, in case that wasn't obvious) that isn't present in much of 
anything else. Of course, most of it is at least theoretically 
experimental, but it also still works fine for code that doesn't use its 
new features.

-- 
    Later,
    Jerry.

The universe is a figment of its own imagination.

"Jerry Coffin" <spamtrap@crayne.org> wrote in message 
news:MPG.20d1241b159e33479898f8@news.sunsite.dk...

> I'm not sure exactly what he's talking about -- I have gcc 4.3.0 running
> just fine in Windows and that's not really even officially released yet.

As a little experiment, could you please:

o Create a file with just one function, that only returns
  an integer value, say 12345678910

o Compile the function with gcc 4.3.0 with switches -m64 -S

o Show us the source code file and the resulting *.s file.

Thanks in advance.

-- 
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

Phil Carmody <thefatphil_demunged@yahoo.co.uk> wrote:

>Spiro Trikaliotis  <spamtrap@crayne.org> writes:
>> 
>> This might be. Nevertheless, sticking to C89/C90/C95, you are on the
>> safe side. If you use C99, you are asking for trouble whenever
>> portability is important for you. This is true for the moment, and it
>> does not look like it will change soon.
>
>On what platform that you use will the latest version of gcc 
>not compile? If none, what particular feature of C99 do you 
>most use that the latest version of gcc does not support?

It's interesting you would put it this way.  In my view, "the latest
version of gcc" is only one compiler, no matter how many operating system
it runs on.  "Portability" surely means "across different compilers", and
with that definition, Spiro's statement has some truth.
-- 
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

In article <b9WdnahsTYK0A_rbnZ2dnUVZ_q2pnZ2d@comcast.com>, 
spamtrap@crayne.org says...
> "Jerry Coffin" <spamtrap@crayne.org> wrote in message 
> news:MPG.20d1241b159e33479898f8@news.sunsite.dk...
> 
> > I'm not sure exactly what he's talking about -- I have gcc 4.3.0 running
> > just fine in Windows and that's not really even officially released yet.
> 
> As a little experiment, could you please:
> 
> o Create a file with just one function, that only returns
>   an integer value, say 12345678910
> 
> o Compile the function with gcc 4.3.0 with switches -m64 -S

Sorry, but I haven't compiled it to produce 64-bit output. With a bit of 
luck, I may be able to do that this weekend though...
 
> o Show us the source code file and the resulting *.s file.

Other than that minor detail, sure.  Here's the source code:

int trash() { 
	return 123456;
}

and the resulting output:

	.file	"junk.c"
	.text
	.align 2
..globl __Z5trashv
	.def	__Z5trashv;	.scl	2;	.type	32;	.endef
__Z5trashv:
	pushl	%ebp
	movl	%esp, %ebp
	movl	$123456, %eax
	popl	%ebp
	ret

With -fomit-frame-pointer the result is a bit nicer:

	.file	"junk.c"
	.text
	.align 2
..globl __Z5trashv
	.def	__Z5trashv;	.scl	2;	.type	32;	.endef
__Z5trashv:
	movl	$123456, %eax
	ret

I'm afraid I don't see much about this that would have anything to do 
with the version of the compiler though -- other than trivial 
differences in the syntax, I'm pretty sure the result would pretty much 
the same from essentially _any_ compiler.

-- 
    Later,
    Jerry.

The universe is a figment of its own imagination.

"Jerry Coffin" <spamtrap@crayne.org> wrote in message 
news:MPG.20d280eba6fa09339898f9@news.sunsite.dk...

>                            I'm pretty sure the result would pretty much
> the same from essentially _any_ compiler.

Of course not.  A compiler would issue native code:

C:\MASM>type junk.c
/* File: junk.c */

__int64 trash()
{
   return 12345678910LL;
}

/* End of file: junk.c */

C:\MASM>cl /Fa /c junk.c
Microsoft (R) C/C++ Optimizing Compiler Version 14.00.40310.41 for AMD64
Copyright (C) Microsoft Corporation.  All rights reserved.

junk.c

C:\MASM>type junk.asm
; Listing generated by Microsoft (R) Optimizing Compiler Version 
14.00.40310.41


include listing.inc

INCLUDELIB LIBCMT
INCLUDELIB OLDNAMES

PUBLIC  trash
; Function compile flags: /Odtp
_TEXT   SEGMENT
trash   PROC NEAR
; File c:\asm\masm\junk.c
; Line 5
        mov     rax, 12345678910                        ; 00000002dfdc1c3eH
; Line 6
        ret     0
trash   ENDP
_TEXT   ENDS
END

Obviously you are trying to be difficult by choosing a result
to return that doesn't involve setting the high bits of rax,
contrary to my request.

-- 
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

In article <iOmdnQvBk6Wkd_XbnZ2dnUVZ_s2vnZ2d@comcast.com>, 
spamtrap@crayne.org says...

[ ... ]

> Obviously you are trying to be difficult by choosing a result
> to return that doesn't involve setting the high bits of rax,
> contrary to my request.

Your request was:

> As a little experiment, could you please:
>
> o Create a file with just one function, that only returns
>  an integer value, say 12345678910

IMO, this does not make it at all clear that the size of integer in 
question is any particular importance at all. I had started work on 
building gcc supporting a 64-bit target, but when I saw this assinine 
accusation, I stopped working on it immediately, and I won't be starting 
again.

Acting like a jerk is not a good way to get somebody to do you a favor!

-- 
    Later,
    Jerry.

The universe is a figment of its own imagination.