Mail Archives: djgpp-workers/1999/03/22/14:43:32
DJ Delorie wrote:
>
> Please make sure nothing in djgpp uses sh[rl]d before changing the
> meaning of that opcode. If you do that, I'll check in your patch.
src/stub/stub.asm shr/shl only
tests/libc/crt0/teststub.asm shr/shl only
These are the only *.asm files in djgpp that use any sh[rl]*
instructions. (find . -name '*.asm') in the cvs tree.
> djasm can have its own directory when it has complete documentation
> and omf support, but not before 2.03.
Sounds like a good deal to me. I was expecting someting link 3.00:)
> o finish omf support (do you still want that, DJ?)
>
> Yup. It should work with djlink :-)
Thought so, though I'd been under the impression you've given up on
djlink (hence the question).
> o better symbol handling (allow forward references in most expressions)
>
> In what cases don't they work now?
I can't remember the exact cases right now, I'll have to produce some
test cases, but I remember being frustrated by this on occasion.
> o better section support (first stage, being able to swap between
> .text, .data and .bss at will, later maybe `real' segment support (esp
> 16/32 bit control))
>
> for coff this would be useful, but I think you're reinventing the
> wheel here. Both gas and nasm already handle those kinds of programs.
> But if you want to, and it doesn't destabilize it for djgpp, go ahead.
But look at all those different wheels out there:) Seriously, `real'
sements is probably way off (if ever), but a.out standard sections will
be a real boon. Also, stability is very important to me (eg, the patch
I sent is about 6 months old), so I have no intention of breaking
stub.asm (in fact, I use it as a stability test).
> o finalise instruction support for 486
> o pentium* instructions
>
> No problem here.
So long as I don't get any more name clashes. If I do, I'll post hear
to discuss what to do.
Bill
--
Leave others their otherness.
- Raw text -