Re: Creating several types from a base type and conversion

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

On 2020-01-21 23:35, Shark8 wrote:
> On Saturday, January 18, 2020 at 5:49:17 AM UTC-7, Ken Roberts wrote:
>>
>> The concept is emulating a 30-bit computer from olden days.
> Then allow me to suggest you do that, instead:
> 
>     Type Word is range 0..2**30-1
>      with Size => 30;
> 
> this allows you to also do something like this:
>    Function Convert( Data : Integer ) return Word
>      with Inline, Pre => Data in Integer(Word'First)..Integer(Word'Last);

This won't work in Janus/Ada or other Ada compilers (if there are 
any...) with a 16-bit Integer. Better use a user-defined type with a 
sufficient range.

>> It was my understanding that a boolean array would be better than an
>> integer in order to do some of the bit manipulations that the old
>> computer was designed for.

> That might be true; though If you're going that route you may want to
> number the array indices 1..30.

Why? Bit numbers normally start at zero, in either bit-number order, and 
in all computer manuals and instruction sets I have ever seen.

(The rest of my comments are addressed mainly to Ken Roberts.)

>> 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.

> 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.

>> 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.

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.

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