src/cpu/mips/vm/icache_mips.hpp

Tue, 26 Jul 2016 17:06:17 +0800

author
fujie
date
Tue, 26 Jul 2016 17:06:17 +0800
changeset 41
d885f8d65c58
parent 1
2d8a650513c2
child 6880
52ea28d233d2
permissions
-rw-r--r--

Add multiply word to GPR instruction (mul) in MIPS assembler.

aoqi@1 1 /*
aoqi@1 2 * Copyright (c) 1997, 2010, Oracle and/or its affiliates. All rights reserved.
aoqi@1 3 * Copyright (c) 2015, 2016, Loongson Technology. All rights reserved.
aoqi@1 4 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
aoqi@1 5 *
aoqi@1 6 * This code is free software; you can redistribute it and/or modify it
aoqi@1 7 * under the terms of the GNU General Public License version 2 only, as
aoqi@1 8 * published by the Free Software Foundation.
aoqi@1 9 *
aoqi@1 10 * This code is distributed in the hope that it will be useful, but WITHOUT
aoqi@1 11 * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
aoqi@1 12 * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
aoqi@1 13 * version 2 for more details (a copy is included in the LICENSE file that
aoqi@1 14 * accompanied this code).
aoqi@1 15 *
aoqi@1 16 * You should have received a copy of the GNU General Public License version
aoqi@1 17 * 2 along with this work; if not, write to the Free Software Foundation,
aoqi@1 18 * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
aoqi@1 19 *
aoqi@1 20 * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
aoqi@1 21 * or visit www.oracle.com if you need additional information or have any
aoqi@1 22 * questions.
aoqi@1 23 *
aoqi@1 24 */
aoqi@1 25
aoqi@1 26 // Interface for updating the instruction cache. Whenever the VM modifies
aoqi@1 27 // code, part of the processor instruction cache potentially has to be flushed.
aoqi@1 28
aoqi@1 29 // On the x86, this is a no-op -- the I-cache is guaranteed to be consistent
aoqi@1 30 // after the next jump, and the VM never modifies instructions directly ahead
aoqi@1 31 // of the instruction fetch path.
aoqi@1 32
aoqi@1 33 // [phh] It's not clear that the above comment is correct, because on an MP
aoqi@1 34 // system where the dcaches are not snooped, only the thread doing the invalidate
aoqi@1 35 // will see the update. Even in the snooped case, a memory fence would be
aoqi@1 36 // necessary if stores weren't ordered. Fortunately, they are on all known
aoqi@1 37 // x86 implementations.
aoqi@1 38
aoqi@1 39 class ICache : public AbstractICache {
aoqi@1 40 public:
aoqi@1 41 enum {
aoqi@1 42 stub_size = 0, // Size of the icache flush stub in bytes
aoqi@1 43 //FIXME aoqi
aoqi@1 44 //line_size = BytesPerWord, // conservative
aoqi@1 45 //log2_line_size = LogBytesPerWord // log2(line_size)
aoqi@1 46 line_size = 32, // flush instruction affects a dword
aoqi@1 47 log2_line_size = 5 // log2(line_size)
aoqi@1 48 };
aoqi@1 49
aoqi@1 50 //nothing to do
aoqi@1 51 static void initialize() {}
aoqi@1 52
aoqi@1 53 static void call_flush_stub(address start, int lines);
aoqi@1 54
aoqi@1 55 static void invalidate_word(address addr);
aoqi@1 56
aoqi@1 57 static void invalidate_range(address start, int nbytes);
aoqi@1 58
aoqi@1 59 static void invalidate_all();
aoqi@1 60
aoqi@1 61 };

mercurial