Re: Pseudo random numbers / DOS / memory, etc....

Hi,

On Oct 31, 5:52 am, Markus Wichmann <nullp...@xxxxxxxxxxxxxxxxxxx>
wrote:
On 30.10.2011 22:23, Bjarni Juliusson wrote:

This isn't really going to answer any of your questions, but I see this
all the time and I have to ask:

Why do so many people still run MSDOS on their computers?

My guess is that several people think you can't write assembly for
anything but MSDOS. The reason being they tried their old MSDOS code on
Windows or Linux and - surprise - it turned out to be unportable. Yeah,
well that's the idea behind assembly! But some people just don't get it.

If you want portable code, assembly probably isn't the answer. You
can, in theory, write "dual mode" code for 16-/32-bit, but most people
don't. (The fact that x86 is "everywhere" obliterates the need for
super portability, though.)

Here at the Uni I'm attending we had a course for assembly language.
Well, suffice it to say that the instructor wanted me, as someone who
said he already had experience with assembly, to write up some code for
the FPU so that he has something. No FPU code in the course? Frig? OK,
then in 20 years they'll start learning about MMX or what?

FPU/MMX/3dnow! are all deprecated and only remain for legacy. I don't
see how they could ever cleanly remove those, but who knows. The
future is all SSE2 on up, for good or bad (no 80-bit numbers??).
Everything nowadays really exercises CPUID, that's for sure!

All this however just served to make the other attendees think assembly
was a dying art. Well d'uh! When all you do is teaching people assembly
on grounds of software that is so old it has to be emulated nowadays,
something really isn't right!

The idea is that computers are fast enough and RAM is abundant enough
to not need assembly, which is obviously not true (or at least only
partially). Still, people flock to Java and C#/.NET in droves, for
whatever reason. Unfortunately, HLLs don't always deliver on their
promises of being ultra portable ("strictly conformant"??, LP64 vs.
LLP64, etc).

Also, 8086? That's a 35 year old processor you have there. I'd like to
encourage you to learn about assembly language programming, but I have
to say my best advice would be to forget about the 8086, and enter into
the 1980s and the wonderful world of the 80386 and the wide variety of
operating systems avalilable for it. Why make it hard on yourself?

386 (1986) isn't exactly modern anymore. And most people don't even
utilize 686 (1996?) properly. Only now are we starting to see decent
coverage for AMD64 (2003). The industry is slow to adopt, sometimes
for good reasons. Too many changes too quickly doesn't help anybody.

Exactly. PLus, try to steer clear of 16-bit mode as it has several
pitfalls, like only allowing you to reference memory from certain
registers... in 16-bit mode, you can use pointers in bx, bp, si and di
and several additions of the four, but not from ax, cx, dx and sp.
Especially the latter is kind of dull when you try to allocate a
temporary variable on stack: You can push it, but you can't reference it
unless you created a stack frame beforehand. I just needed a place for
my friggin 80-bit long double to stay for a short time!

None of that is a dealbreaker. It's easy to overcome such silly
limitations, no processor mode is perfect. There's always a few
gotchas, which is why there is no clear-cut answer.

As for MSDOS, I think you will find a proper modern operating system
gets in your way a lot less, and especially the various Un*x flavours
are really comfortable for us programmers! Try it!

Right so! Just sometimes I'd like dosbox's debugger natively for Linux,
but then again, maybe I just have to write it.

It's true, Linux has gotten many ports so that the uniqueness of DOS
is much, much less these days (e.g. Tran's Timeless). Still, don't
forget that DOS had a decade or two of good software (esp. games).

Really though, the kernel interface to MSDOS was kind of shit, but then
so is the entire 16-bit mode, with 32-bit pointers that are effectively
20 bits long (64-bit mode nearly manages to up this by introducing
64-bit pointers that are effectively 48-bits long. But at least 48 bits
of address space are impossible to fill completely nowadays at least.)

Also, of course, it's a matter of learning what's useful - if you start
with 8086/MSDOS, you will then have to partially relearn the way you
program to be able to write programs that are really useful on modern
computers and operating systems.

You'll be constantly relearning anyways as things move too fast. There
are tons of competing technologies, and they all come and go (thus
will be abandoned eventually, even DEC's Alpha or Sony's Cell or
Intel's Itanium or MS' Win32 API).

I started with MSDOS, writing 16-bit assembly code in the mid 1990s,
when those things were on their way out, but once I tried 32-bit
assembly on Linux, I realised just how difficult MSDOS and 16-bit
programming had been and how counterproductive it was to continue doing
it. I haven't looked back.

I learned assembly on Win32 a while back, then switched to Linux, then
had to do some work for DOS, then embraced Linux really hard! Now I'm
writing code for Linux/AMD64 and wonder where all those MSDOS and 8086
enthusiasts lived the past 20 years or so... under a rock?

No, just old (but functional) hardware and lack of decent tools, texts/
tutorials, etc. No sense in bothering with learning 64-bit if you
don't have the hardware to test. (Yes, I know, QEMU had a 32-bit-
hosted emulator.) Also no sense in using 32-bit when 16-bit gets the
job done.

"A poor carpenter blames his tools." Viva la FreeDOS! ;-)

(yes, I'm actually triple-booting these days, for no obvious reason:
FreeDOS, Linux32, Win64)
.

Relevant Pages

  • Re: Pseudo random numbers / DOS / memory, etc....
    ... Why do so many people still run MSDOS on their computers? ... Windows or Linux and - surprise - it turned out to be unportable. ... programming had been and how counterproductive it was to continue doing ...
    (comp.lang.asm.x86)
  • Re: File Handling Problems Python I/O
    ... Thanks for the advice as the programming I am doing will be run on both ... Windows and Linux based PC's, that being the main reason for my venture ...
    (comp.lang.python)
  • Why the Linux Desktop Just Wont Work! and why Linux depresses me.
    ... Why having Linux on the desktop of Aunt Tille is a myth. ... direction: incompatible websites. ... Even though Firefox usage has ... For this reason, and for this reason only, is it important for Firefox ...
    (comp.os.linux.misc)
  • Re: Why the Linux Desktop Just Wont Work! and why Linux depresses me.
    ... > Why having Linux on the desktop of Aunt Tille is a myth. ... > direction: incompatible websites. ... Even though Firefox usage has ... > For this reason, and for this reason only, is it important for Firefox ...
    (comp.os.linux.misc)
  • Re: [PATCH] adding two new options to cp
    ... >> Is emulating Linux behavior that good an idea? ... reason to change FreeBSD. ... >> functionality to the system, while adding things that we would rather ... of a good reason not to add a feature is *not* a good reason to add ...
    (freebsd-hackers)