From: user5857@newsgrouper.org.invalid
Paul Clayton posted:
> On 11/13/25 5:13 PM, MitchAlsup wrote:
> >
> > anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
> [snip]
> >> What I wanted to write was "And assembly language is
> >> architecture-specific".
> >
> > I have worked on a single machine with several different ASM "compilers".
> > Believe me, one asm can be different than another asm.
> >
> > But it is absolutely true that asm is architecture specific.
>
> Is that really *absolutely* true? Architecture usually includes binary
> encoding (and memory order model and perhaps other non-assembly details).
If/when you use an instruction in a more modern implementation,
that you HAVE made this program incompatible with prior implementations.
> I do not know if being able to have an interrupt in the middle of an
> assembly instruction is a violation of the assembly contract. (In
> theory, a few special cases might be handled such that the assembly
> instruction that breaks into more than one machine instruction is
> handled similarly to breaking instructions into µops.) There might not
> be any practical case where all the sub-instructions of an assembly
> instruction are also assembly instructions (especially not if
> retaining instruction size compatibility, which would be difficult
> with such assembly instruction fission anyway).
The real question is whether you support multiple memory instructions
Since we all seem to be supporting multiple data instructions (Vector
and SIMD).
In My 66000 case, Memory to Memory move is performed using indexing
from starting points {From and To}, Program status cache line maintains
the index when a MM is interrupted, so we can restart in the middle.
{Essentially no different than VAX except its an index instead of a
set of pointers}
> Self-modifying assembly obviously breaks with different encodings (as
> would using instruction encodings as data).
>
> If the assembly instructions were different sizes, control flow
> instructions could be broken if addresses or explicit displacements
> were used rather than abstract labels (which might not be allowed or
> merely considered bad practice). Jump tables would also be affected
> (such could also be fixed automatically if the jump table location and
> format is known).
In My 66000, jump tables are PIC.
> Obviously, one could also do the equivalent of complete binary
> recopmilation, which would usually not be considered the role of an
> assembler.
>
> I _feel_ that if only the opcode encoding is changed (a very tiny
> difference that would only affect using code as data) that one could
> rightly state that the new architecture uses the same assembly. I
> doubt there could be any economic justification for only changing the
> opcode encoding, but theoretically such could have multiple
> architectures with the same assembly.
>
> If one allows changing the placement of constants, register
> specifiers, and opcodes (without changing the machine code size of any
> assembly instruction) to still be the same assembly language (which I
> consider reasonable), the benefit of a new encoding might be
> measurable (albeit tiny and not worthwhile).
>
> If one allows assembly instructions to change in size as well as
> encoding (but retain even interrupt semantics), the assembler could
> still be very simple (which might justify still calling it an assembler).
In My 66000, compiler produces an abstract address. After linking when
the address/offset/displacement is manifest, Linker determines the size
of the instruction.
> If the assembly language includes macros (single assembly instruction
> that is assembled into multiple machine instructions), interrupt
> granularity should not be considered part of compatibility, in my
> opinion. Yes, behavior would change because some uninterruptable
> assembly instructions would become interruptable, but the mapping was
> already not simple.
I do not think anyone would think that converting macros into multiple
instructions in any way prevents interrupts from happening anywhere.
> If one allows pipeline reorganization in the assembler (as I think was
> considered a possibility for handling explicit pipelines that
> changed), then size changes would be allowed in which case substantial
> encoding changes should be allowed.
S/substantial/moderate/
> I do not think assembly language considered the possible effects of
> memory order model. (Have all x86 implementations been compatible? I
> think the specification changed, but I do not know if compatibility
> was broken.)
Agree with previous responder: programmer programs to memory model
not ASM.
> Upward compatibility is also a factor. Since one could say that adding
> assembly instructions to an assembly language does not change the
> language (like adding machine instructions does not change the
> architecture in terms of name (upwardly compatible family?)), one
> could argue that increasing the number of registers could maintain the
> same "assembly language' as well as increasing the size of registers.
But the use of said addition, prevent this program from running on
previous implementations.
> In addition to the definition for "assembly language" one also needs
> to define "architecture". In a very strict sense, x86-64 is not a
> single architecture — every different set of machine instructions
> would constitute a different architecture. Intel has sold incompatible
> architectures within the same design by fusing off functionality and
> has even had different application cores in the same chip have
> different instruction support (though that seems to have bit Intel).
The ISA is less than 1/3rd of an architecture:: you have
a) Memory management
b) exception management
c) interrupt management
d) system check management
e) PCIe Root Complex management
f) peripheral management
g) power management
h) frequency management
i) virtualization
j) Boot considerations
...
>
> AMD and Intel also differ slightly in architecture for one or two
> application-level instructions (as well as virtualization
> differences), but are considered the same architecture.
Requiring different builds for any sense of compatible performance.
> Architecture seems to be used in the fuzzy sense rather than the
> strict sense of 100% timing-independent compatibility,
You are only considering 1/3rd of what architecture IS.
> so it seems
> reasonable to have a fuzzier sense of assembly language to include at
> least encoding changes. It seems reasonable to me for "assembly
> language" to mean the preferred language for simple mapping to machine
> instructions (which can include idioms — different spellings of the
> same machine instruction — and macros).
The modern sense of ASM is that it is an ASCII version of binary.
The old sense where ASM was a language that could do anything and
[continued in next message]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
