Re: "tweetable" "symbolic" hex COM loader

> lseek to 0, then write 0 bytes is ftruncate.

this was a kludge, as interactive use[0] with a redirect and without  
the truncate was placing a transcript of the interactive session into  
the output file as well.  don't know if that's a general DOSism or a  
bug in my Q/freedos setup.

>> It seems a little alarming that we're storing a two-byte line  
>> number/byte
>> offset in a single-byte table entry.  I suppose that's not a  
>> problem as long as
>> your labels are always at least two letters apart... but isn't  
>> there an x86
>> addressing mode that makes that problem easier?  So you could do  
>> `mov %ax,
>> [0x200+2*bx]` or something, with just the input byte in bx?   
>> Probably then
>> you'd want to initialize %di to 0x400 in case somebody wants to  
>> use extended
>> ASCII labels.


Yeah, my bad.  I noticed it when translating to a 32-bit com-like  
environment[1,2], at which point I'd fixed it by storing byte  
offsets, but your solution is much better.

> The global assembler label is a remarkably powerful tool.  I  
> wonder, though, if
> it might be a bit too powerful; perhaps the Forth approach (two  
> separate
> stack-based mechanisms for backward and forward jumps, plus an  
> updatable symbol
> table for calls to earlier-defined routines, giving each symbol a  
> scope from
> its own definition until the next definition of the same name) is  
> actually
> better.

Good point.  This time I went with the decision for global labels in  
order to maximize straight-line code; taking the second pass means  
there's no requirement for dispatching[3].  MIXAL apparently makes a  
"single" pass by backpatching, so it's single pass over the input but  
random access in the output; given enough stack one can also claim   
to make a "single" recursive pass, reading on the way down and  
writing on the way back up, but that's still fairly close to two  
monotonic passes.  One great temptation to use the power of the  
global labels is that other tools (such as a stack-based control- 
structure preprocessor) can then simply be streaming transformers.

> Barely relatedly, linking is apparently a progressively bigger  
> bottleneck in
> builds of big C and even C++ projects, because you can compile each  
> source file
> on a separate core, but then the linker has to deal with the entire  
> corpus at
> once.  It occurred to me that a mapreduce approach to linking ought  
> to be quite
> parallelizable:

Definitely.  I'd claim that assigning contiguous addresses (which is  
a parallel-prefix sum problem) is the most essentially serial part of  
a linker.  If you're willing to take your chances, random snippet  
address assignment in a 64-bit address space (cf birthday problems)  
would nearly completely parallelize.

-Dave

[0] it is indeed possible to use with direct input, contra:
> It does sort of assume you already have an interactive text editor,  
> though. (Or, say, a paper tape reader, a knife, and Scotch tape.)
[1] it turns out to be relatively easy to append code onto a stock  
Mach-O header that sets up a 4K rwx area with entry point 0x100,  
either by fixing up the filelen or dd'ing/xxd'ing the program text  
into a fixed-size block ... ELF would presumably not be much more  
complicated.
[2] or maybe before?  looks a little suspicious now that my labels  
for the self-assembly were in greek alphabetical order.
[3] given not-very-(marginally-)onerous restrictions on the input,  
the first loop was indeed expressible without interior branching

-- 
To unsubscribe: http://lists.canonical.org/mailman/listinfo/kragen-discuss