Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.misc > #2108 > unrolled thread

Testers wanted!

Back to article view | Back to comp.lang.misc

Contents

  Testers wanted! Nils M Holm <news2009@t3x.org> - 2014-05-01 13:41 +0000
    Re: Testers wanted! "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-01 17:08 -0400
      Re: Testers wanted! "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-01 17:15 -0400
      Re: Testers wanted! "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-01 18:14 -0400
        Re: Testers wanted! Nils M Holm <news2009@t3x.org> - 2014-05-02 06:23 +0000
          Re: Testers wanted! "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-02 06:13 -0400
            Re: Testers wanted! "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-02 06:38 -0400
            Re: Testers wanted! Nils M Holm <news2009@t3x.org> - 2014-05-02 18:23 +0000
              Re: Testers wanted! Nils M Holm <news2009@t3x.org> - 2014-05-02 18:42 +0000
                Re: Testers wanted! "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-02 21:02 -0400
                  Re: Testers wanted! Nils M Holm <news2009@t3x.org> - 2014-05-03 08:00 +0000
                    Re: Testers wanted! "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-03 08:33 -0400
                      Re: Testers wanted! Nils M Holm <news2009@t3x.org> - 2014-05-03 13:40 +0000
    Re: Testers wanted! "BartC" <bc@freeuk.com> - 2014-05-02 22:02 +0100
      Re: Testers wanted! Nils M Holm <news2009@t3x.org> - 2014-05-03 08:11 +0000
        Re: Testers wanted! "BartC" <bc@freeuk.com> - 2014-05-03 10:22 +0100
          Re: Testers wanted! Nils M Holm <news2009@t3x.org> - 2014-05-03 10:03 +0000
          Re: Testers wanted! "BartC" <bc@freeuk.com> - 2014-05-03 11:02 +0100
            Re: Testers wanted! Nils M Holm <news2009@t3x.org> - 2014-05-03 10:58 +0000
              Re: Testers wanted! "BartC" <bc@freeuk.com> - 2014-05-03 12:44 +0100
                Re: Testers wanted! Nils M Holm <news2009@t3x.org> - 2014-05-03 13:42 +0000
      Re: Testers wanted! Nils M Holm <news2009@t3x.org> - 2014-05-03 08:21 +0000
        Re: Testers wanted! Nils M Holm <news2009@t3x.org> - 2014-05-03 11:03 +0000
    Re: Testers wanted! Luuk <luuk@invalid.lan> - 2014-05-03 12:33 +0200
      Re: Testers wanted! Nils M Holm <news2009@t3x.org> - 2014-05-03 10:59 +0000
        Re: Testers wanted! Nils M Holm <news2009@t3x.org> - 2014-05-03 11:02 +0000
          Re: Testers wanted! Luuk <luuk@invalid.lan> - 2014-05-03 13:12 +0200
            Re: Testers wanted! Nils M Holm <news2009@t3x.org> - 2014-05-03 11:18 +0000
              Re: Testers wanted! Luuk <luuk@invalid.lan> - 2014-05-03 16:14 +0200
                Re: Testers wanted! Nils M Holm <news2009@t3x.org> - 2014-05-03 14:28 +0000
    Re: Testers wanted! "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-04 21:55 -0400
      Re: Testers wanted! Nils M Holm <news2009@t3x.org> - 2014-05-05 07:07 +0000
        Re: Testers wanted! "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-05 04:13 -0400
          Re: Testers wanted! "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-05 04:18 -0400
            Re: Testers wanted! "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-05 06:52 -0400
              Re: Testers wanted! Nils M Holm <news2009@t3x.org> - 2014-05-07 14:49 +0000
                Re: Testers wanted! "James Harris" <james.harris.1@gmail.com> - 2014-05-07 20:50 +0100
                  Re: Testers wanted! Nils M Holm <news2009@t3x.org> - 2014-05-08 08:37 +0000
                    Re: Testers wanted! "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-05-08 10:50 +0200
                      Re: Testers wanted! Nils M Holm <news2009@t3x.org> - 2014-05-08 08:55 +0000
                    Re: Testers wanted! "James Harris" <james.harris.1@gmail.com> - 2014-05-08 10:21 +0100
                      Re: Testers wanted! George Neuner <gneuner2@comcast.net> - 2014-05-08 13:43 -0400
      Re: Testers wanted! Luuk <luuk@invalid.lan> - 2014-05-05 20:29 +0200
        Re: Testers wanted! "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-05 19:09 -0400
          Re: Testers wanted! Nils M Holm <news2009@t3x.org> - 2014-05-12 07:06 +0000
            Re: Testers wanted! Nils M Holm <news2009@t3x.org> - 2014-05-12 16:18 +0000
              Re: Testers wanted! "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-12 20:00 -0400
                Re: Testers wanted! Nils M Holm <news2009@t3x.org> - 2014-05-13 14:24 +0000
                  Re: Testers wanted! "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-13 17:04 -0400
                    Re: Testers wanted! Nils M Holm <news2009@t3x.org> - 2014-05-14 16:50 +0000
                      Re: Testers wanted! "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-14 19:04 -0400
                        Re: Testers wanted! Nils M Holm <news2009@t3x.org> - 2014-05-16 09:39 +0000
                          Re: Testers wanted! "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-16 17:33 -0400
                            Re: Testers wanted! Nils M Holm <news2009@t3x.org> - 2014-05-17 20:25 +0000
                            Re: Testers wanted! "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-05-30 04:28 -0400

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#2167

BartC <bc@freeuk.com> wrote:
> I tried it with Linux/Ubuntu to get an idea of how it works. This OS is 
> running within Virtual Box under Windows, and I believe runs in x86 32-bit 
> mode (Windows itself is 64-bit).
> 
> It builds much more smoothly!

Good to hear!

> It managed to compile and run a Hello World program, but there is clearly 
> some gcc influence in there as the output was put in a.out.

a.out dates back to very early Unix systems and predates GCC by quite
a couple of years. It is actually SubC that calls the file that way,
but you can change it by adding

#define AOUTNAME "prefered-name"

to sys.h.

> I will try Mingw's gcc on the .s output under Windows to see what happens.

-- 
Nils M Holm  < n m h @ t 3 x . o r g >  www.t3x.org

[toc] | [prev] | [next] | [standalone]

#2153

BartC <bc@freeuk.com> wrote:
> targets/cg/cg386.c:6:18: fatal error: defs.h: No such file or directory
>  #include "defs.h"
>                   ^
> compilation terminated.
> makefile:50: recipe for target 'scc0' failed
> make: *** [scc0] Error 1
> 
> The file defs.h exists, but maybe it can't be accessed from that directory.

After having a look: it's probably the terminating CR/LF which the
preprocessor does not handle correctly. Yes, this is a bug.

-- 
Nils M Holm  < n m h @ t 3 x . o r g >  www.t3x.org

[toc] | [prev] | [next] | [standalone]

#2161

Nils M Holm <news2009@t3x.org> wrote:
> BartC <bc@freeuk.com> wrote:
> > targets/cg/cg386.c:6:18: fatal error: defs.h: No such file or directory
> >  #include "defs.h"
> >                   ^
> > compilation terminated.
> > makefile:50: recipe for target 'scc0' failed
> > make: *** [scc0] Error 1
> > 
> > The file defs.h exists, but maybe it can't be accessed from that directory.
> 
> After having a look: it's probably the terminating CR/LF which the
> preprocessor does not handle correctly. Yes, this is a bug.

Should be fixed in 2014-05-03.

-- 
Nils M Holm  < n m h @ t 3 x . o r g >  www.t3x.org

[toc] | [prev] | [next] | [standalone]

#2157

On 1-5-2014 15:41, Nils M Holm wrote:
> Hi all!
>
> I am currently migrating the individual ports of my SubC compiler
> from a non-optimizing back-end with left-to-right evaluation to an
> optimizing back-end with R-to-L evaluation. Needless to say, things
> *will* go wrong during this process.
>
> So what I am looking for is a few people who could invest a couple
> of minutes by downloading and trying the EXPERIMENTAL SubC version
> from
>
> http://www.t3x.org/subc/index.html
>
> I am mostly interested in the results for Linux-386, Linux-x86-64,
> and Windows-386 (MinGW). (Feel free to try other ports, too, but they
> are likely to cause some trouble at this point).
>
> It's not really that hard and would help me a lot. The basic
> prodecure is:
>
> ./configure # just a harmless script, no autoconf stuff
> cd src
> make test
> make tests
>
> and tell me where it went wrong (or that it went through without any
> problems).
>
> Any help would be appreciated!
>

luuk@asus:~/tmp/subc/src> make tests
./scc -o scc2 cexpr.c cg.c decl.c error.c expr.c gen.c main.c misc.c 
opt.c prep.c scan.c stmt.c sym.c tree.c
cmp scc scc2 && rm -f scc2
awk -f ../tests/ptest.awk <../tests/ptest.src >../tests/ptest.c
./scc0 -o ../tests/ptest ../tests/ptest.c && \
         ../tests/ptest && \
         rm ../tests/ptest
./scc0 -o ../tests/systest ../tests/systest.c && \
          (cd ../tests && ./systest) && \
         rm ../tests/systest
_time() returned 1399113128
./scc0 -o ../tests/libtest ../tests/libtest.c && \
         (cd ../tests && ./libtest) && \
         rm ../tests/libtest
luuk@asus:~/tmp/subc/src> uname -a
Linux asus.example.com 3.7.10-1.28-desktop #1 SMP PREEMPT Mon Feb 3 
14:11:15 UTC 2014 (c9a2c6c) i686 i686 i386 GNU/Linux
luuk@asus:~/tmp/subc/src>


it went OK on my 'Intel(R) Pentium(R) 4 CPU 2.80GHz'

[toc] | [prev] | [next] | [standalone]

#2159

Luuk <luuk@invalid.lan> wrote:
> luuk@asus:~/tmp/subc/src> make tests
> ./scc -o scc2 cexpr.c cg.c decl.c error.c expr.c gen.c main.c misc.c 
> opt.c prep.c scan.c stmt.c sym.c tree.c
> cmp scc scc2 && rm -f scc2
> awk -f ../tests/ptest.awk <../tests/ptest.src >../tests/ptest.c
> ./scc0 -o ../tests/ptest ../tests/ptest.c && \
>          ../tests/ptest && \
>          rm ../tests/ptest
> ./scc0 -o ../tests/systest ../tests/systest.c && \
>           (cd ../tests && ./systest) && \
>          rm ../tests/systest
> _time() returned 1399113128
> ./scc0 -o ../tests/libtest ../tests/libtest.c && \
>          (cd ../tests && ./libtest) && \
>          rm ../tests/libtest
> luuk@asus:~/tmp/subc/src> uname -a
> Linux asus.example.com 3.7.10-1.28-desktop #1 SMP PREEMPT Mon Feb 3 
> 14:11:15 UTC 2014 (c9a2c6c) i686 i686 i386 GNU/Linux
> luuk@asus:~/tmp/subc/src>

Great! Thanks!

-- 
Nils M Holm  < n m h @ t 3 x . o r g >  www.t3x.org

[toc] | [prev] | [next] | [standalone]

#2160

Nils M Holm <news2009@t3x.org> wrote:
> Luuk <luuk@invalid.lan> wrote:
> > luuk@asus:~/tmp/subc/src> uname -a
> > Linux asus.example.com 3.7.10-1.28-desktop #1 SMP PREEMPT Mon Feb 3 
> > 14:11:15 UTC 2014 (c9a2c6c) i686 i686 i386 GNU/Linux
> > luuk@asus:~/tmp/subc/src>
> 
> Great! Thanks!

You just turned green the Linux-x86-64 box on
http://www.t3x.org/subc/status.html

-- 
Nils M Holm  < n m h @ t 3 x . o r g >  www.t3x.org

[toc] | [prev] | [next] | [standalone]

#2162

On 3-5-2014 13:02, Nils M Holm wrote:
> Nils M Holm <news2009@t3x.org> wrote:
>> Luuk <luuk@invalid.lan> wrote:
>>> luuk@asus:~/tmp/subc/src> uname -a
>>> Linux asus.example.com 3.7.10-1.28-desktop #1 SMP PREEMPT Mon Feb 3
>>> 14:11:15 UTC 2014 (c9a2c6c) i686 i686 i386 GNU/Linux
>>> luuk@asus:~/tmp/subc/src>
>>
>> Great! Thanks!
>
> You just turned green the Linux-x86-64 box on
> http://www.t3x.org/subc/status.html
>


'Linux-x86-64 box'  ??
was that not already green?

;-)

[toc] | [prev] | [next] | [standalone]

#2163

Luuk <luuk@invalid.lan> wrote:
> On 3-5-2014 13:02, Nils M Holm wrote:
> > Nils M Holm <news2009@t3x.org> wrote:
> >> Luuk <luuk@invalid.lan> wrote:
> >>> luuk@asus:~/tmp/subc/src> uname -a
> >>> Linux asus.example.com 3.7.10-1.28-desktop #1 SMP PREEMPT Mon Feb 3
> >>> 14:11:15 UTC 2014 (c9a2c6c) i686 i686 i386 GNU/Linux
> >>> luuk@asus:~/tmp/subc/src>
> >>
> >> Great! Thanks!
> >
> > You just turned green the Linux-x86-64 box on
> > http://www.t3x.org/subc/status.html
> 
> 'Linux-x86-64 box'  ??
> was that not already green?
> 
> ;-)

Not a few minutes before now, or am I missing a joke here? :-)

-- 
Nils M Holm  < n m h @ t 3 x . o r g >  www.t3x.org

[toc] | [prev] | [next] | [standalone]

#2168

On 3-5-2014 13:18, Nils M Holm wrote:
> Luuk <luuk@invalid.lan> wrote:
>> On 3-5-2014 13:02, Nils M Holm wrote:
>>> Nils M Holm <news2009@t3x.org> wrote:
>>>> Luuk <luuk@invalid.lan> wrote:
>>>>> luuk@asus:~/tmp/subc/src> uname -a
>>>>> Linux asus.example.com 3.7.10-1.28-desktop #1 SMP PREEMPT Mon Feb 3
>>>>> 14:11:15 UTC 2014 (c9a2c6c) i686 i686 i386 GNU/Linux
>>>>> luuk@asus:~/tmp/subc/src>
>>>>
>>>> Great! Thanks!
>>>
>>> You just turned green the Linux-x86-64 box on
>>> http://www.t3x.org/subc/status.html
>>
>> 'Linux-x86-64 box'  ??
>> was that not already green?
>>
>> ;-)
>
> Not a few minutes before now, or am I missing a joke here? :-)
>

no, i compiled on 'i686 i686 i386 GNU/Linux'
and your response is about 'x86-64'

[toc] | [prev] | [next] | [standalone]

#2169

Luuk <luuk@invalid.lan> wrote:
> no, i compiled on 'i686 i686 i386 GNU/Linux'
> and your response is about 'x86-64'

Oops! 686 != x86-64, of course! That '6' in 686 gets me every time.

Thanks!

-- 
Nils M Holm  < n m h @ t 3 x . o r g >  www.t3x.org

[toc] | [prev] | [next] | [standalone]

#2176

On Thu, 01 May 2014 09:41:59 -0400, Nils M Holm <news2009@t3x.org> wrote:

> So what I am looking for is a few people who could invest a couple
> of minutes by downloading and trying the EXPERIMENTAL SubC version
> from
>

Well, I've been following the conversation on comp.compilers.
I decided to see what the older version did for reference.

FYI, for the older version (20140425) a diff of the binaries
scc and scc1 shows *NO* differences.  The sources are the same
too.  However, the test sequence "make ptest systest libtest"
fails the same way as tne newer version:

/bin/sh: line 2:  2897 Segmentation fault   ./libtest
make: *** [libtest] Error 139


So, what did you change from April 25th to May 4th? ...


Can you incrementally back out the changes?  I.e., can you go
through the backups and test each change one by one?

I would guess that any one of these changes could change some
address locations:


 From Changes differences:
...
2014-05-01 Added removal of zero offsets from address computation.
...
2014-04-xx Adapted ... to new calling convention.
...
2014-04-28 Removed varargs redefinition hack (no longer needed).
2014-04-28 Changed calling convention to standard C (right-to-left).
...

 From Todo differences:
- Rewrite crt0 module to remove GLIBC system call layer:
...
. fix & in setjmp() and longjmp()

 From Makefile differences in /src:
  opt.c tree.c has been added

declaration for _va_start changed

etc.


Are all the changed addresses in the binaries different by the
same amount? (I haven't checked.) I.e., fixed quantity of bytes?


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#2177

Rod Pemberton <dont_use_email@xnothavet.cqm> wrote:
> FYI, for the older version (20140425) a diff of the binaries
> scc and scc1 shows *NO* differences.  The sources are the same
> too.  However, the test sequence "make ptest systest libtest"
> fails the same way as tne newer version:

Now this is getting stranger and stranger!

> /bin/sh: line 2:  2897 Segmentation fault   ./libtest
> make: *** [libtest] Error 139

As said before, this is very likely due to signal(). The new
release (05-04) contains a test for this bug. There is even a
workaround, but it is extremely ugly.

> So, what did you change from April 25th to May 4th? ...

Thanks for the suggestion, but I think this is the wrong path.
One of the testers wrote me in private and told me that he could
reproduce that linking the *same* *objects* with GNU ld twice in
a row generates differing binaries.

And even if it did not, a compiler bug would not answer the
question why the assembly output for stages 2 and 3 is identical
(while the binaries are not).

> Are all the changed addresses in the binaries different by the
> same amount? (I haven't checked.) I.e., fixed quantity of bytes?

Good question! I will have a look.

BTW, the latest version uses a diff on the assembly output to
perform the triple test, in case you want to give it a try (or
anybody else wants).

-- 
Nils M Holm  < n m h @ t 3 x . o r g >  www.t3x.org

[toc] | [prev] | [next] | [standalone]

#2179

On Mon, 05 May 2014 03:07:09 -0400, Nils M Holm <news2009@t3x.org> wrote:
> Rod Pemberton <dont_use_email@xnothavet.cqm> wrote:

>> So, what did you change from April 25th to May 4th? ...
>
> Thanks for the suggestion, but I think this is the wrong path.
> One of the testers wrote me in private and told me that he could
> reproduce that linking the *same* *objects* with GNU ld twice in
> a row generates differing binaries.
>

Ok.  But, it seems to be consistend for both here.

> And even if it did not, a compiler bug would not answer the
> question why the assembly output for stages 2 and 3 is identical
> (while the binaries are not).

My point was that something changed the expected result.
It's possible, that it can be found if you work from good
results to bad.  I.e., a second option instead of attempting
to use logic to find and fix the problem, is to locate the point
at which things changed.

>> Are all the changed addresses in the binaries different by the
>> same amount? (I haven't checked.) I.e., fixed quantity of bytes?
>
> Good question! I will have a look.
>

A bunch from 'hexdump -C' differences seem to be 120 bytes different.

A 'readelf -a' of the program headers gives different load location
results.  The difference for readelf is 132 bytes. scc has a value
of 0x000176ee for one of it's load locations, while scc1 has 0x00017766.
I'm not that familiar with readelf, yet, so it may have more information.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#2180

On Mon, 05 May 2014 04:13:08 -0400, Rod Pemberton  
<dont_use_email@xnothavet.cqm> wrote:

>>> Are all the changed addresses in the binaries different by the
>>> same amount? (I haven't checked.) I.e., fixed quantity of bytes?
>>
>> Good question! I will have a look.
>>
>
> A bunch from 'hexdump -C' differences seem to be 120 bytes different.
>
> A 'readelf -a' of the program headers gives different load location
> results.  The difference for readelf is 132 bytes. scc has a value
> of 0x000176ee for one of it's load locations, while scc1 has 0x00017766.
> I'm not that familiar with readelf, yet, so it may have more information.
>

Other readelf output has 0x0001763e for scc, 0x000176b6 for scc1, for
the .text section.  That's the 120 bytes.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#2182

On Mon, 05 May 2014 04:18:07 -0400, Rod Pemberton  
<dont_use_email@xnothavet.cqm> wrote:
> On Mon, 05 May 2014 04:13:08 -0400, Rod Pemberton  
> <dont_use_email@xnothavet.cqm> wrote:

>>>> Are all the changed addresses in the binaries different by the
>>>> same amount? (I haven't checked.) I.e., fixed quantity of bytes?
>>>
>>> Good question! I will have a look.
>>>
>>
>> A bunch from 'hexdump -C' differences seem to be 120 bytes different.
>>
>> A 'readelf -a' of the program headers gives different load location
>> results.  The difference for readelf is 132 bytes. scc has a value
>> of 0x000176ee for one of it's load locations, while scc1 has 0x00017766.
>> I'm not that familiar with readelf, yet, so it may have more
>> information.
>>
>
> Other readelf output has 0x0001763e for scc, 0x000176b6 for scc1, for
> the .text section.  That's the 120 bytes.
>

Were you (we) looking at the correct object files?

The build builds four versions: scc0, scc1, scc, scc2.
The build compares scc and scc2, which are the same.
Then, the build deletes scc2.  I.e., isn't the equal
comparison proof that it's building correctly?
That's 3 stages after the 1st bootstrap version.

You had me diff scc and scc1.
scc1 is generated from scc0's objects.
scc  is generated from scc1's objects.
scc0's and scc1's objects are different.
Specifically:

opt.o scan.o sym.o misc.o prep.o tree.o

scc1 was compiled by scc0, but scc0 wasn't compiled
some form/version of scc.  scc0 was compiled by GCC.

It seems valid to me that binary from GCC compiled
code (scc0) wouldn't necessarily match that from
scc0 compiled code (scc1).  I.e., they're from
different compilers.

So, why do they match for the older version?  I.e.,
are you (we) looking at this wrongly? backwards?

Also, a bugfix for you.

Your src/Makefile is missing opt.c in the lint section.

'make lint' errors:

Both versions complain of implicit declaration for 'strdup'.
main.c 29:2 "newfilename"

Both versions complain of pointer from integer without a cast.
main.c 29:13 "newfilename"

The experimental version complains of parenthesis for '-'
   for '&' operand.
opt.c 29:4 "fold2"
  (missing parenthesis in case OP_MUL: section)

HTH,


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#2212

Rod Pemberton <dont_use_email@xnothavet.cqm> wrote:
> Were you (we) looking at the correct object files?

Hi Rod, you are raising a few very valid points here. I could not
reply in the past days, because I has some urgent personal business
to attend to.

However, I have a 64-bit box in the mail, so I will soon be able
to conduct some own experiments. I'll keep you all informed about
the results.

Nils

> The build builds four versions: scc0, scc1, scc, scc2.
> The build compares scc and scc2, which are the same.
> Then, the build deletes scc2.  I.e., isn't the equal
> comparison proof that it's building correctly?
> That's 3 stages after the 1st bootstrap version.
> 
> You had me diff scc and scc1.
> scc1 is generated from scc0's objects.
> scc  is generated from scc1's objects.
> scc0's and scc1's objects are different.
> Specifically:
> 
> opt.o scan.o sym.o misc.o prep.o tree.o
> 
> scc1 was compiled by scc0, but scc0 wasn't compiled
> some form/version of scc.  scc0 was compiled by GCC.
> 
> It seems valid to me that binary from GCC compiled
> code (scc0) wouldn't necessarily match that from
> scc0 compiled code (scc1).  I.e., they're from
> different compilers.
> 
> So, why do they match for the older version?  I.e.,
> are you (we) looking at this wrongly? backwards?
> 
> Also, a bugfix for you.
> 
> Your src/Makefile is missing opt.c in the lint section.
> 
> 'make lint' errors:
> 
> Both versions complain of implicit declaration for 'strdup'.
> main.c 29:2 "newfilename"
> 
> Both versions complain of pointer from integer without a cast.
> main.c 29:13 "newfilename"
> 
> The experimental version complains of parenthesis for '-'
>    for '&' operand.
> opt.c 29:4 "fold2"
>   (missing parenthesis in case OP_MUL: section)

-- 
Nils M Holm  < n m h @ t 3 x . o r g >  www.t3x.org

[toc] | [prev] | [next] | [standalone]

#2213

"Nils M Holm" <news2009@t3x.org> wrote in message 
news:bsuvfgFflr6U1@mid.individual.net...
> Rod Pemberton <dont_use_email@xnothavet.cqm> wrote:
>> Were you (we) looking at the correct object files?

...

> However, I have a 64-bit box in the mail, so I will soon be able
> to conduct some own experiments. I'll keep you all informed about
> the results.

Just an FYI: if you have a machine which is 64-bit capable but is running a 
32-bit OS you can still run 64-bit virtual guests using something like 
Oracle VirtualBox

  https://www.virtualbox.org/manual/ch03.html#intro-64bitguests

Not something I use now but I have set up a couple of these in the past on 
an Athlon X2 under 32-bit Windows.

James

[toc] | [prev] | [next] | [standalone]

#2218

James Harris <james.harris.1@gmail.com> wrote:
> Just an FYI: if you have a machine which is 64-bit capable but is running a 
> 32-bit OS you can still run 64-bit virtual guests using something like 
> Oracle VirtualBox

Good to know, thanks!  The box I get will probably be a 1 GHz
Core 2 Duo. Does this offer sufficient CPU power for virtualization?
RAM is not so much of a problem, since I would only install CLI-based
guests.

-- 
Nils M Holm  < n m h @ t 3 x . o r g >  www.t3x.org

[toc] | [prev] | [next] | [standalone]

#2219

On 8 May 2014 08:37:59 GMT, Nils M Holm wrote:

> James Harris <james.harris.1@gmail.com> wrote:
>> Just an FYI: if you have a machine which is 64-bit capable but is running a 
>> 32-bit OS you can still run 64-bit virtual guests using something like 
>> Oracle VirtualBox
> 
> Good to know, thanks!  The box I get will probably be a 1 GHz
> Core 2 Duo. Does this offer sufficient CPU power for virtualization?
> RAM is not so much of a problem, since I would only install CLI-based
> guests.

RAM could be a problem, because under 32-bit an application cannot get more
than 2GB (3GB with special settings in boot.ini), This will apply to
VirtualBox as well.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[toc] | [prev] | [next] | [standalone]

#2220

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> On 8 May 2014 08:37:59 GMT, Nils M Holm wrote:
> > James Harris <james.harris.1@gmail.com> wrote:
> >> Just an FYI: if you have a machine which is 64-bit capable but is running a 
> >> 32-bit OS you can still run 64-bit virtual guests using something like 
> >> Oracle VirtualBox
> > 
> > Good to know, thanks!  The box I get will probably be a 1 GHz
> > Core 2 Duo. Does this offer sufficient CPU power for virtualization?
> > RAM is not so much of a problem, since I would only install CLI-based
> > guests.
> 
> RAM could be a problem, because under 32-bit an application cannot get more
> than 2GB (3GB with special settings in boot.ini), This will apply to
> VirtualBox as well.

Yes, but a virtual FreeBSD without X11 typically needs only 256..512 MB
RAM, so 2 GB should be plenty.  I am more concerned about CPU power.
Host system will be FreeBSD.  Guests will be misc. BSDs, Debian, PCDOS,
*maybe* some old Windows to run MinGW on (2K or something).

-- 
Nils M Holm  < n m h @ t 3 x . o r g >  www.t3x.org

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.misc

csiph-web