Alternatives to ROM. Magnetic vs. Electric

[Ian]

Well, a plugboard can be used also to program an _analog_
computer. I had fun with those in college. Great at
solving certain problems. Wonderfully smooth output curves.

And some fell on stony ground....
(thank goodness!)

Regards
Ian

;-)

 

[MooseFET]

(e-mail address removed) says... [.....]

Some machines have "loadable control stores". We really don't want to
start taking about them, do we.

Why not? ;-)

SSSSHHHHHH! They might hear you!

It is.

Learn something new every day.

 

[Robert Redelmeier]

I don't think this is what happens. It is more likely that
it is a structure like Flash memory. You really don't want
to have to publish the fact that your processor contains
such stuff unless you really need to.

They do! How else would you propagate an FDIV-like bugfix?
IIRC, the BIOS writer's guides are NDA-only, and Intel
provides the binary lump under licence.

Reloading the microcode isn't a big deal each boot,
a few kB at MB/s. Too much for embedded, though.

-- Robert

 

[chrisv]

True. Is there a way to increase the life span?

Also, why is it so expensive?

It's not "so expensive". It's expensive "compared to disk".

 

[Bob Myers]

However, I would like the storage to be as real-time and hardware as
possible.

No problem; I have yet to see any type of storage that stored
things in imaginary time OR imaginary hardware.

I know it's impractical. Just fun to brainstorm about, though. Whether
the film is color or not, wouldn't matter because video isn't being
stored on the film. Computer data and audio would be. But again, this
is for analog storage only.

If you can store data, you can store video. And of course the
color matters; you certainly wouldn't want to be storing red
video in green, would you? Something like that could rip
asunder the very fabric of reality!

Bob M.

 

[Radium]

It's not "so expensive". It's expensive "compared to disk".

Why is it more expensive?

 

[Alex Colvin]

Oh. The other type of ROM I like is analog ROM in the form of variable-

density analog B&W monaural negative [no positive and no "reversal";
just the negatives] film optical tracks. This is similar to the
optical film audio tracks used in old B&W films.

How about the Optigon?

 

[Bob Myers]

Why is it more expensive?

Primarily, because it costs more.

Bob M.

 

[kony]

No, *YOU* have to ignore all such posts if *YOU* don't want to "waste
your time" with him. You know, newsreaders have killfiles and
scoring for a reason. Use them so you don't waste your precious
time.

As already stated, it's not just my time being wasted.

Anyone who had not been aware of Radium's posting folly
would then be aware after I'd mentioned it. If you don't
like that someone mentioned it, too bad for you.

 

[Terje Mathisen]

[followups set to c.arch which I read]

They do! How else would you propagate an FDIV-like bugfix?

You cannot in fact fix any errors of the FDIV kind.

This is because FDIV is/was a non-priviledged opcode, with no way for
the OS/kernel to trap attempts to divide (by good or bad divisors).

I wrote the FDIV workaround code, and the way it worked was by replacing
all FDIV opcodes generated by nearly all x86 compilers:

Instead of a regular FDIV it would generate a call to a fixup function.
This function would first check if the current cpu actually had the bug
or not.

If not, then the CALL FIXUP instruction could be back-patched into a
normal FDIV followed by a few NOPs to make the size work out correctly.

If the bug was present, then the fixup function would go through a
number of steps to make everything work out:

- Store the (64-bit) divisor in memory, then inspect the top 10 bits of
the mantissa. If this number in the [0-1023] range did not correspond to
one of the 5 values which could trigger the bug, then the fixup function
would just jump to a regular FDIV opcode and return. This entire
operation took less than twice as long as a normal inline FDIV, so the
actual overhead was pretty reasonable since very few programs do nothing
but back-to-back FDIVs.

- If the mantissa turned out to be problematical (odds of 5:1024), then
more work was needed:

-- Save the current fp control word, then set the FPU to extended
(80-bit) mode.

-- Multiply both dividend and divisor by 15/16. Since this happened in
extended mode, both operations were exact.

-- Restore the original (64-bit) control word

- Finally, do the FDIV (with 80-bit inputs and 64-bit result!) and
return with the result.

Terje

 

[krw]

As already stated, it's not just my time being wasted.

As I already stated, it's not your job to save other people from
themselves.

Anyone who had not been aware of Radium's posting folly
would then be aware after I'd mentioned it.

Not only do you not believe people can look out for themselves but
believe they're all stupid. Have you really been appointed by the
Usenet gods to protect the stupid? Wow!

If you don't like that someone mentioned it, too bad for you.

Look who is whining about his toes.

 

[kony]

As I already stated, it's not your job to save other people from
themselves.

Nor yours to offer an opinion on whether you "like" what I
posted. If you don't, too bad.

Not only do you not believe people can look out for themselves but
believe they're all stupid. Have you really been appointed by the
Usenet gods to protect the stupid? Wow!

If you don't like it, too bad.

Look who is whining about his toes.

You seem to be better at whining than I.

 

[Robert Redelmeier]

[followups set to c.arch which I read]

ah, but as posted, I read in csiphc. Do you wanna trim?

You cannot in fact fix any errors of the FDIV kind.

Sure you can! Just not easily retroactively AFAIK, current
CPUs use BIOs-loaded microcode so faulty LUTs (among other bugs)
can get fixed.

This is because FDIV is/was a non-priviledged opcode, with no way for
the OS/kernel to trap attempts to divide (by good or bad divisors).

Your solution is probably the best. But it is not the only one:
Iff you're willing to suffer the performance hit on other FPU
instructions, an OS could leave Task Switch (the lazy x87
context save) bit 3 of CR0 set. #NM (Device not available)
exception would be raised each time, and dealt with by OS code
(subsituting FDIV as necessary). It could also use the EM
(emulation) bit 2 of CR0 to do much the same thing.

I wrote the FDIV workaround code, and the way it worked was by replacing
all FDIV opcodes generated by nearly all x86 compilers:

This way is probably better since it doesn't slow normal FPU code.

Another solution we used was to ignore the FPU bug. Our data
has _way_ sloppier tolerances and the code considers it
"converged" with far fewer bits. But some people probably are
calcing eigenvalues close to zero. I have far less sympathy
for people using Excel to do accounting.

-- Robert

 

[Radium]

Oh. The other type of ROM I like is analog ROM in the form of variable-
density analog B&W monaural negative [no positive and no "reversal";
just the negatives] film optical tracks. This is similar to the
optical film audio tracks used in old B&W films.

How about the Optigon?

The Optigon uses discs, not film. When dealing with analog optical
audio, I prefer to use similar film material as was used in the
optical audio tracks of B&W movies.

Also, it's possible to store info other than audio in an optical film
track. For example, computer codes for certain programs. I'd like to
convert my vintage Chessmaster 3000 and Mavis Beacon 2.0 CDs into
optical info stored on an analog film track. Just for the sake of
experimentation.

 

[krw]

Nor yours to offer an opinion on whether you "like" what I
posted.

Of course it is. Are you really saying that I have no right to
express an opinion? You are more of a control freak than even I
thought.

If you don't, too bad.

No, it's really to "too bad". I really don't care. You're not
important enough.

If you don't like it, too bad.
No, it's really not.



You seem to be better at whining than I.

I am just better, that's all that need be said. ;-)

 

[MooseFET]

They do! How else would you propagate an FDIV-like bugfix?
IIRC, the BIOS writer's guides are NDA-only, and Intel
provides the binary lump under licence.

Reloading the microcode isn't a big deal each boot,
a few kB at MB/s. Too much for embedded, though.

Learn something new every day. I guess the NDA is how Intel avoids
letting to much of the magic get away.

 

[kony]

You're not
important enough.

Then why did you WASTE YOUR TIME?

 

[krw]

Learn something new every day. I guess the NDA is how Intel avoids
letting to much of the magic get away.

The magic isn't documented either. It's just bits. In addition to
the stuff Robert is talking about, we had things called "chicken-
switches" for options/fixes we weren't quite sure worked. We could
always go back to the previous operation/logic, if need be. Some of
these chicken-switches controlled customer specific options, as well.

 

[krw]

Then why did you WASTE YOUR TIME?

That's simple. No waste of time at all. I love watching control
freaks twist in the wind.

 

[kony]

That's simple. No waste of time at all. I love watching control
freaks twist in the wind.

You're gotten so used to wasting time you can't even
recognize it, which is sad.