Re: Static Libraries and Assembly Language

"Betov" <betov@xxxxxxx> ???????/???????? ? ???????? ?????????:

I never program in C, but i would not be much surprised if
the available C Static Libs would not propose functionalities
already available on any Win32 HD, under the form of C Run-Time
Libraries (DLLs).

One another day, i will have to look at this, but, for sure,
for example, in "MSVCRT.DLL", there are _hundreads_ of Functions.

So, (me) supposing they could be the same, i would also fail
to understand why they should be encoded a second time, in
an Executable.

For the "Portability" story, i don't know if the matching
Functions are available the same way, say, for Linux. I
suppose yes. So...

In the first place i meant the portability among different hardware platforms. The OS-portability has a place to be too.
Since a HLL has its semantic constructs considered to be its *standard* features, their implementation would be both OS-
dependent and hardware-dependent. The "static libraries" is one of methods to fabricate that.

In the case of assembler, the platform portability goes away, but
we still have portability issues among different assemblers. If you
want to utilize a piece of assembly code written in another assembly
syntax, you can choose to translate it to syntax of your assembler,
or you can use its native assembler to produce object file in a
format appropriated for linking. The second way would be faster.
So, an object library created with one assembler may be used with
another assembler.

And then? Why not a DLL?

Usage of a DLL is good thing as long as this DLL is common and is used widely. MSVCRT.DLL is a good example of such DLL, and i completely approuver with a one who would say that it's better to link it dynamically rather than use its static incarnation.
Even if you need just a one function from it :)

However, there are also a cons. There were already some arguments from f0dder and Evenbit here.

Why not disassembling Re-Assembling?

But.. How about author's comments and understandable shape of
writing? A naked code obtained as a result of Re-Assembling could not provide that, even if it was disassembled correctly.

And so on...

After all, please, don't loose my point above. In the case of *assembly* programming, i agree, it's better to have a primary source code as it is (yeah, we don't bother about compiling time and we also know that smart enough linkers are able to
exclude [properly drawn] unreferenced functions even if they are in the same source module with referenced items). The point was about utilizing of assembly code among different assembly
sources with different syntax. The "object format" appear to be a kind of common basis here.

Historically, Static Libs had two concerns:

1) Compilations Times.

In the old days, the usage of pre-compiled things
were significantly reducing the time. This point is,
nowadays, completely dead, given the speeds of the
actual Processors and Assemblers.

Here i'm agreeing completely.

2) Code Re-use.

This is _the_ actual point.

So, what we are talking about, here, is not about knowing
if the old Static Libs practice is interresting or not,
but to see what _Code Reuse_ Methods are good, and "good
for what", and "depending on what".

Basically, calling for a Lib (Static or Dynamic) is Black-
Box Programming. Of interrest when calling for the OS Functions,
there usage, in Assembly should decrease with the importance
of the called materials. Take, as an example, what Master Pdf
did, in the Satic Library he designed for his HLL, in the "Math"
or in the "Chars" Folders... You will see there, innoumerous
functions, usually one page or two long, that, in Assembly,
would take one or two instructions. That is, an extreeme
case of absurd Black-Box programming, doing nothing but
hidding Assembly entirely. In such cases, there is a choice
to be done in between the HLL, and the Assembler road. Here,
clearly, the usage of the Static Library, is utterly incompatible
with any form of Assembly.

If he provides a source code for that, that's not a "black box",
however there may be some notes about insufficiently considered
design, etc, etc.. But that's a single example. It's better to say that using "assembler" brand may be non-pertinent in the HLA
case.

[..]

Now, back to the real problem of Code Re-use... Depending on
the size of the Routines, they can be given in a Librarian
Tool (like the one of RosAsm), for the small Snippets. This
method has evident and huge advantages:

1) You can customize the selected Routine to your exact needs.

2) You have it inside your Source. So, no Black-Box, here.

3) In case of error, the Source Level Debugger can point it
out, in the Source.

4) The Method is faster (just a mouse selection, and a [Ctrl]
[V]), simpler, and more secure than the other ones.

Still considering the sizes and the types of usage, there also
are the cases of "Modules". For this also, there are better
methods than Static Linking, with most of the same advantages
as above ("Include" thingies...).

I seem to understand and appreciate such approach. However, the
common background is: there are only one assembler - the RosASM assembler; there are no other assemblers and there are no HLLs.
So, you can't use assembly code written in another syntax, you
can't mix assembly code with a HLL-written code. Too much egocentric.

Then, there are the DLLs. I suspect that some guys could wrongly
believe that the DLLs calls would 'consume' something... like
"calling time", or something like this, which is perfectly wrong.
There is no real difference in between calling a Function in a
DLL or inside the Binary. Just indirect, instead of direct... :
Nothing.
.

Relevant Pages

  • Static Linking in RosAsm
    ... > by libraries which have private variable lables, ... assembler produces creates some problems here. ... Understood that the goal is not to add a linker to RosAsm. ... programmers know C/C++. ...
    (alt.lang.asm)
  • Re: Static Libraries and Assembly Language
    ... Dynamic linked libraries are also nice in such situations. ... which is far more precious than disk space, a DLL generally consumes ... *far more* memory than a statically linked library. ... For example, an assembler ...
    (alt.lang.asm)
  • Re: Why do we use different files for C ?
    ... The window tutorials were geared for the ... You mean, like HLA? ... In my youth I used BASIC and assembler about equally. ... libraries to extend and give power to the asm programming ...
    (alt.lang.asm)
  • Re: The Lib debate
    ... > support but (and I'll give you due credit on the idea, Rene, because ... > putting the source code into the libraries and the object files...as ... If you decide that your assembler is ... Rene may think ...
    (alt.lang.asm)
  • Re: The Lib debate
    ... > I guess you only know Linux from hearing it in the newspapers commercials paid ... It is not a problem for source-level libraries at all. ... I am talking about assembler ... if you use precompiled libraries written on HLL? ...
    (alt.lang.asm)
Loading