On Thursday 04 October 2001 11:40 pm, Gibbs Tanton - tgibbs wrote:
> >Well, that obviously should be MAX_whatever and MIN_whatever.
> >But sufficient for now, since that's probably a configure thing.
>
> Yes and No. If our inline constants are always going to be 32 bits then 2
> ** 31 should alwa
On Thursday 04 October 2001 11:40 pm, Gibbs Tanton - tgibbs wrote:
> >Well, that obviously should be MAX_whatever and MIN_whatever.
> >But sufficient for now, since that's probably a configure thing.
>
> Yes and No. If our inline constants are always going to be 32 bits then 2
> ** 31 should alwa
Oops...after looking at the code closer I take this back...we do need to
find our own "ptrcast_t" type. I'm replacing the size_t with ptrcast_t and
adding a typedef size_t ptrcast_t to the config_h.in file. I'll then let
Brent work out what to really put there :)
-Original Message-
From
Bryan wrote --
>> Ok, I was put in a burlap sack and beaten for my first attempt at
>>this;
>> hopefully this attempt will go better. Based on everyone's (read:
Dan's)
>> comments I have changed the patch to NOT move integer constants to the
>> constant table. Instead, the assembler dies if you
On Thursday 04 October 2001 03:51 pm, Gibbs Tanton - tgibbs wrote:
> Ok, I was put in a burlap sack and beaten for my first attempt at this;
> hopefully this attempt will go better. Based on everyone's (read: Dan's)
> comments I have changed the patch to NOT move integer constants to the
> consta
On Thursday 04 October 2001 02:22 pm, Dan Sugalski wrote:
... answers.
Excellent. Thanks for your patience!
--
Bryan C. Warnock
[EMAIL PROTECTED]
Oops...I meant OpCode.pm ... not OpFunc.pm
Sorry for the confusion.
-Original Message-
From: Gregor N. Purdy
To: Gibbs Tanton - tgibbs
Cc: '[EMAIL PROTECTED] "'
Sent: 10/4/2001 7:40 PM
Subject: Re: [PATCH] process_opfunc.pl cleanup
Tanton --
> This patch makes process_opfunc.pl use Opf
Tanton --
> This patch makes process_opfunc.pl use Opfunc.pm for all of its opcode
> related information. Therefore, it no longer needed to parse interp_guts.h
> or opcode_table. Also, I removed the $nvivsize from Opcode.pm (it wasn't
> being used anyway as process_opfunc.pl was recalculating i
This patch makes process_opfunc.pl use Opfunc.pm for all of its opcode
related information. Therefore, it no longer needed to parse interp_guts.h
or opcode_table. Also, I removed the $nvivsize from Opcode.pm (it wasn't
being used anyway as process_opfunc.pl was recalculating it.) I think this
Brent Dax:
# '$make test' is still acting up on Win32, but even 'perl
# t/harness' now
# is reporting an error.
But not if you run perl t/op/stacks.t. Ugh.
--Brent Dax
[EMAIL PROTECTED]
Configure pumpking for Perl 6
They *will* pay for what they've done.
'$make test' is still acting up on Win32, but even 'perl t/harness' now
is reporting an error.
C:\autotest\parrot>perl t/harness
t/op/basic..ok
t/op/bitwiseok
t/op/integerok
t/op/number.ok
t/op/stacks.NOK 5# Failed test (Parrot/Test.pm at line 74)
# got: 'Seem to
When I run make test, I get a bunch of things like this:
t/op/number.NOK 20# Failed test (Parrot/Test.pm at line 74)
# got: 'PackFile_Constant_clear: Unrecognized type ' during
unpack!
'
# expected: '0.50
-0.50
'
t/op/number.NOK 21# Failed test (Parrot/
Andy Dougherty:
# In perl.perl6.internals, you wrote:
# >Looks like long long is no longer a problem, but long double
# still is.
# >That's okay--Itanium is bouncing up and down in glee compared to
# >yesterday.
#
# Can you check if sizeof(long double) is 12 or 16? I think there are
# still pla
Well, barring some real abuse that the testing and config system need. :)
Count VMS as OK, and I'll work on getting things patched up so it doesn't
need hand-massaging after the fact.
Dan
--"it's like this"
Automated smoke report for patch Oct 4 07:00:01 2001 UTC
v0.01 on dec_osf using gcc version 2.8.1
O = OK
F = Failure(s), extended report at the bottom
? = still running or test results not (yet) available
Build failures during: - = unknown
c = Configure, m = make, t =
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> At 12:48 PM 10/4/2001 -0500, Gibbs Tanton - tgibbs wrote:
>> This is what my initial patch addressed. If opcode_t is always 32
>> bits, but we allow the native integer type to be 64 bits, then we
>> cannot have inlined integers.
At 12:43 PM 10/4/2001 -0400, Bryan C. Warnock wrote:
>Within t/, I count 42 instances of an integer constant being used as
>something other than a jump or branch offset.
Fair enough, but they're not going to be representative of the ultimate
usage patterns, so I don't know that it's a good idea
At 01:25 PM 10/4/2001 -0400, Andy Dougherty wrote:
>On Thu, 4 Oct 2001, Dan Sugalski wrote:
>
> > > > Sort of. They're guaranteed to be as big as the native integer you've
> > > > chosen to build Parrot with, and at least 32 bits.
> > >
> > >Ok, but does "long long" count as a "native integer"?
>
Ok, that makes sense. Thanks!
-Original Message-
From: Dan Sugalski
To: Gibbs Tanton - tgibbs; 'Andy Dougherty '
Cc: '[EMAIL PROTECTED] '
Sent: 10/4/2001 12:52 PM
Subject: RE: moving integer constants to the constant table
At 12:48 PM 10/4/2001 -0500, Gibbs Tanton - tgibbs wrote:
>This
At 12:48 PM 10/4/2001 -0500, Gibbs Tanton - tgibbs wrote:
>This is what my initial patch addressed. If opcode_t is always 32 bits, but
>we allow the native integer type to be 64 bits, then we cannot have inlined
>integers.
Sure we can. We just can't have inlined integer constants outside the ran
This is what my initial patch addressed. If opcode_t is always 32 bits, but
we allow the native integer type to be 64 bits, then we cannot have inlined
integers. Instead, we have to move the integers out into the constant
section. Therefore, it would seem that we must force sizeof( opcode_t) ==
In perl.perl6.internals, you wrote:
>Looks like long long is no longer a problem, but long double still is.
>That's okay--Itanium is bouncing up and down in glee compared to
>yesterday.
Can you check if sizeof(long double) is 12 or 16? I think there are
still places that assume sizeof(numval)/si
On Thu, 4 Oct 2001, Dan Sugalski wrote:
> > > Sort of. They're guaranteed to be as big as the native integer you've
> > > chosen to build Parrot with, and at least 32 bits.
> >
> >Ok, but does "long long" count as a "native integer"?
>
> Yup, if that's what you configured perl with.
Ok, last qu
At 12:58 PM 10/4/2001 -0400, Andy Dougherty wrote:
>On Thu, 4 Oct 2001, Dan Sugalski wrote:
>
> > > > Parrot guarantees you can embed 32-bit signed integer constants in the
> > > > instruction stream, and that's it. These constants are used to load up
> > > > integer registers, sure, but they're a
On Thu, 4 Oct 2001, Dan Sugalski wrote:
> > > Parrot guarantees you can embed 32-bit signed integer constants in the
> > > instruction stream, and that's it. These constants are used to load up
> > > integer registers, sure, but they're also used for jump offsets. Integer
> > > *variable* constan
At 12:43 PM 10/4/2001 -0400, Andy Dougherty wrote:
>On Thu, 4 Oct 2001, Dan Sugalski wrote:
>
> > Parrot guarantees you can embed 32-bit signed integer constants in the
> > instruction stream, and that's it. These constants are used to load up
> > integer registers, sure, but they're also used for
On Thursday 04 October 2001 12:05 pm, Dan Sugalski wrote:
> At 11:29 AM 10/4/2001 -0400, Bryan C. Warnock wrote:
> >Just the fact that we needed this patch in the first place indicates that
> >we're not doing *nearly* enough talking beforehand of some of the
> >particulars of Dan's overall design.
On Thu, 4 Oct 2001, Dan Sugalski wrote:
> Parrot guarantees you can embed 32-bit signed integer constants in the
> instruction stream, and that's it. These constants are used to load up
> integer registers, sure, but they're also used for jump offsets. Integer
> *variable* constants should go
At 11:27 AM 10/4/2001 -0500, Gibbs Tanton - tgibbs wrote:
>Okey dokey...this patch is scratched; thanks for the feedback. However, I
>will probably issue another one soon that makes sure that intval is never
>used in the bytecode, only opcode_t.
Keen, I like that. Hopefully this'll be the last r
Looks like long long is no longer a problem, but long double still is.
That's okay--Itanium is bouncing up and down in glee compared to
yesterday.
Automated smoke report for patch Oct 4 07:00:01 2001 UTC
v0.01 on linux using cc version 2.96-ia64-000717 snap
001117
O = OK
F = Fa
Okey dokey...this patch is scratched; thanks for the feedback. However, I
will probably issue another one soon that makes sure that intval is never
used in the bytecode, only opcode_t.
-Original Message-
From: Dan Sugalski
To: [EMAIL PROTECTED]; Gibbs Tanton - tgibbs; '[EMAIL PROTECTED]
> This patch moves integer constants to the constant table if the size
chosen
> for integers is not the same as the size chosen for opcodes.
It still leaves room for trouble. I suggestion we move everything that can
not be hold by int32_t out of opcode stream. The need for 64-bit constant
are rar
At 11:29 AM 10/4/2001 -0400, Bryan C. Warnock wrote:
>Just the fact that we needed this patch in the first place indicates that
>we're not doing *nearly* enough talking beforehand of some of the
>particulars of Dan's overall design.
That's the thing, though--we *don't* need this patch, not for in
Dan Sugalski:
# At 02:56 PM 10/4/2001 +0100, Simon Cozens wrote:
# >Can't we just use a hints file? :(
#
# Give me a day or so and I'll get it fixed properly. I'm used
# to that by
If you're hacking in that area, can you package the test.c stuff in a
subroutine for ease of hints overloading?
# n
> Any and all feedback is appreciated.
Personally, (and this isn't directed at you, Tanton) I'd rather see patches
that implement or bullet-proof the design and direction of Parrot, rather
than dictating them.
Part of any interative programming is figuring out exactly what you need to
do, a
On Thursday 04 October 2001 11:22 am, Dan Sugalski wrote:
> At 11:16 AM 10/4/2001 -0400, Bryan C. Warnock wrote:
> >Since pointers and integers are now considered incommensurate, the only
> >integer that can be safely converted to a pointer is the constant 0.
> > The result of converting any oth
At 11:16 AM 10/4/2001 -0400, Bryan C. Warnock wrote:
>Since pointers and integers are now considered incommensurate, the only
>integer that can be safely converted to a pointer is the constant 0. The
>result of converting any other integer to a pointer is machine dependent.
Since the only place
At 07:16 PM 10/4/2001 +0400, Timur Safin wrote:
>ptrdiff_t
> Signed integral type of the result of subtracting two pointers.
Ah, signed. Forgot about that.
size_t would be better, then. Absolute addresses are unsigned.
Dan
---
On Thursday 04 October 2001 11:08 am, Bryan C. Warnock wrote:
> In C9x, pointer-integer conversions (except for 0) aren't guaranteed for
> doing pointer arithmetic. (There was a good explanation that I ran across
> the other day, but I can't seem to find it now.)
Found it. The ANSI rationale
Hi Tanton,
My "Single User Specification, V.2" description isn't very detailed on this respect
(although it became pretty clear from the second sight). In the stddef.h document we
have following sentence:
"
ptrdiff_t
Signed integral type of the result of subtracting two pointers.
...
size_t
On Thursday 04 October 2001 10:48 am, Gibbs Tanton - tgibbs wrote:
> My ANSI and ISO Standard C reference manual (Plauger and Brodie) has it
> listed in with the comment:
>
> ptrdiff_t( which is the type of the subtract operator when its operands
> are both pointers to data objects ).
>
> Althoug
My ANSI and ISO Standard C reference manual (Plauger and Brodie) has it
listed in with the comment:
ptrdiff_t( which is the type of the subtract operator when its operands are
both pointers to data objects ).
Althought the book was written in 1989 I still think it applies.
Tanton
-Origi
On Thursday 04 October 2001 10:38 am, Gibbs Tanton - tgibbs wrote:
> INTVAL is used in memory and register to cast a pointer to an integer for
> mathematical operators. Instead of using INTVAL I propose we use
> ptrdiff_t or size_t (with my preference being the former). It would not
> be used an
At 09:38 AM 10/4/2001 -0500, Gibbs Tanton - tgibbs wrote:
>INTVAL is used in memory and register to cast a pointer to an integer for
>mathematical operators. Instead of using INTVAL I propose we use ptrdiff_t
>or size_t (with my preference being the former).
Is ptrdiff_t a base type that crept i
INTVAL is used in memory and register to cast a pointer to an integer for
mathematical operators. Instead of using INTVAL I propose we use ptrdiff_t
or size_t (with my preference being the former). It would not be used
anywhere else, just when we need to do mathematics on pointers. Both are
giv
At 02:45 PM 10/4/2001 +0100, Simon Cozens wrote:
>On Wed, Oct 03, 2001 at 01:18:04PM -0700, Brent Dax wrote:
> > foreach(grep {/pattern/} keys %Config) {
> > blah blah blah
> >
> > with:
> >
> > while($_=each %Config) {
> > next unless /pattern/;
> >
At 02:56 PM 10/4/2001 +0100, Simon Cozens wrote:
>Can't we just use a hints file? :(
Give me a day or so and I'll get it fixed properly. I'm used to that by
now... :) (There's a reason we just chucked it all and do our own thing to
configure stuff in perl 5 on VMS)
On Thu, Oct 04, 2001 at 02:45:31PM +0100, Simon Cozens wrote:
> Oh dear.
Even if I hack it wildly:
Alright, now I'm gonna check some stuff by compiling and running
a small C program. This could take a bit...
Use of uninitialized value at configure.pl line 140.
CC/DECC /float=ieee/Include=[]/Sta
At 09:43 AM 10/4/2001 -0400, Gregor N. Purdy wrote:
>Anyone object to me making 0.0.2 pass all its string tests without
>skipping any by making the print_s op into a noop if the register
>contains a NULL pointer?
Nope, not at the moment, since print_s is a throwaway op anyway.
On Wed, Oct 03, 2001 at 01:18:04PM -0700, Brent Dax wrote:
> foreach(grep {/pattern/} keys %Config) {
> blah blah blah
>
> with:
>
> while($_=each %Config) {
> next unless /pattern/;
> blah blah blah
Better, but it doesn't appear to ever *en
All --
Anyone object to me making 0.0.2 pass all its string tests without
skipping any by making the print_s op into a noop if the register
contains a NULL pointer?
I'm assuming that real I/O stuff comes later and can deal with SVs
and complaints about undef and so on.
--
I'm also curi
On Wed 03 Oct 2001 16:55, Simon Cozens <[EMAIL PROTECTED]> wrote:
> Any objections to a release today? How's Cygwin and Win32 looking?
AIX 4.3.3, vac 5.0.2.1
I had to manually add the -L/... from my config's ldflags to find the required
libs. After that:
i2:/pro/3gl/CPAN/parrot 108 > make test
52 matches
Mail list logo
