How many instructions are there ?

rcgldr

I specifically mentioned a zero initialized section, not an unitialized section. However, it appears that the Wintel environment does zero all of the .bss segment. I also discovered that unitialized global variables ended up in the .data segment. In debug builds, the stack is initialized to 0xcccccccc, so local unitialized variables will be set to "c...c", in release builds I assume that no initialization is done.

I just tested this with Visual Studio 2005. A static variable ends up in the .bss section if there's no initializer, or it ends up in the .data segment if there is an initializer. As mentioned, I was suprised to find that an uninitialized global variable ended up in the .data segement and set to zero.

Well the linker has to generate global values for a startup program to know what sections need to be zeroed out, or the executable format will need to include all of the .data / .bss sections, including the zeroed out section. I read the document you linked to and in section 5.1, it states that zero only sections images don't have to be included in the object file, which implies the startup routine clears these sections.

As mentioned, the Wintel environment appears to zero out all of .bss section. In the Arm environment, only a portion of the .bss segment is zeroed out, with the remainder remaining truly unitialized, which I assume is to reduce the execution time. Global values are generated by the linker, that indicate the location and size of the zero initialized logical segment which is the first part of the .bss segment.

It's from Visual Studio 2005, click on help, search for static, then click on C/C++ link and you get this: static.jpg.

Back in 1986, when Atari came out with the 68000 based ST1024 system with 1 meg of memory for under $1000, I and other programmer / engineers asked how long it would be before people started commenting, you only have 1 meg of memory in your computer. Eventually the Atari series reached 4MB of ram before it sold off it's computer division to a European company, the only place where sales were still reasonable. The point here is that a lot of engineers realized that home computer memory sizes were going to continue to grow.

Regarding memory sizes on mainframes, high end IBM 360's and 370's had 1MB or more of memory during the 1960's and 1970's. By 1985, a Cray 2 super computer had 512MB of memory.

oldtobor

I downloaded and tried a PICO for DOS version. It is not too bad, better than vi, at least simpler. The question ws about an exact replica of DOS, but I think I found out why. During the late 80s, early 90s there were many full screen DOS programs around, but the unix environment was very separated from the PC users (unix being very high end professional). You could more easily find unix utilities (like awk already in 1989 by polytron) ported to DOS than vice versa. It was like someone asking to port DOS basic to IBM MVS, it didn't make sense. Then came windows gui and then linux. With linux the possibility of porting any DOS to unix became virtually zero because DOS was no longer even on the radar and because of hostility for anything DOS by OSS programmers.

I just wonder how it might have evolved if all those full screen DOS programs were ported as exact replicas to unix, unix - prompt. Like turbo pascal, or quick basic, etc.

NoTime

The IBM 360 was constrained to a max of 64k memory.
In the company I worked for, we had 5 370's, the biggest was 512k until 78 when they upgraded to a meg.
I think they did it to support TCAM the predecessor to VTAM.
The IBM 370 was constrained to 268 meg until around 84 when they came out with XA.
That was a PITA due to all the software that had used the upper 4 bits of the address to pass flags.

NoTime

DOS had access to the video buffer and the keystroke buffer.
IIRC the first CRT TTY terminals used for UNIX (and other applications) only transmitted the line the cursor was on when the enter key was hit.
This was a carry over from paper termiminals.
The arrow keys and whatnot were only available to the TTY terminal and not the OS.

AlephZero

I find that very hard to believe. I was working for a company that used 360/65s round about 1970 (before they had virtual memory operating systems) and the standard sized job streams were set at 100 180 and 240k memory (several streams running at once). That makes no sense if the machine had a max of 64k.

Even our little IBM 1130s had 32k words (not bytes) of memory.

Quite possibly the smaller models of 360 (models 20 and 30) were more contrained though.

Nope, it had 512 Mwords (64 bit) = 4 GB.

NoTime

The ones I was thinking of were models 20 and 30.

Hurkyl

I wonder, then, how the DOSBox project exists.

graphic7

You either seem to be forgetting or don't know that standards "typically" dominate the UNIX world (note, I said UNIX world, which excludes UNIX-like operating systems, such as Linux) and what dominates standards usually are tools that are on multiple variations of the said operating system over a long period of time prior to the formation of the standard. In this case we are talking about ed/ex/vi, which were around for some time before POSIX 1003.2-1992 (the specific POSIX standard that mandates which commands/utilities should exist on a POSIX 1003.2-1992 compliant system).

Simply said, the reason editors like ed, ex, and vi are still around is the standard that most UNIX variants follow mandates them, and users of those systems are guaranteed to always have such editors around. Even if the said system isn't POSIX-compliant, such as a BSD release that predates POSIX, vi will still be around, because vi originated on a very, very old BSD release (2BSD or so, I think). If a user is going to choose an editor to learn, it would be reasonable and advantageous to choose the editor that will be available everywhere.

Also, more 'modern' editors like emacs, nedit, etc. are not going to be available on every system, even modern systems, like AIX or Solaris without installing additional freeware, which may or may not be practical in a production environment with strict standards specifying what can be installed on systems within the production environment.

chroot

Excellent find! There's oldtobor's EDIT right there, running on Linux. As if, somehow, pico isn't similar enough.

- Warren

Hurkyl

Huh? You say it like those are bad things.

Yes, a programmer inexperienced with those tools can do a lot of damage, but so can someone inexperienced with a circular saw. That doesn't make circular saws a bad thing.

rcgldr

How is runtime binding signficantly different than using pointers to functions? In the old days on some systems where every instruction cycle counted, one way to speed up interrupt processing was to change the interrupt vector address (pointer to function) at each step to eliminate the extra time it would take to do an indirect jump via software.

D H

They (operator overloading, multiple inheritence) have the potential to be very bad things. Why do you think operator overloading and multiple inheritence were intentionally left out of Java?

For some rather stong opinions regarding operator overloading, read these thread on operator overloading in Java:
http://forum.java.sun.com/thread.jsp...hreadID=489919 and http://bugs.sun.com/bugdatabase/view...bug_id=4905919.

Hurkyl

Circular saws have the potential to do very bad things too. That doesn't make them a bad tool. (Wait, didn't I already say that?)

Operator overloading and a certain portion of multiple inheritance functionality was intentionally left out of java because java has different design goals.

AlephZero

No comment on the advisability of building flight software using circular saws.

However, I did once spend a long night helping ferry the "walking wounded" to hospital, after a plane crash caused partly by the fact that somebody managed to wire up the flight deck on a commercial airliner so a problem with engine 1 lit up the warning indicators for engine 2, and somebody else inspected what they had done and said "yeah, that's OK". The consequence was the flight crew attempted a one-engine landing, except they shut down the engine that was working properly, not the other one.

By all means tell me that sort of thing will never happen with modern software design methodologies, but I won't necessarily believe you.

NoTime

I had admin responsibilities for a couple years.
AIX and SUN.
I got to do a lot of work for things that should have evolved to no-brainers.
I would think, that after 25 years or so they could come up with better "standards".

NoTime

If you really want to get into multiple inheritance functionality then try some UNIX X-Windows coding.
IMO 3/4 of the development time and half the code is spent overriding inheritance.

IIRC Java's original design goal was as a small interpretive language to run on a consumer set top box imbedded p-engine.
Now it envisions itself as a competitor to C++.
It's original goal seems to have disappeared.

While circular saws may not be a bad tool, they certainly are dangerous.