PC_Shopping 板


LINE

完整标题: Intel 与 AMD 联手推进 APX 指令集!x86 架构迎来史上最大变革,效能提升不增功耗 原始连结: https://www.koc.com.tw/archives/641394 内文: Intel 与 AMD 这对数十年来在 CPU 市场上正面厮杀的竞争对手,正透过 x86 生态系统 顾问小组(EAG)持续深化合作。继两天前联合发布 ACE(AI Compute Extensions)AI 矩阵加速指令集白皮书之後,EAG 再度揭露了 APX(Advanced Performance Extensions )的最新细节。这项被称为「x86 自 64 位元以来最大演进」的指令集扩充,将通用暂存 器数量直接翻倍,并在不增加晶片面积与功耗的前提下显着提升效能。 https://i.imgur.com/dDlr9lf.jpeg APX 是什麽?为什麽是 x86 的重大演进? APX(Advanced Performance Extensions)是 Intel 与 AMD 共同制定的新一代 x86 指 令集扩充标准。它的核心精神非常直接:让 x86 指令集能够存取更多的暂存器( Registers)。 暂存器是 CPU 内部容量极小但存取速度极快的储存单元,负责存放正在运算的资料、指 令与记忆体位址。当指令集能存取更多暂存器时,处理器就能在更短的时间内完成更多工 作,因为大量资料可以直接在 CPU 内部处理,不需要频繁到速度较慢的记忆体中读写。 https://i.imgur.com/6wsaewW.jpeg 这项规格早在 2024 年 10 月就由 Intel 首次提出,如今在 EAG 的框架下由 Intel 与 AMD 共同推动,并释出了更多技术细节。 APX 六大核心改进 APX 并非单一功能的补强,而是对 x86 指令集架构的一次系统性升级。以下是主要改进 项目: 通用暂存器(GPR)翻倍:由现有的 16 个一举扩充至 32 个。这让编译器可以将更多资 料与变数保留在暂存器中,而非写入速度较慢的记忆体,对程式码编译与执行效率有直接 帮助。 https://i.imgur.com/2N81Nkk.jpeg 记忆体操作效率提升:经过 SPEC CPU 2017 整数基准测试的模拟验证,APX 编译後的程 式码可减少 10% 的读取操作(loads)与 20% 的写入操作(stores),代表更快且功耗 更低的程式执行。 非破坏性指令形式:传统 x86 指令大多是「破坏性」的,运算结果会直接盖掉其中一个 来源运算元。APX 新增了非破坏性版本,减少暂存器复制需求,让程式码更简洁且执行更 快。 条件执行扩充:过去 x86 的条件执行仅限於 CMOV 与 SET 等少数指令。APX 新增了条件 式读取(Conditional Load)、条件式写入(Conditional Store)、条件式比较/测试( Conditional Compare/Test)以及旗标抑制功能,大幅扩展 if-conversion 的应用范围 ,减少分支预测失误。 堆叠操作强化:新增 PUSH2 与 POP2 指令,可以在一次记忆体操作中同时推送或弹出两 个暂存器,加速函式呼叫的进入与返回流程。 程式码密度不变:尽管新增了大量指令与功能,APX 并不显着增加程式码体积,并且完全 向下相容——既有的 x86 软体可以在支援 APX 的处理器上无缝执行。 与 ACE 指令集同属 EAG 框架下的战略布局 APX 的公布时间点极具战略意义。就在两天前的 4 月 30 日,Intel 与 AMD 才刚联合发 布了 ACE(AI Compute Extensions)技术白皮书,将其定位为 x86 架构的「标准矩阵加 速架构」,支援 INT8、FP8、BF16 等主流 AI 资料格式,并相容於 AVX10 指令集。 ACE 聚焦 AI 矩阵运算加速,APX 则专注於通用运算效能的全面提升:两者相辅相成,共 同构成 EAG 对 x86 架构未来发展的完整蓝图。EAG 自去年成立以来,陆续公布了 FRED (弹性返回与事件递送)、AVX10(向量指令集统一)、ChkTag(记忆体安全标签检查) 以及 ACE 与 APX 等多项核心特性。 https://i.imgur.com/s3drPcm.jpeg 不用更大面积、不必更高功耗,效能自然提升 APX 最令人惊艳的特色之一,是这些效能提升几乎不需要额外的矽晶圆面积或功耗作为代 价。Wccftech 的报导强调,APX 可以在不显着增加核心面积与功耗的情况下,实现更高 的通用运算效能:这对於晶片设计与散热解决方案来说,意义极为重大。 对开发者与消费者的意义 对於软体开发者而言,APX 最大的价值在於编译器的最佳化空间大幅增加。当编译器能够 将更多变数保留在暂存器而非记忆体中,程式就能跑得更快、更省电。尤其对於 LLVM 与 GCC 等主流编译器来说,APX 的 32 个通用暂存器将成为极具吸引力的编译目标。 对於一般消费者而言,APX 带来的效益将间接体现在日常使用中:从网页浏览、文书处理 到游戏与内容创作,支援 APX 的处理器将能以更低的功耗完成相同的工作,或在相同功 耗下提供更流畅的效能表现。 结语 Intel 与 AMD 从数十年的竞争对手,到如今在 EAG 框架下联手推进 x86 架构的演进: 这不仅是为了对抗 ARM 与 RISC-V 的新兴威胁,更是对 x86 这套走过近半世纪的指令集 架构注入全新生命力。APX 的通用暂存器翻倍、ACE 的 AI 矩阵加速标准化,再加上 FRED、AVX10、ChkTag 等一系列基础架构革新,x86 的故事显然还没有写完。 心得: 出大事了 x86要大改了,上次大改还是x86-64 x86-64的重点在於扩充暂存器长度+新增新暂存器 APX的重点在於新增新暂存器+现代风格的资料流指令 目前用的资料流逻辑还是1970年代流行的那套 从古老到现代,过去50年的历史刻在x86的指令集里面 并且x86已经做好再战50年的准备了 --



※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 36.233.109.127 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/PC_Shopping/M.1778099855.A.2E4.html
1F:→ hn9480412: 但还有一个猪队友微软 59.125.187.40 05/07 04:46
2F:推 WusoAiwen: 难怪两家股价最近这麽飙,果然商场上 101.8.48.155 05/07 06:44
3F:→ WusoAiwen: 没有永久的敌人 101.8.48.155 05/07 06:44
4F:→ olozil: 阿不就越来越像RISC 220.132.89.193 05/07 08:10
5F:推 NoneWolf: 太好了 我买AMD 42.70.198.105 05/07 08:29
6F:推 takanasiyaya: x86抄risc也已经很久了就是。 49.218.208.119 05/07 08:40
7F:推 smallreader: 新增16个暂存器不增加空间 是重新利223.139.162.224 05/07 08:56
8F:→ smallreader: 用AVX的暂存器吗(不懂就问)223.139.162.224 05/07 08:56
9F:→ olozil: 这跟AVX没什麽关系就是了 111.243.2.147 05/07 09:04
10F:推 smallreader: 看来我被"不增加面积"误导了,他们有223.139.162.224 05/07 09:28
11F:→ smallreader: 在实体上增设这16个暂存器,说的也是223.139.162.224 05/07 09:28
12F:→ smallreader: "不显着增加"面积而已223.139.162.224 05/07 09:28
13F:→ smallreader: 中文都乱写,不意外223.139.162.224 05/07 09:30
14F:推 oopFoo: 现代cpu都有几百个"虚拟暂存器",只是开 36.224.222.169 05/07 09:31
15F:推 smallreader: 第一段最後一句对应原文意思是「在不223.139.162.224 05/07 09:32
16F:→ smallreader: 显着增加...之下,能提升效能」223.139.162.224 05/07 09:32
17F:→ oopFoo: 放出来而已。基本上就是指令集的改进。 36.224.222.169 05/07 09:32
18F:→ oopFoo: NovaLake会有,Zen6应该要有。FRED已经在 36.224.222.169 05/07 09:33
19F:→ smallreader: 被翻成在不增加...下能显着提升 整个223.139.162.224 05/07 09:33
20F:→ smallreader: 意思就大转弯了223.139.162.224 05/07 09:33
21F:→ oopFoo: PTL上了。FRED在某些io上有大进步。 36.224.222.169 05/07 09:34
22F:→ oopFoo: https://reurl.cc/X2prXE 36.224.222.169 05/07 09:35
23F:→ oopFoo: fred只需要作业系统支援。apx就需要重新 36.224.222.169 05/07 09:37
24F:→ oopFoo: 编码,理论上可20%的效能提昇。 36.224.222.169 05/07 09:38
25F:推 oopFoo: 基本上,实体面积真的没什麽增加。 36.224.222.169 05/07 09:44
26F:推 olozil: 对APX不用太期待,基本上就是已经没什麽手 111.243.2.147 05/07 09:49
27F:→ olozil: 段了还不想大改,影响CPU的主要有计算、控 111.243.2.147 05/07 09:49
28F:→ olozil: 制、IO、同步,增加暂存器就是对计算与控 111.243.2.147 05/07 09:50
29F:→ olozil: 的部分增强,但效果有限,IO来说你加大了 111.243.2.147 05/07 09:50
30F:→ olozil: L1反而性能会下降,你把L1从32K->48K 111.243.2.147 05/07 09:50
31F:→ olozil: 访问就会从4个cycle变5个cycle, 111.243.2.147 05/07 09:50
32F:→ olozil: 然後掉性能,X86最大的问题一直是记忆体的 111.243.2.147 05/07 09:50
33F:→ olozil: 一致性,这是RISC不会有的问题 111.243.2.147 05/07 09:50
34F:推 smallreader: 就算是虚拟的也要有实体位置支援吧223.139.162.224 05/07 09:57
35F:推 olozil: 直接举例来说,上一次加暂存器是X86-64, 111.243.2.147 05/07 09:57
36F:→ olozil: 然後这次幅度还会比上次小一点 111.243.2.147 05/07 09:58
37F:→ smallreader: 不然能并行的线头数量会减少(?)223.139.162.224 05/07 09:59
38F:推 oopFoo: 记忆体的一致性,TSO,有好有坏。现代cpu 36.224.222.169 05/07 10:01
39F:→ oopFoo: 的性能,根本发挥不出来。记忆体频宽又小 36.224.222.169 05/07 10:02
40F:→ oopFoo: 所谓的虚拟其实就是实际暂存器,我讲的 36.224.222.169 05/07 10:04
41F:→ oopFoo: 有点反过来。实际有几百个暂存器,cpu会 36.224.222.169 05/07 10:04
42F:→ oopFoo: 虚拟成好几组,同时使用。现在只是开放 36.224.222.169 05/07 10:05
43F:→ oopFoo: 给程式直接使用,可缩短程式码,更有效率 36.224.222.169 05/07 10:06
44F:推 smallreader: 嗯 反过来 实体=几百个 虚拟=一个执223.139.162.224 05/07 10:06
45F:→ smallreader: 行绪所看到的223.139.162.224 05/07 10:06
46F:→ oopFoo: 的应用。 36.224.222.169 05/07 10:06
47F:推 CyBw: 还没要升x86-128吗,都几年了 114.35.167.130 05/07 10:09
48F:推 oopFoo: 暂存器增加多吧,x64加8个,apx加16个。 36.224.222.169 05/07 10:14
49F:→ oopFoo: cpu内部看到的暂存器跟程式码不一样。例如 36.224.222.169 05/07 10:15
50F:→ oopFoo: store [rax]然後接着load rax,cpu会用两 36.224.222.169 05/07 10:16
51F:→ oopFoo: 暂存器,因为它们互不干扰,可以平行处理 36.224.222.169 05/07 10:17
52F:→ oopFoo: 你要一个cycle同时处理8个指令,那这八个 36.224.222.169 05/07 10:18
53F:→ oopFoo: 指令不能互相依赖。太少暂存器就容易制造 36.224.222.169 05/07 10:19
54F:→ oopFoo: 依赖。 36.224.222.169 05/07 10:19
55F:推 nrsair: 新指令集扩充 49.217.202.62 05/07 10:20
56F:推 s25g5d4: 6202 年还在谈 CISC/RISC 就落伍了,是没 211.22.64.132 05/07 10:31
57F:→ s25g5d4: 看到 ARM 近几年疯狂加各种 SIMD 指令集 211.22.64.132 05/07 10:31
58F:→ s25g5d4: ,ARM 跟 x86 这几年差异主要在 variable 211.22.64.132 05/07 10:31
59F:→ s25g5d4: instruction length 而已。ARM 现在也是 211.22.64.132 05/07 10:31
60F:→ s25g5d4: decoder 拆 mOP 下去跑,跟 x86 一样, 211.22.64.132 05/07 10:31
61F:→ s25g5d4: 只是 fixed length decoder 比较好做而已 211.22.64.132 05/07 10:31
62F:推 kuninaka: 股价飙跟这没关系啊 1.174.97.117 05/07 10:46
63F:→ kuninaka: 那是AI需求 1.174.97.117 05/07 10:46
64F:→ h311013: 苹果推自研真的是很有远见 61.227.103.243 05/07 11:31
65F:推 wahaha99: 就算是实体暂存器 占用空间也还好 37.19.205.168 05/07 11:35
66F:→ wahaha99: 君不见现在占CPU最多的早就不是逻辑单元 37.19.205.168 05/07 11:35
67F:推 takanasiyaya: Apple从来就喜欢自研,只有core2时 49.218.208.119 05/07 12:43
68F:→ takanasiyaya: 代的Intel真的太厉害才低头用Intel 49.218.208.119 05/07 12:43
69F:→ takanasiyaya: ,不然全部都嘛用自己的。不过M系列 49.218.208.119 05/07 12:43
70F:→ takanasiyaya: 记忆体架构有创新是真的有意义 49.218.208.119 05/07 12:43
71F:→ labbat: 存储记忆体都是公共资源,通用暂存器都是 39.15.56.30 05/07 12:47
72F:→ labbat: 特定执行绪限定资源,编译器活用可以减轻 39.15.56.30 05/07 12:47
73F:→ labbat: 汇流排负担 39.15.56.30 05/07 12:47
74F:推 Bencrie: 我想得到的好处就 x86-64 ABI 呼叫函数 60.251.10.52 05/07 12:51
75F:→ Bencrie: 的时候 args 塞 regs 的上限变高 60.251.10.52 05/07 12:51
76F:推 guanting886: 看起来虽然是APX很厉害 但感觉上是 42.78.166.15 05/07 13:16
77F:→ guanting886: 两边找机会把过去的技术债一起清掉 42.78.166.15 05/07 13:16
78F:→ guanting886: 之前有多少0day搞到资料中心很紧张 42.78.166.15 05/07 13:16
79F:推 ltytw: 清掉技术债怎麽不是找时间重新发明X86? 36.234.230.69 05/07 13:20
80F:→ ltytw: 例如什麽X86 Gen2 然後顺便清掉技术债或 36.234.230.69 05/07 13:20
81F:→ ltytw: 屎山代码 36.234.230.69 05/07 13:21
82F:推 tsairay: 清掉技术债不是叫你不要向下相容 202.39.11.150 05/07 13:22
83F:嘘 bhmagic: 血红姊哭哭 没人理VIA 99.118.209.229 05/07 13:29
84F:→ olozil: X86实际可用6个暂存器, _sp与_bp有限制 111.243.2.147 05/07 13:37
85F:→ olozil: 所以是 86(6) -> 86-64(16) -> APX(32) 111.243.2.147 05/07 13:38
86F:→ olozil: 这次增加幅度没有上次多 111.243.2.147 05/07 13:39
87F:→ commandoEX: 升128没啥好处吧,要说的话AVX就能处 59.125.204.130 05/07 13:47
88F:→ commandoEX: 理128/256/512 bit的数据了 59.125.204.130 05/07 13:48
89F:推 takanasiyaya: 卡难,x86的小白使用者们不允许,i 49.218.208.119 05/07 13:48
90F:→ takanasiyaya: 皇当初雄心壮志要打掉x86重练itinum 49.218.208.119 05/07 13:48
91F:→ takanasiyaya: 的结果就是被AMD x86-64闯空门进去 49.218.208.119 05/07 13:48
92F:→ takanasiyaya: 伺服器 49.218.208.119 05/07 13:48
93F:→ commandoEX: VIA授权不是过期了吗? 59.125.204.130 05/07 13:49
94F:→ ma721: 把ai放进去 101.10.87.189 05/07 14:07
95F:推 leon1757tw: 要清技术债的是x86s吧 不过被放弃了 123.110.162.31 05/07 14:17
96F:推 s25g5d4: 重新发明 x86?IA64: 211.22.64.132 05/07 14:52
97F:→ gainsborough: 只要I、A、高通、发哥还是卖SOC,那 114.41.201.174 05/07 16:10
98F:→ gainsborough: 注定就有面积大小的成本获利定价冲 114.41.201.174 05/07 16:11
99F:→ gainsborough: 突,感觉还是打不赢大面积狂堆晶体 114.41.201.174 05/07 16:12
100F:→ gainsborough: 管数量的苹果SOC(面向普通消费者) 114.41.201.174 05/07 16:12
101F:→ cor1os: 加新指令集才是淘汰老PC最快的方法 -.- 122.147.131.2 05/07 16:30
102F:推 oopFoo: _bp没有限制,_sp有限制所以_sp+_bp来存取 58.114.66.74 05/07 19:58
103F:→ oopFoo: stack frame。但esp可以offset了,ebp就可 58.114.66.74 05/07 19:59
104F:→ oopFoo: 空出来。如果你的环境许可,esp也可挪来用 58.114.66.74 05/07 20:00
105F:→ oopFoo: 。但就算6>16>32。16还是比10多啊。 58.114.66.74 05/07 20:01
106F:推 soem: 可惜X86S各方没共识,能移除一些旧时代的指 1.34.10.55 05/07 20:04
107F:→ soem: 令集的话也算是有进步 1.34.10.55 05/07 20:04
108F:推 oopFoo: 移除没有意义,因为空间占很少。现代cpu的 58.114.66.74 05/07 20:08
109F:→ oopFoo: 瓶颈在branch,在cache,在memory,这都不 58.114.66.74 05/07 20:10
110F:→ oopFoo: 是指令集的问题。x86虽然丑,但相容性100% 58.114.66.74 05/07 20:11
111F:→ friedpig: 相容性100%除了少数老旧工业软体没再更 114.32.196.169 05/07 21:48
112F:→ friedpig: 新以外 真的那麽重要吗? 114.32.196.169 05/07 21:48
113F:→ friedpig: 真的必须的旧软体没剩多少了八 114.32.196.169 05/07 21:49
114F:推 smallreader: 编译器框架很在意相容性吧223.139.162.224 05/07 22:21
115F:→ smallreader: 有一些万年不变的程式码还活在底层223.139.162.224 05/07 22:24
116F:推 oopFoo: 编译器,直译器不需要重新再来。软体生态 58.114.66.74 05/08 04:05
117F:→ oopFoo: 重新再来,就算相似也是超大工程。远望 58.114.66.74 05/08 04:06
118F:→ oopFoo: riscv。 58.114.66.74 05/08 04:07
119F:推 athraugh: 请教各位高人. CPU 对RAM 的频宽要 39.12.109.188 05/08 08:48
120F:→ athraugh: 增加,到VRAM (GPU的)那样大频宽, 是 39.12.109.188 05/08 08:48
121F:→ athraugh: 需要增加指令集 还是 对连接的实体线数 39.12.109.188 05/08 08:48
122F:→ athraugh: 量? 目前都不做的困难点是什麽. 39.12.109.188 05/08 08:48
123F:推 oopFoo: 频宽增加要实体线数量增加+高速ram。困难 36.224.222.169 05/08 09:39
124F:→ oopFoo: 点在於"贵"。之前高阶pc的需求主要来自於 36.224.222.169 05/08 09:40
125F:→ oopFoo: 游戏,游戏吃"大快取",对频宽要求反而不 36.224.222.169 05/08 09:41
126F:→ oopFoo: 高。现在ai兴起,狂吃频宽。所以之後的pc 36.224.222.169 05/08 09:42
127F:→ oopFoo: 也会在这方面加强。 36.224.222.169 05/08 09:42
128F:推 athraugh: 谢谢回复 39.12.109.188 05/08 10:58
129F:推 Rollnmeow: X86s始终没共识只有Intel提倡而已 49.214.1.195 05/08 12:08
130F:→ Rollnmeow: 这个APX才是共识下的产物 49.214.1.195 05/08 12:10
131F:推 roseritter: VRAM一般都是高速,比起MB上的RAM 223.139.62.6 05/08 12:51
132F:推 atelier: x86阵营包袱多权力也分散 改架构难度太高 101.10.218.47 05/08 13:24
133F:→ atelier: 苹果软硬体一把抓 单纯多了 又有信仰 101.10.218.47 05/08 13:25
134F:→ atelier: 换架构驾轻就熟Motorola 68000->PowerPC 101.10.218.47 05/08 13:26
135F:→ atelier: x86->Apple Silicon 101.10.218.47 05/08 13:27
136F:→ atelier: 以前PowerPC转x86 软体支援说断就断 101.10.218.47 05/08 13:28
137F:→ atelier: 苹果的使用者还不是就摸摸鼻子买新的 101.10.218.47 05/08 13:28
138F:→ xxtomnyxx: 现在似乎很多call都把资料阵列用ecx/120.126.106.155 05/08 13:46
139F:→ xxtomnyxx: rcx指向,PUSH和POP功能增加有用吗?120.126.106.155 05/08 13:47
140F:→ xxtomnyxx: 是说,以前自学组合语言时一直没弄清楚120.126.106.155 05/08 13:48
141F:→ xxtomnyxx: ,stack资料调用的速度会比offset快吗120.126.106.155 05/08 13:48
142F:→ xxtomnyxx: ?120.126.106.155 05/08 13:49
143F:推 tn601374: 哦豁 36.224.223.120 05/08 16:15
144F:→ dildoe: 起码reg 相依关系会打断一些 阿公级isa有 36.229.169.173 05/09 06:18
145F:→ dildoe: 在改 算好事吧 36.229.169.173 05/09 06:18
146F:→ dildoe: 反正主要客户是大厂 大厂homebrew多 对re 36.229.169.173 05/09 06:22
147F:→ dildoe: build 重编译 没啥感觉吧 36.229.169.173 05/09 06:22
148F:→ dildoe: 对常见calling conventions 会摸reg有什 36.229.169.173 05/09 06:26
149F:→ dildoe: 麽疑问 直接google问ai 回答都不错吧 36.229.169.173 05/09 06:26
150F:推 demintree: reg数增加,实际应用的效能不知多少 73.252.153.154 05/09 14:31
151F:推 demintree: DRAM优势在低延迟,而VRAM在於吞吐量 73.252.153.154 05/09 14:35
152F:→ xxtomnyxx: 没想过可以直接问AI,拿去问了之後觉得120.126.106.155 05/09 18:04
153F:→ xxtomnyxx: 当时自学如果有AI肯定学得更好120.126.106.155 05/09 18:05







like.gif 您可能会有兴趣的文章
icon.png[问题/行为] 猫晚上进房间会不会有憋尿问题
icon.pngRe: [闲聊] 选了错误的女孩成为魔法少女 XDDDDDDDDDD
icon.png[正妹] 瑞典 一张
icon.png[心得] EMS高领长版毛衣.墨小楼MC1002
icon.png[分享] 丹龙隔热纸GE55+33+22
icon.png[问题] 清洗洗衣机
icon.png[寻物] 窗台下的空间
icon.png[闲聊] 双极の女神1 木魔爵
icon.png[售车] 新竹 1997 march 1297cc 白色 四门
icon.png[讨论] 能从照片感受到摄影者心情吗
icon.png[狂贺] 贺贺贺贺 贺!岛村卯月!总选举NO.1
icon.png[难过] 羡慕白皮肤的女生
icon.png阅读文章
icon.png[黑特]
icon.png[问题] SBK S1安装於安全帽位置
icon.png[分享] 旧woo100绝版开箱!!
icon.pngRe: [无言] 关於小包卫生纸
icon.png[开箱] E5-2683V3 RX480Strix 快睿C1 简单测试
icon.png[心得] 苍の海贼龙 地狱 执行者16PT
icon.png[售车] 1999年Virage iO 1.8EXi
icon.png[心得] 挑战33 LV10 狮子座pt solo
icon.png[闲聊] 手把手教你不被桶之新手主购教学
icon.png[分享] Civic Type R 量产版官方照无预警流出
icon.png[售车] Golf 4 2.0 银色 自排
icon.png[出售] Graco提篮汽座(有底座)2000元诚可议
icon.png[问题] 请问补牙材质掉了还能再补吗?(台中半年内
icon.png[问题] 44th 单曲 生写竟然都给重复的啊啊!
icon.png[心得] 华南红卡/icash 核卡
icon.png[问题] 拔牙矫正这样正常吗
icon.png[赠送] 老莫高业 初业 102年版
icon.png[情报] 三大行动支付 本季掀战火
icon.png[宝宝] 博客来Amos水蜡笔5/1特价五折
icon.pngRe: [心得] 新鲜人一些面试分享
icon.png[心得] 苍の海贼龙 地狱 麒麟25PT
icon.pngRe: [闲聊] (君の名は。雷慎入) 君名二创漫画翻译
icon.pngRe: [闲聊] OGN中场影片:失踪人口局 (英文字幕)
icon.png[问题] 台湾大哥大4G讯号差
icon.png[出售] [全国]全新千寻侘草LED灯, 水草

请输入看板名称,例如:WOW站内搜寻

TOP