Why was godwhomismike's FYI thread closed?

[elpete77]

Like I said, ^^^^?

[agctr]

It was closed by me as the content looked to be all code.

[elpete77]

Secret code, eh? So if I input all that into an ATM, millions and millions of dollars will pour out at my feet and I won't have to ever work again?

[godwhomismike]

It was text out of the "BIOS and Kernel Developer's Guide for AMD Athlon64"

[godwhomismike]

"The BIOS and Kernel Developer’s Guide for the AMD Athlon™ 64 and AMD Opteron™ Processors is intended for programmers involved in the development of low-level BIOS (basic input/output system) functions, drivers, and operating system kernel modules. It assumes previous experience in microprocessor programming, as well as fundamental knowledge of legacy x86 and AMD64 microprocessor architecture. The reader should also have previous experience in BIOS or OS kernel design issues, as related to microprocessor systems, and a familiarity with various platform technologies, such as DDR, HyperTransport™ technology, and JTAG."

[G.T.Subie]

I lokked at that post.This all sounds like nonsense to me.But i dont know much on this subject.

[elpete77]

Crap. I just told my boss that I quit because I had a secret code that provides endless wealth.

[godwhomismike]

:lol: :lol:

 

 

The BIOS and Kernel Developer’s Guide for the AMD Athlon™ 64 and AMD Opteron™ Processors is intended for programmers involved in the development of low-level BIOS (basic input/output system) functions, drivers, and operating system kernel modules. It assumes previous experience in microprocessor programming, as well as fundamental knowledge of legacy x86 and AMD64 microprocessor architecture. The reader should also have previous experience in BIOS or OS kernel design issues, as related to microprocessor systems, and a familiarity with various platform technologies, such as DDR, HyperTransport™ technology, and JTAG.

 

 

All AMD Athlon™ 64 and AMD Opteron™ Processor-based systems must support 64-bit operating systems. As a result, all platforms must support APIC and declare it to the operating system in the appropriate tables.

The local APIC contains logic to receive interrupts from a variety of sources and to send interrupts to other local APICs, as well as registers to control its behavior and report status.

 

Interrupts can be received from:

• HyperTransport™ I/O devices, including the I/O hub (I/O APICs)

• Other local APICs (inter-processor interrupts)

• APIC timer

• Performance counters

• Legacy local interrupts from the I/O hub (INTR and NMI)

• APIC internal errors

 

 

The APIC timer, performance counters, local interrupts, and internal errors are all considered local interrupt sources, and their routing is controlled by local vector table entries. These entries assign a message type and vector to each interrupt, allow them to be masked, and track the status of the interrupt.

I/O and inter-processor interrupts have their message type and vector assigned at the source and are unaltered by the local APIC. They carry a destination field and a mode bit that together determine which local APICs will accept them. The destination mode (DM) bit specifies if the interrupt request

packet should be handled in Physical or Logical destination mode.

• In physical destination mode, if the destination field is FFh, the interrupt is a broadcast and is accepted by all local APICs. Otherwise, the interrupt is only accepted by the local APIC whose APIC ID matches the destination field of the interrupt. Physical mode allows up to 255 APICs to be addressed individually.

 

AMD Opteron™ Processors

• In logical destination mode, a local APIC accepts interrupts selected by the logical destination register (LOG_DEST) and the destination field of the interrupt using either cluster or flat format, as configured by the destination format register.

– If flat destinations are in use, bits 7–0 of the LOG_DEST field are checked against bits 7–0 of the arriving interrupt’s Destination Field. If any bit position is set in both fields, this APIC is a valid destination. Flat format allows up to 8 APICs to be addressed individually.

– If cluster destinations are in use, bits 7–4 of the LOG_DEST field are checked against bits 7–4 of the arriving interrupt’s destination field, identifying the cluster. If all of bits 7–4 match, then bits 3–0 of the LOG_DEST and the interrupt destination are checked for any bit positions

that are set in both fields, choosing processors within the cluster. If both conditions are met, this APIC is a valid destination. Cluster format allows 15 clusters of 4 APICs each to be addressed.

– In both flat and cluster formats, if the destination field is FFh, the interrupt is a broadcast and is accepted by all local APICs.

 

 

8.1 Interrupt Delivery

 

SMI, NMI, INIT, Startup, and External interrupts are classified as non-vectored interrupts.

When an APIC accepts a non-vectored interrupt, it is handled directly by the processor instead of being queued in the APIC. When an APIC accepts a fixed or lowest priority interrupt, it sets the bit in the interrupt request register (IRR) corresponding to the vector in the interrupt. (For local interrupt

sources, this comes from the vector field in that interrupt’s local vector table entry.) If a subsequent interrupt with the same vector arrives when the corresponding IRR bit is already set, the two interrupts are collapsed into one. Vectors 0–15 are reserved.

 

 

8.2 Vectored Interrupt Handling

 

The task priority register (TPR_PRI) and processor priority register (PROC_PRI) each contain an 8-bit priority, divided into a main priority (bits 7–4) and a priority sub-class (3–0). The task priority is assigned by software to set a threshold priority at which the processor will be interrupted. To calculate processor priority, an 8-bit ISR vector is set based on the highest bit set in the in-service register (ISR). Like the TPR_PRI and PROC_PRI, this vector is divided into a main priority (7–4) and priority sub-class (3–0). The main priority of the TPR_PRI and ISR are compared and the highest is the PROC_PRI, as follows:

 

If (TPR_PRI[7:4] >= ISRVect[7:4])PROC_PRI = TPR_PRI

Else PROC_PRI = {ISRVect[7:4],0h}

 

The resulting processor priority is used to determine if any accepted interrupts (indicated by IRR bits) are high enough priority to be serviced by the processor. When the processor is ready to service an interrupt, the highest bit in the IRR is cleared, and the corresponding bit is set in the ISR.

 

The corresponding trigger mode register (TMR) bit is set if the interrupt is level-triggered and cleared if edge-triggered. When the processor has completed service for an interrupt, it performs a write to the end of interrupt

(EOI) register, clearing the highest ISR bit and causing the next-highest interrupt to be serviced. If the corresponding TMR bit is set, EOI messages will be sent to all APICs to complete service of the interrupt at the source.

 

 

8.3 Spurious Interrupts

 

In the event that the task priority is set to or above the level of the interrupt to be serviced, the local APIC will deliver a spurious interrupt vector to the processor, as specified by the spurious interrupt vector register. The ISR will be unchanged and no EOI will occur.

 

 

8.3.1 Spurious Interrupts Caused by Timer Tick Interrupt

A typical interrupt is asserted until it is serviced. Interrupt is deasserted when software clears the interrupt status bit within the interrupt service routine. Timer tick interrupt is an exception, since it is deasserted regardless of whether it is serviced or not. A BIOS programs the 8254 Programmable

Timer to generate an 18.2 Hz square wave. This square wave represents the timer tick interrupt (PITIRQ) and in some interrupt configurations it is connected to the 8259 Programmable Interrupt Controller (PIC) IRQ0 input.

The processor is not always able to service interrupts immediately (i.e. when interrupts are masked by clearing EFLAGS.IM or when the processor is in debug mode). The method of interrupt delivery to the processor (wire or messages) determines system behavior for the timer tick interrupt connected to the PIC after the processor has not been able to service it for some time.

 

The PIC output INTR is identical to PITIRQ when interrupts are not serviced.

If interrupts are delivered to the processor using a wire, and the processor is not able to service the timer tick interrupt for some time, timer tick interrupts asserted during that time will be lost. The following cases are possible when the processor is ready to service interrupts:

• INTR is deasserted and it is not serviced by the processor. This will happen almost 50 percent of the time.

• INTR is asserted and it is serviced by the processor. This will happen almost 50 percent of the time.

• INTR is asserted, and it is detected by the processor. The processor sends the interrupt acknowledge cycle, but when the PIC receives it, INTR is deasserted, and the PIC sends a spurious interrupt vector. This will happen a very small percentage of the time.

The probability of spurious interrupts, when interrupts are delivered to the processor using a wire, is very low. An example of a configuration that uses wire to deliver interrupts to the processor has PITIRQ connected to PIC IRQ0, and PIC INTR connected to LINT0 of an AMD Athlon processor.

 

If interrupts are delivered to the processor using messages, and the processor is not able to service the timer tick interrupt for an extended period of time, the INTR caused by the first timer tick interrupt asserted during that time is delivered to the local APIC in ExtInt mode and latched, and the subsequent timer tick interrupts are lost. The following cases are possible when the processor is ready to service interrupts:

• An ExtInt interrupt is pending, and INTR is asserted. This results in timer tick interrupt servicing. This occurs 50 percent of the time.

• An ExtInt interrupt is pending, and INTR is deasserted. The processor sends the interrupt acknowledge cycle, but when the PIC receives it, INTR is deasserted, and the PIC sends a spurious interrupt vector. This occurs 50 percent of the time.

There is a 50 percent probability of spurious interrupts when interrupts are delivered to the processor using messages. An example of an AMD Athlon™ 64 or AMD Opteron™ processor configuration that uses messages to deliver interrupts to the processor has PITIRQ connected to PIC IRQ0, PIC

INTR connected to IOAPIC IRQ0, and interrupts are delivered to the processor by HyperTransport messages. HyperTransport messages are always used to deliver PIC interrupts to the processor in a system with AMD Athlon™ 64 or AMD Opteron™ processors. An example of an AMD Athlon processor configuration that uses messages to deliver interrupts to the processor has PITIRQ connected to PIC IRQ0, PIC INTR connected to IOAPIC IRQ0, and interrupts are delivered to the processor by APIC 3-wire messages.

 

 

8.4 Lowest-Priority Arbitration Fixed and non-vectored interrupts are accepted by their destination APICs without arbitration.

 

 

Delivery of lowest-priority interrupts requires all APICs to arbitrate to determine which one will accept the interrupt. If focus processor checking is enabled (bit 9 of the spurious interrupt vector register cleared), then the focus processor for an interrupt will always accept the interrupt. A processor is the focus of an interrupt if it is already servicing that interrupt corresponding ISR bit is set) or if it already has a pending request for that interrupt (corresponding IRR bit is set). If there is no focus processor for an interrupt, or focus processor checking is disabled, then each APIC will calculate an arbitration priority value, and the one with the lowest result will accept the interrupt.

 

To calculate arbitration priority, an 8-bit IRR Vector is set based on the highest bit set in the IRR. Like the ISR, TPR_PRI, and PROC_PRI, this vector is divided into a main priority (7–4) and priority subclass (3–0). The main priority of the TPR_PRI, ISR, and IRR are compared and the highest is the new ARB_PRI, as follows:

 

If (TPR_PRI[7:4] >= IRRVect[7:4] and

TPR_PRI[7:4] > ISRVect[7:4]) ARB_PRI = TPR_PRI

Else if (IRRVect[7:4] > ISRVect[7:4]) ARB_PRI = {IRRVect[7:4],0h}

Else ARB_PRI = {ISRVect[7:4],0h}

 

 

 

8.5 Inter-Processor Interrupts

 

In order to redirect an interrupt to another processor, originate an interrupt to another processor, or allow a processor to interrupt itself, the interrupt command register (ICR) provides a mechanism for generating interrupts. A write to the low doubleword of the ICR causes an interrupt to be generated,

with the properties specified by the ICR low and ICR high fields.

 

 

8.6 APIC Timer Operation

 

The local APIC contains a 32-bit timer, controlled by the Timer LVT entry, initial count, and divide configuration registers. The processor bus clock is divided by the value in the timer divide configuration register to obtain a time base for the timer. When the timer initial count register is written, the value is copied into the timer current count register. The current count register is

decremented at the rate of the divided clock. When the count reaches 0, a timer interrupt is generated with the vector specified in the Timer LVT entry. If the Timer LVT entry specifies periodic operation, the current count register is reloaded with the initial count value, and it continues to decrement at the

rate of the divided clock. If the mask bit in the timer LVT entry is set, timer interrupts are not generated.

 

 

8.7 State at Reset

 

At power-up or reset, all registers take on the values listed in their descriptions. SMI, NMI, INIT, Startup, and LINT interrupts may be accepted.

When the APIC is software-disabled, pending interrupts in the ISR and IRR are held, but further fixed, lowest-priority, and ExtInt interrupts will not be accepted. All LVT entry mask bits are set and cannot be cleared. When a processor accepts an INIT interrupt, the APIC is reset as at power-up, with the exception that APIC_ID is unaffected.

[emlevins]

:icon_eek:

[jj808]

I figured it was your AMD chipped comp blowing its wad into a thread.

[alpinefun]

Can we speak English, please.

[Thrasher]

gwim- use that computer saavy to figure out how to get the average mph calculator to be accurate with bigger injectors...

[rfd425]

I don't understand any of this stuff, but I don't understand why it was closed. If it has meaning or value to some members, and it's posted in "general chat", what's the problem?

 

Seriously, Adam, could you elaborate on the reason for the closing? At worst, the thread seems harmless, unless there's some hidden meaning that is beyond my understanding.

[Guest *Jedimaster*]

It was closed by me as the content looked to be all code.

I didn't see anything about not posting code in the rules- care to enlighten us?

[gt_ltd]

[rfd425]

Adam, could you clarify this please? I am becoming increasingly confused as to what kind of threads/posts are acceptable on this board, and what are not. I would have thought, for example, that the "FYI" code thread in "general chat" was less objectionable than the flamefest in your "5MT vs. 5EAT" thread that went on for days between Mblock66 and Phuzaxeman.

 

I, as a member of the board, would rather have obscure computer code post/threads in "general chat" than have insult-ridden hijacks of legitimate car-related threads in the Technical or General Legacy forums.

[mach_six]

IBTL. boo-yah!

[elpete77]

Wow, didn't mean to create such a ruckus, just wanted to know if the FYI was a secret ATM code to be used to extract millions of dollars. Whoopsy.

[jj808]

No, its secret plans to build huge speakers that will blow the clothes off of women when you crank them above 4.

[mach_six]

fi the code was readily available from AMD site then it's not secret. If it's MS Windows source code that's different.

[Guest *Jedimaster*]

Monololy FTW

[red beast]

It was closed by me as the content looked to be all code.

 

 

01110111011010000110000101110100001000000111010001101000011001010010000001100110011101010110001101101011001000000110100101110011001000000110100001100101001000000111010001100001011011000110101101101001011011100110011100100000011000010110001001101111011101010111010000111111

[NHLEG]

Like I said in the closed thread, WTF???

[Guest *Jedimaster*]

Strangely, no response- someone PM him.

[godwhomismike]

int WINAPI WinMain

(HINSTANCE hInst, HINSTANCE hPrevInst, LPSTR cmdParam, int cmdShow)

{

char className [] = "ITBL";

WinClassMaker winClass (WinProcedure, className, hInst);

winClass.Register ();

WinMaker maker (className, hInst);

Window win = maker.Create ("Stop Closing My Threads!");

win.Display (cmdShow);

 

MSG msg;

int status;

while ((status = ::GetMessage (& msg, 0, 0, 0)) != 0)

{

if (status == -1)

return -1;

:: DispatchMessage (& msg);

}

return msg.wParam;

}