SPEC

   subject: SPEC Run Rules for CINT92     date: January 23, 1992

                                          from: SPEC Steering Committee



                             ABSTRACT



   This document provides guidelines for how to run the
   benchmarks, how to report the results (which is explained
   more fully in the document SPEC Reporting Rules) and how to
   report results for modified versions of benchmarks.  It
   contains several examples of necessary types of changes.




   Memorandum to
   Performance Analysts









































                                          SPEC



   subject: SPEC Run Rules for CINT92     date: January 23, 1992

                                          from: SPEC Steering Committee



   1.  General

   The general philosophy behind this set of rules for running
   the SPEC benchmarks is to ensure repeatability and
   documentation of all factors pertinent to duplicating
   reported performance results. Suggestions for improving this
   run methodology should be made to SPEC for consideration in
   future releases.

   In general:

      - All times reported must be for runs that produce
        correct results.

      - Single user mode is allowed.  This must be documented
        in a report of the results.

      - These benchmarks have been run across a number of
        platforms with several compilers, but are not
        guaranteed to be free of language extensions that are
        commonly found, but not part of industry standard
        language specifications.

      - Use of software features (in pre-processors, compilers,
        etc.) which invoke, generate or use software designed
        specifically for any of the SPEC Benchmark Releases is
        not allowed.

      - Source code may not be modified unless it is required
        for portability. See Section 4 (Source Code Changes)
        for specifics.



   2.  Makefiles,_Compilers_and_Libraries

   Generic Makefiles are provided for convenience and insight
   into running the benchmarks. Typically a vendor supplied
   wrapper (M.ident) is used in conjunction with the generic
   Makefile. These are provided for convenience and can be
   replaced to facilitate running benchmarks on proprietary
   operating systems or to take advantage of optimizations not
   easily activated with the current method.  It is anticipated
   that the build process which is capable of building the
   highest performance executable will be employed, even if a











                              - 2 -



   different set of optimizations are activated for each
   benchmark.

   For example, one SPEC benchmark can be built with one set of
   options and another can be built with an entirely different
   set of options.

   Special libraries may be used as long as they

     1.  are products announced for availability to customers
         within 6 months of the date of test,

     2.  do not require changing benchmark source code,

     3.  implicitly replace routines in the benchmark source
         code,

     4.  are not "benchmark specific" (i.e.targeted
         specifically for a SPEC benchmark).

   Libraries can be specified in the Makefile. Source code
   changes to eliminate default high level language subroutines
   so that optimized library versions can be used is not
   allowed.

   Accuracy verification specifications (i.e. to diff or spiff)
   must not be overridden in Makefiles (or in any other
   manner).  Only SPEC approved alternative input files are
   allowed. Use of these alternate input files must be
   documented in the footnotes section.

   It should be recognized that each company is continuously
   improving its compilation system and that new optimizations
   may be required to achieve published performance ratings.
   If you are unable to reproduce a vendor's published rating,
   please contact the vendor and ensure that you have the
   latest Makefile wrappers and equivalent system
   configuration.



   3.  Pre-Processors

      - Use of a pre-processor on unmodified source code that
        is part of the identified released software is allowed.

      - Use of benchmark specific pre-processor features is not
        allowed.

      - Documented pre-processor options may be used, and
        should be specified either in the testing report or in











                              - 3 -



        the vendor Makefile (M.ident) provided on the SPEC
        tape.


   4.  Source_Code_Changes

   SPEC policy allows only portability changes to the source
   code.  When source code changes are made, a diff listing of
   the changes must be included in the testing report.

   SPEC encourages performance comparisons to be made across
   systems running the unmodified SPEC code, or if necessary,
   with the minimum required portability changes.


      - Portability

           o Source code changes required for standards
             compliance should be described in the testing
             report.  Appropriate standards documents should be
             cited.  All such changes should be reported to
             SPEC.  SPEC may consider incorporating such
             changes in future releases.  Whenever possible,
             SPEC will strive to develop and enhance benchmarks
             to be POSIX and ANSI compliant.

             SPEC recognizes that some source code changes may
             be necessary in order to meet specific language
             implementations.  Such changes must be documented,
             appropriate references must be cited and results
             marked as portability changes (denoted by * on any
             publicly reported results).  Once these changes
             are incorporated into the tape including alternate
             source files, then the asterisk may be dropped.

           o The double precision (real*8) floating point in
             SPEC benchmarks is intended to be 64 bits.  If
             this is not the case on the machine being tested,
             modify the appropriate declarations and forward to
             SPEC the source code changes required to
             accommodate the system.  Over time, SPEC desires
             to use compiler options to eliminate the need for
             such changes.

           o If any portability change is backed off, one of
             three things must happen:

               i.  benchmark code does not compile, or

              ii.  benchmark code does not execute, or












                              - 4 -



             iii.  benchmark code produces the wrong result.


   5.  Alternate_Source_Files

   Some portability changes made to the source files may be
   generally useful to other SPEC users.  These are classes of
   codes that meet the portability requirement (i.e., code
   won't compile, or won't execute, or produces wrong result),
   but are required by one or more target systems.  In such
   instances, the files are placed in a directory named
   "src.alt" in the benchmark directory.  All files placed in
   this directory have been reviewed and approved by the SPEC
   Steering Committee; alternate source files are otherwise not
   permitted.  When alternate source files have been approved
   for inclusion, however, the M.vendor makefile must be
   modified to retrieve the appropriate version.  In general,
   original copies of codes which are to be replaced by
   alternate copies are preserved in the directory "src.std"
   for safe-keeping.  When an alternate source file is used, it
   must be annotated in the footnotes section of the report.
   The asterisk (*) is not used to denote portability changes
   when alternate source files are employed.


   6.  Alternate_Results_Files

   On occasion, one platform will cause a variance in the
   results of the benchmark which may not necessarily be
   incorrect.  In such cases, an alternate results directory,
   called "result.alt", contains additional valid results.
   Only results that have been reviewed and approved by the
   SPEC Steering Committee are placed in this directory.
   Otherwise, all results must compare with the files in the
   "result.ref" directory.  In such cases, the M.vendor
   makefile must be modified to accommodate alternate results.
   An example of such a case can be seen with the benchmark
   085.gcc.  In this program, the output is sorted by a system
   library routine. As more vendors ran 085.gcc, it became
   apparent that the sort routine produced different orderings
   among systems.  Though the results were still equivalent,
   they could not be compared directly with the results.ref
   files, hence, the addition of alternate results became
   necessary.  If alternate results are used, they must be
   specified in the footnotes section of the report.

















                                          SPEC



   subject: SPEC Reporting Rules For      date: January 24, 1992
            CINT92
                                          from: SPEC Steering Committee



                             ABSTRACT



   This memorandum describes the Rules for reporting the
   results of SPEC CINT92 suite.  This is a companion document
   to SPEC Run Rules, which describes the process of running
   the benchmarks contained in the SPEC Suite.




   Memorandum to
   Performance Analysts










































                                          SPEC



   subject: SPEC Reporting Rules For      date: January 24, 1992
            CINT92
                                          from: SPEC Steering Committee



   1.  SPEC_CINT92_Introduction

   The SPEC CINT92 benchmark suite consists of CPU intensive
   benchmarks that are intended to be meaningful samples of
   applications which perform non-floating point logic and
   computations in a technical computing environment. SPEC
   CINT92 does not assess the ability of a system under test to
   handle disk, graphics, communication, or multi-user
   activity.

   Many of the SPEC CINT92 benchmarks have been derived from
   publicly-available application programs, and they are
   intended to be portable to as many current and future
   hardware platforms as possible.  Consequently, the version
   of the programs in this distribution contains no hardware
   dependencies.  Where possible, the programs have been
   structured to ensure that they do not unfairly favor one
   hardware architecture over another.  For this reason, the
   application programs in this distribution should not be used
   to assess the probable performance of commercially
   available, tuned versions of the same application.

   Different degrees of tuning and availability of specialized
   hardware features may make large (and varying) differences
   between the performance of the programs in this distribution
   and that of commercial applications for production use.

   The individual benchmarks in this suite may be similar, but
   not necessarily identical to benchmarks with the same name
   which are available from sources other than SPEC.  Therefore
   it may not be valid to compare the individual benchmark
   results of SPEC CINT92 to any benchmarks not obtained from
   SPEC.

   Reporting of results must follow the guidelines established
   in the "Reporting Guidelines" section of the distribution
   documentation. It is not intended that the SPEC CINT92
   benchmark suite be used as a replacement for the
   benchmarking of actual customer applications to determine
   vendor or product selection.
















                              - 2 -



   2.  REPORTING_GUIDELINES

   This section describes the standard reporting format that
   must be used when reporting results using the SPEC CINT92
   benchmarks to obtain a SPECint92 rating for a system. The
   SPECint92 rating is used to describe the speed of a system.

   EXAMPLES OF REPORTING RULES FOR SPEC RESULTS CAN BE SEEN IN
   THE QUARTERLY SPEC NEWSLETTER. 1 The intent of the SPECint92
   Reporting Guidelines is to describe a consistent method of
   reporting results to aid customers in interpreting and
   comparing results of different systems' performance.

   All measured and calculated values are reported to the
   nearest tenth.

   Unless noted to the contrary, the report must contain the
   following items of information:

   2.1  Table_of_Run_Times

   A table of 7 rows and 4 columns structured as follows:

     a.  One row for each individual benchmark in SPEC CINT92

     b.  Four columns


           i.  Name of benchmark (preferred order (numerical)
               shown in example below)

          ii.  SPEC Reference Time for each benchmark in the
               suite.

                 A.  008.espresso: 2270 seconds

                 B.  022.li: 6210 seconds

                 C.  023.eqntott: 1100 seconds

                 D.  026.compress: 2770 seconds

                 E.  072.sc: 4530 seconds



   __________

    1. Articles describing the suite and metrics can be found
       in the December 1991 SPEC Newsletter.












                              - 3 -



                 F.  085.gcc: 5460 seconds



         iii.  For SPECint92, Elapsed time (rounded to the
               nearest 0.1 second) for the System-Under-Test
               (SUT) taken to run each benchmark of SPEC CINT92
               suite.


               The elapsed times reported are for each
               benchmark run one at a time.  For the SPECint92,
               the elapsed time value measures the execution of
               a single copy of each benchmark.  The reported
               times are the best times that can be
               consistently reproduced.

               If any changes to an individual benchmark are
               made for portability purposes (e.g. to obtain a
               clean compile), the elapsed time should be
               followed by an "*", and a description of the
               change should be described in PART 7 of the
               report.  The asterisk is dropped after the
               portability change has been approved by the SPEC
               steering committee as a portability change and
               not a performance change and when this change
               has been implemented in the tape.  2

          iv.  For SPECint92, Column 4 has Ratio of SPEC
               Reference Time to SUT time (divide number in
               column 2 by number in column 3).  The ratio is
               without dimension, and will be referred to as
               SPECratio.


     c.  A row with the Geometric mean for the numbers listed
         in column 4.  This row is labeled as "Geom Mean:
         SPECint92".  The Geometric Mean is calculated as the
         6th root of the product of the individual values in
         the SPECratio column.

         For SPECint92, the Geometric Mean of the SPECratios in
         column 4 is defined as the SPECint92 of the SUT.

         Please note:  if an "*" sign appears in any of the


   __________

    2. REFER to portability rules in SPEC run rules document.












                              - 4 -



         rows to indicate a portability change in a benchmark,
         the "*" must be displayed after the Geometric Mean
         calculation for elapsed time and SPECratio.

   2.2  Identification_Information

   This information includes the date (month/year) that the
   benchmarks were run, the name and location of the company
   that ran them and the license number of the SPEC tape used.
   It is typically listed under the table generated in Section
   2.1.


   2.3  Hardware_Configuration

   A description of  the system (cpu/clock, fpu/clock) number
   of processors, relevant peripherals, etc are included in
   this space.  It is typically listed next to the table
   generated in Section 2.1.  The amount of information
   supplied should be sufficient to allow duplication of
   results by another party.  The following checklist is
   provided to show examples of hardware features which may
   affect the performance of SPEC CINT92 benchmarks.  The
   checklist is not intended to be all-inclusive, nor is each
   feature in the list required to be described.  The rule of
   thumb is: "if it affects performance or the feature is
   required to duplicate the results, describe it".

   HARDWARE PLATFORM FEATURES

      o Manufacturer's model number

      o CPU component ID and clock speed

      o Floating Point Unit (FPU) ID and clock speed

      o Number of CPUs and FPUs

      o Cache Size (per CPU), description and organization

      o Memory (Amount and description)

      o Disk subsystem configuration

           - Number of active connected disks

           - Disk controllers: ID, number and type

           - Disk: ID, number and type













                              - 5 -



      o Network Interface


   2.4  Software_Configuration


   The description of the software configuration used should be
   detailed enough so that another party could duplicate the
   results reported. This is typically reported after the
   hardware decription.  The following is a list of possible
   items that might be documented:

      o Operating System Type and Release level (with
        revision/update level if appropriate)

      o Compiler release levels used.  If multiple compilers
        are available, specify which ones were used.

      o Optional software required to reproduce results

      o File system type used

      o Firmware level


   2.5  Systems_Environment


   This section should document the overall systems environment
   used to run the benchmark. It is typically listed after the
   software description. The following is a list of possible
   items that might be documented:  SYSTEMS ENVIRONMENT
   CHECKLIST

      o Single or multi-user state

      o System tuning parameters (e.g. MAKEFS and TUNEFS
        parameters)

      o Process tuning parameters (e.g. stack size, time slice)

      o Background load, if any


   2.6  General_Availability_of_the_SUT


   This item indicates the availability (or projected
   availability) date for the system or components being
   benchmarked.  If both hardware and software are not
   available at the same time, list them separately. SPEC











                              - 6 -



   requires that the availability of hardware and software
   should be within 6 months of the date of publication of the
   data. It should be listed in Month/Year format.


   2.7  Individual_Benchmark_Notes


   This section documents ANY changes made to the individual
   benchmark source code or execution parameters for
   portability reasons.  For example, if difficulty arises in
   compiling or executing an individual benchmark because of
   portability problems, the difficulty should be described,
   and the code changes made to resolve the portability problem
   documented.  This should include module name, line number
   and actual source code changes.  This section must also
   include any use of alternate source files, alternate input
   files, or alternate result files, as noted in "Runrules"
   section of the distribution documentation.


   2.8  Graphical_Representation

   If desired, a graphical summary of the table from Section
   2.1 may be included as an additional item of information.

   If included for SPECint92, it should be shown as follows:

     a.  The 6 benchmarks comprising of  SPEC CINT92  suite
         should appear as individual points on the x-axis
         ordered by benchmark numbers.

     b.  The SPECratio of each benchmark (obtained from column
         4 in the table described above), should be plotted as
         a vertical bar graph.

     c.  A horizontal line should be drawn across the graph
         intersecting the y-axis at the SPECint92 geometric
         mean value.  This permits differentiation between each
         benchmark's SPECratio and the overall SPECint92
         geometric mean.



   3.  SAMPLE_REPORTS

















                              - 7 -



   3.1  SPECint92_-_Summary_of_SPEC_CINT92_Results

    __________________________________________________________
   | SPEC Benchmark|      SPEC    |  System Under|  SPECratio|
   |     CINT92    |   Reference  |      Test    |           |
   |               |  Time Elapsed|    (Sample)  |           |
   |               |      Time    |  Elapsed Time|           |
   |               |   (seconds)  |   (seconds)  |           |
   |_______________|______________|______________|___________|
   |_______________|______________|______________|___________|
   | 008.espresso  |      2270    |     1245.0   |    1.8    |
   |_______________|______________|______________|___________|
   | 022.li        |      6210    |     2275.0   |    2.7    |
   |_______________|______________|______________|___________|
   | 023.eqntott   |      1100    |      684.0   |    1.6    |
   |_______________|______________|______________|___________|
   | 026.compress  |      2770    |     1390.0   |    2.0    |
   |_______________|______________|______________|___________|
   | 072.sc        |      4530    |      783.0   |    5.8    |
   |_______________|______________|______________|___________|
   | 085.gcc       |      5460    |     1521.0   |    3.6*   |
   |_______________|______________|______________|___________|
   | Geometric Mean|              |              |    2.6*   |
   |_______________|______________|______________|___________|


   *Changes made to benchmark for portability reasons, see PART
   7 for details

   The geometric mean is the nth root of the product of n
   elements. Therefore, in this case it is the 6th root of the
   product of 6 SPECratios in the 4th column.


   3.2  Identification_Information

   Tested on mm/yy, tested by xxxxx of (location), SPEC License
   No. yyyyy.

   3.3  Hardware_Configuration

   Hardware Configuration Detail for "Sample" system

      o Vendor machine xxxxxxx, model number nnnnnnn

      o RISC processor xxxxxx; nn MHz clock speed

      o FPU xxxxxxxx, nn MHz clock speed

      o One processor/FPU












                              - 8 -



      o n MB main memory

      o n disk drives, each nnn megabytes capacity


   3.4  Software_Configuration

   Software Configuration Detail for "Sample" system

      o Operating System name, Version nnn, update nnn applied

      o FORTRAN Version nnn

      o C Version nnn

      o Other software:  (if applicable)

      o Firmware level:  (if applicable)



   3.5  General_Availability

   The harware wil be available mm/yy and the software will be
   available in nn/yy.

   Note: When a beta version is used, the date of the final
   release must be included which must be within 6 months of
   result publication.

   3.6  Systems_Environment

   Systems Environment Detail for "Sample" system

      o Tuning Parameters:

      o Background load:

      o System state:  (Mult-user or single user)


   3.7  Notes_On_Individual_Benchmark_Runs

      - 085.gcc: was compiled using gnu compiler * 085.gcc:
        changed variable name xxxx to yyyy to avoid library
        conflict.

Sometimes, algorithmic ingenuity is only one half of the problem. Making a slow algorithm fast might be hard, but the king of algorithms is... multiple algorithms, each one being optimized and handling their respective purpose. I guess.

I tried to make "I'm an PhD in applied CS" joke, but that would be a blatant lie.

downvote tiếp đi!!! downvote đi!!! không ai quan tâm đâu...

init():

    ret

Yoshi():

    push    rax

    push2p  rbp, r15

    push2p  r14, r13

    push2p  r12, rbx

    sub     rsp, 16

    mov     rdi, qword ptr [rip + std::cin@GOTPCREL]

    lea     rsi, [rsp + 4]

    call    std::istream::operator>>(int&)@PLT

    movsxd  r12, dword ptr [rsp + 4]

    test    r12, r12

    js      .LBB1_37

    test    r12d, r12d

    je      .LBB1_15

    {nf}    shl     r15, r12, 2

    mov     rdi, r15

    call    operator new(unsigned long)@PLT

    mov     rbx, rax

    mov     dword ptr [rax], 0

    lea     r14, [rax + 4]

    cmp     r12d, 1

    je      .LBB1_4

    lea     r13, [rbx + r15]

    lea     rdx, [r15 - 4]

    mov     rdi, r14

    xor     esi, esi

    call    memset@PLT

    mov     r14, r13

.LBB1_4:

    lea     rbp, [rbx + 4*r12]

    mov     r15, qword ptr [rip + std::cin@GOTPCREL]

    mov     r12, rbx

    mov     qword ptr [rsp + 8], rbp

.LBB1_5:

    mov     rdi, r15

    mov     rsi, r12

    call    std::istream::operator>>(int&)@PLT

    add     r12, 4

    cmp     r12, r14

    jne     .LBB1_5

    movsxd  r13, dword ptr [rsp + 4]

    test    r13, r13

    js      .LBB1_38

    test    r13d, r13d

    je      .LBB1_16

    {nf}    shl     r12, r13, 2

    mov     rdi, r12

    call    operator new(unsigned long)@PLT

    mov     r14, rax

    mov     dword ptr [rax], 0

    lea     r15, [rax + 4]

    cmp     r13d, 1

    je      .LBB1_12

    lea     rbp, [r14 + r12]

    lea     rdx, [r12 - 4]

    mov     rdi, r15

    xor     esi, esi

    call    memset@PLT

    mov     r15, rbp

.LBB1_12:

    lea     rbp, [r14 + 4*r13]

    mov     r12, qword ptr [rip + std::cin@GOTPCREL]

    mov     r13, r14

.LBB1_13:

    mov     rdi, r12

    mov     rsi, r13

    call    std::istream::operator>>(int&)@PLT

    add     r13, 4

    cmp     r13, r15

    jne     .LBB1_13

    jmp     .LBB1_17

.LBB1_15:

    xor     ebx, ebx

    mov     qword ptr [rsp + 8], 0

.LBB1_16:

    xor     ebp, ebp

    xor     r14d, r14d

.LBB1_17:

    mov     ecx, 1

    xor     esi, esi

    xor     edi, edi

    jmp     .LBB1_19

.LBB1_18:

    inc     rdi

    inc     rcx

    cmp     rdi, 3000

    je      .LBB1_28

.LBB1_19:

    cmp     rdi, 2998

    ja      .LBB1_18

    mov     r8d, dword ptr [rbx + 4*rdi]

    mov     r9d, dword ptr [r14 + 4*rdi]

    mov     r10, rcx

    jmp     .LBB1_23

.LBB1_21:

    mov     eax, r16d

.LBB1_22:

    {nf}    shl     edx, eax, 13

    xor     eax, edx

    {nf}    shr     edx, eax, 17

    xor     eax, edx

    {nf}    shl     edx, eax, 5

    xor     eax, edx

    add     rsi, rax

    inc     r10

    cmp     r10, 3000

    je      .LBB1_18

.LBB1_23:

    mov     eax, dword ptr [rbx + 4*r10]

    {nf}    sub     edx, r8d, eax

    sub     eax, r8d

    cmovl   eax, edx

    mov     edx, dword ptr [r14 + 4*r10]

    {nf}    sub     r11d, r9d, edx

    sub     edx, r9d

    cmovl   edx, r11d

    cmp     eax, edx

    cmovb   r16d, edx, eax

    cmovbe  eax, edx

    test    r16d, r16d

    je      .LBB1_22

    xor     edx, edx

    div     r16d

    test    edx, edx

    je      .LBB1_21

    tzcnt   eax, edx

    tzcnt   r11d, r16d

    shrx    edx, edx, eax

    shrx    r16d, r16d, r11d

.LBB1_26:

    {nf}    sub     r17d, r16d, edx

    sub     r18d, edx, r16d

    cmovae  edx, r16d

    cmovae  r17d, r18d

    tzcnt   r16d, r18d

    shrx    r16d, r17d, r16d

    test    r16d, r16d

    jne     .LBB1_26

    cmp     r11d, eax

    cmovb   eax, r11d

    shlx    eax, edx, eax

    jmp     .LBB1_22

.LBB1_28:

    mov     rdi, qword ptr [rip + std::cout@GOTPCREL]

    call    std::ostream& std::ostream::_M_insert<long>(long)@PLT

    mov     byte ptr [rsp + 3], 10

    mov     rcx, qword ptr [rax]

    mov     rcx, qword ptr [rcx - 24]

    cmp     qword ptr [rax + rcx + 16], 0

    je      .LBB1_31

    lea     rsi, [rsp + 3]

    mov     edx, 1

    mov     rdi, rax

    call    std::basic_ostream<char, std::char_traits<char>>& std::__ostream_insert<char, std::char_traits<char>>(std::basic_ostream<char, std::char_traits<char>>&, char const*, long)@PLT

    jmp     .LBB1_32

.LBB1_31:

    mov     rdi, rax

    mov     esi, 10

    call    std::ostream::put(char)@PLT

.LBB1_32:

    test    r14, r14

    je      .LBB1_34

    {nf}    sub     rsi, rbp, r14

    mov     rdi, r14

    call    operator delete(void*, unsigned long)@PLT

.LBB1_34:

    test    rbx, rbx

    je      .LBB1_36

    {nf}    sub     rsi, qword ptr [rsp + 8], rbx

    mov     rdi, rbx

    call    operator delete(void*, unsigned long)@PLT

.LBB1_36:

    add     rsp, 16

    pop2p   rbx, r12

    pop2p   r13, r14

    pop2p   r15, rbp

    pop     rax

    ret

.LBB1_37:

    lea     rdi, [rip + .L.str.4]

    call    std::__throw_length_error(char const*)@PLT

.LBB1_38:

    lea     rdi, [rip + .L.str.4]

    call    std::__throw_length_error(char const*)@PLT

    jmp     .LBB1_47

    mov     r15, rax

    test    r14, r14

    jne     .LBB1_45

    test    rbx, rbx

    jne     .LBB1_48

    jmp     .LBB1_43

    mov     r15, rax

.LBB1_45:

    {nf}    sub     rsi, rbp, r14

    mov     rdi, r14

    call    operator delete(void*, unsigned long)@PLT

    test    rbx, rbx

    jne     .LBB1_48

.LBB1_43:

    mov     rdi, r15

    call    _Unwind_Resume@PLT

.LBB1_47:

    mov     r15, rax

.LBB1_48:

    {nf}    sub     rsi, qword ptr [rsp + 8], rbx

    mov     rdi, rbx

    call    operator delete(void*, unsigned long)@PLT

    mov     rdi, r15

    call    _Unwind_Resume@PLT

main:

    push    rax

    xor     edi, edi

    call    std::ios_base::sync_with_stdio(bool)@PLT

    mov     rax, qword ptr [rip + std::cin@GOTPCREL]

    mov     rcx, qword ptr [rax]

    mov     rcx, qword ptr [rcx - 24]

    mov     qword ptr [rax + rcx + 216], 0

    lea     rdi, [rip + .L.str]

    lea     rsi, [rip + .L.str.1]

    call    fopen@PLT

    test    rax, rax

    je      .LBB2_2

    mov     rax, qword ptr [rip + stdin@GOTPCREL]

    mov     rdx, qword ptr [rax]

    lea     rdi, [rip + .L.str]

    lea     rsi, [rip + .L.str.1]

    call    freopen@PLT

    mov     rax, qword ptr [rip + stdout@GOTPCREL]

    mov     rdx, qword ptr [rax]

    lea     rdi, [rip + .L.str.2]

    lea     rsi, [rip + .L.str.3]

    call    freopen@PLT

.LBB2_2:

    call    Yoshi()

    xor     eax, eax

    pop     rcx

    ret

.L.str:

    .asciz  ".inp"

.L.str.1:

    .asciz  "r"

.L.str.2:

    .asciz  ".out"

.L.str.3:

    .asciz  "w"

.L.str.4:

    .asciz  "cannot create std::vector larger than max_size()"

DW.ref._gxxpersonality_v0:

    .quad   __gxx_personality_v0

AMD là rác thải

Intel là rác thải

ARM là rác thải

Mọi thứ đều là rác thải...

SAY MY NAME!!! LOOK BELOW FOR MORE INFORMATION!!!

This is how the Super Mario Galaxy movie should have been (according to my 3 AM fever dream)

Bro, I have to talk about the craziest fever dream I’ve had in a long time, because this was not just a dream — this was an entire cinematic universe that my brain cooked up at like 3 AM.

So I had just watched the Mario Galaxy movie, and I loved it. I loved the fights, I loved the references, I loved how much fan service it had, and I was already hyped. But then I went to sleep… and my brain somehow made an even more insane, more cinematic, more peak version of it.

And in this dream, it starts exactly like Super Mario Galaxy movie, but with a huge twist.

Instead of Mario and Luigi going to the honey hive planet, they end up in the Cap Kingdom from Super Mario Odyssey — Cappy’s home. And there’s a massive crisis happening there. So now the movie immediately becomes this a short adventure where Mario and Luigi have to help Cappy save his kingdom, and in my version I even invented a new character: Cappy’s brother. So now Mario has Cappy, Luigi has this new cap partner, and on top of that, Yoshi is there too. So right away the team-up energy is already at maximum levels.

And then the stakes explode.

Because now Bowser Jr. is the one making moves. He captures Rosalina and Princess Peach (instead of just Rosalina), and the whole point is to use their power to destroy entire planets — entire galaxies. And the weapon in my dream is this giant Bowser Planet (slightly different from the Galaxy movie), and I’m talking a planet with Bowser’s face built into it. Like the Death Star, but instead of a machine, it’s got this huge Bowser face in the middle, and it also reminded me of Ego the Living Planet from Guardians of the Galaxy Vol. 2, where the whole planet has the villain’s face and presence built into it. That’s the kind of scale this had.

So now Peach and Rosalina are both captured, not just one of them, and Bowser Jr. is doing all of this because, in classic Bowser Jr. fashion, he’s trying to help his father and take things to the next level.

Then the rescue mission starts.

Mario, Luigi, Cappy, Luigi’s new cap partner in my version, and Yoshi all go in together. And the whole fight scene plays like a giant playable movie (similar to the final battle in the movie with a few additional contents). Mario is using Cappy the way you do in Odyssey, with Cappy helping him dodge, attack, and move through combat. Yoshi is throwing eggs. Everybody is moving at once. The whole thing already feels like a final boss battle… and then it gets even crazier.

Because then that giant dragon from Super Mario Odyssey shows up, and now the fight is on a completely different level.

And after all of that chaos, yes, you still get Dry Bowser. But that’s not even the real end of it.

Because then Bowser Jr. pulls out the magic paintbrush weapon, and he restores Dry Bowser back into regular Bowser.

But not just regular Bowser.

He comes back as Fury Bowser.

So now Bowser becomes absolutely gigantic. Kaiju-level. World-ending level. The kind of final boss where the entire movie suddenly feels too small to contain him.

And Mario and Luigi do not have the Giga Bell or the giant cat transformation to match him, so now they have to improvise. They hit a Question Block, get a Star power-up, combine that with both caps, and in my dream they basically become this ridiculous, god-tier Mario and Luigi fusion form. Not just powered up — fused. Like a full “this is the hypest thing ever put on screen” transformation.

And they use that power to actually contain Bowser and capture him using the fused Cappy power.

But even that is not the final boss.

Because then the brush Jr has falls into electrical circuits and gets corrupted. It infects the systems of the Bowser Planet, takes control of the whole world, and now the real final villain is not Bowser anymore.

The real final villain is the planet itself.

So now the movie becomes this insane galaxy-scale war where Mario, Luigi, and Yoshi have to destroy a living berserk planet that has gone completely out of control. Bowser is gigantic. The planet is gigantic. The whole battlefield is cosmic. And then Yoshi powers up too — giant Yoshi with Giga mushroom found in another question mark block— and now Bowser (technically Mario and Luigi in Bowsers body) is literally riding Yoshi into battle.

That is the kind of fever dream this was.

And then Bowser unleashes this giant beam attack — basically a full Kamehameha-style dragon breath — and the whole corrupted planet is finally destroyed. Peach and Rosalina are saved. Mario and Luigi survive. Yoshi shrinks back down. Everyone escapes. And for one second, it feels like the story is finally over.

But it’s not over.

Because now we get the credit scene. (Which is way more different than what we saw in the actual Galaxy movie)

Instead of Bowser and Bowser Jr. just ending up locked away and humiliated, they crash back down into the Mushroom Kingdom and find a glowing question mark . And this power-up is the Red Star from Super Mario Galaxy.

And in my version, Bowser gets it.

Not Mario. Bowser and Jr.

So now Bowser and Bowser Jr. take the Red Star, head into space, go to the Moon Kingdom, team up with the rabbit enemies from Odyssey — the Broodals — and start building a new army. Bowser starts rebuilding his power, rebuilding his world, and in my dream he even creates the Koopalings using the star power up as a part of this new setup.

That alone would already be enough to set up another movie.

But then my brain was like, “No. We’re not done.”

Because Luigi gets his own side story too.

Now Luigi goes into this whole haunted-kingdom direction, basically Luigi’s Mansion mode. He gets ghost-hunting gear, goes into a kingdom full of ghosts, and ends up in the Sand Kingdom, where he meets Princess Daisy. And that becomes this whole side setup where Luigi gets his own mini arc, almost like a TV spin-off inside the larger cinematic universe. So now the dream is not just making one sequel — it’s making a sequel, a spin-off, and a future trilogy plan at the same time.

And then we hit the final post-credits scene. (Previous one was the first credits scene)

Rosalina gets an emergency signal.

The screen goes dark.

And all you see is the Hylian Shield.

Not a big reveal shot. Just the shield.

And instantly you know: Link is here.

And now the dream becomes a full Super Smash Bros. movie.

Because the true villain is not Bowser. It’s not even the corrupted planet. The true villain is Master Hand 💀😭.

So now Link is fighting Ganon, because Ganon has some kind of pact with Master Hand, and the threat is no longer one kingdom or one galaxy — it’s all universes. Multiversal madness. Total collapse. Total crossover war.

So Link (after beating Gannon) joins Mario, Luigi, Yoshi, and the cap team, and they start traveling across worlds to warn everybody.

And then out of nowhere, Detective Pikachu shows up — specifically the Ryan Reynolds version — literally dropping in to figure out what the hell is going on like he’s investigating the end of reality itself.

And now it becomes a full team-up movie and then find out where the Hand was staying.

So:

Mario.

Luigi.

Yoshi.

Link.

Bowser and Jr and the Koopalings eventually joining in.

Everybody.

Then Star Fox and his team show up.

Then Zelda comes in.

Then Palutena.

Then all the Nintendo princesses start arriving.

And even with all of that… they’re still losing.

NOW THE JUCY PART!

A nether portal opens!

And Steve from Minecraft shows up — and yes, he’s voiced by Jack Black — and he comes in with full “I am Steve” energy. Steve starts building castles for the war, teaming up with Bowser and Bowser is firing cannonballs, the whole battlefield becomes this insane mash-up of every gaming universe possible.

Then Sonic enters using his rings.

Steve literally builds him a rail.

Sonic launches himself at full speed into battle.

And then even the Angry Birds show up cuz they in space (Angry Birds Space!)

At this point, this is not just crossover fan service anymore. This is a complete gaming apocalypse Avengers-level event.

Now Hand is COOKED! Kirby shows up from the forgotten land as the space was ripping apart over there also!

And the final image in my head was Mario and Luigi taking Link’s sword, using their jump ability to launch high enough into the sky, and cutting Master Hand in half.

That’s the ending.

That’s how they save the entire GAMING multiverse.

That’s how they bring peace back to the Nintendo and other galaxies.

And then, somehow, my brain still had one last move left.

Because in the final final post-credit scene, we find out the real mastermind behind all of it was Doctor Doom.

So now the whole thing connects into this even bigger multiverse setup where Doctor Doom wanted to destroy the gaming universe because it had become too powerful with SOOOO MANY IPs. So he created Master Hand as part of the plan, it failed, and now he’s furious.

And then — because apparently my sleeping brain has no chill whatsoever — I even added Howard the Duck into the setup as another wild-card crossover piece entering the game universe.

So yeah…

That was the dream.

I’m telling you right now — I did not just sleep.

I attended the premiere.

Also MARIO AND LUIGI WILL RETURN IN DOOMSDAY!