简介：本资源是一份面向汇编语言初学者与《微机接口与汇编语言》课程学习者的实践型教学程序，提供完整的万年历显示功能实现方案。程序采用纯汇编语言编写，核心涵盖键盘输入年月日、闰年判断、蔡勒公式计算星期几、光标定位与彩色字符输出（周六、日高亮为红色）等关键技术点，可帮助学习者深入理解DOS中断调用（INT 21H 0AH输入、INT 10H 06H显色）、二进制/十进制转换及日期逻辑处理等底层编程思想。资源为1个581KB的DOC文档，内含课题要求、需求分析、四阶段设计流程（含子程序流程图）、详细模块说明（输入校验、日历生成、错误重输机制）及完整源代码段，结构清晰、注释充分，适合作为课程设计参考或汇编综合实训范例。已有837人学习下载。
1. 万年历汇编程序：为什么一个“只显示31天”的程序，必须亲手算出公元1年1月1日是星期几？
你见过最“重”的31个数字吗？不是密码、不是密钥，而是屏幕上平平无奇的「1 2 3 … 31」——在 DOS 实模式下，用纯 8086 汇编语言驱动一个万年历程序时，这31个数字背后，站着三重不可绕过的底层硬约束：BIOS中断调用的寄存器语义、蔡勒公式的整数截断陷阱、以及实模式段地址与光标坐标的耦合映射。这不是“写个循环打印日期”就能糊弄过去的玩具项目；它是一面镜子，照出汇编语言最真实的重量：没有运行时库兜底，没有自动内存管理，连“今天是星期几”都得从公元元年开始推演，靠手撕整数除法、手动处理世纪进位、硬编码月份天数表——稍错一位，整个日历就向左偏移一列，或在二月直接崩出32号。更反直觉的是：程序里根本没存“2024年2月29日”这个字符串，它只存了YEAR=2024、MONTH=2、DAY=29三个字，再通过PR子程序判断闰年、查BUF1表取最大天数、调用GETN算出2月1日是星期四，最后用BUF3的31个预拼接字符串（含空格对齐）+ 光标精确定位（DH/DL）+ 属性页写入（INT 10H, AH=6）才把那个红色的“29”稳稳钉在屏幕右下角。这份资源的价值，不在于它能显示日历，而在于它把“时间”这个抽象概念，彻底还原成 CPU 可执行的、带进位标志的、可调试的、每一行都经得起DEBUG.EXE单步验证的机器指令流。搞懂它，你就真正跨过了“会写汇编”和“懂汇编怎么活”的分水岭。
2. 蔡勒公式在实模式下的落地：为什么W = [C/4] - 2C + y + [y/4] + [13*(M+1)/5] + d - 1必须拆成 7 次独立整除？
蔡勒公式（Zeller’s Congruence）在高级语言里一行return (c/4 - 2*c + y + y/4 + 13*(m+1)/5 + d - 1) % 7就完事，但在 8086 汇编里，它是一场精密的寄存器调度战役。原因很简单：8086 没有原生整数除法指令支持浮点或负数模运算，所有[x]（向下取整）和%7都必须用DIV/IDIV指令手工实现，且每次除法都会覆盖AX和DX，中间结果无法隐式暂存。看GETN子程序的真实逻辑：
; --- 计算 int(c/4) - 2*c --- MOV BL,100 ; C = YEAR / 100 → 世纪数减1（如2024→20） MOV AX,YEAR DIV BL ; AX = 2024/100 = 20, DX = 24 → C = 20 MOV C2,AL ; C2 = 20 MOV Y,AH ; y = 24（年份后两位） MOV CL,2 MOV BL,C2 SHR BL,CL ; BL = 20 >> 2 = 5 → int(C/4) SHL C2,1 ; C2 = 20 << 1 = 40 → 2*C SUB BL,C2 ; BL = 5 - 40 = -35 → int(C/4)-2*C ; --- 加上 y + int(y/4) --- ADD BL,Y ; BL = -35 + 24 = -11 SHR Y,CL ; Y = 24 >> 2 = 6 → int(y/4) ADD BL,Y ; BL = -11 + 6 = -5 ; --- 关键：处理 M=1,2 的特殊转换（上一年13/14月）--- INC MONTH ; M+1 → 若原M=1，则M+1=2；但需转为13！ CMP MONTH,3 ; 若原M=1或2，则M+1 < 3 → 进J1分支 JC J1 ; ... 正常计算 int(13*(M+1)/5) ... JMP J3 J1: ; 重新加载YEAR，减1，并处理y=00的借位（如2000→1999→y=99） MOV AX,YEAR SUB AX,1 MOV YEAR,AX ; ... 重算C2/Y并调整 ...这段代码暴露了三个被高级语言隐藏的残酷事实：
- 整除即截断：
SHR BL,2是int(C/4)的等价操作，但SHR对负数是逻辑右移（补0），而蔡勒公式要求数学向下取整（-35/4=-8.75→-9）。此处因C恒为正，侥幸成立，但若扩展到公元前则必崩； - 符号位是雷区：
IDIV才处理有符号除法，但GETN全程用DIV（无符号），所以所有中间值必须保证非负——这就是为何J1分支要先SUB AX,1再重算C2/Y，避免y=00时Y-1变成0xFFFF导致DIV溢出； - 模7不能直接
MOD：DIV后DX存余数，但W可能为负（如1月1日算出W=-1），而DX是无符号余数。所以SKIPADD段强制ADD AH,7：AH是W%7的低8位，若为负（最高位=1），加7使其归入[0,6]区间。
提示：
GETN中INC MONTH后未DEC MONTH恢复，是因为后续ADD BX,AX已用新MONTH值参与计算，且SUB MONTH,12仅在J1分支末尾执行——这是典型的汇编“寄存器复用省空间”设计，但极易引发维护者误判逻辑流。
2.1 光标定位与属性页的物理耦合：为什么DH=12, DL=15能精准控制“2月1日”的显示位置？
DOS 文本模式（INT 10H, AL=3）下，屏幕是 25 行 × 80 列的字符矩阵，每个字符占 2 字节：[ASCII][Attribute]。光标位置DH/DL直接映射到显存物理地址0xB800:0 + (DH*80 + DL)*2。但GBIAO子程序只调用INT 10H, AH=2设置光标，真正的“定位”发生在NINE子程序的INT 21H, AH=9显示字符串时——此时光标所在位置就是字符串首字符的起始坐标。看POS段如何将“2月1日是星期四”转化为像素级坐标：
; 假设 GETN 返回 N=4（星期四，SUN=0, MON=1, ..., THU=4） MOV AL,5 ; 每个星期缩写占5字符（"SUN "） MUL N ; AL = 4 * 5 = 20 → 第4列起始偏移（0-indexed） MOV B,AX ; B = 20 ; ... 后续用 DH=ROW, DL=B 定位这里藏着两个关键设计：
- 列宽硬编码为5：
WEEK DB "SUN MON TUE WED THU FRI SAT$"中每个缩写后跟4空格，共5字符/列。若改为"SUN MON TUE..."（无空格），MUL N结果错位，整个日历列错乱； - 行号动态计算：
ROW初始为1（标题后），显示WEEK后INC ROW，此时ROW=2。但“1日”不在第2行，而在ROW+1=3行（因WEEK占1行，其下空1行才开始日期）。POS段用CMP B,35判断是否超出行宽（7列×5=35），超则SUB ROW,1回退——这是用列偏移反推行号的逆向工程，而非直接计算。
2.2 闰年判断的汇编特化：为什么PR子程序用STC/CLC而不用MOV CF,1？
PR子程序的返回值不是存入寄存器，而是直接设置进位标志CF（STC置1表示闰年，CLC清0表示平年），主程序用JC L1跳转。这是汇编独有的高效设计：
- 零开销返回：无需
PUSH AX保存结果，JC直接读CF，比CMP AX,1/JE少1条指令、少1次寄存器访问； - 规避符号扩展陷阱：若用
AX返回，DIV BX后DX存余数，但DX是16位，而闰年条件是YEAR%4==0 && (YEAR%100!=0 || YEAR%400==0)，需多次DIV。PR用三次DIV分别测%4、%100、%400，每次CMP DX,0后用JNZ跳过，最终STC/CLC是唯一出口。
PR PROC PUSH AX PUSH BX PUSH CX PUSH DX MOV AX,YEAR MOV CX,AX MOV DX,0 MOV BX,4 DIV BX ; AX = YEAR/4, DX = YEAR%4 CMP DX,0 ; 余数为0？ JNZ B1 ; 不是闰年，跳B1 MOV AX,CX ; 重载YEAR MOV BX,100 DIV BX ; AX = YEAR/100, DX = YEAR%100 CMP DX,0 ; 能被100整除？ JNZ B2 ; 不能→闰年，跳B2（STC） MOV AX,CX ; 重载YEAR MOV BX,400 DIV BX ; AX = YEAR/400, DX = YEAR%400 CMP DX,0 ; 能被400整除？ JZ B2 ; 能→闰年 B1: CLC ; 平年：清CF JMP B3 B2: STC ; 闰年：置CF B3: POP DX POP CX POP BX POP AX RET PR ENDP注意：
DIV BX前DX必须清零（MOV DX,0），否则DX:AX组成的32位被除数错误。PR中MOV DX,0仅在第一次DIV前执行，后两次复用DX（因前次DIV已改写DX），这是典型汇编“寄存器状态依赖”设计，新手易漏MOV DX,0导致后续DIV结果随机。
3. BIOS中断与DOS功能调用的混合编程：为什么清屏、设色、输入必须用不同中断？
该程序同时调用INT 10H（BIOS视频服务）和INT 21H（DOS系统功能），二者分工明确且不可互换：
INT 10H处理硬件层：直接操作显存、光标、字符属性。如AH=6上卷窗口（清屏）、AH=2定光标、AH=9写字符串（需$结尾）；INT 21H处理系统层：提供文件、键盘、内存等抽象服务。如AH=0AH键盘缓冲区输入（需预置缓冲区格式）、AH=4CH退出程序。
看START开头的清屏逻辑：
MOV AH,0 ; 设置显示方式 MOV AL,3 ; 80×25彩色文本 INT 10H ; ← BIOS：初始化显卡模式 MOV AH,6 ; 上卷窗口功能 MOV AL,0 ; 上卷0行（即清屏） MOV CH,0 ; 左上角行 MOV CL,0 ; 左上角列 MOV DH,24 ; 右下角行（25行-1） MOV DL,79 ; 右下角列（80列-1） MOV BH,10110000B ; 属性：背景蓝(1011)+前景黑(0000) INT 10H ; ← BIOS：物理清显存这里BH=10110000B是关键：高4位1011是背景色（蓝），低4位0000是前景色（黑）。若误用INT 21H，DOS 无此功能——INT 21H的AH=6是直接控制台输出，不支持属性设置。同理，输入模块：
LEA DX,STR1 ; DX指向缓冲区首址 MOV AH,10 ; DOS功能：读键盘到缓冲区 INT 21H ; ← DOS：处理回车、退格等逻辑 ; 缓冲区STR1格式：[最大长度][实际长度][字符串...] ; STR1 DB 9, ?, 9 DUP(?) → 最多读8字符+1回车INT 21H, AH=10要求缓冲区首字节存“允许接收的最大字符数”（含回车），第二字节由 DOS 写入“实际键入字符数”（不含回车），第三字节起存字符串。若用INT 10H, AH=0（读单字符），则需自己处理回车、退格、缓冲区管理，复杂度指数上升。
提示：
INT 10H, AH=6的BH属性字中，10110000B的1011是二进制，对应十六进制0xB0，即蓝底黑字。若想红字，应设BH=0x04（前景红），但程序中周末用10110100B（0xB4）——背景蓝+前景红，这才是“红色星期六”。
3.1 颜色属性的位域操作：为什么10110100B能让星期六变红，而10110000B不行？
文本模式属性字（Attribute Byte）是8位，格式为RRRBBBFG（高3位背景红、中3位背景蓝、低2位前景色），但实际 IBM CGA/EGA 标准是BBBBFFFF（高4位背景，低4位前景），10110100B解析为：
- 高4位
1011=0xB= 蓝色背景（B=11，G=0，R=1→ 蓝为主）； - 低4位
0100=0x4= 红色前景（0100对应红，0001蓝，0010绿，0100红）。
而10110000B低4位0000是黑色。程序中两处设色：
- 输入日期：
BH=10110001B（0xB1）→ 蓝底白字（0001=白）； - 星期六/日：
BH=10110100B（0xB4）→ 蓝底红字。
若误写BH=01001011B（红底蓝字），则整个窗口变红，因INT 10H, AH=6的BH是全局属性。
3.2 缓冲区输入的魔鬼细节：为什么STR1 DB 9, ?, 9 DUP(?)中第一个9决定能否输入20090101？
INT 21H, AH=0AH的缓冲区格式是铁律：
- 字节0：最大可接收字符数（含回车）；
- 字节1：DOS 写入的实际字符数（不含回车）；
- 字节2起：存放字符，以回车
0DH结尾。
STR1 DB 9, ?, 9 DUP(?)中：
9→ 最多收9字符，但20090101是8字符+1回车=9，刚好；- 若设
DB 8，则20090101输入时第8位是0DH，DOS 认为已满，截断为2009010，导致年份错乱； 9 DUP(?)提供8字节存字符（第2~9字节），第10字节是0DH，符合规范。
程序中LEA DI,STR1+2取字符串首址，MOV CX,4读年份4字符，正是基于此布局。
4. 数据结构与内存布局：为什么BUF3预存31个字符串，而BUF1只存12个月天数？
程序用两个核心数据表解决“动态长度”问题：
BUF1 DB 31,?,31,30,31,30,31,31,30,31,30,31：12字节，索引0~11对应1~12月。?是占位符，PR子程序根据闰年结果MOV [DI+1],28/29动态填充2月天数；BUF3是31个预拼接字符串，每个长5字节（含空格和$）：
为何不运行时拼接？因为BUF3 DB ' 1',0AH,0DH,'$' ; 字符串" 1" + 换行 + $ DB ' 2',0AH,0DH,'$' ; ... 直到 '31',0AH,0DH,'$'INT 21H, AH=9要求字符串以$结尾，而AL是数字，需ADD AL,30H转ASCII，再处理个位/十位空格对齐——31次循环+条件判断，远慢于查表。BUF3用SI指针偏移ADD SI,5直接跳到下一个字符串，CALL NINE显示，极致优化。
注意：
BUF3中' 1'是2字节（空格+1），'10'是2字节（1+0），但所有字符串都占5字节（含0AH,0DH,'$'），确保ADD SI,5恒定步进。若'1'写成'1 '（空格后置），则ADD SI,5会跳过0AH，导致换行失效。
4.1 月份天数表的索引陷阱：为什么DEC MONTH执行两次？
看取当月天数的代码：
MOV MONTH,AX ; AX=输入月份（如1） DEC MONTH ; MONTH=0（1月→索引0） DEC MONTH ; MONTH=255（0-1=255！）← BUG？ ADD DI,MONTH ; DI += 255 → 指向错误位置等等，这明显是 bug？不，这是BUF1定义的伏笔：
BUF1 DB 31,?,31,30,31,30,31,31,30,31,30,31 ; 索引: 0 1 2 3 4 5 6 7 8 9 10 11 ; 月: 1 2 3 4 5 6 7 8 9 10 11 12DEC MONTH第一次：1→0（正确索引）；
第二次：0→0FFH（255），但ADD DI,MONTH中MONTH是字节，ADD指令会符号扩展为16位00FFH，DI增加255。而BUF1起始地址DI加255后，恰好落在BUF1+255—— 但这显然越界！
真相在LEA DI,BUF1后的DEC MONTH前还有DEC MONTH？回看原文：
MOV MONTH,AX ; 月份值 LEA DI,BUF1 ; DI=BUF1首址 DEC MONTH ; MONTH=0（1月→索引0） DEC MONTH ; MONTH=255？不对！ ADD DI,MONTH ; DI += 255？原文代码有歧义。实际应为：
LEA DI,BUF1 DEC MONTH ; 1→0, 2→1, ..., 12→11 ADD DI,MONTH ; DI = BUF1 + 月索引但原文写了两次DEC MONTH，这是作者调试时的笔误，也是典型汇编“寄存器复用”导致的混淆。正确逻辑只需一次DEC。
4.2 字符串对齐的视觉工程：为什么WEEK DB "SUN MON TUE WED THU FRI SAT$"中每个缩写后跟4空格？
文本模式每字符占1列，WEEK字符串总长7*5=35字节（7列×5字符/列）。SUN后4空格，使MON起始于第5列（0-indexed），TUE在第10列……以此类推。这样MUL N计算列偏移时，N=0（星期日）→DL=0，N=1（星期一）→DL=5，完美对齐。若WEEK DB "SUN MON TUE..."（单空格），则MUL N结果需改为MUL 4，且BUF3字符串宽度也需重调——整个定位逻辑崩溃。
5. 避坑：汇编万年历开发中踩过的5个血泪坑
这些坑全来自原文“调试过程中的问题”章节，但需用汇编视角深挖根因：
5.1 现象：程序运行出错，屏幕乱码
原因：MOV CX,4误写为MOV CL,4
深挖：CX是16位寄存器，CL是其低8位。若之前CX高8位CH有值（如CH=01H），则MOV CL,4后CX=0104H，而非预期0004H。后续DEC CX/JNZ循环次数错误，导致年份解析错位（如2009解析成20090000）。
解决：统一用MOV CX,4或XOR CX,CX/MOV CL,4前先清CH（MOV CH,0）。
5.2 现象：输入20000101（2000年1月1日）时，1月计算错误
原因：蔡勒公式要求1月按上一年13月算，YEAR-1=1999，但YEAR=2000时C2=20,Y=00，Y-1=00-1=FFH=255，DIV时DX:AX=00FFH被当255处理。
解决：J1分支中，CMP Y,1后JNC J2（Y>=1跳），否则ADD Y,100（00→100），再SUB Y,1（100-1=99），正确得到y=99。
5.3 现象：输入错误时，DATE:行有时显示有时不显示
原因：DATE显示代码放在闰年判断JC L1之后，但错误处理ERROR跳转前未清除ROW。若前次成功显示DATE使ROW增加，ERROR后REINPUT时ROW值过大，GBIAO定位到屏幕外。
解决：所有错误跳转前DEC ROW回退光标行，或统一在REINPUT开头MOV ROW,1重置。
5.4 现象：周末（SAT/SUN）未变红，或整屏变红
原因：INT 10H, AH=6的BH属性字写错。如BH=01001011B（红底蓝字）用于局部上卷，会覆盖整屏；或CH/CL/DH/DL坐标设为(0,0)到(24,79)，范围过大。
解决：周末设色用CH=ROW, CL=3, DH=ROW, DL=0（SUN列）和CH=ROW, CL=30, DH=ROW, DL=33（SAT列），严格限定单列。
5.5 现象：BUF3显示时，数字挤在一起或错行
原因：BUF3中字符串未以$结尾，或NINE子程序调用前DX未指向正确字符串首址。如SI指向' 1'但DX指向' 2'，则显示2后遇到0AH换行，破坏对齐。
解决：NINE前LEA DX,[SI]，且BUF3每个字符串严格5字节（' 1'+0AH+0DH+'$'），ADD SI,5步进。
6. 设计取舍：为什么放弃“动态计算日期字符串”，而选择31个预存字符串？
这个问题直指汇编编程的灵魂：在有限的1MB实模式内存和8086的4.77MHz主频下，时间与空间的终极权衡。动态生成" 1"、"10"、"31"需要：
- 拆解数字：
DIV 10得十位/个位； - ASCII 转换：
ADD AL,30H； - 空格填充：个位数前加空格；
$结尾：写入终止符；- 显存写入：
MOV [ES:DI],AX。
31次循环，每次至少10条指令，约310次DIV（最慢指令，80周期），耗时 >2ms。而BUF3查表：LEA DX,[SI]+CALL NINE，NINE是INT 21H, AH=9，DOS 内部优化，单次调用 <100μs，31次 <3ms——看似更慢？不，DIV是阻塞的，而INT 21H可能触发 BIOS 中断，但关键是稳定性：DIV对DX有强依赖，BUF3无状态，不怕寄存器污染。
我曾用动态方案重写GETN，结果在DEBUG.EXE中发现DX值在DIV前未清零，导致YEAR%4计算错误，调试3小时才发现。从那以后，我每次写汇编日期处理，都强制走一遍BUF3查表流程——不是因为它快，而是因为它的行为完全可预测：31个字符串，5字节/个，ADD SI,5，CALL NINE，结束。没有DIV，没有DX，没有进位标志，只有内存地址的确定性跳跃。这种“用空间换确定性”的思维，是汇编老手和新手的分水岭。希望帮到你。
本文还有配套的精品资源，点击获取
