Oops...meant to send this to the group.
-Original Message-
From: Gibbs Tanton - tgibbs
Sent: Wednesday, September 26, 2001 1:31 PM
To: 'Andrew Kuchling '; Gibbs Tanton - tgibbs
Subject: RE: new assemble.pl
Thanks! Applied.
-Original Message-
From: Andrew Kuchling
To: Gibbs T
I changed assemble.pl so that the 0b constants will work on versions of perl
prior to 5.6. The problem was that oct before 5.6 did not recognize 0b as a
valid prefix. Therefore, I created a separate function from_binary that
converts binary numbers to decimal numbers and I now call it instead of
On Thu, 27 Sep 2001, Andreas Buggs Hauser wrote:
> On Thursday 27 September 2001 01:27, Gregor N. Purdy wrote:
> > On Wed, 26 Sep 2001, Andreas Buggs Hauser wrote:
> > > On Wednesday 26 September 2001 23:09, Simon Cozens wrote:
> > > > On Wed, Sep 26, 2001 at 02:18:11PM -0400, Gregor N. Purdy
On Thursday 27 September 2001 01:27, Gregor N. Purdy wrote:
> On Wed, 26 Sep 2001, Andreas Buggs Hauser wrote:
> > On Wednesday 26 September 2001 23:09, Simon Cozens wrote:
> > > On Wed, Sep 26, 2001 at 02:18:11PM -0400, Gregor N. Purdy wrote:
> > > > I've just committed the changes I posted a few
On Wed, 26 Sep 2001, Andreas Buggs Hauser wrote:
> On Wednesday 26 September 2001 23:09, Simon Cozens wrote:
> > On Wed, Sep 26, 2001 at 02:18:11PM -0400, Gregor N. Purdy wrote:
> > > I've just committed the changes I posted a few days back that prepare
> > > for putting NVs in the const_table
> with CygWin everything works ok...however I get a ton of warnings for
> packfile.c that look like they need to be addressed...I'll look at them
> soon. Also, when I type make test it tells me that test doesn't need to do
> anything; this was happening before these changes, but I was wondering i
with CygWin everything works ok...however I get a ton of warnings for
packfile.c that look like they need to be addressed...I'll look at them
soon. Also, when I type make test it tells me that test doesn't need to do
anything; this was happening before these changes, but I was wondering if
anyone
On Wednesday 26 September 2001 23:09, Simon Cozens wrote:
> On Wed, Sep 26, 2001 at 02:18:11PM -0400, Gregor N. Purdy wrote:
> > I've just committed the changes I posted a few days back that prepare
> > for putting NVs in the const_table. Stay tuned for more, but here's
> > the bullets for this co
Some cleanup, plus:
* detects assembler errors
* better output when tests are run manually
and tests fail
Suggestions for the new output format are welcome
C:\Developement\perl6\parrot>perl t/op/basic.t
1..5
not ok 1 - noop, end
# Failed test (t/op/basic.t at line 6)
### Got:
#="."
On Wed, Sep 26, 2001 at 02:18:11PM -0400, Gregor N. Purdy wrote:
> I've just committed the changes I posted a few days back that prepare
> for putting NVs in the const_table. Stay tuned for more, but here's
> the bullets for this commit:
These are pretty huge changes. Can I get some status report
Makes Win32 use ExtUtils::Command::rm_f as a rm -f replacemnt.
Regards
Mattia
Index: Configure.pl
===
RCS file: /home/perlcvs/parrot/Configure.pl,v
retrieving revision 1.19
diff -u -2 -r1.19 Configure.pl
--- Configure.pl20
On Wed, 26 Sep 2001, Hong Zhang wrote:
>
> You are using the wrong flag. The expression in second is long long.
> So you should use flag "%llx". Since printf uses vararg, it is
> undefined behavior if there is type mismatch with argument.
Oops. :-)
Andy Dougherty [EMAIL PROTEC
On Wed, 26 Sep 2001, Andy Dougherty wrote:
[Spoiler below]
> On Wed, 26 Sep 2001, Hong Zhang wrote:
>
> > There should be no need. ~0xfff is singed int, which will be signed extended
> > by compilers as needed. Unless you are using a buggy compiler.
>
> Hehehe. Ok. Guess what the following w
You are using the wrong flag. The expression in second is long long.
So you should use flag "%llx". Since printf uses vararg, it is
undefined behavior if there is type mismatch with argument.
Hong
> Hehehe. Ok. Guess what the following will print:
>
> #include
> int main(void) {
> int x
Andy Dougherty:
# On Wed, 26 Sep 2001, Andy Dougherty wrote:
#
# > I posted a patch last week to change the 'l' to a 'q', but
# more generally,
# > the assumption that sizeof(opcode_t) == sizeof(IV) should
# probably be
# > removed and each should be computed independently. Perhaps
# late today I'
On Wed, 26 Sep 2001, Andy Dougherty wrote:
> I posted a patch last week to change the 'l' to a 'q', but more generally,
> the assumption that sizeof(opcode_t) == sizeof(IV) should probably be
> removed and each should be computed independently. Perhaps late today I'll
> have a chance to do that i
On Wed, 26 Sep 2001, Hong Zhang wrote:
> There should be no need. ~0xfff is singed int, which will be signed extended
> by compilers as needed. Unless you are using a buggy compiler.
Hehehe. Ok. Guess what the following will print:
#include
int main(void) {
int x = 511;
printf("x = %
> > ># > 0xf000 for 64 bit systems. With that changed
>
> > Don't bother. Make the constant be ~0xfff. :)
>
> Umm, are you sure? It's used in an integer context and masked against an
> IV, so you might need an 'int', a 'long', or a 'long long'. I'm unsure
> what type to portably
On Wed, 26 Sep 2001, Dan Sugalski wrote:
> ># > Tru64 core dumps because the value of MASK_CHUNK_LOW_BITS
> ># > 0xf000 for 64 bit systems. With that changed
> Don't bother. Make the constant be ~0xfff. :)
Umm, are you sure? It's used in an integer context and masked against an
All --
I've just committed the changes I posted a few days back that prepare
for putting NVs in the const_table. Stay tuned for more, but here's
the bullets for this commit:
* bytecode.[hc] removed. packfile.[hc] are the interface to the
packfile/bytecode file from C. May be renamed in the
I tested this on Tru64, SunOS 5.8, and CygWin. It worked on each of those
so I went ahead and committed it. If you have any problems, let me know and
I will fix or revert.
Thanks!
Tanton
I'm not sure this always works. On systems with 32 bit pointers but 64 bit
integers this might produce undesired results...I'm not sure though.
-Original Message-
From: Simon Cozens
To: [EMAIL PROTECTED]
Sent: 9/26/2001 12:15 PM
Subject: Re: Tru64 core dumps
On Wed, Sep 26, 2001 at 01:
On Wed, Sep 26, 2001 at 06:15:02PM +0100, Simon Cozens wrote:
> On Wed, Sep 26, 2001 at 01:11:56PM -0400, Dan Sugalski wrote:
> > Don't bother. Make the constant be ~0xfff. :)
>
> Oh yeah. *blush*.
All tests successful, 5 subtests skipped.
Yeah!
--
Writing software is more fun than working.
At 04:36 AM 9/26/2001 +0200, Buggs wrote:
>On Wednesday 26 September 2001 01:36, Dan Sugalski wrote:
> > At 05:00 PM 9/25/2001 -0400, Will Coleda wrote:
> > >In parrot_assembly.pod, line 135 seems to trail off...
> >
> > Hmmm. Could you paste in the offending bit? I'm not seeing it, so I'm not
> >
On Wed, Sep 26, 2001 at 01:11:56PM -0400, Dan Sugalski wrote:
> Don't bother. Make the constant be ~0xfff. :)
Oh yeah. *blush*.
--
It would be different if I had an actual ambition to be a corporate pitbull
and be the righteous, noble paperwork warrior tirelessly fighting for the
future vision
On Wed 26 Sep 2001 19:00, Andy Dougherty <[EMAIL PROTECTED]> wrote:
> On Wed, 26 Sep 2001, Brent Dax wrote:
>
> > Configure Man To The Rescue! (Trumpets sound, then stop abruptly.)
> > Now, how do I figure out if we're on a 64-bit system? :^)
>
> ivsize, nvsize, ptrsize, and opcode_t_size (as
At 09:46 AM 9/26/2001 -0700, Brent Dax wrote:
>Simon Cozens:
># On Wed, Sep 26, 2001 at 09:47:08AM -0500, Gibbs Tanton - tgibbs wrote:
># > Tru64 core dumps because the value of MASK_CHUNK_LOW_BITS
># is designed for a
># > 32 bit system. It needs to be changed in the Configure.pl
># script to be
On Wed, 26 Sep 2001, Brent Dax wrote:
> Configure Man To The Rescue! (Trumpets sound, then stop abruptly.)
> Now, how do I figure out if we're on a 64-bit system? :^)
ivsize, nvsize, ptrsize, and opcode_t_size (as yet uncomputed, but will be
needed) come to mind. A '64-bit' system is an impre
On Wed, Sep 26, 2001 at 09:46:42AM -0700, Brent Dax wrote:
> Now, how do I figure out if we're on a 64-bit system? :^)
$Config{ptrsize} == 8;
--
Some people claim that the UNIX learning curve is steep, but at least you
only have to climb it once.
Simon Cozens:
# On Wed, Sep 26, 2001 at 09:47:08AM -0500, Gibbs Tanton - tgibbs wrote:
# > Tru64 core dumps because the value of MASK_CHUNK_LOW_BITS
# is designed for a
# > 32 bit system. It needs to be changed in the Configure.pl
# script to be
# > 0xf000 for 64 bit systems. With th
On Wed, Sep 26, 2001 at 09:47:08AM -0500, Gibbs Tanton - tgibbs wrote:
> Tru64 core dumps because the value of MASK_CHUNK_LOW_BITS is designed for a
> 32 bit system. It needs to be changed in the Configure.pl script to be
> 0xf000 for 64 bit systems. With that changed it works fine.
Tru64 core dumps because the value of MASK_CHUNK_LOW_BITS is designed for a
32 bit system. It needs to be changed in the Configure.pl script to be
0xf000 for 64 bit systems. With that changed it works fine.
-Original Message-
From: Mattia Barbon
To: Simon Cozens
Cc: Gibbs Ta
Even with the old assembler, I get the correct answer. It might be
something with your version of perl. I'm using 5.6.1. I'll try to find a
5.005 version and retry.
-Original Message-
From: Mattia Barbon
To: Gibbs Tanton - tgibbs
Cc: ''[EMAIL PROTECTED] ' '
Sent: 9/26/2001 9:00 AM
Subj
I also get six, I miscommunicated that one.
-Original Message-
From: Simon Cozens
To: Gibbs Tanton - tgibbs
Cc: '[EMAIL PROTECTED]'
Sent: 9/26/2001 8:42 AM
Subject: Re: Tru64 core dumps
On Wed, Sep 26, 2001 at 08:42:52AM -0500, Gibbs Tanton - tgibbs wrote:
> I'm getting a core dump on T
Holy crap.
- Forwarded message from Andrew Kuchling <[EMAIL PROTECTED]> -
From: Andrew Kuchling <[EMAIL PROTECTED]>
Subject: [Python-Dev] Crude Python->Parrot compiler
To: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
X-Beenthere: [EMAIL PROTECTED]
X-Mailman-Version: 2.0.6 (101270)
Over
On Wed, 26 Sep 2001, Simon Cozens wrote:
>On Wed, Sep 26, 2001 at 08:42:52AM -0500, Gibbs Tanton - tgibbs wrote:
>> I'm getting a core dump on Tru64 for stacks.t. Does anyone else get this?
>
>Just the one? I'm getting six of the damned things.
The 01:00 UTC snapshot segfaulted on all tests beca
On Wed, 26 Sep 2001, Gibbs Tanton - tgibbs wrote:
>It works for me and looks to be ok, can you tell me why you think binary
>numbers are broken?
Sorry: I was unclear.
I meant: the current assembly is broken here ( I have perl 5.005 BTW )
( debugging shows that the register is set to zero instead
It works for me and looks to be ok, can you tell me why you think binary
numbers are broken?
-Original Message-
From: Mattia Barbon
To: Gibbs Tanton - tgibbs
Cc: '[EMAIL PROTECTED] '
Sent: 9/26/2001 2:44 AM
Subject: Re: new assemble.pl
On Wed, 26 Sep 2001, Gibbs Tanton - tgibbs wrote:
On Wed, Sep 26, 2001 at 08:42:52AM -0500, Gibbs Tanton - tgibbs wrote:
> I'm getting a core dump on Tru64 for stacks.t. Does anyone else get this?
Just the one? I'm getting six of the damned things.
--
Mohandas K. Gandhi often changed his mind publicly. An aide once asked him
how he could so
I'm getting a core dump on Tru64 for stacks.t. Does anyone else get this?
On Wed, 26 Sep 2001, Mattia Barbon wrote:
> Problem is that al line 159 it does:
>
> elsif ($c{ivsize} == 8) {
> $c{packtype_i} = 'q';
> $c{packtype_op} = 'l';
> }
>
I posted a patch last week to change the 'l' to a 'q', but more generall
Damien Neil [mailto:[EMAIL PROTECTED]] wrote:
> This is a far more error-prone interface in a number of ways
> (...)
I don't believe that with the proper tools and rules that this system will
be any more difficult to manage. All of the things that you stated as
disadvantages could be countered w
> From: Brent Dax [mailto:[EMAIL PROTECTED]]
> Henrik Tougaard:
> # > --
> # > CORE PLATFORMS
> # > --
> # > OpenVMS (Alpha)
> # > ??
> #
...[snip]...
> As a stopgap measure,
>
> ($^O eq 'VMS' ? " /Include=[.include]" : " -I./include")
Henrik Tougaard:
# > --
# > CORE PLATFORMS
# > --
# > OpenVMS (Alpha)
# > ??
#
# Fails during configure.pl:
...
# What flags would you like passed to your C compiler?
# [/Include=[]/Standard=Relax
# ed_ANSI/Prefix=All/Obj=.obj/NoList -I./incl
"Gregor N. Purdy" wrote:
> Michael --
>
> > I had more time to think about it, and I determined how a compute op-code
> > could be efficient.
> >
> > [snip]
>
> You wicked, wicked person! :)
>
> I'd like to see some benchmarks on that one vs. the most efficient
> possible hand-coded separate ops
On Wed, 26 Sep 2001, Buggs wrote:
>===
> Win32
>make ok / test ok
>(with caveats: nmake doesn't do 'test' correctly, and 'clean' doesn't
>work because of the 'rm' command)
use namke -a [1]; for the rm problem I posted a patch some time ago,
and Andy Dougherty posted anoter one abo
On Wed, 26 Sep 2001, Gibbs Tanton - tgibbs wrote:
>Attached is a new assemble.pl. No, it doesn't change anything, it only
>breaks the code up into easier to follow functions (which are commented). I
After looking at the old assembler code: Thanks!
>am going to test it on a few more platforms a
> --
> CORE PLATFORMS
> --
> OpenVMS (Alpha)
> ??
I have seen that a couple of times, and decied to locate the old VMS box we
have in the cellar somewhere, and give it a try:
Fails during configure.pl:
$ perl configure.pl
Subroutine ln red
48 matches
Mail list logo
