Re: Which assembler can handle the BIG stuff ?

>Reply to article by: Alex McDonald <ar.mcdonald@xxxxxxxxxxxxxxxxx>
>Date written: Mon, 04 Jul 2005 02:01:27 GMT
>MsgID:<XL0ye.22665$%O1.2020@xxxxxxxxxxxxxxxxxxxx>

>>>>What someone may want to say is that this "test" is nonsense as no one is going
>>>>to create an application with a 16k jmp table, much less a 16M jmp table. It is
>>>>a useless exercise that proves nothing in the real world since in real life, jmp
>>>>tables are used sparingly in ASM programs, and in fact would be a sign of
>>>>incpometent programming skills if a jmp table exceeds 1k in size.

>>>Well, although I agree that a 16M jump table might be a table looking
>>>for a solution, you don't have to look too far for examples of jump
>>>tables bigger than 16K.

>>>Have a look at (for instance) PE DLL headers for examples of very large
>>>jump tables; these sorted tables of API entry points can be very large
>>>indeed.

>>An OS is not an application, and no, I still don't see any API DLLs with a 16k
>>jmp table. The worst OS DLL that I know of it the kernal and it has 864 entries
>>(time one word equals) 1728 bytes.

>Kernel, please.

>864*4 (a word is 4 bytes) is 3456. There are 949 entries in my copy of
>kernel32.dll.

You are assuming that all EXPORTED PROC are the same, when they are not, ie --
some are fixed while others are movable which makes some of the so-called jmps
four bytes (offset only) while others are six bytes (segment plus offset). The
kernal has at least three segments, so an offset alone would never work. Just
extract the PE header for the kernal and see for yourself.

But technically speaking, there is no jmp table in the kernal. It simply lists
the location in a header. A true jmp table has the opcode for a (far) jmp
followed by the (seg:)offset so if you call or jmp to that location, it will jmp
again to the function() directly. So that blows your argument your argument out
of the water to begin with, doesn't it?

>There are 6937 entries in mfc42.dll, a Visual C DLL used by applications
>developed using MFC (Microsoft Foundation Classes) at run time. That's a
>jump table of 27748 bytes. And it's not an OS DLL.

Same thing applies to this DLL as it does for the kernal.

>>Now I can understand how an OS kernal would
>>need more than a 1k jmp table but not an application.

>mfc42.dll must be a very, very bad DLL indeed.

Not for any of the reasons you've cited.

>>>Some programming languages (threaded interpretive languages or
>>>TILs) also use large jump tables. Objective C, due to its late binding
>>>model, can generate some very large jump tables indeed; WATCOM/C switch
>>>statements could also generate large sparse jump tables.

>>Those large jmp tables are either a sign of poor programming skills or an
>>iefficient compiler.

>Please, try and understand why they're useful. Large jump tables in
>Objective C are caused by the nature of the language and late binding.
>TILs use jump tables because coding if then else if... several hundred
>times is just plain stupid, and it would run like a dog. OK, WATCOM/C
>wasn't the world's best C compiler...

As I pointed out before, properly created object oriented code needs to have jmp
tables, so I already know that. Just please remember that object oriented code
is bigger and slower than non-object oriented code. It's the nature of all that
overhead and jmp tables are most definitely overhead.

>>>And then there are hardware simulators; jump tables are quite efficent
>>>for this application, and given the arcane instruction set of an x86,
>>>several 1K+ tables are required to provide coverage.

>>I have yet to see "several" 1k tables for such an program but like the kernal, I
>>would expect a hardware simulator to have more entries in the jmp table.

>What's the "kernal" (how I hate that spelling) got to do with a hardware
>simulator? The kernel provides core OS services; a hardware simulator
>simulates hardware. Different things.

Same programming paradigm.

>>And none of the above would be written in ASM.

>Arrgghh... Lots are. Just about every VM I've ever seen has been
>implemented with jump tables, with cores either in assembler, or less
>frequently in C.

Show me lots of them then -- preferably an internet link I can check out
directly. I predict you will fail.

>Tell me, how would you implement a VM with several hundred instructions
>without using a jump table? What do you think the Java bytecode VM looks
>like, for instance?

I once wrote a compiler that used a jmp table. I had to because the address for
the various calls couldn't be calculated by the compiler at compile time. I
found a better way to do this was to create a DLL and call that DLL.

Speaking of DLLs, here is something that Hutch has no clue about when it comes
to DLLs:

You can take any DLL and extract the headers. All the EXTERNS in the header will
have names and (seg:)offsets which in turn can be created into a library for
that DLL. For example, my PE extractor has an entry like this in the kernal:

Name: SWAPRECORDING Entry: 204

Doing a search gives this entry for 204:

Entry 204: Segment: 03h Offset: 024Fh Exported

This gives me enough information to write my own library or hand calculate the
offsets for my proc that calls this API function().

Hutch naively believes that none of the 864 offsets referred to in the kernal
DLL will work because they are all referenced to offset zero (the beginning of
the file) and will all lead to "protected mode exceptions", yet they do work --
but only if you know how to use and clearly Hutch does not.

The Sage

=============================================================
My Home Page : http://members.cox.net/the.sage

"Toward no crimes have men shown themselves so cold-bloodedly
cruel as in punishing differences in belief"
-- James Russell Lowell
=============================================================
.

Relevant Pages

  • Re: Which assembler can handle the BIG stuff ?
    ... their right mind is going to make jmps to jmp tables to jmp to internal ... Now let's say you have a DLL with a function called SOME_FUNCTIONat ... to know where offset 0h is in memory, ... Now everyone and their dog knows that an EXE file is loaded at 400000h ...
    (alt.lang.asm)
  • Re: Which assembler can handle the BIG stuff ?
    ... Here is a sample extract from the Windows kernal... ... >>One entry contains an offset and the other contains an offset and a segment. ... It is a list of pointers, not a jmp table. ... >A jump table is a list of addresses or offsets to jump to. ...
    (alt.lang.asm)
  • Re: Which assembler can handle the BIG stuff ?
    ... >their right mind is going to make jmps to jmp tables to jmp to internal ... >Now let's say you have a DLL with a function called SOME_FUNCTIONat offset ... >to know where offset 0h is in memory, and then calculate the offset from there ... >Now everyone and their dog knows that an EXE file is loaded at 400000h ...
    (alt.lang.asm)
  • Re: Which assembler can handle the BIG stuff ?
    ... to create an application with a 16k jmp table, much less a 16M jmp table. ... you don't have to look too far for examples of jump tables bigger than 16K. ... There are 6937 entries in mfc42.dll, a Visual C DLL used by applications developed using MFC at run time. ... would expect a hardware simulator to have more entries in the jmp table. ...
    (alt.lang.asm)
  • Re: Which assembler can handle the BIG stuff ?
    ... >a jump table, each case *always* consumes four bytes. ... segment nor a CODE segment. ... calculated from the offset. ... a table where jmp instructions are stored to ...
    (alt.lang.asm)