JIT info

Folks, JIT work's definitely proceeding in earnest and lots of interesting things are happening. (We can definitely use help from folks on non-x86 platforms) A word of warning, though--GCC 2.96 (which didn't really exist, but Red Hat shipped) really dislikes it. If you find your trials fail wi

[PATCH] The Code Police [1/

Until David Mitchell gets them online, we'll stick with obvious things, like line lengths. I, for the most part, left strings alone ('cause I''ll be anal with them separately), as well as some of the files. This is for *.c files. Index: interpreter.c ==

Re: [PATCH] The Code Police [1/

At 04:41 PM 12/29/2001 -0500, Bryan C. Warnock wrote: >Until David Mitchell gets them online, we'll stick with obvious >things, like line lengths. I, for the most part, left strings alone >('cause I''ll be anal with them separately), as well as some of the files. Cool, thanks. Did we giv

Re: Yet another switch/goto implementation

On Wed, Nov 07, 2001 at 05:15:14PM -0500, Dan Sugalski wrote: *) The program is fully parsed *) There are no string eval, do, or requires *) There are no symbolic references on the LHS of any assignment *) There is no use of MY within the block or in any subs c

Large string patch

First, I want to apologize for the size of this patch. I normally try to make bite size changes but this one just touched too many things. I still have a few enhancements to make but wanted to get this in before anyone else started hacking on the same pieces. This patch had a number of goals.

Re: [PATCH] The Code Police [1/

Hi. Since there is a code police now: I am sure that no one in his or her right mind would ever want something like opcode_t * code_start in beautified code. Of course, it's not a multiplication--we all know that--but when just skimming over the code it sure distracts towards this direc

Re: Large string patch

On Sat, Dec 29, 2001 at 06:25:33PM -1000, David & Lisa Jacobs wrote: > First, I want to apologize for the size of this patch. I normally try to > make bite size changes but this one just touched too many things. I still > have a few enhancements to make but wanted to get this in before anyone el

Re: [PATCH] The Code Police [1/

On Sat, 29 Dec 2001, Boris Tschirschwitz wrote: > I suggest > opcode_t* code_start So what does this declare: opcode_t* code_start, code_end; If you said two pointers to opcode_t then you just got fooled by your notation! If you want to move the '*' then it has to go to the RHS since

We're all just Parrot Troopers

I'm sure I was supposed to write something a little less terse than this, but I'm tired. We've not a lot folks. Balance the glitz work. It's still early, but we're getting glitter-heavy, quickly. There's a lot of work on Parrot going on, but not much work on Parrot, if you get my drift. I

Re: Large string patch

>From what I could tell, it looks like Dan put it in there as a potential GC hook when allocating the header of a string or PMC (see resources.c). My guess is that he is planning to fire off the GC from the interpreter. If that is the case and we need it back, let me know and I'll restore it. H

[Updated Patch] Core.ops pod, misc cleanups, and gcc -Wall

I've updated my last patch and split it into three pieces. It's all fairly trivial. First, some simple POD fixups to core.ops. Second, a few minor code tweaks to silence a few compiler or lint warnings. Third, a change to the makefile to turn on -Wall and (optionally) -pedantic for gcc users.