Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.os.development > #8251 > unrolled thread

Re: What form of executable or load module for your OS?

Back to article view | Back to alt.os.development

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: What form of executable or load module for your OS? "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-06-25 21:20 -0700
    Re: What form of executable or load module for your OS? "James Harris" <james.harris.1@gmail.com> - 2015-07-01 10:36 +0100
      Re: What form of executable or load module for your OS? "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-07-01 21:07 -0700
        Re: What form of executable or load module for your OS? "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-07-02 23:35 -0700
          Re: What form of executable or load module for your OS? "James Harris" <james.harris.1@gmail.com> - 2015-07-03 08:35 +0100
            Re: What form of executable or load module for your OS? "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-07-03 02:49 -0700
              Re: What form of executable or load module for your OS? "James Harris" <james.harris.1@gmail.com> - 2015-07-03 11:27 +0100
                Re: What form of executable or load module for your OS? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-03 16:54 -0400
                  Re: What form of executable or load module for your OS? "James Harris" <james.harris.1@gmail.com> - 2015-07-03 22:45 +0100
                    Re: What form of executable or load module for your OS? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-03 17:56 -0400
                    Re: What form of executable or load module for your OS? "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-07-03 15:28 -0700
                      Re: What form of executable or load module for your OS? "James Harris" <james.harris.1@gmail.com> - 2015-07-03 23:48 +0100
                        Re: What form of executable or load module for your OS? "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-07-03 21:52 -0700
                        Re: What form of executable or load module for your OS? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-04 04:00 -0400
                          Re: What form of executable or load module for your OS? "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-07-04 04:42 -0700
                            Re: What form of executable or load module for your OS? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-05 02:12 -0400
                              Re: What form of executable or load module for your OS? "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-07-05 00:47 -0700
                                Re: What form of executable or load module for your OS? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-05 05:28 -0400
                                  Re: What form of executable or load module for your OS? "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-07-05 02:58 -0700
                            Re: What form of executable or load module for your OS? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-06 06:21 -0400
                              Re: What form of executable or load module for your OS? "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-07-07 01:44 -0700
                                Re: What form of executable or load module for your OS? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-07 05:40 -0400
                                  Re: What form of executable or load module for your OS? "Kerr Mudd-John" <admin@127.0.0.1> - 2015-07-07 14:02 +0100
                                    Re: What form of executable or load module for your OS? "wolfgang kern" <nowhere@never.at> - 2015-07-07 18:13 +0200
                                      Re: What form of executable or load module for your OS? "Kerr Mudd-John" <notsaying@invalid.org> - 2015-07-08 12:54 -0100
                                        Re: What form of executable or load module for your OS? "James Harris" <james.harris.1@gmail.com> - 2015-07-09 13:19 +0100
                                  Re: What form of executable or load module for your OS? "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-07-07 22:10 -0700
                                    Re: What form of executable or load module for your OS? "James Harris" <james.harris.1@gmail.com> - 2015-07-08 08:48 +0100
                                      Re: What form of executable or load module for your OS? "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-07-08 23:53 -0700
                                      Re: What form of executable or load module for your OS? "James Harris" <james.harris.1@gmail.com> - 2015-07-09 17:29 +0100
                                        Re: What form of executable or load module for your OS? "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-07-10 01:01 -0700
                                          Re: What form of executable or load module for your OS? "James Harris" <james.harris.1@gmail.com> - 2015-07-10 13:46 +0100
                                      Re: What form of executable or load module for your OS? "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-07-10 00:59 -0700
                                    Re: What form of executable or load module for your OS? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-08 03:52 -0400
                                      Re: What form of executable or load module for your OS? "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-07-08 06:46 -0700
                                      Re: What form of executable or load module for your OS? "James Harris" <james.harris.1@gmail.com> - 2015-07-09 13:16 +0100
                                      Re: What form of executable or load module for your OS? "s_dubrovich@yahoo.com" <s_dubrovich@yahoo.com> - 2015-07-11 09:57 -0700
                                        Re: What form of executable or load module for your OS? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-13 02:47 -0400
                                          Re: What form of executable or load module for your OS? "s_dubrovich@yahoo.com" <s_dubrovich@yahoo.com> - 2015-07-14 07:39 -0700
                                            Re: What form of executable or load module for your OS? "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-15 02:37 -0400
          Code insanity "Mike Gonta" <mikegonta@gmail.com> - 2015-07-03 03:47 -0400
            Re: Code insanity "Alexei A. Frounze" <alexfrunews@gmail.com> - 2015-07-03 02:57 -0700
            Re: Code insanity (was: What form of executable or load module for your OS?) "James Harris" <james.harris.1@gmail.com> - 2015-07-03 11:35 +0100

Page 1 of 3  [1] 2 3  Next page →

#8251 — Re: What form of executable or load module for your OS?

On Wednesday, June 24, 2015 at 4:34:48 AM UTC-7, James Harris wrote:
> We may have discussed this in the past but while I can find related 
> discussions I cannot find anything specifically the same so....
> 
> If you have a working OS what form of executable does it load and 
> execute, of if your OS is in development what form of executable are you 
> thinking to support?

I will not be original. For 16-bit mode x86 DOS' .COM/.EXE, ELF for
everything else. Good enough and there exist tools and code that can
work with these formats.

> I am currently facing the question and have come up with *some* answers, 
> some of which may surprise you, and some of which may be nonsense, ... 
> and some or all of the elements of those two sets may intersect. :-|
> 
> First, for me, whatever format is used needs to be a form that can be 
> constructed by existing build tools so that I can create modules in that 
> form. Presumably you had or have the same issue, unless you made your 
> own build tools.
> 
> Second, it needs to be a form that can be constructed without the 
> toolchain building-in something specific to an existing OS (unless my OS 
> is going to support that feature which is unlikely).

As you probably know, I now have Smaller C self-hosting in DOS, Windows
and Linux. That's plenty of freedom for cross-compiling to a custom OS.
Once NASM (or something else like FASM) is ported to it, cross-compiling
can be abandoned (though, FASM is a little problematic for Smaller C
w.r.t. sections).

If you want something fancy, you may need a different format, though,
but most of the traditional uses are or can be supported in .COM/.EXE
and ELF.

Alex

[toc] | [next] | [standalone]

#8256

"Alexei A. Frounze" <alexfrunews@gmail.com> wrote in message 
news:5bb535cc-0995-4fdd-ae16-a1217c4b8e92@googlegroups.com...
> On Wednesday, June 24, 2015 at 4:34:48 AM UTC-7, James Harris wrote:

...

>> If you have a working OS what form of executable does it load and
>> execute, of if your OS is in development what form of executable are 
>> you
>> thinking to support?
>
> I will not be original. For 16-bit mode x86 DOS' .COM/.EXE, ELF for
> everything else. Good enough and there exist tools and code that can
> work with these formats.

That makes sense, though choosing an *object module* form for 16-bit x86 
is harder. They seem to have multiplied like rabbits!

James

[toc] | [prev] | [next] | [standalone]

#8263

On Wednesday, July 1, 2015 at 2:36:13 AM UTC-7, James Harris wrote:
> "Alexei A. Frounze" <...@gmail.com> wrote in message 
> news:5bb535cc-0995-4fdd-ae16-a1217c4b8e92@googlegroups.com...
> > On Wednesday, June 24, 2015 at 4:34:48 AM UTC-7, James Harris wrote:
> 
> ...
> 
> >> If you have a working OS what form of executable does it load and
> >> execute, of if your OS is in development what form of executable are 
> >> you
> >> thinking to support?
> >
> > I will not be original. For 16-bit mode x86 DOS' .COM/.EXE, ELF for
> > everything else. Good enough and there exist tools and code that can
> > work with these formats.
> 
> That makes sense, though choosing an *object module* form for 16-bit x86 
> is harder. They seem to have multiplied like rabbits!

Not necessarily. The same ELF can do. As you might already know, there
are extensions in ELF allowing 16-bit relocations and they are supported
by NASM and GNU as/ld. These extensions are just 2 additional relocation
types, modeled after 32-bit relocation and differing only in that they
apply to 16-bit entities (immediates/offsets) instead of 32-bit ones.
The mechanics is the same. I make use of this in my compiler and linker.
IOW, for the tiny and small memory models everything is straightforward
and ELF just works.

If you want to support multiple segments, it's not hard to do. The
simplest way would be to put individual subroutines and data objects
into individual sections, each aligned on a 16-byte boundary.
With that you can refer to each by simply using a segment value and an
offset of 0, both trivially derived from the linear 32-bit address of
the section start. If you want it less wasteful, combine several objects
into the same section (just make sure that each such section is never
larger than 64KB). Even though ELF does not support segments directly,
there's nothing in it precluding you from using it for segmented memory
models. You may, however, need some additional information in the file
to address some of segment-related relocations. E.g. for something like

mov ax, seg foo

you'd need to emit mov ax, 0 and make a note for the linker that the
immediate is to be a properly relocated segment selector of foo.
And the same for things like:

pfoo dd foo ; pfoo to contain seg:ofs of foo
call [far] foo ; ditto

My compiler emits additional information for things like above
into dedicated sections when compiling for the DOS huge memory
model. The linker and the start-up code take care of the rest
using this info.

Alex

[toc] | [prev] | [next] | [standalone]

#8271

On Thursday, July 2, 2015 at 4:27:25 AM UTC-7, James Harris wrote:
> "Alexei A. Frounze" <...@gmail.com> wrote in message 
> news:c80bcbf7-a245-45a7-bb30-21e5660c2959@googlegroups.com...
> > On Wednesday, July 1, 2015 at 2:36:13 AM UTC-7, James Harris wrote:
> >> "Alexei A. Frounze" <...@gmail.com> wrote in message
> >> news:5bb535cc-0995-4fdd-ae16-a1217c4b8e92@googlegroups.com...
> >> > On Wednesday, June 24, 2015 at 4:34:48 AM UTC-7, James Harris 
> >> > wrote:
> >>
> >> ...
> >>
> >> >> If you have a working OS what form of executable does it load and
> >> >> execute, of if your OS is in development what form of executable 
> >> >> are
> >> >> you
> >> >> thinking to support?
> >> >
> >> > I will not be original. For 16-bit mode x86 DOS' .COM/.EXE, ELF for
> >> > everything else. Good enough and there exist tools and code that 
> >> > can
> >> > work with these formats.
> >>
> >> That makes sense, though choosing an *object module* form for 16-bit 
> >> x86
> >> is harder. They seem to have multiplied like rabbits!
> >
> > Not necessarily. The same ELF can do. As you might already know, there
> > are extensions in ELF allowing 16-bit relocations
> 
> No, I wasn't aware of 16-bit ELF extensions. I have been looking into 
> this with the other info you mentioned (snipped) and can see that the 
> relocation types exist and have built a load module in Nasm to use them.

A "load module"? What's that?

> However, I am not sure that I could use the extensions. I haven't (yet) 
> found a way to get from C source to 8086 ELF object code.

You mean, you don't know of any 8086 C compilers producing ELFs?
Mine might be, if not among the very few, the only one.

> Incidentally, you mentioned segment support in C. Just to be clear, my 
> requirements are not as complicated as that as my C code doesn't do 
> anything which is not standard C. So I don't have any explicit segment 
> or offset separation in the source.

In your C source? My compiler doesn't support any segments at the
source level either and hides all the segmentation insanity in the
huge memory model from the programmer (the insanity is visible in
the generated assembly code, of course), making the one megabyte of
memory look contiguous. And in the tiny and small memory models there
isn't anything to hide.

> The C code I write is linked with 
> assembly and, for the 8086-output model, the total code size is under 
> 64k. That allows such programs to be built as tiny or small model (aka 
> impure and pure) executables.

OK.

Alex

[toc] | [prev] | [next] | [standalone]

#8272

"Alexei A. Frounze" <alexfrunews@gmail.com> wrote in message 
news:75acded2-9f64-4d9f-81c2-7ec73fd72e01@googlegroups.com...
> On Thursday, July 2, 2015 at 4:27:25 AM UTC-7, James Harris wrote:

...

>> No, I wasn't aware of 16-bit ELF extensions. I have been looking into
>> this with the other info you mentioned (snipped) and can see that the
>> relocation types exist and have built a load module in Nasm to use 
>> them.
>
> A "load module"? What's that?

It's interesting that you should ask. Perhaps it is a term which is 
largely from the past and is no longer used as much. To quote a 
dictionary: "load module A program in machine language form that is 
ready to run in the computer. The linker generates the load module."

That is from

  http://encyclopedia2.thefreedictionary.com/load+module

What would *you* call it? An executable file?

>> However, I am not sure that I could use the extensions. I haven't 
>> (yet)
>> found a way to get from C source to 8086 ELF object code.
>
> You mean, you don't know of any 8086 C compilers producing ELFs?
> Mine might be, if not among the very few, the only one.

I wish. AIUI yours won't generate 8086 code but assumes a later CPU.

>> Incidentally, you mentioned segment support in C. Just to be clear, 
>> my
>> requirements are not as complicated as that as my C code doesn't do
>> anything which is not standard C. So I don't have any explicit 
>> segment
>> or offset separation in the source.
>
> In your C source?

Yes. While I can see a use for it in certain non-portable cases I hated 
the, for example, OpenWatcom extensions to C which allow it to work with 
segments and offsets.

> My compiler doesn't support any segments at the
> source level either and hides all the segmentation insanity in the
> huge memory model from the programmer (the insanity is visible in
> the generated assembly code, of course), making the one megabyte of
> memory look contiguous. And in the tiny and small memory models there
> isn't anything to hide.

OK.

James

[toc] | [prev] | [next] | [standalone]

#8278

On Friday, July 3, 2015 at 12:35:41 AM UTC-7, James Harris wrote:
> "Alexei A. Frounze" <...@gmail.com> wrote in message 
> news:75acded2-9f64-4d9f-81c2-7ec73fd72e01@googlegroups.com...
> > On Thursday, July 2, 2015 at 4:27:25 AM UTC-7, James Harris wrote:
> 
> ...
> 
> >> No, I wasn't aware of 16-bit ELF extensions. I have been looking into
> >> this with the other info you mentioned (snipped) and can see that the
> >> relocation types exist and have built a load module in Nasm to use 
> >> them.
> >
> > A "load module"? What's that?
> 
> It's interesting that you should ask. Perhaps it is a term which is 
> largely from the past and is no longer used as much. To quote a 
> dictionary: "load module A program in machine language form that is 
> ready to run in the computer. The linker generates the load module."
> 
> That is from
> 
>   http://encyclopedia2.thefreedictionary.com/load+module
> 
> What would *you* call it? An executable file?

Something like that. To me "load module" is an unfamiliar and
ambiguous term. I guess, I haven't studied formal CS enough. :)

> >> However, I am not sure that I could use the extensions. I haven't 
> >> (yet)
> >> found a way to get from C source to 8086 ELF object code.
> >
> > You mean, you don't know of any 8086 C compilers producing ELFs?
> > Mine might be, if not among the very few, the only one.
> 
> I wish. AIUI yours won't generate 8086 code but assumes a later CPU.

True. But how much code do you need to be 8086-only? I bet, for anything
practical you too would need at least a 80386. So, is it then only the
part that ensures that the CPU is at least a 80386 and prints an error
message if it's not? Couldn't you code this part in assembly? After all,
SP, (E)FLAGS and special CPU instructions aren't accessible in plain C.

> >> Incidentally, you mentioned segment support in C. Just to be clear, 
> >> my
> >> requirements are not as complicated as that as my C code doesn't do
> >> anything which is not standard C. So I don't have any explicit 
> >> segment
> >> or offset separation in the source.
> >
> > In your C source?
> 
> Yes. While I can see a use for it in certain non-portable cases I hated 
> the, for example, OpenWatcom extensions to C which allow it to work with 
> segments and offsets.

The whole real mode thing is a horrible kludge.

Alex

[toc] | [prev] | [next] | [standalone]

#8280

"Alexei A. Frounze" <alexfrunews@gmail.com> wrote in message 
news:1687b850-3c16-44ec-9bd9-4eb0dc2a201b@googlegroups.com...
> On Friday, July 3, 2015 at 12:35:41 AM UTC-7, James Harris wrote:
>> "Alexei A. Frounze" <...@gmail.com> wrote in message
>> news:75acded2-9f64-4d9f-81c2-7ec73fd72e01@googlegroups.com...
>> > On Thursday, July 2, 2015 at 4:27:25 AM UTC-7, James Harris wrote:

...

>> I wish. AIUI yours won't generate 8086 code but assumes a later CPU.
>
> True. But how much code do you need to be 8086-only? I bet, for 
> anything
> practical you too would need at least a 80386. So, is it then only the
> part that ensures that the CPU is at least a 80386 and prints an error
> message if it's not?

No, far from it. I wouldn't expect to do video editing(!) with 8086 code 
but I found that it can do a lot more than people think: multitasking 
OS, device drivers, hardware control/interaction, memory management etc. 
An 8086 OS would be very suitable for interacting with hardware such as 
in a lab environment. And if I ever write a boot manager (which I have 
been thinking of for a while) I would choose to use 8086 code simply 
because it is so portable. Nothing more is needed. The areas where 8086 
code falls down are those that require protection or lots of memory but 
600k can be quite a lot for an OS and many apps.

Much of the OS C code I have written so far can compile both to 8086 
code and to 80386 code, and run just as well in real mode as in 
protected mode, so it's not as if the time spent producing 8086 code 
will only work in that environment.

James

[toc] | [prev] | [next] | [standalone]

#8283

On Fri, 03 Jul 2015 06:27:42 -0400, James Harris  
<james.harris.1@gmail.com> wrote:
> "Alexei A. Frounze" <alexfrunews@gmail.com> wrote in message  
> news:1687b850-3c16-44ec-9bd9-4eb0dc2a201b@googlegroups.com...
>> On Friday, July 3, 2015 at 12:35:41 AM UTC-7, James Harris wrote:
>>> "Alexei A. Frounze" <...@gmail.com> wrote in message
>>> news:75acded2-9f64-4d9f-81c2-7ec73fd72e01@googlegroups.com...
>>> > On Thursday, July 2, 2015 at 4:27:25 AM UTC-7, James Harris wrote:

>>> I wish. AIUI yours won't generate 8086 code but assumes a later CPU.
>>
>> True. But how much code do you need to be 8086-only? I bet, for anything
>> practical you too would need at least a 80386. So, is it then only the
>> part that ensures that the CPU is at least a 80386 and prints an error
>> message if it's not?
>
> No, far from it. I wouldn't expect to do video editing(!) with 8086 code
> but I found that it can do a lot more than people think: multitasking
> OS, device drivers, hardware control/interaction, memory management etc.
> An 8086 OS would be very suitable for interacting with hardware such as
> in a lab environment. And if I ever write a boot manager (which I have
> been thinking of for a while) I would choose to use 8086 code simply
> because it is so portable. Nothing more is needed. The areas where 8086
> code falls down are those that require protection or lots of memory but
> 600k can be quite a lot for an OS and many apps.
>
> Much of the OS C code I have written so far can compile both to 8086
> code and to 80386 code, and run just as well in real mode as in
> protected mode, so it's not as if the time spent producing 8086 code
> will only work in that environment.

IIRC, Alexei said SmallerC can emit NASM.  If so, you only need add
a NASM directive to the assembly, i.e., CPU 8086, to have NASM tell
you which instructions are incorrect for 8086.  If the C code is
minimal, e.g., bootloader or bootsector, then it's not really that
much assembly to rework by hand.  Or, you could do like Ben and
customize SmallerC.  I.e., you could adjust the assembly selection
code of SmallerC to not use 386 or later instructions.  Just how
many more advanced x86 instructions could Alexei really use? ...
The basic x86 instructions were set before the 386.


Rod Pemberton

-- 
Tolerance and socialism attracts intolerance and terrorism.  See:
France, United Kingdom, Germany, Denmark, Belgium, Netherlands, ...

[toc] | [prev] | [next] | [standalone]

#8284

"Rod Pemberton" <boo@fasdfrewar.cdm> wrote in message 
news:op.x07tovymyfako5@localhost...
> On Fri, 03 Jul 2015 06:27:42 -0400, James Harris 
> <james.harris.1@gmail.com> wrote:
>> "Alexei A. Frounze" <alexfrunews@gmail.com> wrote in message 
>> news:1687b850-3c16-44ec-9bd9-4eb0dc2a201b@googlegroups.com...
>>> On Friday, July 3, 2015 at 12:35:41 AM UTC-7, James Harris wrote:

...

>>>> I wish. AIUI yours won't generate 8086 code but assumes a later 
>>>> CPU.

...

> IIRC, Alexei said SmallerC can emit NASM.  If so, you only need add
> a NASM directive to the assembly, i.e., CPU 8086, to have NASM tell
> you which instructions are incorrect for 8086.  If the C code is
> minimal, e.g., bootloader or bootsector, then it's not really that
> much assembly to rework by hand.

It's an idea but then I would have to "rework by hand" each time I added 
a new module and each time I recompiled any existing module. That's not 
really a starter. At the moment I use bcc to generate 8086 code and it 
does all that for me, albeit that it generates as86 object files which 
is rather an obscure format.

> Or, you could do like Ben and
> customize SmallerC.  I.e., you could adjust the assembly selection
> code of SmallerC to not use 386 or later instructions.

I have thought about that and Alex has offered to give me some pointers 
to get me started but it would take me a lot of time to do.

Other things I have considered for this and related purposes: bug-fixing 
bcc, converting bcc's as86 output to something more widely used (either 
via bespoke code or using GNU's BFD library), writing a separate 
compiler, post-processing other output etc. But all would take a lot of 
time.

> Just how
> many more advanced x86 instructions could Alexei really use? ...
> The basic x86 instructions were set before the 386.

I don't know what he emits that is not 8086 compatible. Could it be more 
than just a few instructions? Off the top of my head

  pusha/popa
  shifts and rotates immediate by more than 1
  push immediate
  registers wider than 16 bits

You could probably add more. None of those are available to 8086 code.

James

[toc] | [prev] | [next] | [standalone]

#8286

On Fri, 03 Jul 2015 17:45:01 -0400, James Harris  
<james.harris.1@gmail.com> wrote:

>> Just how
>> many more advanced x86 instructions could Alexei really use? ...
>> The basic x86 instructions were set before the 386.
>
> I don't know what he emits that is not 8086 compatible. Could it be more  
> than just a few instructions? Off the top of my head
>
>   pusha/popa
>   shifts and rotates immediate by more than 1
>   push immediate
>   registers wider than 16 bits
>
> You could probably add more. None of those are available to 8086 code.

If he procedurized the code, i.e., calls pusha() to emit "pusha",
then it's an easy change.  If it's a switch and bunch of printf()'s,
it's slightly more work.  I.e., you won't know how easy it is to
modify SmallerC until you look at the code.  Does BCC emit NASM?
Having access to NASM's macro pre-processor could be worth the effort.


Rod Pemberton

-- 
Tolerance and socialism attracts intolerance and terrorism.  See:
France, United Kingdom, Germany, Denmark, Belgium, Netherlands, ...

[toc] | [prev] | [next] | [standalone]

#8287

On Friday, July 3, 2015 at 2:45:02 PM UTC-7, James Harris wrote:
> "Rod Pemberton" <...@fasdfrewar.cdm> wrote in message 
> news:op.x07tovymyfako5@localhost...
> > On Fri, 03 Jul 2015 06:27:42 -0400, James Harris 
> > <...@gmail.com> wrote:
> >> "Alexei A. Frounze" <...@gmail.com> wrote in message 
> >> news:1687b850-3c16-44ec-9bd9-4eb0dc2a201b@googlegroups.com...
> >>> On Friday, July 3, 2015 at 12:35:41 AM UTC-7, James Harris wrote:
> 
> ...
> 
> >>>> I wish. AIUI yours won't generate 8086 code but assumes a later 
> >>>> CPU.
> 
> ...
> 
> > IIRC, Alexei said SmallerC can emit NASM.  If so, you only need add
> > a NASM directive to the assembly, i.e., CPU 8086, to have NASM tell
> > you which instructions are incorrect for 8086.  If the C code is
> > minimal, e.g., bootloader or bootsector, then it's not really that
> > much assembly to rework by hand.
> 
> It's an idea but then I would have to "rework by hand" each time I added 
> a new module and each time I recompiled any existing module. That's not 
> really a starter. At the moment I use bcc to generate 8086 code and it 
> does all that for me, albeit that it generates as86 object files which 
> is rather an obscure format.
> 
> > Or, you could do like Ben and
> > customize SmallerC.  I.e., you could adjust the assembly selection
> > code of SmallerC to not use 386 or later instructions.
> 
> I have thought about that and Alex has offered to give me some pointers 
> to get me started but it would take me a lot of time to do.
> 
> Other things I have considered for this and related purposes: bug-fixing 
> bcc, converting bcc's as86 output to something more widely used (either 
> via bespoke code or using GNU's BFD library), writing a separate 
> compiler, post-processing other output etc. But all would take a lot of 
> time.
> 
> > Just how
> > many more advanced x86 instructions could Alexei really use? ...
> > The basic x86 instructions were set before the 386.
> 
> I don't know what he emits that is not 8086 compatible. Could it be more 
> than just a few instructions? Off the top of my head
> 
>   pusha/popa
>   shifts and rotates immediate by more than 1
>   push immediate
>   registers wider than 16 bits
> 
> You could probably add more. None of those are available to 8086 code.
> 
> James

In 16-bit memory models (without long/32-bit types):
movsx/movzx
push imm
shl/shr/sar reg, imm>1
setcc
jcc rel16 (generated automatically by NASM where jcc rel8 isn't sufficient)

Alex

[toc] | [prev] | [next] | [standalone]

#8289

"Alexei A. Frounze" <alexfrunews@gmail.com> wrote in message 
news:fe6d6902-6d1a-4452-94a6-233d89db24e1@googlegroups.com...
> On Friday, July 3, 2015 at 2:45:02 PM UTC-7, James Harris wrote:

...

>> I don't know what he emits that is not 8086 compatible. Could it be 
>> more
>> than just a few instructions?

...

> In 16-bit memory models (without long/32-bit types):
> movsx/movzx
> push imm
> shl/shr/sar reg, imm>1
> setcc
> jcc rel16 (generated automatically by NASM where jcc rel8 isn't 
> sufficient)

They don't seem too bad. What about when 32-bit integers are used? Do 
you then go into 32-bit regs? I guess code gen for those would be harder 
to alter for 16-bit only.

James

[toc] | [prev] | [next] | [standalone]

#8290

On Friday, July 3, 2015 at 3:48:58 PM UTC-7, James Harris wrote:
> "Alexei A. Frounze" <...@gmail.com> wrote in message 
> news:fe6d6902-6d1a-4452-94a6-233d89db24e1@googlegroups.com...
> > On Friday, July 3, 2015 at 2:45:02 PM UTC-7, James Harris wrote:
> 
> ...
> 
> >> I don't know what he emits that is not 8086 compatible. Could it be 
> >> more
> >> than just a few instructions?
> 
> ...
> 
> > In 16-bit memory models (without long/32-bit types):
> > movsx/movzx
> > push imm
> > shl/shr/sar reg, imm>1
> > setcc
> > jcc rel16 (generated automatically by NASM where jcc rel8 isn't 
> > sufficient)
> 
> They don't seem too bad. What about when 32-bit integers are used? Do 
> you then go into 32-bit regs?

Yep.

> I guess code gen for those would be harder 
> to alter for 16-bit only.

Yep. The current mess would need to be rewritten to become a
different kind of mess. :)

Alex

[toc] | [prev] | [next] | [standalone]

#8291

On Fri, 03 Jul 2015 18:48:56 -0400, James Harris  
<james.harris.1@gmail.com> wrote:
> "Alexei A. Frounze" <alexfrunews@gmail.com> wrote in message  
> news:fe6d6902-6d1a-4452-94a6-233d89db24e1@googlegroups.com...
>> On Friday, July 3, 2015 at 2:45:02 PM UTC-7, James Harris wrote:

>>> I don't know what he emits that is not 8086 compatible. Could it be  
>>> more
>>> than just a few instructions?
>
> ...
>
>> In 16-bit memory models (without long/32-bit types):
>> movsx/movzx
>> push imm
>> shl/shr/sar reg, imm>1
>> setcc
>> jcc rel16 (generated automatically by NASM where jcc rel8 isn't  
>> sufficient)
>
> They don't seem too bad.

They seem straightforward to me and I'm falling asleep ...

I just constructed these using NASM and an online x86 manual.
I didn't test these.  Obviously, "CPU 8086" for NASM will
flag some mistakes, i.e., non-8086 instructions.  You can
obviously post to CLAX too for additional solutions.  8086
has a unique variety of solutions for certain computations.

Sequences for PUSH imm8/16 instruction and SHL/SHR/SAR
instructions have "trivial" side-effects.  With NASM's
macro processor, it should be possible to work around
the side effect for SHL/SHR/SAR.


1) MOVSX

MOVSX reg16,r/m8

; where reg8 is low sub-register of reg16
MOV reg8,r/m8
CBW reg16

2) MOVZX

MOVZX reg16,r/m8

; where XOR reg8 is high sub-register corresponding
;  to low sub-register MOV reg8
MOV reg8,r/m8
XOR reg8,reg8  ; clear high

Alternately,

; where reg8 is low sub-register of reg16
XOR reg16,reg16
MOV reg8,r/m8

3) PUSH

3a) PUSH imm16

; this needs a register that can be destroyed, e.g., AX
MOV  reg16,imm16
PUSH reg16

3b) PUSH imm8   ; sign-extended to stack size 16/32-bits from imm8

; where reg8 is low sub-register of reg16
; this needs a register that can be destroyed, e.g., AX
MOV  reg8,imm8
CBW  reg16
PUSH reg16

Obviously, if you don't use the sign-extension and are only using
the lower 8-bits of the register, then that can be shortened by
eliminating the CBW.  The high 8-bits will be garbage, but unused.

Alternately,

; this needs a register that can be destroyed, e.g., AX
XOR reg16,reg16
ADD/OR reg16,imm8   ; imm8 is sign-extended to 16-bits
PUSH reg16

Either ADD or OR should work.  ADD and OR treat flags differently.

4) SHL/SHR/SAR

SHL/SHR/SAR r/m8/16,imm8

PUSH CX
MOV CL,imm8
SHL/SHR/SAR r/m8/16,CL
POP CX

Obviously, you should avoid selecting CL or CX to shift ...

5) SETcc

SETcc r/m8

MOV r/m8,1h
Jcc here
DEC r/m8
here:

6) NASM auto-generated long branches

6a) use old NASM 0.98.39
6b) set a NASM flag to not do that
6c) patch up SmallerC to not generate long branches
6d) generate short branch around long jump
6e) use indirect address in memory
etc

7) registers wider than 16 bits

If Alexei uses this, which he didn't list, then
the code would need to be reworked, since operand
and address size overrides came later.

8) PUSHA/POPA

These need to be expanded to full set of PUSHes or POPs.
They should probably preserve the stack order of PUSHA/POPA.


Rod Pemberton

-- 
Tolerance and socialism attracts intolerance and terrorism.  See:
France, United Kingdom, Germany, Denmark, Belgium, Netherlands, ...

[toc] | [prev] | [next] | [standalone]

#8292

On Saturday, July 4, 2015 at 1:00:54 AM UTC-7, Rod Pemberton wrote:
> On Fri, 03 Jul 2015 18:48:56 -0400, James Harris  
> <...@gmail.com> wrote:
> > "Alexei A. Frounze" <...@gmail.com> wrote in message  
> > news:fe6d6902-6d1a-4452-94a6-233d89db24e1@googlegroups.com...
> >> On Friday, July 3, 2015 at 2:45:02 PM UTC-7, James Harris wrote:
> 
> >>> I don't know what he emits that is not 8086 compatible. Could it be  
> >>> more
> >>> than just a few instructions?
> >
> > ...
> >
> >> In 16-bit memory models (without long/32-bit types):
> >> movsx/movzx
> >> push imm
> >> shl/shr/sar reg, imm>1
> >> setcc
> >> jcc rel16 (generated automatically by NASM where jcc rel8 isn't  
> >> sufficient)
> >
> > They don't seem too bad.
> 
> They seem straightforward to me and I'm falling asleep ...
> 
> I just constructed these using NASM and an online x86 manual.
> I didn't test these.  Obviously, "CPU 8086" for NASM will
> flag some mistakes, i.e., non-8086 instructions.  You can
> obviously post to CLAX too for additional solutions.  8086
> has a unique variety of solutions for certain computations.
> 
> Sequences for PUSH imm8/16 instruction and SHL/SHR/SAR
> instructions have "trivial" side-effects.  With NASM's
> macro processor, it should be possible to work around
> the side effect for SHL/SHR/SAR.
> 
> 
> 1) MOVSX
> 
> MOVSX reg16,r/m8
> 
> ; where reg8 is low sub-register of reg16
> MOV reg8,r/m8
> CBW reg16

CBW, CWD, CDQ and so on don't take an operand. The operand is implicit
(*AX and *DX).

> 2) MOVZX
> 
> MOVZX reg16,r/m8
> 
> ; where XOR reg8 is high sub-register corresponding
> ;  to low sub-register MOV reg8
> MOV reg8,r/m8
> XOR reg8,reg8  ; clear high
> 
> Alternately,
> 
> ; where reg8 is low sub-register of reg16
> XOR reg16,reg16
> MOV reg8,r/m8

Except for BP, SI and DI, which lack individually accessible 8-bit
halves. Smaller C doesn't use MOVSX/MOVZX to move from or to these
regs, though.

> 3) PUSH
> 
> 3a) PUSH imm16
> 
> ; this needs a register that can be destroyed, e.g., AX
> MOV  reg16,imm16
> PUSH reg16
> 
> 3b) PUSH imm8   ; sign-extended to stack size 16/32-bits from imm8
> 
> ; where reg8 is low sub-register of reg16
> ; this needs a register that can be destroyed, e.g., AX
> MOV  reg8,imm8
> CBW  reg16
> PUSH reg16
> 
> Obviously, if you don't use the sign-extension and are only using
> the lower 8-bits of the register, then that can be shortened by
> eliminating the CBW.  The high 8-bits will be garbage, but unused.
> 
> Alternately,
> 
> ; this needs a register that can be destroyed, e.g., AX
> XOR reg16,reg16
> ADD/OR reg16,imm8   ; imm8 is sign-extended to 16-bits
> PUSH reg16
> 
> Either ADD or OR should work.  ADD and OR treat flags differently.

I don't think there's any gain in simulating PUSH imm8. PUSH imm16
is most likely going to be the same or shorter.

> 4) SHL/SHR/SAR
> 
> SHL/SHR/SAR r/m8/16,imm8
> 
> PUSH CX
> MOV CL,imm8
> SHL/SHR/SAR r/m8/16,CL
> POP CX
> 
> Obviously, you should avoid selecting CL or CX to shift ...
> 
> 5) SETcc
> 
> SETcc r/m8
> 
> MOV r/m8,1h
> Jcc here
> DEC r/m8
> here:

Or XOR + J!cc + INC.

> 6) NASM auto-generated long branches
> 
> 6a) use old NASM 0.98.39
> 6b) set a NASM flag to not do that

What will NASM do then?

> 6c) patch up SmallerC to not generate long branches

There's no such thing as a long branch in Smaller C. If it needs a
branch, it generates one. The assembler is expected to take it from
there and do the right thing. Smaller C does not attempt to count
or estimate the size of the resultant machine code and so it has no
idea of whether any of the generated branches is short or long.
That's something the assembler must deal with.

> 6d) generate short branch around long jump
> 6e) use indirect address in memory
> etc
> 
> 7) registers wider than 16 bits
> 
> If Alexei uses this, which he didn't list, then
> the code would need to be reworked, since operand
> and address size overrides came later.

They came together with MOVSX/MOVZX and SETcc.
32-bit regs are used in the huge memory model only when targeting
real mode.

> 8) PUSHA/POPA
> 
> These need to be expanded to full set of PUSHes or POPs.
> They should probably preserve the stack order of PUSHA/POPA.

These are unused.

Alex

[toc] | [prev] | [next] | [standalone]

#8295

On Sat, 04 Jul 2015 07:42:20 -0400, Alexei A. Frounze  
<alexfrunews@gmail.com> wrote:
> On Saturday, July 4, 2015 at 1:00:54 AM UTC-7, Rod Pemberton wrote:
>> On Fri, 03 Jul 2015 18:48:56 -0400, James Harris
>> <...@gmail.com> wrote:
>> > "Alexei A. Frounze" <...@gmail.com> wrote in message
>> > news:fe6d6902-6d1a-4452-94a6-233d89db24e1@googlegroups.com...
>> >> On Friday, July 3, 2015 at 2:45:02 PM UTC-7, James Harris wrote:

>> 1) MOVSX
>>
>> MOVSX reg16,r/m8
>>
>> ; where reg8 is low sub-register of reg16
>> MOV reg8,r/m8
>> CBW reg16
>
> CBW, CWD, CDQ and so on don't take an operand. The operand
> is implicit (*AX and *DX).

Yes, I was sleepy ... ;-)

Actually, I didn't think to check CBW for a hardcoded register ...
I do have it listed in my own notes on x86 issues.

So, a longer sequence is needed:

; this needs a register that can be destroyed, e.g., AX
MOV AL,r/m8
CBW
MOV reg16,AX

Alternately, a PUSH/POP wrap to preserve AX:

PUSH AX
... ; code above
POP AX

Or, using NASM's macro functionality (untested):

%macro movsx_ 2
%ifdef I8086
%ifidn %1,ax
   push ax
%endif
   mov al,%2
   cbw
   mov %1,ax
%ifidn %1,ax
   pop ax
%endif
%else
   movsx %1,%2
%endif
%endmacro
%macro mul_ 0
%error "no arguments"
%endmacro

That's based on other macro's I wrote some years ago for
an assembly backend for a simple Forth converter.

You would need to emit "movsx_" with an underscore instead
of "movsx" and include the macro file and optionally define
I8086 or some define to select the non-386 code.  E.g.,

movsx_ bx,cl

If the untested macro is correct, it should emit this
for 386:

movsx bx,cl

And, emit this for 86 (when I8068 is defined) without
preserving AX since it's not a parameter to the movsx_ macro:

mov al,cl
cbw
mov bx,ax

If the first parameter to movsx_ is "ax" it should wrap
with the PUSH/POP of AX.  If not, it needs %ifnidn instead
of %ifidn.

>> 6) NASM auto-generated long branches
>>
>> 6a) use old NASM 0.98.39
>> 6b) set a NASM flag to not do that
>
> What will NASM do then?

Nothing.  The user must fix it.  E.g., perhaps a manual short
branch over jump or an indirect branch.

>> 6c) patch up SmallerC to not generate long branches
>
> There's no such thing as a long branch in Smaller C. If it
> needs a branch, it generates one. The assembler is expected
> to take it from there

Acceptable.

> and do the right thing.

Questionable ...  :-D

If you can design around it being a potential issue, you should.  Yes?

> Smaller C does not attempt to count
> or estimate the size of the resultant machine code and so it has no
> idea of whether any of the generated branches is short or long.
> That's something the assembler must deal with.

Well, NASM has the ability to allow you to specify, e.g.,
'SHORT' and 'NEAR', if the compiler "knows" the branch size.

If not, you can always jump:

Jcc SHORT over
JMP NEAR rel16
over:

NASM has special syntax to allow for re-using short labels.
So, you should be able to do this, if you haven't (unconfirmed):

here:  ; local label needs a prior non-local label
...
Jcc SHORT .over
JMP NEAR rel16
.over
...
Jcc SHORT .over  ; re-used
JMP NEAR rel16
.over


In a similar manner, I have this macro in my code which
conditionally jumps over a call that uses the same label
repeatedly:

%macro xx_ 3
   cmp %1,byte 0
   j%+3 short %%over
   call %2
   %%over
%endmacro

It's used this way for an "if" and "else" (not shown) etc:

%macro if_ 2
   xx_ %1,%2,z
%endmacro

if_ eax,try
...
try:

Note the ability to pass the condition code 'z' from
another macro.

If you aren't using NASM macro's, they're worth a look.
I.e., you could use them to automatically select SHORT,
NEAR, and FAR memory jumps, based on the parameter passed
to the macro, e.g., 's' 'n' 'f' :

%macro jmp_ 2
%ifidn %2,s
   jmp SHORT %1
%elifidn %2,n
   jmp NEAR %1
%elifidn %2,f
   jmp FAR %1
%else
%error "unknown argument"
%endif
%macro jmp_ 0
%error "no arguments"
%endmacro

jmp_ try,s
...
try:

I.e., should be:

jmp SHORT try

HTH, well someone, if not you, you probably read
the NASM manual ...


Rod Pemberton

-- 
Tolerance and socialism attracts intolerance and terrorism.  See:
France, United Kingdom, Germany, Denmark, Belgium, Netherlands, ...

[toc] | [prev] | [next] | [standalone]

#8297

On Saturday, July 4, 2015 at 11:12:45 PM UTC-7, Rod Pemberton wrote:
> On Sat, 04 Jul 2015 07:42:20 -0400, Alexei A. Frounze  
> <...@gmail.com> wrote:
> > On Saturday, July 4, 2015 at 1:00:54 AM UTC-7, Rod Pemberton wrote:
...
> >> 6) NASM auto-generated long branches
> >>
> >> 6a) use old NASM 0.98.39
> >> 6b) set a NASM flag to not do that
> >
> > What will NASM do then?
> 
> Nothing.  The user must fix it.  E.g., perhaps a manual short
> branch over jump or an indirect branch.

You're probably using an older version of NASM if "the user must fix it".

----8<----
; file: br.asm
; compile (with nasm 2.10): nasm -f bin br.asm -o br.com
; decompile: ndisasm -b 16 -o 0x100 br.com
CPU 8086
org 0x100
bits 16

jz lab
times 256 nop
lab:
ret
----8<----
Assembles without errors.

Disassembly:
----8<----
00000100  7503              jnz 0x105
00000102  E90001            jmp word 0x205
00000105  90                nop
00000106  90                nop
00000107  90                nop
00000108  90                nop
...
00000200  90                nop
00000201  90                nop
00000202  90                nop
00000203  90                nop
00000204  90                nop
00000205  C3                ret
----8<----

So, NASM 2.10 (or maybe all the way back to 2.03) is doing just fine.

> >> 6c) patch up SmallerC to not generate long branches
> >
> > There's no such thing as a long branch in Smaller C. If it
> > needs a branch, it generates one. The assembler is expected
> > to take it from there
> 
> Acceptable.
> 
> > and do the right thing.
> 
> Questionable ...  :-D
> 
> If you can design around it being a potential issue, you should.  Yes?

NASM does it for me. And if I were writing my own assembler, it too
would do it. It's 201x and assemblers could be a bit friendlier with
trivial stuff. Self-driving cars are coming and putting prehistoric
assemblers to shame. :)

> > Smaller C does not attempt to count
> > or estimate the size of the resultant machine code and so it has no
> > idea of whether any of the generated branches is short or long.
> > That's something the assembler must deal with.
> 
> Well, NASM has the ability to allow you to specify, e.g.,
> 'SHORT' and 'NEAR', if the compiler "knows" the branch size.

But it doesn't. And it is a deliberate choice. Assembly code is a little
more standardized in format/layout than object files. So, I don't
need to bother with branch lengths in the compiler, I can trivially
switch to generating instructions for a different architecture without
having to also incorporate support for yet another object file format
and I get cheap inline assembly for free, all if I just emit assembly
code.

If the target assembler doesn't adjust branches for me, I may do
something about it. But so far I haven't needed to do anything about it.

So, it's not an actual problem for me. Any Smaller C porters lining
up? It could be a potential problem for them, yes. But I'm not hearing
of people running into this. They more likely have issues with many
different things. I'm judging by the failed attempts to port Smaller C
that I'm aware of. Ben is among the very few who made their way through
the code and made it do what they wanted it to. Perhaps, compilers,
even non-optimizing ones, aren't for everyone to understand and 
comfortably/confidently to work on. So, the branch problem doesn't exist
in my practice.

Alex

[toc] | [prev] | [next] | [standalone]

#8298

On Sun, 05 Jul 2015 03:47:12 -0400, Alexei A. Frounze
<alexfrunews@gmail.com> wrote:
> On Saturday, July 4, 2015 at 11:12:45 PM UTC-7, Rod Pemberton wrote:
>> On Sat, 04 Jul 2015 07:42:20 -0400, Alexei A. Frounze
>> <...@gmail.com> wrote:
>> > On Saturday, July 4, 2015 at 1:00:54 AM UTC-7, Rod Pemberton wrote:

>> >> 6) NASM auto-generated long branches
>> >>
>> >> 6a) use old NASM 0.98.39
>> >> 6b) set a NASM flag to not do that
>> >
>> > What will NASM do then?
>>
>> Nothing.  The user must fix it.  E.g., perhaps a manual short
>> branch over jump or an indirect branch.
>
> You're probably using an older version of NASM if "the user must fix it".
>

LOL.  That is what 6a) said.  6b) was for new NASM.  Obviously ...  ;-)

> ----8<----
> ; file: br.asm
> ; compile (with nasm 2.10): nasm -f bin br.asm -o br.com
> ; decompile: ndisasm -b 16 -o 0x100 br.com
> CPU 8086
> org 0x100
> bits 16
>
> jz lab
> times 256 nop
> lab:
> ret
> ----8<----
> Assembles without errors.
>
> Disassembly:
> ----8<----
> 00000100  7503              jnz 0x105
> 00000102  E90001            jmp word 0x205
> 00000105  90                nop
> 00000106  90                nop
> 00000107  90                nop
> 00000108  90                nop
> ...
> 00000200  90                nop
> 00000201  90                nop
> 00000202  90                nop
> 00000203  90                nop
> 00000204  90                nop
> 00000205  C3                ret
> ----8<----
>
> So, NASM 2.10 (or maybe all the way back to 2.03) is doing just fine.

Are you saying NASM actually compiles that for the 8086 source?

It clearly  DID NOT  do what it was told to do ...  Bad assembler!

So, that's rather surprising to me, since NASM is so "pedantic".

Let's check:

yes 2.09.04 64-bit Linux
yes 2.06rc8 to 2.10.01 32-bit DOS (5 versions)
no  0.98.39 32-bit DOS

The classic 0.98.39 version of NASM reports an error on line 5:
"... error short jump is out of range"

James was concerned with Jcc with an offset greater than 8-bits
for 8086 code.  The 8086 only supported the 8-bit offset for Jcc
instruction.  So, as long as James doesn't need compatibility
with NASM 0.98.39 or some other older intermediate version, he's
all set.  NASM does what I suggested as a fix for short branches,
for the more recent versions.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#8299

On Sunday, July 5, 2015 at 2:28:21 AM UTC-7, Rod Pemberton wrote:
> On Sun, 05 Jul 2015 03:47:12 -0400, Alexei A. Frounze
> <...@gmail.com> wrote:
...
> > ----8<----
> > ; file: br.asm
> > ; compile (with nasm 2.10): nasm -f bin br.asm -o br.com
> > ; decompile: ndisasm -b 16 -o 0x100 br.com
> > CPU 8086
> > org 0x100
> > bits 16
> >
> > jz lab
> > times 256 nop
> > lab:
> > ret
> > ----8<----
> > Assembles without errors.
> >
> > Disassembly:
> > ----8<----
> > 00000100  7503              jnz 0x105
> > 00000102  E90001            jmp word 0x205
> > 00000105  90                nop
> > 00000106  90                nop
> > 00000107  90                nop
> > 00000108  90                nop
> > ...
> > 00000200  90                nop
> > 00000201  90                nop
> > 00000202  90                nop
> > 00000203  90                nop
> > 00000204  90                nop
> > 00000205  C3                ret
> > ----8<----
> >
> > So, NASM 2.10 (or maybe all the way back to 2.03) is doing just fine.
> 
> Are you saying NASM actually compiles that for the 8086 source?

Yes, as you can see. :)

> It clearly  DID NOT  do what it was told to do ...  Bad assembler!

GOOD assembler! Here, have a treat! :)

> So, that's rather surprising to me, since NASM is so "pedantic".
> 
> Let's check:
> 
> yes 2.09.04 64-bit Linux
> yes 2.06rc8 to 2.10.01 32-bit DOS (5 versions)
> no  0.98.39 32-bit DOS
> 
> The classic 0.98.39 version of NASM reports an error on line 5:
> "... error short jump is out of range"
> 
> James was concerned with Jcc with an offset greater than 8-bits
> for 8086 code.  The 8086 only supported the 8-bit offset for Jcc
> instruction.  So, as long as James doesn't need compatibility
> with NASM 0.98.39 or some other older intermediate version, he's
> all set.  NASM does what I suggested as a fix for short branches,
> for the more recent versions.

We just learned a new thing. Made a discovery. In something we use
often. :) I guess, the fireworks were quite appropriate. :)

Alex

[toc] | [prev] | [next] | [standalone]

#8308

On Sun, 05 Jul 2015 18:15:50 -0400, Alexei A. Frounze  
<alexfrunews@gmail.com> wrote:

> For MOVZX. PUSHF/POPF not needed.
>
> MOVSX is worse:
>
> PUSH AX ; if dst != AX
> MOV AL, src
> CBW
> MOV dst, AX ; if dst != AX
> POP AX ; if dst != AX
>

It's too bad there is no PUSH reg8 ...

> There are two types of comparisons in Smaller C:
> 1. comparisons whose result is used for if/while/for:
>   if (a < b) ...
>   while (a < b) ...
>   do ... while (a < b);
>   for (...; a < b; ...) ...
> 2. all other comparisons:
>   c = a < b;
> CMP+Jcc are used in the former.
> CMP+SETcc are used in the latter.

If those are the only comparisons, what are you using MOVSX for?
Signed-arithmetic?  If so, delay using CBW until an arithmetic
operation is performed when AX is free.  Then, no need for MOVSX.


Rod Pemberton

-- 
Tolerance and socialism attracts intolerance and terrorism.  See:
France, United Kingdom, Germany, Denmark, Belgium, Netherlands, ...
UK: Strong encryption, non-issue. GR: Eurozone currency, priority.

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | alt.os.development

csiph-web