opinion poll

Hello, All Do you think dynamic linking of code makes sense? within the ZX-Spectrum platform: 1) very important and needed anywhere 2) makes little sense in specific tasks 3) can be used equally with static linking 4) no one in their right mind uses this at all

Hello jtn makes sense only in specific cases because sometimes it’s really hard without it. however, in all other 90% of cases there is no need for it.

Hello fk0 4th option. who was talking about the votka?

Hello Sinus 3 point. Loading of drivers and plugins is usually used - which is not dynamic Likovka?

Hello jtn jtn> 4th option. who was talking about the votka? Programs for ZX-Spectrum in most cases use static layout of program code. In most cases, but not always. Let's consider the options when static linking is not applicable: * using functions located in ROM is, in fact, dynamic association, linking, program code with a library located in ROM; * use of driver programs, for example HDD driver; * use of plug-in programs that extend functionality main program; * connection of the application program with OS functions. These are the main ones, but not all cases when using dynamic layouts are inevitable. There are also cases where the use dynamic linking is not mandatory, maybe not even widespread practiced, but in general it would be useful, in particular this library programs. Practical benefits of dynamic linking lies in the possibility of independent modernization of each part jointly linkable code. For example, the library can receive some advanced functionality, bugs may be fixed and etc. Static linking is traditionally used to combine program code modules of one program, as well as for inclusion in program of library functions (at the compilation stage).In general, we can say that both layout methods are currently time is used and important. Discard any one method in favor of another is impossible.

Hello jdigreze jdi> fk0, your understanding of dynamic linking is incorrect... jdi> The very concept of “Dynamic Linking” or “Dynamic Linking” jdi> implies building a library or program after loading into jdi> memory, before execution. In this case, all pointers to are rebuilt jdi> procedures, this is DYNAMICS. And the use of ROM functions jdi> is just a static link, since the ROM is not linked in principle jdi> ;) And all its procedures are always located AT STATIC addresses. jdi> But no. All procedures for a SPECIFIC VERSION of ROM programs are coded to specific static addresses. And the addresses of the procedures any programs located in ROM are generally UNKNOWN, because they tend to change from time to time. Yes, and according to your definition of “assembly after loading in memory" fits very well with ROM in the sense that assembly of *all parts* of various programs is carried out after loading them into memory. In the sense that that one from the disk, Once it is loaded, then the layout will take place. Before that programs exist only separately. And besides, the process of installing a new ROM chip into the socket,with a new version of programs - this is also, to some extent, a “download”. > And the difficulty of implementing true dynamic linking is related to > limited resources of the spec, since the assembly must > produce some kind of download manager, after which, upon request > user programs, BY NAME, call the desired procedure > regardless of where he linked this procedure... > Firstly, I don’t see a logical connection. Like having a manager due to limited spec resources. Secondly calling functions of loaded procedures using a certain function manager is just one of the methods. There are and others that involve a direct call in one way or another. > Well, we need an OS that will manage resources... This is a problem without an OS > not solvable... Well, yes, of course. And a mouse with windows for it. And Open-GL is a must. Otherwise without Tuxrace and Quake-III won't do anything...

Hello fk0 fk0> And the addresses of procedures of any programs located in ROM, in general fk0> case UNKNOWN, because they tend to change from time to time. fk0> I agree, this is a good example, but it only addresses a special case using that part of the ROM that relates to TR-DOS, and I would not take it for rule... fk0> First of all, I don’t see a logical connection. How does having a manager relate to fk0> limited spec resources. From the personal experience of implementing managers... Not everything is so simple. It's even possible to say that it is not very easy... Let me digress a little to make it clearer. Have you personally seen it on the Spectrum? linker? I saw... In IS-DOS... Nowhere else :) Do you know why they are not there, how those? Because the "FLAT" memory model is ALWAYS used. For which, Using a linker is a waste of machine resources. But let's return to the manager. Dynamic memory allocation, in particular for loading the library should look something like this: 1) prog (dynamic link manager) accesses the memory manager: “Brother, you need a piece of memory of 123 bytes!” 2) the memory manager must decide whether there are so many resources? 3a) if there are no resources, then the answer will be something like: “Go on... route default"...3b) if there are 123 bytes, it must “bite them off” from the free space, allocate a unique ID to this piece, write in your plates what is for this ID is a reserved piece of 123 bytes, in such and such a bank, at such and such an address, and issue ID at the output... Then, the linker, in order to access this section, must contact to the RAM manager, like “let me work with this piece...”. And when linking there will be... well, quite a lot of such calls... :) I may be complicating things... But SO CORRECT! in general... everything else will be a special case of the general one. fk0> Secondly, calling functions of loaded procedures using no one The fk0> function manager is just one of the methods. There are others fk0> implying a direct call in one way or another. In any case, the call must be direct, i.e. indirect when launch happens according to, say, the contents of HL... But, before you launch procedure, you need to set the configuration of the machine, the banks there, and so on... fk0> Well, yes, of course. And a mouse with windows for it. And Open-GL is a must. fk0> Otherwise, without Tuxrace and Quake-III, nothing will go anywhere... :) There's a lot of this goodness... P.S. There is no need to try to create an analogue of big brother! Spectrum is still aliveonly thanks to the fact that everyone can write “what they want”, and most importantly - "AS HE WANTS." Attempts to force everyone under IS-DOS back in 95 did not lead to anything good brought... Because this is a general case, but there were not enough resources for specific ones... And also Speck is a hobby car. And it should bring joy, not suffering.

Hello jdigreze jdi> I agree, this is a good example, but it only addresses a special case jdi> using that part of the ROM that relates to TR-DOS, and I would not jdi> took it as a rule... It's not true, there is still inertia in ROM - programs use direct calls SOS ROM procedures - and if they were configured on the fly - then the system would be much more productive - we are now (and, by the way, for quite a long time) able to write the same ROM code but faster, more reliable and more compact, but try this do - and more than half of the programs will refuse to work for you, so TR-DOS and SOS - almost the entire set of ROMs that a standard Speck has - you can already talk not about a particular example but about a pattern ;)

Hello jdigreze Actually, I answered that dynamic linking is always needed and here’s why. First of all, I see the role of dynamic linking not only in call binding functions but also binding the memory location where the program was loaded to its internal addresses (i.e. a module that is dynamically linked must also be we relocate as well). This gives me the opportunity to write (my blue dream is I sleep and see ;)) - multitasking OS with pseudo-corporate use resources. Without dynamic linking and configuration by addresses in the OS it will be very difficult work with memory resources - there will simply not be enough of it (as indeed and all other resources).

Hello,GriV I won’t argue, but I’ll stick to my opinion. Since the cases under consideration are are only partial from the general concept of dynamic linking. which implies that the programmer does not need to know how his program works with library, and what version of this library is currently available for use. I am not opposed to implementing special cases of dynamic linking, since, in relation to the Spectrum, to implement according to the rules all possible combinations, if possible, are not advisable. :) That's why my vote is for "makes sense only in specific cases."

Hello jdigreze jdi> I agree, this is a good example, but it only addresses a special case jdi> using that part of the ROM that relates to TR-DOS, and I would not jdi> took it as a rule... jdi> The case is quite abstract, where a certain one program located on one medium (ROM) and another, independent of the first, placed on the other (HGMD). And the question how should they interact? How can I find out what kind of program is located in ROM memory, what version and what interfaces it provides. In case of TR-DOS this really isn't the case. > Let me digress a little to make it clearer. You personally saw on > Spectrum linker? I saw... In IS-DOS... Nowhere else :) > CP/M - many, most programming tools. > Do you know why they don’t exist, as such? Because it is ALWAYS used > memory model "FLAT". For which, using a linker is superfluous > waste of machine resources. > Linux also always uses a flat memory model. And there is dynamic linking, and the linker itself for, for example, static linking of your programs. And what?The point is not the unnecessary waste of resources, but the availability of the original code of all compiled modules. There are only two problems here: conflict of names local to different modules and excessive symbol table size. Modern assemblers have several "jars" of memory. That's why in iS-DOS and CP/M, where there is so much memory is not available, they prefer separate assembly of small modules and their subsequent arrangement into smaller ones forces. > But let's return to the manager. Dynamic memory allocation, in > in particular for loading the library should look something like this: > 1) prog (dynamic link manager) contacts the manager > memory: "Brother, we need a piece of memory of 123 bytes!" > 2) the memory manager must decide whether there are so many resources?? > 3a) if there are no resources, then the answer will be something like: “Go to... > default route"... > 3b) if there are 123 bytes, he must “bite them off” from the free one > space, allocate a unique ID to this piece, register it in yours > signs that a piece of 123 bytes is reserved for this ID, in > such and such a bank, at such and such an address, and issue an ID at the exit...> Then, the linker, in order to access this section, must contact > to the RAM manager, like “let me work with this piece...” > And when linking there will be... well, quite a lot... :) > > I may be complicating things... But SO CORRECT! in general... > Exactly. I think you have a mess in your head. Dynamic linking and memory management are completely disjoint concepts. And as a trivial memory manager, in a system where memory basically only allocated (and released by pressing the button RESET) a stack is quite suitable, the functioning of which requires one cell memory type (void*). > The call in any case must be direct, i.e. indirect when launch > occurs according to, say, the contents of HL... But, before > run the procedure, you need to set the configuration of the machine, banks there, > and so on... > It should not, but can be both direct and indirect, I already wrote...