BTW, Cygwin works fine (although -Wall issues a number of warnings related
to the printf flags).
-Original Message-
From: Simon Cozens
To: Gregor N. Purdy
Cc: '[EMAIL PROTECTED]'; [EMAIL PROTECTED]
Sent: 9/30/2001 3:21 PM
Subject: Re: NV Constants
On Sun, Sep 30, 2001 at 11:25:04AM -0400
Simon,
I'm completely confused by this,
1.) Why are you allocating sizeof(IV) instead of sizeof(NV)?
2.) What is the difference between
mem_sys_memcopy( &value, cursor, sizeof(NV) )
and allocating a new pointer and copying into it? They are both just
copying data into a pointer...does th
I would assume that you would want to embed IV constants if at all possible
because of a locality of reference cache bonus. Even if the opcode_t is 32
bit and IV is 64 bit, it should still be possible to embed the constants
into the stream. As for having smaller opcode_t values, I think the argum
I tested the patch on CygWin, Solaris SunOS 5.8, and Tru64. It passed on
all three systems.
Tanton
Ok, I've added (NV) to all of the integer trans ops arguments. See if that
helps.
-Original Message-
From: Michael G Schwern
To: Buggs
Cc: Gibbs Tanton - tgibbs; '[EMAIL PROTECTED] '
Sent: 9/28/2001 10:39 PM
Subject: Re: Solaris problems with trans.t
On Sat, Sep 29, 200
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
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
Thanks. Applied.
-Original Message-
From: Josh Wilmes
To: [EMAIL PROTECTED]
Sent: 9/19/2001 3:04 PM
Subject: [PATCH] mem_allocate_aligned explanation
This patch adds Dan Sugalski's explanation to the code.
Index: memory.c
===
This has been applied. Please rerun Configure.pl after updating.
Thanks!
Tanton
-Original Message-
From: Gibbs Tanton - tgibbs
To: '[EMAIL PROTECTED] '
Sent: 9/19/2001 1:15 PM
Subject: [REPATCH] changing IV to opcode_t
Ok, this patch changes from the union to a simple
To make Parrot pass (almost) all of the tests, also change the n => 2 line
in process_opfunc.pl to a 1. On my Tru64 box, it passed all tests but the
overflow ones.
-Original Message-
From: Gibbs Tanton - tgibbs
To: '[EMAIL PROTECTED]'
Sent: 9/19/2001 2:05 PM
Subject: 64
Nope, I think you've messed up your math there :)
The current version multiplies the number of numeric types seen by two
(because (unportably) most numbers are twice the size of integers). Yours
does not take that into account.
-Original Message-
From: Pat Eyler
To: [EMAIL PROTECTED]
S
Ok, after class I will fix and repatch. Making opcode_t a simple type that
is configurable.
Thanks!
Tanton
-Original Message-
From: Dan Sugalski
To: Simon Cozens; ''[EMAIL PROTECTED]' '
Sent: 9/19/2001 10:14 AM
Subject: Re: [PATCH] changing IV to opcode_t!!
At 03:58 PM 9/19/2001 +0100,
Do you know if there happens to be anything weird about the alignment on
this machine?
-Original Message-
From: Josh Wilmes
To: Gibbs Tanton - tgibbs
Cc: '[EMAIL PROTECTED]'
Sent: 9/19/2001 12:34 AM
Subject: Re: Purify machine
solaris 2.7
--Josh
At 0:13 on 09/19/2001
What type of machine is the hourly purify running on. It keeps dieing with
a SIGBUS on most set_n_nc calls (meaning invalid alignment). This is really
bad. I would like to know the type of an NV as well as the sizeof NV,
sizeof IV, and sizeof void*.
Thanks!
Tanton
Ok...let me try to get this straight and I'll repatch...
opcode_t should be something that will represent the native opcode type. In
most cases it should just be long; however, there might be special systems
where it is somehting different (int, long long, etc...). IV should be a
union with a l
All the tests are great! But, could everyone please remember to put an
"end" at the end of each assembly test...cygwin doesn't like it if you
don't. I think I've patched all the ones up to this point.
Thanks!
Tanton
I would vote no. HOWEVER, I would think that the user should have the
option to turn on checking for malformed bytecode (i.e. Safe mode). In the
default case, I think the bytecode should be assumed well formed and no
extra checking be performed.
-Original Message-
From: Damien Neil
To:
Applied.
-Original Message-
From: Simon Cozens
To: Gibbs Tanton - tgibbs
Cc: '[EMAIL PROTECTED]'
Sent: 9/18/2001 3:53 PM
Subject: Re: [PATCH] changing IV to opcode_t!!
On Tue, Sep 18, 2001 at 03:31:11PM -0500, Gibbs Tanton - tgibbs wrote:
> 8. I would love someone to tes
Earlier there was some discussion about changing
typedef long IV
to
typedef union {
IV i;
void* p;
} opcode_t;
This patch does that. I have tested it on cygwin, solaris 5.8, and solaris
8. I would love someone to test it on Tru64 and Win32.
If this is NO LONGER WANTED, just let me know.
or strings). Does that
sound ok?
Tanton
-Original Message-
From: Jarkko Hietaniemi
To: Timur Safin
Cc: Gibbs Tanton - tgibbs; 'Josh Wilmes '; [EMAIL PROTECTED]
Sent: 9/17/2001 3:24 PM
Subject: Re: "Automated" Purify Run
On Tue, Sep 18, 2001 at 12:06:32AM +0400, Timur Safin
eing 0, but this way
it will be portable.
Does this sound ok?
Tanton
-Original Message-
From: Jarkko Hietaniemi
To: Gibbs Tanton - tgibbs
Cc: 'Josh Wilmes '; ''[EMAIL PROTECTED] ' '
Sent: 9/17/2001 2:26 PM
Subject: Re: "Automated" Purify Run
On
system
it does. So, it appears we have two options:
1.) Ignore the error
2.) Put an if statement around the print and have it not print if the
string is of length 0.
Any sugestions or other ideas?
-Original Message-
From: Josh Wilmes
To: Gibbs Tanton - tgibbs
Cc: ''[EMAIL
The hourly should be fine...can you do me one other favor and run the
following c snippet through Purify:
int main() {
char* c = (char*)malloc(0);
printf( "%.*s\n", 0, c );
return 0;
}
-Original Message-
From: Josh Wilmes
To: Gibbs Tanton - tgibbs
Cc: '[EMAIL PROTE
It looks like to me that this is only running every day. Can we get it to
run every hour? Perhaps even on demand? I think I have fixed all of the
memory access errors but one.
-Original Message-
From: Josh Wilmes
To: [EMAIL PROTECTED]
Sent: 9/15/2001 5:16 PM
Subject: "Automated" Purif
Wearing my coding standard police hat -
You should remove your cuddled else statements:
i.e. if {
} else {
}
becomes
if {
}
else {
}
other than that, it looks good.
-Original Message-
From: Gregor N. Purdy
To: [EMAIL PROTECTED]
Sent: 9/17/2001 11:37 AM
Subje
Things work fine for me on cygwin...just be sure that you use cc instead of
ld. Also, you probably don't want to include any libraries. As for the
Manifest I haven't had any problems.
-Original Message-
From: Dan Sugalski
To: [EMAIL PROTECTED]
Sent: 9/17/2001 9:10 AM
Subject: Time for a
Yep, you were right...I made a patch for you and applied it :)
Thanks!
Tanton
Philip Kendall wrote:
* The trickier one: with the above two changes, test and test2 work,
but test3 tries to pop a non-existent stack frame. In Parrot_pop_i,
should the fragment:
if (chunk_base->prev) {
-
From: Ask Bjoern Hansen
To: [EMAIL PROTECTED]
Sent: 9/17/2001 7:16 AM
Subject: Re: Half-completed parrot/parrot.h conversion?
[EMAIL PROTECTED] (Dan Sugalski) writes:
> At 11:31 AM 9/14/2001 -0500, Gibbs Tanton - tgibbs wrote:
> >The patch assumes that your source code directory
Ok, here is the rule based makefile...
-Original Message-
From: [EMAIL PROTECTED]
To: Gibbs Tanton - tgibbs
Cc: '[EMAIL PROTECTED] '
Sent: 9/16/2001 2:49 PM
Subject: Re: [PATCH]Makefile.in
This should be done with an implicit rule or a pattern rule.
By putting all the expl
Here is a potential patch for all of the non documented opcodes.
It is a patch for parrot_assembly.pod
Thanks!
Tanton
-Original Message-
From: Simon Cozens
To: Dan Sugalski
Cc: [EMAIL PROTECTED]
Sent: 9/16/2001 11:12 AM
Subject: Re: Op documentation versus implementation
On Sun, Sep 16
Brent,
This patch allows the Makefile to work for me...if the
$(CC) -o $*$(O) -c $*.c
line is not below each .c file cygwin's make does not do the right thing and
does not make properly. This patch adds those lines. If you have a better
way to do it, I would be glad to implement that instead.
I don't think anyone objects to this...I vote go ahead and move the .h files
and modify Makefile.in according to Brent's email.
Tanton
-Original Message-
From: Gregor N. Purdy
To: Gibbs Tanton - tgibbs
Cc: 'Robert Spier '; '[EMAIL PROTECTED]"&#x
giving a 40% gain in both cases.
-Original Message-
From: Gibbs Tanton - tgibbs
To: 'Simon Cozens '; '[EMAIL PROTECTED] '
Sent: 9/16/2001 10:39 AM
Subject: RE: Op cost models
Yeah, I ran a test where I substituted a huge switch statement with all
of
the operations inli
Yeah, I ran a test where I substituted a huge switch statement with all of
the operations inlined for the function calls and I went from 27 seconds to
21 seconds on the benchmark.
-Original Message-
From: Simon Cozens
To: [EMAIL PROTECTED]
Sent: 9/16/2001 10:01 AM
Subject: Op cost models
It seems to me that this might eventually get out of hand...could there
possibly be some way to automate the generation of a family of opcodes? For
example:
MANUAL_OP_FAMILY eq_T1_T2 {
if( T1 == T2 ) {
RETURN(P3);
}
else {
RETURN(P4);
}
} OVER(i, ic, n, nc)
Note that I'm not pro
Ok, I just updated every .c and .h file to include the new coding standard.
I also updated most of the .pl files to use Parrot_Interp instead of
Perl_Interp. Please refresh your copy of the files.
I will try to watch things as they go in and make coding standard changes
immediately from now on s
> Never mind 'portable' for now, currently it's not even *working* on
> 64-bit platforms
You might try putting an ! after the l in the assembler pack type and see if
that fixes things. Right now, it is going to be putting opcodes out in 32
bits. Since Tru64 is 64 bits, a long is going to be
I don't know, I always liked seeing them separate. I'll change it to $Id:$
to take up less space.
-Original Message-
From: Russ Allbery
To: [EMAIL PROTECTED]
Sent: 9/15/2001 2:08 PM
Subject: Re: coding standards
Gibbs Tanton <- tgibbs <[EMAIL PROTECTED]>> w
Oh yeah...good point...:)
This patch has been applied.
Thanks!
-Original Message-
From: Will Coleda
To: Gibbs Tanton - tgibbs
Cc: '[EMAIL PROTECTED] '
Sent: 9/15/2001 12:33 PM
Subject: Re: Difficulties
Um... with the current setup, there IS no Makefile until you run
Configur
I haven't had any problem with my instead of use vars...can you send me the
test program that blows up?
-Original Message-
From: Uri Guttman
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: 9/15/2001 8:57 AM
Subject: Re: Difficulties
> "BD" == Brent Dax <[EMAIL P
You actually don't want to add the Makefile.in patch. Brent Dax submitted a
patch that puts the correct -I./include in the Configure.pl file. If you
don't still have the patch I can forward it to you.
Tanton
-Original Message-
From: Gregor N. Purdy
To: Gibbs Tanton -
The README really doesn't have to mention Configure.pl because when you do
make test_prog it will run Configure.pl for you (at least it is supposed to
:)
-Original Message-
From: Will Coleda
To: [EMAIL PROTECTED]
Sent: 9/15/2001 12:13 AM
Subject: Difficulties
The README doesn't mention
I have modified assemble.pl to do a slightly different form of
lookup...basically, it takes the op and gets all operations that have op as
a base (followed by (_([ins]c?)|p)+). Then, it goes through each candidate
and compares the arguments declared in opcode_table to the arguments
actually give
Sorry...forgot the tabs...this one should be right.
memory.c
Below is memory.c changed to support all (I think) of the coding standards.
Please look it over and let me know. Once the powers that be give the ok, I
will try to change all the source files to the standard.
Thanks!
Tanton
/* Memory.c
* Copyright: (When this is determined...it will go here)
Since we are so early in the game, I'm not sure if it really matters whether
we keep the version information or not. Does anyone have a problem with me
deleting the header files and readding them under include/parrot/. or is the
general concensus moving the RCS files?
Also, would anyone like to
Ok, my previous patch to assemble.pl caused somethings to core dump...I
promise this one won't :) It fixes the problem with numeric values having
the wrong pack type. Also, config_h.in was changed to typedef ${iv} double
NV to typedef ${nv} NV
Index: assemble.pl
The patch assumes that your source code directory is named parrot. This may
have been an invalid assumption, but it is going to be hard to do this patch
unless we agree on the name of the source directory.
-Original Message-
From: Gregor N. Purdy
To: [EMAIL PROTECTED]
Sent: 9/14/2001 11:
test3.pasm needed an end at the end of the file. Here is the patch
This should fix one of the bugs reported by purify.
Index: test3.pasm
===
RCS file: /home/perlcvs/parrot/t/test3.pasm,v
retrieving revision 1.1
diff -u -r1.1 test3.p
Will the coding standard get assigned a PDD number and be put into CVS?
Just wondering,
Tanton
I think the substr in strnative.c is incorrectly growing the destination
string. The following is a patch to fix it. It also uses the previous
patch for function names...so it needs to be applied after that patch.
Index: strnative.c
==
This patch implements some of the coding standards in an earlier PDD.
Functions such as Allocate_Aligned were changed to lowercase, and all
functions in memory.{h,c} had mem_ prepended to them. The only thing I
didn't really try to fix were the #define's being lowercase (such as
sys_memcopy). I
Because of some of the changes to the assembler...my patch no longer applies
cleanly. Therefore, I'm resubmitting it. When we changed assemblers, the
new assembler did not correctly support the transcendental math
functions...this patch fixes that.
Index: assemble.pl
==
This patch allows 0-9 in the opcode name (for atan2 and log10 etc...). It
also uses the pack_type hash for the pack instead of the real_type.
Index: assemble.pl
===
RCS file: /home/perlcvs/parrot/assemble.pl,v
retrieving revision 1.
Forgot to mention that this patch works with doubles (8 bytes) because that
is what the disassembler was set up with. However, both print_n and
Configure.pl seem to prefer long doubles (12 bytes). I have no clue which
one ya'll want to use, however, the patch below includes my previous patch,
bu
I've never submitted a patch before, but here goes...
Here are the transcendental math functions.
A couple of notes:
1.) I had to change the real type of n to a 'd' for it to output
the correct type in the pack in the assembler. It was already
a 'd' in the disassembler. I also change
Ah, apparently I selected long double for NV which doesn't work
correctly...double works fine however.
-Original Message-
From: Gibbs Tanton - tgibbs
To: '[EMAIL PROTECTED]'
Sent: 9/12/2001 11:32 PM
Subject: print_n doesn't work?
I have done all the trancendental
I have done all the trancendental math functions...but I'm having a problem
with print_n...I checked out a clean copy of parrot and ran the following
program:
set_n_nc N1, 1
print_n N1
end
and nothing prints out...
Can anyone else get this to print out anything...is it just me?
Also, test3.pas
58 matches
Mail list logo
