It would be nice to update the assembler
ZXNet echo conference «zx.spectrum»
Hello! Dear Vyacheslav!
At 17:12, Saturday April 05 1997 there was such a thing that
Vyacheslav Mednonogov scribbled down the letter All:
VM> Get msg, All!
VM> So, here are some ideas about subj. Maybe
VM> someone will add something or express their opinion?
Oh, Slava, I completely agree with you and am even ready to help in
developing the standard. I
experienced the inconvenience of full assembly coding myself.
2All: If you have good thoughts on this matter, be sure to write!
This will be useful to all coders who write logic for games.
With respect, Roman.
And he will add and express :)
VM> Why are so few large programs released for the Spectrum?
VM> IMHO, one of the reasons is the difficulty of writing
VM> large source codes in assembler.
Significant sized source codes are difficult to write in anything, and not
only in assembler :(
VM> simply suppresses the sheer volume of information - a bunch of files with
VM> source codes of hundreds of lines, eternal confusion with input/output
VM> parameters, and the text itself, even abundantly sprinkled with
VM> comments, remains difficult to read.
In order to simplify this process, you need not a new assembler, but
a convenient project management system, with built-in documentation tools
working with symbolic information from the _entire_ project and a powerful debugger
(with the ability to dynamically check during program execution and
a flexible system of breakpoints)
VM> The last months
VM> of debugging are usually filled with rustling printouts with listings,
VM> an attempt to connect disparate procedures and search
VM> for “stupid” errors, which from the point of view of the assembler are not errors
VM>.
The same will happen with any other language, including an advanced
assembler
VM> What are the alternatives today? Pascal.
Theoretically - yes, practically there are no normal compilers.
VM> As the only available example
VM>, let's look at HiSoft products. If we discard the standard
VM> library, which is forcibly attached to each program, the analysis
By the way, this is not true (at least for its PC analogue - Avocet C)
VM> of the generated code will show at least two weak points:
VM> the transfer of parameters to functions is carried out relative to index
VM> registers, and all variables are stored in memory (even in C, even those
VM> for which a set of registers would be enough to store) -
VM> naturally, this sharply reduces performance and significantly
VM> increases the length of the object code. I mean, a normal
VM> programmer will not write like that.
There are much more weaknesses there:
There are no attempts to reduce arithmetic to a more efficient byte
form
There is a complete absence of global optimization (although it is not really needed)
There is no optimization in the code generator (what they call it) optimization
is possible with a stretch)
All these weak points come down to one thing - there is no optimizing
code generator :(
VM> You could, of course, try to write a new
VM> C compiler, but it is unlikely that you will be able to do it optimally from your handheld
VM>.
This should be done not from your handbook, but armed with the relevant information, and
as well as a lot of free time :(
VM> Iit seems that a more realistic way is to try
VM> to “twist” the assembler itself.
Maybe, but not in the way you suggested - this is no longer an assembler, but a cross between Fortran and assembler (by the way, Fortran was made exactly this way - by
'twisting' the assembler to be able to write more or less conveniently program,
at the same time bringing its syntax into a more readable form)
VM> The first step on this path has already been taken: macros.
The right path.
VM> The second
VM> step was the appearance in some assemblers of commands
VM> replacing the chain of commands, which are (in the opinion of
VM> authors) the most common encountered.
End of the road (IMHO)
As soon as an assembler begins to compile a single input line into
combined sequences of commands (more complex than one
operation - one sequence), it ceases to be an assembler
and becomes a High Level Language.
VM> From here onwards,
VM> should dance (IMHO). Here are a few thoughts:
[dancing skipped]
VM> 5. Then we can introduce the concept of an assignment expression. For example:
VM> B=(DAT0)+5-C+(DAT1)+DAT2-(HL)
Indeed, this is it - Fortran+Assembler
VM> special characters. This string is converted to something like:
VM> LD A,(DAT0) ; fetch at address (DAT0)
VM> ADD A,5 ; +5
VM> SUB C ; -C
VM>PUSH HL; fetch at address (DAT1)
VM> LD HL,(DAT1) ; / not very nice and you should think about it
VM> ADD A,L ; /
VM> POP HL ;/
VM> ADD A,DAT2 ; +DAT2
VM> SUB (HL) ; -(HL)
VM> LD B,A ; B:=result
Here you will have to _VERY_ think, since compiling an arbitrary
expression, the operands of which can also be working registers, is an
_EXTREMELY_ difficult task, writing a regular translator with C is _much_
simpler :(
VM> 14. For starters - what the source might look like:
VM> subr_ix PROC (var HL,IX,A) : BC
VM> GOSUB s1(#5800,A+color)
VM> .IX[10]=IX[1]+shift[A]-#7F
VM> IFC (IX[10]-100) m1,m2,m3
VM> m1 .IX[10]-=1
VM> GOTO m2
VM> m3 .IX[10]=(mmx)
VM> .IX=IX+16
VM> m2 RETURN
Oh, mother, take me back! The assembler will remain :)
VM> And in the assembler it would be possible like this (as if we have
VM> a good optimizer :))
Golden words (about a good optimizer) :)
[an example of how a good optimizer works - it’s already good]
Summary:
1. It is better not to expand the assembler in this way.
2. If you really need it, then it’s better to spend your time and energy on a normal C
3 compiler.Debugging problems at the final stages should not be solved using the language, and it is better to spend time and effort on creating a normal shell for development (note: the shell is not only a text editor, it will take up no more than 10% of it, and most likely even less)
PS. I have not seen normal shells _anywhere_, the first approximation to a _normal_
shell I was lucky enough to meet only on SparcStation :(
Roman
PS. All of the above regarding compilers is based on my personal experience in
this region.
Get msg, Roman!
10 Apr 97 01:55 -- Roman Khvatov told Vyacheslav Mednonogov about Re: it would be nice
to update the assembler:
RK> [dances skipped]
RK> Oh, mom, take me back! Don't do that! Let it be better for Assembly to remain
RK> :)
Well, well
With warm greetings, Slava.
/skip critical remarks/
RK> 2. If you really need it, then it’s better to spend time and effort on a normal
RK> C compiler
In short, I understand, all your comments come down to this? I agree, it would
not be bad, but we live on earth, not in heaven :)
Maybe then be more specific: like “the case statement proposes to do this and
that, passing parameters so and so”, etc. What should be limited, what should be added. God himself ordered you, because... It seems like you were analyzing Avotek
C and HiSoft C code.
At worst, a reference to the literature will do :))
With warm greetings, Slava.
Get msg, Denis!
12 Apr 97 18:03 -- Denis Zaytsev told Roman Petrov about it would be nice to update the assembler:
DZ> The ultimate goal (unattainable) is a macro language capable of “digesting”
DZ> expressions of high-level languages. But the problem with data transfer and its
DZ> distribution between registers and memory will apparently remain:(
So, you can:
a) come up with a syntax for macro expressions/operators that would not
allow non-optimal distribution;
b) which would allow, but in the listing it would produce warning';
c) introduce an additional key - which would allow either mode (a) or
mode (b) (for those who need the optimal code and for those who do not)
DZ> The best solutions are often perversions. As an example, let me remind you that in the unforgettable *ELITE* PUSH commands were used to clear the screen - and this is, indeed, the fastest solution.
Because We are still talking about the subject, any perverted solutions are acceptable :)
With warm greetings, Slava.
MK>> Haven't you looked at the port cp/m80 by A.Moa?
VM> Port?
MK>> If you kick the author hard, then maybe some
MK>> documentation will be cleared up. I assure you - three quarters of your
MK>> ideas come down to banal macro definitions.
VM> Exactly. We are not talking about creating a new flawed
VM> programming language.
VM> As soon as it comes to this, the advantages of
VM> assembler, such as the conciseness of the code and its speed, will immediately be lost.
VM> If you look closely, these are macro definitions, externally
VM> similar to the constructions of some language. The question basically comes down to what
VM> constructs are used most often by most
VM> programmers (not just supposed developers), and how to put them into
VM> form so that it is easy to understand.
VM> Let's start over. Having thought carefully, we can propose the following
VM> form of expression (single-byte):
VM> res_t1=arg_t1*arg_t2*arg_t2*....*arg_t2
VM> Where:
VM> = - assignment operator
VM> * - one of the mathematical ones. operators (+,-,&,|,^,....)
VM> res_t1 is any register, or (HL), or (receiver_address),
VM> or IX[n], or IY[n]
VM>arg_t1 is the same as res_t1
VM> arg_t2 is any of the registers (except for accumulator A), or
VM> (HL),
VM> or IX[n], or IY[n]
VM> Thus, expressions like:
VM> B=(dat1)+(dat2) ; because implies redundant operations with the stack
VM> ;for temporary storage of one of the operands
VM> L=C+(HL)+A ;inclusion of the accumulator except as the first
VM> argument
VM> ;leads to ambiguity and is contrary to common sense
VM> ;sense :)
VM> Other expressions, no matter how tricky they may be,
VM> are allowed, and,
VM> what is most important - YOU CAN’T WRITE THEM IN AN OPTIMAL ASSEMBLER (IMHO):
VM> (RES)=(SRC)F+6+(HL)-C
VM> [ld a,(SRC); and #1f; add a,6; add a,(hl); sub c]
VM> All optimization of expressions comes down to checking the need for
VM> initial assignment to the accumulator, i.e.:
VM> (HL)=C is ld (hl),c; -but not ld a,c; ld (hl),a.
VM> By the way, this expression representation can describe most
VM> operations on byte operands (I took the big list and checked ;).
VM> There are, respectively, two questions to All:
VM> - what is wrong in what is written above?
VM> - what is missing there?
MK>> With best wishes, Michael.
VM> With warm greetings, Slava.
VM> p1\ I need to watch TASM4_by_RST7 - there are rumors that he did a lot of things there
VM>.
VM> p2\ due to the long absence of ZXF6, I should throw the Black_Raven demo into the
VM> echo. Y?
Hello, Slava! This is Scorpion Club. I'm a little off topic, but with a small
request: how can I contact Sergei with Fida? Throw it with soap!
VM> --- MS GENS'97 v2.51.A0901++
VM> * Origin: Made by Copper Feet (2:5030/461.12)
VM>> ;).
MK> Isn’t that a little? Here and there I have to operate with 32-bit arguments
MK> .. And multiplication/division is also not the last thing.
It seems that the raised topic hits the wall of individuality - everyone has their own
way of writing in assembler => everyone has their own most frequent turns, which
he would like to see in the form of new commands. Dead end?
Warm greetings, Slava.
VM>> in echo. Y?
MK> Oh! In file?
Already. In the echo
Warm greetings, Slava.
Hello, Efim!
Tue 01:49 15 Apr 1997 Efim Shuvikov writes to Vyacheslav Mednonogov:
ES> Hello, Slava! This is Scorpion Club. I'm a little off topic, but with
ES> a small request: how can I contact Sergei with Fida? Throw,
ES> soap!
[*] overquoting, quoting technical information.
Best wishes! Michael, CoModerator of ZX.SPECTRUM
[a pile of boiled water]
IMHO such an “update” is only necessary for game programmers.
because No self-respecting coder would trust assembly language optimization in Speccy (cool demos are more difficult to write in macro technology).
The only thing I always understood was this. For example. repeating fragments like
MASM's BEGIN - END operators.
Of course, if someone can prove otherwise, Masm 2.0 can become like that...
With Best Regards,
AIG .
MK> Hmm, I couldn’t find a more suitable wording.
This is exactly what it is.
MK> What else can you call m80, processed by some converter 8080->8086
MK> with minimal hardware? ;)
No way.
By the way, the thing is developing and, perhaps, soon it will no longer be a port. True,
REL will no longer be REL (that is, only in one direction :().
Andrew
Hello Vyacheslav!
Thursday April 17 1997, 16:01 .
Tuesday April 15 1997 02:02, Vyacheslav Mednonogov wrote in a message to
Michael Kondratyev:
VM> It seems that the raised topic runs into the wall of individuality -
VM> everyone has their own way of writing on assembler => everyone has their own most
VM> frequent revolutions that he would like to see in the form of new commands.
VM> Dead end?
No, I think that there is simply no need to specify the task so much, because
you can go the other way:
Let's divide the programs by topic: system, game, demo, etc.
Now let's think about system programs: most likely they do not require any special
assembly improvements. Specki has too little memory to write such programs using macros.
Another thing is the game... Here, as nowhere else, arithmetic is important, especially with floating
point.
That's where there is something to think about.
And the most colorful example is demos, so repeating
blocks were written for them ( see previous letter). And here it seems that it’s difficult to come up with anything other than improving
the functions of Begin End structures.
There is a reasonable proposal: leave everything as it is, but add something like
enumerated type variables:
%Name1 = (7,6,5,1) or %Name2 = (H,L,XH,XL,D,E)
And in the body:
Begin Count
Ld %Name2,%Name1
end
So that with each cycle %Name takes on the followingvalue.
Of course, we must not forget about the variable already made, for example, in Masma, which
contains the current pass of the structure, but this is only if the dependence is subject to the
function.
So you can go ahead.
With Best Regards,
Ilya .
Forth can be considered:
1) A high-level language (with most OOP elements), and more machine-
independent than C.
2) A low-level language (working with the processor is actually at the level of machine
instructions), sometimes it is mistakenly considered a macro assembler, but its capabilities
are many orders of magnitude bypass the capabilities of conventional macro assemblers...
3) An interpreter (you can use it like a BASIC calculator, only
the speed will be much higher).
4) A compiler (each definition, immediately after input, is compiled into a very
compact and efficient threaded code and is immediately ready for execution).
5) A language creation tool (unlike most programming languages
it allows redefine absolutely everything and use arbitrary command syntax).
6) Operating system (in principle, Forth can be designed so that it runs on a “bare” machine without an OS)...
In general, find a book, it’s best to start with
“A Beginning Course in Programming in the Forth Language,” L. Brody, M. 1990.
“The Forth Language and Its implementation", S. Baranov, N. Nozdrunov, L. 1988.
There you will find so many new ideas for you... Like separate stacks
for return addresses and data passed to procedures, compiling
when executing expressions, organizing a dictionarydefinitions, implementation
encapsulation, etc. I liked these ideas so much that I wrote my own version of Forth for IBM, in the style of Forth-83. In principle, it can be
adapted to the Spectrum, but I would like to do this not before there is a
general standard for a video controller (normal Forth needs output to the screen
in lines of at least 64 characters)...
Good luck George
AM> I wrote somewhere here about the fact that before writing, you need to draw up a plan,
AM> then practically the volume no longer affects.
Anyway, there are two enemies: the readability of the text and its volume (with the growth of which
the probability of random errors increases). The plan is good, but you can’t write everything down.
AM> Always and everywhere, critical parts were written in assembler, the rest was according to
AM> taste. What difference does it make how many milliseconds it takes to display and process the menu,
AM> one or a hundred?
I used to always give a damn (almost :))
So, lose “everything about your own, about women’s”... Apparently, I raised this topic in connection with
programming real_time_strategy. There, one would like everything to work quickly, because... in fact, everything affects the speed.
And in quests, RPGs, turn-based strategies (and shadow monitors :)) - I agree,
there is no problem.
/skip/
VM>> You can introduce a universal GOTO, which will itself determine what
VM>> to set - JR, JP. True, how passable your assembler will be
VM>> is another question :))
AM> Two (not including the linking process :)
Actually, it’s not important, but let me disagree with you.
VM>> 11. It seems like I touched on a little of everything. By the way, we still need to decide what
VM>> to convert the source text into - into pure assembler or directly into code.
VM>> Well, onAt every step you need to remember about optimization.
AM> Here it is especially clear that you proposed a new Java program.
New set of macro commands :-? And the conversion to pure ASM is for manual
adjustment and quality control ;)
AM> I heard, I mean I read it there. Actually, everything is simple: Sources are taken
AM> Small-C (from Dr.Dobs), then a statement is made, then... (see a little higher
AM> :) IMHO, and sorry if I offended anyone...
I mean, are you a pessimist too?)
VM>> All for the development of a national standard!
AM> And corn is the queen of fields!
Damn, such a simple idea - and meets with such fury resistance.
With warm greetings, Slava.
Get msg, Roman!
17 Apr 97 03:50 -- Roman Khvatov told Vyacheslav Mednonogov about Re: it would be a good idea to update the assembler:
RK> if the language wants to remain an assembler, then _all_ operations in it should
RK> be _strictly_ specified and not depend in any way on the environment in which
RK> they meet.
Mmmm... Yes, that makes sense. Perhaps, then, I will reformulate the initial
statement of the problem: supplement the assembler only with such commands (constructions,
pseudo-commands?) that are _unambiguously_ converted into code. Optimization
is excluded (I have already given the form of a byte expression as an example).
Do this solely for the purpose of _increasing_readability_ and compactness
of the source text.
RK> If for assembler, then all operations must have an _unambiguous_ equivalent
RK> with real code, for example, there cannot be an operation '+', but maybe only
RK> operation '+=', etc. etc.
Well, several operations in one line still scares you :)
RK> And if for C, then there is a very large field for specific discussions:
About C - I’m a little rash. It’s interesting what could be attached to the subj
idea.
RK> 1) If possible, reduce all operations to byte operations. Example:
RK> char c;
RK> int i,j;
RK> c=i+j;
That’s right, when you write in C, and even in IBM,You manipulate types freely, without thinking about which engine you attach to your program. IMHO, when
programming in ASMA, one tries to
avoid operations on variables of different types (and there is no need to do this)
RK> Here addition can be done byte, not word.
The given example is somewhat far-fetched, you must agree.
RK> 3) Parameters of procedures are passed through registers. When calling
RK> this is almost always possible, but using such parameters inside the
RK> procedure is a separate and very complex issue.
Almost unsolvable. By the way, what I suggested is just a convenient
format for calling procedures, which is translated into code _unambiguously_. In parallel
monitoring is carried out for the correspondence of the types of input parameters, their number, and
within the procedure itself - for saving/restoring to/from the stack.
RK> (If there are more parameters than registers - through the stack)
And select them through (IX+...). We know. IMHO, a “living” programmer never
does this - in extreme cases, EXX or through memory.
RK> 4) Perform an interprocedural analysis of the use of registers. This feature
RK> should be turned on only during the final assembly of the entire program, since
RK> in this case multiple iterative retransmissions are possible, which will be
RK> very slow.
Why do we need it slow? That is, as in point 3, it’s nice thatIt will be possible
to program in C. But the practical return is small.
P.5,6,7 seem to be saying the same thing. Not to mention that no one will seriously
tackle this difficult task.
With warm greetings, Slava.
The second argument in “(HL)+A” ({non-terminal}) is a character from the alphabet “A”:
L = C + “A” i.e. {A} = {A} + {non-terminal "A"}
"A" = (HL) + A i.e. {non-terminal "A"} = {A (or B)} + {A}
VM> The rest of the expressions, no matter how tricky they may be, are allowed
VM> and, most importantly, YOU CAN NOT WRITE THEM IN THEIR OPTIMAL ASSEMBLY (IMHO):
VM> (RES)=(SRC)F+6+(HL)-C
Elementarily decomposed into:
(RES)= "A" + "B"
"A" = (SRC) & #1F
"B" = 6 + "C"
"C" = (HL) - C
Hi, Vyacheslav!
Friday April 11, 1997. Vyacheslav Mednonogov wrote Roman Petrov, and then I couldn’t stand it...
VM> Get msg, Roman!
[...]
VM> I don’t know what “Dune2” and “WC” for the Spectrum are like inside, but
VM> Black Raven is written in truly, I’m not afraid this word, at the object level
VM> :)) Impacts exerted by one object on another usually do not cause
VM> immediate actions, but generate an event sign. When the
VM>'s turn reaches the target object, it recognizes the received impact, and only then
VM> processes it. This is very convenient from the point of view of debugging individual
VM> subprograms, it puts all heroes in the same conditions, it does not
VM> overload the program with multiple influences. But this is quite
VM> unpleasant in the sense of debugging interaction between blocks (finding the source
VM> of an error is difficult).
Hmm... Maybe then it makes sense to support OOP? There is no need to invent anything: IBM's TASM has such a feature.
Further, if there are objects, then there must be connections between them. You need something like a unified lib for passing messages between objects.
You can also write a debugger for it. With a built-in lip roller :)
Imho, OOP support can be implemented in a good macro language. Maybe he is a
panacea?
Crespect to you, Vyacheslav, who were not too lazy to read this nonsense,
Denis AKA Worm2.
Hi there, Andrew!
On the day 18 Apr 97 at 05:44:07 Andrew MOA wrote to Vyacheslav Mednonogov
somewhat...
[..skipped..]
AM> processing of the source text during the translation process. Macro has a number of
AM> _mandatory_ commands, one way or another present in all
AM> modern assemblers, without which the use of Macro is not possible.
AM> So, IMHO there is no dead end, you just need to know the “material parts” :)
AM> By the way, a certain language was built into Laser Genius...
Laser was a real macro assembler (and GENS too) - conditional compilation,
includes (not to be confused with the inclusion of pieces from other files, although this was also the case),
description of procedures (if I don’t confuse it with Phoenix). And the built-in language (call it Phoenix)
is most likely also a macro extension, with a “pseudo-C-like” syntax and
a library that is compiled at the code generation step. It seemed convenient, but
I didn’t use it... Andrey, what did it look like from the inside? Phoenix, I mean -
really macro?
AM> Andrew
//Wicked Cyril
e-mail: mcy...@deeds.spb.ru Ravel support: ftp://ftp.ShadowMAC.org/ravel/
cy...@star.spb.ru
■ Men's magazines often feature pictures of naked women. Women's magazines also
feature pictures of naked women. This is because the female body is a beautiful
work of art, while the male body is hairy and lumpy and should not be seen by
the light of day.
On day 15 Apr 97 Vyacheslav Mednonogov had the good fortune to write to Michael Kondratyev:
VM> It seems that the raised topic hits the wall of individuality - each
VM> has his own way of writing in assembler => everyone has his own most frequent
VM> turns that he would like to see in the form of new commands. Dead end?
About twenty years ago (and maybe more) a more or less
standard extension to assembler was invented - macro. Just one caveat - Macro is not a reproduction of text fragments, but a kind of means of processing the source text in the translation process. Macro has a number of _mandatory_ commands, one way or another
present in all modern assemblers, without which using Macro
is not possible. So, IMHO there is no dead end, you just need to know the “material parts” :)
VM> Yes, yes. So, where do you get ideas from? :)
What do you call assembly language? I give you an idea - wasm. Because tasm and masm already exist.
With best wishes, Michael.
Hello Andrew!
Wed Apr 16 1997, Andrew MOA concocted a letter to Michael Kondratyev:
AM> By the way, the thing is developing and, perhaps, soon this will no longer be a port.
Oh! If it is also 32-bit, then it will be worthy of all praise. I can
even help in moving in the right direction as an interested party.
Whatever you say, the current 50k for everything is a bit tight..
AM> True, REL will no longer be REL (that is, only in one direction
AM> :().
Yes, you’re just reading my thoughts. ;) B First of all, dissatisfaction is caused by 6
character names. I even thought one day: why not take an ordinary obj as a starting point? True, you will still need your own linker, but imho it’s still not the worst solution..
With best wishes, Michael.
EM> I have the same ones.
It seems that there were no objections from anyone except M. Kondratiev, who
mainly works with 32-bit arithmetic (joke).
You can only propose a standard for the symbolism of operations, otherwise where as soon as
they are not distorted:
+,- - plus/minus
&,|,^ - and,or,xor
Unary operations (inversion, shifts, ...) somehow don’t fit well into a
harmonious system :( Maybe someone has thoughts.
Intermediate assignment - also do not enter - impairs readability.
As an example for doubters - a typical piece of code:
LD A,H
AND %00011000
LD H,A
LD A,D
AND %00000111
ADD A,H
LD D,A
LD A,(SCRADR)
ADD A,H
LD H,A
LD E,L
LD A,L
RRCA
RRCA
RRCA
AND %00011111
LD L,A
We get: Or better yet, according to the code:
H=H ;H&=#18
D=D+H ;D&=... - IMHO, it will be wrong here
H=(SCRADR)+H ;H+=(SCRADR)
E=L ;E=A=L
A=L ; -
L=A>>3F ;it’s possible to represent the shift like this (?)
Maybe it’s unusual at first, but it’s beautiful and understandable (once you get used to it :), and
it takes up little space (almost :)
True, what about the calculations at the translation stage? Hmm, probably - don’t care.
Here’s an example:
lda,shift+#40 -> A=shift+#40 ;calculate the amount during translation
Or maybe it’s better like this:
A=[shift+#40] - everything in brackets is an expression calculated
at the translation stage. It agrees well with IX[n],IY[n]. And any
familiar operations inside are permissible (/,%, etc., etc.)
-----------------------------------------------------------------------
Now we come to operations with double-byte operands and register
pairs. Well, it’s not rich here, although it’s more confusing. The ideology is approximately the same, only
instead of the accumulator there will be HL (in some cases - IX,IY?).
Example:
(word1)=(word2)+DE
this is
ld hl,(word2)
add hl,de
ld (word1),hl
Several subtleties are immediately noticeable:
a) if the receiver is a register pair DE, BC - perhaps
_two_ assignments ld e,l and ld d,h are required. However, the situation can be declared erroneous.
b) the same applies to IX,IY. Apparently, mixing them with HL in an expression is not
allowed.
c) subtraction - apparently, you will have to be forced to precede it with the command OR A
What do you say? (can you tell?)
With warm greetings, Slava.
ps\ I remind you once again that all standard assemblerостаётся.
VM>> everyone has their own way of writing in assembler => everyone has their own most
VM>> frequent turns that he would like to see in the form of new commands.
VM>> Dead end?
/skip/
IA> Now let’s think about system programs: most likely they don’t need
IA> anything special improvements to the assembler.
I don’t agree - system engineers are people too! It is still unknown who has more demo-makers or system engineers.
IA> Speccy has too little memory to write such programs using macros
IA>.
And yet we are not only talking about cross-systems on a PC.
Since the proposed structures will be standard and will be included in the
assembler, tokens will probably appear for them. It seems that the proposal was based precisely on
this - the introduction of new function words (PROC, RETURN, GOSUB, IFx,...)
Even the assignment is proposed to be “tailored to this comb” and preceded by the word
LET or a period (although on a PC it is possible without this). And the syntax itself is linear and not
complicated.
IA> Another thing about the game... Here, more than anywhere else, arithmetic is important, especially with
IA> floating point.
Eh, where is it important? For example, in HLO1/2 there are no more than 4-5 single-byte divisions per pair. Commonplace, right?
IA> Well, and the most colorful example of demos, that’s why repeating blocks were written
IA> (see the previous letter). And here it looks like there’s nothing
IA> except improvementfunctions Begin End structures are difficult to come up with.
IA> %Name1 = (7,6,5,1) or %Name2 = (H,L,XH,XL,D,E)
IA> And in the body:
IA> Begin Count
IA> Ld %Name2,%Name1
IA> end
I understand the example. However, I heard that _particularly_cool_coders_ write procedures
that simply expand such repeating pieces, even if the code inside
changes according to some law :))
Well, seriously, one does not interfere with the other, although it was possible to slightly
twist macros, such as:
ldmac MAC
LD %NAME2,%NAME1
ENDM
and in the body, for example:
REPEAT ldmac, Сount
It’s just that Begin/End is usually not associated with this (for some reason for me :)
Warm greetings, Slava.
GS> This means that you have already learned the first stage of programming,
GS> you can more or less formulate an algorithm in Assembly (or another
GS> language, it doesn’t matter which one, the problems will be the same).
This means that by this moment the number of subroutines and variables is such that
it is simply difficult to understand. Not only the purpose of individual blocks is forgotten,
but also the input parameters, and in general, which subsection is in which file.
There is a huge risk of writing some subsection again if you forget that you
already wrote it and used it somewhere.
But even if you find it, it still takes a long time to figure out what it does. But
standard assembler is not the most readable language.
GS> And now you face the next stage - learning programming
GS> as a science (that is, the correct organization of all stages of writing
GS> programs, automation of frequently performed actions, etc.).
This is exactly the stage we are talking about - in the sense of “automation often of
actions"
AM> Twenty years ago (or maybe more) it was invented more or less
/skip about 20 years ago/
AM> By the way, a certain language was built into Laser Genius...
I don’t know what happened 20 years ago, and what was built into Laser Genius - I’m not an archaeologist or an antiquities specialist :) This is how the request begins: Andrey,
please illustrate your words with examples, otherwise sometimes it’s difficult to follow
the thread of your story :)
With warm greetings, Slava.
Get msg, Denis!
18 Apr 97 20:13 -- Denis Zaytsev told Vyacheslav Mednonogov that it would be a good idea to update the assembler:
DZ> IMHO, OOP support can be implemented in a good macro language. Maybe he is -
DZ> a panacea?
DZ> With respect to you, Vyacheslav, who were not too lazy to read this nonsense,
This is not nonsense, it’s just tomorrow. The main thing is to start :)
With warm greetings, Slava.
Get msg, Dmitry!
20 Apr 97 00:21 -- Dmitry Grigoryev told Vyacheslav Mednonogov about it would be a good idea to update the assembler:
VM>> Damn, such a simple idea - and it meets such fierce resistance.
DG> This is not resistance, Slav. It’s just that everyone who left ZX
/skip/
at one time and didn’t count on anything special. I thought maybe someone had some
specific thoughts (or left over from Spekov’s times).
But for myself I’ll probably do it as I described ;) By the way, thanks anyway to everyone
who responded, which opened their eyes to something.
With warm greetings, Slava.
C> [*] overquoting, quoting technical information.
I'm sorry! But this was the only place where I could find the person I needed! I apologize again!
C> Best wishes! Michael, CoModerator of ZX.SPECTRUM
C> ---
C> * Origin: KLUG's BBS ■ Freq: 1:00-5:30 ■ USR Courier V.Evr (2:5020/378)
I’m simplifying my task a little, but this will make the principle clear. A colon
begins a Forte definition, a semicolon ends it. Prefix
notation. Words starting with T are compiled into the target segment. Let's define:
HEX \ switched to 16-bit mode
\ Loading constants
: = 3E TC, TC, ; \ compiling the command ld a,n
\ and so on
\ Loading constants from memory
: =( 3A TC, T, ; \ compiling the command ld a,(addr)
\ and so on
\ Operations with constants
: & E6 TC, TC, ; \ compiling the command and n
: + C6 TC, TC, ; \ compiling the command add a,n
\ and so on
: +(HL) 86 TC, ; \ compiling the command add a,(hl)
: -C 91 TC, ; \ compiling the command sub a,c
That's it, I can already write down your example, albeit in a somewhat unusual
form for you:
SRC =( 1F & 6 + +(HL) -C
In 2 minutes a program has been written that will perform assembly in Z80 codes on any computer. Forth can be easily adapted to any hardware. Naturally, you can rightly argue that such a syntax is unusual and inconvenient. In half an hour, you can create a text string interpreter in Forth that can accept your notation form, but this will reduce the cost somewhat. flexibility...
Easiest to doinfix representation of variables and constants, after
which it will be possible to write the same example:
RES ) =( SRC & 1F + 6 +(HL) -C ;
I don’t write how, because few people here know Forth, for most you will have
explain the meaning of each Forth word, and this takes time. But it
is not difficult at all.
The main thing is the speed of writing the compiler and its convenience improvements...
As I already wrote, it is not at all difficult to make a program in Forth that will “understand” exactly the syntax you proposed.
RK>> is almost always possible, but the use of such parameters
RK>> inside a procedure is a separate and very complex issue.
VM> Almost unsolvable.
In fact, quite solvable: space is allocated for variables in stack, but
values are not copied there immediately, but only when there are no free
registers left for current operations, and in general this is a special case of optimal
register distribution with dynamic reassignment of their variables.
VM> By the way, what I proposed is just a convenient
VM> design of procedure calls, which is translated into code _unambiguously_.
VM> In parallel, monitoring is carried out for the correspondence of the types of input parameters, their
VM> number, and within the procedure itself - for saving/restoring
VM> to/from the stack.
Such procedures (with parameters in memory) are not reentrants, although you can achieve their
re-call manually saving the parameters. In this way, you can pass parameters to C (provide a special pragma or keyword to denote non-reentrant procedures)
[*] correspondence with the moderator/comoderator in the echo conference, quotation of technical
information.
Didn’t your boss explain to you that correspondence with the moderator/comoderator is carried out
_netmail_? And that there is no need to quota Tierlines and Origins?
On the day of 18 Apr 97, Vyacheslav Mednonogov had the good fortune to write to Evgeny Milun:
VM> As an example for doubters, a typical piece of code:
VM> LD A,H
VM> AND %00011000
VM> LD H,A
VM> LD A,D
VM> AND %00000111
VM> ADD A,H
VM> LD D,A
VM> LD A,(SCRADR)
VM> ADD A,H
VM> LD H,A
VM> LD E,L
VM> LD A,L
VM> RRCA
VM> RRCA
VM> RRCA
VM> AND %00011111
VM> LD L,A
{skipped}
VM> It may be unusual at first, but it’s beautiful and understandable (once you get used to it
VM> :), and it takes up little space. No ambiguity (almost :)
=== Cut ===
.comment &
screen structure (address formation):
15 8 7 0
┌─┬─┬─┬─┬─┬─┬─┬─┬─┬ ─┬─┬─┬─┬─┬─┬─┐
│0│1│0│ │ │ │ │
└─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┘
│ │ │ │ │ │ └───────┴── (0) familiarity number 0..31
│ │ │ │ └───┴──────────── (1) line number in a third of the screen
│ │ └───┴────────────────── (2) line number in the “sign line”
└─┴──────────────────────── (3) third number
character line number splits into two parts (3)+(1)
&
;calculation of the address of a familiar place on the screen (symbol 6 dots) 03/01/97 08:13 ;for 6 points -- is multiplied by 6 === Cut === Andrew
;returns the address on the screen in HL, in B the “offset” in the familiar place
ADRLIN::
ld a, (IX+2) ;+2 window start coordinate on Y (rows)
add a, (IX) ;+0 coordinate cursor on Y (vertical)
ld h, a
rrca
rrca
rrca
rrca
and
add a, c ;*2
add a, c ;*3
add a, a, a ;2*(3n<6n) => 00000111b ;07h
ld b, a ;08/01/97 10:41 p-r B instead of NUMCP
ld a, c
rrca
rrca
rrca
add a, (IX+3) ;+3 at the origin of X coordinates 00011111b
or l
ld l, a
ld a, h
and 00011000b ;leave number third
or 01000000b ;add constant
if NUMSCR>endif
h
or NUMS older byte of the address
ret
Places, indeed, takes a lot, but when you get used to ...
:)
VM> I don’t know what happened 20 years ago, and what was built into Laser Genius - I
VM> am not an archaeologist or an antiquities specialist :) This is how the request begins:
VM> Andrey, please illustrate your words with examples, otherwise it’s sometimes difficult
VM> to follow the thread of your narrative :)
It’s difficult with examples. This, apparently, was said to mean that part of what you
want has already been done one way or another, and it’s good to at least
look at it first.
In general, I am (for now) a supporter of the fact that let the assembler remain an assembler. And
if I forgot what this or that procedure does, then I need to do a “multi-file”
search, go to the procedure and read the comment. Usually this takes no more than
4-5 seconds.
Here is part of the description for Laser Genius (from Murzinov's legacy :)
=== Cut ===
4. PROGRAMMAR LANGUAGE P H O E N I X.
--------------------------------------------------------------
Expression evaluation:
---------------------
#DSE These pseudo-operations convert at assembly time
#DUE
execution of the program occur while preserving temporary
results on the stack. Arithmetic operations are defined in
a special Genius library, and they are accessed
using CALL commands from the program. ( see #LIB )
Assignment:
----------- Assignment to variables occurs during
program execution. Genius itself, during
broadcast, takes care of reserving memory for
variables. F.e.: #DUE state = 1 => 1 -> (state),
#DSE x = y = 0 => 0 -> (x)
0 -> (y) ,
#DSE y = ( z = x * x ) + x - 20
=> (x) * (x) -> (z) (z) + (x) - 20
-> (y)
where x, y and z are variables, and (x), (y) and (z) are the values of memory cells
corresponding to these variables.
Arrays:
-------- The following will show how to define variables
for translation. However, by creating variables
you can use them as the basis for indexed
variables. Thus, this allows you to create one-dimensional
arrays - vectors. That is, by defining a block of memory as a variable,
you can access it as an array.
F.e.: xcoord:#DS INT, 10
defines space for 10 integers (20 bytes).
The first integer is a variable withname xcoord, the
others are accessed as follows:
xcoord[
where
from 0 to 9. Which corresponds with xcoord[0] ( or xcoord )
to xcoord[9].
F.e.: ( value assignment )
#DSE xcoord[2] = 100
Defining variables:
-----------------------
Command for defining a variable without initialization:
VM> In general, it’s not important, but let me disagree with you.
When I wrote my first cross assembler, I was very annoyed with macro-11
(there was such an assembler on the PDP-11), and I kept wondering why it made so many
passes (it displayed statistics there). But this passed, over time.
I still strongly recommend L. Beck "Introduction to system
programming." Chapter 2. Assemblers. 2.4. Options for constructing assemblers
(double-view, single-view, multi-view). Chapter 3. Loaders and
linking programs. Chapter 4. Macroprocessors.
RK> If it’s really pressing, it will do it,
If it’s really pressing, the missing part of the parameters is usually passed through
variables (when you write in ASMA) or through alternative registers.
RK> because this is the only way to ensure the re-reency of the call, which
RK> can be required, for example, in interrupt processing.
This re-entry was given to you :) Even when handling interrupts, it is
inherent in a multi-level interrupt system (which, again, is not present in the spec). And
if an interrupt interrupts itself, it’s most likely a glitch :)
IA> floating point. Now there is something to think about.
Or maybe remember about such a thing as integer arithmetic or
fixed-point arithmetic, it seems to work a little faster.
IA> something like variables of an enumerated type:
AM> It’s difficult with examples. This, apparently, was said to the effect that partly
AM> what you want has already been done one way or another, and it’s good to at least look at
AM> first.
I agree with this, that’s why I’m asking.
AM> === Cut ===
AM> 4. L A N G P H O G R A M M I R O V A Y P H O E N I X.
/skip/
AM> === Cut ===
Thank you. I know what not to do :)
Warm greetings, Slava.
Get msg, George!
20 Apr 97 15:15 -- George Shepelev told Vyacheslav Mednonogov that it would be a good idea to
update the assembler:
GS> Let's continue. One of the uses of Forth is the creation of target compilers
GS> (assemblers). Moreover, the compactness and ease of implementation can surprise
GS> even experienced programmers!
Another conversation! And then at first it looked like you were offering Forth as an
alternative to assembler Ж-[]
/skip/
GS> Naturally, you can rightfully object that such
GS> syntax is unusual and inconvenient. After spending half an hour, you can create a text string interpreter in
GS> Forte that can accept your
GS> record form. But this will somewhat reduce flexibility...
If this is so, then just cool. The only thing left to do is to write a preliminary
Fort system on the Spectrum, so that you can then write a new assembler on it :) Or
are you talking about cross-systems, for example, on a PC?
With warm greetings, Slava.
Get msg, Andrew!
22 Apr 97 08:25 -- Andrew MOA told Vyacheslav Mednonogov about it would be a good idea to update the
assembler:
VM>> Formatting of procedures:
VM>> a) Memory model specifiers, NEAR and FAR specifiers - on
VM>> Sinclair is not necessary.
AM> But you need to indicate where (in which memory bank) the variable or
AM> procedure is located and take appropriate actions to access it. Here
AM> speed is lost, and therefore there must be a modifier preventing
AM> from this.
And when a procedure from one bank calls a procedure from another bank
it is necessary to provide a third procedure that would provide communication between
these procedures...
VM>> b) Declaring language conventions that affect the method of passing
VM>> parameters - IMHO, is also not necessary. Because the only
VM>> _widely used_ and _fastest_ way on Sinclair is
VM>> passing parameters through registers.
AM> But not always all parameters can be squeezed into registers, sometimes it is convenient
AM> to put something on the stack and then _easily_ access it).
Usually in such rare cases additional parameters are passed through
variables (IMHO)
VM>> c) saving registers (USES) - they are restored before
VM>> any RET. Reduces flexibility -what if I don’t want to?
AM> If you don’t want it, you don’t use it.
AM> And everything else is the same.
It’s clear - look at TASM, look at Laser Genius, watch Beck - if you don’t want to -
don’t use it - and everything else is the same :)
With warm regards, Glory.
Really?
[missing...]
GS> HEX \ switched to 16-bit mode
GS> \ Loading constants
GS> : = 3E TC, TC, ; \ compiling the command ld a,n
GS> \ and so on
GS> \ Loading constants from memory
GS> : =( 3A TC, T, ; \ compiling the command ld a,(addr)
GS> \ and so on
GS> \ Operations with constants
GS> : & E6 TC, TC, ; \ compiling the command and n
GS> : + C6 TC, TC, ; \ compiling the command add a,n
GS> \ and so on
GS> : +(HL) 86 TC, ; \ compiling the command add a,(hl)
GS> : -C 91 TC, ; \ compiling the command sub a,c
GS> That's it, I can already write down your example, though in a slightly
GS> form that is unusual for you:
GS> SRC =( 1F & 6 + +(HL) -C
Somehow I don’t see the advantages of a fort here over at least BASIC.
GS> A program was written in 2 minutes,
On ASMA writing this “program” will take 3 minutes - so what?
GS> which will execute on any computer assembly in codes
GS> Z80.
On the Spectrum it will also perform? Let's say... And how many hours will it take? And how much space will a full-fledged editor take?
2VM - I may have missed something, but for which machine did you propose to update the assembler editor? For the Pentium Pro?Possibility
of using it on Spectrums?
GS> The fort can be easily adapted to any hardware. Naturally, you and
GS> can rightfully object that such syntax is unusual and
GS> inconvenient. After spending half an hour, you can create an interpreter
GS> of text strings in Forth that can accept your notation form.
Well, how long, in general, will it take you to write the assembler that Slava needs? Two hours? So why not do something nice for the person?
[missing...]
GS> time. But it's not difficult at all. The main thing is the speed of writing the
GS> compiler and the convenience of its modifications...
The main thing is the speed of the compiler itself. And the convenience of modifications can only be
beneficial ;) If assembling five kilobytes of code takes at least 20
seconds (I’m still talking about Speccy) - then who can be satisfied with this?
GS> As I already wrote, it’s not at all difficult to make a program on Forth
GS> that will “understand” exactly the syntax you proposed.
Actually, that wasn’t what we were talking about _how_ to write a new assembler editor.
Hello, Vyacheslav!
Tuesday April 22, 1997 01:07, Vyacheslav Mednonogov wrote to Roman Khvatov:
[missing...]
VM> It is unlikely that something written in C will work faster than something written in
VM> assembler.
No, well, you can also write a slow-running program in assembler ;)
VM> However, I agree, no one would refuse to have good C on the
VM> spec, at least in order to comfortably write time-intensive parts
VM> of their program.
In addition to speed, there is another important parameter for Specky - the length of the object
code. Which will always be unreasonably large after C compilation. A
library of procedures hanging in memory just to draw a menu and
therefore practically not being used is not at all the same thing as hanging out
somewhere on a hard drive. Although, there are examples... The CDOS program, on which all modem operators in Moscow work. According to the author (ROBERT), it is almost entirely written in C. And it works! Not so slow... It has quite wide
opportunities... But everyone who looks “inside” is amazed at the extreme
irrationality of the code and its volume.
VM> With warm greetings, Slava.
Regards, Dmitry (OLDMAN).
Get msg, Roman!
25 Apr 97 01:23 -- Roman Khvatov told Vyacheslav Mednonogov about Re: it would be a good idea to update the assembler:
RK>>> This is possible. The result will be a very advanced macro mechanism. It is possible
RK>>> to generalize - to make a _customizable_ macro mechanism, so that it would be possible
RK>>> to set the _syntax_ for describing macros,
VM>> Type of operator overloading in C? That would be cool. But, probably,
RK> This is cooler. Operator overloading allows you to expand the semantics within
Indeed, a rich idea. Maybe you can develop it further? At least on the fingers
- how to screw up macros? Then the whole garden about subj will be useless.
VM>> Well, what is the difference between (D=A+B+C) and (A=A+B; D=A+C)? The first one, at least, is more compact.
RK> The first one does not reflect the fact that A has also changed.
I finally found the weakest point (I thought no one would notice :) Indeed,
there is a risk of forgetting that A is implicitly included in the expression (like HL - in the expression with
words) and offhand, by the form of the expression, you cannot determine whether it is included in general.
Source of new errors :(((But, on the other hand, we are used to the fact that there is ADD A, B and
SUB B - let’s get used to it here too :))
/skip/
Get msg, Dmitry!
24 Apr 97 14:17 -- Dmitry Grigoryev told Vyacheslav Mednonogov about it would be a good idea to update the
assembler:
DG> In addition to speed, there is another important parameter for Specky - the length
DG> of the object code.
-------------------------------------------------------------------------------
As S. Novikov says - QUOTE DAY.
DG> Which will always be unreasonably large after C compilation. A
DG> library of procedures, hanging in memory only to
DG> draw a menu and therefore practically not used - is not at all
DG> the same thing as hanging out somewhere on a hard drive.
DG> Although, there are examples... The CDOS program, on which all
DG> modems in Moscow work. According to the author (ROBERT), almost entirely
DG> is written in C. And it works! Not so slow... It has quite a wide range of capabilities... But everyone who looks "inside" the DG is amazed at the extreme irrationality of the code and its volume. personalities! :)
Warm greetings, Slava.
Get msg, Alexandr!
25 Apr 97 15:55 -- Alexandr Kulakov told Vyacheslav Mednonogov that it would be nice to update the assembler:
VM>> If this is the case, then that’s just cool. The only thing left to do is to write
VM>> a Forth system on the Spectrum first, so that later
VM>> you can write a new assembler on it :) Or are you talking about cross-systems, for example, on
VM>> PC?
AK> This is a common thing for
AK> FORTH!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
AK> Guys! I respect Spectrum very much and want it to develop.
Reread the above carefully - there is no good fort system on Spectrum (I saw
only two - fig-fort and something else). If you mean using Fort to
define assembler.
If you mean: “Fort is in itself a good language for the Spectrum,” then I don’t
know. IMHO, the Z80 is not very suitable for Fort. Still pushing and pushing from the stack
is fine, but more complex manipulations are a waste (no index addressing via SP). It won't be so fast as to compete with the assembler :(
AK> "You can't go far in the back of the past..." (C)
Yes, you see, we're going little by little for now :)
With warm greetings, Slava.
A “live” programmer can pass parameters in a way that the most twisted compiler would never dream of in any
nightmare :) And parameters are sometimes
passed via the stack "live" programmers (that's the truth through IX+... they are not elected)
VM> You were given this re-entry :) Even when handling interrupts
Well, you need to somehow justify it ;-)
VM> it is characteristic of a multi-level interrupt system (which again
VM> is not present on the spec). And if an interrupt interrupts itself, this is more likely a glitch :)
Not necessarily a glitch, it is possible to schedule interrupts in such a way that even with a
single-level interrupt system, numerous nested
interrupts will be possible. For example: multi-level timer interrupts. The interruption procedure is organized in the form of a series of layers superimposed on each other, each layer carries out some processing (each subsequent one takes longer), and through a given number of passes calls the next one in the hierarchy. In this case, the work of the layer can
be interrupted by numerous processing of all underlying layers.
GS>> compilers (assemblers). Moreover, the compactness and lightness of
GS>> implementation can surprise even experienced programmers!
VM> Another story! And then at first it looked like you were offering Fort
VM> as an alternative to assembler Ж-[]
Why no?
VM> /skip/
GS>> Naturally, you can rightfully object that
GS>> such a syntax is unusual and inconvenient. After spending half an hour
GS>> you can create a text string interpreter in Forth,
GS>> which can accept your record form. But this
GS>> will somewhat reduce flexibility...
GS>> HEX \ switched to 16-bit mode
GS>> \ Loading constants
GS>> : = 3E TC, TC, ; \ compiling the command ld a,n
GS>> \ and so on
GS>> \ Loading constants from memory
GS>> : =( 3A TC, T, ; \ compiling the command ld a,(addr)
GS>> \ and so on
GS>> \ Operations with constants
GS>> : & E6 TC, TC, ; \ command compilation and n
GS>> : + C6 TC, TC, ; \ command compilation add a,n
GS>> \ and so on
GS>> : +(HL) 86 TC, ; \ command compilation add a,(hl)
GS>> : -C 91 TC, ; a,c
IP> Well, for example, my speccy has 512 kB and that’s not enough ???
And I have 1024 ;) Are you writing only for yourself?
What do macros have to do with it? If I'm not mistaken, a macro is just a form of notation that is more convenient for someone than the standard mnemonics that make up the body of the macro...
If I'm wrong, then explain what is hidden under this word (from
macro assemblers I have only seen GENS).
IP> Sincerely, Igor
Regards, Dmitry (OLDMAN).
Hi, Dmitry!
24 Apr 97 at 21:52 Dmitry Grigoryev wrote to George Shepelev the following:
DG> Hello, George!
DG> Sun April 20, 1997 15:15, George Shepelev wrote to Vyacheslav
DG> Mednonogov:
DG> [missed...]
GS>> Let's continue. One of the uses of Forth is the creation of target
GS>> compilers (assemblers). Moreover, the compactness and ease of
GS>> implementation can surprise even experienced programmers!
DG> Really?
DG> [missed...]
GS>> HEX \ switched to 16-bit mode
GS>> \ Loading constants
GS>> : = 3E TC, TC, ; \ compiling the command ld a,n
GS>> \ and so on
GS>> \ Loading constants from memory
GS>> : =( 3A TC, T, ; \ compiling the command ld a,(addr)
GS>> \ and so on
GS>> \ Operations with constants
GS>> : & E6 TC, TC, ; \ command compilation and n
GS>> : + C6 TC, TC, ; \ command compilation add a,n
GS>> \ and so on
GS>> : +(HL) 86 TC, ; \ command compilation add a,(hl)
GS>> : -C 91 TC, ; \ command compilation sub a,c
GS>> That's it, I can already write down your example, albeit in a somewhat
GS>> form that is unusual for you:
GS>> SRC =( 1F & 6 + +(HL) -C
DG> Somehow I don’t see any advantages herefort before, at least, BASIC.
Look at the root...
GS>> A program was written in 2 minutes,
DG> On Acma, writing this “program” will take 3 minutes - so what? Let's say... And how many
DG> hours will it take? And how much space will a full-fledged editor take up?
DG> 2VM - I may have missed something, but for which machine did you propose to update the
DG> assembler editor? For Pentium Pro? Or do
DG> need to consider the possibility of using it on Spectrums?
GS>> The fort can be easily adapted to any hardware. Naturally,
GS>> you can rightfully object that such syntax
GS>> is unusual and inconvenient. After spending half an hour, you can create a text string interpreter in
GS>> Forte, which can
GS>> perceive your notation form.
DG> Well, how long, in general, will it take you to write the required
DG> Glory of assembler? Two hours? So why not do something nice for a person
DG>?
DG> [missing...]
GS>> time. But it's not difficult at all. The main thing is the speed
GS>> of writing the compiler and the convenience of its modifications...
DG> The main thing is the speed of the compiler itself. And the convenience of
DG> improvementscan only be profitable ;) If assembling five
DG> kilobytes of code takes at least 20 seconds (I’m still talking about Speccy) -
DG> then who can be satisfied with this?
GS>> As I already wrote, it’s not at all difficult to make a program on Forth
GS>> that will “understand” exactly the syntax you proposed
GS>>.
DG> Actually, we were not talking about _how_ to write a new editor
DG> assembler.
VM>>> All optimization of expressions comes down to checking the need for
VM>>> initial assignment to the accumulator, i.e.:
VM>>> (HL)=C - this is ld (hl),c; -but not ld a,c; ld (hl),a.
GS>> : (HL)=C 75 TC, ; \ compilation ld (hl),c
DG> IF n$="(HL)=C" THEN POKE a,113
DG> It’s so simple... And code #75 is ld (hl),l actually.
GS>> Well, this is a straightforward solution, it could be more universal, but it
GS>> will take up more space...
DG> And how much kilobyte?
GS>> Good luck George
DG> Best regards, Dmitry (OLDMAN).
DG> -+- GoldED 3.00.Alpha2+
DG> + Origin: * ON-LINE newspaper * (2:5020/689.31)
With best wishes,
Alexandr
And, in my opinion, it’s high time!!!!!!!!!
Guys! I respect Spectrum very much and want it to develop.
“You can’t go far in the shell of the past...” (C) You know from school!!!
If not us, then who???!!! For merchants this is purple now, and for altruists they have rotted...
VM> With warm greetings,
VM> Slava.
VM> -+- MS GENS'97 v2.51.A0901++
VM> + Origin: Made by Copper Feet (2:5030/461.12)
With best regards best wishes,
Alexandr
Hello Vyacheslav!
Mon Apr 21 1997, Vyacheslav Mednonogov concocted a letter to Evgeny Milun:
VM> L=A>>> 3F ;is it possible to imagine the shift like this (?)
EM>> ^^ a-g-a, but he said “problems”.
VM> Well, here the question arises - who: RRC X or RR X. And for SRL X you can
Neither one nor the other. The operators << and >> have been arithmetic shifts all their lives.
The question arises about the “sign” of the operand.
VM> *2,*4,..., for SLA X The unary inversion remains uncovered
VM> (probably
VM> is CPL? or NEG?) - turn it into binary - ~1 (1-from the bullshit), i.e.
VM> С=B~1:
a=~b this is exactly it (cpl). neg will look like a=-b
VM> Description of routines. Slightly simplify the initial version (do not
VM> use the word var):
VM> PROC name (in_reg1, ... ,in_regN)
VM> USES reg1, reg2,...
VM> ...
VM> RETURN
Or maybe it’s better right away:
#pragma aux Proc_Name =\
"..."\
parm [in_reg1 ... in_regN] \
modify [reg1 reg2 ...]\
value [out_reg1 out_reg2 ...];
The main thing is that it may be useful for future projects ;))
With best wishes, Michael.
VM> If it’s really pressing, the missing part of the parameters is usually
VM> passed through variables (when writing in ASMA) or through
VM> alternative registers.
If you know how many there are. In addition, it is simply convenient for temporary use of memory to eat it off the stack. If this allows the memory model to say so.
Hello Andrew!
Tue Apr 22 1997, Andrew MOA has concocted a letter to Michael Kondratyev:
MK>> interested party. Whatever you say, the current 50k for everything
MK>> is a bit tight..
AM> I wonder - for what?
I still returned to the original plan of “assembling everything in one
piece.” I just had to make macro.inc a little more modest (these macros
eat a lot more labels)...
AM> The linker is already “its own”. And obj - maybe, but for some reason I didn’t
AM> like it at first glance (maybe I was looking in the wrong place, but is there a sensible description
AM> of the fields?).
I only found a Russian file ~70k (it is recorded on almost all software
CD collections). ;(
With best wishes, Michael.
Hello, Alexandr!
Friday April 25, 1997 17:13, Alexandr Kulakov wrote to Dmitry Grigoryev:
[a lot of quotas were missed...]
AK> Look to the root...
Kozyma Prutkov for my soul? :-))
Sincerely, Dmitry (OLDMAN).
Hello Vyacheslav!
24 Apr 97, Vyacheslav Mednonogov writes to Roman Khvatov:
RK>> This is cooler. Operator overloading allows you to expand the semantics within
RK>> framework
VM> Indeed, a rich idea. Maybe you can develop it further? At least on
VM> fingers - how to screw up macros? Then the whole garden about subj will be of no use
VM> to anything.
Please:
The macro itself is specified in the form of a regular expression (maybe not in canonical
form, but in a somewhat closer to the usual assembly notation)
The body of the macro can use parts of the string matched with the expression as
parameters.
For example (a very crude form) byte addition operator:
macro 'A += {B|C|H|L|D|E|(HL)|(IX+\n)|(IY+\n)}'
add a,#1
endm
In general, everything is clear here, {} - denote a group (you can address),
| - denotes an alternative, \n - denotes a number (or expression), #1 -
substitution of the first matched group.
Inside macros you can support generators: program for special. language (very
simple but complete), when executed, the output text is generated for
assembly.
For example: register pair shift:
macro 'rr {HL|DE|BC}'
# p1=substr(#1,1,1) ; substring from the 1st position of length 1, i.e. senior
; register from register pair
rr #p1
# p1=substr(#1,2,1) ; .. and junior register
rrc #p1
endm
Generating macros are also possible:
macro 'irp {\n}'
# emit('# for (i=0;i<'+str(#1)+';i++)')
endm
macro 'irpend'
# emit('# endfor')
endm
Operator emit treats its parameter as a string that needs to be substituted
and which will be assembled after first passing through the macroprocessor.
The operator is necessary so that when processing the primary macro this string
is not recognized as part operator.
Etc. etc. You can introduce a hierarchy of patterns (for example, so as not to write out
a set of registers each time).
This approach has the advantage of exceptional power compared to
other macro assemblers, but there are also disadvantages: firstly, to translate such
macros you will need a lot of memory, and parsing text too (in reality this is only possible on a PC, IMHO), and secondly, using regular expressions
it is impossible to write down a combination of expressions, i.e. The principle 'one
line - one statement' will be followed. This limitation can be circumvented by introducing, in addition to regular
expressions, support for grammars, but this will entail two major troubles:
the amount of required memory, as well as the complexity of the parser, will increase significantly,
in addition, you will have to practically draw at the source level text
rules for translation of expressions, which of course is very flexible,but it’s too tedious :(
(As for how this kind of parsing is done, you can look at the source codes of lex
and yacc, or read the relevant literature)
Hello Dmitry!
26 Apr 97, Dmitry Grigoryev writes to Roman Khvatov:
RK>> existing syntax, but what I proposed allows you to expand
RK>> syntax. Then it will be possible to describe almost any type of
RK>> elementary operations, for example, 'add a,b' can become 'a=a+b' or
RK>> 'a+=b' or even 'add a and b and put result into a' ;-)
DG> That is, the listing of each individual programmer will look different
DG> and will not be clear to anyone except him? Let's assume that the text will be
DG> tokenized, and having loaded a procedure written with mnemonics alone, the
DG> editor will display it correctly, but what about publishing texts
Alas, this approach works at the level of non-tokenized text, and in general
represents a set of _macros_, i.e. for the assembler itself it does not have
any structure. So, if someone wants to write their own
macros, then they will have to attach a file with these macros to the program.
As for macros that directly describe the assembly language, there will be quite a lot of them, they will be written by the author of the assembler himself and may
be part of the assembler itself only in precompiled form (in the form of ready-made macro tables). So the sources will look the same (or there will be
several pre-definedcommand formats, if the author makes several
descriptions)
...
VM> This re-entry was given to you :) Even when processing interrupts
VM> it is characteristic of a multi-level interrupt system (which again
VM> does not have on the spec). And if an interrupt interrupts itself, it’s more likely a glitch :)
VM> Thank you. I know what not to do :)
I just want to note that this was an extension to a completely normal macroassembler, it was even loaded separately. Moral - if you don't want it, you don't
use it.
Andrew
VM> And when a procedure from one bank calls a procedure from another bank
VM> it is necessary to provide a third procedure that would provide communication
VM> between these procedures...
No, this is not done by a procedure, but by a run-time-library (that’s how it seems to be written :)
Which, for that matter, you write yourself (well, or have direct access to it
access).
VM> It’s clear - look at TASM, look at Laser Genius, look at Beck - if you don’t
VM> want it, don’t use it - and everything else is the same :)
Well, what did you want? It’s just that at one time, when I was trying to find some “worthy” cross-system for myself, I looked at a lot of things, which greatly expanded my horizons :-) But nothing more: assembler is assembler, C is C, and so on. And as usual, everything depends on debugging, that is, on the “environment”.
Andrew
On the day 25 Apr 97 Dmitry Grigoryev had the good fortune to write to Igor Pronin:
DG> What do macros have to do with it? If I'm not mistaken, a macro is just a form of recording
DG> that is more convenient for someone than the standard mnemonics that make up the body of a
DG> macro... If I'm wrong, then explain what is hidden under this
DG> word (of the macro assemblers I've seen only GENS).
GENS is not quite a macro assembler, more precisely an assembler with the rudiments.
And macros, for example, here
=== Cut ===
.z80
.lall
clrbuf macro ?buffer, ?count
local pastsub
jp pastsub ;; here you need, of course, jr
clr:
push de
ld e, l
ld d, h
inc de
dec bc
ld (hl), 0
ldir
pop de
ret
pastsub:
clrbuf macro buffer, count
if nul count
ret
else
ld hl, buffer
ld bc, count
call clr
endif
endm
clrbuf ?buffer, ?count
endm
=== Cut ===
Calling in a program
clrbuf 50000, 256
clrbuf 60000, 512
will result in output
=== Cut ===
Macro Assembler-80 v1.10 MOA, Mar 1996 Page 1
.z80
.lall
clrbuf 50000,256
0000' C3 000E' + jp ..0000
0003' + clr:
0003' D5 + push de
0004' 5D + ld e, l
0005' 54 + ld d, h
0006' 13 + inc de
0007' 0B + dec bc
0008' 36 00 + ld (hl), 0
000A' ED B0 + ldir
000C' D1 + pop de
000D' C9 + ret
+
000E' + ..0000:
+ clrbuf macro buffer, count
+ if nul count
+ ret
+ else
+ ld hl, buffer
+ ld bc, count
+ call clr
+ endif
endm
+
+ clrbuf 50000, 256
+ if nul 256
+ ret
+ else
000E' 21 C350 + ld hl, 50000
0011' 01 0100 + ld bc, 256
0014' CD 0003' + call clr
+ endif
clrbuf 60000,512
+ if nul 512
+ ret
+ else
0017' 21 EA60 + ld hl, 60000
001A' 01 0200 + ld bc, 512
001D' CD 0003' + call clr
+ endif
end
No Fatal error(s)
=== Cut ===
An example, in general, not vital, but interesting.
When a macro is called for the first time, a sub-item (or sub-items) are built, which will be
referenced during subsequent uses of the macro.
Here is an example of redefining a macro “on the fly”, macros can be and
recursive.
Andrew
On the day 24 Apr 97 Vyacheslav Mednonogov had the good fortune to write to Dmitry Grigoryev:
{skipped about C}
VM> No comments!
VM> And some people indiscriminately call us to do this. personalities! :)
Actually, this is not what they are calling for. Since this is _inevitable_, so why call for it?
I would really not like discussions, such as comparing assembler (programming in
codes :) with Java. Since all the advantages and disadvantages of both have long been known and “discussed” dozens of times in various books and echoes.
In addition to the language itself, there are many more interesting things, so to speak, “language-independent”. For example, working with memory: hip, malloc/free, stack memory, and for the Spectrum - page memory. And how, say, in this page
memory to dynamically allocate something?
......
Andrew
MK> I still returned to the original plan of “assembling everything in one
MK> piece.” I just had to make macro.inc a little more modest (these macros
MK> eat a lot more labels)...
In the m80 assembler, to reduce the memory for macros (if they are large), you can
do the following things - define a macro immediately before use
and delete (redefine) after. But if they are small (and, accordingly, there are
a lot of them), then - alas.
The memory allocated for macros can only expand, taking away space from
the symbol table.
Andrew
Hi there, Andrew!
On the day 28 Apr 97 at 05:35:28 Andrew MOA wrote to Vyacheslav Mednonogov
somewhat...
[..skipped..]
AM> In addition to the language itself, there are a lot of interesting things, so to speak
AM> “language-independent”. For example, working with memory: hip,
AM> malloc/free, stack memory, and for the Spectrum - page memory. And
AM> how, say, to dynamically allocate something in this page memory?
AM> ......
If the need arises, someone will do it. There are a lot of methods - it’s worth looking
at wasps that do not support memory protection and choose the most suitable one for a 16
bit address (or better for a page and consider it a hip for simplicity).
It’s another matter if they invent something to the point of “genius” hard wired and crap: you can’t compile it and you can’t use it.
AM> Andrew
//Wicked Cyril
e-mail: mcy...@deeds.spb.ru Ravel support: ftp://ftp.ShadowMAC.org/ravel/
cy...@star.spb.ru http://www.star.spb.ru/~cyril/
■ It isn't the fall that kills the child, it is the splattering of the brain
against the inside of the skull.
DG>> will be “time-intensive” when the program is conceived for some
DG>> time - this is called “hanging”, “slowing down” and other unflattering
DG>> words.
RK> This will happen on the contrary, they are called “time-intensive” pieces,
That’s exactly what I said.
RK> and it is these that need to be optimized, and such pieces of code will be just
RK> 20% of the total code size (usually).
Again, it largely depends on the purpose of the program and on the free resources
of the machine. For example, if you need to meet an interrupt, you'll start chasing every extra clock cycle; if you need to fit the program in one sector, you'll start chasing every extra byte. This is optimization. And it is thanks to her that programs are now being made on Speccy, the creation of which was previously considered impossible.
DG>> On the Pentium, both graphics output and mathematical calculations can be
DG>> equally time-intensive, this trick will not work on the Spectrum.
RK> The 20/80 ratio does not depend on the computer.
It does not depend on anything, since it is taken from thin air. Theory.
RK> It will depend on the computer whether it is necessary to optimize at all, and what
RK> exactly to optimize and how much of it - not.
In most Speccy programs (and even more so in games) you needoptimize
practically _everything_ that you have enough patience for and that is reasonable - there is no limit
to perfection ;) And to make programs that are 80% made up of something incomprehensible... just
it would work... :(
RK> Roman
Regards, Dmitry (OLDMAN).
DG> Again, it largely depends on the purpose of the program and on the free
DG> resources of the machine. For example, if you need to meet the interrupt -
DG>, you will start chasing every extra clock cycle, if you need to fit the program into
DG> one sector - after every extra byte. This is optimization. And it is
DG> thanks to her that programs are now being made on Speccy, the creation of which was previously considered impossible
DG>.
If your _entire_ program is one continuous interruption, then you need not to chase
every clock cycle, but to redesign the program, and if not the whole program -
interruption, then you need to chase the clock cycles not chase through the entire program, but only in
interrupt handling. The same applies to placement in one sector.
In any case, for each field of application there is a good language: for writing not very voluminous, most compact and fast programs - assembler, for
large systems - C (although the question remains open about the possibility and
efficiency of large programs on Speci)
C will never be able to replace assembler, but it can occupy part of the ecological
niche of programs on Speci. If, when writing a program, the desire arises
to make something more out of assembler, then this program is a direct candidate for
replacing the language forсебя.
DG>> compiled, then this code is not optimized ;)
RK> Such energy for peaceful purposes - for example, to write an optimizer for
RK> C itself ;-)))
It will work out - let him write it on himself ;) I meant that both your and my
phrases have the same right to exist. But! There is a small
difference between them - in your case the result depends (of course, not completely, but still to a sufficient extent) on the compiler, in mine - only on the programmer! :-))
Besides, no matter how perfect the compiler is, it will not replace the human brain, his imagination... I am sure that you can write well in C, but it
will no longer be easier than in ASMA. That is, you can write in C in an optimized way, but
for this you need to know the structure of its compiler, what kind of code it will compile
and in what case. And use, in most cases, the simplest operands that compile unambiguously. But then the advantage of Java is lost - "high
level", don't you think?
RK> A normal compiler should not insert 'extra' commands
It should. He gets them from somewhere, doesn't he? This means they are universal there, because it cannot
keep in itself all possible combinations of processor commands...
RK> (BTW, there is not a single _normal_ C compiler on the Z80 _, so don't
RK> need to look at what HiSoft C has generated,
NeverIt never occurred to me to look at what HiSoft C would compile there - I'm afraid
for my sanity ;-) What does it have to do with whether it exists or not, you've seen a normal
compiler on something else? So, can you imagine an algorithm
compiling on the Z80 (or for the Z80)? Then give an example that proves your point of view. What would, for example, a text converter
from one code table to another look like in compiled form?
RK> but there is nowhere to look yet - so this dispute is meaningless)
There are no meaningless disputes :-) And you can look at similar things on other
platforms. So I look at one of these and notice that there are programs that perform the simplest functions, but they take up tens of kilobytes and when working
they squeak for a long time and loudly (I exaggerate slightly), and there are those that perform effective
actions and have sizes in bytes. I hope you understand how they differ from
each other?
RK> For example, a code that enters a key in the menu when starting a game is much less
RK> demanding on the quality of its optimization than the sprite output cycle
RK> or screen refresh, am I right?
Right, if this code requires only speed, and if size?
If you just need to check the pressing of a key, then such a procedure
written in ASMA is itself optimized; it will take several bytes. But
written in Java, it is possible that it will dothis is through scanning
the entire keyboard :)
RK>> that same C ;-)))
DG> It will work out - let him write it on himself ;) I meant that both yours and
It (the C programming language) still does not know how to write on itself :)
DG> my phrases have the same right to exist. But! There is
DG> a slight difference between them - in your case the result depends (of course, not
DG> completely, but still to a sufficient extent) on the compiler, in mine -
DG> only on the programmer! :-))
In mine too - from the programmer who wrote the compiler ;)
In addition, in my case, if the programmer is not satisfied with the code generated by the compiler (he is not satisfied not because it could be better, but because
it _should_ be better), then this piece can always be written in assembler.
DG> In addition, no matter how perfect the compiler is, it will not replace the brain
DG> of a person, his imagination...
No, of course, and such a goal is not worth it.
DG> I am sure that you can write high-quality in C, but
DG> it will no longer be easier than in ASMA.
For high-quality writing in C you need to think about how to implement algorithm, and
not how to encode it as densely as possible.
DG> That is, you can write
DG> in C in an optimized way, but for this you need to know the structure of its compiler,
No need. In addition, it is almost impossible.
DG> what kind of code it will compile and in what case. And usein
DG> in most cases, the simplest operands compile unambiguously. But
This is true in the case of using the _simplest_ C compilers; for
optimizing compilers this is no longer true.
DG> then the advantage of the Java language is lost - “high level”, don’t you think?
No, it doesn’t seem so.
Hello, Vyacheslav!
Friday May 02, 1997 02:09, Vyacheslav Mednonogov wrote to Dmitry Grigoryev:
VM>>> However, indeed, the problem of re-entry may
VM>>> arise on the Spectrum in the case of arr. interrupts.
DG>> So, what’s the problem? The main thing is that it does not output on
DG>> the stack and does not modify itself and its variables.
VM> Well, the problem is that the subroutine for some reason modifies its
VM> variables :)
Don’t allow it to do this :) Store parameters only on the stack or in registers.
Or let the calling procedure be responsible for the parameters. For example, like this:
LD IX,beginning of the variable area
CALL SB
...
SB:
...
LD (IX+x),A ; wrote down the variable
...
LD A,(IX+x) ; considered...
Although the brakes... It is better to do without writing variables into memory at all.
VM> Warm greetings, Slava.
Regards, Dmitry (OLDMAN).
DG>> will, for example, look like a text converter from one code table to
DG>> another?
RK> What should it look like? Such a converter can be made in the 1000 and 1
RK> way, in particular - how should the tables be set, where should the text be taken from and
RK> where should the text be output?
I will specify the task to the extreme :)
#6000 - the first 8-bit table (256 characters)
#6100 - the second table
#6200 db "Transcoding $%. Choose the fastest or shortest algorithm.
From you - the text of the program in C + compiled code in ASMA (or in
processor commands ;) with libraries, if they are used + be ready to explain
the principle of compilation...
From me - the text in ASMA (what else?) :)
RK> Yeah, probably the amount of time it takes to write them? I
RK> for example, it doesn’t matter if a text converter from one code table to
RK> another will take 1k or 44k (real figure), if they work with
RK> the same speed.
It doesn’t matter to you, a spektruman with a 600kb disk and 48 (128) memory - no.
Don't forget, we're only talking about the Z80 code compiler (even if it'swill be
implemented on PC).
RK> And also, I would be very interested to look at, for example, MS WORD
RK> 7, written in assembly language ;-)
I would also really like to :-) Just imagine how much space on the disk and
RAM it will take up and at what speed it will work :-))) Well come on
tell me that it would be worse... By the way, according to my information, the 7th Word was written in
VB, although this is not relevant ;)