Re: [perl #24931] [PATCH] Win32 MinGW build fixes
Mattia Barbon [EMAIL PROTECTED] wrote: the important part is the change to config/init/hints/mswin32.pl, without which the build fails. The other changes are just warning fixes. Tested with GCC 3.3 (and 3.2 and 2.95) with GNU make 3.79 Thanks, applied Mattia leo
Re: [PATCH] Fix imcpasm tests on Win32
Harry Jackson [EMAIL PROTECTED] wrote: Leopold Toetsch wrote: [ Please provide patches relative to parrot root to simplify applying ] Do you mean we should be using: cvs -Q diff -c patchfile.txt when creating our patches rather than just diff'ing two files and then sending them with I don't care, if the diffs are done by cvs diff or by diffing a changed source against an up-to-date Parrot tree. But diffs should be done always from parrot's root directory, so that file paths in patch files contain the directories of the files: $ diff -u ../parrot-from-cvs/src/some_file.c src/some_file.c # fine $ cd src $ diff ...# wrong BTW don't we have some docs/*.pod with a summary of sending patches? Also the Fgettingingstarted.pod seems to be missing in the tree. Harry leo
Re: Problem during make test
Chromatic [EMAIL PROTECTED] wrote: On Sat, 2004-01-17 at 04:29, Leopold Toetsch wrote: I've converted this exit() to Parrot_exit() now. If that helps, I'll change a bunch of other such code too. Yep, that fixed. Now there are hangs in some of the t/src files. Right now, it's t/src/sprintf.t at test 2. The backtrace looks familiar: Fine. I just changed 2 occurences of exit. There are some more, that should fix more stuff. But I'm a bit worried about the reason, why it actually hangs here: (gdb) bac #0 0x0ff976a4 in __pthread_sigsuspend () from /lib/libpthread.so.0 ... #3 0x0fd0a694 in exit () from /lib/libc.so.6 #4 0x0fcf23a8 in __libc_start_main () from /lib/libc.so.6 These are exit calls from the main thread. That should AFAIK just kill all threads that got started eventually and finish the process. There seem to be a lot of exit() calls in the icu lib. Changing these isn't really a solution. Perhaps a Parrot_cleanup() would help extenders and embedders? That is: Parrot_exit(exit_status) - we have that already. My first attempts to cleanup all interpreter resources use an on_exit(3) or atexit(3) handler, but both werent't protable, so the code was change to do an explicit destroy processing via Parrot_exit(). -- c Thanks for digging into this, leo
Re: Events and JIT
Gordon Henriksen [EMAIL PROTECTED] wrote: On Saturday, January 17, 2004, at 12:47 , Leopold Toetsch wrote: Ops that can leave the code segment have to explicitely check for=20 events. Then no need to patch invoke*. Yep, that's true. I'm waiting for the ops-file hints, then that can be cleaned up. If the target thread handles the event and unpatches the bytecode before=20= the source thread finishes patching? Then we have kind of a race ;) But AFAIK it doesn't harm (except it slows down the interpreter a bit) If the target thread hits again a patched instruction it checks the task_queue, finds it empty, patches again the opcode stream with the original code and continues running until the next real event is scheduled. And the target thread could communicate with the event-handler thread with and volatile *patch_opcode_t. This hasn't to be exact (so no locking), but would allow, that the event-thread stops patching. But if events arrive faster, then the time needed for patching the opcode stream twice, then there is a real problem :) [ BTW does anyone have a spare dual-Opteron machine, I'd really like to test threads on a MP machine ] Gordon Henriksen --Apple-Mail-7--579835501-- Can you switch that to send ASCII mails? leo
Re: Events and JIT
Jeff Clites [EMAIL PROTECTED] wrote: On Jan 17, 2004, at 2:51 AM, Leopold Toetsch wrote: What I meant was, _every_ backward branch (etc.) in the bytecode, or just one location that we thought would execute soon. (But you implicitly answered this, below.) Every backward branch. Guessing the PC and patching in front of that can't work. But we can of course measure how long it takes to patch a certain amount of code twice. It just seems bad that the efficiency of event delivery would be proportional to the size of the bytecode (or segment). So it's slower to deliver events in large programs. That seems like a bad omen. It depends, how bad it really is: - it should be possible, to patch only the current subroutine, which might or might not help (a Sub can still be huge). The program flow can't have left the Sub in the meantime, because: - a bunch of opcodes (sleep, invoke*) will check events explicitely (this is the original strategy) - the problem is of course loops, that don't have any explicit check event opcode inside. For these there are 2 strategies: a) the event handler thread patches these backward branches or b) the backward branch op checks for events always Both have some costs: a) means slower event delivery, b) means slower execution in the absence of events. If patching takes too long, we can't do it and have to use b) that's it. The negative performance impact of b) can be reduced somtimes by partial loop unrolling. As said, we have to benchmark all. JEff leo
[PATCH] RE: More Buffer IO Bugs (was: Strangeness when printing to file)
When running this I would expect the 2 files to look the same, but they don't. Additionally to the reported bug these seem to be broken: 1) Turning off buffering: The attached patch fixes the above two bugs: a) when the buffer is full, it is not completely flushed; fixed. b) setbuf sets b-size to PIO_GRAIN (and wrongly sets io-flags) when passed 0. The patch sets b-size to 0 - hope it is the expected behavior. Tests, tests, tests, and fixes very welcome, leo arvindh biofixes.patch Description: biofixes.patch This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Any unauthorised review, use, disclosure, dissemination, forwarding, printing or copying of this email or any action taken in reliance on this e-mail is strictly prohibited and may be unlawful. Visit us at http://www.cognizant.com
Re: [PATCH] RE: More Buffer IO Bugs
Arvindh Rajesh Tamilmani [EMAIL PROTECTED] wrote: The attached patch fixes the above two bugs: a) when the buffer is full, it is not completely flushed; fixed. b) setbuf sets b-size to PIO_GRAIN (and wrongly sets io-flags) when passed 0. The patch sets b-size to 0 - hope it is the expected behavior. Thanks, applied. Tests, tests, tests, and fixes very welcome, People, if you have some IO related PASM snippets, that were broken and are ok now (or not :), please convert that into a test and sent it to bugs-parrot. Thanks. arvindh leo
RE: CVS troubles
do $ cvs update -A classes/timer.pmc to remove the sticky tag and try committing again. Ah, yes thanks, that worked. If you wish to get a particular revision/branch of a file, but don't want the sticky tag to be set, you may use this command: $ cvs update -r tag -p file file This way, Working revision and Sticky Tag will remain unchanged. arvindh This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Any unauthorised review, use, disclosure, dissemination, forwarding, printing or copying of this email or any action taken in reliance on this e-mail is strictly prohibited and may be unlawful. Visit us at http://www.cognizant.com
[perl #24941] [PATCH] RE: More Buffer IO Bugs (was: Strangeness when printing to file)
# New Ticket Created by Tamilmani, Arvindh Rajesh (Cognizant) # Please include the string: [perl #24941] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=24941 When running this I would expect the 2 files to look the same, but they don't. Additionally to the reported bug these seem to be broken: 1) Turning off buffering: The attached patch fixes the above two bugs: a) when the buffer is full, it is not completely flushed; fixed. b) setbuf sets b-size to PIO_GRAIN (and wrongly sets io-flags) when passed 0. The patch sets b-size to 0 - hope it is the expected behavior. Tests, tests, tests, and fixes very welcome, leo arvindh biofixes.patch Description: Binary data This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Any unauthorised review, use, disclosure, dissemination, forwarding, printing or copying of this email or any action taken in reliance on this e-mail is strictly prohibited and may be unlawful. Visit us at http://www.cognizant.com
Re: [PATCH] Fix imcpasm tests on Win32
On 17 Jan 2004, at 21:47, Leopold Toetsch wrote: [...] BTW don't we have some docs/*.pod with a summary of sending patches? Also the Fgettingingstarted.pod seems to be missing in the tree. I have a submissions.pod on the wiki which I'll put in. Problem is at the moment I can't see either the wiki or cvs.perl.org. Not certain where the problem is. Mike
Register stacks organization
Luke Palmer clearly should, that optimizations WRT register frame stacks are possible. The follwing numbers seem to second that: FRAMES_PER_CHUNK time real user 4 1.2s0.9 8 1.6 16 2.3 1.4 These are runs of parrot -j -Oc examples/benchmarks/fib.imc on an unoptimized built parrot on Athlon 800. The main problem seems to be, that we are copying around a lot of memory: 16 chunks * 32 regs * 4/8 bytes More fields for optimizations: - regstack_copy_chunk alwyas copies a full chunk (despite of used) - memory is allocated zeroed - the COW flags is only reset on one user of 2 provocing even more unneeded ocpies. Comments welcome, leo
Re: Events and JIT
On Jan 17, 2004, at 12:33 PM, Leopold Toetsch wrote: Gordon Henriksen [EMAIL PROTECTED] wrote: On Saturday, January 17, 2004, at 12:47 , Leopold Toetsch wrote: Ops that can leave the code segment have to explicitely check for events. But if the event dispatch thread is setting some flag for the target thread to detect, it's going to need to lock (or something similar) to make sure that the value of this flag is visible to other threads. (If not, then the target thread could branch to a new code segment after the dispatch thread thinks it has set this flag, but before it's actually become visible to the target threads.) So that could mean a lock inside of every invoke If the target thread handles the event and unpatches the bytecode before the source thread finishes patching? Then we have kind of a race ;) But AFAIK it doesn't harm (except it slows down the interpreter a bit) If the target thread hits again a patched instruction it checks the task_queue, finds it empty, patches again the opcode stream with the original code and continues running until the next real event is scheduled. So the really bad case here will be if the patching thread is working just ahead of the running thread--if it has to patch 1000 locations, then we could end up hitting each of those (and checking for an event, unpatching everything...) before the patching thread has finished. So now we are probably quadratic with the size of the segment. (Patching N locations leads to N times where we un-patch all N locations.) And the target thread could communicate with the event-handler thread with and volatile *patch_opcode_t. This hasn't to be exact (so no locking), but would allow, that the event-thread stops patching. As above, it may be ineffective if we don't lock--the other thread may not see the value change. (The volatile keyword in Java is magic in terms of inter-thread visibility, but not in C.) JEff
[PATCH] Re: Register stacks organization
Leopold Toetsch writes:
Luke Palmer clearly should, that optimizations WRT register frame stacks
are possible.
The follwing numbers seem to second that:
FRAMES_PER_CHUNK time real user
4 1.2s 0.9
8 1.6
16 2.3 1.4
These are runs of
parrot -j -Oc examples/benchmarks/fib.imc
on an unoptimized built parrot on Athlon 800.
The main problem seems to be, that we are copying around a lot of memory:
16 chunks * 32 regs * 4/8 bytes
I think it would be a good idea to reduce FRAMES_PER_CHUNK anyway. The
more continuations are used, the more a high value hurts us.
I'm working on yet another scheme at the moment, with a special op that
pushes and clears simultaneously, to see if I can avoid copying
altogether! It costs another indirection in the core registers, so I'm
worried that it will slow things down too much in general to be useful.
But we'll see what the benchmarks say.
More fields for optimizations:
- regstack_copy_chunk alwyas copies a full chunk (despite of used)
- memory is allocated zeroed
Fixed in included patch.
- the COW flags is only reset on one user of 2 provocing even
more unneeded ocpies.
Again, I don't think this is hurting us. If there's another copy, it's
in a continuation. And unless continuations destroy themselves when
they're invoked, the stack they hold on to should stay COW.
Comments welcome,
leo
Luke
Index: include/parrot/register.h
===
RCS file: /cvs/public/parrot/include/parrot/register.h,v
retrieving revision 1.18
diff -u -r1.18 register.h
--- include/parrot/register.h 12 Jan 2004 09:50:24 - 1.18
+++ include/parrot/register.h 18 Jan 2004 18:28:54 -
@@ -50,7 +50,7 @@
struct RegStack {
struct RegisterChunkBuf* top;
-size_t chunk_size;
+size_t frame_size;
};
/* Base class for the RegChunk types */
Index: src/register.c
===
RCS file: /cvs/public/parrot/src/register.c,v
retrieving revision 1.38
diff -u -r1.38 register.c
--- src/register.c 17 Jan 2004 11:40:03 - 1.38
+++ src/register.c 18 Jan 2004 18:28:54 -
@@ -23,22 +23,22 @@
buf = new_bufferlike_header(interpreter, sizeof(struct RegisterChunkBuf));
Parrot_allocate_zeroed(interpreter, buf, sizeof(struct IRegChunkBuf));
interpreter-ctx.int_reg_stack.top = buf;
-interpreter-ctx.int_reg_stack.chunk_size = sizeof(struct IRegChunkBuf);
+interpreter-ctx.int_reg_stack.frame_size = sizeof(struct IRegFrame);
buf = new_bufferlike_header(interpreter, sizeof(struct RegisterChunkBuf));
Parrot_allocate_zeroed(interpreter, buf, sizeof(struct SRegChunkBuf));
interpreter-ctx.string_reg_stack.top = buf;
-interpreter-ctx.string_reg_stack.chunk_size = sizeof(struct SRegChunkBuf);
+interpreter-ctx.string_reg_stack.frame_size = sizeof(struct SRegFrame);
buf = new_bufferlike_header(interpreter, sizeof(struct RegisterChunkBuf));
Parrot_allocate_zeroed(interpreter, buf, sizeof(struct NRegChunkBuf));
interpreter-ctx.num_reg_stack.top = buf;
-interpreter-ctx.num_reg_stack.chunk_size = sizeof(struct NRegChunkBuf);
+interpreter-ctx.num_reg_stack.frame_size = sizeof(struct NRegFrame);
buf = new_bufferlike_header(interpreter, sizeof(struct RegisterChunkBuf));
Parrot_allocate_zeroed(interpreter, buf, sizeof(struct PRegChunkBuf));
interpreter-ctx.pmc_reg_stack.top = buf;
-interpreter-ctx.pmc_reg_stack.chunk_size = sizeof(struct PRegChunkBuf);
+interpreter-ctx.pmc_reg_stack.frame_size = sizeof(struct PRegFrame);
Parrot_unblock_DOD(interpreter);
}
@@ -112,10 +112,11 @@
PObj_COW_CLEAR((PObj*) buf);
Parrot_block_DOD(interpreter);
-Parrot_allocate(interpreter, buf, stack-chunk_size);
+Parrot_allocate(interpreter, buf, stack-frame_size * FRAMES_PER_CHUNK);
Parrot_unblock_DOD(interpreter);
-memcpy(buf-data.bufstart, chunk-data.bufstart, stack-chunk_size);
+memcpy(buf-data.bufstart, chunk-data.bufstart,
+stack-frame_size * FRAMES_PER_CHUNK);
return buf;
}
@@ -136,7 +137,8 @@
sizeof(struct RegisterChunkBuf));
Parrot_block_DOD(interpreter);
-Parrot_allocate_zeroed(interpreter, (PObj*)buf, stack-chunk_size);
+Parrot_allocate(interpreter, (PObj*)buf,
+stack-frame_size * FRAMES_PER_CHUNK);
Parrot_unblock_DOD(interpreter);
buf-used = 1;
Re: [PATCH] Re: Register stacks organization
Luke Palmer writes: -memcpy(buf-data.bufstart, chunk-data.bufstart, stack-chunk_size); +memcpy(buf-data.bufstart, chunk-data.bufstart, +stack-frame_size * FRAMES_PER_CHUNK); Silly me -- left over from benchmarks. Of course I mean: + memcpy(buf-data.bufstart, chunk-data.bufstart, + stack-frame_size * chunk-used); Luke
Re: Vtables organization
Thusly did Dan Sugalski inscribe: At 3:33 PM -0500 1/16/04, Benjamin K. Stuhl wrote: Dan Sugalski wrote: I was going to go on about a few ways to do this, but after I did I realized that only one option is viable. So, let's try this on for size: Vtables are chained. That means each vtable has a link to the next in the chain. It *also* means that each call into a vtable function has to pass in a pointer to the vtable the call came from so calls can be delegated properly. If we don't want this to suck down huge amounts of memory it also means that the vtable needs to be split into a vtable header and vtable function table body. Downside there is that we have an extra parameter (somewhat pricey) to all the vtable functions. This is sort of icky. What about dynamically constructing vtables and caching them? How would one wrap a vtable, then? If you do this, there's no way to call back into the original (or earlier wrapping) entry. Other than the special case of :readonly, can you give me an example of when you'd need to, rather than simply writing a PMC class that inherits from some base? I'm having trouble thinking of an example of when you'd want to be able to do that... After all, since operator overloading and tying effectively _replace_ the builtin operations, what more does one need? -- BKS
Re: Vtables organization
Benjamin K. Stuhl writes: Other than the special case of :readonly, can you give me an example of when you'd need to, rather than simply writing a PMC class that inherits from some base? I'm having trouble thinking of an example of when you'd want to be able to do that... After all, since operator overloading and tying effectively _replace_ the builtin operations, what more does one need? Well, other than Constant, we need to be able to put locking on shared PMCs. We'd like to add a debug trace to a PMC. We could even make any kind of PMC sync itself with an external source on access, though that's a bit of a pathological case. Indeed, all of this can be done, however, by subclassing Ref. I think the reason this isn't sufficient is that we want to change the actual PMC into this new variant when it is possibly already in existence. Like my Csupplant was evilly trying to do. Perhaps there's a way to get that working safely... Luke -- BKS
Re: Problem during make test
On Sat, 2004-01-17 at 12:12, Leopold Toetsch wrote:
But I'm a bit worried about the reason, why it actually hangs here:
(gdb) bac
#0 0x0ff976a4 in __pthread_sigsuspend () from /lib/libpthread.so.0
...
#3 0x0fd0a694 in exit () from /lib/libc.so.6
#4 0x0fcf23a8 in __libc_start_main () from /lib/libc.so.6
These are exit calls from the main thread. That should AFAIK just kill
all threads that got started eventually and finish the process.
What if the event thread is stuck? When the tests hang, suspending and
resuming the process unsticks it, though the current test will fail. I
wonder if it's waiting for a masked signal or a signal that never
arrives.
(Warning: I've just about exhausted my knowledge of pthreads programming
coming up with that idea, so if it sounds crack-addled, it's definitely
due to gaps in my knowledge.)
I base that idea on this backtrace:
/home/chromatic/dev/parrot/t/src/extend_8, process 19479
Reading symbols from /lib/libpthread.so.0...done.
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 19479)]
[New Thread 32769 (LWP 19480)]
[New Thread 16386 (LWP 19481)]
Loaded symbols for /lib/libpthread.so.0
Reading symbols from /lib/libnsl.so.1...done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/libm.so.6...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /lib/libcrypt.so.1...done.
Loaded symbols for /lib/libcrypt.so.1
Reading symbols from /lib/libutil.so.1...done.
Loaded symbols for /lib/libutil.so.1
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld.so.1...done.
Loaded symbols for /lib/ld.so.1
0x0ff976a4 in __pthread_sigsuspend () from /lib/libpthread.so.0
(gdb) info threads
3 Thread 16386 (LWP 19481) 0x0ff976a4 in __pthread_sigsuspend ()
from /lib/libpthread.so.0
2 Thread 32769 (LWP 19480) 0x0ff9c140 in waitpid ()
from /lib/libpthread.so.0
1 Thread 16384 (LWP 19479) 0x0ff976a4 in __pthread_sigsuspend ()
from /lib/libpthread.so.0
(gdb) bac
#0 0x0ff976a4 in __pthread_sigsuspend () from /lib/libpthread.so.0
#1 0x0ff973e0 in __pthread_wait_for_restart_signal ()
from /lib/libpthread.so.0
#2 0x0ff96fe4 in pthread_onexit_process () from /lib/libpthread.so.0
#3 0x0fd0a694 in exit () from /lib/libc.so.6
#4 0x0fcf23a8 in __libc_start_main () from /lib/libc.so.6
(gdb) thread 2
[Switching to thread 2 (Thread 32769 (LWP 19480))]#0 0x0ff9c140 in
waitpid ()
from /lib/libpthread.so.0
(gdb) bac
#0 0x0ff9c140 in waitpid () from /lib/libpthread.so.0
#1 0x0ff9c128 in waitpid () from /lib/libpthread.so.0
#2 0x0ff958d0 in pthread_handle_exit () from /lib/libpthread.so.0
#3 0x0ff94c90 in __pthread_manager () from /lib/libpthread.so.0
#4 0x0fdb3118 in clone () from /lib/libc.so.6
(gdb) thread 3
[Switching to thread 3 (Thread 16386 (LWP 19481))]#0 0x0ff976a4 in
__pthread_sigsuspend () from /lib/libpthread.so.0
(gdb) bac
#0 0x0ff976a4 in __pthread_sigsuspend () from /lib/libpthread.so.0
#1 0x0ff973e0 in __pthread_wait_for_restart_signal ()
from /lib/libpthread.so.0
#2 0x0ff93f9c in [EMAIL PROTECTED] () from
/lib/libpthread.so.0
#3 0x101d7614 in queue_wait (queue=0x10279e30) at src/tsq.c:159
#4 0x1009c968 in event_thread (data=0x10279e30) at src/events.c:349
#5 0x0ff94d98 in pthread_start_thread () from /lib/libpthread.so.0
#6 0x0fdb3118 in clone () from /lib/libc.so.6
(gdb) q
and the fact that the attached patch seems to fix things. I don't
expect that it's correct. It might paper over a real problem, perhaps
on my system. It's food for thought though.
If it turns out that the problem does lie here, can anyone suggest a
very small test program that would demonstrate the real problem?
-- c
Index: src/interpreter.c
===
RCS file: /cvs/public/parrot/src/interpreter.c,v
retrieving revision 1.258
diff -u -u -r1.258 interpreter.c
--- src/interpreter.c 16 Jan 2004 20:47:23 - 1.258
+++ src/interpreter.c 19 Jan 2004 02:10:34 -
@@ -1123,6 +1123,7 @@
* wait for threads to complete if needed
*/
if (!interpreter-parent_interpreter) {
+Parrot_new_terminate_event(interpreter);
pt_join_threads(interpreter);
}
/* if something needs destruction (e.g. closing PIOs)
Re: cvs commit: parrot/imcc imcc.l
Melvin Smith wrote: At 08:44 PM 1/9/2004 +, Harry Jackson wrote: So, are they staying, staying for now or not sure yet? I have a few hundred lines of imcc that uses macros and if they are being removed then I would rather change now and save myself some pain later. I think we are going to have an alternative to C.constant builtin to IMCC, the best suggestion seems to be C.define As far as macros, I guess we will keep them for the near future. I think its time to create a new branch for imcc development, so lets see how things work out. It may be that we can keep them in some form. One thing to consider: when we put an API on top of IMCC, macros won't translate; they are only for the text version. Thankfully this will not affect me. I am unable to find the email now but I remember someone mentioning breaking the pre-processor out of IMCC and into its own program, it was probably yourself. I have a few questions about this. What are the requirements on the pre-processor. I am pretty rusty with C and decided that I would oil my joints a little so I have been playing with a toy pre-processor (Thank god for KR). I know I should probably work with the one already there and not re-invent the wheel, I am also sure there are better ways to do it than the way I am doing it but.. ;-) This is as far as I have got and roughly how things are processed. $ preprocess filename.imc 1. Ignore comments where the *#* comes before text. If there is any text before the # I process the line as a normal statement # This line will not be processed .pcc_call blah # This line will be processed 2. Recursively process .include files ie .include /file/blah/blah goto step 1. 3. Store macro declarations in a hash table ie 146 .macro PQgetvalue(RES, tuple_num, count, data) 147 P0 = global PostgreSQL::PQgetvalue 148 I5 = .tuple_num 149 I6 = .count 150 P5 = .RES 151 invoke 152 .data = S5 153 .endm gets stored as PQgetvalue and a linked list holds each line up to the .endm. This is the area I need some clarification on. How is the current pre-processor handling arguments to the macros. Do they need to be pre-processed and if so in what ways. 4. Find macro calls by name assuming they have been found in Step 3 ie .PRINT(RES) and replace with the macro text. Using the name PRINT I access the hashtable traverse the linked list of lines printing them out as I go along. There are a few minor bugs in it which I am working on. I was just wondering what other types of things would the pre-processor need to handle. If you managed to get this far and are still interested. I have used a seriously hacked version of the dbj2 hash to store the macros. I had a look at the one in KR and thought I would have a look for a few others and this was the first one I found on google. http://www.cs.yorku.ca/~oz/hash.html Harry
