0x0

[vb_student]

Hello

can you guys tell me what is the first instruction that is executed by a desktop

i guess that the program counter of the processor points to 0x0, what instructio nwould be present at 0x0 in the memory bank?

[Al42]

You'd have to look at a listing for the BIOS. It could be almost anything. I assume you're talking about a PC. In other types of computer, the first address executed on start might not be 0. (With a Z-80, I used to put the ROM at the top of the address space, then make the hardware execute NOPs until the program counter reached the first address of the ROM. That was usually E000 or F000.)

[vb_student]

thanks for the reply

why is the mapping of the z80 in such a way that its boot up sequence starts of from e000/f000?

i am looking at this exception vector mapping

0x0000 0000 Reset
0x0000 0004 Undefined Instruction
0x0000 0008 Software Interrupt (SWI)
0x0000 000C Prefetch Abort
0x0000 0010 Data Abort
0x0000 0014 Reserved
0x0000 0018 IRQ
0x0000 001C FIQ

is this exception vector mapping just for ARM processor's?

i guess when you get an interrupt from your UART, it raises an IRQ, how does the program know that it has to go to 0x0000 0018?

[wossname]

I would suspect that the first instruction would normally be a jump to somewhere else.

In PIC chips the GOTO START instruction is the first that gets executed. In some cases this just means going straight to instruction 2.

[vb_student]

i guess the instruction at 0x0 could be something like load pc counter 0x10000000 and that is where the reset handler would be, which would probably set the clocks, initialise the memories

[sunburnt]

thanks for the reply

why is the mapping of the z80 in such a way that its boot up sequence starts of from e000/f000?

i am looking at this exception vector mapping

0x0000 0000 Reset
0x0000 0004 Undefined Instruction
0x0000 0008 Software Interrupt (SWI)
0x0000 000C Prefetch Abort
0x0000 0010 Data Abort
0x0000 0014 Reserved
0x0000 0018 IRQ
0x0000 001C FIQ

is this exception vector mapping just for ARM processor's?

i guess when you get an interrupt from your UART, it raises an IRQ, how does the program know that it has to go to 0x0000 0018?

The addresses are hardcoded into the system, I believe, which is why what you have posted is just a jump table (see how they're all exactly 4 bytes?). When an interrupt occurs (that is determined to be handled by the IRQ and not the FIQ by some mask register), the processor jumps to 0x18. When you compile code with an IRQ vector, like say, this baby:

void __attribute__((interrupt("IRQ"))) hplarmv_irq(void)
{
   mos_led_toggle(0);
   uint32_t pending = ICHP;
   pending >>= 16;
   
   while(pending & (1 << 15))
   {
      uint8_t id = (pending & 0x3f);

      switch(id)
      {
      // OS Timer interrupt / timeslice 
      case PPID_OST_4_11:
         ostimer_fired();
         break;
         
      }

      pending = ICHP;
      pending >>= 16;
   }
}

The compiler will put a branch instruction to the address of your handler in the four bytes at 0x18.

For example, the table in my current (xscale) project looksl like this:

Address		Opcode		Source
0x00000000	EA001033	B         PC+16588              $000040D4 hplarmv_fiq + 0x0004	
0x00000004	EA00102B	B         PC+16556              $000040B8 hplarmv_undef	
0x00000008	EA00102B	B         PC+16556              $000040BC hplarmv_swi	
0x0000000C	EA00102B	B         PC+16556              $000040C0 hplarmv_pabort	
0x00000010	EA00102B	B         PC+16556              $000040C4 hplarmv_dabort	
0x00000014	EA00102B	B         PC+16556              $000040C8 hplarmv_reserved	
0x00000018	EA003C95	B         PC+62036              $0000F274 hplarmv_irq + 0x000C	
0x0000001C	EA00102B	B         PC+16556              $000040D0 hplarmv_fiq

[vb_student]

thanks for the reply

i guess by hard coded it means that when the irq signal comes, at an electronic level it gates the signal in such a way that the address 0x18 is loaded into the PC< right?

[sunburnt]

I believe so, yes.

[Al42]

why is the mapping of the z80 in such a way that its boot up sequence starts of from e000/f000?

It's not - the Z-80 starts executing at 0. The old trick was to run the data pins through 2 inverting buffers to the data buss. That way, if the buss-side buffer was turned off, the Z-80 saw 0x00 on its data pins, which is an NOP (no operation) instruction, so it would just increment the program counter, execute the next instruction (another NOP), increment the PC, etc. At 0xE000, part of the hardware would turn the buffer on, so the Z-80 would begin to execute the instructions in the ROM, which was at 0xE000 (or 0xF000, or wherever you put it, up against 0xFFFF, so it only took up the top of memory - no one thought that 58k or 56k or whatever was "all anyone would ever need". there were even designs that put the ROM in another memory bank, so there was a full 64k of RAM available.)

i am looking at this exception vector mapping

Interrupts are implemented in about as many ways as there are CPU architectures. In the Z-80, the table address was formed by the last 16 bits (LSBs) of the address buss - the MSBs were programmed at boot. It was the responsibility of the device causing the interrupt to put the LSBs on the buss.

[vb_student]

thanks for the reply

why would the hardware turn the buffer on at 0xe000, why not before?

[Al42]

The hardware was set to turn the buffer on at the lowest address of the BIOS ROM - it was usually E000 or F000 in those systems, depending on how fancy the BIOS got. (I usually set mine to one page at FF00, with code to page another few k into the memory space during BIOS access. You have to get creative when you have to load the code with a shoe horn and a sledge hammer. The video RAM usually also resided up around there, so it could be fun.)

[vb_student]

thanks for the reply

why wouldn't the BIOS ROM start from 0x0? the bBIOS is the boot loader, correct?

[Al42]

It is. But in CP/M you want the low addresses free - CP/M resides as high as possible (top address - length of BIOS) - I don;t know if the newer Mac OSs still do that, but the older ones did. In the PC, the BIOS resides starting at 0. Also, the PC is segmented, the Z-80 isn't. (Segmentation means that every segment has an offset address of 0, so legacy code [ported CP/M code] can reside in low memory - which was 0x100, not 0. The first page, 0-0xFF, was reserved for system use.)

[vb_student]

thanks for the reply

i suppose normal boot loaders start of 0x0 but cp/m (did it include a boot loader) started of 0xf000.

i did not understand by what you mean by every segment has an offset address of 0x0

what sort of system use was the first page used for, i thought the typical system use was OS and boot loader use?

[CornedBee]

Actually, the x86 boot loaders don't start at address 0 either. The BIOS loads the initial 512 bytes of boot information into 0x7c.

[Al42]

i suppose normal boot loaders start of 0x0

There's no such thing as "normal boot loader". The person coding that part of the OS (or his boss) picks an address for various reasons.

i did not understand by what you mean by every segment has an offset address of 0x0

Addresses in x86 machines take the form of segment:offset. A segment is a 16 byte boundary. The address of the first byte of the segment is segment:0 (whatever number "segment" represents).

what sort of system use was the first page used for

It's been decades, but IIRC (and I probably don't), 0 was a jump to the reboot address, 5 was a jump to the start of the BDOS.

i thought the typical system use was OS and boot loader use?

It is where the OS is low and the boot loader is at 0. It's not in DOS or Windows (or CP/M or MacOS or ...). I don't recall how TRSDOS and the Apple OS were laid out. In Windows the low pages are used for system variables (I/O addresses, keyboard state, etc.)