Talk:Assembly language

Some architectures, e.g., IBM System/360,^[1] UNIVAC III,^[2] have truncated addressing; an instruction does not have enough room for a full address, only an offset against a specified register. Assemblers^[3][4][5][a] for those architecture typically have special feature to assist in dealing with addressing, e.g., DSECT and USING for S/360 through IBM z/Architecture. I believe that the article should discuss the issue and give some illustrative examples. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:13, 20 June 2024 (UTC)

Truncated addressing seems like it goes to address mode, but yes, the assembler features needed could go here. Many RISC processors seem to have 32 bit instructions, and 32 bit addresses, which requires some way to encode an address in two instructions. That, then, usually means some assembler feature to generate such code. I would guess that a feature like DSECT isn't so unusual, but USING might be rare. Gah4 (talk) 00:26, 21 June 2024 (UTC)

Many more recent processors use PC relative addressing, which avoids the need for USING for code addresses. Addressing DSECT is a different question, and I don't know enough different assemblers to know. And I think PC relative addressing should have its own page. Gah4 (talk) 04:48, 21 June 2024 (UTC)

Describing PC-relative addressing and describing assembler support for it are two separate issues, and I believe that there is a case for both. Note that processors as far back as Atlas, GE 635 and DEC PDP-11 allowed indexing by the program counter, long before RISC architectures, e.g., IBM 801 , Power ISA. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 10:59, 21 June 2024 (UTC)

Note also that not all PC-relative addressing is general; some architectures support only PC-relative branching. SPARC, for example, has PC-relative branching with 22-bit displacements, plus a procedure-call instruction with a 30-bit displacement (if the upper 2 bits of the instruction are 01, it's a CALL instruction). Load and store instructions have either 2 register operands, or a register operand and a 13-bit offset, that are added together to generate the memory address. There's no equivalent of USING in SPARC assembler languages, but relatively little assembler-language programming is done for SPARC, unlike System/3x0. (And, for an OS that runs on S/390 and z/Architecture, related to the OSes that run on SPARC, the assembler doesn't, as far as I know, offer any equivalent to USING, as there's not much assembler-language programming done there, either - about 28 files with 4035 lines in the kernel and 91 files with 11160 lines in GNU libc.) — Preceding unsigned comment added by Guy Harris (talk • contribs) 20:13, 21 June 2024 (UTC)

Modern processors discourage mixing of code and data. Especially those with separate code and data cache, where it causes much problems. (That is, slow execution.) I am not, then, surprised that they don't supply PC relative data references. A common use of USING, along with DSECT, is named references to structure members. I suspect some assemblers have a way to do that. (That is, what would be part of a C struct.) USING used to be used for data references in the code, but, as above, that is now discouraged. Gah4 (talk) 21:46, 21 June 2024 (UTC)

Modern processors discourage mixing of code and data. Heck, the PDP-11 at least didn't encourage it, especially with separate I and D space. Unix programs tended to be built with separate code and data segments, and the code segment was often mapped shared and read-only; some DEC operating systems may have done the same. PC-relative data references were, I think, mostly auto-increment; that's how immediate operands were implemented.

...named references to structure members. I suspect some assemblers have a way to do that. Named references to structure members is independent of the size of displacements in instructions. 4BSD, at least, had a C program, genassym, which included a bunch of system headers and generated a file with a bunch of #defines for the offsets of various structure members, as part of the kernel generation and build process. The resulting assym.s file would be #included by assembler-language files that needed to refer to those structures. UN*X assemblers tended not to provide full-blown macro facilities or other assists such as DSECTs, as it was not expected that assembly language would be used except in rare cases where either 1) you needed to use specialized instructions to control the machine or 2) hand-coded some low-level routines such as memory copying, string manipulation, and language support such as larger-than-word-size integer arithmetic (e.g., 32-bit integers on a 16-bit platform or 64-bit integers on a 32-bit platform). They sometimes supported using the C preprocessor as a primitive macro facility, but that's about it. Guy Harris (talk) 22:23, 21 June 2024 (UTC)

Actually, HLASM runs on zLinux, although probably not Solaris; it's a gas (gd&r).

Somewhat perversely, z/Architecture has a 16-bit relative and a 32-bit relative long; IMHO a 64 KiB single code section is much too large, to say nothing of 4 GiB code sections. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 00:02, 22 June 2024 (UTC)

I suspect I have been surprised by many features added to z/Architecture by now. But some relative branches can be resolved at link time, and so branch more than a single code section. If the linkage editor still has the ability to relink previously linked code, it will need to be able to unresolve such branches. As far as I know, Java still has a 64K byte limit for a single method. Gah4 (talk) 01:10, 22 June 2024 (UTC)

I doubt that the linkage editor can handle branch relative berween CSECTs, but possibly the Binder can. I'll have to check the Program Management manual. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 04:10, 23 June 2024 (UTC)

Actually, HLASM runs on zLinux, although probably not Solaris ...because OpenSolaris for System z was discontinued; otherwise, IBM might have ported it.

Was HLASM ported to Linux to support moving existing assembler-language code to Linux? Guy Harris (talk) 06:22, 22 June 2024 (UTC)

That would be my guess. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 04:02, 23 June 2024 (UTC)

Could the huge range of the relative long instructions be for compiler support of monolithic C, COBOL, FORTRAN and PL/I applications? -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 04:02, 23 June 2024 (UTC)

On Linux (and, were the project to have finished, on Solaris), it would more likely have been for compiler support of large shared libraries in C/C++/etc.; for executable images, PIC is only necessary if you're building position-independent executables whose starting address can be randomized. I can't speak for z/OS (or VSE or z/TPE). Guy Harris (talk) 10:47, 23 June 2024 (UTC)

IBM assemblers use DSECT in about the way that C programmers use struct. That is, for computing offsets into data structures. (In the case of struct pointers, that is all the compiler does. For an actual struct, it also allocates memory.) What I am wondering now, is which other assemblers have a similar feature? This would be the case where the assembler computes the offsets, and not a series of (the equivalent of) #define. Gah4 (talk) 23:31, 23 June 2024 (UTC)