Re: Creating several types from a base type and conversion

[Ken Roberts <alisonken1@gmail.com>]

On Tuesday, January 21, 2020 at 3:06:55 PM UTC-8, Niklas Holsti wrote:
> On 2020-01-21 23:35, Shark8 wrote:
> > On Saturday, January 18, 2020 at 5:49:17 AM UTC-7, Ken Roberts wrote:

<snip>

> >> One example:
> >>
> >> ADD LP : L[Y*(Q)]+(A) -> A
> >>
> >> Take the logical product of Y and Q register, then add A register,
> >> place results in A register.
> >>
> >> (LP being boolean AND of 2 registers)
> 
> Modular types, including Interfaces.Unsigned_32, have built-in bit-wise 
> boolean operators, so there is little advantage in using arrays of 
> booleans instead of modular types.
> 
> >> I think I tried doing tagged records and subtypes, but kept getting
> >> errors like 'Bits already mapped' when trying to extend the BaseWord
> >> (30 bit) into a data word ( 2 separate 15-bit fields) and instruction
> >> word (5 separate bit-mapped fields) while still being able to easily
> >> convert between BaseWord and others (think pulling next instruction
> >> from memory array, then pulling data from arbitrary location in
> >> memory array).
> 
> Perhaps you (Ken) did not understand that when you extend a tagged 
> record type, you are *adding* components to the components in the parent 
> type. The parent type's components are still there, and still occupy the 
> bit ranges specified in the representation clause for the parent type. 
> This is not a "remapping" or "reinterpretation" of the bits of the 
> parent type -- that is what the Unchecked_Conversion function is for.
>

I kinda understood it was not a remapping but adding components, but was kinda hoping to be able to have:

var.data = 30 bits
var.upper = upper 15 bits of data
var.lower = lower 15 bits of data

 
> > Hm, you *could* make the programs a stream and use the stream > read/write attributes. -- Though this *might* be a bit of a
> > bear to debug, it does have the advantage that you could "dump > the bits to the stream" and let the Read attribute/function take
> > care of interpreting the data.
> 
> That's a bad idea, IMO. The emulated RAM should be randomly accessible, 
> word by word, which is cumbersome and slow (if possible) for streams.
> 

Correct - I was planning on using

Memory : array (0 .. 32768) of Word;

As I noted, with modern computers this size of array would be pretty much a corner of ram.


> >> Functionally, it would be relatively easy to just ignore the hardware
> >> aspect of the emulation, but I'm trying to set it up so I can emulate
> >> the hardware later as a learning tool to how this old computer
> >> actually did things (like 1's complement subtractive addition). The
> >> real fun will be programming the timing (1MHz clock split into 4
> >> phases, with interesting interrupt handling).
> 
> It seems to me that emulating the instruction semantics (functional 
> emulation) is a reasonable goal for someone new to Ada. Emulating the 
> cycle-by-cycle operation of the HW is much more ambitious, especially 
> when various HW units are running in parallel, and I do not advise 
> starting there. Better to start from a functional emulation, and tackle 
> the cycle-accurate emulation later.
> 

The original plan was to emulate the software, but by careful planning should be able to reuse the instruction interpreter functions/procedures when it comes time to actually emulate the hardware - note that the main emulation parts are moving data between registers and bit manipulation within the registers.

> Your github documents suggest that you intend use network messages to 
> emulate data transmitted at clock-rate between the different HW units of 
> the emulated computer. I suspect that this, together with the 
> cycle/phase-specific emulation, will not let you reach your target of 
> running the emulation at the 1 MHz rate of the original computer.
> 

The network emulation is not for messaging between computer sections - it's for emulating the cabling between the computer and peripheral equipment.

The timing is a consideration both in emulating the software as well as emulating the timing between the peripheral equipment.

The long-term project goal is to emulate the USQ-20 suite - so the message passing via network would simulate the cabling between the nodes. Node examples:

Node 1 : CP642 (unit A)
Node 2 : CP642 (unit B)
Node 3 : CP642 (unit C)
Node 4 : RD231 (Magnetic tape unit)
Node 5 : UGC13 (Teletypewriter)
Node 6 : SYA4  (PPI display - radar repeaters w/symbology)

> -- 
> Niklas Holsti
> Tidorum Ltd
> niklas holsti tidorum fi
>        .      @       .