public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Jesse Thompson <jesset@gmail.com>
To: cygwin@cygwin.com
Subject: Re: Request for an example x68 assembler portable Hello World script
Date: Fri, 26 Apr 2019 21:04:00 -0000	[thread overview]
Message-ID: <CA+wh7Kg+KDGN0b=-UFZ7UnX_fgHw69p_PXmdaqSrncHZsVGCbA@mail.gmail.com> (raw)
In-Reply-To: <CA+wh7Kg4UAO+_ZBONXbJ=3Hf9Tz6LSX2DX+LQNPLYqty4wkTag@mail.gmail.com>

> 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

  parent reply	other threads:[~2019-04-26 21:04 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-26  7:25 Jesse Thompson
2019-04-26 11:16 ` Eliot Moss
2019-04-26 21:04 ` Jesse Thompson [this message]
2019-04-27  1:56   ` Doug Henderson
2019-04-27 18:35   ` bzs
2019-04-28 20:00   ` Eliot Moss
2019-04-29 14:29     ` Sam Habiel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CA+wh7Kg+KDGN0b=-UFZ7UnX_fgHw69p_PXmdaqSrncHZsVGCbA@mail.gmail.com' \
    --to=jesset@gmail.com \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).