Re: Which assembler can handle the BIG stuff ?



The_Sage wrote:

>
> >Code
> >segments are typically 32 KB in size, because Mac applications use
> >PC-relative (program counter) instructions. Such instructions are used
> >so that code is address independent and capable of being placed
> >anywhere within scarce physical memory.
>
> What does that say again? That the Mac has a 64k segment (that's plus *OR* minus
> 32k...duh!).

Obviously, you don't know the meaning of the term "segment". I wrote a
primer on memory management for Byte Magazing back in the 80's. As
you're a big fan of looking up old Byte magazine articles, you might
check that out and learn what segmentation is all about.

> That's just like DOS!

You have no clue what segmentation is about.

> So if I have function that spans more than
> 64k, what do we do again?

You have no clue what segmentation is about.

> We use jump tables to jump, not to call pointers, but
> to jump to the next segment.

Jump tables are jump tables, regardless of whether the underlying
memory management system uses segmentation.

> >These segments might be used
> >briefly, purged from memory to make room for other code segments, and
> >then reloaded as necessary into another portion of memory.
>
> NOTE: We aren't aren't talking about code that is too big to fit in MEMORY, but
> code that is too big to fit in one SEGMENT.

Actually, in this particular situation we're talking about using *word*
displacements, which limit you to +/- 32K. This has nothing to do with
segmentation (or even the +/- 32K limitation of displacements in
certain 68K addressing modes) and *everything* to do with the choice of
".word" as the directive. One can easily extend the reach by using a
".dword" (or whatever directive) and using a different addressing mode
that allows the use of a 32-bit PC-relative offset. It's a bit more
work, cause you have to load the offset into a register, but it's quite
doable. Of course, on 68K systems outside the original Macintosh, where
PC-relative coding isn't required, you can simply initialize the
entries in your jump table with the absolute addresses of the code you
wish to jump to rather than the offsets from the jmp instruction.

> Nevertheless, just to humor you,
> notice how the vast majority of Mac programs were mcuh smaller than 128k so this
> wasn't a very common issue. Yet when these rare kind of issues did occur, it
> STILL REQUIRED THE USE OF JUMP TABLES in addition to a loader to
> overwrite/relocate code from segment to segment.

If you mean "it required the use of offsets to JMP instructions..." you
are incorrect. Some compilers emitted code this way because they
weren't too bright, but you could easily generate a jmp table
containing 32-bit entries, if you chose to do so (BTW, as the 128K Mac
predated the GNU tools by a tiny bit, the whole issue of that ".word"
leading to jump instructions doesn't even apply to the Mac, as they
used different compilers; remember, the documentation you're reading is
for FSF software; it doesn't even apply to the Mac 128K).


>
> And as anyone can clearly see, *NONE* of this ancient, outdated, backwards,
> obsolete programming technique is useful with today's modern non-segmented
> memory model, ie -- 32-bit and above.

And none of it has anything to do with jump tables, either. Today, just
as back then, most people simply store addresses into jump tables when
implementing things such as switch statements (such as the thing that
Hutch was creating in the original post in this thread). The only
reason for using JMP instructions in a manner you suggest in modern
code is to conveniently support dynamic linking -- a completely
unrelated subject.
>
> That is except with idiot ASM programmers in this newsgroup who don't know any
> better.

Yes. The guy who doesn't know assembly language, and doesn't even know
C that well, is in a much better position to tell all the assembly
language programmers what an assembly language construct really is :-)

Cheers,
Randy Hyde

.

Relevant Pages

  • problem in hooking cocreateinstance
    ... what Detours does is quite "easy": ... appends to G a jump to &F. ... Since I didn't want to write a table of IA-32 opcodes by ... wholly inside this segment, or it has to perform an absolute ...
    (microsoft.public.win32.programmer.directx.video)
  • Re: Problem with NASM
    ... I am using the DOS versions of NASM which may be slighty older than the Win ... to use a CS segment override to access data in the DS segment, ... a lot of bootsectors that count on that, *without* the far jump. ... In a way, a bootsector isn't a good project for a beginner, although a lot of 'em want to do it - too hard to troubleshoot, and too easy to get something that works on "my machine" but isn't "generic". ...
    (alt.lang.asm)
  • Re: EM64T how to switch from 64bit mode back to compatibility mode?
    ... a segment I have already defined but all attempts to jump there failed. ... need to reload the GDT and I still have the problem that the EIP points ...
    (comp.lang.asm.x86)
  • problem in hooking cocreateinstance
    ... cocreateinstance from same application where my function is .. ... Detours does on my own. ... appends to G a jump to &F. ... wholly inside this segment, or it has to perform an absolute ...
    (microsoft.public.windowsmedia.sdk)
  • Re: [GIT PULL] x86 setup: correct booting on 486 (revised)
    ... It did both the short jump and the far jump before reloading any segments. ... The old code did do some instructions in between the short jump and the far jump, but they were all the kind of instructions that didn't care about the PE bit: there was a _read_ of the segment descriptor value, but that's mode-independent, and the other instructions were bog-standard integer instructions. ... I have to admit I agree with Eric that this is probably overkill, but hey, there is nothing like a bit of overkill to make sure something is really and truly dead. ...
    (Linux-Kernel)