ethonion10/v86
1
0
Fork 0
Code Issues Pull requests Packages Projects Releases Wiki Activity
v86/src/acpi.js

44 lines
1.2 KiB
JavaScript
Raw Normal View History

Change CPU from closure to prototypical notation. This change was necessary for several reasons: - Code is much clearer and more modular - The CPU object is now serializeable and therefore can be safed and restored - A dynamic translator from instructions to (optimized) JavaScript is planned. It would use `new Function` to create functions at runtime. Functions created this way don't have access to any scope (except for the global scope) and therefore were not have been able to modify registers, etc. This is now possible through the cpu object - Possibly, but not necessarily a speedgain can be achieved. See http://mrale.ph/blog/2012/09/23/grokking-v8-closures-for-fun.html Additionally, some code was moved around.
2014-06-15 22:25:17 +02:00
"use strict";
Minor changes
2015-12-31 00:31:08 +01:00
/** @const */
var PMTIMER_FREQ = 3579545;
Change CPU from closure to prototypical notation. This change was necessary for several reasons: - Code is much clearer and more modular - The CPU object is now serializeable and therefore can be safed and restored - A dynamic translator from instructions to (optimized) JavaScript is planned. It would use `new Function` to create functions at runtime. Functions created this way don't have access to any scope (except for the global scope) and therefore were not have been able to modify registers, etc. This is now possible through the cpu object - Possibly, but not necessarily a speedgain can be achieved. See http://mrale.ph/blog/2012/09/23/grokking-v8-closures-for-fun.html Additionally, some code was moved around.
2014-06-15 22:25:17 +02:00
Minor changes
2015-12-31 00:31:08 +01:00
/**
* @constructor
Some annotations
2015-02-25 18:21:54 +01:00
* @param {CPU} cpu
*/
Change CPU from closure to prototypical notation. This change was necessary for several reasons: - Code is much clearer and more modular - The CPU object is now serializeable and therefore can be safed and restored - A dynamic translator from instructions to (optimized) JavaScript is planned. It would use `new Function` to create functions at runtime. Functions created this way don't have access to any scope (except for the global scope) and therefore were not have been able to modify registers, etc. This is now possible through the cpu object - Possibly, but not necessarily a speedgain can be achieved. See http://mrale.ph/blog/2012/09/23/grokking-v8-closures-for-fun.html Additionally, some code was moved around.
2014-06-15 22:25:17 +02:00
function ACPI(cpu)
{
var io = cpu.io;
var acpi = {
pci_id: 0x07 << 3,
pci_space: [
0x86, 0x80, 0x13, 0x71, 0x07, 0x00, 0x80, 0x02, 0x08, 0x00, 0x80, 0x06, 0x00, 0x00, 0x80, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x09, 0x01, 0x00, 0x00,
],
pci_bars: [],
improve pci logging
2016-01-01 17:49:21 +01:00
name: "acpi",
Change CPU from closure to prototypical notation. This change was necessary for several reasons: - Code is much clearer and more modular - The CPU object is now serializeable and therefore can be safed and restored - A dynamic translator from instructions to (optimized) JavaScript is planned. It would use `new Function` to create functions at runtime. Functions created this way don't have access to any scope (except for the global scope) and therefore were not have been able to modify registers, etc. This is now possible through the cpu object - Possibly, but not necessarily a speedgain can be achieved. See http://mrale.ph/blog/2012/09/23/grokking-v8-closures-for-fun.html Additionally, some code was moved around.
2014-06-15 22:25:17 +02:00
};
// 00:07.0 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 08)
cpu.devices.pci.register_device(acpi);
// ACPI status
Minor changes
2015-12-31 00:31:08 +01:00
io.register_read(0xB004, this, undefined, function()
Change CPU from closure to prototypical notation. This change was necessary for several reasons: - Code is much clearer and more modular - The CPU object is now serializeable and therefore can be safed and restored - A dynamic translator from instructions to (optimized) JavaScript is planned. It would use `new Function` to create functions at runtime. Functions created this way don't have access to any scope (except for the global scope) and therefore were not have been able to modify registers, etc. This is now possible through the cpu object - Possibly, but not necessarily a speedgain can be achieved. See http://mrale.ph/blog/2012/09/23/grokking-v8-closures-for-fun.html Additionally, some code was moved around.
2014-06-15 22:25:17 +02:00
{
Minor changes
2015-12-31 00:31:08 +01:00
dbg_log("ACPI status read", LOG_ACPI);
Change CPU from closure to prototypical notation. This change was necessary for several reasons: - Code is much clearer and more modular - The CPU object is now serializeable and therefore can be safed and restored - A dynamic translator from instructions to (optimized) JavaScript is planned. It would use `new Function` to create functions at runtime. Functions created this way don't have access to any scope (except for the global scope) and therefore were not have been able to modify registers, etc. This is now possible through the cpu object - Possibly, but not necessarily a speedgain can be achieved. See http://mrale.ph/blog/2012/09/23/grokking-v8-closures-for-fun.html Additionally, some code was moved around.
2014-06-15 22:25:17 +02:00
return 1;
});
Minor changes
2015-12-31 00:31:08 +01:00
// ACPI, pmtimer
io.register_read(0xB008, this, undefined, undefined, function()
Change CPU from closure to prototypical notation. This change was necessary for several reasons: - Code is much clearer and more modular - The CPU object is now serializeable and therefore can be safed and restored - A dynamic translator from instructions to (optimized) JavaScript is planned. It would use `new Function` to create functions at runtime. Functions created this way don't have access to any scope (except for the global scope) and therefore were not have been able to modify registers, etc. This is now possible through the cpu object - Possibly, but not necessarily a speedgain can be achieved. See http://mrale.ph/blog/2012/09/23/grokking-v8-closures-for-fun.html Additionally, some code was moved around.
2014-06-15 22:25:17 +02:00
{
Minor changes
2015-12-31 00:31:08 +01:00
var value = v86.microtick() * (PMTIMER_FREQ / 1000) | 0;
//dbg_log("pmtimer read: " + h(value >>> 0), LOG_ACPI);
return value;
Change CPU from closure to prototypical notation. This change was necessary for several reasons: - Code is much clearer and more modular - The CPU object is now serializeable and therefore can be safed and restored - A dynamic translator from instructions to (optimized) JavaScript is planned. It would use `new Function` to create functions at runtime. Functions created this way don't have access to any scope (except for the global scope) and therefore were not have been able to modify registers, etc. This is now possible through the cpu object - Possibly, but not necessarily a speedgain can be achieved. See http://mrale.ph/blog/2012/09/23/grokking-v8-closures-for-fun.html Additionally, some code was moved around.
2014-06-15 22:25:17 +02:00
});
}
Reference in a new issue Copy permalink