Or it can just read the variable y as a long and then store the data to X as a char. I don't recall the assumption that C makes when you do an assignment like this, but it does not *require* that you read y as a char.
I still don't follow how it is simpler.
Impressive !
How many gates/chips were required for this ?
Did the 1965 DTL series contain only NAND/NOR gates or did Flip-Flops or XOR gates exist as single packages ? At lest the DTL families available in Europe (mainly Philips) were not very sophisticated even in 1968.
As a related issue, what would be the simplest hardware (in the number of gates/transistors/tubes etc.) that could support a high level language and thus be able to execute any program, if the execution time is not an issue ?
No doubt this would have to be bit serial machine and the compiler would have to generate a large number of (micro)instructions for each high level language statement. Early computers had about 1000 tubes but could it be doable with a smaller number of active elements ?
There seems to be various Turing machine emulators, but are there any hardware implementations ?
Paul
Chips were still very expensive then. It contained (IIRC) about
1500 transistors and 4000 diodes. The logic element was built around a custom RC ceramic package that provided the base drive network and the collector load, and required +- 12 Volts. So the majority of the system was built out of three components. Double sided boards cost significantly more than single sided, so the system was designed to use single sided. The diodes provided the connectivity in most cases, so jumpers were rare.Two nand gates made a set/reset flip flop. Add a capacitor and resistor and you could build a toggling counter. Basically 2 diodes, 2 transistors, 2 ceramics, and one capicitor and resistor per counter element.
The net component count was as above. The memory was magnetic core, 4 bits per word, 2k words. The core was inherently non-volatile, so programming survived power cycles.
I conceived the machine as having pico-instructions executed by nano-instructions executed by micro-instructions executed by milli-instructions executed by instructions (which last were the key presses, or the recordings of such). Decimal floating point operations executed in 50 to 70 millisecs, with a clock rate of about 100 khz. No fans, the design tried to minimize dissipation. No roms, all was hard-wired.
-- Chuck F (cbfalconer at maineline dot net) Available for consulting/temporary embedded and systems.
Depends a lot on what you will use as your main memory, and how much you care about its efficiency.
A good example of a minimalistic implementation is (again) the LGP-30 which had a 4K 30-bit word drum and used germanium diodes for logic and about 100 mostly 12AT7-equivalent tubes. It had ALGOL, BASIC and a number of other compilers; some could be stored resident on a protected area of the drum, others were run in passes from paper tape. Like most drum-based machines, the programmer could optimize by positioning code and data based on rotational latency and since it was a multi-address architecture one could also use addresses and opcodes as immediate constants and use other tricks for code conservation.
Regards,
Michael msg _at_ cybertheque _dot_ org
You are mixing up endian with counting numbers.
With an x digit number, the digits to the left always have a larger weighting than the numbers to the right, irrespective of how you write down the number (ie in decimal, hexadecimal, or binary).
Why is the left most digit the highest weighting and not the lowest? Well you would have to ask _____________. Don't know enough about the history of numbers to fill in that last blank! But I am sure we have a lot of years of convention here.
Have fun.
Paul.
Your example doesn't make any sense. Address generation for your example would be made at compile/assembly time and wouldn't require any extra logic at run time.
-- "Big-Endian byte order is known as 'normal', 'intuitive', or 'obvious'. Little-Endian is sometimes called 'perverse', 'annoying', 'dysfunctional', or 'stupid'. These designations do not, of course, imply any bias or preference." Christopher R. Hertel, "Implementing CIFS" 2004
A Turing machine is a concept, not an actual machine. It consists of a finite state machine (FSM) that controls a head that can read and write a tape and move it left and right to the next bit of data on the tape. To implement it in hardware would require a definition of what the FSM does and that is application dependant. So Turing machines are a class of computer, not any particular computer.
Emulating it in software is easy since you can change the FSM at will. Building it in hardware would require a definition of the FSM or at least a limitation on the complexity of the FSM in which case it is no longer a Turing machine. Oh, and you would have to have an infinitely long tape (memory) too...
I guess you could always use a microprocessor for the FSM and write software for it. :^)
Back when code was done in ASM and silicon was expensive and slow the rules where different.
"Big-Endian byte order is known as 'normal', 'intuitive', or 'obvious'. Little-Endian is sometimes called 'perverse', 'annoying', 'dysfunctional', or 'stupid'. These designations do not, of course, imply any bias or preference."
I am sooooo confused now!, why would Little Endian be perverse, annoying & such?!?!?!
depending on the endianess: 1234 = to 4321? omg!!!! (and that is in decimal notation btw).
LOL
Everett M. Greene wrote:
It is a concept, but it can be turned into an actual machine, as long as you limit the tape to some finite length. It then becomes computationally equivalent to any physical computer.
As far as the FSM, you could implement a Universal Turing Machine. It would use an interpreted "language" with instructions that it reads from the tape itself. That way, the FSM can remain constant. For a binary tape, the smallest known design uses 24 states according to
For a hardware implementation, you would need something equivalent to a tape with bits that allows you to read current bit, overwrite current bit, and move tape forward/backwards by one step.
To control the tape, you'll need 5 flipflops for the 24 states, and a small ROM for the state machine. The ROM would map from {current state, read bit } -> { next state, write bit, tape direction }.
To perform a computation, you put the input data, and instructions on the tape, turn the machine on, and it would put the output data somewhere else on the tape.
Of course, the efficiency would be totally horrible. :)
AFAIK the mask in rlwinm instructions requires the begin and end mask bit indices to be specified.
Rob
Well, here is your change to see a reversed databus!
It is the (old) TMS99xx series. I remember using it's IEEE488 controller TMS9914 and it had D0=MSB...D7=MSB, and I didn't notice. Of course the board had the databus upside down. I rewrote the driver to redefine the control / status registers and to exchange the data bits. It worked after that, just a bit slower.
See the datasheet of a compatible chip here, page 8:
BTW: the 8051 bit addressing is litte endian, bit.0 in a byte is D0 = LSB and the instruction carries '000' in the field used to select that bit.
Regards, Arie de Muijnck
It's not really. It's just that most languages arrange numbers from left to right (even Arabic or Hebrew where words are normally right to left). This is when writing numbers; when speaking numbers many languages go the other way or mix things up. "Four and Twenty." (This may be why Arabic only looks like it switches order when doing numbers, when they're really being written least-precision first) Some languages are top to bottom also.
Big endian is only natural to people where left-to-right and highest precision first is natural. Computer memory doesn't have lefts or rights or tops or bottoms.
-- Darin Johnson
Yeah, after looking it up, that's right. I always considered the bit positions to be "amount to rotate". Ie, rotate the original register as normal, then generate the mask by also rotating 1's and 0's (which may be what occurs internally). The masks are always constants as well.
Practically speaking though, this "endianness" is irrelevant to data interchange or portability, unlike byte-endianness.
-- Darin Johnson
My understanding was that big-endian is easier to implement in hardware, at least for a modern processor with a wide bus and load-store architecture. AFAIK, most RISC processors use big-endian, and for those that support both (like the PPC and MIPS), little-endian is very much a second-class citizen, and is dropped on smaller implementations.
In the old days, when most processors were 8-bit, using little-endian format could make a big difference if you were dealing with multi-byte data. If you are trying to do arithmetic on 32-bit (or more) numbers, then little-endian ordering makes a lot of sense, so the usage probably stems from the days when 8-bit processors were used for number crunching and financial work.
Yes, that's about right for the PPC. You *really* want to avoid assembly programming on that thing. I've only used a PPC device on one project, but I even wrote the crt0 startup code in C after the initial "load stack pointer, jump to start code" assembly code.
The convention is also visible to anyone reading the user manuals, and to the guy drawing out the schematics. The scope for error here is enormous.
PPC is pretty easy to use and learn, if you ignore the rotate and mask instructions (even then you can just keep a guide handy). I certainly found it a lot less mysterious than many other assemblers and easier to use. Lots of registers, a very orthagonal instruction set, load/store with simple addressing modes, no LEA, etc.
-- Darin Johnson
That's a good point. It must require a lot of strange internal wiring to reverse the byte order between the bus and registers if the data is Little-Endian.
I asked a question (of this newsgroup?) regarding the choice of endiness made when it's an option and got not a single response. I wish somebody would have strongly told the Indians doing an ARM compiler that Little-Endian and Srecords is not the proper combination to arbitrarily assume!
I'm not convinced that it makes that much difference even in the cases you cite. Whether you increment a pointer to the data or decrement it makes little difference in the hardware.
Op Mon, 20 Nov 2006 10:56:37 PST schreef Everett M. Greene:
Why, a simple inversion of the lowest address lines will do.
-- Coos
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.