iup-users

[Iup-users] (Re: I figured it out, finally): Sad to see your IUP/Linux troubles...

[sur-behoffski <sur...@gr...>]

G'day,

Sorry to hear about your troubles.  As you know, I resorted
to extraordinary lengths (lglicua SourceForge project) to get
IM/CD/IUP to compile under GNU/Linux, especially GCC.


As far as I'm aware, no-one tries to write programs directly
in assembler, and only assembler.  The usual framework I've
seen is to use C to set things up, declare an external function,
and then have that function, written in assembler, interface
with GCC.

This is because of a simple programming maxim:  Try to write
your program in the least number of "simple" or "reasonable"
lines, using programming languages that support high-level
abstractions, as a single line in a high-level language may
translate into many thousands or even millions of lines in
low-level languages such as assembler/machine code.

(APL?  SQL?  R?  Python?  Matlab?  Lua?  A spreadsheet?  A
virtual machine?  A network of clustered machines?)

Basically, revert to a lower-level language only when the
higher-level language cannot model it (e.g. some hardware
features of CPUs and/or GPUs), often due to a desire to gain
performance.

As a rule of thumb, code is read perhaps 10 times more often
than it is written, and it takes perhaps the same amount of
time to write a code in any language -- therefore, always
strive to minimise the drift to lower languages.

Sometimes, algorithm changes or highly expressive languages
can give startling results.  For an example of this, consider
Conway's game of Life:

    - Look up HashLife, that can simulate billions of
      generations efficiently; and/or
    - A YouTube demo of Life in APL, with the final run
      given in a single line of APL:

          https://www.youtube.com/watch?v=a9xAKttWgP4

----

As a worked example, the C program "hw.c":

        #include <stdio.h>

        static void p(char *pStr)
        {
                printf("%s\n", pStr);
        }


        int main(void)
        {
                p("Hello, World");
                return 0;
        }

can be compiled to show the assembly-language output via:

        gcc -O0 -Wa,-ahl hw.c

The "-Wa," incantation means 'send the rest of this argument
as a command-line item ("-ahl") to the assembler'.

The gcc command produces the following output:

--------------------------------------------------------------------


GAS LISTING /tmp/ccpTGSO4.s 			page 1


   1              		.file	"hw.c"
   2              		.text
   3              		.type	p, @function
   4              	p:
   5              	.LFB0:
   6              		.cfi_startproc
   7 0000 55       		pushq	%rbp
   8              		.cfi_def_cfa_offset 16
   9              		.cfi_offset 6, -16
  10 0001 4889E5   		movq	%rsp, %rbp
  11              		.cfi_def_cfa_register 6
  12 0004 4883EC10 		subq	$16, %rsp
  13 0008 48897DF8 		movq	%rdi, -8(%rbp)
  14 000c 488B45F8 		movq	-8(%rbp), %rax
  15 0010 4889C7   		movq	%rax, %rdi
  16 0013 E8000000 		call	puts@PLT
  16      00
  17 0018 90       		nop
  18 0019 C9       		leave
  19              		.cfi_def_cfa 7, 8
  20 001a C3       		ret
  21              		.cfi_endproc
  22              	.LFE0:
  23              		.size	p, .-p
  24              		.section	.rodata
  25              	.LC0:
  26 0000 48656C6C 		.string	"Hello, World"
  26      6F2C2057 
  26      6F726C64 
  26      00
  27              		.text
  28              		.globl	main
  29              		.type	main, @function
  30              	main:
  31              	.LFB1:
  32              		.cfi_startproc
  33 001b 55       		pushq	%rbp
  34              		.cfi_def_cfa_offset 16
  35              		.cfi_offset 6, -16
  36 001c 4889E5   		movq	%rsp, %rbp
  37              		.cfi_def_cfa_register 6
  38 001f 488D0500 		leaq	.LC0(%rip), %rax
  38      000000
  39 0026 4889C7   		movq	%rax, %rdi
  40 0029 E8D2FFFF 		call	p
  40      FF
  41 002e B8000000 		movl	$0, %eax
  41      00
  42 0033 5D       		popq	%rbp
  43              		.cfi_def_cfa 7, 8
  44 0034 C3       		ret
  45              		.cfi_endproc
  46              	.LFE1:
  47              		.size	main, .-main
  48              		.ident	"GCC: (Gentoo 13.2.1_p20230826 p7) 13.2.1 20230826"
  49              		.section	.note.GNU-stack,"",@progbits

----------------------------------------------------------------

Hope this helps,

sur-behoffski (Brenton Hoff)
programmer, Grouse Software

Re: [Iup-users] (Re: I figured it out, finally): Sad to see your IUP/Linux troubles...

[Anonymous <ano...@gm...>]

On 9/27/23 17:27, sur-behoffski wrote:
> G'day,
>
> Sorry to hear about your troubles.  As you know, I resorted
> to extraordinary lengths (lglicua SourceForge project) to get
> IM/CD/IUP to compile under GNU/Linux, especially GCC.

Yes, thank you for your effort, although that wasn't a solution to my 
actual problem.

> As far as I'm aware, no-one tries to write programs directly
> in assembler, and only assembler.
Well now you can say you are finally aware of someone. With time maybe 
you will discover some more :)
> This is because of a simple programming maxim:  Try to write
> your program in the least number of "simple" or "reasonable"
> lines, using programming languages that support high-level
> abstractions, as a single line in a high-level language may
> translate into many thousands or even millions of lines in
> low-level languages such as assembler/machine code.

Actually the exact opposite is more likely to be true: use whatever 
language that uses the least abstraction/obfuscation/disconnect from 
what you are trying to do. Only asm can do that (and only big 
monopolies/corporations would want you to believe otherwise because they 
want something they can control or install backdoors into).

Have you ever tried to program an app using asm? I don't think so. Every 
program ever written in any language is translated into assembly 
language, I'm just skipping over all those steps to get there. And 
writing in asm using macros isn't much different from writing in C.

> Basically, revert to a lower-level language only when the
> higher-level language cannot model it (e.g. some hardware
> features of CPUs and/or GPUs), often due to a desire to gain
> performance.
Most programs are no faster in asm than they are in any other language. 
There are only small sections of code where that is true.
> As a rule of thumb, code is read perhaps 10 times more often
> than it is written, and it takes perhaps the same amount of
> time to write a code in any language -- therefore, always
> strive to minimise the drift to lower languages.
Most programs are unreadable spaghetti code, even the ones written in C, 
so readability isn't the issue :)
> Sometimes, algorithm changes or highly expressive languages
> can give startling results.  For an example of this, consider
> Conway's game of Life:
>
>      - Look up HashLife, that can simulate billions of
>        generations efficiently; and/or
>      - A YouTube demo of Life in APL, with the final run
>        given in a single line of APL:
>
>            https://www.youtube.com/watch?v=a9xAKttWgP4
>
> ----
>
> As a worked example, the C program "hw.c":
>
>          #include <stdio.h>
>
>          static void p(char *pStr)
>          {
>                  printf("%s\n", pStr);
>          }
>
>
>          int main(void)
>          {
>                  p("Hello, World");
>                  return 0;
>          }
>
> can be compiled to show the assembly-language output via:
>
>          gcc -O0 -Wa,-ahl hw.c
>
> The "-Wa," incantation means 'send the rest of this argument
> as a command-line item ("-ahl") to the assembler'.
>
> The gcc command produces the following output:

That output would not assemble in any assembler known to mankind. GCC 
obviously isn't a good way to learn assembly, especially with that lame 
AT&T syntax and gobs of non-asm directives/pragmas that have nothing to 
do with the code but with GCC tasks. The Intel syntax (which is the only 
syntax that reads like all processor manuals are written) is way more 
readable. And like I said, using the NASM macro capability that program 
looks like this in assembly...

locf main
	body
	invoke p,"Hello World"
	rtn 0
	endf
locf p,pStr
	body
	invoke printf,"%s\n",[pStr]
	rtn
	endf

If you had actually written a program in asm, you would know that :)

The advantage of asm over any higher level language is that I can do 
anything I want with it because I'm not limited to only whatever the 
language was programmed to allow me to do. I don't have to worry about 
gobs of unnecessary type conversions or inane syntax conventions. 
Nothing about any program is hidden or abstracted from me. I don't have 
to install anything to get it to work, other than NASM (although I 
haven't tried to run NASM as a standalone program in Linux like I could 
in Windows ... yet. In fact, in Windows I could program, assemble, and 
run entire entire apps from just a 1Mb USB stick).

So why are you preaching to me about how you don't like me programming 
in assembly? It doesn't matter to you one bit what I do, does it? Of 
course not.

Signed,
Andres