--
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
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 and
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 about
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 for moderate to
From: Brent Dax [mailto:[EMAIL PROTECTED]]
Henrik Tougaard:
# --
# CORE PLATFORMS
# --
# OpenVMS (Alpha)
# ??
#
...[snip]...
As a stopgap measure,
($^O eq 'VMS' ? /Include=[.include] : -I./include)
ought to work
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
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 generally,
the
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
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, 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
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 the
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
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
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.
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 that
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.
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
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 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 yet
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
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
sure if
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.
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
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
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
IV, so
# 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 assume for
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 stdio.h
int main(void) {
int x = 511;
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 if
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'll
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 stdio.h
int main(void) {
int
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 will
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 PROTECTED]
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.pl
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 reports
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\parrotperl t/op/basic.t
1..5
not ok 1 - noop, end
# Failed test (t/op/basic.t at line 6)
### Got:
#=.
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 commit:
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
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. Stay
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 days
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
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
41 matches
Mail list logo
