 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis wrote:
> Darren New escreveu:
>> I've never seen it done well unless the whole system was broken down
>> into parallel operations and then optimized back into larger components.
>
> I read in the early days the programmer would manually break a program
> into small chunks that could fit in the memory. Eventually the process
> became automated.
Yep. That's what "overlays" were. Now we have demand-paging. (And it wasn't
that "early". Any machine without virtual memory (and some with it) did
that, including Amigas, IBM machines before the 386, 68000s, etc.)
--
Darren New, San Diego CA, USA (PST)
Serving Suggestion:
"Don't serve this any more. It's awful."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New escreveu:
> nemesis wrote:
>> Darren New escreveu:
>>> I've never seen it done well unless the whole system was broken down
>>> into parallel operations and then optimized back into larger components.
>>
>> I read in the early days the programmer would manually break a program
>> into small chunks that could fit in the memory. Eventually the
>> process became automated.
>
> Yep. That's what "overlays" were. Now we have demand-paging. (And it
> wasn't that "early". Any machine without virtual memory (and some with
> it) did that, including Amigas, IBM machines before the 386, 68000s, etc.)
really?! What was it? An settable option for the compiler?
--
a game sig: http://tinyurl.com/d3rxz9
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis wrote:
> really?! What was it? An settable option for the compiler?
Not really. You created basically a tree of code, where the only
permissible movements into a branch were from the node directly above.
(E.g., you couldn't have A as the parent of B and C, and have B call C, or C
return to B after it had been overwritten.)
Then the linker would link multiple routines to live in the same address
space, such that B and C might share addresses. Then it would patch the
calls from A to B or A to C to first make sure that the appropriate branch
of the tree was in memory (loading it if not) before branching to the actual
routine.
So, by the time of MS-DOS, it was not dissimilar to building a makefile that
you gave to the linker, and it would do the patching up. You just had to
have enough knowledge of your system that you knew what pieces could be
overlaid. (Which was *way* easier with procedural code rather than OO or
something.)
--
Darren New, San Diego CA, USA (PST)
Serving Suggestion:
"Don't serve this any more. It's awful."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis wrote:
> really?! What was it? An settable option for the compiler?
So say you had a piece of code that would take input, do some calculations,
then print the report.
"main" would be in the root, along with things like printf(), malloc(), etc.
And anything else that was used in more than just input, calcs, or print.
Main would call your top input routine, which would cause that chunk of code
to be read in and branched to. It would take the inputs it needs and save
them out to a file (or memory or whatever). Input routines would return
with a flag that says "Yes, go run the calcs", so Main would invoke the calcs.
You'd overlay input on top of calcs, so while you're doing the math, your
input validation routines and code to draw menus and widgets and such
doesn't need to be around.
Your calcs would write out their results (say, in a CSV file) and return to
main, which would invoke the print routines, including those that knew how
to put in commas and dollar signs, paginate reports, print the appropriate
footnotes on the proper pages, etc. All your printer drivers could be gone
while you're doing input. All your input validation could be gone while
you're doing printing.
--
Darren New, San Diego CA, USA (PST)
Serving Suggestion:
"Don't serve this any more. It's awful."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New escreveu:
> nemesis wrote:
>> really?! What was it? An settable option for the compiler?
>
> So say you had a piece of code that would take input, do some
> calculations, then print the report.
>
> "main" would be in the root, along with things like printf(), malloc(),
> etc. And anything else that was used in more than just input, calcs, or
> print.
>
> Main would call your top input routine, which would cause that chunk of
> code to be read in and branched to. It would take the inputs it needs
> and save them out to a file (or memory or whatever). Input routines
> would return with a flag that says "Yes, go run the calcs", so Main
> would invoke the calcs.
>
> You'd overlay input on top of calcs, so while you're doing the math,
> your input validation routines and code to draw menus and widgets and
> such doesn't need to be around.
>
> Your calcs would write out their results (say, in a CSV file) and return
> to main, which would invoke the print routines, including those that
> knew how to put in commas and dollar signs, paginate reports, print the
> appropriate footnotes on the proper pages, etc. All your printer drivers
> could be gone while you're doing input. All your input validation could
> be gone while you're doing printing.
you are into this for a long time, huh, dude? :)
if you didn't give up in the hard hairy days, it's certainly not today...
--
a game sig: http://tinyurl.com/d3rxz9
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 18/01/2011 16:16, Invisible nous fit lire :
> As far as computer programming is concerned, writing programs which
> aren't single-threaded is a "hard problem". Oh, it depends on the task
> of course. But many programs are just really awkward to write in a way
> that utilises multiple cores.
Multiple jobs|tasks is a concept available to your desktop since 1984 (I
do not speak of mainframe) on an English home computer.
(single core, time slicing scheduler in the kernel)
Yet many programmers have still issue with a single program and its
sequential calls in Functional Programming.
And sometime the specifications themselves are just sequential.
And sometimes people have trouble with synchronisation & protection
mechanisms. (Why should I use a mutex to protect that shared array of
data ?)
>
> Part of that is the design of the system, of course. The design worked
> OK when there was only one processor, but having several starts to
> stress the design assumptions. Multiple cores fight over available
> memory bandwidth, unified cache, and cache coherence.
Most of the time the issue is not about that fight, but the design (or
lack of it) for the program: the programmers start with a basic loop
with minimal functionality, then push in more patches & kludges to
extend it. Or when it goes parallel, it goes to the other extreme: every
single "object" get its own threads...
The time is long gone where a programmer would optimise a code (in
assembly) to fill in the cache just in time...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis wrote:
> you are into this for a long time, huh, dude? :)
This is the DOS 3 timeframe. Before that, architectures were even more
screwy in mainframes.
> if you didn't give up in the hard hairy days, it's certainly not today...
It's actually somewhat harder nowadays, in some ways. Now it's so easy that
every bozo can build something that your boss thinks will save you time.
--
Darren New, San Diego CA, USA (PST)
Serving Suggestion:
"Don't serve this any more. It's awful."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] san rrcom> wrote:
> nemesis wrote:
> > you are into this for a long time, huh, dude? :)
>
> This is the DOS 3 timeframe. Before that, architectures were even more
> screwy in mainframes.
>
> > if you didn't give up in the hard hairy days, it's certainly not today...
>
> It's actually somewhat harder nowadays, in some ways. Now it's so easy that
> every bozo can build something that your boss thinks will save you time.
>
> --
> Darren New, San Diego CA, USA (PST)
> Serving Suggestion:
> "Don't serve this any more. It's awful."
I don't know about other manufacturers, but the IBM OS/360 systems
had an overlay mechanism much like you described in your earlier post.
You described an overlay structure to the linkage editor, and it
linked your program. When your program ran, the modules were loaded into
the overlay areas when called. I don't recall anything particularly screwy
about that. At one time all our programs had to run in a maximum region
(memory) size of 250K. When you ran on a real memory system with less than 1M
of memory, you did what you had to do.
Isaac.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Clarence1898 wrote:
> I don't recall anything particularly screwy
> about that.
The IBM OS/360 wasn't the one I was talking about. :-)
Some of the older HP machines had really funky hardware architectures. Stuff
like a segment for each "object" and so on. Or the Burroughs B series. The
sort of stuff you couldn't even run C on.
--
Darren New, San Diego CA, USA (PST)
Serving Suggestion:
"Don't serve this any more. It's awful."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 18/01/2011 07:24 PM, nemesis wrote:
> really?! What was it? An settable option for the compiler?
I think FactInt uses overlays. Go read the source code... :^)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
