Libraries-modules-programs...
ZXNet echo conference «code.zx»
Hello Vitamin
the right thing. I think the same way. It's high time to unify SpecSoft. 21st century on
yard
Hello, All
I wanted to dream here. So I started daydreaming.... :)
I was digging through my library of modules here the other day, along the way
looking with one eye at different docks on the topic of independent relocatable modules
for different platforms. And I imagined such an inspiring picture.
Each spektrumist has a certain system disk. The most
programs needed in everyday life - commanders, editors, other rubbish.
Usually the necessary software accumulates there, sometimes on an entire disk.
it turns out. But, if you look at it, most of the code of all utilities consists of
user interface, disk functionality, some kind of graphic
engine.
Now let's imagine a system disk on which there are several
dozens of BASIC files ranging in size from 3 to 10 sectors and a bunch of libraries,
used in different combinations by different programs. (Pepper is clear, in case
screw and a single FS it looks absolutely delicious). BASIC file contains bootloader
unique code block for each program, unpacker (in the general case),
list of used libraries and linker. After launching the bootloader
unpacks a code block into memory, searches, unpacks and links to it
found modules and starts the whole thing.
It is clear that this approach will have both pros and cons. I'll start with the first ones:+ save disk space (not always, but in general)
+ ease of fixing one glitch in a number of programs (and accordingly adding
new glitches %)))
+ developers can worry less - the main thing is to have a library, it
interface and work with it
That's enough for now, let's move on to the cons:
- you will have to crawl around on the disk a lot (and for a long time!) until the necessary libraries are collected,
and then they link
- a bunch of small files may take up little space, but they will quickly fill up the directory
- difficulties with transferring and copying programs
- possible compatibility problems - different versions, different interfaces...
That's enough for now too.
Now you can specify some ways to remove minuses.
1) compress libraries with packers. Fortunately, there’s quite a lot of “extra” inside there.
information may be
2) collect a set of libraries in an archive and search in it (not to mention
caching the directory for quick search)
3) an autoassembler utility that assembles a single bootloader and a bunch of libraries
a packaged monoblock that runs on any machine solves the third minus :)
That's basically all. In fact, there are much more pros and cons than I have here
pointed out.
What will dear All say?
Hello, captain cobalt
But here [http://zx.pk.ru/showthread.php?t=1912&page=1&pp=10] I’m not talking about the same thing
did you say?
Hello, CityAceE
If I give all the sources in GENS3/GENS4 format, without comments or with
comments with obscenities, will this suit new programmers?
Ready.
I don’t remember anything myself; about 15 years have passed.
I'm sorry.
Hello Vitamin
Vit> Libraries for the axis and libraries in the form described above are different things.
However, you should at least consider borrowing libraries from sources other than
disk, but from memory.
Vit> A regular program requires a certain set of libraries
There is also a good and useful thing - plugins.
Their set is unknown in advance and can be configured by the user.
Vit> there is no need for extra ones - there is simply no memory for them
128 may not have enough of this.
And 256 and even more so 512 and above can easily be enough not only for everything
libraries, but also for several programs to run them from memory.
You shouldn't talk about 128-only.
Vit> Moreover, after the initial linking they are no longer suitable for
Vit> for further use in another library - they will be configured for
Vit> specific address.
It's unclear.
The library sits in memory, configured to the address.
Well, let him sit there.
It is its newly downloaded clients that must be linked taking into account this address.
Hello Vitamin
You can also exit the program not via RESET, but to the axis. At the same time, libraries
remain in memory. When you start the next program, you don’t need to pump it up again
libraries, just download the program and link it with libraries in
memory.
Hello, captain cobalt
cap> You can also exit the program not via RESET, but to the axis. At the same time
cap> libraries remain in memory. When starting the next program it is not necessary
cap> pump up the libraries again, just load the program and
cap> link it with libraries in memory.
Libraries for the axis and libraries in the form described above are different things. For regular
the program requires a certain set of libraries, there is no need for extra ones - just use them
no memory. Moreover, after the initial linking they are no longer suitable for
further use in another library - they will be configured to
specific address.
Well, in addition, you can implement an API for runtime linking of modules.
Hello jim
I tried to make a library just for this purpose, so that there would be scroll bars,
menus, mouse, convenient text output in which all symbols are present
GOST alternative encoding. All this resulted in one program - CUTTER.
The matter stalled on disk procedures. The idea of using one library
I definitely support it for all system programs.
Hello, yoko_ono
yok> Why should they take the Amiga as a model, they never even look at her
yok> saw... =) PC (Linux and Windows) 'corroded Moscow'... :(
What’s special about them, the Amigas? And why are there millions of lemmings in this
were you mistaken?
Hello Vitamin
Vit> About the same thing. But from the source point of view. Here we are talking about
Vit> binary libraries.
Vit> "Constructor" from source code is the first step towards this. With only
Vit> binary and list of entry points, the problem of picking and disappears
Vit> understanding what and how it works (and accordingly the temptation to finish it disappears
Vit> everything for yourself).
This is exactly what I was talking about 100 years ago. Shaos even did a lot in terms of
implementation of this idea. True for a sprinter, but also applicable for spec. For
Just don’t use PC and Linux as a base. Use Amigas. don't explain
Pudu Pachama =)))
And about libs from Shaos - ask him on his forum
http://www.nedopc.org/forum/
Hello, CityAceE
Cit> Isn’t that what I was talking about here?
About the same thing. But from the source point of view. Here we are talking about binary
libraries.
The “constructor” from source code is the first step towards this. Having only a binary on hand
and the list of entry points eliminates the problem of tinkering and sorting out what and how
works (and accordingly, the temptation to finish everything for yourself disappears).
Hello, acidrain
aci> This is exactly what I was talking about 100 years ago. Shaos even did a lot in
aci> plan for the implementation of this idea. True for a sprinter, but also applicable
aci> for spec. Just don’t use PC and Linux as a basis.
aci> Use Amiga. I can’t explain Pachama =)))
aci> And about the libs from Shaos - ask him on his forum
aci> http://www.nedopc.org/forum/
Why should they take the Amiga as a model, they’ve never even seen her...
=) PC (Linux and Windows) 'corroded Moscow'... :(
Hello icebear
ice> What's special about them, the Amiga libs? And why are millions of lemmings and
ice> were you wrong in this case?
We made a mistake. =) And the peculiarity is that they are not made that way and are not resource-intensive and
To work, they do not need many tons of memory, as in other cases.
Quote: And if on topic. Module structure, e.g. for Linux (ELF)
supports many data types, which is very good for libraries,
created in Java (if any...). Does it support the notorious hunks?
Hmmm. I actually don’t know about the data types described and supported in
elves, but I don’t see the point. All types of data on Amiga, if you are not aware,
supported by datatypes system. By the way, many axes still draw from this
system advantages. I don’t know what and how about Java =(
You should first study what Amiga libli are and what they are eaten with.
For info; http://www.nedopc.org/forum/viewtopic.php?t=7689&highlight=lib;
http://www.nedopc.org/nedopc/shaos/libman_r.shtml
Hello icebear
yok> Why should they take the Amiga as a model, they never even look at her
yok> saw... =) PC (Linux and Windows) 'corroded Moscow'...
Hehe. And if you say “(from) where do you need qnx’s (linux’s, bsd’s, etc)
take binaries, you've never seen it... =) Amiga 'ate Mosk,
even a bone one, stuffed sawdust instead, put on a stupid smile and sent
work as a salesperson in Euroset stores;)
And if on topic. The module structure for e.g. Linux (ELF) supports
many data types, which is very good for libraries created in Java (if
any...). Does it support the notorious hunks?
Hello, acidrain
aci> You should first study what Amiga libli are and what they are eaten with.
aci> For info; http://www.nedopc.org/forum/viewtop...9&highlight=lib;
aci> http://www.nedopc.org/nedopc/shaos/libman_r.shtml
I read it. Educational. And now a few technical questions
1) According to the first link, the description of the library header, according to the second example, is not
corresponding to the structure description. Are these two different formats? If yes, where?
description for the second format
Next we talk about the first (described) format
2) The module is relocatable (I didn’t see any technical details
really, it would be interesting, please post a link if you have one), why do you need a choice?
desired window?
3) Kernal in the form of entry points is not gut, at least for the purpose
which I described in the first post of the thread. Instead there should be a link with
correction of the calling module code to substitute specific call addresses (and
also data structures)
Regarding the second link. No support for relocation was observed. Am I right?
Hello, yoko_ono
yok> ...This clearly demonstrates the thesis 'PC ate Moscow'...
burn Lena!!!
Hello Vitamin
Vit> There is also a linker for Linux (ld, gcc). Is this also Windows???? ))
Don't get it twisted, you understand what I mean. and the linking is as it is on Linux and
etc. available on any machine that has normal C.
Ehh, psssssssssssssssssssssssssssssssss. Look, that sprinter imitated the PC and what happened to him? your idea will be
wait the same =)
Just kidding, I hope she lives long and develops.
PS. I'm not evil, my brain is in place, that's why I analyze your idea and idea
sold on ammi. It's up to you...
Hello Vitamin
Vit> Damn... Linking is the connection of several pieces of code for collaboration
Vit> works. In the first case (my method) this is done by
Vit> direct merging of pieces of code. In the second case (yours,
Vit> Amiga, Windows, etc. method) case this is done by obtaining
Vit> handle and function calls. Linking (in any form) is excluded only in
Vit> if “I carry everything I have with me” and don’t need anything else.
Vit>
AHHHH! No! not like that!
Hello Vitamin
Vit> We have two approaches to the linking problem:
Vit> 1) The loader loads the necessary libraries, links them between
Vit> by yourself and the main program, configures addresses and starts the main one
Vit> program. From her point of view, she consists of a solid piece
Vit> code/data - like a regular Spectrum program.
Vit>
Are you talking about your method again? No, it’s not like that on the Amiga - Eliminate the linking! Let's say
So, kernal (exec.library on ammy) doesn’t link anything! Why link? Prog
requested a library, say gadgets.library - exec searches for it, loads it into memory,
returns its handle (address in memory, i.e. entry point), the program already has an offset
from the handle (i.e. subfunction number) in register D0 (type A on z80) calls
the initial address of libla - tama is physically registered jp $...... and voila! yours
task completed. (I explained this in a simplified way!)
What to link?
> 2) The main program must include the used libraries. When
> this is them
> a) are loaded into the tail of the main program and configured. As a result
> we get the same as in 1)
> or> b) loaded to a predetermined location, configured and called
> is already there. Limits the freedom of memory allocation.
>
> Right? Or did I miss something?
See above.
The benefit from such a scheme is if the new version of the subfunction is larger in size
(for example, it was 100 bytes, but became 102), then the end user is not
touches
Hello Vitamin
Vit> I read it. Educational.
Read carefully. The second link is about relocation. and the first one is like
someone is writing an axis for a sprinter. and the second link has questions for Shaos.
And secondly, linking is already a waste. Well, I say Windows is dictated by all the Specs,
except me! =)
Hello Vitamin
Vit> Honestly? I don't understand.
Ugh! There is only one Windows. Linking is the same everywhere. Only
Why link if you need to open a tiny lib and use it!
Why go through the back when you can go through the front door? ;)
The meaning is that libs on ammi are relocatable (well, just so it’s clear) exe,
which are opened (the bulk is read from external media) only then,
when will she open it? If several programs use it (this does not threaten the spec), then
The entry point for all programs is the same. Next, he opened it and received a handle, and danced from it.
You no longer have version compatibility problems (partially) and don’t need any
Constantly recalculate addresses! It's easier for me in ace or soap with you
talk...
Hello, acidrain
Vitamin, what did you get from this link?
Why are you linking if your program doesn’t even know how to liblate the function?
fulfills? The program only makes a subroutine call and waits for the result (confirmation)
and continues further. Maybe there will even be a ret instead of a subroutine. Why
link your program to my library, if it is a resident (for example) of libla
graphix.library in Nн bank. The program only makes a request to the main library (exe)
(let's say it loads with BASIC) about opening Libly Graphics, then using it
nafsu.
Then the program closed, but the lib remained, if we say there was no bc,gfx_handle;
de,flushlibrary; hl,execbase; jp (hl), then the next program can use it!
And, mind you, WITHOUT LINKING! =)
Hello, acidrain
Read:
aci> The program only makes a request to the main lib (exe) (say, with BASIC
aci> is loading) about opening the graphs library, then using it nafsu.
Call it whatever you want, let the opening of the library be called linking from now on.
Understand. Old programs _will not_ use your dlls (since this is not
libla, but only a stupid dllka, duh!), and new programs may well know that
bank Nн - under libly. The can number can be determined before opening and then
need to know. As you say, it’s also not the same, but suddenly it starts unpacking
pieces, the program will self-modify and in addition there will be an autocode in memory
litter. TADA what? Hanging? You can't joke around here anymore ;) It's like playing
rules vaguely reminiscent of oska
Hello, acidrain
I would be happy to give normal links to the necessary descriptions, but they are under (c) and
You won’t be able to find them right away on the net.
That's why all sorts of nonsense is presented...
http://wandel.ca/homepage/execdis/devices_doc.txt
Hello, yoko_ono
unfortunately in English only -
http://www.mways.co.uk/amiga/howtocode/text/generalguidelines.php
While looking for more links to autodocs...
Hello, acidrain
aci> Don't get it twisted, you understand what I mean. and the link is as it is on
aci> Linux, etc. available on any machine that has normal C.
Honestly? Didn't understand. What is so specific about Windows linking that is not there anymore?
nowhere?
Hello, acidrain
aci> Why go through the back when you can go through the front door?
Let's go :) Let's dance from the stove, I think misunderstandings will decrease.
We have two approaches to the linking problem:
1) The loader loads the necessary libraries, links them together and
the main program, configures the addresses and starts the main program. From her point
From the point of view, it consists of a solid piece of code/data - like a regular Spectrum
program.
2) The main program must include the used libraries. At the same time they
a) are loaded into the tail of the main program and configured. In the end we get the same
as in 1)
or
b) they are loaded into a predetermined location, configured and called there.
Limits the freedom of memory allocation.
So? Or am I missing something?
Hello, acidrain
aci> And, mind you, WITHOUT LINKING! =)
Yeah. Where did this lib come from? Did it appear out of thin air? Plus again, where is she?
is very important - with static memory allocation (as is usual for
situations without an OS) you need full control over memory. And there won't be a next one
program to use this lib! Because there is no OS or supporting !!BEEP!! funds (times
It breaks you so much to hear the word “linking” :), although that’s exactly what you described).
Hello, acidrain
aci> Read carefully. The second link is about relocation. and the first -
aci> this is like someone is writing an axis for a sprinter. and follow the second link questions
aci> Shaos.
I got confused. I read the links in reverse order, so... :)
In that case, what is a moving table? What is its purpose, format,
features?
aci> And secondly, linking is already an issue
There is also a linker for Linux (ld, gcc). Is this also Windows???? :)))
yok> That is, you claim that each left program should be adjusted under
yok> absolute library addresses are better than giving each program
yok> just the address of the beginning of entry points on the lib?
Let's read the topic from the beginning. We load the starting code block (which can be
non-relocable), and we already glue to it (and configure it to the address) the necessary
libraries, substituting the necessary addresses into the call points.
yok> Programs on the Amiga can be COMPLETELY relocatable, without data
yok> relocations in general, and at the same time it’s great to use any libs.
There is an elderberry in the garden, and there is a man in Kyiv. The x86 is also full of all sorts of commands, but on the workstation
too much. But 8051 is generally wretched compared to the zetnik, but it’s a lotWhy can you weaken on it! So don't confuse sour with long. Here's the conversation
about Spectrum and those capabilities of other platforms that can be spied and
use. And the team
yok> call (ix+const)
is not one of them.
PS. And I thought that the Amiga was such a good computer... It turns out that it also ate mosk
some citizens...
Hello, acidrain
aci> What to link?
Damn... Linking is the connection of several pieces of code to work together. B
in the first case (my method) this is done by directly merging the pieces
code. In the second case (your, Amiga, Windows, etc. method) case this is
This is done by getting a handle and calling functions. Linking (in any form)
excluded only if “I carry everything I have with me” and nothing else
necessary.
Hello, acidrain
aci> This is a type of playing by the rules, vaguely reminiscent of oska
Without the axis, this is a completely unnecessary perversion.
The "lib in a jar" concept is good for programs that support plugins. In this
In this case, the program plays the role of the OS, and the plugins play the role of applications. Lets them steer
system calls (without an intermediate call - opening the library), etc.
I'm talking about something else. About runtime self-assembly of programs from those available on
library disk. In this case, self-modification is not scary and there is complete
power over memory. You will have to pay for this with loading delays (or
collect everything into a candy bar and get a regular program).
PS. Initially, my thought was aimed at the following - to finalize my modular
structure to a form that is applicable in some of my programs. For this I collect
information about ways to present object code on different platforms,
trying to take something interesting from everyone. Along the way I started daydreaming (see first post
:) ). And then people swooped in and let’s praise the Amiga (and purely in words,
without any useful information for me). You are an exception - you post links,
I've already dug up some things I need :)
Hello, yoko_ono
yok> In my humble opinion, the original idea of the respected Vitamin
yok> is dictated more by imitation of the PC than by the real one
yok> necessity and convenience.
If you look at it, everyone imitates someone. The author of the first "arrows and windows"
in some buta or commander, too, probably foaming at the mouth, was accused of
imitation of Xerox/Apple or (in a terrible whisper) WIND!!! And nothing, it's not
it made it difficult to briskly stomp on the keys and steer with the arrow, and then stick out your tongue
attach the mouse.
With the level of development of development software that we have now, the idea is very
cheese (the use of cross-assemblers is not implied).
yok> As he correctly noted, linking with certain libs in runtime (in
yok> the moment the program starts) will lead to coma. Moreover, I’m not afraid
yok> of this word, to a terrible coma.
Not that creepy. The main losses are for downloading/unpacking files. Linking
(especially if symbolic names are used) is also resource-intensive (but less,
than disk operations), but setting up addresses is very fast.
yok> It will be much faster to read 'statically linked' (using
yok> in literal terms) a code block, which also clamps betteryok> than many individual pieces.
Well, now everywhere, quite often this is the case - the candy bar is loading, followed by
a statically linked and packaged piece of code. There's a lot at stake, let's get started
first...
The point of the idea is to move common pieces of code into separate files (parts of a file in the case
library archive). If the user is willing to sacrifice loading time
programs for the sake of versatility and upgradability - please do not prepare - we are making
monoblocks and we get what we wanted
Hello Vitamin
Vit> I read it. Educational. And now a few technical questions
Vit> 1) According to the first link, a description of the library header, according to the second example,
Vit> does not match the structure description. Are these two different formats? If
Vit> yes, then where is the description for the second format
Vit>
Dear acidrain, apparently, he got excited, or I didn’t understand something. Follow the links
something related to a sprinter.
> Next we talk about the first (described) format
> 2) The module is relocatable (no technical details
> I really saw it, it would be interesting, please post a link if you have one), why
> need to select the desired window?
>
On the Amiga lib - the same code, and is also fixed to absolute addresses when
loading.
> 3) Kernal in the form of entry points is not gut, at least for that
> the goal that I described in the first post of the thread. Instead there should be
> linking with correction of the calling module code for substitution
> specific call addresses (as well as data structures)
> That is, you claim that adjusting each left-wing program according to
absolute library addresses are better than giving each program just an address
the beginning of the entry points on the library? This clearly demonstrates the thesis 'pc ate
Moscow'...
Programs on Amiga can be COMPLETELY relocatable, without relocation data
in general, and at the same time it’s great to use any libs.
With the only exception - there is no call (ix+const) command on the Z80
Hello, acidrain
aci> Wrong. =) And the peculiarity is that they are not made that way and are not
aci> are resource-intensive and do not require many tons of memory to work, as in others
aci> cases.
This is not the answer. I believe that they are “not made that way,” but why and how and what?
aci> You should first study what Amiga libli are and what they are eaten with.
aci> For info;
aci>; http://www.nedopc.org/forum/viewtopic.php?t=7689&highlight=lib
aci> http://www.nedopc.org/nedopc/shaos/libman_r.shtml
Where is it about Amiga libs? Or when did the Sprinter turn into an Amiga?
Hello, acidrain
aci> Let's just say that the kernal (exec.library on ammi) doesn't link anything! Why
aci> link? The program requested a library, say gadgets.library - exe
aci> searches, loads into memory, returns its handle (address in memory, i.e. dot
aci> input), the program already has an offset from the handle (i.e. subfunction number) in
aci> register D0 (type A on z80) calls the starting address of the library - tama
aci> physically registered jp $......
Mosk is completely corroded :( and how does this differ from the screw one:
HMODULE h = LoadLibrary(pluginName);
FOO fn = (FOO)GetProcAddress(h,"foo");
(*fn)();
CloseHandle(h);
or Linux:
m = dlopen("libsample.so", RTLD_LAZY);
fn = (FOO)dlsym(m, "foo");
(*fn)();
dlclose(m);
Hello elf/2
elf> HMODULE h = LoadLibrary(pluginName);
elf> FOO fn = (FOO)GetProcAddress(h,"foo");
elf> (*fn)();
elf> CloseHandle(h);
elf>
elf> or Linux:
elf>
elf> m = dlopen("libsample.so", RTLD_LAZY);
elf> fn = (FOO)dlsym(m, "foo");
elf> (*fn)();
elf> dlclose(m);
Uh-huh. This is what I was talking about. The same Faberge only in profile. Tovarischi except
the Windows didn’t see anything, but they are very proud of the fact that they saw the Amiga, and others
no.
Hello, acidrain
aci> Mlyn, read, people, don’t get mad! I wrote that I am not only an amiga
aci> and is passionate about spec. And I provided links for information! I still need something
aci> chew?! I didn't think that icebear, whom I respected, was so much
aci> inattentive.
It's most likely your problem :) How do you tell me to understand the links you provided?
immediately after your phrase “You should first study what Amiga libs are and with
what do they eat?"
aci> No, that's funny! Have you seen TOS? Let's compare pussies?
No, what kind of pussies? You said that Amiga libs are cooler, that’s what people are
became interested, “reached out.” And you immediately get offended. I would have written it more clearly,
There would be no questions. So everything is fine :v2_cheer;
aci>; And also, describe the discovery process, our know-it-alls, lib in Windows and
aci> Linux. I described it, albeit superficially.
Well, elf/2 already wrote to you.
Hello, acidrain
aci> here's how it differs:
the code was skipping around... honestly, I didn’t understand what you wanted to say with this source code :(
Well, he’s on ASMA, so what?
in Windows you can also:
1. at runtime, load the library by name and get it in some register
pair its handle (it is not the download address, so what?)
2. if INVALID_HANDLE_VALUE is returned, then there are some problems, what exactly?
you can find out by pulling another system function
3. Next we get a pointer to the function by passing its name or sequence number
(after this we don’t need them)
4. call her by this pointer directly
5. when the library is no longer needed, unload it
6. if the library is compiled without base relocation, it will be loaded according to
there will be no fixed addresses and no loading overhead...
I suspect that read-only segments (code) can be shared between processes, although
I won't say that
It is possible that when compiling the code you will get more than in the proposed example, but
If you want, you can write it in Asma...
aci> Damn, the scoop is in action! Such resistance in the West is unlikely
aci> you will meet, I know from personal experience.
And what does the scoop have to do with it? I'm interested in understanding what exactly the Amiga approach to
working with libs is very different from the same Windows.
I forgot to add that init/cleanup is also there, the system pulls the dllMain c functionthe necessary argument
Hello, Vitamin
вот чем отличается:
┌─- CODE ───
; /+===========================================================+/
; // //
; // Open all Needed Libraries and Try Optional Ones. //
; // //
;/+===========================================================+/
OpenLibs
;==== Exec Always needed !
move.l #EM0,Exitmessage
move.l Execbase,a6
move #39,d0 ;version
lea IntName,a1
call OpenLibrary
move.l d0,Intuibase
tst.l d0
beq .fail
;==== Dos needed for VBL task (NO MORE VBLTASK).
;==== dos always needed.
IFNE Own_Dosbase
move.l #EM1,Exitmessage
move #36,d0 ;version
lea DosName,a1
call OpenLibrary
move.l d0,_DOSBase
tst.l d0
beq .fail
ENDC
;==== ASL needed for screen request.
move.l #EM2,Exitmessage
move #36,d0 ;version
lea _AslName,a1
call OpenLibrary
move.l d0,Aslbase
tst.l d0
beq.b .fail
;==== Graphics always needed.
move.l #EM3,Exitmessage
move #39,d0 ;version
lea GraName,a1 call OpenLibrary
move.l d0,GfxBase
tst.l d0
beq.b .fail
;==== Cybergraphics.library can be here or NOT !!
;==== if d0 = 0, CGX Screens are impossible.
move #39,d0 ;version number was not checked.
lea Cgxname,a1 ;"39" must work for CGX3 and 4.
call OpenLibrary
move.l d0,Cgxbase ;can not cause error.
;===== we MUST open timer.device to synchronise the scripts.
; OpenDevice("timer.device",0L, (struct IORequest *) AudioIO ,0L);
;== alloc some iorequest
;error = OpenDevice(devName, unitNumber, iORequest, flags)
;D0 A0 D0 A1 D1
move.l #IOTV_SIZE,d0 ;size of "iorequest for timer device"
structure.
jsr _AllocRmb
tst.l d0
beq.s .fail
move.l d0,TimerDev
move.l d0,a1
move.l Execbase,a6
lea Timername,a0
move.l #UNIT_MICROHZ,d0 ; It has precision down to about 2
microseconds,...
clr.l d1
call OpenDevice
move.l d0,TimerDevResult ;used for closing
tst.l d0 ; 0 if successful
beq .nodevice
clr.l d0
bra.s .yesdevice
.nodevice
moveq.l #-1,d0
.yesdevice
;Note; if; CGX is not present, 0 is returned as base.
; It can be a nice way to decide if the screen will be
; AGA or CGX.
;
.ok
moveq.l #-1,d0 ;no error!!!
.fail
rts
└── CODE ───
=)
Guys, either I'm a bad teacher or you're accordionists.
File: samplelib.zip http://zx.pk.ru/attachment.php?attachmentid=3907
Hello, acidrain
So as not to mislead you -
┌─- CODE ───
; +------------------------------------------------------------+
; //
; /Useful Macros/
; //
;+------------------------------------------------------------+
call macro
jsr_LVO1(a6)
endm
└── CODE ───
Hello icebear
ice> Where is it about Amiga libs? Or when the Sprinter managed to turn into
ice> Amiga?
Mlyn, read, people, don’t get mad! I wrote that I am not only an Amiga and a Speck
passionate. And I provided links for information! Who else do I have to chew on?! I didn't think
that icebear, whom I respect, is so inattentive.
quote: The comrades have not seen anything except Windows, but they are very proud of the fact that
saw the Amiga, but others did not.
No, that's funny! Have you seen TOS? Let's compare pussies?
And also, describe the discovery process, our know-it-alls, lib in Windows and Linux. I
described, albeit superficially. If you want to get to the bottom of it, tell me, I’ll send it
exec.library sources.
Damn, the scoop is in action! You are unlikely to encounter such resistance in the West, but
I know from personal experience.
Hello icebear
ice> It's most likely your fault :) How would you like to understand what you've given
ice> links immediately after your phrase “You should first study what it is
ice> Amiga libli and what do they eat with."?
ice>
And the fact is that, at my instigation, Shaos wrote libman and used some kind of Amiga
experience. Exhaustive?
> No, what kind of pussy? You said that Amiga libs are cooler, that's the people
> and became interested, “reached out.” And you immediately get offended. I would write
> is clearer, no questions would arise. So everything is fine :v2_cheer;
>;
I didn’t say - I have a gender, it’s MALE. Not neuter.
Hello, acidrain
aci> Such resistance is unlikely to be found in the West
Resistance to WHAT? Brainwashing that everything is done in Amiga
the only correct method? As elf/2 clearly showed, in the same Windows and
Linux with dynamic libraries works EXACTLY THE SAME -
connected, called, released. This is dynamic linking at runtime.
Hello, acidrain
aci> No, enlighten me!
And everything is very simple: lib is a static library, it is also relocatable,
but here it is “imprinted” into the final program code when linking (with editing
all calls of course). This increases the size of the program. Well, dll - you yourself
you know. Moreover, the dll in Windows is loaded once, upon request. Yes
the ability to load the dll directly yourself (as shown by elf/2), or (as it were
it would be more correct to say in Russian, I apologize, but Russian terminology is in this
case is almost unfamiliar to me) compile a call to any function from the desired
libraries, so when this call is executed, Windows itself will load
library. The last method is all windows on Windows, because user32 and gdi32 with
system startup hangs in memory. On the Amiga this is hardly done differently.
Hello, acidrain
aci> And the fact is that at my instigation, Shaos wrote libman and used some
aci> Amiga experience. Exhaustive?
In order to guess about such a development of affairs, what abilities do you need to have?
aci> I didn’t say - I have a gender, it’s MALE. Not neuter. I don't
aci> said that they are cooler, don’t attribute them.
Why are you so small? I misspelled it, not on purpose, isn't that so?
it was clear. And don't cling to words. Cooler in this case - "what are they wrong
made and not resource-intensive and they do not need many tons of memory to work." What for?
write with boiling water if the meaning of my words is clear? If we go by principle -
My question was for yoko_ono, and you answered. Who is to blame now that your
Was the answer unclear?
Hello, acidrain
aci> In general, on the Amiga there is one lib for everyone; it is not duplicated in memory.
This would be the so-called singleton pattern. What do you do with the data in this case?
Also the same for all callers? How do threads work?
Hello, acidrain
aci> Please clarify further. Why is the same thing on ammi less resource-intensive and more
aci> fast (comparing the same power of computers)?
aci> Why then mess up the dll on the spec? If your favorite PC has libs?
aci> Do it as in pc - not dll but libly.
Not about me, but I'll get in. Parameters of resource intensity and speed, as well as
identical computer capacities (units of measurement are of interest) to the studio. And also,
I hope the difference between dll and lib is known?
PS; Warning; possible misinterpretation - nothing personal.
Hello, acidrain
aci> Why drag from memory? I didn’t understand! Why the same code in different
aci> store the program on the screw and in memory, if possible only once per
aci> screw!
That's what they're telling you. On the Amiga it’s done the same way as on Windows (or
on the contrary, on Windows as on Amiga).
aci> CLL is here despite the fact that pieces of its libs (functions) are linked to the program,
aci> even if they (or) are not really noonas there.
I don’t know what CLL is, but you didn’t say anything new.
aci> What does the axis have to do with it?
Despite the fact that in Windows the task of loading/unloading libraries is assigned to it and it
looks and monitors who uses the library, who actually uses it, and who
has already fallen off.
aci> The data is different for each thread, I can’t imagine it any other way
aci> is controlled by signals/semaphores. As one of my friends says - in Windows
aci> almost the same, but clumsier =)
Well then, why did the message from elf/2 outrage you? He told you too, in others
words.
Hello, acidrain
aci> Lib missing. If only in C or so to speak HLL...
I don't understand. What does the programming language as such have to do with it? These are the possibilities
the OS itself, if it does not support working with dynamic libraries, then at least
write in BASIC. And so, everything you wrote about libraries on the Amiga is suitable and
under Windows. The main idea of the dll is not to drag the same code from memory two hundred times
and in the event of a code change, do not recompile every program that uses this
library.
Hello, acidrain
aci> Please clarify further. Why is the same thing on ammi less resource-intensive and more
aci> fast (comparing the same power of computers)?
Let's say you're right and Windows/Linux implementation of dynamic libraries eats up
more resources and works slower (although as icebear correctly noted this
no one measured it).
I can assume that this is the result of the fact that:
1. Ammi implementation is less flexible
2. on Ammi everything is written in Asma and optimized by hand
aci> Why then mess up the dll on the spec? If your favorite PC has libs?
aci> Do as in pc - not dll but libly
As far as I understand, no one is stirring anything up yet. you said that ammi has a unique one
an implementation of shared libraries that doesn't exist anywhere else. moreover, she
ideal for transfer to Speccy. the people present here are
seriously interested, wanted (at least for me) to know about it
more... all the links that flew here did not shed enough light
and here we should not be offended and scold the PC, but explain in a constructive way what
there is something on ammi/PC/MacOS/etc.
Hello, acidrain
aci> I'm not a PC coder, what do you mean it's not a download address?
handle is a unique library identifier (32 bit number)
aci> Shaitan has! This apparently doesn’t exist anywhere, if I focused on
aci> INVALIDE_HOLD_VALUE. AOC will immediately return the error number.
This saves one or two commands and probably nothing more. if there are any errors
a lot, you will still have to create a separate function to process/display them
to the user
aci> There is a plus on the PC - if the rogue programmer has not unloaded, then the output will unload
aci> herself, am I right?
yes, when the process is completed and if no one else uses it
aci> I don’t quite understand what you mean here.
if several processes have loaded the same library, then immutable
segments (for example a code segment) will be present in memory once. although on
100% not sure
aci> Analyzing all of the above, I affirm that the pc is cooler! But ammi is closer and
aci> is smarter. =)
Well, why are you doing this? I suspect that there is something to learn from any platform
Hello, acidrain
Well, damn it, we wrote it :) but there’s really little point so far :(
aci> or at what stage is it linked to the prog - when it is only
aci> is it compiled or when the end user runs it?
possible options:
1. The library is linked to the program statically, i.e. at the stage
compilation/linking
2. the system raises the library when the program starts
3. the library is loaded upon request from the program (these are just the examples that
I brought it)
By the way, when I said that Windows/Linux implementation is more flexible, I meant
just these three options. why all this:
1. the program does not depend on what libraries are on the user’s machine
2. The size of the program is small. no additional body movements (hands
no need to load/retrieve function address)
3. to implement "plugins" in this case the program can work with
libraries that did not exist at the time of its creation through some API
once again about the handle returned from LoadLibrary - it’s just a number, not
associated with the download address
and now IMHO; dynamic; libraries are needed mainly for system
programs, it won’t be very convenient to use them on Specki since we
tied to floppy.
Hello, yoko_ono
yok> That is, you deliberately decided to slow down the loading of the program for
yok> end-user? So that he listens to the spasms of the disk drive darting around everything
yok> disk, for the sake of the dubious convenience of the programmer?.
I may not have understood Vitamin's original post correctly, but it's in the last line
wrote:
Vit> autoassembler utility that assembles from a loader and a bunch of libraries
Vit> a single packaged monoblock that runs on any machine solves
Vit> third minus
Vit>
that is, the end user will not see this entire kitchen, perhaps except for some
brakes at startup to configure libraries for specific addresses
Hello, yoko_ono
yok> You yourself say that they are improving and, therefore,
yok> increase in size
What does this mean? Maybe on the contrary... they are decreasing?
yok> and it becomes impossible to guess the amount of free memory!
Why guess? No need to guess. In the most primitive case, a sign is built
memory allocation between libraries...
Hello Shaos
Sha> I mentioned the link to libman a couple of times on this forum - 0
Sha> interested
Sha>
Sha> If there are >= 3 people interested, then I promise to port it
Sha> sprinter on the Spectrum - there are examples of libs in this format, a piece
Sha> was very promising, but the sprinter died...
So no one is interested? Maybe you'll be interested?
Hello Vitamin
Vit> Resistance to WHAT? Brainwashing that everything is in the Amiga
Is Vit> done using the only correct method? As elf/2 clearly showed, in
Vit> the same Windows and Linux with dynamic libraries work EXACTLY
Vit> THE SAME - connected-called-released. This is dynamic
Vit> linking in runtime.
Please clarify further. Why is the same thing on ammi less resource-intensive and more nimble?
(comparing the same power of computers)?
Why then mess up the dll on the spec? If your favorite PC has libs? Do
as in pc - not dll but libly.
Hello Vitamin
Vit> since they were not taken into account at all.
I can say the same for you! =)
Hello, acidrain
Okay, let's digress. I didn't want to offend anyone.
In my version, the program requests the required library, the main one looks for it on
screw (disk or whatever), loads it, returns the entry point. then dominates
program - uses liblu (several, if necessary).
In the Vitamin version, what will it all look like?
Hello elf/2
elf> 1. Ammi implementation is less flexible
elf> 2. on Ammi everything is written in Asma and optimized by hand
1 - no
2 - no, C and only C
Hello elf/2
elf> handle is a unique library identifier (32 bit
elf> number)
didn't answer the question. IMHO =)
Hello elf/2
elf> if several processes have loaded the same library, then
elf> immutable segments (for example a code segment) will be present in
elf> memory once. although I'm not 100% sure
In general, on the Amiga there is one lib for everyone; it is not duplicated in memory.
Hello elf/2
elf> and here we should not be offended and scold the PC, but explain it in a constructive way
elf> in line with what is what on ammi/PC/MacOS/etc.
Do you know? Read the implementation (libla example). There are questions - many with
They'll be happy to advise.
Chaos was never noticed? He offered you a real deal! You don't care, come on
push me! What are you doing, guys?! Let's do it and not be a pain!
Hello elf/2
elf> the code was skipping around... honestly, I didn’t understand what you wanted to say with this source code
elf> :(
elf> well, he's on ASM, so what?
elf>
Asm/non-asm - whatever came to hand, that's what we got :) Just showed the mechanism
Libla opening/closing.
> in Windows you can also:
> 1. at runtime, load a library by name and get it in some
> register pair of its handle (it is not a loading address, well
> what?)
>
I'm not a PC coder, what do you mean it's not a download address?
> 2. if INVALID_HANDLE_VALUE is returned then there are some problems, which
> you can find out exactly by pulling another system function
Shaitan! This apparently doesn’t exist anywhere, if you focused on
DISABLED_HOLD_VALUE. AOC will immediately return the error number.
> 3. Next we get a pointer to the function by passing its name or ordinal
> number (after this we don’t need them)
Also practically, I agree.
> 4. call it by this pointer directly
Yeah, same thing.
> 5. when the library is no longer needed, unload it
> There is a plus on the PC - if the scam programmer has not unloaded, then the output will unload it itself,
am I right?
> 6. if the library is compiled without base relocation then it will be loaded
> at fixed addresses and no loading overhead
> will be...
I can’t imagine, because on the Amiga everything is relocatable, why statics?
> I suspect that read-only segments (code) can be shuffled between
> processes, although I will not say this
I don't quite understand what you mean here.
> it is possible that when compiling the code you will get more than what is proposed
> example, but if you want, you can write it in ASMA...
That's not what we're talking about.
Analyzing all of the above, I affirm that it’s cooler! :v2_finge; But; ammi is closer
and smarter. =)
Hello elf/2
elf> a unique implementation of shared libraries that does not exist anywhere else
I didn't say that! don't attribute it!
Hello icebear
ice> On the Amiga this is hardly done differently.
The lib is missing. If only in C or so-called HLL...
Hello icebear
ice> I don't understand. What does the programming language as such have to do with it? This
ice> capabilities of the OS itself, if it does not support working with dynamic ones
ice> libraries, then at least write in BASIC. And so, everything you wrote about
ice> libraries on the Amiga are also suitable for Windows. The main idea of the dll is not
ice> drag the same code from memory two hundred times even if the code changes
ice> do not recompile every program that uses this library.
Why carry it from memory? I didn’t understand! Why the same code in different programs?
store on the screw and in memory, if possible only once on the screw!
HLL here despite the fact that pieces of its libs (functions) are linked with the program, even if
They (either) are not really noonas there. What does this have to do with the axis?
The data is different for each thread, I can’t imagine it being managed any other way
signals/semaphores. As one of my friends says, it’s almost the same in Windows, but
clumsier =)
Hello icebear
ice> And also, I hope the difference between dll and lib is known?
No, enlighten me!
Hello icebear
ice> Despite the fact that in Windows the task of loading/unloading libraries is assigned to
ice> her and she watches and monitors who uses the library, who is her
ice> actually uses, but who has already fallen off.
ice>
And before that you stated that:
"What does the programming language as such have to do with it? These are the capabilities of the OS itself, ..."
That is is she monitoring the dll or lib? You've confused me.
Exec is also watching.
Okay, what the author suggested - is it a lib or a dll? or at what stage is it linked?
with a program - when you just compile it or when the end user runs it?
Hello icebear
ice> Quote:
ice> Message from acidrain
ice> No, that's funny! Have you seen TOS? Let's compare pussies?
ice>
ice>
ice> No, what kind of pussy? You said that Amiga libs are cooler, that's the people
ice> and became interested, “reached out.” And you immediately get offended. I would write
ice> is clearer, no questions would arise. So everything is fine
I think it’s clear that the quote is mine, so I answered, what does yokoon have to do with it? =)
Well, I'm not touchy! I can even admit my mistakes and shortcomings - I try
develop in all respects 8)
Hello, acidrain
I'm freaking out, dear editors... 4 pages (in total) of attacks... Where
the world is rolling...
PS. Judging by the intervention of fresh people in the discussion, I conclude that
I don't have any insanity. And then yesterday it was a sinful thing to think that my
the answers in the topic were only in my mind, since they were not taken into account
absolutely.
Hello Vitamin
Vit> I'm talking about something else. About runtime self-assembly of programs from
Vit> libraries available on disk. In this case, it’s not scary and
Vit> self-modification and has complete power over memory. For this cause
Vit> will have to pay with loading delays (or assemble everything into a candy bar
Vit> and get the regular program).
Vit>
Oh, is it so straight and complete? You yourself say that either they are improving and,
consequently, they increase in size - and it becomes impossible to guess
amount of free memory!
PC with 4 gigs of virtual space and 32-bit addressing is one thing, but another thing is
Spectrum...
> PS. Initially, my thought was aimed at the following - to finalize my
> modular structure to a form that is applicable in some of my programs.
That is, you deliberately decided to slow down the loading of the program for the end user?
So that he listens to the spasms of the disk drive, darting all over the disk, for the sake of dubious
convenience for the programmer?...
Hello Vitamin
Vit> Any questions? corrections? additions?
Regarding object files: aren't these the files that contain the executable code,
but don’t have a “wrapper” (that is, a header)? Because the exe from the dll is not supposed to
It is very different, or rather it differs in that the exe does not export functions.
Hello, yoko_ono
yok> Libs are simply written in a reentrant style. All local data -
yok> on the stack, if necessary, an object, address is created for each application
yok> which is passed to functions.
Oh, that's it! Windows is the opposite :) The question is not in this topic - but in the event model
is there?
yok> The data is naturally the same, because there is no virtual memory system. Streams
yok> is also not available (in AOC) - only individual tasks.
Wait, can't Amiga read from a disk and do something else?
in parallel? How can this be done without threads (in the sense that it would work
always and everywhere)?
And another offtopic: on the avatar there is a cat from Ivan Vasilyevich?
Hello Vitamin
Vit> (this is me asking to show an example of connecting the library and calling
Vit> functions).
Vit> 2Shaos; information; I read libman as soon as acidrain
Vit> posted the link. And he asked several questions, receiving answers only to
Vit> half. So I agree that there is 0 interest...
Hmm, I posted it. you don't read, right?
Who did you ask questions to?
I'm for point 2. Finally, a constructive conversation is emerging.
But no one is stopping C from writing for point 1. ;)
Constructively, you didn’t want to talk - I laid it out, searched, tried to hear
questions. There was nothing. If you have any questions, ask. I can give you 10mb for soap
source code holy of holies exec.library (the only libla written in ASMA, and
not in si). Also about 30 MB rom kernel manuals - there will be a desire to study and
understand the entire system from the inside? =)
Hello Vitamin
Vit> 2acidrain; Let's; Let's start with terminology (we should have started with this and
Vit> start...). so, we have 3 types of program code management
Vit> 1) Static linking. Object files created in advance
Vit> are connected to the binary at the compilation stage and are present in
Vit> executable file. During operation, no additional
Vit> movements on the part of the program to connect these object files
Vit> are just direct calls to functions. In the simplest case, object
Vit> files compiled from different source codes are collected in
Vit> final binary. When connecting the same library in two
Vit> different programs data is physically duplicated. Examples - a,obj,lib
Vit> files (the first thing that came to mind)
Vit> 2) Dynamic linking. Object files are included during
Vit> work of the program by opening the library (no matter who does it
Vit> OS or the application itself). Further function calls are carried out on
Vit> based on the existing descriptor of the connected library. When connectingVit> of the same library into two different programs (for multitasking
Vit> OS), the code is not duplicated. Examples - so, dll.
Vit> 3) Other. In particular, the lack of linking at the binary level
Vit> files, only at the source level at the compilation stage.
Vit> Using only internal functions or OS functions (in general
Vit> case, if any).
Vit>
Vit> Any questions? corrections? additions?
Why didn't you start with terminology right away? I couldn't figure it out without my help
what is it called? Moreover, you write below that your creation does not fit any point
OK, then what did you come up with?
You posted your idea for approval or advice - here's mine
advice: don’t try to complicate things, look for simpler solutions. IMHO AOC for
These goals (imitation) are much better suited than Windows or Linux.
There is generally a ready-made one - Shaos libman. Take it, use it! Develop! Don't invent a bike!
Hello, acidrain
aci> did not receive answers to all of them
I’ve already flagged a lot, but forgive me - a quote to the studio! what did you ask?
about the second type of lib - read the forum, or should I rewrite it too?
As for the first one, read the Shaos website, I won’t think for you! don't ask =)))
> Provided there is no OS, applicable only in a plug-in system...
>
give reasons!
> Let's take a closer look at that source. Calling a function (multiple)
> occupies one line there. Everything else is preparing the library and its
> release. This is a one-time sequence.
And if you call several functions from one library, with one call in lib 1,
another in lib2, then 4, then 1 - what to do in this case?
> And then people swooped in and let’s praise the Amiga (and purely on
> words, without any information useful to me)
Before that you wrote that thank you for the information, it is so useful. Now you write that
I didn’t write anything at all? And how many people flew in? Me and unknown
where is the searched yaka_ini from? Now count how many people attacked
me?
Hello elf/2
elf> 1. The library is linked to the program statically, i.e. at stage
elf> compilation/linking
elf> 2. the system loads the library when the program starts
elf> 3. the library is loaded upon request from the program (these are the ones
elf> examples that I gave)
elf>
Just like on the Amiga. Where is Windows/Linux more flexible?
Hello elf/2
elf> 2. The size of the program is small. no additional body movements
elf> (you don’t need to load/find the function address by hand)
elf> 3. to implement "plugins" in this case the program can work with
elf> libraries that did not exist at the time of its creation through some API
We are talking about the same thing. And with plugins - nonsense. no plugin in libl category
shove it! a plugin is just that: a plugin. here you need an interface like Arexx's
elf> once again about the handle returned from LoadLibrary - it’s just a number
elf> not related to the download address
What is this? serial number of the prisoner? Handle - basic input (exaggerated), like
on pc - xs.
Hello elf/2
Can I butt in? Well, just a little...
Personally, for those programs - such as system ones (converters and various packers) -
Just a couple of plugins would be useful - working with disk (save/load/select
file from the directory/entering a name for the save) and some semblance of a GUI (that is, the inscription
to display if necessary, well, you can select something on the screen). basically it's me
I’ve already written it for myself - though in an obscene form that satisfies me
one. Implemented exactly as an include at the compilation stage (that is, lib - right?
=) )
If modules with similar capabilities were actually written that could
It would be easy to use - I have no doubt that I would use them...
About loading time and other things - if you don’t go into the directory for
determining the coordinates of a file on disk, then loading 2-3 files will be practically
invisible even in real life... And in the absence of an operating system, I doubt something
the emergence of programs that use dozens (hundreds!!! =)) of similar modules...
Personally, I can think of a couple more that are really necessary and that’s it...
Sorry that I'm here in dirty boots and in the shower, okay?
Hello, acidrain
aci> but excuse me - a quote to the studio! what did you ask?
Regarding relocation tables. I'm interested in knowing their device. Are there docks? B
poking around in source codes is resource-intensive :)
aci> argue !
Please. To load a library on demand, you need some kind of manager for these
libraries, as well as a memory manager for resource allocation. Since we have
If there is no OS, then it is clear that the program is forced to carry these managers with them. All
libraries are connected once and never disabled (in this case
the manager turns out to be “disposable”) If this is not the case, then we get a plugin
system (what I was talking about).
In essence, I propose just such a system, but with some fundamental
differences:
-the application does not connect anything itself, everything is done by the bootloader
-the location of libraries is not fixed, but is chosen according to circumstances
(in the simplest case, one by one in memory)
-there is no kernel; when linking, direct call addresses are substituted.
aci> And if you call several functions from one library, with one call in
aci> Lible 1, another in Lible2, then 4, then 1 - what to do in this case?
If the lib names are unknown at the compilation stage, then open the required number
libraries, get function pointers from them and call them using these pointersthe required number of times. If the names are known, then with all these operations
(opening-receiving address-closing) is usually managed by the OS
Hello elf/2
elf> that is, the end user will not see this entire kitchen, perhaps except
elf> some brakes at startup to configure libraries for specific ones
elf> addresses
After passing through the auto assembler, we end up with a regular BASIC file, in which
everything is inside and no additional movements are made to load it. Those.
essentially turning dynamic-static (I have exactly this option, not
fits into my own classification :)) linking into a purely static one.
Hello icebear
ice> On object files: aren't these the files that contain
ice> executable code, but do not have a “wrapper” (that is, a header)? Because
ice> exe from dll in theory is not very different, more precisely it differs in that
ice> exe does not export functions.
In theory, yes, for example, on Linux, the result of the assembly (object file or shared
library) depends on the compiler switches (if the program is not compiled with
main(int argc, char const * argv[])) In Windows you also need to register
additional specifiers in headers, depending on what is imported
or a function is exported.
aci> I am for the 2nd point.
Do you mean dynamic linking? If there is no OS, only applicable
in a plugin system...
aci> Structurally, you didn’t want to talk - I laid it out, searched,
aci> tried to hear the questions.
Well, I asked questions about the first two links from the nedopc site - not all of them
got answers. Regarding the other links - recommendations for programming in
amiga. Without knowledge of its assembler, it is of little use to go there, in the content of that cycle
I didn’t find anything interesting for myself.
aci> (the only libla written in ASMA, not in C)What for (why, see above). In such a situation, S is closer. And even more useful is intelligible
dock according to the format (I think I have it somewhere). Because the raw example is not enough
what will you understand
yok> And such horror FOR EVERY function?..
yok> On the Amiga it was done in an optimal way - it’s enough to call the function
yok> know which jmp in the call table should be accessed (and not extracted
yok> offset for each function separately), and in addition the base address (where
yok> this call table, that is). I think the problem with PC is that
yok> give the whole register to the base register when calling through the jmp table -
yok> unaffordable luxury for poor x86 architecture.
Let's take a closer look at that source. Calling a function (multiple times) takes
one line. Everything else is preparing the library and releasing it. This
a one-time sequence.
This approach (forced loading of the library and obtaining the function address)
used only when organizing a plugin system - we get a list of plugins,
we connect the one we need when needed, get the addresses of the necessary functions from it, and work
with them, we release the plugin. (When using OOP (modern approach) from
plugin, one single function is picked out - the class factory, whichproduces instances of plugin-dependent classes whose functions are called
occurs through the mechanism of polymorphism).
If the names of the modules are known at the compilation stage, then you can force the compiler
generate special code that includes the library when the program starts. When
In this case, work with its functions is carried out completely transparently for the programmer.
Hello, yoko_ono
yok> it becomes impossible to guess the amount of free memory!
I agree there is a problem here. We must look for a way out.
(however, with dynamic linking and “libs in jars” it is no less easy to guess
impossible)
yok> That is, you deliberately decided to slow down the loading of the program for
yok> end-user? So that he listens to the spasms of the disk drive darting around everything
yok> disk, for the sake of the dubious convenience of the programmer?...
There is such a thing - caching.... Usually it makes life a lot easier and speeds up
work.
Mdablin... Straight military action... Although I must admit, my only
This is a constructive dialogue with yoko_ono (although not without bias). All
the rest of the acidrain thread proves that the same concept is on the Amiga and
Windows is called differently and in every possible way ignores the answers to its own questions
(I'm asking you to show an example of connecting a library and calling a function).
2Shaos; information; I read libman as soon as acidrain posted it
link. And he asked several questions, receiving only half answers. So
I agree that there is 0 interest...
2acidrain; Let's; Let's start with terminology (we should have started with this...).
so, we have 3 types of program code management
1) Static linking. Object files created in advance are connected tobinary at the compilation stage and are present in the executable file. During
work does not require any additional movements on the part of the program to
connect these object files, just direct function calls. In the simplest
case, object files compiled from different source codes are collected
into the final binary. When connecting the same library to two different
program data is physically duplicated. Examples - a,obj,lib files (the first thing on
it came to my mind)
2) Dynamic linking. Object files are included during operation
program by opening the library (no matter who does it, the OS or itself
application). Further calls to functions are carried out based on the existing
descriptor of the connected library. When connecting the same library in
two different programs (for multitasking OS), the code is not duplicated. Examples-
so.dll.
3) Other. In particular, the lack of linking at the binary file level, only
at the source level at the compilation stage. Use only internal
functions or OS functions (in general, if available).
Any questions? corrections? additions?
Hello elf/2
elf> HMODULE h = LoadLibrary(pluginName);
elf> FOO fn = (FOO)GetProcAddress(h,"foo");
elf> (*fn)();
elf> CloseHandle(h);
elf>
elf> or Linux:
elf>
elf> m = dlopen("libsample.so", RTLD_LAZY);
elf> fn = (FOO)dlsym(m, "foo");
elf> (*fn)();
elf> dlclose(m);
And such horror FOR EVERY function?..
On the Amiga it was done in an optimal way - to call a function it is enough to know
which jmp in the call table should be accessed (rather than extracting the offset for each
functions separately), and in addition the base address (where is this call table, that is).
I think the problem with PC is that the whole register is given over to the base one when
calling through the jmp table is an unaffordable luxury for the poor x86 architecture.
Hello icebear
ice> This would be the so-called. singleton pattern. What do you do with the data in
ice> this case? Also the same for all callers? How do threads work?
It's just that libs are written in a reentrant style. All local data is on the stack,
if necessary, an object is created for each application, the address of which is transmitted
functions.
Naturally, there is only one data, because there is no virtual memory system. There are no streams either
(in AOS) - only individual tasks.
Hello, ng_dead
ng_> What does this mean? Maybe on the contrary... they are decreasing?
ng_>
From a simple fact - development is the addition of new features and capabilities. For
on the contrary, the deliberate mass removal of features and capabilities is some kind of destruction
simple. Various optimizations and removing small things - global size reduction
do not provide.
> Why guess? No need to guess. In the most primitive case, it is built
> memory allocation table between libraries...
Usually all normal programmers on the Spectrum mean that they have
there is a certain amount of memory in stock, which can be found out at the stage
compiling a program, for example. And if these so-called libraries are
have an unpredictable size?
Hello Vitamin
cap> 1. Import by function number (ordinal).
cap> 2. Using dynamic binding instead of dynamic linking.
More clarifications:
Offsets (in the address table) are compiled into the binary and are generally inaccessible
to the bootloader.
The calling code itself selects the address from the table and performs the transition.
Every time you need to call the library, you must first select an address.
> Essentially, I propose just such a system, but with some
> fundamental differences:
> - the application does not connect anything itself, everything is done by the bootloader
> - the location of the libraries is not fixed, but is selected accordingly
> circumstances (in the simplest case, one by one in memory)
> - there is no kernel, when linking, direct addresses are substituted
> call.
I support this 100%
______________________
Here's another idea. :)
Archive programs into a continuous RAR archive.
Continuous archiving will compress the same code in different programs.
And the compression ratio is decent.
All that remains is to make a launcher based on ZX-UnRAR that will
unpack the desired program into memory and transfer control to it. :)
Hello Vitamin
So, let's try to formulate the basic principles of Amiga implementation:
1. Import by function number (ordinal).
2. Using dynamic binding instead of dynamic linking.
The disadvantage of the first point is the lack of ability to control integrity during
loading time.
The second point means that the library can be considered as an OOP class (and
singleton object) and functions are called as "virtual functions". Disadvantage -
Excess of resources during execution. Even on Motorola, where there is an indirect call
according to the address table is done with one command, a register is required (very valuable
resource). What if you need to mix and match functions from different libraries? On
The Z80 will need many more machine commands just to transmit
control to the library, and, depending on the implementation, some registers
may not be available for passing arguments. In this situation,
I think the stories about “dynamic layout malfunction” can be discarded.
ice> Oh, that's it! Windows is the opposite :)
In this aspect, I think the Amiga (and Linux) approach is more correct.
The so-called "thread-safe libraries".
elf> and now IMHO; dynamic; libraries are needed mainly for system ones
elf> programs, using them on Specki will not be very convenient because
elf> we are tied to floppy-ki.It is precisely because they are tied to floppy that dynamic linking can help.
The more time we can keep libraries in memory and link them
to different programs, the more floppy resources can be saved.
Hello Vitamin
So, let's try to formulate the basic principles of Amiga implementation:
1. Import by function number (ordinal).
2. Using dynamic binding instead of dynamic linking.
The disadvantage of the first point is the lack of ability to control integrity during
loading time.
The second point means that the library can be considered as an OOP class (and
singleton object) and functions are called as "virtual functions". Disadvantage -
Excess of resources during execution. Even on Motorola, where there is an indirect call
according to the address table is done with one command, a register is required (very valuable
resource). What if you need to mix and match functions from different libraries? On
The Z80 will need many more machine commands just to transmit
control to the library, and, depending on the implementation, some registers
may not be available for passing arguments. In this situation,
I think the stories about “dynamic linkage malfunction” should be discarded.
ice> Oh, that's it! Windows is the opposite :)
In this aspect, I think the Amiga (and Linux) approach is more correct.
The so-called "thread-safe libraries".
Hello Vitamin
Vit> Regarding the relocation tables. I'm interested in knowing their device. Yes
Vit> docks? Poking around in the source code is resource-intensive :)
Vit>
Completely primitive. Each 'exe' - after loading into memory, represents
itself a certain number of sections, with codes, with data, etc. If the section has
absolute addresses with links to s.l. section - it is placed in the file itself
relative offset from the beginning of this section, and in the relocation table for this
sections - offset to the address that needs to be corrected and the section number, in
which he must indicate. Plus variations with 16-32 bit offsets. Here we go
that's it.
Hello Vitamin
yok> Each 'exe' - after loading into memory, represents something
yok> number of sections, with codes, with data, etc. If the section has
yok> absolute addresses with links to s.l. section - then in the file itself
yok> is set to a relative offset from the beginning of this section, and in the table
yok> relocation for this section - offset to the address you need
yok> also correct the number of the section to which it should point. Plus
yok> variations with 16-32 bit offsets. That's all.
What is the name for adjusting sections using relocation tables? :)
Hello, captain cobalt
yok> in the file itself a relative offset from the beginning of this section is set,
yok> and in the relocation table for this section - the offset to the address that
yok> must also be adjusted to the number of the section to which it should point.
Well yes. I did this myself. I just have a little more flexibility - there is an opportunity
refer to functions in other modules and load incomplete addresses
(high or low byte)
cap> Archive programs into a continuous RAR archive.
cap> Continuous archiving will compress the same code in different programs.
cap>
I already talked about this, you don’t even need to compress it, but just put everything into one file
or so as not to fumble around the disk during assembly.
cap> I support this 100%
Well, there you go. Once again I am convinced that in a dispute the truth is often born (at least
at least for me). How much have we discussed about the OS? :) I do a lot of things
learned for myself. It’s a little worse here, but I think the situation will improve.
So, the task is to consider options for the structure of relocatable models on different
platforms and synthesize a hybrid that is as suitable as possible for
use on spec.
Hello Vitamin
In general, once again my imho. dynamic linking (ie dll/so/exec.library) on
at the current stage in speck is not needed because:
1. there is no axis, which means the linker will have to be added STATICALLY to each
program
2. even if we use only one function from the library in memory there will be
hang all over
!!! but we don't have a lot of memory :(
3. since libraries are actually searched by file name, downloading everything
the application will take a very long time (you will have to go to the directory every time and
back). If the directory is cached for speedup, then again we run into memory...
4. as psndcj correctly noted, 2-3 libraries are really needed, is it worth it?
Should I fence this garden?
5. we don’t have multitasking, so we don’t use one library
there will be no multiple applications, therefore saving memory from
There will be no use of the same code several times either.
Vitamin's original proposal i.e. assembly from object kits (in my opinion
again) has more prospects
Hello, yoko_ono
yok> And such horror FOR EVERY function?..
yok>
of course not:
1. open the library
2. get a pointer to fn1
3. get a pointer to fn2
n. use the functions
n+1. close the library
yok> On the Amiga it was done in an optimal way - it’s enough to call the function
yok> know which jmp in the call table should be accessed (and not extracted
yok> offset for each function separately), and in addition the base address (where
yok> this call table, that is). I think the problem with PC is that
yok> give the whole register to the base register when calling through the jmp table -
yok> unaffordable luxury for poor x86 architecture.
the point is not in the "poorness" of the architecture, but in the fact that such a method of access to
libraries are used very rarely. Usually the library is linked dynamically and
the system is engaged in "obtaining pointers". from a programmer's point of view in this
In this case, you don’t need to open anything, you don’t need to resolve addresses either. he's just calling
the necessary function and that’s it. this is really optimal :)
Hello, elf/2
elf> мое imho
+1
Hello, acidrain
aci> What do you mean the names are not known? How should a coder use them if he doesn’t
aci> knows their names? Should I make a request based on functions?
Read about COM; by default, only three functions are declared there. Here
where your head starts to boil.
Hello, acidrain
aci> Oh, forgive me, a sinner, on the Amiga - no need to get pointers to
aci> functions! that's the trick.
but a direct call to a known address is faster :)
aci> Well, for me personally (!) such a common method is dynamic
aci> linkable libla - climb through the butt with a toothpick! Why does Oska need to know where
aci> what function (especially from a third-party libl manufacturer)? She needs
aci> do other things, for example realtime
the axis should make life easier for the user first and foremost and the programmer second
second. That's what Windows/Linux do. As a result, the code size and number of
errors (you can’t forget to initialize the lib, linking errors are processed
system, there is no difference for the programmer between static/dynamic
linking)
and the mechanism there is simple to the point of disgrace: Liba has a list of exported functions
and the program has a list of jumps to be imported. when loading Windows, list of jmps
corrects
Hello Vitamin
Vit> If the lib names are unknown at the compilation stage, then open
Vit> required number of libraries, get function pointers from them and
Vit> is called using these pointers the required number of times. If the names are known, then
Vit> these all operations (opening-getting address-closing) are usually
Vit> manages the OS
What do you mean the names are not known? How should a coder use them if he doesn’t know them?
names? Make a request based on functions, or what?
> Essentially, I propose just such a system, but with some
> fundamental differences:
> - the application does not connect anything itself, everything is done by the bootloader
> - the location of the libraries is not fixed, but is selected accordingly
> circumstances (in the simplest case, one by one in memory)
Well, I told you about the same thing yesterday - the bootloader opens and closes the libs.
> To load a library on demand, you need some kind of data manager
> libraries, as well as a memory manager for resource allocation.
> Since we do not have an OS, it is clear that these managers are programs> has to be carried around with you. All libraries are connected once and not
> are not disabled once (in this case the manager turns out
> "disposable") If this is not so, then we get a plug-in system (then, o
> what I said).
Don’t get confused and don’t confuse people - quote: then we get a plug-in system
again you write managers with you (one bootloader manager for everyone! like
boot). No plugins (you can, but not related to the topic) - this is just a set of standard ones
functions that use any programs (single-task axis;) with access to axis 8) and not
in vasik/tyrdos.
yok> Completely primitive. Each 'exe' - after loading into memory
yok> represents a certain number of sections, with codes, with data, and
yok> etc. If the section contains absolute addresses with links to certain objects. section
yok> - then in the file itself a relative offset from the beginning of this is set
yok> sections, and in the relocation table for this section - the offset to the address
yok> which needs to be corrected and the number of the section in which it should be
yok> indicate. Plus variations with 16-32 bit offsets. That's all.
That's right! I’m amazed by you, it’s a pity you’re married and have two daughters, but you ;)))but Vitamin was asking about libman libs and not about Amiga!
2Vitamin: I assume that everything in libman with relocation is simple, as I studied
source codes on SRR (they are there in the archives, there is even an .exe for auto relocation or something
something like that - I don’t remember, 4 years have passed)
And also, all questions about libman should be addressed to the author: Shaos, write to his forum,
ICQ - don't ask me about that, ok?
And don’t make things up, I repeat, the bike - libman - is a ready-made, well-developed format and
easily ported to spec by the author - use what is already ready! And so, if
If you crave fame, then go for it.
I can send you my first book (if I find it, I kept it on pieces of paper), which I
I wrote for the spec and the system, as I described above. Tama mouse driver type :)
Hello, captain cobalt
cap> Even on Motorola, where an indirect call to the address table is made
cap> with one command, a register is required (a very valuable resource)
You can use the register as you please! =) Nobody forbids it
use it - it is not always needed, only when accessing the library. The rest of the time
you can forget about it and use it constantly until the next call. System
is such that you take the handle of the library into the register, and when you return, it is yours again. How
and any other register necessary to transfer data to the library.
I hope I explained it clearly. So it's not a resource-intensive method!
Hello elf/2
elf> 4. as psndcj correctly noted, 2-3 libraries are really needed, it’s worth
elf> Is this a reason to fence the garden?
Worth it - this is the beginning from the beginning... for the axis :)
Hello elf/2
elf> of course not:
elf> 1. open the library
elf> 2. get a pointer to fn1
elf> 3. get a pointer to fn2
elf> ...
elf>
elf> n. use functions
elf> n+1. close the library
And, forgive me, a sinner, on the Amiga - you don’t need to get pointers to functions! here
what's the trick?
> the point is not in the “poorness” of the architecture, but in the fact that such an access method
> is used very rarely for libraries. usually the library is linked
> is dynamic and the system is engaged in “obtaining pointers”. from point
> from the programmer's point of view, in this case there is no need to open anything, addresses
> also does not need to be resolved. it just calls the required function and that’s it. this is it
> really optimal
Well, for me personally (!) such a common method is dynamic linking
libla - to reach through the butt with a toothpick! Why does Oska need to know where which function is (so
more from a third party manufacturer)? She needs to do other things
for example realtime ;)
Hello, acidrain
aci> What do you mean the names are not known? How should a coder use them if he doesn’t
aci> knows their names? Should I make a request based on functions?
very simple. there is an API - a certain set of functions. some libraries this API
support
When loading the application, we look for files by mask (for example 'plugins/*.dll'). everyone
we load the file one by one through LoadLibrary, and get it from each library
required functions.
If the file is loaded and the necessary functions are found, then we can calmly use it (by the way
in ruby they even came up with a special term for this (well, almost for this :) - duck
typing)
Hello Vitamin
Vit> (note, in EVERY program)
No, not every time!!!
Hello, acidrain
aci> Don't get confused and don't confuse people - quote: then we get a plug-in system
aci> again you write managers with you (one loader manager for everyone!
aci> type boot). No plugins (you can, but not related to the topic) - this is the set
aci> standard functions that can be used by any program (single-task OS
aci> output to axis 8) and not to vasik/tyrdos.
Let me explain. Plugin system - that is, OS and applications (only in a different
scale). One big host program with a sophisticated manager and simple
plugins. And if we don’t have a host program/OS, then create a sophisticated manager
(note, in EVERY program) there is absolutely no point.
aci> And don’t make things up, I repeat, the bike is a libman - ready,
aci> well-developed format and easily ported to spec by the author - use it
aci> with what is already ready! And so, if you want fame, then go for it.
I started writing my system a year later than the date of the article about libman.
Of course, I didn’t know anything about him, I just had some idea about
isdos object file format.
2Shaos; Can; obtain documentation on library format, capabilities, etc.
Because the functionality may not be enough and you will have to “invent”
bicycle"...
Hello Vitamin
Vit> Let's take a closer look at that source. Calling a function (multiple)
Vit> occupies one line there. Everything else is preparing the library and its
Vit> release. This is a one-time sequence.
Vit>
For EVERY function!
> This approach (forced loading of the library and obtaining the address
> functions) is used only when organizing a plug-in system -
> get a list of plugins, connect the one you need when needed, get it from
> contains the addresses of the necessary functions, work with them, release the plugin. (When
> using OOP (modern approach) is picked out from the plugin
> one single function - a class factory that produces
> instances of plugin-dependent classes whose functions are called
> occurs using the polymorphism mechanism).
> If the names of the modules are known at the compilation stage, then you can force
> the compiler generates special code that includes the library when
> program start. At the same time, work with its functions is carried out perfectly> is transparent to the programmer.
Well, you yourself wrote that in any case it comes down to picking
absolute addresses of EVERY function, either by hand or with startup code!
Hello elf/2
elf> 2. even if we use only one function from the library in memory
elf> the entire library will hang
elf>
Exactly! While compiling a lib from source allows you to compile
only REALLY required functions, and that is from assembling or from source codes
Vitamin and wants to leave!
> Vitamin's original proposal i.e. assembly from object kits (on mine
> look again) has more perspectives
Well, in my humble opinion, there is not much originality here - the idea is 'seamless' with
PC-Windows-Linux.
First of all, his idea implies relocability. Which is being implemented at the stage
compilation in any assembler or code generator and is supported by the axis on
pc/amiga/etc. On the Spectrum - neither one nor the other. Existing assemblers
all of them do not support relocation (tricks with macros do not count).
And in general, the programming paradigm on the Spectrum is alien to relocation -
unless, of course, you write all programs in the 'academic' style
Z80 programming.
If you really want lib, then you can propose the following mechanism, free from
relocatability of at least a user program (that is, one that uses
libs and loads them from disk).
The user program loads the library into a statically defined location in memory. She herselfrelocates by some method (let the author of the book practice, since he
nothing to do except write). And for example at the beginning of the indicated
the user-program of the place builds a table of calls of its functions, consisting of JP
func1:JP func2:JP func3 etc. After which the user program, knowing the beginning of this
tables (since she indicated it), makes CALLs there. Can be separated
the actual body of the library from the call table. You can put the body of the library in
page, including it before calling (no axis - no page manager,
available to the library).
Hello elf/2
elf> of course not:
elf> 1. open the library
elf> 2. get a pointer to fn1
elf> 3. get a pointer to fn2
elf> ...
elf>
elf> n. use functions
elf> n+1. close the library
elf>
We get a pointer for EVERY function used, how about 'of course not'?
> the point is not in the “poorness” of the architecture, but in the fact that such an access method
> is used very rarely for libraries. usually the library is linked
> is dynamic and the system is engaged in “obtaining pointers”. from point
> from the programmer's point of view, in this case there is no need to open anything, addresses
> also does not need to be resolved. it just calls the required function and that’s it. this is it
> is really optimal :)
Is it optimal? Extra relocation links travel with each executor, and if
any, even small ones, or if there is none - then the eheshnik is basically not
will load. Although the programmer could decide along the way that if either is not there, then
and some functions are missing.
Hello Vitamin
Vit> Shaos; alignment; This is good. But not always. I have this
Vit> is optional. More questions
Vit> - only functions are exported or can be exported
Vit> data?
Vit> - is it possible to set links to external ones during compilation
Vit> points unknown at compilation stage?
Vit> -if yes, how is it described by the format
Vit> - how is the relocated lib compiled? (special compiler
Vit> what other “perversions” :)))
Functions only - access data through functions. Each library instance
will have its own data and its own code. No external points. Relocated library
compiled like this - compile from address #0000, then compile from address #0100 and
we compare what happened byte by byte - if the corresponding bytes are in two
compilation results differ, then we write 1 to the corresponding bit, otherwise 0.
A similar trick with relocation works only if addresses are indicated directly
text and are not calculated by tricky formulas. And accordingly it cannot be
no self-modification of the code or corrections to the transition addresses.
Hello, captain cobalt
cap> A lot.
Plus RLE file compression, which will eat all zeros if there were none in the code
transitions. In fact, 1/8 of the code volume is not much at all, considering that
in return we get true relocation in 256-byte increments.
cap> In other words, four registers are not available for passing arguments.
cap> Every call is a potential page scam.
cap> A fairly straightforward implementation of the Amiga approach.
cap> And what about the practicality of the result? ;)
Well, yes - switching the memory page is a pittance of time. And everything works. And bye
no one suggested anything better ;)
P.S. In addition, this lib format is supported in the Forth language compiler and in
C language compiler (both on Sprinter)
Hello, captain cobalt
cap>
elf> cap> there is no axis, which means the linker will have to be added STATICALLY to
elf> each
elf> cap> program
elf> cap>
elf>
elf> This is optional.
elf> The entire axis can be built on a dynamic linker.
elf> Even memory management and parallelism can work on top
elf> dynamic linker.
elf>
elf> OOP allows you to break the system into subsystems by abstraction, not by
elf> functionality.
I didn't understand what you meant :(
1. What does OOP have to do with it?
2. what other option is possible besides adding a linker to each program?
if we don't have an OS?
Hello, yoko_ono
yok> If you really want lib, then you can propose the following mechanism
yok> free from relocation of at least a user program (that is, one
yok> which uses libs and loads them from disk).
yok>
yok> The user program loads the library into a statically defined location in memory. Ta
yok> relocates itself using some method (let the author of the library
yok> is practicing, since he has nothing to do except write). And
yok> for example, at the beginning of the place specified by the user program, builds a table
yok> calls of their functions, consisting of JP func1:JP func2:JP func3, etc.
yok> After which the user program, knowing the beginning of this table (since it is its
yok> indicated), makes CALLs there. You can separate the body itself
yok> libraries from the call table.
By the way, this is roughly how it’s done on Windows when it’s loaded by the system :)
only the program import table and its
filled in by the system based on the list of exported functions or
Hello, yoko_ono
yok> Is it optimal? Extra links travel with every student
yok> relocation, and if there is no relocation, even a small one, then eheshnik
yok> will not be loaded by the axis in principle. Although the programmer could decide on the fly
yok> the thing is that if there is no library, then there are no functions.
at least more flexible :) if either is mandatory, then let the system itself
does everything, if it’s not required, then we use loading via LoadLibrary
and if you really need it, you can almost use your approach: library
exports only one function, then we call it by passing the index of the desired one
"invisible" function
yok> We get a pointer for EVERY function used, of course
yok> no'?
Apparently I didn’t quite understand your original comment, it seemed to me that you
were interested in the need for the entire structure (load, get address, dump,
close). it is really necessary to get the address of each function used.
or use the approach described above (used for example in Mirande)
yok> Well, in my humble opinion, originality is worthless here
meant: original = proposed in the first post of the topic
aci> No, you stubbornly don’t want to hear what they tell you! There are noaci> function pointers! There is only a handle for the library and that’s it! After all, before
aci> call a function, you should know what it does, right? So you know
aci> in which library should I look for it? Then WHY do you need an address or a pointer to
aci> function?
what are you doing again? you are both right:
1. without knowing the address, you cannot call the function directly
2. no one calls her directly to the ammi
Hello Vitamin
Vit> And what prevents you from writing a new compiler?
Historically developed preferences and reluctance to convert everything from one’s own
beloved asma in your new one. This is another inhibitory factor in rapid development
your idea.
Hello Vitamin
Vit> Because if there is no pointer to a function or its addresses (different
Vit> things), then the function cannot be called!
No, you stubbornly don’t want to hear what they tell you! There are no pointers to
features! There is only a handle for the library and that’s it! After all, before you call the function, you
should know what she's doing? So you know where to look for it? Then
then WHY do you need an address or a pointer to a function?
Hello Vitamin
Vit> I already talked about this, you don’t even have to compress it, just into one file
Vit> add everything together so as not to fumble around the disk when assembling.
Take statically linked programs.
Each program can have its own instance of the library.
Compress these programs.
Continuous compression will compress duplicate libraries within programs. :)
ng_> +1
-1
elf> there is no axis, which means the linker will have to be added STATICALLY to each
elf> program
This is not necessary. :)
The entire axis can be built on a dynamic linker.
Even memory management and parallelism can work on top of dynamic
linker.
OOP allows you to break a system into subsystems based on abstractions rather than subsystems.
functionality.
aci> You can use the case as you please! =) No one
aci> prohibits its use - it is not always needed, only when accessing
aci> lible. The rest of the time you can forget about it and use it constantly until
aci> next call. The system is such that you take handle libs into the register
aci> and upon return - he is yours again. Like any other register
aci> necessary for transferring data to lib.aci> I hope I explained it clearly. So this is not a resource-intensive method!
Load a handle into a register - a machine command and resource consumption. :)
Sha> relocation table takes up 1/8 of the code size
A lot.
lib> Library functions are called using the L_CALL subroutine.
lib> This subroutine independently connects the necessary code to the required one
lib> window (the programmer must specify it correctly when loading
lib> libraries so as not to be closed by the opened code page
lib> manager, data, stack), transfers control to the code
lib> of the corresponding library function, and then returns that one
lib> page that was there before the library function was called.
lib> Before the call, the library identifier is set in HL, and in
lib> register B - the library function to be called. Register C
lib> - reserved for the future:
lib>
lib> ld hl,(handle)
lib> ld b,function
lib> call l_call
lib> jp c,error
lib> lib> An error is indicated by a set carry flag. Data can
lib> transmit and receive in registers A,DE,IX,IY, as well as through
lib> second set of registers.
In other words, four registers are not available for passing arguments.
Every challenge is a potential page scam.
A fairly straightforward implementation of the Amiga approach.
What about the practicality of the result? ;)
Hello Vitamin
elf> I didn’t understand what you meant :(
Bad.
You need to understand OOP. I recommend the book
[http://www.intuit.ru/shop/product.xhtml?id=2493373&contents=1].
elf> 1. what does OOP have to do with it?
Let's try to figure it out.
There is "procedural programming" and there is OOP.
What's the difference?
Procedural programming is the explicit use of functionality
procedures. For example, to display a sprite, the address calculation procedure is used
in video memory. At the same time, the programmer knows exactly what to expect from her
there is an implementation of this procedure.
OOP extends this model by allowing functionality to be used implicitly. This
called "polymorphism". When calling a procedure, the programmer no longer relies on
its specific implementation. The implementation may not be unique, and, moreover,
the same call at different times may actually access
different implementations.
Let's look at the example of Windows DLLs.
If a specific library is used, then the most reasonable way is
register it in the import, and it will be implicitly loaded when the program is loaded.
Now let's look at FAR with plugins. FAR obviously loads them explicitly with
LoadLibrary. At the same time, FAR developers do not know what is implemented in the plugin. They
They just hope it's something useful. :) This is an implicit use
functionality.(funny combination: explicit use of functionality - implicit loading
DLL; implicit use - explicit loading)
What does all this have to do with it?
IMHO about five points [http://zx.pk.ru/showpost.php?p=61111&postcount=85]
thoroughly imbued with the spirit of procedural programming. "To be dynamic
linker, you need to have an axis first." This is not true. OOP provides a mechanism
overcoming. FAR can easily use plugins that didn't exist
at the time of writing it.
This idea can be developed further. If we have a basic implicit mechanism
use of functionality (and in assembler this is simply an indirect transfer
controls), then you can (and should) get rid of explicit loading in the LoadLibrary style
manually.
elf> 2. what other option besides adding a linker to each program
elf> is possible if we do not have an OS?
Let us have no axis, no programs, no libraries, there is only dynamic
linker. Now, by slipping modules into this builder, you can build at least
axis, even a program. Anything. :)
Hello, yoko_ono
yok> We get a pointer for EVERY function used, of course
yok> no'?
Laugh. And on the Amiga, by chance, the function index is not looking for a pointer to it
(indirect) for subsequent transition? Because if there is no pointer to
function or its addresses (different things), then the function cannot be called!
yok> Exactly! While compiling a lib from source allows
yok> compile only REALLY required functions, and from
yok> builds lib from Vitamin sources and wants to leave!
Madam! Have you heard about optimization? When from object code (libraries then
yes) are unused functions removed? Of course, this operation is applicable
only when assembling a finished program, and not during runtime assembly, but nevertheless :lol
Yes, by the way, how can you determine whether functions are needed or not at the compilation stage?
taking into account the “programming paradigm on the Spectrum” and without “perversions with macros”?
To be honest, even with perversions I cannot clearly determine this.
yok> Well, in my humble opinion, originality is worthless here - the idea
yok> 'seamless' from PC-Windows-Linux.
Take your shoes off and see that the idea of dynamic linking is the same on
Amiga both on Linux and on Windows (which has been repeatedly shown in this thread)?The only difference is in the technical details of organizing the call.
PS. If the idea had been “seamlessly drawn” from the Amiga, there would probably be boiling water here
wrote...
yok> First of all, his idea implies relocation. Which is being implemented
yok> at the compilation stage in any assembler or code generator and
yok> is supported by the axis on PC/Amiga/etc. On the Spectrum - neither one nor the other
yok> another. Existing assemblers do not support all of them
yok> relocatability (tricks with macros do not count).
And why doesn't it count? And what prevents you from writing a new compiler?
yok> If you really want lib, then you can propose the following mechanism
yok> free from relocation of at least a user program (that is, one
yok> which uses libs and loads them from disk).
A user program can freely be non-relocable, it does not need this. Reading
more carefully.
Shaos; alignment; This is good. But not always. I do this optionally at my place.
More questions
-Are only functions exported or can data be exported?
- is it possible during compilation to set links to external ones that are unknown at the stage
compilation point?
-if yes, how is it described in format?-how is the relocated lib compiled? (special compiler, some others
"perversions" :)))
Hello Vitamin
Vit> Laughing. And on the Amiga, by chance the function index is not a pointer to it
Vit> is searched (indirect) for subsequent transition? Because if not
Vit> pointer to a function or its address (different things), then call the function
Vit> impossible!
Vit>
Mr. Vitamin, in my opinion, you have slipped into absurdity. Something is preventing you from adequately
perceive what is written?
>Madam!
>
Sorry, that's just rude! I'm not your 'madam'! Contact me like this
French sluts!!!
> Have you heard about optimization? When from object code (libraries then
> yes) are unused functions removed? Of course, this operation
> is applicable only when assembling a finished program, and not during runtime assembly,
> but nevertheless :lol
>
Have you heard about this on SPECTRUM?
> Yes, by the way, how to determine whether it is necessary or not needed at the compilation stage
> functions taking into account the “Spectrum programming paradigm” and without
> "perversions with macros"? To be honest, I can’t even with perversions
> define this clearly.>
Not familiar with all the features of alasm? I sympathize...
> And why doesn’t it count? And what prevents you from writing a new compiler?
>
Nothing interferes, but for some reason they don’t write. Think about why.
> a user program can freely be non-relocable, it does not need this.
> Read more carefully.
>
How is it non-relocable if the call addresses of your linked libraries are all
change the same and information about them still needs to be stored?
Hello, captain cobalt
cap> OOP allows you to break the system into subsystems by abstraction, not by
cap> functionality.
cap> Load a handle into a register - a machine command and resource consumption. :)
cap> A lot.
cap>
Well, doesn’t your vaunted OOP imply the use of pointers to
objects in registers and passing these pointers to functions? It's harder to come up with
anything more resource-wasting than OOP in a cross-cross implementation.
> In other words, four registers are not available for passing arguments.
> Every call is a potential page scam.
>
How many registers will YOU use in your OOP? Would you please
give examples?
> A fairly straightforward implementation of the Amiga approach.
> What about the practicality of the result? ;)
Tell me, as a child, didn’t you read zx-reviews and spectrophones at night?
Apparently they were reading...
Hello, captain cobalt
cap> Poor.
cap> You need to understand OOP. I recommend the book
cap> [http://www.intuit.ru/shop/product.xhtml?id=2493373&contents=1].
cap>
Admit it, are you an agent of the PLO sect? How much did you get paid to advertise this?
books?
> Let's try to figure it out.
> There is “procedural programming” and there is OOP.
> What is the difference?
> Procedural programming is an explicit use
> procedure functionality. For example, to display a sprite, is used
> procedure for calculating an address in video memory. At the same time, it is known for certain that
> what to expect from it, the programmer has an implementation of this procedure.
>
> OOP extends this model by allowing for implicit usage
> functionality. This is called "polymorphism". Calling the procedure
> the programmer no longer relies on its specific implementation. Implementation
> may not be unique, and, moreover, the same call in different
> times may actually refer to different implementations.
> What does this have to do with SPECTRUM? Are you able to 1 - give an example
implementation of your 'OOP' on the SPECTRUM and 2 - demonstrate the result obtained with
Is there a benefit in using this 'OOP' in speed or program size?
Hello elf/2
elf> only the import table is used as a list of jmps
elf> program and it is filled in by the system based on the list of exported
elf> functions or
That's right - a separate part of the EXE stores a list of cells into which you need to
substitute the absolute addresses of these functions at the time of casting the EXE into
functional view (when loading), and the creation of such lists is a standard function
PC code generators On the Spectrum, such an operation is non-standard, and to this day
is carried out by macros, introducing many restrictions and significantly
complicating and slowing down the process of compiling a program, therefore it is necessary
get away from such a mechanism.
Shaos's and mine variants are free from any modification of absolute call addresses
library functions in the user program.
Hello, yoko_ono
aci> No, you stubbornly don’t want to hear what they tell you! There are no
aci> function pointers! There is only a handle for the library and that’s it! After all, before
aci> call a function, you should know what it does, right? So you know
aci> in which library should I look for it? Then WHY do you need an address or a pointer to
aci> function?
I'm telling you. When using classically, either the address is obtained
function (one-time) and its call (multiple). It’s happening on the Amiga
calculating the address of a function (multiple!) followed by multiple
challenge.
aci> Historically developed preferences and reluctance to convert everything
aci> from your favorite ASMA to your new one. This is another inhibitory factor
aci> rapid development of your idea.
I agree. It's unfortunate, but I agree. But in this case, all ideas
implementations of relocatable binaries are broken on this fucktor.
Sha> Functions only - access data through functions. Each instance
Sha> libraries will have their own data and code. No external points.
Sha> The relocating lib is compiled like this - compile from address #0000, thenSha> compile from address #0100 and compare byte by byte what happened - if
Sha> the corresponding bytes in the two compilation results are different, then
Sha> write 1 to the corresponding bit, otherwise 0. A similar trick with relocation
Sha> rolls only if addresses are indicated in plain text and not
Sha> are calculated using tricky formulas. And accordingly there cannot be any
Sha> self-modification of the code or with corrections to the transition addresses.
Not enough functionality IMHO. There are very few links to external libraries for
collaboration.
cap> Compress these programs.
cap> Continuous compression will compress duplicate libraries within programs.
No, there shouldn’t be duplicate libraries inside programs! Maximum - duplicates
functions.
yok> Mr. Vitamin, in my opinion, you have slipped into absurdity. Something is bothering you
yok> adequately perceive what is written?
Where did I write the absurd? That to call a function you must have its address or pointer
at her?
yok> Sorry, that's just rude! I'm not your 'madam'!
yok> Address French sluts like this!!!
Oops (lieutenant, keep quiet!!!!)! Feminism in action! Comrade Elena, I forgive youI apologize for showing too much respect for the weaker sex and will continue to try
maintain the required 3 cm distance :lol;
yok>; Have you heard about this on SPECTRUM?
Nunu. Some five years ago on the Spectrum they had not heard of jpeg, nor of RAR, nor of
many more things. Or is what I said completely unrealizable?
yok> Are you not familiar with all the features of alasm? I sympathize...
Source to the studio.
yok> Nothing interferes, but for some reason they don’t write. Think about why.
They write. Does the name SjASM mean anything? If I'm not mistaken, he has macros
everything is fine, just like Alasm. And if the idea goes widely among the masses, you can
encourage the author to provide native support for relocatable code generation.
yok> How is it non-relocable if the call addresses of yours are linked
yok> libraries are still changing and information about them is still needed
yok> store?
What is relocation? Possibility of the program to work in any address. And the links
For functions in libraries, this is a separate matter (in the general case). So
the main module can be nailed to a specific address, the main thing is that it
and loaded under it. Well, and the table of offsets, which contains calls to external
functions are also needed, of course.yok> It's hard to think of anything more resource-wasting than OOP in
yok> implementations of 'c-cross-cross'.
Exclusively for the purpose of improving your level of education. There are implementations
Less resource-wasting OOP? OOP is at the very least IMHO, but a compromise between
functionality and resource intensity.
yok> give an example of implementing your 'OOP' on SPECTRUM
Already mentioned in one of the threads. The first thing that came to mind was calling a virtual
Features:
;iy=this a=func index
add a,a
add a,(iy)
ld l,a
adc a,(iy+1)
subl
ld h,a,a,(hl)
inc hl
ld h,(hl)
ld l,a
jp(hl)
It's hard, no doubt about it. I used IY to store this so that I could easily
reach class members. For comparison, calling by index a la Amiga:
;a- func index hl-libr addr
add a,a
add a,a
add a,l
ld l,a
adc a,h
subl
ld h,a
jp(hl)
I proceeded from the assumption that the jump table occupies 4 bytes per point. If
not 4, but 3 (regular jp addr), then the challenge will be even greater.
You can optimize it slightly if you locate the library from an address that is a multiple of 256.
Is there a very significant difference?
yok> Shaos' and mine variants are free from any modification of the absolute ones
yok> addresses of library function calls in the user program.
I saw the Shaos version. Where is yours, comrade? ;)What else is he free from? From the possibility of late linking of modules between
by yourself?
PS. But my option allows you to implement a point kernel without any problems
login if you want. Or it can work without it. What can't be said about
proposed. But in the assembled program this kernal is a waste of time and
memory.
Hello Vitamin
Vit> In making this assumption, I was based on the fact that libman
Vit> ported (a softer term than “ripped off”, right? ;)) from Amiga s
Vit> with the same ideas. Namely, a kernel with transitions to functions:
Vit> jp func1
Vit> jp func2
Vit> jp func3
Vit> ...
Vit>
Vit> And the call is carried out as follows:
Vit> ld hl,(handle)
Vit> ld b,function
Vit> call l_call
Vit> jp c,error
Vit>
Vit> and tell me what happens inside the l_call function? More likely
Vit> that's all, the code that I wrote, namely the calculation of the address and the transition
Vit> on it....
When I wrote libman, I didn’t even see the Amiga, so I couldn’t “rip it off” :)
Hello Vitamin
Vit> On the Amiga, the function address is calculated (multiple!)
Vit> along with subsequent multiple calls.
Vit>
You're kidding, right? Tell me are you kidding? No, well, you don’t understand anything, do you? What
calculation (especially multiple times?) - motivate (apparently you code for ammi every
day?)
Hello Vitamin
Vit> The first thing that came to mind was calling a virtual function:
Vit>
Vit> ;iy=this a=func index
Vit> add a,a
Vit> add a,(iy)
Vit> ld l,a
Vit> adc a,(iy+1)
Vit> sub l
Vit> ld h,a,a,(hl)
Vit> inc hl
Vit> ld h,(hl)
Vit> ld l,a
Vit> jp (hl)
Usually func index for each specific call point is a constant.
You can do constant propagation. We get:
┌─- code ───
LD L,(IY+D)
LD H,(IY+D+1)
JP(HL)
└── code ───
This piece of code can be inlined. You can add PUSH HL before this, and in
the beginning of each POP HL virtual function. Accordingly, HL will become available
to pass arguments to a virtual function. :)
Hello Vitamin
yok> Doesn’t your vaunted OOP imply the use
yok> pointers to objects in registers and passing these pointers
yok> functions?
Yes.
Every time the data does not fit into the registers, use transmission via
memory. In OOP, data is stored in objects and pointers to objects are passed. B
what's the problem? What's worse about pointer passing in "regular programming"?
yok> And how many registers will YOU use in your OOP? Not
yok> would you please give examples?
This is the wrong question.
Libman (and the Amiga libraries) do not pretend to be OOP. And the registers are already like splinters
flying. It would be better to wonder what will happen if you try to implement
OOP on top of it.
yok> Tell me, as a child, didn’t you read “zh-review” and “spectrophones”
yok> for the night? Apparently, they were reading...
Do you have any complaints against them?
yok> Admit it, are you an agent of the PLO sect?
Yes, but what's the problem? :)
When the complexity of a software system reaches the point where
temptation to take advantage of the implicit use of functionality, it is necessary
Good command of OO analysis. Otherwise it will easily turn out to be a bloody mess.yok> How much did you get paid to advertise this book?
Not at all.
yok> Are you able to 1 - give an example of the implementation of your 'OOP' in
yok> SPECTRUM
1. Block drivers for iS-DOS (and other OS).
2. Extended memory drivers in ALASM (and much more).
3. GUI in BGE.
All these examples are rightly considered the pearls of Speccy programming.
yok> demonstrate the gain obtained by applying this 'OOP'
yok> speed or size of the program?
The main benefit of OOP is flexibility.
Useful functionality often comes from flexibility. Useful
functionality is what is presented to the end user.
This is where the scope of applicability of OOP should be taken.
Speed and size can degrade in inverse proportion to
programmer skill. Especially the level of proficiency in OOP. :)
Hello Vitamin
Let's try to formulate theses based on the results of the topic:
1. The approach of the Amiga libraries is OOP brakes without the advantages of OOP.
2. For Speccy, the best approach is to patch the CALL client.
3. Indirect transitions should be used for polymorphism.
Hello Shaos
Sha> When I wrote Libman, I didn’t even see the Amiga, so “rip it off”
Sha> could not
I'm not saying that on purpose. And I don’t see anything wrong with the transfer at all
good ideas from/to spec.
I am based on the words of comrade yoko_ono and acidrain, who say that it is “as in
Amiga".
Hello, acidrain
aci> You're kidding, right? Tell me are you kidding? No, well, you don’t understand anything, do you?
aci> What kind of calculation (especially multiple?) - motivate (apparently you code
aci> for ammi every day?)
In making this assumption, I was based on the fact that libman is ported
(a softer term than “ripped off”, right? ;)) from Amiga with the same ideas. A
namely, a kernel with transitions to functions:
jp func1
jp func2
jp func3
And the call is carried out as follows:
ld hl,(handle)
ld b,function
call l_call
jpc,error
and tell me what happens inside the l_call function? Most likely the code
what I wrote, namely calculating the address and moving to it....
Hello, captain cobalt
cap> When the complexity of a software system reaches the point where
cap> there is a temptation to use implicit usage
cap> functionality, you must be proficient in OO analysis. Otherwise
cap> it will easily turn out to be a bloody mess.
Uh-huh. Even if the implementation of OOP in C++ is not a fountain (some things are missing and there are
redundancy), but this is the de facto standard. And in procedural programming for
Simulating polymorphism use arrays of function pointers. Explicitly, not
by the compiler.
cap> 3. GUI in BGE.
I don’t know about other examples, but this one can be an example of the implementation of polymorphism
attributed with the same probability as ALL plugins for other programs, and
also...compiled music modules! %)
cap> Usually func index for each specific call point is a constant.
cap> You can perform constant propagation.
Hm. I didn’t even think about this matter, I was guided by the assembler and the covering
functionality. In the case of propagation of constants, of course everything works out
very, very elegant and beautiful. Respect!
Hello, captain cobalt
cap> You need to understand OOP. I recommend the book.
Apparently we read different books...
cap> Procedural programming is an explicit use
cap> procedure functionality. For example, to display a sprite, is used
cap> procedure for calculating an address in video memory. At the same time, it is known for certain that
cap> what to expect from it, the programmer has an implementation of this procedure.
cap>
cap> Now let's look at FAR with plugins. FAR obviously loads them explicitly
cap> using LoadLibrary. At the same time, FAR developers do not know that
cap> is implemented in the plugin. They just hope it's something useful. This
cap> implicit use of functionality.
cap>
cap> (funny combination: explicit use of functionality - implicit
cap> loading DLL; implicit use - explicit loading)
in my books OOP=inheritance+encapsulation+polymorphism. and accordingly
"implicit" calling is only possible for explicit children. in the case of headlight this is not even
smells.
far detects and uses plugins based on a list of functions, it is not OOP.this is closest to duck typing, which is actively used in newfangled languages
(python, ruby)
then:
#include "stdio.h"
printf(...)
also OOP :) such a program could have been written many years ago, but it works until
still with new versions of libc. and over the years of existence of the libc program could
change a lot including new functionality
cap> IMHO the five points are thoroughly imbued with the spirit of the procedural
cap> programming. "For there to be a dynamic linker, you need to
cap> first there was an axis." This is wrong. OOP provides a coping mechanism. FAR
cap> can easily use plugins that did not exist at the time
cap> his spelling.
five points are not impregnated with anything :) I described those problems that are dynamic
Loading libraries is currently available for the spec. let alone what for
dynamic linking definitely needs an axis, I definitely didn’t say :) if you
say that OOP allows you to bypass these limitations/problems, then I
I'll be happy to hear how
cap> Let us have no axis, no programs, no libraries, we only have
cap> dynamic linker. Now, slipping this linker
cap> modules, you can build either an axis or a program. Anything.But the explanation about the “spherical compositor in a vacuum” is not an explanation.
This is demagoguery in my opinion. because:
1. who will download the linker?
2. who will tell him what needs to be loaded?
Hello, captain cobalt
I really want to ban books about OOP :(
cap> 1. The approach of the Amiga libraries is OOP brakes without the advantages of OOP.
where is OOP in the Amiga approach? where is inheritance and encapsulation? what are they like
brakes?
cap> 3. Indirect transitions should be used for polymorphism.
What the fuck is polymorphism on Speck? calling a function on a table is not
polymorphism
guys, let's not throw around terms! especially if they don't
unambiguous and everyone understands them in their own way. and if we scold something, then at least
with arguments
Hello, yoko_ono
yok> That's it - a separate part of the EXE stores a list of cells in which
yok> you need to substitute the absolute addresses of these functions at the time of casting
yok> EXE into a workable form (when loading), and creating such lists -
yok> standard function of PC code generators.
yok> ...
yok> Shaos' and mine variants are free from any modification of the absolute ones
yok> addresses of library function calls in the user program.
Please re-read my original message. EXE is not patched and by the way
too.
1. in the header of the exe file there is a list of jmps
2. all calls go to them
3. when the system loads the exe+dll, it corrects the addresses in these JMPs. none
the byte inside the program does not change!
If I'm not explaining it well, then look at MSDN, it's different from the Amiga docs
be in the public domain.
Moreover, if the dll is without base relocation (i.e. loaded according to fixed
addresses) then inside the exe all calls go directly to the library without additional
jmp'a. and all this is done automatically by the linker when assembling the program, by hand
you don't need to do anything
Hello, captain cobalt
cap> In terms of functionality, the OS is already obtained, although it would seem
cap> dynamic linker...
that's what I mean :) either the linker is part of the "axis", or it is statically linked with
program
but we should stop talking about OOP in this thread, imho. There is no language with explicit support yet
at least...
and in general it is not correct to compare OOP with libraries. because they lie on
completely different levels.
one problem in this thread: everything is too emotional, and it should be two or three more
divide
1. static linking from objects (Vitamin suggested): how to do this on
specky optimal
2. dynamic linking: outline and compare existing approaches
(ammi/libman/Win/Lin/etc.) and as a result select/synthesize what for
specka is better suited
3. OOP and others like it (it’s better to go straight to flame)
Hello elf/2
Guys, is it really worth it?
Let's look at the advantages again:
1) space saving. But who cares about it among the emulators (and they are the majority)? Yes
and real-life people try to cut off a screw or flash drive.
2) correcting an error in the library eliminates it in all dependent programs.
But as was rightly noted, (2) simultaneously leads to much greater
The problem is that in Windows it was called DLL-hell. Okay, correct the mistake there, huh
what to do when, as a result of evolution, a stage comes when change is required
function interface? Spectrum resources are too modest to solve such problems.
tasks where even with the older brothers everything is still not going smoothly.
And one more thing. In the Spectrum environment, during all this time, the practice has somehow not developed
use of shared libraries, do you think when the community became much less
numerous still have a chance?
The problems of shared libraries are partially solved with the advent of a normal OS. After all
then I/O will already be supported by the kernel, and this is the main thing where they can
common pieces are present. The second is UI-core - but it's almost always every
prefers to do things his own way.
IMHO, a flexible tool for connecting libraries during linking would be more
appropriate By the way, this happened in CP/M. Including there it was possible to connect from
libraries to the module directly a specific function, and not the entire library.
Hello Vitamin
Vit> If people want to support the idea, then I am waiting for proposals for expansion
Vit> functionality
Here are the proposals:
1. The dynamic linker and libraries should remain in memory as much as possible
longer without unnecessary re-downloads from disk. Then the axis will be able to “grow”.
2. Integrity control is needed. For example, based on a string with the enumeration
arguments. If the imported and exported interface do not match,
I need an error message.
3. We need uniform tool support for static and
dynamic layout. So that from the same sources it is possible
compose both dynamically and statically.
4. We need to make a list of libraries that humanity needs. With description
what they should do.
Hello Vitamin
elf> EXE is not patched and neither is lib.
Here it is necessary to clarify that on x86 the direct CALL and JMP commands are relative.
Regarding the program counter. If the code uses only such
transitions, then we move it without patching.
Hello Vitamin
elf> in my books OOP=inheritance+encapsulation+polymorphism.
That's right. But this is just the definition of OOP. If you use only
By definition, nothing good will come of it.
If you read the definition of poetry, then immediately after that they will not immediately
make good poems. :)
If we take from mathematical analysis the definition of the limit of a function at a point, then we can even calculate
one limit is quite difficult. Fortunately, there are much more for this
handy tools, such as "L'Hopital's Rule", "Cauchy's Theorem" and also a carriage
all sorts of different ones that do not directly follow from the definition of the limit.
How to write OOP programs correctly. There is no answer to this question in books like
"OOP=inheritance+encapsulation+polymorphism." It's like teaching
the art of poetry according to the principle: “poetry is <...here is the definition of poetry...>;
Here, for example, is Pushkin: <...here are Pushkin's poems...>".
How do you still design OOP programs? This is discussed completely in
other books. And this is discussed without falling into definitions.
elf> accordingly, an “implicit” call is possible only for explicit descendants. in
elf> in case the headlight doesn't even smell like this
OOP is the implicit use of functionality.
Implicit use of functionality is not always OOP. But it can alwaysbe expressed in OOP. And if it can, then, according to members of the “PLO sect,” it should
be expressed that way. :)
How to express plugins in OOP? Very simple: all plugins must inherit from
one abstract plugin class.
elf> five points are not saturated with anything :)
elf>
elf> if you say that OOP allows you to bypass these limitations/problems
elf> then I'll be happy to listen to how
It's very simple: clients of the base class can be dynamically linked with
implementations of derived classes.
elf> that's just the explanation about the "spherical builder in vacuum" this is not
elf> explanation. This is demagoguery in my opinion. because:
elf> 1. who will load the linker?
It doesn't matter.
It can be booted from boot.B and can be flashed into ROM. A lot of things are possible.
But once the dynamic linker is loaded into memory, it can sit there
for as long as you like. :) And dynamically compose as many as you like. :)
elf> 2. who will tell him what needs to be loaded?
And it’s not his business to load anything. :) His job is to put together what he is given.
:) Where the stuff that he is given to compose was downloaded from is also none of his business. :)
Who will load what needs to be assembled? It can load, for example, #3D13,which is always available.
But who will tell #3D13 that it needs to be loaded? Well. I'll have to write
a small program that will do this. With user interface.
And call it "file manager". :) Moreover, since there is a dynamic
linker, then you can link with the (yourself loaded) driver
HDD, and then load modules from the HDD.
In terms of functionality, the OS already turns out, although it would seem dynamic
linker... ;)
Hello Vitamin
elf> where is OOP in the Amiga approach? where is inheritance and encapsulation? which
elf> such brakes?
This is not OOP. These are just OOP brakes. No inheritance or encapsulation.
Brakes on loading the handle into the register, indirect transfer of control, and
inaccessibility of the register for passing arguments.
The same brakes as calling a virtual function.
But if polymorphism is the power of wow :), then the Amiga has “just libraries”. :)
elf> calling a function on a table is not polymorphism
But polymorphism is (often and among other things) calling a function on a table.
elf> guys, let's not throw around terms! especially if they don't
elf> are unambiguous and everyone understands them in their own way. and if we scold
elf> something, then at least with arguments
Okay. Always ready. ;)
Hello, captain cobalt
This is roughly what I've been waiting for for 13 pages now %))
cap> 1. The dynamic linker and libraries must remain in memory
cap> for as long as possible without unnecessary repeated downloads from disk. Then the axis
cap> will be able to “grow”.
I have not yet looked into such distant jungles as dynamic layout. I have
(in meaning) static-dynamic: dynamic in the sense that everything is loaded
at startup, but static in the sense that everything is configured behind the scenes and the program
does not know that it was assembled from pieces.
cap> 2. Integrity control is needed. For example, based on the string with
cap> by listing the arguments. If imported and exported
cap> interfaces do not match, an error message is needed.
Well, the simplest control goes without saying - if there are any left in the assembled program
If some external links are not resolved, it is considered invalid. As well as
if there are two or more points with the same name (for universality -
signature). Plus, of course, version control
cap> 3. We need uniform tool support for static and
cap> dynamic linking. So that from the same sources you cancap> was composed both dynamically and statically.
These are already subtleties, their implementation is carried out automatically with the correct
choosing the functionality and mechanism for implementing relocation and interfaces.
cap> 4. We need to make a list of libraries that humanity needs. S
cap> a description of what they should do.
Well, the simplest ones are mathematics, graphics, disk operations. And in the future - every
can write his own and post them.
Hello elf/2
elf> where is OOP in the Amiga approach? where is inheritance and encapsulation? which
elf> such brakes?
This means that OOP is slow, but there are also advantages, and the Amiga approach is
brakes (as in OOP), but there are no advantages that outweigh the brakes.
elf> I just want to ban books about OOP
No need %) OOP is good (if used correctly, of course).
If we talk about polymorphism as applied to plugins, then they do it the way I do
told earlier - one single function of the class factory is exported,
which instantiates the descendants of the interface class. But when called it’s already clean
polymorphism results.
Let's return to the topic of conversation. Why did you start everything? I have my one
library of modules. I plan to use it in some of my projects. At the same time
time, it’s not harmful to dream (see first post). If people want to support the idea,
then I'm waiting for proposals to expand the functionality (change globally there
it doesn’t seem like anything is needed). And if you don’t need it, then don’t... I’ll do it exclusively
for yourself, for your own purposes
Hello, captain cobalt
cap> For example, in the dotnet, assemblies are controlled by version number.
cap> The spec offers control of signatures by hashes
cap> There is a proposal to combine this with an auto-documentation system
cap> source. Object code is compiled separately from the source
cap> separately - documentation.
cap> Verification hashes are generated from key pieces of documentation.
Vit> Store inside the library file. If you don't have enough space for a line like
Vit> memcpy[signature in crazy format], then you can do hashing in
Vit> 3-4 bytes and don’t worry. Of course, the linker must take this into account
I don’t even want to comment :( if this is all about dynamic libraries.
1. generation/verification of signatures should be done automatically. on asma types
no, and the parameters are transferred as God pleases. it means the machine gun is walking through the forest
2. who saw the normally commented code on the spec?
3. checking will consume a lot of time... and you just flattened the Amizhniks
about "brakes similar to OOP"
Hello, captain cobalt
cap> Correction. They didn't. Now that DLL hell has finished the channel, they came up with
cap> new miracles of technology.
I heard that dll hell was due to incompatibility of library versions... but anyway
no less miracles of technology in the studio. How can we deal with this now? no longer indulged
Is it possible to do reflection on the Speck?
cap>
elf> and especially where to get signatures in the case of assembler?
elf>
elf> Register manually.
ftopku! There will be too many errors and the main thing is not clear how to check them later.
also with your hands :) ?
Hello, captain cobalt
cap> A signature is good and mandatory.
What kind of signature checking is used for dynamic linking? this even in Windows,
where there are a lot of resources, they don’t do it. and even more so where to get signatures in case
assembler?
Hello Vitamin
Vit> saying that it is “like in Amiga”.
I didn’t say that libman is like in Amiga. This is completely the creation of Shaos.
How he implemented it - he did not go into detail. But at the beginning (the first impetus for creation)
I took part. But this does not mean that it is a copy of the Amiga.
Regarding transitions - there are no calculations on the Amiga, guess why 8)
Hello Vitamin
Vit> I have not yet looked into such distant jungle as dynamic
Vit> layout. I have (in meaning) static-dynamic: dynamic
Vit> in the sense that everything is loaded at startup, and static in the sense that
Vit> everything is configured behind the scenes and the program does not know that it was assembled
Vit> from pieces.
As just shown, loading and linking are two different things.
Assembly at load time is dynamic linking.
Keeping libraries in memory is most useful for development.
Currently, include is used for assembly. In single-text assemblers, for each
During assembly there is a crawling motion on the disk. In multi-text, when everything is in memory, everything
There are also brakes with compilation. If everything lies in memory ready for
use, you only need to link one developed one when compiling
module.
Vit> Well, the simplest control goes without saying - if in the assembled program
Vit> some external links remained unresolved, it is considered
Vit> is invalid. The same as if there are two or more points with the same
Vit> name (for universality, signature).
Here.
A signature is good and mandatory.Vit> These are subtleties, their implementation is carried out automatically when
Vit> correct choice of functionality and mechanism for implementing relocation and
Vit> interfaces.
The problem is this.
There is the "good old static" assembly via include. There's a "new cool"
dynamic". :)
The programmer is watching. If the tools are different, you need to choose what
use. The old method already has its own proven code. For new
the method must be rewritten, redone almost from scratch. Many won't be able to
understand your own old assembler sources. :)
If gradual migration is possible, then more programmers will develop
universal code. It will be used with static linking at first,
but will accumulate a base for dynamic linking.
Vit> Well, the simplest things are mathematics, graphics, disk operations. A
Vit> in the future, everyone can write their own and post them.
We need a more precise list.
In previous versions of this topic, specific proposals were made. We need them
collect everything, organize it, deepen it, broaden it. Publish. Then the programmers
They will scrape through their reserves.
elf> and in general it is not correct to compare OOP with libraries. because lie
elf> they are at completely different levels.Are there “class libraries”? :)
Hello Vitamin
elf> generation/verification of signatures should be done automatically.
Yes.
elf> who saw the normally commented code on the spec?
It is impossible to use someone else's code without documentation.
Reusable code must be documented.
elf> parameters are passed as God wishes
Passing parameters is described in the documentation. From these pieces of documentation
verification hashes are generated.
elf> checking will consume a lot of time...
For each exported-imported character, compare two numbers.
No runtime overhead.
elf> means the machine gun is walking through the forest
This means the machine gun does not go through the forest.
elf> there are no types on asma
Bad.
There are two main options:
1. Look at the OOP on the PC (in TASM, etc.).
2. Use typed assembly language, abbreviated as
TAL. The idea can basically be screwed onto the Z80. But this is just very distant
a future that we will talk about much later. Links here
[http://www.wasm.ru/forum/viewtopic.php?id=8338].
Hello Vitamin
elf> generation/verification of signatures should be done automatically.
Yes.
elf> who saw the normally commented code on the spec?
It is impossible to use someone else's code without documentation.
Reusable code must be[b] documented.
elf> parameters are passed as God wishes
Passing parameters is described in the documentation. From these pieces of documentation
verification hashes are generated.
elf> means the machine gun is walking through the forest
This means the machine gun does not go through the forest.
elf> checking will consume a lot of time...
For each exported-imported character, compare two numbers.
No runtime overhead.
elf> there are no types on asma
Bad.
There are two main options:
1. Look at the OOP on the PC (in TASM, etc.).
2. Use [b]typed assembly language, "typed assembler",
Abbreviated as TAL. The idea can basically be screwed onto the Z80. But this is just strong
the distant future, which we will talk about much later. Links here
[http://www.wasm.ru/forum/viewtopic.php?id=8338].
Hello Vitamin
elf> some kind of signature check during dynamic linking? this even in
elf> they don’t do it on Windows, where there are a lot of resources.
Correction.
They didn't.
Now that DLL hell has finished the channel, new technological miracles have been invented.
elf> and especially where to get signatures in the case of assembler?
Register manually.
Hello Vitamin
elf> I heard that dll hell was due to version incompatibility
elf> libraries... but none the less miracles of technology in the studio. how now with
elf> fight this? Isn’t it possible to do reflection on the spec?
For example, in Dotnet, assemblies are controlled by version number.
The spec offers control of signatures by hashes.
elf> ftopka! there will be too many errors and most importantly it is not clear how to make them later
elf> check. also with your hands :) ?
There is a proposal to combine this with a system for auto-documenting the source code.
The object code is compiled separately from the source, and the documentation separately.
Verification hashes are generated from key pieces of documentation.
The idea is that with incorrect documentation it is impossible to write the correct one.
client code. :)
Then the rule works: “if the documentation on which the programmer wrote
client code does not match current documentation - linking is not
is happening." :)
Vit> These are intimate compiler problems. Will be cached - will be in
Vit> memory, will not cache - will crawl around the disk.
Well, it’s better if they sit next to each other. Sit and not
move from place. The new code will be placed in free memory and
align with them.
Hello Vitamin
max> But as was correctly noted, (2) at the same time leads to much
max> The bigger problem is that in Windows it was called DLL-hell. Okay there
max> correct the error, but what to do when it occurs as a result of evolution
max> stage when a function interface change is required? Spectrum resources
max> are very modest to solve such problems, where even the elders
max> brothers, everything is still not going smoothly.
That is why we need to control the interface not just by name, but by signature.
You can ignore the advances of the older brothers specifically from Microsoft.
:)
max> And one more thing. In the Spectrum environment, during all this time, the practice somehow did not work out
max> use of shared libraries, think when the community has become much
max> are there still chances for the less numerous?
max>
max> The problems of shared libraries are partially solved with the advent of normal
max> AXES. After all, then I/O will already be supported by the kernel, and this is the main thing
max> where common pieces may be present. The second is UI-core - but it’s almost there
max> everyone always prefers to do things their own way.This is the next question.
We need more than just libraries. We need a framework. A kind of frame with cells, in
which you can insert your code.
Programming becomes much more comfortable.
But here, now, someone is about to go hysterical again.
Hello elf/2
elf> I heard that dll hell was due to version incompatibility
elf> libraries... but none the less miracles of technology in the studio. how now with
elf> are we fighting this?
Here's a more detailed summary: ;)
> History of software revolutions from Microsoft, in brief: First there were
> Windows API and DLL Hell. The N1 revolution was DDE. Remember how links
> allowed us to create status lines reflecting the current price
> Microsoft shares? Around the same time, Microsoft created the VERSION resource
> INFO excluding DLL Hell. But another group at Microsoft found it in DDE
> fatal flaw They didn’t write it!
>
> To solve this problem they created OLE (similar to DDE, but
> other), and I naively remember the speaker at Microsoft
> conference saying that the Windows API will soon be rewritten as OLE API
> and every element on the screen will be an OCX. Interfaces appeared in OLE
> exclusive DLL Hell. Remember the disease called "locally", when
> which we dreamed of embedding all our applications into one (possibly> very large) Word document? Somewhere around the same time Microsoft
> I believed in the C++ religion, MFC arose, which solved all our problems yet
> times.
>
> But OLE wasn’t going to sit back and watch this, so it’s done again
> was born under the name COM, and we suddenly realized that OLE (or it was
> DDE?) will always be H and even includes a carefully designed system
> component versions, excluding DLL Hell. At this time the group
> renegades inside Microsoft discovered a fatal flaw in MFC
> they didn’t write it! They immediately corrected this defect by creating ATL.
> which is like MFC, but different, and they tried to hide all the wonderful
> things that the COM group tried so hard to teach us. This
> caused the COM (or was it OLE?) group to be renamed to ActiveX and
> release about a ton of new interfaces (including control interfaces
> versions excluding DLL Hell), and at the same time the ability to make all the code
> loaded through browsers, directly along with the ones defined> user with viruses (to spite those bastards from ATL!).
>
> A group of operating systems scream loudly like a forgotten middle one
> child, demanded attention, saying that we should prepare for
> Cairo, some mysterious crap that could never even
> to really describe, not to release. To their credit, it should be said
> that they did not introduce the concept of "System File Protection",
> exclusive DLL Hell. But then a certain group at Microsoft found a fatal one
> flaw in Java They didn’t write it! This was fixed by creation
> either J, or Jole, or maybe ActiveJ (to be honest, I just don’t
> I remember), exactly the same as Java, but different. It was cool, but Sun
> sued Microsoft under some decrepit law. It was obvious
> an attempt to strangle Microsoft's right to release the same products as theirs
> others, but others.
>
> Remember the J/Jole/ActiveJ manager banging his shoes on the table and
> saying that Microsoft will never abandon this product? Fool! All> this meant only one thing: lack of attention to the ActiveX group (or
> was it COM?). This incredibly cheerful crowd is back with COM+ and
> MTS is at its best (maybe it should have been called ActiveX+?). It’s unclear why
> they didn’t put “COM” or “Active” or “X” or “+” on MTS
> simply shocked by this! They also threatened to add + to all fashionable
> then expressions. Around the same time, some people started yelling about "Windows
> DNA" (why not DINA) and "Windows Washboard", and screamed for a while,
> but all this died down before everyone realized what it was.
>
> At this point, Microsoft has been growing alarmed for several years
> watched the Internet. They recently came to understand that the Internet
> has a fatal flaw: well, you get the idea. And this brings us to
> current moment and .NET technology (pronounced "doughnut
> (donut in our opinion)", but in a different way), similar to the Internet, but with
> a large number of press releases. The main thing is that you need to be very clear
> understand that .NET excludes DLL Hell.>
> .NET includes a new language, C#, (it turns out that Active++ Jspresso
> was a fatal flaw from which he died). .NET includes
> a virtual machine that will be used by all languages (apparently
> due to fatal flaws in Intel processors). .NET includes
> a unified protection system (there is still a fatal flaw in storage
> passwords not on Microsoft servers). It's really easier to list things
> which .NET does not include. .NET is sure to revolutionize
> Windows programming... for about a year.
Hello, acidrain
aci> Regarding transitions - there are no calculations on the Amiga, guess why
aci> 8)
So what? From my awareness of the fact that they are not made on the Amiga
calculations, they will not disappear on the Spectrum. So look at everything possible
options for creating relocatable binaries through the prism of possibilities
Spectrum.
PS. Did you receive the documents?
elf> 1. generation/verification of signatures should be done automatically. on asma
elf> there are no types, and parameters are passed as God pleases. means
elf> the machine gun is walking through the forest
Where should the compiler get the input data to generate the signature? From
astral or what? :) Write it down by hand. And there are types on ASMA, it’s a shame to say that
no! %) And passing parameters (allocating registers) is perfectly possible
describe in signature. In this regard, there is no need to pull megabytes
documentation with a description of which registers the parameters should be inserted into and constantly
poke around in it.
PS. The idea of generating a hash according to the documentation doesn’t include a comma
rearrange it in the description and that's it, new version?
elf> 3. checking will consume a lot of time... and you just flattened
elf> Amizhniks regarding "brakes similar to OOP"Hash verification is quite fast. And about the brakes - if only the Amiga system
provided the same wide range of opportunities, then there would be no conversation.
They just used it and that's it.
By the way, I was thinking about using polymorphism to reduce size
binaries.
Let's say we have an abstract GUI library with a bunch of different types of widgets.
How is this usually done? Some structure in memory that has a numeric
ID. And somewhere in the output function (creation, deletion, etc.) it hangs
This is such a healthy branching with a bunch of checks and a bunch of transitions to different functions.
What do we end up with? That we will have to pull the entire library, even if we
We use only one or two types of widget. If the library is distributed as
source codes, you can use keys to enable/disable some
opportunities (I did this myself). In binary, this obviously won’t work.
But if we have polymorphism, we completely separate the implementation from the type and
We have the possibility of unlimited expansion through inheritance. At the same time, from
binary, it will be possible to cut out unnecessary (that is, unused) code. True
checking for usability turns out to be very, very resource-intensive - they ruin everything
tables of virtual functions, which in theory are already stitched in the binary, but obviously
they don't light up anywhere...
Hello, maximk
max> The problems of shared libraries are partially solved with the advent of normal
max> AXES. After all, then I/O will already be supported by the kernel, and this is the main thing
max> where common pieces may be present. The second is UI-core - but it’s almost there
max> everyone always prefers to do things their own way.
Why does he prefer? Because “whom I want, I don’t know, who I know, I don’t want.” I
I also wrote my UI based on SupremeGUI from DT. If only it were open (at that time
time) - I would use it and that’s it... And if there is a choice, there will be use.
max> IMHO, there was a flexible tool for connecting libraries during linking
max> would be more appropriate. By the way, this happened in CP/M. Including there you can
max> was to directly connect a specific function from the library to the module, and
max> not the entire library.
I have one idea about this - to cut out only the necessary functions. But
this requires resources and can only be applied during final assembly
binary (not runtime).
Can you tell us more about CP/M (more precisely, implementation)?
cap> Keeping libraries in memory is most useful for development.
These are already intimate compiler problems. Will be cached - will be in memory, not
If it caches, it will crawl around the disk.elf> some kind of signature check during dynamic linking? this even in
elf> they don’t do it on Windows, where there are a lot of resources. and even more so where do the signatures come from
elf> take in case of assembler?
Store inside a library file. If you don't have enough space for a line like
memcpy [signature in crazy format], then you can do hashing in 3-4 bytes and
don't suffer. Of course, the linker must take this into account
Hello Vitamin
Vit> And passing parameters (allocating registers) is perfectly possible
Vit> describe in the signature. In this regard, there is no need to pull
Vit> megabyte of documentation with a description of which registers should be inserted
Vit> parameters and constantly rummage through it.
signature checking works normally only at the compilation stage.
in dynamics we only have two names and that’s it. in this case I don't see what the name is
memcpy functions are worse than memcpy_VI#43543 (written by hand) from the point of view
security and lack of dll hell. and most importantly, no one can check what
we call her correctly just by comparing names.
and normal signature checking i.e. parsing and comparison is not yet clear with what
It will definitely eat up a lot of time.
Hello Vitamin
Vit> Why attach documentation here at all? Not in the life of a library
Vit> did not differ in the description version.
The signature is part of the documentation.
You will still need documentation.
Therefore - so as not to produce entities.
> What???? Just at the linking stage. To know what and with what
> glue.
In fact, in high-level languages it actually works during
compilation. Checks that the correct number of arguments is passed
the right types.
And in assembler. If we forgot to load an argument into the register, and the register is garbage
from previous use - the compiler will not say anything. :(
Hello Vitamin
Vit> The idea of generating a hash from the documentation doesn’t include a comma
Vit> rearrange it in the description and that's it, new version?
Not for all the documentation, but only for the “key pieces”.
The signature is still an integral part of the documentation.
You just need to mark it in a certain way so that the hash is calculated only from it.
Vit> By the way, I was thinking about using polymorphism to reduce
Vit> binary size.
Vit> Let's say we have an abstract GUI library with a bunch of different types
Vit> widgets.
You can place each widget in its own module.
Then only those modules that are used can be registered in the import. :)
Hello Vitamin
elf> in this case I don’t see why the function name memcpy is worse than memcpy_VI#43543
memcpy is the name. VI#43543 is the same verification magic number. It
remains "behind the scenes". Only memcpy is used in the client code. VI#43543
it is simply copied into the client module with the object code at compile time. In
During dynamic linking, they are simply checked for equality.
It is assumed that the author of memcpy changed the interface (or introduced another
incompatibility) will change the signature. Incompatible modules will not be
compose. If the author forgets to change the signature, he will remember when he
something will break. If nothing breaks, someone will tell him,
who will break? If the author neglected the spec, the problem may be published.
The idea is to make incompatibilities easier to detect.
Instead of “incomprehensible devilry” accumulating until
Received the title of "mast day glitch." :)
Hello, captain cobalt
cap> The signature is still an integral part of the documentation.
cap> You just need to mark it in a certain way for the hash to be counted
cap> only from her.
Why put documentation here at all? Never in my life have a library
differed in the version of the description.
cap> You can place each widget in its own module.
cap> Then in the import you can only register those modules that
cap> are used.
That's right, and the main shell manager will be absolutely
monopenisual what to draw and how to question.
elf> signature checking works normally only at the compilation stage.
What???? Just at the linking stage. To know what to glue and with what.
elf> in the dynamics we have only two names and that’s it. in this case I don't see
elf> than the function name memcpy is worse than memcpy_VI#43543 (written by hand) with
elf> from the point of view of security and the absence of dll hell. and most importantly no one
elf> will no longer be able to verify that we are calling it correctly simply by comparing
elf> names.
From the linker's point of view, all these names are equivalent. But for greater unificationit is very, very desirable to encode the input parameters in the signature and
return type. Let's kill several birds with one stone - we can freely have
overloadable functions, eliminating the need to constantly look at the documentation
in order to remember in which registers the parameters are transferred and get the start for
using a Java language (and compilers encode function names this way)
Hello,GriV
2Vitamin> what things are already (currently) related in one way or another
2Vitamin> modular organization (full list, including documentation). What
2Vitamin> is it necessary for this to become “more alive than dead”?
Hello, captain cobalt
cap> Here we go again.
cap>
cap> No need to press RESET.
cap>
cap> You need to exit the viewer. The dynamic linker and modules will remain in
cap> memory.
cap>
cap> Load a text editor. It will use the modules already
cap> located in memory.
cap>
cap> Is there anything against this approach?
Modules that have already been used once will need to be loaded again or kept
a separate part somewhere in memory. The trick is that already “inserted” into
The program modules cannot be separated from the program - this is such a property
modular structure.
Still, I recommend that you look and thoroughly understand the structure
modules. From my point of view, this approach is only compatible with separately
functioning OS, and not independent applications.
However, there are no restrictions on solutions if boot.b is so “smart”
then this option is also possible - it loads the module container into the upper memory, and into
The bottom one copies it, attaches it to the program and let's go...
cap> Possibility of expansion by adding modules.You are misunderstanding something here, again probably because of the modules. You can
expand the program only when you write it - modules are already written and
compiled programs (albeit in a special container). For something
there to expand you will have to load assembler (or Javascript if you like) edit
program and include in it an indication of these modules. Dynamic technology
there is no loading here, because an already running application should not
need no library and work independently.
If the opposite is stated, then once again - this will no longer be a boot-linker and
the whole axis.
Hello Vitamin
Gri> RAM.ChangeLog - change the memory page to the specified logical
Not a very good name for the function.
The list of modules is good.
Gri> Now, I pressed reset. I got tired of the viewer, I wanted to type the text -
Gri> and everything is the same - only MY individual code was loaded and that’s it
Gri> the rest of the modules were picked up by themselves.
Well, here we go again.
There is no need to press RESET.
You need to exit the viewer. The dynamic linker and modules will remain in memory.
Download a text editor. It will use modules already in
memory.
Is there anything against this approach?
Gri> 2) there is no possibility of extension, this is a ready-made code - only when
Gri> recompilation; possibility of replacing libraries - 100% at expense
Gri> modular organization;
Possibility of expansion by adding modules.
Hello, Vitamin
Vit> m- в области памяти с именем name.
Vit> sN- по смещению в стеке в N байт от SP на момент старта про-
Vit> цедуры.
Ещё нужны inline константные аргументы, размещаемые в коде типа
CALL target
DB 5
DW #7ffd
; сюда возврат
Vit> ,
Что это?
Vit> Hеа. Переводим документацию на другой язык получаем другую
Vit> библиотеку? Типа был Паскаль, получили 1С?
Рассмотрим на примере
┌─- code ───
;; @sig strcpy@[C([C{C)#D(DH)
;; Копирование строки
;; @arg HL - источник
;; @arg DE - приёмник
;; @ret DE - результат
strcpy LD A,(HL) ; пошла сама процедура
└── code ───
Две точки с запятой - это комментарий документатора.
С собаки начинаются тэги документатора.
@sig - объявление сигнатуры, которое хэшируется и попадает в модуль с объектным
кодом.
Остальное попадает в документацию. Без тэга - просто переписывается в
документацию. @arg и @ret - оформляется в документации соответствующими
разделами.
Hу разве не заглядение? ;)
Hello Vitamin
Vit> the implementation is complicated IMHO... offsets are only sequential and dance
Vit> from the return address
This means that we need syntax for the signature.
The technology for using such arguments is well established. For example:
┌─- code ───
EX (SP),HL
LD A,(HL)
INC HL
LD C,(HL)
INC HL
LD B,(HL)
INC HL
EX (SP),HL
└── code ───
Even more attractive than poking around the stack through index registers.
Vit> Without this directive, this line will not be interpreted as
Vit> start of the procedure. Because you don't have a special compiler
Vit> able to parse tags in comments, symbolic names will not be generated
Vit> will be
On the other hand, we can recall the need for gradual migration from
static layout to dynamic.
The code with the signature in the comment can be compiled right now, in any
assembler (after tokenization). That is, this second you can develop the code.
In parallel, you can develop a special compiler and documenter.
The ALASM macro code depends on ALASM, which not everyone likes. And only
You still can't get out of it with macros. For example, I would like expressions from
imported symbols that would be stored in compiled modules andwere calculated at link time (again remember the reverse Polish notation in
iS-DOS).
Hello, captain cobalt
cap> We also need inline constant arguments placed in the type code
cap>
cap> CALL target
cap> DB 5
cap> DW #7ffd
cap> ; return here
IMHO the implementation is complicated... offsets are only sequential and dance from the address
return
cap> What is this?
the final 0. C++ syntax added %)
cap> Two semicolons are a documentarian's comment.
cap>
cap> The documenter's tags begin with the dog.
cap>
cap> @sig - signature declaration, which is hashed and ends up in module c
cap> object code.
cap>
cap> The rest goes into the documentation. Without a tag - just rewritten in
cap> documentation. @arg and @ret - documented in the documentation
cap> by the corresponding sections.
cap>
cap> Well, isn't it a sight for sore eyes?
This is not the case for me, I have separate documentation, separate compiler directives. Type:
__PUBLIC "strcpy@[C([C{C)#D(DH)",FUNCTION
ld a,(hl)
Without this directive, this line will not be interpreted as the beginningprocedures. Because without a special compiler that can parse
tags in comments symbolic names will not be generated
Hello, captain cobalt
cap> Сигнатура - это часть документации.
Hеа. Переводим документацию на другой язык получаем другую библиотеку? Типа был
Паскаль, получили 1С? :)))
cap> Документация всё равно понадобится.
ППКС
cap> Поэтому - чтобы не плодить сущностей.
Сущности и не будут плодиться.
cap> Hа самом деле в языках высокого уровня она действительно работает во
cap> время компиляции. Проверяется, что передаётся правильное количество
cap> аргументов правильных типов.
Hасколько я знаю, для создания имен используются описания интерфейсов (для С
это заголовочные файлы). А вот сверка уже потом на этапе линковки.
cap> А в ассемблере. Если мы забыли загрузить аргумент в регистр, и в
cap> регистре мусор от предыдущего использования - компилятор ничего не
cap> скажет.
А это уже везде. Вне зависимости от платформы, наличия или отсутствия ОС.
Я тут наброски делал по поводу организации сигнатуры. Часть подсмотрел, часть
придумал сам. Вот что получилось.
Символьное имя точки.
Символьное имя может содержать в себе дополнительную информа-
цию о сигнатуре, типах параметров и возвращаемом значении (в
квадратных скобках указаны необязательные параметры):
PointName[@signature[(parameters)[#out_type(params_type)]]],
signature определяет сигнатуру точки (флаги в символьном экви-
валенте и типы входных параметров для точки-функции в скобках):
Uname;- пользовательский тип name
[type- указатель на тип type
{type- константный указатель на тип type
число скобок определяет вложенность, итоговая константность
определяется по типу последней скобки.
V- void
C- char
I- int
L- long
F- float
c- CARRY
z- ZERO
y- CARRY&ZERO
f- function
B- byte
W- word
D- dword
E- double
Типы c,z и y применяются только для точек-функций.
Также для точки-функции возможно уточнение типа передавае-
мых и возвращаемых значений после знака #. out_type определяет,
как возвращается значение, params_type определяют способ пере-
дачи параметров. Если уточнения нет, то параметры передаются
согласно компилятору (в случае ЯВУ). Следующие обозначения для
различных способов передачи данных:
a- регистр А, 8 бит
b- регистр B, 8 бит
c- регистр C, 8 бит
d- регистр D, 8 бит
e- регистр E, 8 бит
f- регистр F, 2 бита (ZERO & CARRY)
B- регистр BC, 16 бит
H- регистр HL, 16 бит
L- регистр HLDE, 32 бита (HL- старшие биты)
D- регистр DE, 16 бит
E- регистр DEHL, 32 бита (DE- старшие биты)
X- регистр IX, 16 бит
Y- регистр IY, 16 бит
m- в области памяти с именем name.
sN- по смещению в стеке в N байт от SP на момент старта про-
цедуры. Для доступа к переменным может использоваться сле-
дующий код:
PointName;
ld; iy,-2
add iy,sp
...
ld a,(iy+N)
...
ld l,(iy+N)
ld h,(iy+N+1)
...
Пример кодирования сигнатуры экспортируемых точек:
int integerVariable; => integerVariable@I,
char* strcpy(char* dst, const char* src); => strcpy@[C([C{C),
или, при спецификации регистров (in=de,hl, out=de):
strcpy@[C([C{C)#D(DH),
void myfunc(mytype** ptr); => myfunc@V([[Umytype),
Hello,GriV
Gri> And so, I want to write a boot, I want to write a text editor, I want
Gri> write a viewer, I want to write a toy. Which of these procedures will I do?
Gri> should I use? That's right - all of them.
Gri>
Tell me what you will use if you want to write a 50fps viewer,
a toy with sprite output via a stack and a bunch of 256b-aligned tables,
multicolor or chunky demo, finally? Your approach again gives
pisism, it does not allow you to do on the STRONGLY LIMITED resources of the Spectrum
really fast and cool stuff. If you just vomit standard
Inforcom-level procedures (remember, there were also books - 'how to write a game in
assembler' or 'dynamic graphics') with a bunch of problems about linking, OOP
and so on. blizzards - then you will get sickening programs - slow, uninteresting.
> The general idea of the vitamin is this: behind each of the programs there is a huge burden
> a trail of re-written procedures (it’s really time
> to finish with the invention is great), which can and should be used
> in a standard form and thus tighten and increase the overall
> efficiency of software production.
> Behind each of the programs there is a trail of similar ones (to procedures in other programs)
procedures, and if these are not those programs that make you sick, but really fast ones
things, then each procedure has been licked dozens of times and adapted specifically for
specific application case. Why are there some standard libraries (modules -
call it what you want) with 'swiss-knife type' procedures for all occasions, with
processing all possible situations and a ton of action options?
Hello, captain cobalt
cap> No need to press RESET.
cap> You need to exit the viewer. The dynamic linker and modules will remain in
cap> memory.
cap>
Then, for example, run qc, copying it completely some
floppy disk to another. Or create a ram disk in memory. Or run alasm, which
will absorb a couple of dozen source codes, placing them on pages, and he himself
eats up plenty of pages.
> Load a text editor. It will use the modules already
> located in memory.
>
If traces remain of them. Otherwise, he will climb onto the disk again and fidget
head like a wounded man (out of modesty I won’t say where exactly).
By the way, at the same time, come up with a search for modules by page and checking their integrity,
and report the computer time costs for this.
Hello, captain cobalt
cap> But if polymorphism is the power of wow :), then the Amiga “simply
cap> libraries". :)
cap>
By the way, dear captain cobalt, since you were noticed as a member of the PLO
Hello, captain cobalt
cap> Yes.
cap> It is impossible to use someone else's code without documentation.
cap> Code for reuse must be documented.
cap>
If you are so sure of this, then you have never disassembled someone else's
programs.
> There are two main outputs:
> 1. Look at the OOP on the PC (in TASM, etc.).
> 2. Use typed assembly language, "typed assembler",
> abbreviated as TAL. The idea can basically be screwed onto the Z80. But this is just right
> very distant future, which we will talk about much later.
> Links here [http://www.wasm.ru/forum/viewtopic.php?id=8338].
Are you ready to personally take on the task of writing such an assembler for the Spectrum?
Hello, captain cobalt
cap> Let's try to formulate theses based on the results of the topic:
cap>
cap> 1. The approach of the Amiga libraries is OOP brakes without the advantages of OOP.
cap>
Dear captain cobalt, tell me, have you seen the 'Amiga library approach'? I
I doubt it... You just recently wrote down the Alasma memory driver in OOP
or wherever. Admit it, you haven’t even seen him?!
Hello, captain cobalt
cap> Now includes are used for assembly. In single-text assemblers
cap> with each assembly there is a crawl on the disk. In multi-text
cap> when everything is in memory, there are still compilation problems. If
cap> everything is in memory ready for use, it is only needed during compilation
cap> link one module under development.
cap>
But it’s okay that with any linking in runtime there will be brakes not with compilation, but
every time - with downloading and linking? Or are you ready for the sake of the ideals of pisism
sacrifice anything, including user convenience?
> If gradual migration is possible, then there will be more programmers
> develop universal code. At first it will be used with
> static layout, but will accumulate the base for dynamic
> layout.
>
Believe me, there will be no migration.
Now you are personally ready to use your dynamic layout, and in what
specifically a software product for the Spectrum? Or are you only ready to write dozens
messages about 'dll-hell' and 'oop with dynamic linking rules'?
Hello, captain cobalt
cap> The technology for using such arguments is well developed.
cap> For example:
cap> ┌─- code ───
cap> EX (SP),HL
cap> LD A,(HL)
cap> INC HL
cap> LD C,(HL)
cap> INC HL
cap> LD B,(HL)
cap> INC HL
cap> EX (SP),HL
cap> └── code ───
cap> Even more attractive than poking around the stack through index
cap> registers.
cap>
This is a technology for reading arguments 'hardwired' into machine code, i.e. immutable. And
again, reading into registers, not using them. For their comfort
use (several times and at the right moments), they will have to be transferred to
memory, whether by IX/IY, or absolute (by address). It is also important that such
arguments (built into the code) make it difficult to debug the program (it is not clear how many there are
arguments comes after CALL and when they end and the next code begins, to
In addition, the disassembler will perceive them as code, issuing meaningless commands).
Hello, captain cobalt
cap> Brakes for loading a handle into a register, indirect transfer of control, and
cap> register unavailability for passing arguments.
cap>
You have never seen 68k architecture processors in your life, 15 32-bit ones are not enough for you
registers? This is not x86, where every register is worth its weight in gold.
In addition, please demonstrate the brakes of calling Amiga libraries, not
be unfounded!
For example like this:
┌─- code ───
jsr_LVOFunctionName(a6) ; There are definitely brakes here, 2 whole words are selected
from memory, compared to
jsr absolute_address ; an absolute call, where the address alone takes 2
words
└── code ───
> then the Amiga has “just libraries”. :)
Hello elf/2
elf> and we should stop talking about OOP in this thread, imho. there is no language with explicit yet
elf> support at least...
> 1. static linking from object builders (Vitamin suggested): how is it
> make it optimal for spec
Similarly, I suggest stopping with this, as long as there is no compiler with an explicit
support for this. Not a single more or less adequate ZX encoder will contact this
linking in the absence of its support in the assembler and loader. If so
the library is so irreplaceable, I would rather spend time nibbling on
no linking husk or searching for sorts, rather than mockery
above itself in order to make the program linkable when starting.
> 2. dynamic linking: outline and compare existing approaches
> (ammi/libman/Win/Lin/etc.) and as a result select/synthesize that
> which is better for spec
A variant of dynamic linking with statically located (by
the address specified by the program) by the input table (JP func1:JP func2:...). Given
option allows you to write programs 'as usual
Hello Vitamin
What is "mounting" from the point of view of the Linux kernel?
Hello Vitamin
Gri> The trick is that modules already “inserted” into the program will not work
Gri> to be separated from the program is a property of the modular structure.
Modules are not "inserted" into the program.
The program is loaded on top of library modules.
When the program ends, the modules remain and are not touched.
Now you can load another program on top of them.
Let's replace the word "modules" with the word "OS".
Is the OS "inserted" into the program? No.
Can the OS be separated from the program? Can.
Then why do we need the “modular structure property”?
Gri> To expand anything there you will have to load an assembler (or Java
Gri> if you like) edit the program and include in it an indication of these
Gri> modules. Dynamic loading technology does not work here, because
Gri> an already running application should not need any libraries and
Gri> work independently.
This is the "spirit of procedural programming" again. :)
The functionality does not have to be used explicitly.
If a certain module is loaded into memory, and the program knows how to use abstract
functionality, the specific implementation is this module, then the program
should use this module. And a specific set of modules will be
configurable.
Hello Vitamin
Vit> What is tokenization?
Translation from plain text to "assembly format".
None of the widely used spec assemblers use plain text
for sources.
Vit> Additional pass by some utility? But she’s not there.
There is such a utility.
Each assembler has its own.
Vit> Look at things more broadly. The supposed approach of your wishlist does not deny.
I see that he doesn’t deny it.
Vit> How??? How can a program at runtime expand its
Vit> functionality due to additional modules, if she doesn’t dream about them
Vit> not in spirit???
This is the "spirit of procedural programming" again. :)
Let's look at the example of Linux. :)
It has loadable kernel modules.
Let's load such a module. We'll mount it.
All. Now any program can use the functionality of the module via
standard file I/O, although the module itself is not in the dark.
Now let’s generalize to an arbitrary program interface (not just a file interface).
It's clear?
Hello Vitamin
yok> Dear captain cobalt, tell me, have you seen the 'library approach' live
yok> Amiga'? I doubt something...
Above, the 'Amiga library approach' was classified 'in Windows terms'.
None of the Amizhniks challenged it.
yok> You just recently wrote down the Alasma memory driver in OOP or wherever.
yok> Admit it, you haven’t even seen him?!
Of course we saw it.
Calling the driver directly is an optimization based on the fact that in each
There is only one driver at a time.
yok> You have never seen 68k architecture processors in your life, 15 is not enough for you
yok> 32-bit registers? This is not x86, where every register counts
yok> gold.
More registers are good.
This is very good for single threaded programming.
But there are also parallel programming languages that, with proper
compilers can make good use of at least a million registers. However, this is not
has to do with spec.
yok> In addition, please demonstrate the brakes of library calls
yok> amigas, don't be unfounded!
yok> For example:
All brakes are listed.yok> But it’s okay that with any linking in runtime there will be no brakes
yok> compilation, and each time with loading and linking?
Just in case, I repeat that I suggest replacing the loading brakes with brakes
layout. The module is loaded once and linked many times.
yok> Believe me, there will be no migration.
yok> Now you are personally ready to use your dynamic layout, and
yok> in which software product for Spectrum?
There will be no new software products immediately.
To begin with, it is proposed to adapt existing software, such as ALASM, BGE, PT.
Classic games Exolon, Earth Shaker, add to taste.
yok> If you are so sure of this, then you have never carried out
yok> disassembling other people's programs.
Conducted.
And you can even draw a parallel.
When analyzing one program, in principle, everything you need can be kept in
human memory. But if you analyze ten programs in parallel, you will have to
write down on paper.
It's the same with libraries.
One library can still be used without documentation. A dozen libraries -
no one will.
yok>
> There are two main outputs:
> yok> 1. ...> yok> 2. ...
>
> Are you ready to personally take on writing such an assembler for
> Spectrum?
A similar assembler has already been written for several months. At a sluggish pace, as
everything is on spec. Some ideas from the design documentation were presented here.
When (if) it comes out, you will find that everyone knows how to use it. :)
But... First compilation into dynamically linked modules, and only then
(optional) what is quoted.
yok> Tell me what you will use if you want to write
yok> 50fps viewer, a toy with sprite output via the stack and heap
yok> 256b-aligned tables, multicolor or chunky deme, finally?
To some extent this is possible.
These are all examples of dynamic code generation.
You can give the module more memory - and let it expand procedures into it and
calls them.
This is where flexibility versus speed comes into play. Flexibility can be very beneficial
thing in practice. The speed in the “watch the demo once” style can
has much less significance. Because “Spectrum pixels don’t flatten anyone.”
yok> This is a technology for reading arguments 'hardwired' into machine code, i.e.yok> immutable. And again, reading into registers, not using. For
yok> comfortable use of them (several times and at the right moments)
yok> will have to be transferred to memory, whether according to IX/IY, or to absolute (by
yok> address). It is also important that such arguments (built into the code)
yok> make it difficult to debug the program (it is not clear how many such arguments there are
yok> after CALL and when they end and the next code begins, besides
yok> the disassembler will perceive them as code, issuing meaningless commands).
Everything is correct.
The point is only to provide the syntax for declaring them in
signature
yok> Then, for example, run qc, copying it completely
yok> some floppy disk to another. Or create a ram disk in memory. Or
yok> launch alasm, which will absorb a couple of dozen sources
yok> having placed them in pages, and he himself will eat plenty of pages.
Well, what's the problem?
Unneeded libraries can be thrown out of memory.
If you're really stuck, you can throw out the dynamic linker.
You will get exactly the same qcalasm, but reboot again via RESET.yok> If traces remain of them. Otherwise, it will climb onto the disk again, and it will be
yok> fidget with your head like a wounded man (out of modesty, I won’t say where exactly).
yok>
yok> By the way, at the same time, come up with a search for modules by page and checking them
yok> integrity, and report the computer time costs for this.
No such mechanism is provided.
There are modules - the program works. Modules are killed - the program does not work; RESET;
loading modules from disk.
yok> By the way, dear captain cobalt, since you were noticed during your time
yok> 'Opept of OOP
Hello, captain cobalt
cap> What is “mounting” from the point of view of the Linux kernel?
Calling functions of a specific module, the name of which is specified during execution
operations. And in general, mounting has nothing to do with it in the grand scheme of things.
Let's go back to a simple example - that abstract GUI library,
supporting expansion through a single interface for different widgets. You can
link a bunch of modules with their own widgets, but the library won’t have them
use because he knows nothing about them. The client should know about them
this library, which creates objects whose interface is implemented in those
modules. Those. he must know about them. And if the program doesn't know, it won't
use. In other words, expanding the functionality of programs by downloading
additional modules is not possible unless special
possibilities for this (such as downloading dlls, etc.).
Hello, captain cobalt
cap> This means that you need syntax for the signature.
If we need it, we'll do it. We don't lose anything, in the general case.
cap> The code with the signature in the comment can be compiled right now, in
cap> any assembler (after tokenization). That is, right this second you can
cap> develop code. In parallel, you can develop a special compiler and
cap> documenter.
What is tokenization? Additional pass by some utility? But she’s not there. And
transfer programmers to a new, not yet existing compiler less
real than to transplant everyone under the existing alasm.
Moreover, macros can be ported to any more or less serious assembler.
But for other “toys” nothing will work...
cap> You need to exit the viewer. The dynamic linker and modules will remain in
cap> memory.
cap> Load a text editor. It will use the modules already
cap> located in memory.
Look at things from a broader perspective. The proposed approach does not deny your wish. Let me explain.
Suppose there is a certain severe SYSTEM module that contains the Exit and
LoadLibrary. In the simplest case, the first function will be the output to DOS, and the second will bejust by downloading the file. We replace this module with ours and _automatically_
we get the opportunity to exit into a certain shell (from RC to OS) and load modules from
caching.
cap> Possibility of expansion by adding modules.
How??? How can a program at runtime expand its functionality beyond
counting additional modules if she doesn’t think twice about them???
Gri> what things already (currently) are somehow connected with
Gri> modular organization (full list, including documentation). What
Gri> is it necessary for this to become “more alive than dead”?
The first stable version of the library: http://zxdocs.fatal.ru/coding/module.zip
There are no longer enough opportunities, I plan to expand.
yok> Dear captain cobalt, tell me, have you seen the 'library approach' live
yok> Amiga'? I have some doubts... You just recently are important memory driver
yok> Alasma was enrolled in OOP or wherever. Admit it, you even looked him in the eye
yok> haven't you seen?!
Of course, I apologize wildly, comrade, but in response to all the requests made,
What's so cool about this utter amiga? We received monotonous answers like
"look at libman, everything is there." Well, we looked and made conclusions based on incomplete
(there was so much) information.
Hello, captain cobalt
cap> Translation from plain text to "assembly format".
cap> None of the widely used spec assemblers uses
cap> plain text for sources.
But at least one assembler uses existing developments. Better tit
in your hand than a duck under the bed%)
cap> Such a utility exists.
cap> Each assembler has its own.
Then entrust this utility with generating tables to create a relocatable
code. There is no other way.
cap> This is the "spirit of procedural programming" again.
cap>
cap> Let's look at the example of Linux.
cap> It has loadable kernel modules.
cap> Let's load such a module. We will install it.
cap> That's it. Now any program can use the functionality of the module
cap> via standard file I/O, although we don’t dream about the module itself
cap> not in spirit."
cap> Now let's generalize to an arbitrary program interface (not only
cap> file).
cap> Got it?
Well... Gotcha... To be honest, I don’t remember any polymorphism in the kernelLinux. To make sure, I even asked the person who
I developed these modules - there is no implicit call there!!! There is only something similar
when registering the file interface of special devices, and even then, the kernel is about yours
modules and doesn’t know until you clearly knock on the door of the person he serves
device. I'm not even talking about simple modules that just hang in the kernel and
they are accessed using specific names of functions that must be
unique in the entire address space!
Hello, yoko_ono
yok> If the library is so irreplaceable, I would rather spend the time
yok> to bite off any link husk from it or search for sorts
yok> rather than mocking oneself in order to make linked ones
yok> program launch.
What is link husk? As a result, instead of a universal module,
will it turn out to be a dry code block, brutally compiled to a specific address?
Yes... The versatility is so great.
PS. I am a wild person, I honestly say that I do not know all the possibilities of Alasma.
Enlighten the dense me, how can I do this so that non-callable functions do not
compiled?
Hello, captain cobalt
cap> The signature is part of the documentation.
That is Is CLSID part of the Vinapi document?
cap> And in assembler. If we forgot to load an argument into the register, and
cap> register garbage from previous use - the compiler does not do anything
cap> will say. :(
Did you write in C? On different compilers? If you wrote it, then you know that they are different
Compilers behave differently with uninitialized variables. Nothing
different from your example. Why did I say this? Besides, what about this problem?
don't bother.
Hello Vitamin
Vit> __EXTERN "onefunc@B(DD)",func_ver_1
Vit> __EXTERN "onefunc@B(WW)",func_ver_2
Vit> ...
Vit> ;somewhere in the code
Vit> CALL_ func_ver_1 ;call the first function
Vit> ...
Vit> CALL_ func_ver_2 ;call the second function
Vit>
what does overload have to do with it? you manually assign an alias for the function and use it
you call.
under real overload, the assembler must "magically"
analyze your code before CALL_ and understand which of the onefunc options you
meant and call him
Hello Vitamin
Vit> There is a link to the documentation. I told about her several times in
Vit> in different places.
documentation is modules.txt inside modules.zip? This approach won't work :(
we need examples: why is this, why is it better... and at least a group of comrades
which uses it. and most forum visitors (including me) are
theorists :(
Hello Vitamin
Vit> I made some sketches here about the organization of the signature. Part
Vit> I spied it, some of it I came up with myself. This is what happened.
Vit>
elf> Vit> signature checking works normally only at the compilation stage.
elf> Vit>
elf>
elf> What???? Just at the linking stage. To know what and with what
elf> glue.
guys, this is not funny anymore... mangled function names with signatures appeared in
C++ compilers as workaround; necessary; there was some way to resolve it
overloaded functions, and the obj file format did not contain argument types.
I had to make unique names for overloaded functions. accordingly in
compilation point when the compiler knows the types of all arguments when calling
function it creates this tricky name and the linker just compares two lines... you
want to make overloaded functions on ASMA? this is not possible because
The assembler syntax does not contain function call commands with arguments.
cap> Only memcpy is used in the client code. VI#43543 simple
cap> is copied into the client module with the object code at compile time.cap> During dynamic linking, they are simply checked for equality.
that's it, try to write a function that has a number in register A
screen line returns the address in HL and its call in terms of your mythical
compiler. and explain who and how will form the mangle name _when called_
and the return value is not encoded in the signature at all, because the overload
functions based on return type are not supported because it is not
can always be determined.
Well, and most importantly: omnipotents do not fly!
Hello Vitamin
Vit> I came up with and wrote everything a long time ago. Now I'm trying with help
Vit> improve those present and apply somewhat wider than just in mine
Vit> projects.
then it was necessary to start with a story about what already exists and how it works. and
Be sure to explain why this is better/more convenient than other methods.
Hello, captain cobalt
cap> It is assumed that the author of memcpy has changed the interface (or introduced another
cap> incompatibility) will change the signature. Incompatible modules will not be
cap> compose. If the author forgets to change the signature, he will remember
cap> when something breaks. If nothing breaks,
cap> someone who breaks it will tell him. If the author missed the spec,
cap> the problem can be published.
if the interface of a library/library function changes, then the library
The version number and linker changes based on the program's VERSION requirement
libraries will not be linked with the new version.
Hello, yoko_ono
yok> But no, give you pissism, with the obligatory correction of absolutes
yok> addresses wherever possible! Never mind, time heals...
well, as much as possible, Lena... I’ve already written twice that on Windows/Linux with
no one controls absolute addresses during loading. does exactly what you want
offered. Only the addresses in the jump table are changed. the only difference is
the fact that this is done by the system and not the library.
yok> Similarly, I suggest stopping with this as long as there is no compiler with
yok> explicitly support this. Not a single more or less adequate encoder on the ZX
yok> will contact this link if it is not supported in the assembler and
yok> loader.
with the fact that Vitamin and captain cobalt got carried away and are trying to come up with another
omnipotent, which, firstly, is impossible to do, and secondly, no one
will not agree to use
Hello Vitamin
Vit> And the registry is nonsense.
What exactly?
Is this a dirty word?
What about the approach to configuring autoloading plugins?
Hello Vitamin
Vit> it is possible to implement overloaded functions (for this there are no
Vit> no effort is even required), but whether to use them or not is already
Vit> personal matter of the programmer.
To use overloaded functions, you need to manually register signatures in
client code.
Vit> Yes? How will you create relocation tables? If the assembler does not
Vit> supports macros, you will need to create additional ones
Vit> intermediate tables with addresses of address-dependent points.
The utility that turns source code into source code is a compiler. Better right away
teach her how to make object files. Then the "old assemblers" can be discarded.
:)
elf> so that hell is not enough to be able to store
elf> several versions of the library on one machine. this works in linux and
elf> .net
Is it possible to keep different versions of the library in memory on a spec?
Most likely not.
Therefore, it is important that if compatibility is sufficient, the library is linked.
Insufficient - the problem must be detected.
Each library should have one.
elf> exactly, but where will the “registry” be located in this case? and howelf> it will help solve the problem
It's not clear yet.
It can lie on the “system disk”, and after loading it constantly sits in
memory.
Or each piece can lie next to its program in the "file
configuration".
elf> so that hell is not enough to be able to store
elf> several versions of the library on one machine. this works in linux and
elf> .net
There is another way to store multiple versions of libraries on one machine.
Link programs statically. :)
elf> then just for the sake of the collection link
I'll also throw in a couple of links:
File: links.txt http://zx.pk.ru/attachment.php?attachmentid=3959
Hello Vitamin
elf> "Can you afford to keep ... in memory on spec?" :) necessary
elf> insert
I'll explain.
There is a code. There is data.
For code to process data, it must be addressable at the same time.
Now we are faced with Speccy page addressing.
If you store code in pages, it will not be able to directly address data in
other pages.
If you store code in lower memory, it can efficiently access all
memory through pages. This is how software is most often written.
There is not enough lower memory. Therefore, keeping duplicate code there is unacceptable.
There is much more upper memory. Especially on clone monsters. And use it
for permanent storage of configuration data in order to increase comfort
work - may be quite acceptable.
Hello Vitamin
elf> 1. most often yes, but if you really need it, you can specify a dependency with
elf> up to the minor version. for example, with a minor update it could
elf> a new function will be added, this does not harm compatibility (if done correctly
elf> use of course)
elf> 2. means not fate :) or indicate indicate a list of possible ones
elf> versions when importing
elf> 3. this means this is a new version and call functions with unchanged ones
elf> signatures are most likely dangerous. because they may have side effects
elf>
elf> I gave module initialization as an example of what to do if
elf> function signature (i.e., distribution of arguments across registers) is not
elf> has changed, but the meanings of the return codes have changed, i.e. before 0
elf> meant success, but in the new version it meant an error. the linker will swallow it, but
elf> the program will not work... you can come up with other options.
All hypothetical examples are very good. :)
Well, what can I say?
Each approach has disadvantages.
On the one hand, if integrity is not controlled, the result is DLL hell.If there is version control, we get incompatibility of potentially compatible
code.
Control by signatures is some kind of intermediate solution. And inherits
advantages and disadvantages of both approaches. If we keep this in mind, then the approach is very
practical. ;)
elf> why a list? why not search for all files that match the mask and
elf> lying in a specific location (directory?)
The most important thing about the list is that you can somehow get pointers from it
on plugin functions and call them.
You can search for files by mask, download them, and add them to the list. But they may not
get into memory.
You can also imagine a user with one disk drive. He has a floppy disk with
graphic editor and plugins. It launches the editor and automatically
the plugins that he configured are loaded. But all plugins do not fit on
floppy disk, and sometimes it loads plugins that are stored on another floppy disk. A
He also has floppy disks with his pictures. You can't just search for files in
mask catalog. :)
Hello Vitamin
elf> from now on in more detail:
elf> 1. we have a library xyz.lib
elf> 2. in its export table there is a function get_scr_addr@r_v_q
elf>
elf> 3. write a program that should call this function:
elf> ----------
elf> require 'xyz.lib'
elf>
elf> ld a, 5
elf> call xyz.get_scr_addr
elf> ----------
elf> if the mythical compiler will simply look in the export table
elf> library function starting with get_scr_addr@ and register it
elf> full name in the program import table then this gives nothing except
elf> those cases when we have greatly changed the interface of this particular one
elf> functions. and the interface is sacred! if we start it permanently
elf> change, then it can no longer be called a library.
Everything is correct.
On the spec "all the code has already been written."
On platforms that continue to develop, there are such things as obsolete and deprecated.
elf> and if we added a function to the new version of the libraryelf> initialization which MUST be called first, and the user about
elf> I didn’t know/forgot that all these signatures won’t help. and linker without
elf> errors will all be linked
Initialization is important.
The module initialization function must be called by the linker.
elf> however, they are used on both Windows (activex, .net) and Linux
elf> library version. There are usually minor and major versions. and there will be no software
elf> collect if the major version has changed, but the major version has changed
elf> just means that there is no compatibility. if it has changed
elf> minor version, then as a rule everything comes together
1. If compatibility remains, then the linker should not care about minor
numbers?
2. What if compatibility breaks down in this version, and again in the next?
recovered?
3. What if part of the module remains compatible, but part does not? Signature for
Each symbol of the module is resolved precisely by this.
Hello Vitamin
ice> How is this "behind the scenes"? Access to COM occurs precisely by CLSID. Ie
ice> this is the signature.
Okay.
It remains only to find out the connection between COM and WinAPI. :)
Hello Vitamin
ice> That is. Is CLSID part of the Vinapi document?
This is a "behind the scenes mechanism" that is not visible from the client code.
This is how the signature works.
ice> Did you write in C? On different compilers? If you wrote, then you know that
ice> different compilers behave differently with uninitialized ones
ice> variables. No different from your example. Why am I doing this
ice> said? Moreover, you shouldn’t bother with this problem.
You can put “good style” on T.
And in assembler there are still problems sometimes.
Vit> Everything is true, but you contradict yourself. It is not possible to add new
Vit> widgets (that is, expand the functionality) of a ready-made program! She
Vit> uses only those concepts (libraries) that it knows about at the moment
Vit> compilation. So expanding the functionality of ready-made programs is just like this
Vit> head-on is impossible.
Modules that extend functionality are plugins.
In order for a program to use the functionality of plugins, there must be somewhere
list of plugins.
In order for plugins to be added during operation, this list must be
elements could be added.
Where might this list be located? There are two main ways:1. In the program. The program itself makes the LoadLibrary and adds the element to itself
to the list.
2. In a publicly known place. The user compiles the desired list and places it in
this place. A well-known place loads these modules when the program starts.
The program uses a ready-made list and does not bother with LoadLibrary.
What is this well-known place? It's just a module. More precisely, a list of plugins
is stored not in the module, but on disk. That is, it persists between shutdowns
cars. And a module is just an interface to this disk storage.
Moreover, for each program it will be possible to customize the list of plugins,
automatically loaded when it starts.
And the name of this disk storage is the registry. :)
Hello elf/2
elf> "Can you afford to keep ... in memory on spec?" necessary
elf> insert
I also thought that the black cat ran twice, but you beat me to it %)
The only thing useful I pulled out of captain cobalt's ideas is versioning
at the level of functions, not entire modules. But this is only if there is an opportunity
tear apart libraries, pulling out the necessary functions. Otherwise it's not
makes sense.
Hello elf/2
elf> don't do that, by the way, there is a registry with a general list of everyone
elf> libraries in the system do not save you from all this
It's entirely possible to do this. The library has changed radically - it is changing
name/version and it won’t link “where it shouldn’t”. And the registry is nonsense.
cap> To use overloaded functions, you need to write them manually
cap> signatures in client code.
And to use assembler you need to write programs by hand! Think about it
yes?
cap> The utility that turns source code into source code is a compiler. Better
cap> immediately train her to make object files. Then "old assemblers"
cap> can be discarded.
Well, well. No one showed any desire to switch to the existing alasm, but as soon as
an ephemeral compiler will appear on the horizon, and everyone will immediately run, dropping their slippers
use it and write programs in it. It's better to use what you have.
Hello elf/2
elf> that's what I mean. the library must have a version, not the function
elf> signature. the library contains interconnected functions and
elf> a library is defined by a set of functions.
The signature of a function is at a minimum its name, and at most a name, list and type
passed parameters and version. Another option is to store a hash instead of a signature.
Otherwise, the linking makes no sense. The set of functions in the lib may also change, but
only if, again, it is possible to cut out the excess.
Hello elf/2
elf> why a list? why not search for all files that match the mask and
elf> lying in a specific location (directory?)
Yeah. And there are several versions of the same library and the linker falls into
stupor before the problem of choice. Yes, the memory is not rubber, it seems...
max> The REL format itself seems to be even documented, i.e. somewhere a description of me
I met max>, but I don’t remember where. Most likely in the documentation for
max> dev tools from Digital Research.
Thanks, I'll look for it
Hello elf/2
elf> honestly? I'm afraid there is none. if there are one or two active
elf> developers on the platform...
So to Bobruisk then. I will do what is convenient for me and apply it purely in my own
projects. Goodbye dream...
Hello Vitamin
Vit> ... I'll look
Read what to look for, I think it will be useful.
File: REL_DOC.zip http://zx.pk.ru/attachment.php?attachmentid=3958
Hello, acidrain
aci> I understand that it’s difficult for you to perceive everything, but read this (I’m watching
aci> do moderators carefully remove everything they need?)
aci> http://www.totalamiga.org/pdf/totalamiga_19.pdf
aci> pages 24-26. urgently! =)
before the evil modders rubbed it, I rushed to read... in a nutshell, it’s very
similar to COM :), only less flexible since you can’t find out the list in runtime
interfaces supported by the library and it looks like a list of functions for a specific
The interface is hardcoded in the headers. although based only on this article
I won’t say.
What's frustrating is that even to use basic functionality (Intuition
- is this a GUI? Am I right?) you have to do a bunch of body movements:
1. open lib
2. get an interface
use...
3. give the interface
4. close lib
the structure of the program itself resembles what MS recommended in the days of Windows
3.11, the same message waiting loop, the same clumsy switch-case inside
PS: no offense please, they offered the link themselves
Hello, captain cobalt
cap> 1. Each library must be one. On disk and in memory.
cap> 2. Integrity control is needed.
cap> 3. If compatibility is sufficient, it should be linked.
cap> 4. Everything else is a problem for programmers.
there is an old but very necessary program that requires main.lib.1.0
installed a new program that needs main.lib.10.4
How can a programmer solve this problem?
Hello, captain cobalt
cap> The example shows one program. After all, they can only use libraries
cap> others?
Sorry, I didn't read it carefully :(
however, having multiple versions of the same library on disk is harsh
necessity. otherwise we will get non-working programs (the same dll hell)
Hello, acidrain
aci> I haven’t seen it, please clarify! It’s in vain that you declare out loud - you’re a girl
aci> gave a bunch of examples, so go ahead - compare yours with Amiga
aci> pisism further. Just don’t forget about the arm processor (better then
aci> PPC) make a spec so that the shot somehow works with your pissism and oops
aci> and other priests
It's a pity that I didn't see a lot of examples. By the way, ardent pisism/amigism
There are only a few people involved here, it’s a pity that their voices are so clear
can be heard... Throwing around terms, at least try to substantiate your point of view
words other than “this is pathetic pissism”, “oop” and others from the same series.
aci> Well, first of all, have you seen the girls? With boobs like that? They don't
aci> comrades, rather girlfriends (amiga in Spanish
Apparently these are not found in Taganrog and in Naberezhnye Chelny.
And in general, I consider this a very peculiar and local phenomenon...
aci> It's easier for you to download the Amiga emul and explore everything yourself from scratch -
aci> check it out. You'll poop your pants right away
Excuse me, but on what platform should I run the Amiga emulator? On ZX? Or on x86?
Then what is this - offtopic? And what does Amiga have to do with it? How is the Amiga emulator connected to
current discussion?aci> Ask, and ask the girl Lena (well-searched not only in
aci> amiga, but also PC and zx) - I think she will answer competently...
Offtopic again?
aci> I have never been into Windows (out of spite and addiction to the Amiga and Spec)
aci> coded
Then it is very wrong of you to talk about problems and advantages
writing programs for x86
aci> One lib - graphical interface (GUI), graphic lib (? not
aci> I see the need for spec). Perhaps a mathematical libla. What else
aci> might be needed? Keyboard control? By mouse? All this is in exe
aci> (kernal loader).
Which mouse, which GUI? Mathematical is only possible hypothetically???? you
Are you talking about Spectrum? I have already indicated a list specifically for you that you need
libraries, it’s a pity that you looked at this (or didn’t have time to read it, whatever).
Look on page 16 of this thread. If there are any objections to the list
give us yours.
Hello, acidrain
yok> Dear captain cobalt, tell me, have you seen the 'library approach' live
yok> Amiga'? I have some doubts... You just recently are important memory driver
yok> Alasma was enrolled in OOP or wherever. Admit it, you even looked him in the eye
yok> haven't you seen?!
Let's be careful, after all, we have a club of friends...
yok> A variant of dynamic linking with static linking was proposed
yok> located (at the address specified by the program) entry table (JP
yok> func1:JP func2:...). This option allows you to write programs 'like
yok> usually
Hello,GriV
Gri> Apparently these are not found in Taganrog and Naberezhnye Chelny.
Gri> And in general, I think this is a very peculiar and local phenomenon...
Gri>
I sincerely feel sorry for you 8)
> Quote:
> Message from acidrain
> It’s easier for you to download the Amiga emul and explore everything yourself from scratch -
> check it out. You'll poop your pants right away
>
>
> Excuse me, but on what platform should I run the Amiga emulator? On ZX? Or
> On x86? Then what is this - offtopic? And what does Amiga have to do with it? How in general
> is the Amiga emulator related to the current discussion?
>
Did you read to the end? If the amount of information required exceeds the capabilities of this
forum, then how do you stop me from posting the information? - look. because you found it for PC? and for
Ammi is full of it.
> Quote:
> Message from acidrain
> One lib - graphical interface (GUI), graphic lib (? not
> I see the need for spec). Perhaps a mathematical libla. What else
> might be needed? Keyboard control? By mouse? All this is in exe
> (kernal loader).>
Which mouse, which GUI? Mathematical is only possible hypothetically???? you
Are you talking about Spectrum? I have already indicated a list specifically for you that you need
libraries, it’s a pity that you looked at this (or didn’t have time to read it, whatever).
Look on page 16 of this thread. If there are any objections to the list
give us yours.[/QUOTE]
No, are you going to find fault? I said it was time for me to run - I packed everything in
a few lines in a hurry. What you suggested was repeated by me (do not deny
- everything is the same. I can't constantly monitor the forum), with the exception of dos.
I almost forgot ;) let's add dos.library.
Well, why bother with such a system in the form of your links and other things?
Please comment constructively, without causticism, on what I wrote in that post.
After all, there is 0 constructivism. Read it again, tell me where am I wrong?
Hello,GriV
Gri> Then it is very wrong of you to talk about problems and
Gri> advantages of writing programs for x86
It's not right for you to say that. you don't know what it is
programming for PocketPC? Then to the garden. This is Windows, only stripped down,
despite the fact that it functions on the armament.
Hello Vitamin
Vit> I return once again to the topic of the Amiga. Since I don’t know about her, well
Vit> There is no opportunity to study, I will ask you specific questions. Is it going?
Ask, and ask the girl Lena (well versed not only in Amiga, but also in PC
and zx) - I think she will answer competently...
Hello Vitamin
Vit> we constantly offend each other like this, but with you personally it’s like this
Vit> direct post
no, you didn’t offend me =) read post N217 one more time, ok? =)
Hello, captain cobalt
cap> 1. The library handle must be loaded into the register.
cap> 2. Indirect transition is slower.
cap> 3. The register is not available for passing an argument.
1. +3.
Code:
lea GFXname(pc),a1
jsr -$228(a6) ; OpenLibrary()
How many registers do you need to transfer data? 1 register of 16 32 bits
available at the time of transition - is this a lot?
2. who told you? This is not z80 or x86.
Hello elf/2
elf> the structure of the program itself resembles what MS recommended
elf> Windows 3.11 times, same message waiting loop, same
elf> open switch-case inside
I don’t know how it is with Windows - I’m into Windows (out of spite and addiction to the Amiga and
I've never coded (not counting a couple of fancy programs for my PocketPc).
What is written in this article is true for OS4, and we are discussing OS3.9. here
somewhat differently (by the way, the article says this). How are the headers and
registered ifaces - I don't know, I didn't code it. But because the module is already messed up somehow
the author of the thread - then I think the discussion is not appropriate.
Let's move a little away from OOP and modern proging methods and let's go
the old, old-fashioned way?
At first I took Vitamin's proposal in such a way that there would be some kind of bottle that
will load lib and prog and distribute them in memory (what I did on
speck, until I graduated from university - after that I abandoned this magnificent business). Therefore
I considered the linking absurd, and even more so the request for ifaces and so on. Isn't it
It makes more sense to have libs on disk and only 2-3 open for progs at a time
time. Because There was no talk about multitasking, then memory allocation, management
The opening and closing of the lib could well have been done by the bootloader. One libla - graphicinterface (GUI), graphical lib (? I don’t see the need for a spec).
Perhaps a mathematical libla. What else could you need? Keyboard control?
By mouse? All this is in exe (kernal loader). In total, we actually have 1 libla for
prog.
Exit from the program to boot (or whatever happens there). Naturally all this will grow
over time. no more frills.
It will be even simpler for the programmer - a list of inputs in includes (.h, .i) and autodoc's.
The only problem is relocation, but the bootloader and program can handle it
post-compiler to create the relocation table.
That's all for now, it's time to run
Hello Vitamin
elf> however, having multiple versions of the same library on disk is
elf> severe necessity. otherwise we will get non-working programs (the
elf> the most dll hell)
My position:
1. Each library should be one. On disk and in memory.
2. Integrity control is needed.
3. If compatibility is sufficient, it should be linked.
4. Everything else is a problem for programmers.
Hello Vitamin
elf> do we already have multitasking?
The example shows one program.
After all, some libraries can use others?
aci> I haven’t seen it, please clarify!
1. You need to load the library handle into the register.
2. Indirect transition is slower.
3. The register is not available for passing an argument.
elf> unfortunately, in conditions of critically low resources, you have to think in
elf> first of all about the effectiveness of their use, and not about comfort
elf> work. as I understand it, even on clone-monsters of memory under
elf> user data is not enough. and give one or two pages under
elf> parsers/configurations/registries are “criminal negligence” :)
I have a different opinion.
Look at the RAM disks you got yourself. And all for the sake of work comfort. :)
Compared to this, one page is nonsense.
Hello, acidrain
aci> Well, first of all, have you seen the girls? With boobs like that? They don't
aci> comrades, rather girlfriends (amiga in Spanish. Secondly, well, how many
aci> is it possible, comrade Vitamin C? Well, you slowed down once, you didn’t understand that I
aci> I told you, so why sulk at yourself for so long? forgive yourself! =)
When I address girls as "madam", no one is offended or considers themselves
"French slut", so I switched to a purely neutral tone.
And I don’t sulk at myself, I don’t sulk at anyone for a long time - it gets boring quickly %)
Of course, I understand that I offended her by asking her to provide confirmation of my words,
but, it should be noted, we constantly offend each other here, and with you personally
so through the post directly %))
Hello, acidrain
aci> Ask, and ask the girl Lena (well-searched not only in
aci> amiga, but also PC and zx) - I think she will answer competently...
Ok. Questions may have been asked here before, but I didn’t see the answer to them.
or missed it
To you (all about Amiga):
-is mutual operation of modules supported - import-export?
functions
-is data export/import supported?
since the issue of relocation is not there, another question
-interfaces are hard-coded in the form of function indexes. symbolic links
is there?
maybe I'm asking questions without understanding the subtleties of structure and organization,
if possible, try to use parallels with existing ones
developments on the same PC.
Lena:
-I'm still waiting for an answer on the topic of automatic exclusion of unused functions
when compiling with Alasm :)
-if possible, you can answer questions for acidrai
Hello, acidrain
aci> Read it again, tell me where am I wrong?
What is wrong is that by denying what ALREADY exists, you are not offering anything in return.
Because your proposals are from the series “but on the Amiga...” (despite the fact that the PC is closer to
speck both for accessibility and for architectural reasons) or morally
are outdated because they do not provide proper functionality.
I remind you about post 228 (and not only for you)
Hello, acidrain
aci> no, you didn’t offend me =) read post N217 again, ok? =)
Well, how did you not offend? Constantly demanded argumentation%)
And regarding post 217, I noted the link, I’ll read it later. Download the emulsion and give it a try
I don’t have the opportunity - I just physically don’t have the time.
(in a whisper) Are moderators deleting posts from here? There's probably so much garbage already
accumulated that the removal of one or two piles is not particularly noticeable...
I return once again to the topic of the Amiga. Since I don’t know about it, I haven’t studied it
opportunity, I will ask you specific questions. Is it coming?
Hello Vitamin
Vit> What, do moderators delete posts from here? There's probably so much garbage already
Vit> has accumulated that the removal of one or two piles is not particularly noticeable...
Apparently the database crashed again and they rolled up a backup. Look at the writing counter
messages at home. I was missing about 70 pieces.
Hello, acidrain
aci> To say so is not correct on your part
And I didn’t write under the poke, and I won’t remember anything in connection with this. But never
I won’t say that on Ammi Pocketpetse or anywhere else there is a crap library format and a curve
programming technique, it’s a pity that it’s not symmetrical....
aci> Did you read to the end? If the amount of required information exceeds capabilities
aci> of this forum, then how do you stop posting the information? - look. because for pc
aci> did you find? and for ammi there is plenty of it.
I am against offtopic, and you continue to develop it, what kind of OOP, what CALL
by offset? This is not a Spectrum and never will be. The question is not which is better
- amiga or petse, I don’t understand at all what this has to do with the subject
discussions (as well as emulators and so on), if you have to say that here
specifically this element adopted in library programming to another
platform has a clear positive if used in a modular structure
suggested by the vitamin, then it will be constructive, everything else I think
offtopic and this is so by definition.
Please note that although I do not agree with Captain Cobalt's opinion, he has no
offtopic in this topic - at least from his point of view, he suggests modifications
the current structure of the modules (this is what I call constructive).aci> No, are you going to find fault? I said it was time for me to run - I packed everything
aci> in a few lines in a hurry.
I'm not being picky, I ask you to be careful and look at the whole thing before answering.
topic to the end. If this is difficult for you, then it probably doesn't make sense.
undertake to participate in the discussion of the topic. The first time I started reading this topic
yesterday, and before I wrote my answer, I read all 16 pages CAREFULLY
already existing thread. If you are in a hurry, be patient, choose one
a period of your time so that you can read everything and figure out what
written, and only then answer. The thread will not run anywhere and not a single valuable idea
will not sink into oblivion.
aci> Please comment constructively, without causticism, on what I wrote in
aci> that post.
I wasn't trying to be sarcastic, if I offended you, I'm sorry, I didn't do it on purpose
I don't really understand what message you're referring to, but I'll try.
guess.
I believe that libraries should include ordinary everyday
procedures to which the State Inspectorate and other things that you described do not apply. What are you doing
When writing a program, do you first of all pull the mouse interface and the GUI? I think
you know the answer yourself.
P.S. 2acidrain> It’s very unpleasant when they distort my answers and messagestaken out of context. It’s even more unpleasant when clearly asked questions are not answered.
you get an answer. I try to answer all questions to me, once again
I just have to regret that it is not symmetrical...
Hello, captain cobalt
cap> And when there is one version of C, is it possible if the import graph has glued ones
cap> branches, collect the result with one instance of C?
cap> And, Vitamin?
This was a technical solution; in general, the programmer should not care
issues of libraries and their versions, in the specifications for existing libraries
The required version of the libraries must be specified.
If the primary level - the caller does not use it, he doesn’t care what happens
A and B are glued together, that's all I meant.
aci> Now think about this. Amiga appeared in 1985.
If you continue this way, I will complain to the moderators that you
too much offtopic - almost every message of yours has references to the Amiga
or PC, enough already.
aci> WHEN did I say that the libl format is the go-to format on PC? Or in Linux? To you
aci> it seemed like it! I argue that we need to think differently, and not like everyone else. Y'all
aci> think like on PC. And some see how to implement this without
aci> focusing on pc. And less resource-intensive.
And again PC, and again nothing of substance.
aci> and you too. you still haven't answered the question
I answered the question, read more carefully. If I answered the wrong onethe question is, it’s your fault - that’s how you addressed it to me.
aci> I didn't hear your question. Questions from vitamin - he doesn’t read that
aci> they write to him. stubbornly continues to repeat
Gri> Excuse me, but on what platform should I run the Amiga emulator? On ZX? Or
Gri> On x86? Then what is this - offtopic? And what does Amiga have to do with it? How in general
Gri> is the Amiga emulator related to the current discussion?
Here is my question, to which there was no answer and since you are again inattentive
you are reading. Vitamin reads carefully and I read carefully and just like he doesn’t
I understand - and my misunderstanding is expressed in the questions given to you.
aci> and in the post http://zx.pk.ru/showpost.php?p=61553&postcount=229 I
aci> wrote
I re-read this post 10 times, and still don’t understand anything there, in fact, apparently
We were in a hurry and didn’t have time to formulate our thoughts, so maybe you could explain your
proposal?
aci> wrote that we will move away from PC and Amiga
Hym... and who went to the PC and Amiga?
aci> By gui I meant the intuition interface for creating windows
aci> and primitive gadgets. From our lists, the only expense was that
aci> I offered the mouse and keyboard, but you only offered the keyboard.GUI is a little different, but that's my opinion. Let it be so, then even more so
I don’t understand why there was a list that I already indicated?
Hello, captain cobalt
cap> Library B used C1.0.
Yes, I understood the example
However, you can use a modular structure to bypass this point -
It seems that this has already been discussed here - assemble module A with C1.0 and B with C2.0 - in
As a result, two modules will be released - extended A and extended B, and it is natural that
this kind of perversion is only needed if someone does it on purpose or not
provoked the specified collapse of libraries by version.
cap> Only the “core” and “levels” are not needed, but there are just modules.
The fact of the matter is that a simple linker system can develop into a whole
system, as was the case with is-dos (that’s what you’re referring to), but vitamin
simply offers a system to make efforts easier.
cap> I'm just expressing an idea.
cap> Look, Vitamin says that “does not contradict.”
Then this is constructive %-)))))))
Hello,GriV
Gri> Here is my question, which was not answered and since you are again
Gri> you are not reading carefully. Vitamin reads carefully and I read
Gri> carefully and just like him I don’t understand - and my misunderstanding is expressed in
Gri> questions given to you.
Gri>
How would you like to answer it? what's the question?
Hello,GriV
Gri> If you continue this way, I will complain to the moderators
forward! I'll be glad. a place to pour nothing more. walk! kindergarten to God.
seven attacked one...
Hello,GriV
Gri> But I will never say that the ammi poketpetse or somewhere else is nonsense
Gri> library format and crooked programming technique, it’s a pity that this is not
Gri> symmetrical....
WHEN did I say that the Libl format was missing on PC? Or in Linux? You imagined it! I
I affirm that we need to think differently, and not like everyone else. You all think like crazy. A
some see how to implement this without focusing on PC. And less
resource-intensive.
Hello,GriV
Gri> I ask you to be careful
and you too. You still haven't answered the question posed. I don't read nonsense about
OOP on spec and so on. I already have something to do.
I didn't hear the question from you. Questions from the vitamin - he doesn’t read what they write to him.
stubbornly continues to repeat. and in the post
http://zx.pk.ru/showpost.php?p=61553&postcount=229 I wrote that we will move away from the PC
and amigas. made an assumption about how I understood the vitamin and how I would like it
see on spec. But what came from you was nit-picking and a clear disregard for everything
what is written there.
It says that why dynamic linkers when it can be simpler. I'm waiting
answer. By gui I meant the intuition interface for creating windows and
primitive gadgets. From our lists, the only expense was that of a mouse and keyboard
I suggested, and you only offered Klava.
Hello Vitamin
Vit> (despite the fact that the PC is closer to the spec both in terms of availability and
Vit> architectural considerations) or are morally obsolete, because not
Vit> provide proper functionality.
Bent! Outdated? I say (I even cited an article) that it is developing, it is not outdated.
Let's really draw analogies with PC and spec.
Now think about this. Amiga appeared in 1985. At her disposal
were: 7.14 MHz percent, chipset. But at the same time, this whole thing worked and works at times
faster than on pc. Where was Windows in 85? What did she look like? What kind of
libli? And on the Amiga there was already real multitasking, the notorious autoconfig
(which appeared on PC in the form of plugandplay in the 90s) and multimedia. All this
at 7 MHz!
How are you going to implement functionality with PC on the spec? are there resources?
Hello Vitamin
Vit> -is mutual operation of modules supported -
Vit> import-export functions
Vit> - is data export/import supported
Vit> since the issue of relocation is not there, another question
Vit> -interfaces are hardcoded in the form of function indexes. symbolic
Vit> are there any links?
Vit> maybe I'm asking questions without understanding the subtleties of the structure and
Vit> organization, if possible, try to use parallels with
Vit> existing developments on the same PC.
1 - module? what export? Where?
2 - where? If you're talking about signals and messages, then it's easy.
http://www.totalamiga.org/pdf/totalamiga_18.pdf pages 24-26 a little
touch on this issue.
3 - only super savvy programmers like Stingray can remember all the inputs
Libl by offsets. And everyone else (including me) uses inclusions and headers.
See also archive. it's not complete. I don't think it's necessary anymore. a reasonable person will understand
what's what. These are inclusions for ASMA. I don’t send for si - they don’t differ much.
And the source code, which was clear how to apply.
File: gezya_de+.zip http://zx.pk.ru/attachment.php?attachmentid=3960
Hello Vitamin
Vit> 1. If one module wants to use the functions of another, it must do so
Vit> connect via the download function and use further via the handle?
Vit> 2. Not signals (they are also functions, by and large), but data.
Vit> Sprites are there, fonts, texts.
Vit> 3. No, that’s not what I’m talking about. Some images are stored inside the binary file
Vit> symbolic names of exported functions or bare code?
Vit> I’m reading a magazine. Interesting, beautiful. You indicated the pages in PDF or
Vit> magazine?
1. yes
2. I can’t imagine how dos librari will need graphix librari. the point is
that these are not modules, but libraries, but call them whatever you like. like the program, exchange
via messages, signals, stack. just why?
3. binary - code.
PDF pages.
Hello, captain cobalt
cap> Proven.
cap>
Do you have enough? There was no evidence - only unfounded. What's faster in Windows?
Hello, captain cobalt
cap> A direct subroutine call command is faster than an indirect command with expense
cap> registers.
I agree. and how many operations before this direct call? on spec I mean?
Hello Vitamin
Gri> Still, you didn’t read the modules, that’s why you say this.
I'm just expressing an idea.
Look, Vitamin says it “does not contradict.”
Gri> Some kind of sophistry...
Gri> That's not what I was telling you about.
Gri> First of all, if someone wants to use one repeatedly
Gri> module located resident in memory, then a control system is needed
Gri> modules - centralized - to which everyone will obey
Gri> applications.
Dynamic linker.
Loader.
What else do you need?
Gri> A module is a READY program with export points when it is implemented
Gri> linker, then it became one with the initializer program
Gri> and tearing it away from the program is akin to trying to tear out a stalk
Gri> fruit-bearing apple tree from the wild after they have taken root for 10 years - you
Gri> you will simply kill both without any result.
Let's try to explain it differently.
Some modules use other modules. All modules as a whole form a hierarchy.
Higher level modules depend on lower level modules. But modules
lower levels do not depend on modules of higher levels. The program depends onlibraries. But the library does not depend on the program.
If this makes it clearer, we can number the levels of the hierarchy. For example in
iS-DOS "kernel levels" are numbered. And there is a documented way
dump the top few levels to free up memory. Some are heavy
programs do. In this case, the lower levels do not die.
Now let's say we have a dynamic linker. Everything is exactly the same. Only
"core" and "levels" are not needed, but there are just modules.
Gri> In any case, this program will be on the conscience of the programmer who runs it
Gri> wrote. Usually a set of libraries are not contained within themselves
Gri> is inconsistent, which means that “crooked” modules will be associated with
Gri> with the crooked hand of the one who wrote the text. In addition, if the library is version C
Gri> 1.0 and 2.0
It was like this.
When the programmer wrote his program, library B used C1.0.
And only after that the developers of B released a new version compatible with
previous one, but using C2.0. It's not the programmer's fault.
That is the point of this example.
Version compatibility at one level is intransitive across several levels.
Gri> I want to assure you that there is a very good one - cooperative with a mechanism
Gri> pseudo-evictions.
We need a press release for the people. :)
Hello Vitamin
Gri> assemble module A with C1.0 and B with C2.0 - as a result there will be two modules -
Gri> extended A and extended B
Wow!
And when there is one version of C, is it possible if the import graph has glued branches,
collect the result with one instance of C?
Eh, Vitamin? :)
Hello Vitamin
aci> 2. who told you? this is not z80 or x86.
Okay.
The command system is actually better suited for such calls.
But NOP is two bytes. :) And the commands have different lengths. :)
Briefly speaking.
This approach is not suitable for "poor processors". Right? Then why
there is so much talk about him.
aci> How many registers do you need to transfer data? 1 register out of 16 32
aci> bits available at the time of transition - is this a lot?
The register value is killed.
It is not necessary to pass the argument.
Maybe we just wanted it to store a number and not get corrupted by a call.
Hello Vitamin
aci> And some see how to implement this without focusing on PC. And less
aci> resource-intensive.
More resource intensive at runtime. Proven.
Now we can only compare the resource intensity of the layout. If we didn't
could wait until the layout was finished - that would have been a problem. :) But this is not so.
And after linking, we can enjoy fast code.
Are there other facts besides “visions of resource intensity”?
Hello Vitamin
aci> What's next? There was no evidence - only unfounded.
A direct subroutine call command is faster than an indirect command, consuming registers.
Hello Vitamin
aci> It says that why dynamic linkers when it can be simpler.
aci> Waiting for your answer.
I'll quote myself from another thread:
cap> 1. Relocability is the patching of CALL relative to its base
cap> module
cap> 2. Dynamic linking is patching CALL relative to the base
cap> of another module
If there is relocation on the Amiga, then why is there no dynamic layout, but instead
her "loaders" and "post-compilers"?
Hello Vitamin
aci> I agree. and how many operations before this direct call? on spec I have
aci> in view?
Which operations exactly? Dynamic linker operations or operations
compiled program?
For any given module, the build time is limited by a constant.
The saved cycles tend to infinity if the operating time
the linked code tends to infinity.
Over a finite time, the saved cycles can completely cover the initial
expenses.
Hello Vitamin
elf> there is an old but very necessary program that requires main.lib.1.0
elf> installed a new program that needs main.lib.10.4
elf>
elf> how can a programmer solve this problem?
In my opinion, the ultimate goal of dynamic linking is to eliminate as much as possible
duplication of functionality.
Let us remember once again that almost all the code on the spec has been polished. You just need to roll it up
him to the library.
The answer to the question is that the “old program” needs to be corrected.
Vit> I'm still waiting for an answer on the topic of automatic exclusion
Vit> unused functions when compiling using Alasm :)
There is nothing in my materials. What does the maintainer say?
But this has been in ZXASM for ten years now;
>; The most useful directive is IFUSED
> which allows you to create libraries
> subroutines in source assembler
> texts, so from the entire library
> only those routines will be compiled
> frames to which conversion was carried out
>
Hello, acidrain
aci> 1 - module? what export? where?
aci> 2 - where? if you're talking about signals and messages, then it's easy.
aci> http://www.totalamiga.org/pdf/totalamiga_18.pdf pages 24-26
aci> touch on this issue a little.
aci> 3 - only super savvy programmers like Stingray can remember
aci> all libl inputs by offsets. And everyone else (including me) uses
aci> includes, headers. See also archive. it's not complete. I think not anymore
aci> necessary. a reasonable person will understand what's what. These are inclusions for ASMA. for
aci> I don’t send them - they don’t differ much.
1. If one module wants to use the functions of another, it must
connect via the download function and use it further via the handle?
2. Not signals (they are also functions, by and large), but data. Sprites
there, fonts, texts.
3. No, that’s not what I’m talking about. Some images are stored inside the binary file
Symbolic names of exported functions or bare code?
I'm reading a magazine. Interesting, beautiful. Did you indicate PDF or magazine pages?
PS. I’ll sarcastically note that the interface is copied from a Mac ;) So don’t push
about imitation. I'll also look for Macintosh binaries, what's available, and
I'll look there again! :))))
Hello, acidrain
aci> I can’t imagine how DOS librari will need graphix librari. case
aci> is that these are not modules, but libraries, but call them whatever you like. like
aci> program, exchange via messages, signals, stack. just why?
Simply because you think in different categories. What do we have in case
multitasking OS?
-shared libraries
-reentrant functions inside
-since library code instances formally belong to different processes,
For communication, special methods are used, such as the same signals and messages (which,
by the way, copied from UNIX of various reincarnations, albeit in a simplified form)
What do we have on spec? No OS! And this gives some advantages
(disadvantages belong to a different category, I won’t point them out):
-the library is used by only one process
-functions do not need to be reentrant
-communication between program sections is carried out by direct calls with transmission
parameters.
So, for example, we take a hypothetical module for the Amiga and try it
drag and drop onto the spec as some kind of universal binary storage format
data.
First of all, we cut off the fucking kernel - why is it inside a solid piece of code?
do you need extra transitions? Okay, this approach is still justified for implementation
plugins, and even then, that’s debatable.Next. On the Amiga, a relocating code is not required at all. Flag in her hands, Spectrum
cannot boast of this, so we will have to somehow store information for
code settings for specific addresses. There are a lot of methods.
Next. Expansion of functionality is carried out not only due to
export/import functions, but also data. Encapsulation is of course good, but it is necessary
so that you can do without it. In total, we add support for export/import
variables and arrays.
And what do we ultimately get from the original Amiga module? No way! It turns out
a regular object file that supports relocation, analogues of which
exist on almost all platforms.
Hello, captain cobalt
cap> And when there is one version of C, is it possible if the import graph has glued ones
cap> branches, collect the result with one instance of C?
cap> And, Vitamin?
Common sense dictates that if two modules have functions with the same
signatures, then these modules cannot be glued together. In case of two different versions with 50%
(if not more) this is likely to happen. If we have the opportunity to endure
separate procedures, then we will take the entire newer version of the library and
Let's add there the non-conflicting procedures from the older version.
aci> Questions from vitamin - he doesn’t read what they write to him. continues persistently
aci> repeat. and in the post
aci> http://zx.pk.ru/showpost.php?p=61553&postcount=229 I wrote that
aci> let's move away from PC and Amiga. made an assumption about how I understood
aci> vitamin and how I would like to see it on the spec.
I described how I would see it on the spec in the very first post, and GriV described it also
once in a worker-peasant way in the middle of the branch. And to your _specific_ questions,
purely technical and aimed at opening my eyes to all the delights
Amiga approach, I never received an answer. Instead I got "let'sLet's forget about everything and imagine that PC doesn't exist." He's not stupid either
They came up with it and under DOS there were object files and relocation.
aci> It says that why dynamic linkers when it can be simpler.
It’s easier, as far as I understand, to load ready-made compiled code blocks,
nailed to a specific address, but in kernel at the beginning?
Hello Vitamin
Vit> And on each platform it will generally be its own
Vit> architectural differences.
I’ll say more, for two different applications these files will also be different :)
Once again, the object file format depends on the compiler. for example compilers
Borland and ms for Windows use different format extensions.
Hello Vitamin
Vit> And what do we ultimately get from the original Amiga module? No way!
Vit> This produces a regular object file that supports relocation
Vit> analogues of which exist on almost all platforms.
such a small comment, object files are not related to the platform at all,
this is a “feature” of the development environment (compiler + linker)
Hello Vitamin
Vit> The result of running gcc without parameters is the file a.out, which
Vit> can be launched immediately. Add a key - we get dynamic
Vit> library, another key is static, the third is an object file
Vitamin, are you kidding me? okay, let's get away from the stove... any reasonable program has
dependence at least on the run-time library (libc on Linux, msvcrt on
Windows). since modern compilers "think" about the user they allow
call the linker automatically. those. program to compile into an object maker (I think if
try, you can notice that the .o file is created in the current directory) and in one fell swoop
is called a linker in order to link with runtime. similar with
dynamic library (only run-time will be different). and static
a library is just a set of packaged objects
Hello Vitamin
Vit> Controversial statement. An object file can be understood as
Vit> binary - intermediate result of the compiler, and finished
Vit> executable file or library
you can understand anything by anything :) but it just so happens that object
file is an established term (at least for pisyukans :)). at least
At least I always believed that the object code is the result of the compiler’s work (in the format
REL, OMF, whatever) which cannot even be theoretically executed because
external links are not yet allowed. from the set of these semi-finished products linker (ln,
link, sometimes the compiler itself) assembles the executable binary/dynamic
library
Hello, acidrain
aci> 2. I can’t imagine how DOS librari will need graphix librari.
aci> the thing is that these are not modules, but libraries, but call them whatever you want.
aci> like a program, exchange through messages, signals, stack. just why?
vitamin asked if it was possible to store resources inside the library: icons, lines and
etc.
Well, is there a unified way to get them from there?
why is this necessary? a couple of examples:
1. Several programs use the same "open file" icon.
2. we want a program with a localized interface. we make a library that
stores only message texts. will accordingly have several resource
libraries, one for each language
Is there a standard mechanism for "sharing" resources on Ammi? (this is not a collision, but
question)
Hello, captain cobalt
cap> If the Amiga has relocation, then why is there no dynamic layout
cap> and instead of “loaders” and “post-compilers”?
what are you talking about? from the very beginning acidrain talked about dynamic layout and brought
a bunch of examples. in terms of MSDN on ammi there is "run-time dynamic linking"
Hello, captain cobalt
cap> And when there is one version of C, is it possible if the import graph has glued ones
cap> branches, collect the result with one instance of C?
cap> And, Vitamin?
I thought well here, I’ll try to put it differently, by the way, vitamin himself agrees that
It’s possible, theoretically, but in practice it’s not, but nevertheless
The meaning is this - let it have a bunch of modules - A and B
Moreover, module A has a set of public calls
public OneFunc
public TwoFunc
public ThreeFunc
Module B has public calls
public OneFunc
public TwoFunc
public FourFunc
Application P, which uses A and B for assembly, needs to use the functions
public ThreeFunc and public FourFunc (these are common functions). It would seem - modules
use conflicting function names, but P doesn't use those functions, so
assembly is possible and functions
public OneFunc
public TwoFunc
for A and function
public OneFunc
public TwoFunc
for B
will become contextually private (i.e., in general, public, but due to their
unnecessary for P, they can be made internal to modules).
As a result, the gluing will happen with a bang and everything will work.
How does this relate to the fact that A and B can use different libraries - C1.0 and
S2.0? - Yes, very simple. When gluing A with C1.0 and B with C2.0, you get A+C1.0 and
B+C2.0, and the C library is no longer needed (neither version). I emphasizeThe importance of the point is that application P does not directly use any version of C (in
In this case, you will again have to glue P with C and, for example, having received P + C3.0, knit them
with A+C1.0 and B+C2.0).
Further, for A and B there will be a list of repeating methods, which nevertheless are not
are used in P. Then you can easily make these methods context-private
and work with libraries without conflicts using methods that are
contextually public.
Hello elf/2
elf> Vitamin, are you kidding me?
No, I’m picking on words :)))
I'm a little lost on the terminology. Although I meant the object file as
blank for creating an executable application. And on every platform it will be in
in general, due to architectural differences.
Hello elf/2
elf> which even theoretically cannot be executed because of external links
elf> are not allowed yet. from a set of these semi-finished products linker (ln, link,
elf> sometimes the compiler itself) assembles the executable binary/dynamic
elf> library
The result of running gcc without parameters is the file a.out, which can be immediately
run. Add a key - we get a dynamic library, another key -
static, third - object file
Hello elf/2
elf> such a small comment, object files with the platform are not at all
elf> are linked, this is a “feature” of the development environment (compiler+linker)
Controversial statement. An object file can be understood as
binary - an intermediate result of the compiler, and a ready-made executable
file or library
Hello, captain cobalt
Let's discuss!
Hello Vitamin
The concept of "boot language" can be discussed if it is clear.
Hello Vitamin
The loading language is the language in which the object module is presented, the "format
object file". Example - a file with semi-finished machine code and tables,
indicating where to insert the values of external links into the machine code.
The dynamic linker is the executor of the loading language.
Dynamic linking is the execution of a "program" in a boot language.
The result of dynamic linking is a linked module.
The goal is to get a assembled module.
This can be done in a variety of ways, not just by patching
semi-finished product.
The most radical thing is to generate the final module one byte at a time.
So, let's assume that the object module is a program in the boot language,
completely creating the code of the assembled module.
Any ideas for such a loading language?
Here are a couple of ideas:
1. Stack machine. Can evaluate complex expressions from external references.
2. Copying pieces of code from an already generated part of the code. Like LZ77. More
compact object module.
Hello,GriV
Yeah. First of all, what is a "boot language"?
Hello, captain cobalt
cap> 1. Stack machine. Can evaluate complex expressions from external
cap> links.
This is of course good, but you will have to enter expressions in the OPC manually. Or sculpt
translator into it, which is not good.
cap> 2. Copying pieces of code from an already generated part of the code. As in
cap> LZ77. A more compact object module.
Why the hell? Let the packers do the compression!
I am generally of the opinion that the linker (that is, the executor of the loading language)
should be as simple (that is, more reliable) and lighter as possible.
Hello elf/2
elf> I’ll say more, for two different applications these files will also be
elf> differ
elf> Once again, the object file format depends on the compiler. for example
elf> borland and ms compilers for Windows use different extensions
elf> format.
Well, I wrote, in the general case. And if they are even within the same platform
differ, then even more so. There is plenty to choose from and where to look
useful ideas.
Hello, acidrain
aci> no, no. I just can’t imagine why this is necessary. although
aci> on the spec you can store unified graph objects directly in the lib. but
aci> this IMHO will greatly limit subsequent development (the difference in i-faces
aci> end user).
aci> Let me clarify - there are no obligations other than the libla format. can be done
aci> after all, storing sprites and other things would be desirable. Possible in the body
aci> libs to store anything, the main thing is that it is convenient for the programmer.
aci> But I also find some advantages in pisism. Although I still don’t see
aci> visible reasons to make spec modules so complicated
then perhaps there is another way to share resources on ammi?
Suppose there are two demos and they need to use a common table of sines...
Hello, captain cobalt
cap> Above there was a link to the warez .djvu where the concept is explained and
cap> provides a specific example of a loading language (with but without a stack
cap> compression).
I didn’t notice the link :( can I repeat it?
Hello, captain cobalt
cap> So, let's assume that the object module is a program in the language
cap> load, which creates the entire code of the linked module.
cap> What are the ideas for such a loading language?
well, I suggest using brainf*ck (http://www.muppetlabs.com/~breadbox/bf/)
or whitespace (http://compsoc.dur.ac.uk/whitespace/)
then we make a virtual machine for which this language will be native. then you have to
implement this machine in silicon and install it as a coprocessor on
ROM socket.
cap> The most radical thing is to generate the final module one byte at a time.
we need to be even more radical - one bit at a time
trouble... ban all books about abstract programming...
Vit> Why the hell? Let the packers do the compression!
compression has nothing to do with it... the author suggested using “back” links to already
generated code
Hello, captain cobalt
cap> Is this to say at least something?
no, there were two goals:
1. for the moderators to urgently move this topic to the flame. because once again
since the discussion of "spherical horses in vacuum" begins
2. provide links to interesting programming languages
the only thing that interests me within the framework of a new topic of discussion: where did you succeed
find this term "download language" and how it will be in English. the rest in
application to spec - pure theorizing
Hello elf/2
elf> well, is there a unified way to get them from there.
elf>
no, no. I just can’t imagine why this is necessary. although on spec
You can store unified graph objects directly in the library. but IMHO it's too strong
will limit subsequent development (difference in i-faces of the end user).
Let me clarify - there are no obligations other than the libla format. you can do it too
storage of sprites and other things, if desired. You can store everything in your body
anything, the main thing is that the programmer is comfortable.
But I also find some advantages in pisism. Although I still don’t see any visible reasons
make modules for spec so complicated.
Hello Vitamin
We need to publish the latest version of the signature syntax.
Hello Vitamin
Vit> What about the fact that identical pieces of code are patched differently in
Vit> different places?
Already patched code is copied.
If the code needs to be patched differently, then the code needed is created and patched
as it should.
Vit> There must be relocation/export/import tables. It’s impossible without them.
It's just a list of external symbols.
Often one symbol needs to be patched into more than one place. All these places
are listed in the patching table. So it's not needed. Every place
patching is determined by the current unpacking point.
In general, once each of the external symbols has been used at least once,
Then they can be copied from the unpacked piece, and the import table can be
rub. :)
Hello Vitamin
Vit> Do not offer another special compiler.
Then I suggest “another utility”. :)
It will take your compiled modules and package them. :)
Hello Vitamin
Vit> Do you offer a patching bitmap?
No.
Let's say we have an LZ77 unpacker. It can execute commands (with arguments):
1. Copy from input stream to output stream
2. Copy from output stream to output
3. End of unpacking.
Now we add the stack and commands to it:
4. Put the constant on the stack
5. Put the value from the import table onto the stack
6. Rewrite the number from the stack to the output stream
7. Add two numbers on the stack
Vit> Don't forget that there can be more than one modules. How are you in advance
Vit> will you provide all options for early/late use of symbols?
Vit> By the way, their relationship (external/internal) depends on the current one
Vit> of the module in question.
Okay, let's leave the import table for simplicity.
It's still smaller than the patching table we got rid of.
Hello Vitamin
Vit> This is of course good, but you will have to enter expressions in the OPC manually. Or
Vit> mold a translator into it, which is not good.
What if these values are needed? What's the alternative?
Evaluate expressions at runtime and increase client code size?
Vit> Why the hell? Let the packers do the compression!
Vit>
Vit> I am generally of the opinion that the linker (that is, the language executor
Vit> downloads) should be as simple (that is, reliable) and lightweight as possible.
Then let's try to go from the packer.
A typical LZ77 decompressor will copy bytes from the input and
output stream to output stream.
What if you teach it to calculate expressions from external symbols and write them down?
into the stream?
Unpacking and assembling can be done in one pass!
What other benefits? The approach to patching a semi-finished product requires simultaneously
keep in memory the semi-finished product, import and patching tables. Unpacking
the linker can build code directly on top of the packaged code. All you need is a regular one
for such a thing, the “gap” is ten bytes.
Hello Vitamin
elf> the only thing that interests me within the framework of the new discussion topic: where
elf> did you manage to find this term "loading language" and how it will be
elf> English.
From Soviet cybernetics of the 70-80s. :)
It probably won't work in English.
Above was a link to the warez .djvu where the concept is explained and presented
a specific example of a loading language (with a stack but without compression).
elf> the rest in the application to the spec is pure theorizing
Practice usually follows theory.
Hello Vitamin
elf> well, I suggest using brainf*ck
elf> (http://www.muppetlabs.com/~breadbox/bf/) or whitespace
elf> (http://compsoc.dur.ac.uk/whitespace/)
elf>
elf> then we create a virtual machine for which this language will be native.
elf> then you need to implement this machine in silicone and deliver it as
elf> coprocessor on the ROM socket.
Is this to say anything?
elf> needs to be even more radical - one bit at a time
Spec unpackers, such as Hrust, unpack one byte at a time, and
a packed stream is read one bit at a time in certain cases.
And they are widely used when assembling software. File size for entire memory
unpacks in one or two seconds.
elf> compression has nothing to do with it... the author suggested using "back" links
elf> to the already generated code
The result is a compact object module. Compression.
Hello Vitamin
PS. I'm standing on the asphalt, wearing skis...
Hello, acidrain
aci> But I also find some advantages in pisism. Although I still don’t see
aci> there are obvious reasons to make spec modules so complicated.
Do not complicate, but simplify.
A specific example. There is a hypothetical library of printing in 6x8 font. For
For greater versatility, it should print in different fonts. Embed binary
It is illogical to add any specific font to the module. Therefore, we declare the one used
outer dot font. And we link a module containing only the font and
exporting it as a data point. When linking we get happiness. Ferstein?
And note that the linker doesn’t really care what to glue together - a call with addresses
functions or loading with data address.
cap> Now we add a stack and commands to it:
Here. Already something concrete, more or less understandable. Another ma-a-a-scarlet
The question is: how to automate the creation of such stack modules? One more
Do not offer a special compiler. My modules are created with a bang that actually exist
compiler. And if you manage to port it, then not just one. Creating a module is not
such a common thing as its use.
Hello, captain cobalt
cap> What other advantages? The approach of patching a semi-finished product requires
cap> simultaneously keep in memory the semi-finished product, import tables and
cap> patching. The unpacking linker can produce code directly
cap> on top of the packed one. All you need is the usual “break” for such a thing
cap> ten bytes.
“Dad, who were you talking to just now?” (C)
Borsch separately, flies separately. Separately unpacking (optional), separately
layout (required).
And if you meant:
elf> compression has nothing to do with it... the author suggested using "back" links
elf> to the already generated code
then we get a regular packer (it’s far from a fact that it’s optimal and
standard). What about the fact that identical pieces of code are patched differently?
in different places?
There must be relocation/export/import tables. It’s impossible without them.
Hello, captain cobalt
cap> Already patched code is copied.
cap> If the code needs to be patched differently, then the code needed is created, and
cap> is patched as needed.
In that case, why the hell? To implement this garbage, you need to develop a new
packer Are you ready? Go ahead and sing, I'll wait with the results. You'll change it at the same time
your views on the problem.
cap> Each patching location is determined by the current unpacking point.
Do you offer a patching bitmap? It's a fixed size, obviously.
depending on the code size with a factor of 1/8. Isn't it fat? In what I propose
method, 4 bytes are consumed for each patching point, while
Links to external points are automatically supported. In this case, the size
tables are not tied to the size of the code, but depend on its structure.
cap> In general, as soon as each of the external symbols is used at least
cap> once, then they can be copied from the unpacked piece, and
cap> the import table can be overwritten.
Don't forget that there can be more than one modules. How are you in advance
will you provide all the options for early/late use of symbols? By the way, their
The relationship (external/internal) depends on the current module in question.elf> no, there were two goals:
elf> 1. so that the moderators urgently move this topic to the flame. because in
elf> once again the discussion of “spherical horses in vacuum” begins
elf> 2. provide links to interesting programming languages
Skis! Skis!!! :)
Offtopic: http://rsdn.ru/article/philosophy/languages.xml
Hello, captain cobalt
cap> Then I propose “another utility”.
cap> It will take your compiled modules and package them.
Try it. There will be two independent approaches. Let's compare and synthesize from
something new is better.
Hello Vitamin
Vit> It is illogical to embed a binary of a specific font into a module.
Vit> Therefore, we declare the font used as an external point. And link
Vit> module containing only the font and exporting it as a dot
Vit> data.
Now explain to me why it is impossible to do this: openfont from which thread? And
Why fence a garden for this? Why a separate point? You're still a chunky module
do it.
Hello, acidrain
aci> Now explain to me why it is impossible to do this: openfont from which thread
aci> libli? And why fence a garden for this? Why a separate point? You
aci> make another chunk module.
No, you explain to me why to do this
CALL OpenFont
If it can be done
LD HL,Font
?
What if the font pointer is used not in one place, but in several? Everyone
should I take it out once or store it in a special variable? I can do unlimited
load the direct pointer value into registers the number of times. And just like 2
byte, and separately high or low.
I also scolded OOP, your example is typical encapsulation, JavaBeans in some way
terminology.
What if there are a bunch of lines in the lib? You will also write your own function for each
return a pointer? Or one, but with the transfer of the index for the query? And I just
I will pull out direct pointers to lines from there by their symbolic name during
assemblies.
Hello Vitamin
Vit> Not quite like that. In the case of startup linking, the program does not need AT ALL
Vit> you don’t need to do anything to connect libs. Will do everything
Vit> linker according to the list of libs specified at the compilation stage. If
Vit> needs to be connected during operation, then by symbolic name
Vit> we get the offset in the code block and use it for our own purposes
Vit> purposes. Moreover, this can be an offset of anything - a function, a string,
Vit> array
intended! I gave an example of run-time use, because that is exactly what
applicable to ammi
Hello, acidrain
aci> Explain to me - the program needs a font to get it (open or else
aci> what) what actions do I need to do as a coder?
aci> And what other lines - what do you mean? I'm not a telepath and I can't help but
aci> seeing you live, understand what you mean? Of course I understand
aci> why are you also gesturing behind Monique, but I don’t see
let me try to explain... there is a lib, it says something like:
-+----------------
sin_table db 00h,ffh, ...
db 55h, aah, ...
font db 00h, 00h, ...
strings db "Hello, world!",ffh,"Welcome!",ffh
__export dw sin_table, font, strings
-+----------------
in the program we load this library, get its handle and:
ld de,
ld hl,
call get_addr
we can get the addresses of sin_table and strings in the same way
although on spec it would be better to use indexes or indices rather than names
identifiers
Hello, acidrain
aci> @ griv - you are always everyone
aci> you teach (http://zx.pk.ru/showpost.php?p=12438&postcount=22), and then
aci> flame (your post
aci> http://zx.pk.ru/showpost.php?p=61813&postcount=305 - not at all
aci> you'll get it, like a flame)
Yes, I’m like that ((((-; and I also constantly put emoticons :-D
Let's introduce a specific norm of flame messages per thread :-D and an allowed norm
offtopic :-D
And they also accused me of clinging to words :-D
Will you ever read the documents that vitamin sent you? ;-)
Hello, acidrain
aci> No. No need. when I port it to spec (...), then
aci> I will, although it’s unlikely. =) 8)*-) ))));-P Enough emoticons?! It's not a coincidence
aci> flame section??? Remove me! Ban me! 8)
Have you lost your voice, duh? :-D
Some strange emoticons you have, like a child or a cat walked across the keyboard
:-D And in general, we are terribly mourning the loss of a cool guy on the Spectrum platform
Amiga coder m/ :-D
I think your request is feasible :-D
Hello, acidrain
aci> Apparently I explained it poorly, or did you, how did the mane tell you?
aci> I can’t understand you, and you seem to be from different planets, although it seems
aci> you are also a southerner. Explain to me - the program needs a font to get it
aci> (opening or something else) what actions do I need to take, how
aci> coder?
aci> And what other lines - what do you mean? I'm not a telepath and I can't help but
aci> seeing you live, understand what you mean? Of course I understand
aci> why are you also gesturing behind Monique, but I don’t see
Just read what you wrote, I was even stuck on the first sentence :-D
You probably once explained it well, but we were unlucky, because we
didn’t see it (((((((-;
By the way, what planet are you from? :-D
Hello elf/2
elf> let me try to explain... there is a lib, it says something
elf> type:
elf> ------------------
elf> sin_table db 00h,ffh, ...
elf> db 55h, aah, ...
elf> font db 00h, 00h, ...
elf> strings db "Hello, world!",ffh,"Welcome!",ffh
elf>
elf> __export dw sin_table, font, strings
elf> ------------------
elf>
elf> in the program we load this library, get its handle and:
elf> ld de,
call
Hello,GriV
Gri> Will you ever read the documents that vitamin sent you? ;-)
Gri> __________________
No. No need. when I port it to spec (...), then I will, although
Hardly. =) 8)*-) ;):)))));-P Enough emoticons?! Is this not a flame section by any chance???
Remove me! Ban me! 8)
Hello Vitamin
Vit> What if there are a bunch of lines in the lib? You will also write for each
Vit> your pointer return function?
Apparently I didn’t explain it well, or did you, how did the mane convey it to you?
I can’t understand you, and you me - apparently from different planets, although it seems like you too
Southerner. Explain to me - the program needs a font to get it (open or else
what) what actions do I need to take as a coder?
And what other lines - what do you mean? I'm not a telepath and I can't not see you
Do you really understand what you mean? Of course I understand that you are still behind Monique
and you gesture, but I don’t see :v2_rolley
Hello Vitamin
Vit> If possible
Vit> LD HL,Font
Vit> ?
Vit> And if the pointer to the font is used not in one place, but in
Vit> several? Each time take out or store in a special
Vit> variable? I can download direct an unlimited number of times
Vit> pointer value to registers. Moreover, both 2 bytes at once, and also
Vit>separately senior or junior.
Let me explain - if the font was opened once by someone, then any process (program, like
whatever) can use it. What's wrong with this? How do you imagine
imagine that you have a font, a linker (firmware, have you heard of this already? =)
and the program that wants to use it - what actions does the bootloader need to do,
so that your program just contacts directly?
Hello Vitamin
Vit> Give an example of “someone” who will open these fonts so that the program
Vit> could have used them.
Vit> Just in case, I remind you that our platform is called Spectrum and
Vit> there is no OS and no multitasking.
http://zx.pk.ru/showpost.php?p=61553&postcount=229
Vit> all the utter coolness of Amiga.
I haven’t said anything about the Amiga and PC for a long time - I’m talking in relation to the spec. me
It’s a pity that you never caught up, and your one-place lisses didn’t catch up. You (read
PM)
Hello, acidrain
@ griv - you are always everyone
you teach (http://zx.pk.ru/showpost.php?p=12438&postcount=22), and then you flame
(your post http://zx.pk.ru/showpost.php?p=61813&postcount=305 - not at all
you'll get it, like a flame)
???
Hello, captain cobalt
cap> each time a library function is called, select its address from the table
cap> via handle.
No, not from the table! Are you still reading?
Hello Vitamin
Vit> Along with the module code, a special link code is generated
Vit> which builds and writes to disk. As a compromise - quite
Vit> sane.
Sane.
Consensus.
Hello Vitamin
aci> Apparently I explained it poorly, or did you
I'll explain. :)
On the Amiga there is such a tradition - every time you call a library function, select
its address from the table through the handle.
Is there such a tradition for accessing data from another module.
Hello Vitamin
It is important that this goes into the import tables.
For legacy assemblers, you can do something like this. In the import table
Full names are entered. And in the source code internal names are used (without
dots), which refer to the import table.
Hello Vitamin
Another point on which consensus is needed is how to qualify external names.
There are these options:
1. ModuleName.ProcedureName. Example:
CALL KB.ReadKey
2. Just the name of the procedure.
Less to write, but name conflicts.
Hello Vitamin
Existing assemblers do not know how to assemble basic files with monoloaders and packaging
code.
Utilities like mkace are used to automate this.
It is necessary to focus on existing assemblers.
There is no need to focus on their limited abilities.
And the question is - how to qualify external names?
Hello, acidrain
aci> Let me explain - if the font was opened once by someone, then any process
aci> (prog, whatever) can use it. What's not to like about this?
Give an example of "someone" who will open these fonts so that the program can
use.
Just in case, I remind you that our platform is called Spectrum and there is no
OS and no multitasking.
aci> Do you imagine that you have a font, linker (firmware,
aci> heard, have you already reached this point?=) and the program that wants to use it -
aci> what actions does the bootloader need to do so that your program is simple
aci> contacted directly?
A linker in one module detects a link to an external point and looks it up in a table
exported assembly points. If it finds it, it substitutes the addresses. That's all.
aci> I can’t understand you, and you seem to be from different planets, although it seems
aci> you are also a southerner. Explain to me - the program needs a font to get it
aci> (opening or something else) what actions do I need to take, how
aci> coder?
You probably didn’t read the documentation that I sent you and gave you the link.
on topic.
This is what the module looks like:__EXTERN "Font",font ;declare the external point and its internal alias
..
LD_ HL,font ;the linker will substitute the real font address here when
will collect
...
LDH_ H,font ;and here only the high byte
And there can be as many such points using an external symbol as desired.
aci> And what other lines - what do you mean? I'm not a telepath and I can't help but
aci> seeing you live, understand what you mean? Of course I understand
aci> why are you also gesturing behind Monique, but I don’t see
Regular strings, a sequence of bytes representing text in some form
encoding Explain what encoding is?
I don't gesticulate behind Monique, I just grin, feeling like the most pathetic of all.
the last lamers, because it’s not possible for me to understand all the utter coolness of the utter Amiga. A
You explain and answer questions only when they specifically attack you.
Hello, acidrain
aci> Quote:
aci> Message from Vitamin
aci> Give an example of “someone” who will open these fonts so that the program
aci> could use them.
aci> Just in case, I remind you that our platform is called Spectrum and
aci> there is no OS and no multitasking.
aci> http://zx.pk.ru/showpost.php?p=61553&postcount=229
And you know what you gave and suggested as an example? Applications that work
pulls behind it an entire single-tasking OS-library manager (which without much
needs if a plugin system is not used). I fight even with (like you
expressed himself)
aci> Lisa's one place
to reduce this extra weight to a minimum while maintaining functionality.
aci> I'm sorry that you never caught up
And what have I not caught up to? That it is simply brutally necessary to pull the whole axle from
every application? That kernal and nailed addresses are the last
the squeak of fashion?
But you haven’t caught up with anything at all. And I didn’t even bother to read what I told you
I sent it 20 pages ago.
Hello, captain cobalt
cap> 1. ModuleName.ProcedureName. Example:
cap> CALL KB.ReadKey
Now try using the name with a dot in different assemblers. Give me a list
those who suck at it
Hello, captain cobalt
cap> Utilities like mkace are used to automate this.
cap>
cap> It is necessary to focus on existing assemblers.
cap> There is no need to focus on their limited abilities.
cap> And the question is - how to qualify external names?
Along with the module code, I generate a special linking code that
builds and writes to disk. As a compromise, it’s quite sane.
By implying the existing assembler, we also imply its limited
abilities... Qualify external names exactly as you have already written and
as I did - defining an alias at compile time, I was just very
I was confused by the use of a direct name with a scope right in the source %))
Hello, captain cobalt
cap> For legacy assemblers you can do something like this.
What are "legacy assemblers"?
Let's first focus on existing assemblers, shall we? And then
write additional utilities as planned
Hello elf/2
elf> is intended! I gave an example of run-time use, because
elf> it applies to ammi
Uh-huh. And if anyone wants to use the kernal, then we do everything as usual and
we prohibit the generation of symbolic names (in this case, symbolic links to
there should not be external points either). All that remains is the relocation table for
settings.
Hello elf/2
elf> in the program we load this library, get its handle and:
elf> ld de,
elf> from the library>
elf>
elf> we can get the addresses of sin_table and strings in the same way
elf>
elf> although on spec it would be better to use indices or indexes rather than names
elf> identifiers
Not quite like that. In the case of startup linking, the program does not need ANYTHING
must be done in order to connect libs. The linker will do everything according to the list
lib specified at compilation stage. If you need to connect either during
work, then using the symbolic name we get the offset in the code block and use
him for his own selfish purposes. Moreover, this could be a displacement of anything -
function, string, array
Hello, captain cobalt
:-D in Amiga - yes
in modules - no, there is no kernal in modules :-D
Hello Vitamin
aci> No, not from the table!
Where?
aci> Do you still read?
Yes.
Hello Vitamin
Jumping into the kernel?
Hello, captain cobalt
cap> From?
Implicitly calculated by multiplying the function number by a constant and adding
starting address of the library kernel.
Hello Vitamin
Another idea.
Make it possible for procedures from one module to be inlined into another
module.
With parametric settings.