>From: "Allison" <ajp166 at bellatlantic.net>
>
>>
>>Subject: Anyone playing with the 8x300
>> From: "Dwight K. Elvey" <dwight.elvey at AMD.com>
>> Date: Fri, 13 May 2005 14:29:31 -0700 (PDT)
>> To: cctalk at classiccmp.org
>>
>>Hi
>> I'm looking at an application of the 8X300 by
>>Signetics. This is for a hard disk controller.
>>Is anyone fiddling with simmulators for this processor.
>>It seems like someone was a while back.
>> My current application is on an Olivetti M20 not
>>a TRS80.
>>Dwight
>>
>
>Ah the classic first of the fast microcontrollers.
>I'd have to dig but I vaguely remember the 8x300
>as a disk controller apnote. Nasty beast to program.
>
>Allison
>
Hi
Don't know why you'd say this, it only has 8 instructions!
I've got the spec posted to Al's site.
This controller application is a little interesting in that
who ever designed this board, also must have done a bitslice
designs at one time or another. To save a machine cycle, all
I/O addresses are selected by a ROM tied to the instruction
addressing. Normally it would take two cycles, one to write
the I/O address and one to transfer the data. With the
ROM, the address is understood by the program's execution
address location.
Dwight
>From: "Paul Koning" <pkoning at equallogic.com>
>
>>>>>> "Dwight" == Dwight K Elvey <dwight.elvey at amd.com> writes:
>
> >> From: "Lyle Bickley" <lbickley at bickleywest.com>
> Dwight> ---snip--- The first sentence in
> >> the final paragraph reads: "The moral of this discussion is that
> >> writing code which depends on order of evaluation is a bad
> >> programming practice in any language."
> >>
> >> I'll buy that.
>
> Dwight> Hi Interesting! I've always considered order of execution to
> Dwight> be one of the fundamentals of being able to predict what a
> Dwight> computer does. I've always thought of it as an accentual part
> Dwight> of programming with predictable results.
>
>That's true for a single CPU sequential computer without any
>interrupts going on. It isn't true if you run things in parallel on
>several CPUs. It may not be true in multi-issue computer (which is
>most modern fast CPUs) if the architecture has sufficiently relaxed
>ordering rules.
>
>But all that applies to the hardware. Many programming languages
>don't specify a single order of doing everything in every possible
>program, but instead leave things partially unspecified, so the
>translation from source code to machine language has more
>opportunities for optimization. So even if a machine is fully
>sequential and fully ordered, the high level language programs you
>feed it might not be.
>
> paul
Hi
The last place I worked, the processor was designed to
be able to optimize by doing out of order execution ( HaL
computer system, first Sparc64 ). They soon discovered the
problem when dealing with I/O. They, luckily, had a
sequential mode that they could switch to during I/O
operations that made the order predictable. You'd have
thought that someone in the design team might have realized
the problem.
Dwight
At 18:33 13/05/2005 -0400, you wrote:
>> Now, tell me what will be printed:
>
>> int i = 0;
>> i = i++;
>> printf("%d\n", i);
>
>Whatever the implementation feels like giving you.
EXACTLY! - that is the only truly correct answer.
Expected/likely answers are 0 and/or 1 ... but this is NOT
guaranteed by the standard.
>Again, i is being modified multiple times between sequence points, so
>it's nasal demon time.
Although the nasal demon theory has been around for a long time, I
am certain that this will not be the result here - not of my machines
are fitted with appropriate I/O hardware to cause this - but as was
pointed out many years ago - it COULD be the result!
Yes - this is essentually the same scenario - I just removed any
doubt caused by order of execution of function parameters - this is
an example of prime undefined behaviour.
>/~\ The ASCII der Mouse
>\ / Ribbon Campaign
> X Against HTML mouse at rodents.montreal.qc.ca
>/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
PS: Sorry to be so brief on the phone (family movie in progress)...
see you on sunday.
Dave
--
dave04a (at) Dave Dunfield
dunfield (dot) Firmware development services & tools: www.dunfield.com
com Collector of vintage computing equipment:
http://www.parse.com/~ddunfield/museum/index.html
>From: ard at p850ug1.demon.co.uk
>
>> Assuming the stack is cleared by RUN then you can nest 40 to
>> 50 levels of GOSUBs in most 6502 BAISCs.
>
>Is there any reason why the BASIC subroutine stack has to be the
>processor hardware stack?
>
>-tony
>
Hi
There is no rule, just that it was fast so why not?
Dwight
>From: "Lyle Bickley" <lbickley at bickleywest.com>
>
>On Friday 13 May 2005 14:37, Dwight K. Elvey wrote:
>> From: "Lyle Bickley" <lbickley at bickleywest.com>
>> ---snip---
>> The first sentence in
>>
>> >the final paragraph reads: "The moral of this discussion is that writing
>> > code which depends on order of evaluation is a bad programming practice
>> > in any language."
>> >
>> >I'll buy that.
>>
>> Hi
>> Interesting! I've always considered order of execution
>> to be one of the fundamentals of being able to predict
>> what a computer does. I've always thought of it as
>> an accentual part of programming with predictable results.
>> Each to their own I say.
>> Dwight
>
>The section (and prior discussion) was related to writing code dependent on a
>compilers interpretation of order - as opposed to the programmers purposeful
>order.
>
>Lyle
Sorry, I must have read it out of order :)
My point was that the language should always
have defined order, regardless of what the compiler
was interpreting. Maybe there is something basically
flawed in the concept of that method of interpreting!
The basic concept of a computer language is to define
the operations you'd like done in order! I know that
one could break the sequence into several pieces to
enforce order but I consider it a serious flaw that
one has to be careful about how it interprets order.
I consider order to be one of the most fundamental
concepts of programming. Most everything else is just
nice features.
I repeat, there are languages that do not have ambiguous
order issues.
Dwight
> http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=5196808330
> He's right --- it's a Alto Hawley mouse.
There are actually two there. The optical one uses the sensor
designed by Dick Lyon.
The wirewrapped Alto to Nova interface boards are something I
hadn't seen before.
I have a few ideas who the retired Apple engineer in Seattle
would have been that would have had this stuff. If this
actually sells for 2K, I may think about selling some of the boxes
of Alto parts that I have.
>> Assuming the stack is cleared by RUN then you can nest 40 to
>> 50 levels of GOSUBs in most 6502 BAISCs.
> Is there any reason why the BASIC subroutine stack has to be
> the processor hardware stack?
No, it's just quicker and easier that way.
Lee.
.
___________________________________________________________
Yahoo! Messenger - want a free and easy way to contact your friends online? http://uk.messenger.yahoo.com
>From: "Lyle Bickley" <lbickley at bickleywest.com>
---snip---
The first sentence in
>the final paragraph reads: "The moral of this discussion is that writing code
>which depends on order of evaluation is a bad programming practice in any
>language."
>
>I'll buy that.
Hi
Interesting! I've always considered order of execution
to be one of the fundamentals of being able to predict
what a computer does. I've always thought of it as
an accentual part of programming with predictable results.
Each to their own I say.
Dwight
I know an ex-HP field engineer that needs to read some data off 4mm DAT that
was created on an HP A900 RTE-A system. The tapes are in either ASave or FC
format. I have no A900's in my collection or I'd help him out myself.
Does anyone know of a program that will read ASave or FC format tapes from
RTE, and just dump the files on the local drive of a unix box? Or, in the
absence of such a program, does anyone have an A900 with DAT, and LAN that
they would loan/rent for a short period?
Please reply off-list
Kind regards,
Jay West
