Request for an example x68 assembler portable Hello World script

Request for an example x68 assembler portable Hello World script

[Jesse Thompson]

I would like to learn how to write assembly programs for the command line
that with as little alteration as is feasable will compile both in Cygwin
and in other flavors of Unix like Linux and/or FreeBSD.

I am targeting only x64 CPUs and I'm perfectly happy to use libc calls
instead of direct syscalls or interrupts. I'm hoping to use nasm+gcc, or
perhaps fasm to do the deed. Crosspiling is not a concern, I'll build
cygwin binaries in cygwin and unix binaries in unix.

But I'm confused by the differences in calling convention/ABI between
Windows and/or Cygwin and Linux?

For example, I can get this to compile and run in Cygwin:

```
        global  main
        extern  puts
        section .text
main:
        sub     rsp, 20h                        ; Reserve the shadow space
        mov     rcx, message                    ; First argument is address
of message
        call    puts                            ; puts(message)
        add     rsp, 20h                        ; Remove shadow space
        ret
message:
        db      'Hello', 0                      ; C strings need a zero
byte at the end
```


but it segfaults in Linux (and complains about "Symbol `puts' causes
overflow in R_X86_64_PC32 relocation")

and I can get the following to compile and run in Linux:
```
    extern puts
    global main

section .text
main:
    mov rdi,message
    call puts
    ret

message:
    db  "Hello World",0
```

but *that* segfaults in cygwin.

TL;DR: I think I could get a lot more done if I could start from a single
Hello World asm file that can compile and run in both places, calling out
to puts or something simple like that.

Any help would be appreciated, I hope everything about my question makes
sense. :)

- - Jesse

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Request for an example x68 assembler portable Hello World script

[Eliot Moss]

On 4/26/2019 3:25 AM, Jesse Thompson wrote:
> I would like to learn how to write assembly programs for the command line
> that with as little alteration as is feasable will compile both in Cygwin
> and in other flavors of Unix like Linux and/or FreeBSD.
> 
> I am targeting only x64 CPUs and I'm perfectly happy to use libc calls
> instead of direct syscalls or interrupts. I'm hoping to use nasm+gcc, or
> perhaps fasm to do the deed. Crosspiling is not a concern, I'll build
> cygwin binaries in cygwin and unix binaries in unix.
> 
> But I'm confused by the differences in calling convention/ABI between
> Windows and/or Cygwin and Linux?
> 
> For example, I can get this to compile and run in Cygwin:
> 
> ```
>          global  main
>          extern  puts
>          section .text
> main:
>          sub     rsp, 20h                        ; Reserve the shadow space
>          mov     rcx, message                    ; First argument is address
> of message
>          call    puts                            ; puts(message)
>          add     rsp, 20h                        ; Remove shadow space
>          ret
> message:
>          db      'Hello', 0                      ; C strings need a zero
> byte at the end
> ```
> 
> 
> but it segfaults in Linux (and complains about "Symbol `puts' causes
> overflow in R_X86_64_PC32 relocation")
> 
> and I can get the following to compile and run in Linux:
> ```
>      extern puts
>      global main
> 
> section .text
> main:
>      mov rdi,message
>      call puts
>      ret
> 
> message:
>      db  "Hello World",0
> ```
> 
> but *that* segfaults in cygwin.
> 
> TL;DR: I think I could get a lot more done if I could start from a single
> Hello World asm file that can compile and run in both places, calling out
> to puts or something simple like that.
> 
> Any help would be appreciated, I hope everything about my question makes
> sense. :)

Der Jesse -- Someone else may be able to speak to the specifics, but
register use and calling conventions, and to some extent stack layout,
very from platform to platform.  Roughly, platform = processor + OS.
So (to me anyway) it would not be at all surprising if you have to
write code different for each of Windows, Cygwin, and Linux.  Cygwin
tries to offer library level compatibility for program designed to
run under Posix (there are some seams here and there, where Windows
differences are hard to hide).  But the programs have to be recompiled
to the Cygwin ABI.

Another thing you may be encountering is the difference between the
32-bit and 64-bit worlds.  Recent x86 processor support the x86_64
version as well.  Cygwin offers both 32 and 64 bit versions, but they
are distinct, and a program needs to be compiled to the one under
which you wish to run it.  (I have both 32 and 64 bit Cygwin on my
computer, and the programs can invoke one another, but the installations
need to be in separate file hierarchies.)  The same would tend to hold
under Linux and Windows, though the OS can determine automatically
for a given program whether it is 32 or 64 bit from details of the
first bytes of the executable file.

Regards - EM

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Request for an example x68 assembler portable Hello World script

[Jesse Thompson]

> From: Eliot Moss <moss@cs.umass.edu>
> To: cygwin@cygwin.com
> Date: Fri, 26 Apr 2019 07:16:38 -0400
> Subject: Re: Request for an example x68 assembler portable Hello World
script
>
> Der Jesse -- Someone else may be able to speak to the specifics, but
> register use and calling conventions, and to some extent stack layout,
> very from platform to platform.  Roughly, platform = processor + OS.
> So (to me anyway) it would not be at all surprising if you have to
> write code different for each of Windows, Cygwin, and Linux.  Cygwin
> tries to offer library level compatibility for program designed to
> run under Posix (there are some seams here and there, where Windows
> differences are hard to hide).  But the programs have to be recompiled
> to the Cygwin ABI.
>
> Another thing you may be encountering is the difference between the
> 32-bit and 64-bit worlds.  Recent x86 processor support the x86_64
> version as well.  Cygwin offers both 32 and 64 bit versions, but they
> are distinct, and a program needs to be compiled to the one under
> which you wish to run it.  (I have both 32 and 64 bit Cygwin on my
> computer, and the programs can invoke one another, but the installations
> need to be in separate file hierarchies.)  The same would tend to hold
> under Linux and Windows, though the OS can determine automatically
> for a given program whether it is 32 or 64 bit from details of the
> first bytes of the executable file.
>
> Regards - EM

Hello Elliot, thank you for your reply.

On one point, yes I do appreciate the difference between 32-bit and 64-bit
installations of Cygwin. However for many years now I have been blessed by
being able to use only the 64 bit version, just as I only run 64 bit
versions of Windows and Linux/BSD operating systems on 64 bit processors.

To this end, I wish to be able to entirely leave behind any bonds to the 32
bit architectures. My software won't have to support them, and ideally
won't even have to acknowledge their existences. ;)

My software also won't have to support non-POSIX Windows libraries, and
should only need to relate to windows through the Cygwin POSIX libraries.

So while I can appreciate that C (and other higher level language)
compilers might hide some of the implementational details of moving from
one platform or calling convention to another, and that Cygwin's libraries
exist to help spackle over some of those other potential differences so
that at least a majority of C code written for Unix OSen can compile and
run in a windows environment, aren't there some pieces of Unix software
that include assembly? What process do developers have to go through to
port *those* bits of software that stray from the safety of higher level
compilers?

Ultimately what I am trying to research is how to begin building a simple
compilation system of my own, so how do the *makers* of compilers deal with
these differences in calling convention?

Thank you for your insight, I hope you are all having a great day and
enjoying this lovely spring weather. :)

>

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Request for an example x68 assembler portable Hello World script

[Doug Henderson]

On Fri, 26 Apr 2019 at 15:04, Jesse Thompson <> wrote:
>
> > From: Eliot Moss <>
> > To: cygwin@cygwin.com
> > Date: Fri, 26 Apr 2019 07:16:38 -0400
> > Subject: Re: Request for an example x68 assembler portable Hello World


> Ultimately what I am trying to research is how to begin building a simple
> compilation system of my own, so how do the *makers* of compilers deal with
> these differences in calling convention?

Each hardware and OS combination will usually publish an ABI (an
Application Binary Interface) specification that defines how to call
the OS services, and how applications should call each other and
vendor supplied libraries. Compiler authors will usually generate code
which adheres to these specifications. The C compiler will generate
code that will call the OS and external code accordingly to the
specification. Authors of assembler code must abide by the ABI if they
want their code to inter-operate with the OS and external higher level
language code, however they are free to use any calling convention
they like within their own code.

This page: https://cs.lmu.edu/~ray/notes/gasexamples/ illustrates the
ABI for calling the OS and C-language from assembler in a linux os on
an intel or amd 64-bit cpu. The calling conventions used by Windows on
the same hardware is different, due to different ABIs for those two
OSs.

The GNU Compiler Collection (GCC) support a C-language feature that
allows you to embed assembler instruction in C and C++ code. In this
scenario, one writes otherwise normal C functions where the body of
the function is replaced by assembler instructions (or a mix of C and
assembler). The C compiler generates the correct code for the ABI. And
the assembler code can reference the function arguments by name,
regardless of how they were passed to the function. See:
https://gcc.gnu.org/onlinedocs/gcc/index.html the "Using the GNU
Compiler Collection (GCC)" document. See section 6.47 'How to Use
Inline Assembly Language in C Code" for details.

When you stray from the GNU path, though, things can get more chaotic
where platforms must be considered on a case by case basis.

Have you looked at VM based implementations? These use an intermediate
assembler-like language which is executed on a virtual machine. The VM
is specific to each platforms, but attempts to allow the "Write once,
run anywhere" goal of Java.

HTH,
Doug

-- 
Doug Henderson, Calgary, Alberta, Canada - from gmail.com

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Request for an example x68 assembler portable Hello World script

[bzs]

Just two thoughts:

1. You probably know that 'cc -S foo.c' produces foo.s which is the
assembler output. Might be worthwhile examining how the experts who
wrote the C compiler handle all this. The output is usually quite
readable for someone prone to reading such things.

2. Rather than generating asm some developers generate C and run that
thru the C compiler. One advantage is you can leverage all the C code
optimization and debugging etc infrastructure and anything else you
can find on the C and ld etc man pages (e.g., PIC.)

But there's nothing wrong with learning assemblers and machine
languages. In the distant past I taught it for several years at Boston
University so, good luck!

-- 
        -Barry Shein

Software Tool & Die    | bzs@TheWorld.com             | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD       | 800-THE-WRLD
The World: Since 1989  | A Public Information Utility | *oo*

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Request for an example x68 assembler portable Hello World script

[Eliot Moss]

On 4/26/2019 5:04 PM, Jesse Thompson wrote:

> Ultimately what I am trying to research is how to begin building a simple
> compilation system of my own, so how do the *makers* of compilers deal with
> these differences in calling convention?

They make parts of the compilers conditional on the overall platform.
For example, if a compiler is written in C / C++, they use #define
and #if tests, and may include different modules in a build, etc.

They also try to code various algorithms, such a register allocation,
to be parameterized by a description of how things work on a given
platform.

There are whole swaths that are essentially target independent,
especially those having to do with higher level optimizations.
However, even there, platform differences may lead to different
parameter settings (e.g., default number of times to unroll a
loop) or strategies (presence / absence of vector units and
of predicated instructions (as on the ARM) affect how you want
to generate even the high-level target-independent code).

In the case that you are talking about, most of the code generation
and optimization strategies are the same -- there are just some
fine points different about calling sequences, register usage
conventions, etc.  I think those are mostly addressed by the kind
of parameterization-by-descriptions (or by #defines) that I have
described.

You may still see somewhat different code from different compilers,
even for the same platform, simply because the different designers
chose different base code sequences - which may be equivalent. For
example, to move a constant into a register, add-immediate (adding
to zero) and or-immediate (again, ORing with zero) give the same
result for many arguments, to the choice is arbitrary.  One can
come up with many such examples.

Supporting multiple target instruction sets, or even the range of
models of the x86 line, requires some amount of platform-specific
work, of course, and lot of attention to how to build components
that are either independent of the ISA or retargetable in some way.

Regards - Eliot Moss

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Request for an example x68 assembler portable Hello World script

[Sam Habiel]

I frequently cannot contribute discussion to Cygwin topics, but due to
my work porting a database (fis-gtm) to Cygwin, I can chime in here.

This is a good article to give you an overview of the different
calling conventions out there:
https://eli.thegreenplace.net/2011/09/06/stack-frame-layout-on-x86-64.

Here's a summary of what I learned:
1. Cygwin x32 and Linux x32 use the same assembly layout--application
binary interface (ABI).
2. Cygwin x64 uses the Windows 64 ABI. Linux x64 uses the AMD64 ABI.

This tutorial article is a good place to learn about x64 ABI for
Linux: https://cs.lmu.edu/~ray/notes/gasexamples/.

--Sam

On Sun, Apr 28, 2019 at 4:00 PM Eliot Moss <moss@cs.umass.edu> wrote:
>
> On 4/26/2019 5:04 PM, Jesse Thompson wrote:
>
> > Ultimately what I am trying to research is how to begin building a simple
> > compilation system of my own, so how do the *makers* of compilers deal with
> > these differences in calling convention?
>
> They make parts of the compilers conditional on the overall platform.
> For example, if a compiler is written in C / C++, they use #define
> and #if tests, and may include different modules in a build, etc.
>
> They also try to code various algorithms, such a register allocation,
> to be parameterized by a description of how things work on a given
> platform.
>
> There are whole swaths that are essentially target independent,
> especially those having to do with higher level optimizations.
> However, even there, platform differences may lead to different
> parameter settings (e.g., default number of times to unroll a
> loop) or strategies (presence / absence of vector units and
> of predicated instructions (as on the ARM) affect how you want
> to generate even the high-level target-independent code).
>
> In the case that you are talking about, most of the code generation
> and optimization strategies are the same -- there are just some
> fine points different about calling sequences, register usage
> conventions, etc.  I think those are mostly addressed by the kind
> of parameterization-by-descriptions (or by #defines) that I have
> described.
>
> You may still see somewhat different code from different compilers,
> even for the same platform, simply because the different designers
> chose different base code sequences - which may be equivalent. For
> example, to move a constant into a register, add-immediate (adding
> to zero) and or-immediate (again, ORing with zero) give the same
> result for many arguments, to the choice is arbitrary.  One can
> come up with many such examples.
>
> Supporting multiple target instruction sets, or even the range of
> models of the x86 line, requires some amount of platform-specific
> work, of course, and lot of attention to how to build components
> that are either independent of the ISA or retargetable in some way.
>
> Regards - Eliot Moss
>
> --
> Problem reports:       http://cygwin.com/problems.html
> FAQ:                   http://cygwin.com/faq/
> Documentation:         http://cygwin.com/docs.html
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
>

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple